While preparing a workshop showcasing the power of OpenShift on Azure (ARO) to .NET Core-focused developers, we strived to align to the methodology of 12-Factor Applications. Specifically, rule number three – Configuration.
Since an application is likely to vary between deployments (i.e.: developer environments, staging, production, QA, etc.), its configurations could be stored as constants in the codebase. Sound the alarm bells, this is a clear violation of the strict separation of configuration from code.
Our goal was to take a standard three-tier application containing a React / Redux front-end, .NET Core Web API as middleware, and a data-tier supported by MongoDB and guide a developer through deploying it to OpenShift. During deployment of the front-end, we wished to pull configuration data (such as API URLs, or ClientIDs from an OAuth provider) from within the OpenShift project. Our team was accustomed to pulling these configurations from environment variables within the codebase, but had yet to do so from a container running an Nginx server hosting a JavasScript front-end site.
Following existing patterns involving the use of Dockerfiles and various build configurations, we kept running into walls with the bash script pattern. The issue was that those patterns did not consider that OpenShift Pods are inherently immutable and there was no viable method for adding or updating configurations on the Pods during or after deployment. This immutability stems from the importance of ensuring security and Pod startup performance.
Application modernization is a growing area of focus for enterprises. If you’re considering this path to cloud adoption, this guide explores considerations for the best approach – cloud native or legacy migration – and more.
Then we click “Add to Application”
And add the mount path of our Nginx client-side application and select our application
Then update our app entry point, in this case index.html with a link to the file