Hello @vinicius.deschamps,
Thank you for providing me with that information.
Application containerization is focused around the concept of immutable infrastructure. Specifically, this involves the application code being baked into the container image, but environment-specific configuration settings (such as appsettings) are injected into the container at run time. This makes the container image re-usable across your environments, rather than having to build an image-per-environment.
For .NET applications to adhere to this concept, they typically need to be configured to reference environment variables over performing traditional config transforms and then using those resulting files for the source of configuration settings.
There are then a few ways to map Octopus project variables to these environment variables for containers to use at runtime.
The simplest way, in my opinion, if you don’t have a lot of variables is to map each one using the Environment Variables section of the Add Container section of the Deploy Kubernetes Container step template.
In my example, I have three project variables (DefaultConnection, EnvironmentName, AppVersion) and have mapped each one to an environment variable for the container to use.
In that section of the step, you can also map environment variables from a Kubernetes ConfigMap and a Secret resource. You can either create these resources within the same step to reference or have separate steps that run before creating them.
Using these other Kubernetes resources can be beneficial when working with many project variables that need to be mapped to environment variables. You can script looping through each variable to create the resources instead of manually referencing each one or store the entire configuration to be replaced.
We have a few resources explaining in further detail how you can accomplish this:
I hope that this helps. Please feel free to let me know if anything needs further clarification or you have any other questions.
Best regards,
Mark Butler