cfml server vs standalone application

[Chris Blackwell]

About 2 years ago we binned all of our CF/Railo servers on to which we deployed applications and moved to a model where each application (logical app not cfml application) is deployed in its own instance of Railo (soon to be Lucee once we finish testing) in its own JVM.  To do this we package our app as a war, and embedded it with tomcat in an executable jar.   This jar is then deployed out to the cluster.

We treat Lucee & tomcat as project dependencies, not as a resource or server required to deploy onto. This might not be to everyone's taste, but it works well for our workflow, and we do half a dozen deployments to our staging servers some days.

In this model the whole server/web config hierarchy becomes unnecessary, there just needs to be one config. We don't use the admin web ui once the app is packaged, in fact we have to explicitly block access to it, so it'd be nice to be able to disable it.  Also applications are free to change Lucee versions independently of each other, without requiring a server upgrade and affecting/testing every other app currently running.

Looking at other platforms, like Play Framework and Grails which have some parallels with Lucee, they support a standalone packaging mechanism, as well as WAR packaging.

I've seen a lot of effort in the community around installers and connectors (all good work obviously)  but it's all intended to mimic the behaviour or of ColdFusion, and I'm not sure that's A Good Thing 

If I can package my app in a discrete executable format (and I've coded it to play nicely in a cluster) then I can easily deploy it on 2, 10 or 100 nodes to achieve scale.   I think its this kind of feature that will get a platform adopted, not how easy it is to do virtual hosting.

There was probably a point to this when I started writing it a couple of days a go, but I've lost it now, or maybe a while back tbh.  So i'm just going to hit send as I'm curious to see what others think of this as a packaging a deployment model.

Chris

[Dominic Watson]

I for one would love to see the process you are using written up as explicitly as possible somewhere. I agree with your approach and angle completely, would be great to see some tooling/guides to achieve what you want in the "best" manner.

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAB%3DtfTo%3D%2BBsjSUS4m-2BQvUb%2B7p1QOFWhdORVQheLZW5hHmN9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

Pixl8 Interactive, 3 Tun Yard, Peardon Street, London SW8 3HT, United Kingdom T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: in...@pixl8.co.uk

Follow us on: Facebook Twitter LinkedIn

CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended solely for the addressee, is strictly confidential and may also be subject to legal, professional or other privilege or may be protected by work product immunity or other legal rules. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. Pixl8 Interactive Ltd Registered in England. Registered number: 04336501. Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB

[Nando Breiter]

Chris,

 

I've seen a lot of effort in the community around installers and connectors (all good work obviously)  but it's all intended to mimic the behaviour or of ColdFusion, and I'm not sure that's A Good Thing 

If I can package my app in a discrete executable format (and I've coded it to play nicely in a cluster) then I can easily deploy it on 2, 10 or 100 nodes to achieve scale.   I think its this kind of feature that will get a platform adopted, not how easy it is to do virtual hosting.

Do you mean "If I have packaged my app ..." 

I'm not sure if the issue you are pointing toward is one of education / information, or the ease with with Lucee can be packaged in a discrete executable format. It seems to me that you have said that you already package your apps in the way you want to.

[Dominic Watson]

Thinking on it further, I think a little organisation on the wiki would be a perfect space for this:

- Running Lucee

---- Recipes

-------- Windows

-------- Linux

-------- OSX

---- Theory
-------- Servlet engines

-------- Web servers

---- Building environments (or somesuch title)

Of course, the standard recipes for running lucee should be promoted and pointed to early on in that space so that new comers are not overwhelmed.

[Chris Blackwell]

On 4 March 2015 at 10:47, Nando Breiter <na...@aria-media.com> wrote:

Do you mean "If I have packaged my app ..." 

Yes you are correct, I phrased that poorly. We can and are packaging our apps as executable jar's already, using maven and the tomcat7-maven-plugin exec-war goal.  Which, as you say, is very easy

[Jochem van Dieten]

On Wed, Mar 4, 2015 at 11:18 AM, Chris Blackwell wrote:

About 2 years ago we binned all of our CF/Railo servers on to which we deployed applications and moved to a model where each application (logical app not cfml application) is deployed in its own instance of Railo (soon to be Lucee once we finish testing) in its own JVM.  To do this we package our app as a war, and embedded it with tomcat in an executable jar.   This jar is then deployed out to the cluster.

We go as far as packaging it as a war, but don't embed it with Tomcat. I'm not all that concerned about putting Tomcat outside the development scope and in the sysadmin scope, it has never given us much trouble. And the effect is the same, the sysadmin can do his thing with the tools he is used to (apt-get or yum), and there us just one additional package from the buildserver of the development team.

 

I've seen a lot of effort in the community around installers and connectors (all good work obviously)  but it's all intended to mimic the behaviour or of ColdFusion, and I'm not sure that's A Good Thing 

If I can package my app in a discrete executable format (and I've coded it to play nicely in a cluster) then I can easily deploy it on 2, 10 or 100 nodes to achieve scale.   I think its this kind of feature that will get a platform adopted, not how easy it is to do virtual hosting.

The type of packaging I would like to see is operating system native packaging, i.e. .rpm or .deb. Once you have that it is really just a matter if adding the right repo to your package manager. I have in the past looked into what it would take to create a Debian package for Railo, but even if I build on existing packaging projects (i.e. tomcat, tomcat-user etc.) I found it rather daunting.

Jochem

--

Jochem van Dieten
http://jochem.vandieten.net/

[Christian Meis]

As I'm just starting to dig in the same direction I would certainly welcome being able to read up your processes here.

So if you would find some time to write up your way of doing that I would appreciate this!

Of course I could contribute in the form of "proof-reading" for a point of view not having done that now. And perhaps adding

information from my own research here as it fits in there.

Right now we are doing a part of virtual hosting as part of our normal hosting business (hosting websites for customers - in our

case all CFML based websites are also created by us). Those usually are smaller sites which are absolutely fine running on 

one of our shared hosting servers (performance-wise etc.).

But there are also projects that would be better described as "application", thus usually running on a/more dedicated machine(s)

at  the customers or in our datacenters. Here our usual setup a la "virtual hosting" is overly complex and adds unnecessary

overhead.

That's the reason we are also looking into deploying the whole "gang" as more-or-less standalone - mostly as you are describing

it. I'm in the process of reading up on how to package all the components, put the right configs in there etc.

So I suppose this topic could be of broader interest to other guys here too.

Christian

[Nando Breiter]

Yes you are correct, I phrased that poorly. We can and are packaging our apps as executable jar's already, using maven and the tomcat7-maven-plugin exec-war goal.  Which, as you say, is very easy

... if you know that the possibility exists, and if you know how to do it.

Ideally, if we are talking about Lucee adoption, a recorded presentation would help very much to provide an overview of the possibility, advantages and procedure for newcomers; and a writeup would solidify the procedure. I'm imagining a "Lucee TV" sort of thing. Would Google Hangouts, for instance, be the right medium for video presos regarding Lucee? 

[Chris Blackwell]

I'll look at writing up our methodology, and get an example maven project on github.

Give me a few days as I'm a bit sleep deprived atm, and stacked out in office hours.

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAGHrs%3D-Mz%2B8gVyMwJ2oPktOOV34h4GeM-gBSoG%2BXvGTaZ_QsuQ%40mail.gmail.com.

[Geoff Parkhurst]

On 4 March 2015 at 10:18, Chris Blackwell <ch...@team193.com> wrote:

> In this model the whole server/web config hierarchy becomes unnecessary,
> there just needs to be one config. We don't use the admin web ui once the
> app is packaged, in fact we have to explicitly block access to it, so it'd
> be nice to be able to disable it.

+1 to that... remove it entirely as an option.

It's certainly cut down the attack surface.

[Alex Skinner]

I have been talking a lot to Micha about things similar to this

Take a look at http://12factor.net  I'd like a build of Lucee which has no admin and that the dependencies are injected into your application using environment variables.

You can see an example of this here https://github.com/alexskinner/railo-heroku-template/blob/master/webroot/Application.cfc

In an ideal world I think there would be an inheritence model such that you could set your setting in either 

1. The application.cfc (In my opinion very wrong because its config in code)

2. In The xml file (Via the admin if you must)

3. Injected in via environment variables.

4. Your app gets given its config based on what it is and what environment its on from a central config server (We have this working for our needs)

You are right to point out that a lot of the deployment methods being talked about are quite traditional though we are also working on an NGINX/Undertow combo for very lightweight deployment.

Pixl8 is also working on a Server manager product that allows multi-lucee instance management and injection of environments settings.

A

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAC0HRKma7iNBG%3DD%3DMw9BA-MgcSo_DZHu%2Bmcn3O9ao-yMiupUxw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Alex Skinner
Managing Director

Pixl8 Interactive, 3 Tun Yard, Peardon Street, London SW8 3HT, United Kingdom T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: in...@pixl8.co.uk

[Chris Blackwell]

Hi Alex,

I had a quick look at undertow this afternoon, it looks very interesting. 

I've whipped up very rough example of running lucee with undertow here - https://github.com/d1rtym0nk3y/lucee-runner

Once built you can just do 

> java -jar LuceeRunner.jar /path/to/webroot

Let me know if you have any thought on where this could go, or if it looks useful

In railo-heroku-template I opted for environment variables because thats what heroku supports.  In our production apps we use a param in META-INF/context.xml that defines a default location for the config file

<Context>

    <Parameter name="configFile" value="/etc/appname/config.json"/>

</Context>

This can be retrieved in your application by 

getPageContext().getServletContext().getInitParameter('configFile');

This param gets overridden by the maven profiles to provide different configs for dev, test and staging

Cheers, Chris

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFrbJ5VfRxH7VvZ_aK3Bm9mWRzdUs6dj_AuZRLwupJQe8oPUrw%40mail.gmail.com.

[Igal @ Lucee.org]

very nice Chris!

Igal Sapir
Lucee Core Developer
Lucee.org

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAB%3DtfTpdmekF7okxgYfFVn8Hnyf5q6cVh9Vq8CVBu88WYFPc5g%40mail.gmail.com.

[Alex Skinner]

Hi Chris,

Cool stuff

Checkout http://cfmlprojects.org/artifacts/org/lucee/lucee.pomparent.heroku.runwar/

runwar is the project by Denny and its used by Commandbox too

A

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAB%3DtfTpdmekF7okxgYfFVn8Hnyf5q6cVh9Vq8CVBu88WYFPc5g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.