We don't seem to have a Kubernetes channel, so I'll try asking here - Has anyone gotten commandbox containers to read environment vars from

configmaps

/

secrets

? I'm looking to inject my set of vars at container start time, without fully relying on a populated

.env

file.

Does anyone have experience with Rancher/containerd/nerdctl as a docker alternative? I'm a complete docker noob but had got a little nginx+commandbox/lucee test swarm working nicely via compose on Docker Desktop. Having switched to Rancher Desktop the swarm comes up ok, but nginx can't seem to resolve the commandbox/lucee proxy hostname internally:

failed (111: Connection refused) while resolving, resolver: 127.0.0.11:53

and then

app1 could not be resolved (110: Operation timed out)

I tried changing the resolver in the nginx conf and various other suggestions on SO but to no avail.

Having an issue with FusionReactor with command box when building my container for arm64. All is going fine until FusionReactor decides it wants to use libfrjvmti_x64.so - which is the amd64 version. Can't see anything in any docs that mentions specific instruction / flags for arm or am I missing something obvious? If I don't do a box install commandbox-fusionreactor in my docker build the arm container works as expected

Huzzah - liking the power of docker + command box - in less than a week I have a stack of coldfusion, mariadb, opensearch, redis and a couple of other services all playing nicely on intel and arm deployed on dev macs and AWS - much appreciated @bdw429s and the ortus gang for making the command box bit simple (when you have the right version) 👍

And just for reference, I've posted this but I'll post it again because it's fun to look at. This tests were using Lucee. Here's some numbers I ran for a client who was converting over to the CommandBox-based images with a bunch of possible options for their final images Basic docker file with no warm up • 788 Meg image size (This is only small-ish because it doesn't have any CF engine downloaded/installed) • 45 seconds from start to serving requests • Has external web hits to confirm latest versions of CF Engine, FR, etc and downloads CF Engine on every boot "Warmed up" CF Engine but not finalized • 1.2 Gig image size • 19 seconds from start to serving requests • Has external web hits to confirm latest versions of CF Engine, FR, etc on every boot Finalized single-stage build • 900 Meg image size • 9 seconds from start to serving requests • No external web hits and no downloading Finalized multi-stage build • 466 Meg image size • 9 seconds from start to serving requests • No external web hits and no downloading

getting an NPE during the warmup script, complaining that

Provider lucee.runtime.script.LuceeScriptEngineFactory could not be instantiated

and an array out of bounds (in thread)

What's the best approach to distributed/parallel sessions in a multi-container environment? We have a Redis service so thought it would be easy to config the Lucee containers to store them there, but apparently that only works with CFML sessions and ours are J2EE.

Following the docker/getting-started tutorial and doing fine till I hit binding. I've tried the example commands on my Windows 10 machine for both windows cmd cli and powershell. In both cases I get a silent fail and examining the logs see that it can't find the package.json file in the root of the App folder. Any suggestions for debugging? I can see the package.json in my local directory that I'm trying to bind, so wondering if the App folder contents not getting copied over, or the json is somehow blocked... This is my first foray into Docker, having used Virtual Box in the past...

Does anyone know if it’s possible to have commandbox exit or break the docker build process when an error has occurred? It currently just keeps building.

Hey quick Dockerfile Q. Is there any reason why one might do this:

CMD export SOME_ENV_VAR=some_value

As opposed to just:

ENV SOME_ENV_VAR=some_value

In our Dockerfile we're chaining that

export

with a call to start the actual process, eg:

CMD export SOME_ENV_VAR=some_value && supervisord -c /etc/supervisor/supervisord.conf

But pretty sure that doesn't make any difference to anything. I guess the question is whether there's any difference in how an env variable gets set between

ENV

and calling

export

from the shell.

with

export

the env var will only be available during the build process of the intermediate container that is created while building, it does not persist and will not be available when you run a container from that image. With

ENV

it will persist. See https://stackoverflow.com/questions/33379393/docker-env-vs-run-export

oops ... could be that there's a difference between

RUN export

and

CMD export

... not sure

Yeah I think it is that latter difference. To be clear, both approaches seem to do what is intended... in this case it's setting

LUCEE_JAVA_OPTS

... the container ends up with the correct value being set. Just wondering if I'm missing some idiosyncrasy.

Just curious - anyone here tried Podman instead of Docker? Looks like the newer podman version provide a 'docker' and 'docker-compose' command so it looks fairly seamless. I may give it a try.

Happy Monday, folks. How are y'all handling sessions in Dockerized CFML apps in production? We've always used either sticky sessions alone or with J2EE session replication. I'm currently more interested in info about CF2021 than Lucee.

I know there are native Lucee M1 / ARM images - apologies if this has been asked before, but curious if there are impediments to a Commandbox docker builder on M1? Or is it just a matter of using the right JDK base image?

I've finally talked the powers that be to update to CF2021 and want to spin it up on my local system to see what breaks in our ancient application. I know 2021 is significantly different with the package manager. How does one set this up with Docker + Commandbox? Do I use the base image and then run cfpm command and build my own image? Or has @bdw429s already figured this out and has some snazzy way to do it? FWIW I have not read any docs (yet) LOL.

I posted on here earlier if anyone had tried Podman (a drop in Docker replacement). This weekend it was cold and rainy so I decided to give it a try - I even dusted off my blog to write about it LOL https://thecrumb.com/posts/2022-11-15-docker-to-podman/

Followup to my earlier post - this time I try Podman Desktop: https://thecrumb.com/posts/2022-11-17-podman-desktop/ ;tldr - basically a drop in replacement for Docker Desktop (can even be use with Docker)

Hi folks. I'm pretty fed up with the reliability/repeatability problems of installing Lucee extensions at build time in the official Lucee image. Collectively, I've probably wasted a work week or three on it over the last several years. I know that the big competitor to the official Lucee image is the Ortus one, though I've avoided it so far because it is (or was) pretty convoluted under the hood, but I'm more open to it now that I've steadily soured to the official image. Can someone who knows the Ortus image explain to me the mechanics of its extension installation, and how it knows that extension installation (both *.lex and repo-based) is complete before it shuts down the servlet container? (That's always been my problem with the official image: No simple way to know that the extension installation is complete before shutting down the servlet, which makes it so that 1% of your builds have a badly-built image, with no outward indication that anything went wrong.)

do you happen to know how to "reset" the mechanism that sets the admin password from

password.txt

? since my container image build-time warmup needs to query the admin (with a temporary password) but then needs a different password at container run-time, i've had trouble getting it to pick up that runtime admin password. IIRC, once lucee does the

password.txt

thing, it won't do it again.

New place to do docker... heh. https://codesandbox.io/blog/introducing-docker-support-in-codesandbox

Do you swarm because you still believe it has a future. It looks like you were right! ( https://docs.docker.com/engine/release-notes/23.0/ ) The current release contains long awaited experimental support for SwarmKit cluster volumes and new jobs for stack deploy. There are other features for swarm also. It obviously the commitment to support swarm is holding true. Oh, below here is a link to Bret Fisher's Awesome Swarm repo to collect a list of great swarm links for resources.