@Jim Priest any reason to need a full heavy docker local setup/builds when commandbox can be running on a mac m1 in 2 minutes?

We have a very complicated Docker based development environment consisting of many containers, etc. Can't just spin up a vanilla image unfortunately.

Ahh that dockerfile only came off as 1 container plain jane CF2021

Yeah it's just a simple example for the issue I'm running into

All your other docker containers can run locally and your commandbox instance can easily interact with it as expected whether its DB containers etc

Yeah - some wires are getting crossed somewhere LOL I'm hoping @jclausen can take a peek and let me know what I'm doing wrong

is that directory

/jim

sitting in same folder as your Dockerfile

It's set in my docker compose file... and yes it's just one dir with my index.cfm, dockerfile and docker compose file

volumes:
      - type: bind
        source: ${PWD}
        target: /jim
        consistency: consistent

Shouldnt your target be just / since its the root that has all of your files (index.cfm etc?)

No - within the container it's either /app or /jim Looking at Adobe's Docker images they also use /app without giving you the opportunity to change it (sigh). I can maybe make /app work just going to have to rewrite a lot of scripts that point to our existing webroot dir...

I have always left it as /app any reason to need to change it within the container?

If you are using a multistage build, then the app directory is already defined. There are always two variables in play with a server start CFML file locations: •

APP_DIR

- The place from which the

run.sh

executes ( in the case of a finalized startup though, that finalized script executes and

APP_DIR

is what it was in the first stage •

BOX_SERVER_WEB_WEBROOT

- This is the location from which traffic is served - also in a finalized startup it is set when the script is created - it cannot be changed after that.

Ah ha - I missed BOX_SERVER_WEB_WEBROOT!!! Thanks @jclausen for the clarification on the differences. Does that need to be added here maybe? https://github.com/Ortus-Solutions/docker-commandbox I can open a PR and add that.

No. It defaults to the current directory where the server is started, if not specified. Which, for most users of that container is

/app

Think this may be my core issue. https://stackoverflow.com/questions/71247957/docker-compose-with-commandbox-cannot-change-web-root Symlink to /app seems to work fine with my test containers - will add that to my main build this afternoon and see.

If the production server is linux, it’s helpful that staging an dev environments are also linux. So much effort is expended on making mac and windows docker environments work like docker. Running a Linux VM on your OS is where I’m ending up, which in turn runs docker, and anything that it might need. This has turned out to smooth out a lot of issues and bugs. Easy to start up in a vm for developers as well. Docker seems easier to not use in the start until there’s updates to roll out. :)

Docker seems easier to not use in the start until there’s updates to roll out. 🙂

I would disagree wholeheartedly - especially having worked with all manner and of flavors of Virtualized development enviornments. When working with developers using multiple OS’ ( e.g. your UI team uses Mac, Your back-end team uses multiple flavors ) I have found docker makes it so much easier to provide a consistent development environment. It also makes it easy to stand up that environment for a new developer in a matter of minutes. When you run a Linux container locally You are running your app in Linux. The only disconnect is when you mount in file systems which are case-insensitive, which would run as case-sensitive in Linux. Some care and consideration in the development environment smooths those casing issue out.