http://coldfusion.com logo
Join Slack
Powered by
Hello All... How do you folks generally handle Doc...
# docker-commandbox
c
Hello All... How do you folks generally handle Docker builds for different environments.. In my particular case, when I run the docker build, I only want to 
box install commandbox-fusionreactor
in production.. Interested to hear your approach. Thanks in advance..
p
Don't know your usecase but....... docker is meant to be the same everywhere, Kinda defeats the purpose building the image and then testing but not using in prod then buildign a diffent images for prod.?
c
Hey Paul! My use case I only want to run a bash command during the build of an image used in prod.. the same image is used everywhere, bar this one command.. I'm sensing the Dockerfile is not the place for conditionals
the bash command installs the APM (fusionreactor)
d
I use bash in the dockerfile - my dockerfile builds a commandbox image with the version of ACF I want. Something like
Copy code
# Only add modules for cf >= 2021
RUN if [ "$engine" != "2018" ]; then box cfpm install caching,document,pdf,image,mail,mysql,scheduler,spreadsheet,zip,redissessionstorage; fi
the various versions become the base image used in our application build / test / deploy CI/CD workflow
b
I would put it in the base image and only activate the license in production
👍 1
It's not really going to hurt anything having it there but disabled.
And it will simplify your process
@dougcain Note, the cfpm command in CommandBox is now smart enough to just ignore any non-Adobe servers so it's safe to just always run that if you have a multi-engine setup and it will just be a no-op with a console warning if there is no Adobe engine
👍 1
c
@bdw429s Do you have separate server.json for each environment? If so, how do you determine which file to use at build time?
b
@chapmandu Depends on the project, but I prefer not to if I don't need it
For instance if I have 20 settings in my server.json and only 2 of them are different between dev and prod, I'd rather have 
${}
placeholders in there, or use 
box_server_setting_here
env vars in prod to override
c
My main aim to is to disable FR for all environments except production..
b
well, like I said, that's as simple as just not putting in the license key anywhere but prod
A simple
Copy code
box_server_fusionreactor_licenseKey=xxxxx
env var will do that
Or
Copy code
{
  "fusionreactor": {
    "licenseKey": "${FR_KEY}"
  }
}
and just set 
FR_KEY
as an env var (defaults to empty string if it doesn't exist)
c
ok, thats pretty slick.. I'll check it out. Thank you!
b
There's also an 
fusionreactor.enable
flag too if you really want it 100% gone
Any server.json value can be overridde/set via an env var using a naming convention-- even non-core ones like fusionreator settings https://commandbox.ortusbooks.com/embedded-server/configuring-your-server/env-var-overrides
c
Can I ask how you know when you're in the prod env? I currently have this in my server.json.. but my challenge is where to set FUSIONREACTOR_ENABLE=false
Copy code
"fusionreactor": {
    "enable": "${FUSIONREACTOR_ENABLE:true}"
}
b
That's a concern of your orchestrator
The server itself doesn't necessarily need to know or care.
In my production docker stack, I'd set the env var
In stage, or dev, I wouldn't
simples
For most our Ortus projects, it's just naked CommandBox on dev, and docker for stage/prod. So locally, we use an 
.env
file to simulate the env vars which come from our docker stack and/or docker secrets on stage/prod.
Also, in your example, you're defaulting to enabled, and making disabled be the exception. Seems like you'd want to reverse that and have disabled be the default and enabling it be the exception
👍 1
c
We have something similar.. we use AWS Codebuild.. we have an STAGE env var with either a "stg" or "prod" value.. im wrestling with the correct way to disable FR in the Dockerfile when $STAGE==prod (IF the Dockerfile is the right way to do it...
b
Can you not simply set the env var in the environments where you want it enabled and not set anything in the environments where you want it disabled
Stop thinking about if statements, and just set the darn env var when you want it on!
we have an STAGE env var with either a "stg" or "prod" value
☝️ This is also the most confusing thing I've ever heard, lol
c
Haha.. yes, thats the ideal... I'll have to go through our ops ppl to have it added to the buildspec.. I was hoping to be able to manage it myself
b
You may as well have an env var called 
this_is_production
and set it to 
lol_JK
on dev 😁
c
i agree... long story..
b
I can't imagine it being difficult to just set an env var that exists for your production deploys. Surely it would take less time to do this than I've spent typing that you should do it
c
one would think so...
b
We use docker compose files in our stack, so it's just a line in a yaml file...
env vars are sort of what makes the world go 'round in cloud deploys these days, so they need to be easy to setup and modify as your needs change
💯 1
c
Thanks for your perspective Brad.. I know now how to improve our build process...
👍 1
Full disclosure..
we have an STAGE env var with either a "stg" or "prod" value
not exactly... DEPLOY_STAGE = [ci | staging | uat | production]
b
In ColdBox land, we call that env var 
environment
And ColdBox MVC and CommandBox CLI both have some built in conventions that check for that to default other stuff.
c
Hmm.. I'll look into renaming it.. it's YEARS old...
2 Views
Open in Slack
PreviousNext
Powered by