Basics of Docker

Docker

In the world of DevOps, moving fast while keeping code quality high is paramount. Traditionally, many organizations subscribed to the monolithic approach where all components were tightly-coupled and loads of dependencies exist within. Due to this tight integration, tons of tests had to be performed, teams had to be involved, and more. It could take months before a single change deploys to production. To move fast but stay efficient, we need a better way.

One way to speed up development time is to break up that monolithic application and rely more on a distributed model using microservices. Under a microservices architecture, each component of software is a standalone component down to the operating system. Containers are a technology that greatly assists in microservices and DevOps.

Although containers have been around for many years, they have been traditionally hard to use until a company called Docker came around. Docker humanized container management and provided an easier way to work with containers.

Docker, for DevOps purposes, is a tool that encapsulates a microservice or any application for that matter and bundles it up with all infrastructure dependencies. This Docker application “package” exists in a container.

Using Docker, a DevOps pro can quickly create and deploy an entire application and operating system dependencies and remove the “It works on my machine” comment. From the time a container starts, runs the code, gets tested, and gets deleted, it could easily be minutes. Think of how efficient your software delivery process could be with such a great amount of time saved!

There are three major components that make up Docker you need to understand: the Docker Engine, Docker Images, and Dockerfiles. Let’s first cover the main components and then dig into the project for this chapter.

Docker images

A Docker image is a pre-created set of files that define the environment that the application will be running in. Think of a Docker image as an operating system image with a set of instructions for running an application. The Docker image defines many run-time characteristics of the application from:

• What operating system the application is running on
• What ports will be open
• What type of application will be running
• What will be available to the application

After the Docker engine creates an image, that image can then be run in a container where it can be kept private or made publicly available. Most publicly available Docker images can be found on Docker Hub. Docker Hub is an image registry that allows organizations and individual contributors to upload and share Docker images.

DockerFile

Creating a Docker image isn’t as simple as running a single command. Each image must contain a set of instructions to instruct the engine on how to build the image. A Dockerfile is where these instructions are kept.

A Dockerfile is a text file containing instructions for all commands, ports, and dependencies that need to create an image. Dockerfiles are used to automate the process of creating a Docker image. Think of a Dockerfile as a step-by-step recipe for building a Docker image.

A Dockerfile contains a few key instructions.

• MAINTAINER: The name of the person not only creating the Dockerfile but maintaining it for the developers and operations teams to use.
• FROM: The Docker image name
• RUN: A command that will be run in the Docker image.
• COPY: Any files that need to be copied into the docker image.
• EXPOSE: Any ports that need to be public facing.

For more information on Docker files and the structure, take a look at the best practices from Docker here.

What Docker isn’t

Before moving onto the project for this chapter, it’s important to understand what Docker isn’t. There are a few common misconceptions that you should flesh out of your head from the start.

First, Docker containers are not virtual machines (VMs). VMs run full operating systems and containers do not. Docker (and all other containers) share the host’s operating system.

Docker containers are not a replacement for VMs. VMs still very-much have a place in the tech world. There could come a time when containers eliminate the need for VMs, but that time is not now. Many organizations still heavily rely on VMs. Not to mention the Docker engine itself needs a place to run.