Build, Release and Run Containers with Docker Compose

Instructor: [00:00] Once you have written the Docker file, you can create an executable bundle of your app with the docker build command. This will pull in your app dependencies, and compile binaries and assets into a process that can later be ran as a tagged release.

[00:14] Type docker build, then a -t. What follows is the repo name for the build, which is typically the vendor name, followed by a slash, then the app name. That said, it can also be an arbitrary value. After the repo name is a colon, followed by the tag reversion number.

[00:31] If you leave this part out, it will default this latest, but this is rarely desired in a production build. You want to tag every release with a specific, unique version number. Here, we will use the tag 1.0Then you want a space, followed by the directory you want to build from. We will use a period to specify the current directory.

[00:51] It may take a few moments to run the build process, depending on the size of your base image, install time of dependencies, and asset size and number files being copied to the bundle. After the bundle has been built, we will use docker compose to run our build.

[01:06] Create a file named docker-compose.yaml. This will contain your release configuration. Here's a simple config for our Node.js app. The most important takeaway here is the image property, which should reference the specific tag of the image we just built.

[01:23] This config file, when combined with our tag build, creates our release. Note that we can also define other aspects relating to this release in our config file, such as setting environment variables. After saving this file, we should use version control to commit this release.

[01:40] Before committing, ensure you have both .dockerignore and .gitignore that are set to ignore the .env file in the Node modules directory. Let's add all the files to Git, then commit the release.

[02:02] After committing, we should tag our release with git tag, and use an incrementing version number, in this case, v1.00To run this release for production, we first check out the tag with git checkout v 1.00We create or modify the .env file to our liking on production.

[02:23] This file should not be committed to version control, as it often contains security credentials to third party services. Let's then kick off the production release by running it with docker-compose -d app. This will pull down any Docker images that don't exist on the machine, apply the compose configuration, and start your containers in daemon mode.

[02:45] We can confirm the containers are running by typing docker ps, and follow the log output by running docker logs -f foo_app_1. Upon opening a web browser to the URL localhost:8080, we can see our cat friend Herman.

[03:05] If you desire, you can further optimize the tag, checkout, and production deploy process by creating custom Bash scripts to further automate the process of releasing your software.