<p>I have a front-end (React) application. I want to build it and deploy to 3 environments - dev, test and production. As every front-end app it needs to call some APIs. API addresses will vary between the environments. So they should be stored as environment variables.</p>

<p>I utilize S2I Openshift build strategy to create the image. The image should be built and kind of sealed for changes, then before deployment to each particular environment the variables should be injected.</p>

<p>So I believe the proper solution is to have chained, two-stage build. First one S2I which compiles sources and puts it into Nginx/Apache/other container, and second which takes the result of the first, adds environment variables and produces final images, which is going to be deployed to dev, test and production.</p>

<p>Is it correct approach or maybe simpler solution exists?</p>

Arkadiusz Kałkus
<p>I would not bake your environmental information into your runtime container image. One of the major benefits of containerization is to use the <strong>same</strong> runtime image in all of your environments. Generating a different image for each environment would increase the chance that your production deployments behave differently that those you tested in your lower environments.</p>

<p>For non-sensitive information the typical approach for parameterizing your runtime image is to use one or more of:</p>

<ul>
<li><a href="https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/" rel="nofollow noreferrer">ConfigMaps</a></li>
<li><a href="https://docs.openshift.com/container-platform/4.2/nodes/pods/nodes-pods-secrets.html#nodes-pods-secrets-about_nodes-pods-secrets" rel="nofollow noreferrer">Secrets</a></li>
<li><a href="https://kubernetes.io/docs/tasks/inject-data-application/define-environment-variable-container/" rel="nofollow noreferrer">Pod Environment Variables</a></li>
</ul>

<p>For sensitive information the typical approach is to use:</p>

<ul>
<li><a href="https://docs.openshift.com/container-platform/4.2/nodes/pods/nodes-pods-secrets.html#nodes-pods-secrets-about_nodes-pods-secrets" rel="nofollow noreferrer">Secrets (which are not very secret as anyone with root accesss to the hosts or cluster-admin in the cluster rbac can read them)</a></li>
<li>A vault solution like Hashicorp Vault or Cyberark</li>
<li>A custom solution you develop in-house that meets your security needs</li>
</ul>
