1
votes

I currently have a build pipeline in Azure DevOps that builds a docker image with an Angular web app and pushes it to an Azure Container Registry. I also have a release pipeline that deploys that docker image to an Azure App Service for my DEV environment. The environment variables for DEV are currently hard-coded in the config file.

I want to set up the release pipeline so that it can deploy to DEV, TST and PRD environments using the same image. For an on-prem app, I would normally just take the config file from with tokenized variables from the build artifact and use an ADO release task to replace the tokens with the environment specific variables. I don't think I can do that here since the config file now gets baked in with the Docker image during the build pipeline. Any ideas on how this is usually handled?

2
Hi, how the things going now? Which answer could help you achieve what you want? Just considering accept one answer thus other SO users will be able to see whether the solution works. If you are still facing some issues please leave a comment so we can still help you .Merlin Liang - MSFT

2 Answers

2
votes

One of the cool features that App Service has when hosting Windows Containers is that the App Settings and Connection Strings defined in App Service will be injected into the Windows Container automagically.

Additionally, we support specifying KeyVault references, so the AppSetting in App Service can point to a KeyVault and the platform will take care of pulling the secret from the KeyVault before starting the container and then it will be injected.

If you are using ASP.NET, the App Settings and ConnectionStrings will be populated in the System.Configuration.ConfigurationManager

For more info: https://docs.microsoft.com/en-us/azure/app-service/app-service-web-get-started-windows-container

0
votes

For this issue, yes, the config file which be packed into the docker image could not be modified. As work around, we often create multiple config files then pack them into one image. During the deploy, its logic is select the corresponding config file according to the different deployment environments.

If you don't want to create multiple config files, another work around is run parallel build jobs which has different configuration variable passed in. Then these parallel builds can generated several different images. Then put them in one folder, and during the deploy, select the corresponding image which according to different environment. This method only need one config file. But its disadvantages is, if the image is very huge, it would take more space and time to store these image.