2

I'm wondering if it's possible to feed arguments, or environment variables into a Dockerfile used by AppEngine (flex environment).

I'd like to use this command:

COPY ${STAGE}/keycloak-files/realm-config/* /opt/jboss/keycloak/realm-config/

"STAGE" variable would allow to select the origin (I have a "staging" and "production" directory, containing different configurations).

I've got two different app.yml files, one for each environment, but from what I read online, environment variables are not exposed to the Dockerfile at build time.

People suggest to pass arguments to accomplish the task. But how would that be possible with appengine, where we don't execute the docker build command directly?

funder7
  • 1,622
  • 17
  • 30
  • Would using a predefined Docker image do the trick? It occurs to me that maybe you can build your Docker and use the gcloud app deploy image-url flag: https://cloud.google.com/sdk/gcloud/reference/app/deploy#--image-url – DamPlz Jun 28 '21 at 07:43
  • Yes I saw that option... I don't know if it's the best solution, I'm doing operations in the Dockerfile which are related to the target environment (see example code). Temporarily I duplicated the project into a "staging" and "production" folders, each one with it's Dockerfile and app.yml. Not elegant at all, but seems ok for the moment. What advantages would I have by using the "image-url" flag instead of this? – funder7 Jun 29 '21 at 12:27
  • 1
    Reading an (old) related SO post, I saw that building docker container locally, push it to gcr.io, and then using the --image-url flag, could be a possible workaround. Not sure if it would provide any advantage in your case. The post: https://stackoverflow.com/questions/33913525/docker-arg-command-building-google-managed-vm – DamPlz Jun 30 '21 at 10:08
  • That would be a possible option, there's a difference though, if you build an image locally, I'm not sure if the build happens in your local environment, and then it's pushed to gcr.io, or it's built there. With a regular Dockerfile + app.yaml deploy, it's faster, as you don't need to upload any file. At least, I think you don't :-) – funder7 Jul 01 '21 at 11:59
  • @DamPlz I've just completed a deployment, and read the output, it looks like there's no difference between the "normal" deployment and specifying a docker image. Btw having different folders for staging and prod environment is not so bad, as they are aligned with your servers. At the moment it's a good solution for me. Thanks! – funder7 Jul 01 '21 at 17:57
  • Cool! I'm happy to read you have found a good solution. I was interested in this topic because I think the fact to pass env variables from the app.yaml to the Dockerfile during the deployment phase would be a really interesting feature. Since apparently there is not a straight way to achieve it (I found that there is a public feature request (https://issuetracker.google.com/139688475) from two years ago.), maybe it would be worth sharing your solution in the form of an answer, to help the community in similar situations. Regards! – DamPlz Jul 02 '21 at 08:01
  • I created a feature request for this here: https://issuetracker.google.com/issues/286782972. Please upvote it. Thanks! – Matt Johnson-Pint Jun 12 '23 at 17:16

1 Answers1

2

As @DamPlz said there is not a straight way to pass env variables from the app.yaml to the Dockerfile during the deployment phase . Here are some workarounds that I could think of:

  1. One option could be to create the variable in the Dockerfile directly and if you want to change it each time at runtime you can use a placeholder value and have a script update the value of the variable before running “gcloud app deploy”.
  2. On the other hand you could use build triggers in Google Cloud Registry to modify it in the Docker image using user-defined substitutions.
drauedo
  • 641
  • 4
  • 17