Access Environment Variables in a Dockerfile to Build a Front-End Container
In the previous lesson, Containerize the Front End of an Application with a Multi-Step Docker Build, we managed to put all of our front-end in a container and we can now distribute this container to the rest of our team. This will work well with stand-alone websites but as soon as you need to connect to an API, this could become an issue.
You will need to specify the base URL of your server and this would need to be done as an environment variable. The problem here is that since our application lives in a browser, it can’t read the environment variables from the server.
In the last lesson, you’ve seen that all requests were made to http://localhost:3000. This means that this value was hard-coded somewhere in the front end source code. The first thing you will want to do is to find out where this was coded and make sure that it is only defined in one place.
The fix here will be to create a bash script that updates the hardcoded localhost:3000 URL to a BASE_URL environment variable and update the instances that are used within the frontend app to your environment variable. This script will be called in the projects Dockerfile and override the original entry point.
Instructor: [0:00] The first thing you will want to do is to find out where this was coded, and make sure that it is only defined in one place. If you do a search for localhost:3000, you will see that it is only defined in one place. That's good. Half the work is done already. You will only need to modify the front/source/config.json file.
[0:23] This value works well in our local environment. Maybe other developers in our team are using different values. For this reason, you will leave the value hard-coded in here. You will only change it as part of the build process in the Dockerfile. To do so, you will use a Bash command called "sed." sed is a Linux utility that can be used to substitute some text in a file.
[0:49] Now, head back to your Dockerfile. Right after the copy statement here, let's change the working directory to /app/source. From here, we can run our sed command with the -i argument. We're going to specify what value we are going to change. In this case, we are looking for http://localhost:3000, and we will substitute this with $baseurl. All of this will be done in the file config.json.
[1:28] The result of this operation will be to actually change the config.json file to have a baseURL here on the server inside the container. This replacement works well when there's a single environment variable, like in this example. However, if you want a solution that is more future-proof, this will be introduced in the next lesson.
[1:48] Now that your configuration has been changed to a generic value, you can run your npm-install and build scripts. This will create all the minified CSS and JS files with the generic value. The next step will happen in the next step of our container.
[2:05] Just before the server starts, you will need to override this baseURL in your JavaScript package with the actual value of the baseURL environment variable. In order to do so, you will need to bypass the command that the NGINX base image uses to start the server with a different start script.
[2:24] This new script will use the envsubst command that is included with this image to substitute the baseURL string with the actual value of it from the image environment variable. Now, when you will start the container with a -e flag, it will take this value, overwrite the $baseurl string in our JavaScript file. Once this file is served to the browser, it will now contain the value from the environment variable.
[2:52] To do so, you will write a small Bash script. This file will be called "start_nginx.sh" and will be in the front folder. First, the script will run through all the app.something.js files and rename them to app.tmp.js. Then for each of these .tmp.js, we will use the envsubst to replace the environment variable $baseurl with the actual value from the container environment variable.
[3:34] The output from the envsubst command then pipes to the original file name. Once all the JavaScript files have been modified, you can start the NGINX server with the nginx -g command.
[3:50] The final step, as far as our container is concerned, will be to copy this Bash script into the container, change the permissions on it so that it can be executed, and change the entrypoint of your container. An entrypoint is a command that is executed when the container is ready. It's usually the command that starts your container.
[4:19] There can only be one entrypoint in a container, so by adding it here, you are overriding the default entrypoint that was defined in the NGINX base image. You are now ready to rebuild the front end image and start all three containers.
[4:34] To rebuild the front end, go to your front folder, and run the docker build command. You can now restart all of your containers to see those new changes. First, stop all the running containers. Then, start your database container from the db folder. Also, start your back end. This time, you can also start your back end on port 3001, as you did previously.
[5:04] Finally, start your front end server. This time, add the environment variable baseURL to point to localhost:3001. Now, open up your browser. Point it to localhost:8080 again. You should finally be able to try out the application. Everything is working again.
[5:24] If you change any of the server ports or URLs, you will be able to use an environment variable to specify the new values, and you won't need to change your code. Also, those values, such as the GIPHY API key, won't be in your repository and can be kept a secret on your server.
[5:42] You are now almost ready to deploy those images to a server. Before you do so, you will have to ensure these images run on any server. Right now, those containers are running as a root user inside their context. If you run a Bash shell and run the whoami command, you will see that you are running this session as a root user.
[6:08] You will need to do some small changes to your Docker files to ensure that you are not running as root anymore. This will be done in one of our next lessons.