How to set environment variables in Dockerfile via Azure DevOps

Question

In my projects Docker file I have some environment variables, like this:

ENV ACCEPT_EULA=Y
ENV SA_PASSWORD=Password
ENV MSSQL_PID=Developer
ENV MSSQL_TCP_PORT=1433 

And I would like to pass the password here as an environment variable set in my pipeline.

In Azure DevOps I have two pipelines. One for building the solution and one for building and pushing docker images to DockerHub. There are options to set variables in both these pipelines: I have set the password in both pipelines and edited my password in the Dockerfile to look like this:

ENV SA_PASSWORD=$(SA_PASSWORD)

But that does not seem to be working. What is the correct way of passing environment variables from Azure DevOps into a Docker image?

Also, is this a safe way of passing secrets? Is there any way someone could read secrets from a Docker image?

Thanks!

Answer 1

Also, is this a safe way of passing secrets? Is there any way someone could read secrets from a Docker image?

This questions really depends on the appproach and the importance of your image here. Usually there are 2 ways that somebody would look at to achieve this. Build arguments and Environment variables.

Build Arguments are usually declarted in the dockerfile, and are supplied using --build-arg parameter to the docker builder (docker build). Nothe that the docker build will complain if you declare an argument and not pass it during build if you also didnt supply a default value during declaration. These are available only when the image is being built. The subsequent containers from this image will not have access to the ARG variables, as long as you dont set them again using ENV.

ENV are environment varriables which can be declared and set from the dockerfile or at the os-level. The ENV variables are then available for use in subsequent instructions. These are available during the image build and all the subsequent containers from this specific image will have access to these variables. So if you ssh/exec into the container and take a look at which environment variables are set you will find them.

But that does not seem to be working. What is the correct way of passing environment variables from Azure DevOps into a Docker image?

buildAndPush command will ignore ARG by default in the task-inputs.. So either use a bash step to build the image or separate build and push tasks as described earlier.

Answer 2

I suggest to set the environment variables at runtime. If you are deploying to an Azure App Service, app settings are injected into the process as environment variables automatically.

You can then use the same image for multiple environments. With the Deploy Azure App Service task in a release pipeline, you can change the app settings for each environment.

https://learn.microsoft.com/en-us/azure/app-service/configure-custom-container?pivots=container-linux#configure-environment-variables

Answer 3

In release, choose deploy azure app service task. Provide required properties at App settings section under Application and Configuration Settings option.

Answer 4

You can set an ARG var_name and reference ENV to the ARG variables. Then you can replace those variables when docker build the image $ docker build --build-arg var_name=$(VARIABLE_NAME)

For example the add ARG in dockerfile, and have the ENV variable refer to it:

ARG SECRET
ENV ACCEPT_EULA=Y
ENV SA_PASSWORD=$SECRET
ENV MSSQL_PID=Developer
ENV MSSQL_TCP_PORT=1433 

You can use dock build task and dock push task separately, as buildandpush command cannot accept arguments. And set a variable SECRET in your pipeline.

The set the Build Arguments SECRET= $(SECRET) to replace the ARG SECRET

You can also refer to a similar thread.

Answer 5

I am using the Replace Tokens extension for exactly tasks like this: https://marketplace.visualstudio.com/items?itemName=qetza.replacetokens

However, putting secrets into your Dockerfile might not be the best idea. Usually you would provide secrets or generally runtime configuration as environment variables when you actually execute the container.