From lucee/lucee:220.127.116.11-nginx docker image, which will be deployed both on local developer machines using docker compose, and in Kubernetes as a privately published image.
The Lucee Admin password will vary by ENVIRONMENT. Therefore we need to be able to set an environment variable for LUCEE_PASSWORD, which is NOT part of the build process. Then when the container is spun up from the image, BEFORE Lucee starts, a script (which is copied in during build) is executed that will read the container’s environment variable and echo it into /opt/lucee/server/lucee-server/context/password.txt - after which Lucee will be spun up, read and encrypt the password, and delete the file.
How can I use a Docker entrypoint with the image specified above to do this?
No, because that injects the password file at build time. That would require a separate image for each environment. Kubernetes does not build the image, it takes an existing image, applies environment variables, and spins up the container(s) from it. Therefore, each container must read an environment variable and create the password.txt file when it is spun up.
EDIT: Also, storing the password.txt file in the Docker image is not a good idea.
The problem is, the Docker image i referenced above, lucee/lucee:18.104.22.168-nginx , HAS no entrypoint that I can tell. The Dockerfile has no reference to an entrypoint, nor does the instructions on the Docker page where the image is described.
My vote (if i had one) would be for this functionality to be just baked into future Lucee images as the means to set the Lucee admin password via env vars. It masks the need to create the password.txt file manually and somehow inject it, which (in our case at least) could have lead to a less secure way to do it by baking the password.txt file into the images one creates. But I’ll be the first to admit i’m no expert yet. =)
In Lucee terminology - what you think of a SNAPSHOT and what the LUCEE project thinks of as a SNAPSHOT are possibly different.
If you think of SNAPSHOTS as;
The latest Release with PATCHES to address known issues found since the release was published.
You’re on the right track.
So - the use of a SNAPSHOT in Production is not as “scarey” / “flakey” as you might otherwise envisage it to mean.
Of course - create an image with a SNAPSHOT - run YOUR application’s TESTS, prior to you creating your Release - but that’s just goo practice, no matter what libraries and their status, that you include as part of your “stack”.
As stated on the lucee download page that involves Lucee snapshots: “Snapshots are generated automatically with every push to the repository. Snapshots can be unstable are NOT recommended for production environments.”
Yes! I’ve seen that too somewhere. In fact, snapshots can have pure patch fixes. And with the ongoing work of the Lucee core team with the latest added enhaced testings (during builds), they are getting much better and more stable than before.