Coldbox and VueJS untangled

Using commandbox Lucee for production

We all know, commandbox is a wonderful tool for cfml development projects. It is very easy to spin up some version of Lucee or Adobe ColdFusion, configure a few settings and try out your code with this version. If you want to try other Lucee or ACF versions, you just spin up another version and try again. If you want to save yourself the hassle of configuring this new server again, you can export your settings from the previous version by using cfconfig and import it again.
Since commandbox can install lucee and ACF versions, the question arises if commandbox lucee (or ACF) is suitable for production. This question will come back now and then on the coldfusion and boxteam slack, and until recently I would say: no problem! As CTO and owner of a hosting company I decided this setup was capable for production for several of our customers. But I changed my mind, so let me explain.

Web server or Undertow

This is not really a problem, but just a choice you can make. Nginx and Apache are easy to configure for experienced sysadmins, have excellent rewrite and logging options, and it is almost trivial to install SSL certificates. Undertow can do most of this stuff, but syntax is not standard, so more work for our lazy sysadmins. They don’t want new tools if the existing ones are OK so we put nginx or apache in front of Lucee.

Choice of a webserver is just a matter of taste, but as soon as we wanted to update lucee we opened a can of worms.

Some example

Let me give an example of using different lucee versions, and let’s see what we need. For easy migration between versions you have to install cfconfig so we can can export and import lucee settings:

box install commandbox-cfconfig

So, we start our project with Lucee 5.3.6. You can start a webserver by starting commandbox and from commandbox itself:

start cfengine=lucee@5.3.6

So it will download the latest and greatest version of Lucee 5.3.6. The only thing you have to do is configure some settings. This can be done from the lucee admin, but if you are comfortable with cfconfig most setting can also be created with this module.
When you are ready to use a newer version you can export your settings, stop your old version, start a new one, and import your settings. For example:

cfconfig export to=mysettings.json
stop
start cfengine=lucee@5.3.7
cfconfig import from=mysettings.json
restart

By executing these commands we have a new shiny Lucee version, the same engine settings so all is fine. Or not?

NO! Before you are going to use commandbox lucee versions you have to be aware of a few caveats. We found out the hard way. You can still use commandbox lucee in production, but you can run into trouble if you don’t understand all details.

Pinning

So let’s say we use 5.3.7 in production and we are using the latest version, which was 5.3.7.47 at the time we deployed this.. What happens if a new Lucee version becomes available, like 5.3.7.48?
As soon as we restart the lucee server it will load 5.3.7.48 and drop all settings. Since we do unattended updates, our application breaks. Luckily we have content monitoring so our sysadmins have to wake up and fix the problem. So ALWAYS PIN your version. I wrote a blogpost about this some weeks ago because I was quite frustrated when I discovered this. We don’t talk about angry customers yet. Pinning is easy, but you just have to know the details. If you always want to keep at 5.3.7.47 you have to specify it like this. Notice the PLUS sign, which makes sure you will stay on the same lucee version all the time, until you decide you need something else.

start cfengine=lucee@5.3.7+47

So pinning solves loosing my settings, because we update manually and apply all cfconfig tricks. Does that solve all problems?

Unfortunately not, so read on.

Licensing issues

In this setup we were using the Ortus Redis extension, which has a license file. So after restoring our settings using cfconfig, the setup was still broken. This could only be solved by finding out where the license file was located, and copy the license file to a new location. According to the docs license.properties is located here: {lucee-server}/WEB-INF/lucee-server/context/context/ortus/redis/license.properties, so you only have to find out where the lucee server home is located. This is different for each version, but can be read from commandbox.

So license file moved to the new location. Problem solved?

Unfortunately not.

More licensing issues

Now our license file is invalid. This makes sense since we had a simple single server license. When you activate this license it will be tied to your luceeID which is unique for every lucee version you spin up. So new lucee version means invalid license, and if we Europeans do this kind of work early in the morning all people who can fix this part of the problem are still asleep. It took a while and four different people at Ortus before we all realized our setup was not really compatible with Ortus licensing for single servers. So we finally exchanged our license for a new license for containerized servers. This way we could upgrade our lucee version, move the license file to the correct location, restart the server and everything was fine.

So licensing issues solved. Happy? Not really yet.

Usability issues with upgrades

For developers it is a bonus if you can use multiple versions and switch easily. But my sysadmins and my customers don’t care. They were used to a simple Lucee admin, where they could push an update button, select the correct version and the server was back again in a very short amount of time. Now they have to export configs, stop a version, start a new version with the right syntax for pinning, replace their licenses for redis, move around license files and create some new directories, and now we are not even talking about additional setup of FusionReactor. They think it is too complicated. I think they just need an incremental upgrade, just something simular to the ultra simple ‘standard’ lucee setup.

I had some discussion about a simpler upgrade feature. If we want to use this for production, we should leave the developer mindset and go into ‘customer mode’ or ‘sysadmin mode’. For developers it is quite easy to fire a few commands to update the system. But my customers and sysadmins have to do a lot more than before, so they hate this system. We can call that irrelevant, but it isn’t. They have to learn a new system, just because I think commandbox is cool….

What we did now: we pinned a lucee version and our customers is now doing updates from the lucee admin, and never try to update from commandbox. This makes them happy. Only disadvantage: commandbox is reporting the wrong lucee version. But our monitoring systems can still see the correct version, so we can live with that.

Conclusion

Commandbox is a wonderful tool. But if you are using it for spinning up Lucee production servers, you really have to know what you are doing. Customers hate it when their update procedures become more complicated. They want to keep things simple.

2 Comments

  1. Tom

    Thanks for writing up the woes you experienced. I’m writing an app for work using Commandbox/Lucee 5.x and am ready to move it to production. It’s a very small app that only a few teammates will use so we can get away with something light weight. Nice to know we don’t necessarily need IIS or Apache but also good to know it’s not all sunshine and rainbows using just Commandbox, too. And yes, I, too, think Commandbox is cool.

  2. BKBK

    Useful, informative article about using CommandBox Lucee in a production environment.
    From my experience, you can summarize in one word the greatest risks associated with version-changes in any software: integration. That is, the common ground where two independent software applications meet and work together. In this case, CommandBox and Lucee.

    I expect more such CommandBox Lucee headaches to emerge in future. Let’s hope fellow developers at Ortus think likewise, and will take a closer look at the CommandBox-Lucee integration.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© 2024 ShiftInsert.nl

Theme by Anders NorenUp ↑