Mini talk - Access Environment Variables in a Dockerfile to Build a Front-End Container

Joel Lord
InstructorJoel Lord
Share this video with your friends

Social Share Links

Send Tweet

Introduction for the lesson on using environment variables in a front-end container

Instructor: [0:01] In the previous lessons, we managed to put all of our frontend in a container, and we can now distribute this container to the rest of our team. This will work well in a standalone website. As soon as you need to connect to an API, this could become an issue, since the URL that you used in development will most likely differ from the one in production.

[0:21] In order for your code to still work in production, you will need to specify the base URL of your API. As you've seen in a previous lesson, this can be done by using an environment variable. Since the value of the base URL changes between the environment that you're in, it would be the best way to set this.

[0:40] There is a problem when you want to use environment variables in your frontend. When you use an environment variable in the front or backend, it works because the Node.js server is able to access the value from the operating system.

[0:54] In the case of your frontend, it lives in the browser of your end users. When the user goes to the website, it downloads the HTML, JS, and CSS and runs them inside the user's browser. That code is now unable to communicate with the server's operating system to have access to those environment variables.

[1:15] There are a few techniques that are often used to go around this. You could switch your backend server to a Node.js and create a route that will provide all the configuration, which would be accessible by your frontend. This requires us to change our base image from Nginx to Node.js, and to create a web server, and to change a bit of the logic of our application.

[1:36] You could also use something like PHP or another server-side rendered language to change the HTML content before it get served. Once again, this requires a lot of changes in the way our application is built.

[1:49] Thankfully, there is another way to do everything through a Dockerfile. We're already using Docker to initiate our build process. By adding a few comments, we can change those variables to something more generic in our build process.

[2:05] Then, before our server starts, we can inject the environment variables into our configuration. This way, we don't need to change anything in our development environment, and we can keep our Nginx server for high-performance and small footprint.

[2:22] To do so, you'll need to put all your configuration into a single config.json file to make it easier to override those settings. Next, you can use a bash script to override them as part of the Docker build step.

[2:35] Finally, you can use msubs to override the environment variables with the actual values just before the server starts. If the environment variable changes and the container is restarted, it will take into those new values and send those to the end user.

[2:52] In the next lesson, you will see how to do this in a somewhat naive approach. It will look for hard-coded value, such as localhost port 3000, and simply override them by using, send, a Linux CLI tool to edit some text in a file.

[3:07] The new value of that JSON property will be the name of the environment variable, in this case, dollar sign base URL. This will let you use the msubs on the file to change the name of the variable into the actual value of that variable.

[3:24] This will work perfectly well in the context of this application, and can work for you, if you have a single value that needs to be stored in an environment variable.

[3:32] The lesson after that will show you how to use jq, another CLI tool to change the values inside the JSON file. This time you won't rely on a hard-coded value, but rather on the property of the JSON object.

[3:46] This will make for more future proof container, but requires more work and some bash scripting. Feel free to skip that lesson, if you don't want to dig deeper into this topic. If you want to build future proof containers and frontend containers that can access environment variables, you should probably look into it.