Project Reasoning

This project is a follow on of the goals tracking application which was sent up in a multi-container environment. As it stood, the main downside of the previous project was the amount of commands that were required to spin up and down the containers. Previous knowledge would have led me to use a “MakeFile” to condense the commands down into short hand names. However, a more efficient way is to use Docker compose, which is what this project was all about.

GitHub Project Repository

Project Introduction

As mentioned in the project reasoning, this project was based upon the goals tracker application which was my main hands on entry point into Docker. Rather than trying to dismantle that current project, I simply migrated an existing instance of the application prior to the multi-container set up.

YAML & Docker Compose

The project began by creating a new “docker-compose.yaml” file. This involved first specifying the version of Docker which would be suitable for the configurations in use. The next element of the YAML file is services, which relates to everything that is intended to be set up and takes nested arguments. In this case, that the containers and their attributes. I began with the Mondo DB container and assigned it a name, as well as defining the image (used the existing Mongo Image) and internal volume location. Similarly to the previous project, I wanted to add an element of security to the database. To do this I created a separate “mongo.env” file with the database credentials and referenced the location within the docker compose file.

Back-end

The next container to set up was the back-end. For this, a custom image was required in order to create the environment. Docker composes “build” option allowing me to reference the Docker file to create the image. The ports also needed to be defined according to the “app.js” server file (port 80). Similarly to the previous project, volumes needed to be set up to ensure data remains persistent. Volumes were set up for the server’s logs as well as the bind mount to the local directory using a relative path. Node modules were also added within the container to ensure they are not over written by the local version of node. Environment variables were created in a separate file containing which were used to authenticate access to the database. The location of this file was referenced within the compose file under the syntax name “enf_file”. To ensure this backend container does not run ahead of the MongoDB container, a “depends_on” key was used to avoid any potential errors.

Front-end

The final container to set up was the front-end. The built tag was used once again, with the point set to the frontend directory on my local set up. The ports published for this application were “3002” (as 3000 & 3001 were being used for other applications). A relative bind mount was set up so that any change reflected on the local directory were also reflected within the container. The react frontend must be run in interactive mode, however unlike docker run which used the “-it” command, docker compose uses “stdin_open: true & tty: true”. Finally, the “depends_on” tag was also used to ensure the backend container runs before the frontend.

Summary

This project was incredibly insightful, and allowed me to demonstrate my understanding of Docker further using Compose. Being able to control and deploy containers from a single YAML script, which is useful for the efficiency of multi-container applications.

Tags: There's No Tags