When using the "light" version of Lucee, I'm gonna need to install a few extensions. I see the docs here: https://docs.lucee.org/guides/cookbooks/Extension-Installation.html#extension-installation-via-lex-file. If I want to manage this via my Dockerfile, is the correct approach to stick the various .lex files in the

lucee-server/deploy/

, as per those docs? I only ask cos that mechanism seems to be a way of installing an extension "on the fly" rather than "at install time"? I'd like the extensions I need "already installed" in my Docker image, rather than it being another step I need to wait to run when the container starts up (if that makes sense). EG: I wanna do it once when I create the image, not every time I start a new container.

Google lucee warmup :)

That does not seem to address my latter paragraph. That will only grab the extension once Lucee is running right, so after a container is started. Same as far as I can tell with the

LUCEE_EXTENSIONS

approach (which is what I got from googling "lucee warmup"). I want to install the extensions in the image. Not in a running container.

Lucee needs to be running to install extensions, both those approaches install the extensions immediately as it starts up and installs itself on the file system, before it boots if you want them pre installed in your image the deploy/env var and warmup achieves exactly what you are asking

@Adam Cameron Maybe good / maybe bad suggestion depending on your take on these things, but after the first time you docker up, after the extensions install, you could do a docker commit and use the new image with them already installed. Its technically a golden image but I haven't found that to be a huge problem IRL for things like this. And the new image will start like way faster to boot.

Yeah I was thinking about that after Zac's comment. Not an approach I've used before, but should work. Was gonna look into it. I'm kinda spoilt using

apt-install

/

docker-php-ext-install

etc which all run when building the image from the outset. Was hoping there was a Lucee / Tomcat / something equiv. Or just a file copy or something.

Dockerfile

I do not have an preconceptions re the approach to any of this regarding Lucee; I just know when I run Lucee light the app breaks cos I need the image extension. No doubt there are others I need too. I have not looked into which I do / do not need yet. My general experience is there's a mechanism to have apps / extensions installed in the image file system when building the image, eg:

run apt install vim

in the Dockerfile... goes an installs vim during image build. Similarly with PHP extensions. All the work is done when building the image. All you appear to be doing in that Dockerfile, @jamiejackson is telling Lucee which extensions to install when Lucee runs, which doesn't occur until one runs the container. Not build the image. It's just setting env vars that Lucee looks for when it starts. It's not a show stopper for me at all. Just a less good approach than it could be.

Incorrect. Those two lines install the extension at build time. These lines are magic.

I shall defer to @Mark Drew (he/him) as he knows this stuff inside out

Specify any other extensions you need as well (the syntax I use let's you add as many distinct ENV lines as you want).

Ooh, OK, I misread

RUN LUCEE_ENABLE_WARMUP=true /usr/local/tomcat/bin/catalina.sh start

. Yeah gotcha. We don't use ORM as we're not complete lunatics, so NP there. (full disclosure: we do use CFWheels though (don't

@

me), which kinda claims it has an "ORM" even though... well... it's a stretch to describe it thus)

Adam -- If you didn't already figure this out, the way I build Docker images with the official lite image is add :

ENV _LUCEE_EXTENSIONS_ "D46B46A9-A0E3-44E1-D972A04AC3A8DC10;name=Chart;version=1.0.19.24,B737ABC4-D43F-4D91-8E8E973E37C40D1B;name=Images;version=2.0.0.25"

I am sorry for being late to this thread, was out in Germany for CFCamp. This is a sample Dockerfile for building including lucee extensions and what not: https://github.com/cybersonic/Lucee-Task-Event-Gateways-Kubernetes/blob/main/Dockerfile

Here is the dockerfile I use for all of my builds : https://gist.github.com/quetwo/51b94c15fdd89c27622118e32a189180 It works for Lucee 5.x and 6.x

To help @Adam Cameron it would be good to show what’s in your prewarm.sh file

Ah, if

RUN LUCEE_ENABLE_WARMUP=true /usr/local/tomcat/bin/catalina.sh start

does the trick, that's fine.

Marc -- my prewarm.sh is the stock one. I add a line in there for the password line for the setenv.sh so I can have it create the right file at runtime based on the environment variable of the container.

Makes sense. I do it via build args but can also been done in envs.

In my case, I use the same containers for dev/test/prod. So, I inject different variables and passwords into each one depending on the environment. If you bake them in at build time, you lose that flexibility.

Gotcher, we remove lucee admin in this case, and map configs through configMaps

Same -- but the lucee admin password is still used for some runtime config items (like setting up REST endpoints and adding in extensions on the fly)

Ahh, true that 🙂

In my setup, I usually use a secrets manager to inject certain passwords (like the lucee password) as an environment variable when the container starts.

For that particular use case, using secret directly, with a custom target location is cleanest. (Lots of other use cases need a secrets-to-env-var entrypoint routine, but not that one.)

mixed feelngs about that, the issue with passwords as env vars is that env vars are statically snapshotted into the server scope on startup, whereas dropping a password.txt file under the server context is only there for a moment at startup...

zackster -- I fully agree... unfortunately, we don't have a ton of ways to get around it either, since we still need to pass that password to apps to enable things like REST endpoints and load extensions.

But generally if I want to update the env, I just restart the container anyway, this is the way 🙂 See https://12factor.net/config

image.png

Mark -- exactly that. Grab basic configs through env variables, scaffold everything beyond that. I shouldn't have to touch a single file on the system to move between environments. It also makes testing more consistent because I don't have to worry about a config file in X environment impacting something down the line. Or potentially checking in secrets to a public repo.