What is Docker
Docker is an open platform for developing, delivering, and operating applications. Docker is designed to get your applications up and to run faster. With Docker, you can decouple your application from your infrastructure and treat your infrastructure as a managed application. Docker helps you deploy your code more quickly, test faster, deploy applications faster, and reduce the time between coding and running code. Docker does this with a lightweight container virtualization platform, using processes and utilities to help manage and host your applications.
Docker development began in 2008, and in 2013 it was published as free software under the Apache 2.0 license. Docker was included in the Red Hat Enterprise Linux 6.5 distribution as a test application. In 2017, a commercial version of Docker with advanced features was released.
Docker runs on Linux, whose kernel supports groups and namespace isolation. For installation and use on platforms other than Linux, there are special utilities, Kitematic or Docker Machine.
Benefits of using Docker
- Minimal resource consumption – containers do not virtualize the entire operating system (OS) but use the host kernel and isolate the program at the process level. The latter consumes much less local computer resources than a virtual machine.
- High-speed deployment – you can not install auxiliary components but use ready-made docker images (templates). For example, constantly installing and configuring Linux Ubuntu does not make sense. It is enough to install it once, create an image, and continuously use it, only updating the version if necessary.
- Convenient hiding of processes – for each container, you can use different data processing methods, hiding background processes.
- Working with unsafe code – container isolation technology allows you to run any code without harm to the OS.
- Easy scaling – any project can be expanded by introducing new containers.
- Convenient launch – an application located inside a container can be launched on any docker host.
- File system optimization – the image consists of layers that allow you to use the file system very efficiently.
- 1. Docker-daemon – a container server that is part of the Docker software tools. The daemon manages Docker objects (networks, storages, images, and containers). The daemon can also communicate with other daemons to manage Docker services.
- 2. Docker-client / CLI – interface for user interaction with the Docker daemon. The Client and the Daemon are the most critical components of the Docker Engine. The Docker client can interact with multiple daemons.
- 3. Docker-image – a file that includes dependencies, information, and configuration for further deployment and initialization of the container.
- 4. Docker-file – a description of the rules for building an image, in which the first line indicates the base image. The following commands copy files and install programs to create a specific development environment.
- 5. Docker container – a lightweight, a self-contained executable software package that includes everything needed to run an application: code, runtime, system tools, system libraries, and settings.
- 6. Volume – file system emulation for reading and writing operations. It is created automatically with the container because some applications store data.
- 7. Docker-registry – a reserved server used to store docker images. Register examples:
- 7.1. Docker Center – The registry used to download docker-image. It provides hosting and integration with GitHub and Bitbucket.
- 7.2. Azure Containers – designed to work with images and their components in the Azure directory (Azure Active Directory).
- 7.3. Docker Trusted Registry or DTR is a docker registry service for installation on a local computer or company network.
- 8. Docker-hub or data storage is a repository designed to store images with various software. The presence of ready-made elements affects the speed of development.
- 9. Docker-host – a machine environment for running containers with software.10лDocker-networks – are used to organize a network interface between applications deployed in containers.
- 10. Docker-networks – are used to organize a network interface between applications deployed in containers.
What is Docker Engine
The Docker Engine is the core of the Docker mechanism. The “engine” is responsible for operating and communicating between the main Docker objects (registry, images, and containers).
Docker Engine Elements:
- The server initializes a daemon (background program) used to manage and modify containers, images, and volumes.
- REST API is a mechanism responsible for organizing the interaction between the Docker client and the Docker daemon.
- Client – allows the user to interact with the server using commands typed in the interface (CLI).
How Docker works
The operation of Docker is based on the principles of a client-server architecture, which is based on the client’s interaction with a web server (host). The first sends requests for data, and the second provides them.
Scheme of work:
- The user issues a command using the client interface to the Docker daemon deployed on the Docker host. For example, download a finished image from the registry (Docker image repository) using the docker pull command. The REST API provides the interaction between the client and the daemon. The daemon can use public (Docker Hub) or private registries.
- Based on the command given by the client, the daemon performs various image operations based on the instructions in the Dockerfile. For example, it builds them automatically using the docker build command.
- Image operation in a container. For example, running docker-image with docker run or deleting a container with docker kill.
Application examples of Docker
Developing applications with dependencies
Usually, to install some library or database, the developer needs to read the instructions on the site. He downloads it, installs it, configures it, and launches it. And when you need to switch to anotherthat’sdency, it removes it. And that’s how you deal with every addiction.
Docker provides an alternative path. Libraries, frameworks, and database vendors publish their software on Docker Hub almost daily as a Docker image. The image can be downloaded and deployed via Docker, worked with, pushed, and then stopped or deleted, leaving no traces in the operating system.
A single control interface eliminates the need for individual commands. It is enough to learn Docker commands: how to download images, run containers, forward, stop and remove ports. With Docker, you can run as many identical databases as you want inside one OS. Thanks to isolation, if something goes wrong, the errors will not affect the operating system and will not break anything.
To run autotests, specific dependencies are required, such as databases, message brokers, and the like. They must first be installed and configured on the build server. Problems sometimes arise in this place: if you miss some detail during setup, you can spoil the data or break something. It is much safer to deploy dependencies as a container on the server automatically. This allows you to run the tests quickly and remove the containers without lea”ing a”trace.
Even if the tests “break” some data, they will be deleted along with the container. In addition, the Docker server on which autotests are run will become universal. After all, thanks to containerization, it will be possible to run anything on it. So, you will save on hardware and system setup.
After testing, the project is packaged into an image and published, transferred to clients or infrastructure engineers.
Docker makes it easy to deploy an application further. SRE doesn’t have to consider what dependencies to install because everything is already packaged in the image. For them, this is a black box, which they update uniformly and automatically through the same commands.
The deployment environment also becomes universal because it always deals only with containers. Today, one container was deployed in it, and tomorrow another. At the same time, entirely different applications can be packed in containers.
Cons of Docker
High resource consumption
Docker creates an additional logical layer and consumes additional resources. Therefore, you must determine what is more important to you – resources or convenience. If you have enough resources, you can safely install Docker – you will conveniently update and version applications without fear of damaging the operating system. If resources are in short supply, then it is better to use the classic application installation scheme.
Large applications require an orchestrator.
Docker is suitable for running multiple containers. The default distribution of Docker Compose has a mechanism that allows you to control their launch using a YAML configuration file. But this mechanism is simple; it will not pull an application that includes 50-100 services. Docker does not have enough tools for managing and distributing resources, redundancy, and fault tolerance to implement different schemes for updating containers.
Installation issues on Windows and macOS
Docker was built for Linux. Other operating systems it does not support some types of networks. No one will notice this in most cases, but this limitation must be remembered. Also, on some devices, there is a conflict with Virtual Box when installing Docker on Windows.
What are container technologies?
A container is a standard unit of software in which an application is packaged with all the dependencies necessary for its operation – application code, launch environment, system tools, libraries, and settings.
Containers have been in use for over a decade, and today about a quarter of the leading IT companies use container solutions in production.
Many solutions on the market represent container runtimes and orchestrations, such as CoreOS rkt, LXC, OpenVZ, Apache Mesos, and Docker Swarm. However, more than 4/5 of the containers run in a Docker environment, and over half of the users have chosen Kubernetes for orchestration.
Why containers are useful
Lightness, speed, and the ability to work at a high level of abstraction, delegating hardware and OS issues to the provider, are the advantages of containers, which allow you to reduce the operational costs associated with the development and operation of applications that make solutions based on them so attractive to businesses.
Technical specialists primarily love containers for the ability to package an application along with its launch environment, thereby solving the problem of dependencies in different environments. For example, the difference in versdeveloper’sguage libraries on a developer’s laptop and subsequent environments will sooner or later lead to failures. It will be necessary to spend time at least analyzing them and, at the very least, solving the problem of bugs that have entered production. Using containers eliminates the problem.
Containers also reduce application development time and simplify its management in production due to ease of configuration and configuration changes, the ability to version it along with the application code, and convenient orchestration tools that allow you to scale the infrastructure quickly. In addition, the virtual absence of container binding to the hosting platform gives great flexibility when choosing or changing a provider – you can run them without fundamental differences in the final result on a personal computer, bare metal servers, and cloud services.
How containers differ from virtual machines
The most common question when choosing an application launch environment is the difference between containers and virtual machines – currently the two most popular options. There is a fundamental difference between them. The container, in essence, is a space limited inside the OS that uses the host system’s kernel to access hardware resources. A VM is a complete machine with all the devices necessary for its operation. From this, differences are formed that are of practical importance:
- Containers require significantly fewer resources to run, which positively impacts performance and budget.
- Containers can only be run on the same operating system on the host system – that is, it will not work to run a Windows container on a host system with Linux (on personal devices, this limitation is bypassed using virtualization technology). However, this does not apply to different distributions of the same OS, such as Ubuntu and Alpine Linux.
- Containers provide less isolation because they use the host system’s kernel, potentially creating more operational risks if security is not considered.
Basic principles of application containerization
One container – one service
A container should only do one thing – it shouldn’t contain all the entities that the application depends on. Following this principle allows you to achieve more excellent reusability of images and, most importantly, will enable you to scale the application more thinly – the bottleneck of your service may be only some part of the technology stack used. Dilution of all its parts into different containers will allow you to increase your service performance.
Immutability of the image
All changes inside the container should be made at the image build stage – following this principle ensures you against data loss when the container is destroyed. The immutability of the container also makes it possible to perform parallel tasks in CI / CD systems – for example, you can run various kinds of tests simultaneously, thereby speeding up the product development process.
This principle is a prime e”ample of the modern concept of “Treat infrastructure like cattle, not like pets.” Any container can be destroyed anytime and replaced with another without stopping the service. A container’s configuration in its image is essentially separated from the container instance that directly performs the work, which allows instances to be “knifed” when necessary – when the container state fails, downscaling, etc. Compliance with this principle means that the exit of containers from the building should not be new to your application: container rotation should be a development requirement.
The container must have points for checking the state of its readiness (readiness probe) and viability (liveness probe) and provide logs to track the state of the application running.
The application in the container must be able to interact with the process that controls it – for example, to correctly complete its work on a command from outside. This will allow transactions to be closed gracefully, preventing the loss of user data due to stopping or destroying the container.
The image with the application must have all the necessary dependencies for work – libraries, configs, etc. On the other hand, services do not belong to these dependencies. Otherwise, it would contradict the “1 container – 1 service” principle. The connectivity of containers that depend on each other can be determined using orchestration tools, which will be discussed below.
The best practices for operating containers include setting resource limits (CPU and RAM): following this practice allows you to remain attentive to saving resources and respond in time to their excessive consumption.
Benefits of using Docker containers
Docker solves dependency and environment issues
Containers allow you to pack an application and all its dependencies into a single image: libraries, system utilities, and configuration files. This simplifies porting the application to another infrastructure.
For example, developers create an application in the development system – everything is set up there, and the application works. It needs to be transferred to the testing system and the production environment when it is ready. If one of them does not have the required dependency, the application will not work. Programmers will have to take a break from development and, together with the support team, figure out the situation.
Containers do not have this problem, containing everything needed to run the application. Specialists are engaged in the development, not the solution of infrastructure problems.
Isolation and security
A container is a set of processes isolated from the primary operating system. Applications only run inside containers and do not have access to the underlying operating system. This improves the security of applications: they cannot accidentally or intentionally harm the primary system. If the application in the container crashes or hangs, it will not affect the leading OS.
Accelerating and automating application deployment and scalability
Containers make it easier to deploy applications. In the classical approach, to install the program, you must perform several actions: execute the script, change the settings files, and so on. In this process, the possibility of human error is not ruled out: the user will run the script twice, mix up the sequence, or not understand something. Containers allow you to fully automate this process, including all the necessary dependencies and the order in which actions should be performed.
Containers also make it easier to deploy across multiple servers. In the classical approach, you will need to repeat the same steps to deploy the same application on several machines. Containers get rid of this chore and allow you to automate deployment.
Containers move closer to microservice architecture
Containers fit nicely into a microservice architecture. This development approach breaks an application into small components that are as independent as possible—usually contrasted with a monolithic architecture where all system parts are tightly coupled.
This allows you to develop new functionality faster because, in the case of a monolithic architecture, a change in some part can affect the rest of the system.
Docker compose – Deploy multiple containers at the same time
Docker-compose allows you to deploy and configure multiple containers at the same time. For example, you need to deploy the LAMP stack: Linux + Apache, MySQL, and PHP for a web application. Each of the applications is a separate container for Linux OS. But in this situation, we need all the containers together and not a single application. Docker-compose allows you to deploy and configure all applications with one command, and without it, you would have to deploy and configure each container separately.
Until recently, the debate on the justification for using containers in production did not stop, and accusations of their unreliability were heard now and then. However, time does not stand still, the industry has assessed its prospects, made its choice, and investments in container solutions have flowed like a wide river, every day making resolutions based on them more convenient and attractive. Containers have proven to be a viable and competitive solution that reduces the time to market and the cost of its development and operation.