Different Docker Tutorial

Unit 5 Chapter 2: Minimal Stage 1 Docker Image

In this chapter, you will learn how the Minimal Stage 1 Docker image is built.

Topics Covered

  • Repository
  • gitlab-ci.yml File
  • variables.sh Script
  • build.sh Script
  • Dockerfile
  • usr_local_bin Directory
  • Building the Docker Image Locally

Repository

gitlab-ci.yml File

  • The GitLab CI file treats the build process as a long test. Note that most of the Bash scripts used in the build process contain the command "set -e". This means that if an error is encountered, the script terminates with an error. If a step fails, the entire build process fails. This ensures that a good Docker image in the GitLab repository does not get replaced with a defective one.
  • Note that the GitLab CI file is the same for all Docker image build repositories.
  • The first step of the initial test setup process is logging into GitLab. This is necessary for pushing Docker images to the GitLab Docker image repository. If the appropriate username (REPO_USERNAME) and password (REPO_PASSWORD) are not set in the repository's environment variables, the build process fails here. Logging in is the first step, because it's better for the test to fail now than fail later, as this prompts corrective action sooner.
  • The Docker image used by the GitLab CI environment is based on Alpine Linux. Note that the package list is updated, and Bash is installed.
  • The last step in the before_script process is executing the build.sh script.
  • The "test_master" process is used under the master branch, and the "test_other" process is used under any other branch. Both run a script for testing the Docker image, which runs the sanity check script. (This will be explained in more detail later in this chapter.) The difference between the "test_master" and "test_other" processes is that the former pushes the new Docker image to the GitLab repository. Remember that if any of the previous steps fail, the push action never happens.

variables.sh Script

  • This script is used in the GitLab CI process AND in the build.sh script.
  • The variables.sh script sets the values of the required environment variables. The "export" commands used makes these variables more global. The names of the Docker image and associated Docker container are set just once in the repository.
  • The values that the environment variables are assigned are different in each Docker image build repository.

build.sh Script

  • This script uses the Dockerfile to build the Docker image.
  • Note that the local build.sh script actually calls an external build-image.sh script, which is used for building other Docker images as well. This is the DRY principle at work.

Dockerfile

  • The Dockerfile contains the instructions and parameters used for building Docker images.
  • The "FROM" parameter specifies the Docker image to use as the basis for building the new Docker image. In this Docker build repository, the official Debian Buster Docker image is used.
  • In this and all other Docker build repositories for the Ruby on Racetracks way, the scripts in the usr_local_bin directory are copied to the /usr/local/bin directory in the Docker image and made executable. These scripts transform the parent Docker image into the new one.
  • In this and all other Docker build repositories for the Ruby on Racetracks way, one of the usr_local_bin scripts is explicitly called in the Dockerfile. That script calls the other scripts provided during the build process.
  • Note that the "RUN" step is executed as root, because the parent Docker image does not have a regular user.
  • Note that the "USER" parameter is "winner". After this Docker image is built, one enters it as the regular user "winner" by default.

usr_local_bin Directory

  • The scripts in the usr_local_bin directory are used for transforming the parent Docker image into the new one.
  • Note that these scripts can also be used for building Vagrant boxes. (This is the DRY principle at work.)
  • The min-stage1-root script executes the root actions needed to build the new Docker image. These include updating apt-get (through the aptget script), adding the regular user "winner", giving this user sudo privileges, and installing the Nano editor.
  • The min-stage1-root script also calls the min-stage1-user script, the /usr/local/bin/finalize-root script, the /usr/local/bin/finalize-user script, and the /usr/local/bin/check script.
  • The /usr/local/bin/finalize-root script cleans up the Docker image to make it smaller. (This speeds up the processes of uploading and downloading it.)
  • The /usr/local/bin/finalize-user script adds the build date to the timestamp.txt file in the Docker image. This lets the user know how old the Docker image is.
  • The min-stage1-user script executes the user (non-root) actions needed to build the new Docker image. These actions consist of filling in the user's .bashrc file. Every time a user logs into a Docker container based on the Docker image, the date is added to the timestamp.txt file. At the same time, the contents of the timestamp.txt file are displayed every time the user logs into the Docker container. This indicates whether or not the Docker container is in its original pristine state.
  • The min-stage1-check script (which is called by the /usr/local/bin/check script) displays basic information about the Docker image and which versions of selected software are installed. This is a sanity check.
  • Note that the /usr/local/bin/check script is executed twice during GitLab CI's Docker build process. In the "test_other" process, the second time is at the very end. In the "test_master" process, the second time is the last action before pushing the Docker image.
  • The /usr/local/bin/check script is executed when you run the info.sh script in the shared directory of Docker containers.

Building the Docker Image Locally

  • Enter the following commands:
cd
cd rubyonracetracks
git clone https://gitlab.com/rubyonracetracks/docker-debian-buster-min-stage1.git
cd docker-debian-buster-min-stage1
bash build.sh
  • The screen output is automatically logged. The log files are in the log directory.
  • In a moment, the build process will be finished.
← Chapter 1: Build ProceduresChapter 3: Minimal Stage 2 Docker Image →