In the official Docker image, is there a way to specify a different

server.json

file when starting the server? Looking at the repo, it seems to me like

server.json

is hard-coded in

run.sh

(line 90). My repo has two separate server.json files to support launching in two different modes (front end vs. admin). I have two separate DockerFiles to create containers in the different modes. I've tried various things in the DockerFiles but none of them seem to work:

COPY server-frontend.json /app/server.json

RUN box config set server.singleServerMode=false
RUN box server set serverConfigFile=server-frontend.json

ENV BOX_SERVER_SERVERCONFIGFILE="server-frontend.json"

Have you considered just building 2 different images of your own based on the official image?

Yes, I am actually doing that. I have two separate Dockerfiles - one for each mode. But I'm still not sure what to do to get them to use the correct

server-[mode].json

file.

If each Docker image is different why not just give it 2 different server.json files from 2 different code bases?

Having to maintain two separate code bases where 99.999% of the files are the same, except for server.json? That seems heavy handed. Also, when I run locally I am mounting my approot in into the containers, so both containers use the same root, which is what I want.

No you are right, I wasnt thinking of it that way.

Maybe in my Dockerfile I can copy in my own custom

<https://github.com/Ortus-Solutions/docker-commandbox/tree/development/build|build>/<https://github.com/Ortus-Solutions/docker-commandbox/tree/development/build/util|util>/start-server.sh

which adds the argument to

box server start

to specify the correct file?

We both are probably missing something here; @bdw429s is going to have the answer, unless @jclausen has the answer

Yup, appreciate the help anyways 🙂

COPY

is from the host machine to the image. The order in which you copy matters, because a subsequent copy of a directory can overwrite the previous one.

So, what I'm trying to achieve long term here is the ability to run the apps locally with commandbox (using the different server-[mode].json) files, and then deploy to Docker containers with a minimum of duplication of settings. i.e. putting all the environment stuff in both the Dockerfiles and the server.json files. Does that make sense?

I think ideally if I could just do

ENV BOX_SERVER_SERVERCONFIGFILE=server-frontend.json

in the Dockerfile that would be perfect

Totally, though if your front end application doesn’t need all of the dependencies of your back end application, a modular build ( e.g. including only what you need ) on two separate images, might be more efficient.

they both are quite intertwined - it's really one app with two modes. They share tons of the model and service layer

Got it. I will address the above issue on the next release. For now, I might just suggest modifying the

CMD

of the container to handle an environment variable:

CMD mv $APP_DIR/server-${APPLICATION_MODE:-backend}.json $APP_DIR/server.json && $BUILD_DIR/run.sh

So using that method I would just need an

ENV APPLICATION_MODE=frontend

earlier in the Dockerfile?

Exactly.

And yeah, I have Undertow predicates set up to block the server.json files...

If you really want to maintain portability, then there’s no need for handling the mode separation in the Dockerfile.

I think I get it. I could use the same Dockerfile for both modes.

Exactly. Good call on the undertow settings. I just looked and

blockSensitivePaths

doesn’t handle custom

server-*.json

names: https://commandbox.ortusbooks.com/embedded-server/configuring-your-server/server-rules/baked-in-rules#block-sensitive-paths

I almost suggested the application_mode concept heh

So, the CMD code you sent me above, that would be in addition to or would it replace this line:

RUN ${BUILD_DIR}/util/warmup-server.sh

CMD

is the command that is run when the container starts.

OK. You are exposing my noob-ness here. Ha. I'm learning though. I think.

No problem at all! All n00bs are welcome! 🙂

So that CMD line does go into the Dockerfile. But where? Before the RUN or after? Does it matter?

As the last line preferably.

OK. Giving that a shot! Thank you.

No problem. Any time. 🙂

This is working, for the most part 🙂 a complication is that I'm launching both containers locally via a

docker-compose.yml

file and mounting my app directory into both containers. So when they both launch simultaneously, stuff in the app root gets rewritten / moved / etc causing some race condition issues. If I launch each container separately everything works correctly. I just end up with an extra

server.json

in my root based on whichever the last launch was. And I had to change

mv

to

cp

Yes, that’s going to be a bit of an issue in development using compose and mounts, because you are going to have extra files created in your local.

@seandaniels I know this is an old thread, but it was just pointed out to me. I'm not sure why I didn't see it back in January, but to address a couple things in it.

RUN box server set serverConfigFile=server-frontend.json

ENV BOX_SERVER_SERVERCONFIGFILE="server-frontend.json"

☝️ Neither of those do anything. The first one sets a key in

server.json

that isn't valid or used. The second sets an env var which overrides the same non-existent key in your

server.json

. The valid things you can set in a

server.json

are listed here: https://commandbox.ortusbooks.com/embedded-server/server.json and you'll notice

serverConfigFile

isn't one of them. That is a param to the

server start

command, but it's not a value in your server.json and for obvious reasons. You can't have the server.json file tell CommandBox where to find itself! That's a catch-22!