Docker image does not pick up env variables

Hi there,

I’ve got this most pressing issue where the script below runs on my Octopus cloud instance and deploys my app using an AWS tool called Copilot (it basically builds a docker image and pushes to AWS ECR/ECS). The issue I have is that even though my Dockerfile accepts all ARGs below, for whatever reason it is not able to “see” them. This script runs on a worker with pre-installed software.

What am I doing wrong? Any help is greatly appreciated as this is blocking our deployments at this stage.

export REACT_APP_API_KEY=$(get_octopusvariable "REACT_APP_API_KEY")
export REACT_APP_ENV=$(get_octopusvariable "REACT_APP_ENV")

ENV_NAME=$(get_octopusvariable "Octopus.Environment.Name")
DOCKER_TAG=$(get_octopusvariable "Octopus.Action.Package[xxx.web].PackageVersion")
INSTALL_DIR=$(get_octopusvariable "Octopus.Action.Package[xxx.web].ExtractedPath")

# make sure env name is lower case
ENV_NAME="$(tr [A-Z] [a-z] <<< "$ENV_NAME")"

pushd ${INSTALL_DIR}

copilot svc deploy -e ${ENV_NAME} -n ${SVC_NAME} --tag ${DOCKER_TAG} 2>&1 > /dev/null

# Check for error
if [[ $? -ne 0 ]]
    fail_step "AWS Copilot failed"

Hi Andre,
Thanks for contacting the team here at Support.

I think the best place to start is to get a copy of the logs for the deployment. Please send through the Raw Task log for now to see if there is any obvious errors showing.

If you have done some diagnosis already, let us know how far you got and if any error showed in the Docker or CoPilot implementation.

Looking forward to getting this resolved for you.

Kind Regards,

Hey there @paraic.oceallaigh there are no errors actually which is quite weird. The docker image gets built successfully. The build process builds a single page app and uses env variables to access process.env.STUFF. As these are not present, it fails to run the app in our live environments.

Is there a secure way to send you the logs, I think there will be some confidential info in there.

Hi Andre,
You can use this secure link:

As a follow up, if you add a -x to the bash script, does it print out the variables with the correct values?

Where else might the variables be passed that could be checked? It would good to see where exactly the vars are failing to be passed.

Kind Regards,

Yes, will test that now. What is even more mind-twisting is the fact that Copilot has a built in protection and it checks whether env variables are present or not. If I run the deploy command on my local env without setting env variables, this is what I get:

interpolate environment variables for app manifest: environment variable “REACT_APP_API_KEY” is not defined

Just uploaded the logs, @paraic.oceallaigh. Thank you!

Hi Andre,
I got the logs - thanks.
As you say they don’t show any errors or warnings of any use and to all intents, it was a successful deploy from Octopus’ point of view.

I will wait for your tests and see if anything comes from it. I wonder as well if the REACT API key is being mapped as type sensitive by Octopus and it may be encrypted or unusable. Trying to mark it as an ordinary variable might work better if you can allow that in your script.

Just a thought.

Kind Regards,

Hi Andre,
In passing I did see the GitHub issue here which might be relevant:

Might be worth checking into.

Kind Regards,

Hey @paraic.oceallaigh so I’ve tested it out and can see the value of my env variables being printed out to the octopus log:

This (in theory) tells me the those env variables are available in the shell environment which should be available to copilot which in turns build a docker image that contains my single page app.

The single page app is build by running npm run build. This automatically picks up env variables as per Adding Custom Environment Variables | Create React App

The problem is, it still does not work!

Do you guys have any examples of a build process that builds a single page app inside docker?

Hi Andre,
Thanks for trying the print env option.

Would you be able to confirm the other options to see if copilot is actually getting what it needs. The reason I ask is that the REACT API Key is printing out the masked value in your test. If you can can you test by trying to leave the KEY unmasked with the actual value and see if copilot picks it up?

Also can you confirm you have the latest co-pilot version which has the bug fix mentioned before i.e. > 1.12.0? The GH issue seems to a be close match for the error you are getting with co-pilot. Having said that, that error might be expected if you provide empty variables.

I asked our Solutions team and unfortunately they haven’t had direct experience with copilot or building a one-page npm app.

Let me know how you get on with those items and we can try to move it forward.

Kind Regards,

Hi Andre,
Looks like your last reply didn’t come through there, if you want to retry.

Kind Regards,

Yeah, it seems the email reply doesn’t really work, sorry.

Hey Paraic,

It is definitely getting what it needs otherwise it would error out the build as it’s got built in protection for unset variables.

The REACT API KEY was just an example, I use a bunch of other variables that are not being picked up by “npm run build” (those are plain text).

Yes, running the latest copilot version.

This seems to be a very obscure bug as I cannot reproduce it on my local environment.

Hi Andre,
Thanks for that confirmation.

Is there a way for you to remove Octopus from the pipeline and run it in docker directly, with setting the vars manually? Trying to narrow down where the process is flaking out.

Kind Regards,

This was how I had it working before. Github Actions was being used to do CI and CD. If I go back to it I can definitely deploy the app.

Hi Andre
Thanks for that update.
Is there a way to compare the local environment with the current environment. How different are they?

I can see that Octopus is not registering any errors and seems to be passing the vars correctly. Is there another part of pipeline worth checking?

I’ll have to see if there is another way forward.

Kind Regards,

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.