Home Linux Total Package » Linux Magazine

Total Package » Linux Magazine

Total Package » Linux Magazine

By all accounts, Docker’s developer tools have been an important player in the recent history of enterprise IT. Although containers were not new in 2013, the release of the open source Docker platform made containers more accessible to everyday admins by simplifying development and deployment. Docker also helped shape the container landscape by joining with other container industry leaders to establish the Open Container Initiative (OCI), a Linux Foundation project that maintains open industry standards around container formats and runtimes. Docker even contributed runc, the original OCI container runtime, to the foundation in 2015.

In recent years, container technology has proven to be reliable and ubiquitous, resulting in attention shifting to orchestration tools such as Kubernetes.

Docker the company actually sold its Enterprise division to Mirantis in 2019. Included in that sale was the Docker Swarm orchestration platform, which Mirantis has continued to market under the Docker Swarm brand, causing some confusion over what is Docker and what isn’t. For instance, some viewers (incorrectly) visualize Docker as somehow competing with Kubernetes, when in fact, Mirantis competes with Kubernetes, and the original Docker container platform is fully integrated into the Kubernetes environment.

Docker’s developers are still hard at work, focused on development tools. Their philosophy is that, although it is possible to build a single container on the fly without the need for an enhanced toolset, if you build containers for a living or are concerned with security and consistency in your container creations, you’ll need a versatile set of development tools.

Docker remains heavily invested in open source, and several Docker tools are available under open source licenses. This article takes a tour of the container-building tools in the Docker toolset and offers a glimpse at where the company has been putting its energies.

Many of these open source tools have found their way into the Moby Project, an upstream, community-governed project for container components, which Docker founded in 2017. Moby offers a toolkit of components, a framework for assembling these components, and a community for testing and sharing ideas.

Docker Engine

Docker Engine [1], the open source container engine for building containerized applications, forms the core of Docker’s developer tool suite. Developed upstream in the Moby Project, Docker Engine uses a client-server architecture (Figure 1). Docker Engine consists of the daemon (dockerd) and APIs that specify which programs can talk to and instruct the daemon.

Figure 1: Docker’s client-server architecture.

Docker’s open source CLI client (docker) interacts with Docker Engine, letting you manage your containers from the command line. It talks to the daemon, which does the work of building, running, and distributing containers. Written in Go, the Docker CLI manages single containers, as well as container images, networks, and volumes. For managing multiple containers, you will need a separate tool, Docker Compose (see below).

For its container runtime, Docker Engine relies on containerd, which manages the container life cycle and handles creating, stopping, and starting your containers (see the containerd section for more information).

Docker Engine also integrates the open source BuildKit component. BuildKit replaced and improved the legacy builder in the release of Docker Engine 23.0. BuildKit offers improvements in performance, storage management, and extensibility. Unlike the legacy builder, which performs builds serially from Dockerfiles (the text file containing all the commands called at the command line to assemble an image), BuildKit allows parallel build processing and introduces support for handling more complex scenarios, such as the ability to detect and skip execution of unused build stages.

Docker Engine binaries are available as DEB or RPM packages for CentOS, Debian, Fedora, Ubuntu, Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES), and Raspberry Pi OS. Docker also offers a static binary for non-supported Linux distributions, but it is not recommended for production environments.

Docker Compose

If you are looking to define and run multi-container Docker apps, you will need Docker Compose [2]. Available as a plugin for Docker Engine, Docker Compose lets you run a project with multiple containers from a single source.

Docker Compose uses a YAML file to configure your application’s services. Once configured, you can use a single command to create and start all of your configuration’s services.

Docker Compose provides commands for an application’s entire life cycle. You can use Docker Compose in all environments: development, testing, staging, continuous integration (CI), and even production. Because Docker Compose is an abstraction that aligns with developers’ mental model of their applications, it particularly supports the inner loop of application development.

A recent addition to Docker Compose is Docker Compose Watch [3]. The Watch feature lets you define a list of rules that will cause an automatic service update when a file is modified. Watch monitors the files in the local directory, rebuilding the application container when necessary so the application stays up to date.


Docker donated containerd [4], an industry-standard container runtime, to the Cloud Native Computing Foundation (CNCF) in 2017. With an emphasis on simplicity and portability, containerd manages the complete container life cycle on a host – from image transfer and storage to container execution and supervision, to low-level storage and network attachments.

Designed to be embedded in a larger system such as Docker Engine, containerd functions as an internal runtime with minimal runtime requirements. The containerd daemon is available for both Linux and Windows, with most of its interactions with these operating systems’ container feature sets being handled by runc or operating system-specific libraries.

By design, containerd works with Docker and Kubernetes, as well as any container platform that wants to abstract syscalls or operating system-specific functionality. Whereas containerd implements the Kubernetes Container Runtime Interface (CRI) for those wanting to run a Kubernetes cluster, you can just as easily use containerd without Kubernetes. However, if you do plan to use Kubernetes, you will want to use containerd v1.5.11 or v1.6.4 to address the recent removal of dockershim from Kubernetes.

You can find containerd as a binary package for the 64-bit architectures Intel AMD, PowerPC Little Endian, and RISC-V, as well as for the S390x architecture.

Source link

netbalaban news