Getting Started with Docker

Get started with Docker

To understand the present, we must first understand the past and how we arrived at the present. Back in the day, applications ran on physical servers in the back office.

In most cases, we ran one application per server. The business ordered server racks and other hardware ahead of time in anticipation of a heavy deployment. The pace of development was slow.

Deploying a new application was time-consuming and inefficient, required a large configuration, and took months to complete. Back then, applications were designed and built for a limited number of people, usually in a single office location.

Virtual machines

It wasn’t scalable to run applications on physical servers in the back office as the world became more connected, with fierce competition on all sides. Amidst this, virtualization was born and quickly became a source of relief for most businesses.

Instead of running one application per server, virtualization allows us to divide a physical server’s hardware component into virtual machines, allowing us to run multiple applications on a single server.

Virtual machines were good because they were easier to work with and more cost-effective for businesses. They provided some flexibility, but there were some problems.

Here are the problems with virtualization:

• Each virtual machine requires its own operating system (OS), which requires RAM, memory, and storage to run that could otherwise be used to power other business applications.
• Some operating systems require a license.
• Virtual machines are slow and take time to boot.
• Virtual machines aren’t portable, which makes it hard to migrate workloads between clouds.

After all, it’s obvious that virtualization isn’t a remedy for all use cases because there are situations where flexibility and portability are more important. This is where containerization enters the picture.

While virtualization isolates compute resources through virtual machines, containerization uses the concept of containers to isolate and encapsulate software.

What exactly is a container, though?

Containers

The team behind the Docker platform defines a container as follows:

A container is a standard unit of software that packages up code and all dependencies that it needs to run quickly and reliably from one computing environment to another.

Applications aren’t guaranteed to run consistently in all environments (be it a cloud, CI, or production environment) without container and virtualization technologies. If we’re software engineers or have worked closely with software engineers, we may have heard the classic problem of “But it works on my machine.”

Making applications run in different environments has long been one of the most difficult challenges for developers and system administrators (sysadmins). Engineers often express their dissatisfaction by saying, “It runs on my computer.”

We may be developing in a local environment to discover that the dependencies in the production environment vary slightly from the dependencies used to create the application. It gets much more complicated when we try to make both environments identical. We may find that other resources on the host rely on a dependency that isn’t available on the other. When environments aren’t isolated, we’re faced with this dilemma, which we can call “a dependency nightmare.”

Containerization solves this problem by encapsulating our application and its dependencies into a single self-contained unit that can run consistently anywhere.

Differences between virtual machines and containers

Virtual machines and containers both isolate resources, but they aren’t the same thing.

• Rather than virtualizing the hardware like in a virtual machine, containers virtualize the operating system, with each container containing the application code and dependencies.

• Containers are typically a few megabytes in size. This makes them portable and easy to move between environments.

• Containers are fast and don’t need to boot up like a virtual machine.

• Containers, as opposed to virtual machines, consume fewer resources and have a smaller memory footprint.

• In virtualization, we have to patch and update each guest operating system. In containers, only the host OS needs to be patched or updated.

Virtual machines or containers: which should we use?

When is it appropriate to use virtual machines and when is it appropriate to use containers? The answer is that it depends.

If we’re developing a microservice-based application or planning to migrate to a microservice architecture, we use containers. Because of their small, lightweight, and fast nature, containers are ideal for microservices or cloud applications that scale quickly across multiple environments.

Containers consume less RAM and memory, allowing us to fit more on a physical server and use available resources efficiently. When developing an application with a strong emphasis on portability, scalability, and maintainability, we use containers.

If we want to run applications in a safe, secure sandbox environment while isolating one workload from another, a virtual machine is suitable. It provides better workload isolation and security. Unlike containers, which share the same kernel as other containers on the host, a virtual machine is completely isolated.

If our application requires a rollback feature, such as the ability to restore our data or system to a specific point in time, we should use a virtual machine. A virtual machine platform will enable us to take a snapshot of a virtual machine at a specific point in time and roll it back when necessary.

Finally, by running containers in virtual machines, we can get the best of both worlds. Containers and virtual machines can coexist.

Although there are other container runtime environments such as podman, LXC, and others, we’ll concentrate on the most common runtime— Docker.

Docker

Depending on the context, the term “Docker” can mean a variety of things. It’s critical to clear up some confusion.

• Docker, Inc. is the company behind Docker.
• Docker is the Docker project in its entirety. It’s a platform for developers and system administrators to build, ship, and run applications.

The term “Docker” is sometimes used interchangeably with “Docker, Inc.” The trick is to pay attention to the context in which it is used since it can refer either to the technology or to the company. For the most part, the term “Docker” will be used to identify the technology.

