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