I use the official Lucee docker image and I use the

LUCEE_EXTENSIONS

environment variable, along with (the baked-in)

prewarm.sh

. Now that I'm using (Ortus's) CFConfig, I'm interested in porting over to `config.json`'s

extensions {}

configuration. is that even a thing in a non-CommandBox context? If so, what do I need to do? Sill a

prewarm.sh

run?

We use the Lucee images. I just recently went through the process of upgrading from Lucee 5 to 6, getting rid of the xml files in favor of the CFConfig.json file. Our “base” image has just the Lucee Admin extension via the config file, like so…

"extensions": [
		{
			"id": "CED6227E-0F49-6367-A68D21AACA6B07E8",
			"name": "Lucee Administrator",
			"version": "1.0.0.5"
		}
	],

But each of our apps that use our base image were already set up to use the

LUCEE_EXTENSIONS

environment variable to install what they need (e.g. Oracle, Postgres, s3, Redis, etc.) so we are leaving it there at the app level. You can do either, I’m not sure if there is an advantage to one route vs. the other, but would love to hear it if there is.

I'm kinda guessing that your extension installation then happens at runtime versus build-time, unless you've got a prewarm in the mix somewhere.

I’m befuddled by the whole prewarm thing, honestly. We started using the Lucee images early before that all was available. It just hasn’t clicked for me as to why it matters.

I've been using the Lucee images before

prewarm.sh

was built-in. Without doing prewarm (or my hand-rolled version of prewarm), I found that one out of a hundred deployments would fail because of a problem with deferred (runtime) installation, so I've never trusted Lucee since to install plugins at anything but build-time.

Ok, trying to translate what that means, exactly. Over the weekend, we happened to have a pod that was evicted from a node and a new one started in its place (normal stuff). It happened while the Lucee extensions were not available on Saturday so the app started up but didn’t have the Oracle extension installed, which means it wasn’t worth much. We restarted the pod after the extensions were available and all was well again. Are you saying the prewarm would try to address this situation? Sorry, feel free to talk to me like I’m 5. 😄

Yeah, I think you got a taste of why I do/verify all the extension installation at build time. I think it's bad news to defer any building to runtime.

Interesting. Still trying to wrap my head around it.

A failed build is way better than a flaky runtime.

Ok, that’s what I was thinking (“well, the app still would’ve tanked because it couldn’t find the extension. It just would’ve tanked differently” were my thoughts). Interesting.

A container shouldn't have to, for instance, reach out to the internet to complete its build when you start the container. That's a dodgy thing to do and that's what building ought to be for.