Docker has altered the way we develop, package, and deploy applications. The concept of packaging applications in containers, on the other hand, isn’t new. It existed long before Docker. Unix v7 included process isolation as early as 1979.

Docker simplifies containerization for sysadmins and developers by creating a simple local daemon and APIs with excellent tooling to hide containerization complexities.

Docker also includes an image layering framework that is efficient (more on that later) and a registry for creating and sharing Docker images with others. This is why Docker is now a requirement in nearly all development workflows.

The Docker architecture

The Docker platform uses a client-server architecture. A client-server architecture is an architecture composed of a client and a server. The client requests and receives service from a centralized server, also known as the host. We can think of the Docker daemon as the server and the Docker CLI as the client in the Docker context.

The Docker daemon runs in the background on our host machine, actively waiting for requests to be handled. It’s the Docker container platform’s control center. It exposes REST APIs through which we can interact with it. This means that anyone can create a Docker client to interact with the daemon. However, unless we have a specific requirement, we don’t need to create a Docker client. To interact with the Docker daemon APIs, we should use Docker CLI—a tool built for this purpose.

The Docker daemon currently runs on Linux because it relies on several Linux kernel features to isolate an environment (more on this later). This doesn’t mean that we can’t use Docker on Mac or Windows; there are other methods for running Docker on these operating systems.

We could, for example, run Docker in a Linux virtual machine on Windows and interact with its APIs via a client. Because Docker is a client-server architecture, it doesn’t matter where the server is or how far the client is from the server. We can interact with it remotely.

The difference between Docker containers and Docker images

As we learn more about Docker, we’ll notice that the terms “Docker container” and “Docker image” appear frequently. It’s important to understand the difference between a Docker container and a Docker image if we want to advance in the world of Docker.

Docker image

A Docker image is a file that represents our packaged software code, including all of its dependencies, runtime, settings, and libraries. A Docker image can’t be changed once we’ve created it. Every time we make a change to it, we create an entirely new image. The immutability of Docker images allows them to run in the same way indefinitely, regardless of the environment.

Docker images can be distributed. Docker, in fact, has a Docker registry called Docker Hub, which serves as a repository for Docker images. Because Docker images are immutable, we can publish them and share them with friends with confidence that our image will continue to function indefinitely.

However, if a Docker image isn’t running, it’s not that useful. We may share a Docker image, but the real deal is the running instance.

Docker container

A Docker container is an instance of a Docker image. If we’ve worked with an object-oriented programming language before, chances are we’re familiar with the concept of a class and the instance of a class. If a Docker image is a class, a Docker container is the instance of that class.

It’s possible to have multiple instances of a Docker image, just as it’s possible to have multiple instances of a class. In other words, we can use the same Docker image to run multiple Docker containers at the same time.

It’s wrong to think a Docker container is a running instance of a Docker image. A Docker container doesn’t have to be in a running state. Containers in Docker can be in one of five states: created, running, paused, stopped, or deleted.

With seven states that a Docker container can be in, we can use Docker CLI to create, start, restart, pause, or perform other actions. The following chapter delves even deeper into this.

Why and when should we use Docker?

The key to building API products that developers adopt and enjoy using is to build something that makes their lives easier. The same can be said for Docker. Docker abstracts complexities and simplifies container management, alleviating major pain points for developers and sysadmins.

Regardless of how complex the software is, running a Docker image is as simple as running a command. If we no longer require the software and wish to remove it, we can do so with a single command, and our system will be as clean as before.

Docker saves us time, energy, and money. It allows us to concentrate on what’s most important—developing our software.

Everyone uses a Docker container. The ecosystem is vast and actively supported by big tech companies. Docker was the most loved and most wanted platform in the 2019 Stack Overflow Survey. Docker’s popularity isn’t going down anytime soon because almost all tech-driven companies have adopted Docker.

With Docker’s benefits, can we use Docker for almost anything? When is it appropriate to use Docker?

Docker runs all applications that run on the Linux operating system and can run Windows applications that run on Windows servers, such as our databases, web servers, and mail servers. However, we can’t run native Windows and macOS applications on Docker. This means we can’t run our favorite desktop applications like web browsers, IDEs, word processors, and graphic editors on Docker.

Let’s summarize the points discussed above.

The following are examples of when we use the Docker container:

• We use Docker when we need to run software on multiple environments, such as local, test, CI, and production environments.
• We use Docker when portability is important to us and we want to share our software.
• We use Docker if we want to speed up our team and have them up and running in minutes while ensuring consistency across multiple environments.
• We use Docker if we want to save money or fit as many applications as possible on a limited hardware budget.