Docker - The Beginning

The above process can take a lot of time, which is neither productive nor cost-effective. Software developers, wanting to shorten the time needed for deployment—for example, in the step where they request the operations team to install additional components—might be tempted to bake them directly into the application themselves to bypass this step. 

This is where tools like heroku show their utility and strength, often compared to standard deployment methods as being more efficient.

Docker is not Heroku, but it enables achieving similar results. It uses a slightly different, more open approach, offering its solutions along with all necessary elements while allowing them to be swapped for others. The starting point is using an image repository, thereby separating the responsibility for builds from deployment and maintenance. 

The above already gives an idea of the benefits of using this solution. Furthermore, one can observe strong support for this project from major IT market players. Over time, the project is constantly being developed and improved. Since June 2015, we can also speak of the standardization of such solutions thanks to The Open Container Initiative. 

Docker offers great capabilities and is applicable in complex solutions. In itself, it is no longer so intimidating and represents a classic client-server architecture model. It has a single executable module handling both components; the difference lies in the parameter with which it is launched. 

Docker Compose

A tool for running multi-container applications. It allows you to create a compose file, thereby configuring all necessary services to be started with a single command. Documentation.

Docker Machine

A tool that allows you to install the Docker engine on a local Windows host and use it to issue commands and manage existing hosts with Docker installed in the infrastructure. Using docker-machine commands, you can start, check, stop, and restart managed hosts, upgrade the Docker server and client versions, and perform configuration changes. Documentation. 

Docker Swarm.

A solution providing a native cluster for Docker. It allows you to use a pool of Docker hosts from a single master host. Since Swarm communicates with the world using the same API as Docker, it is possible to use any tool that already communicates with Docker to leverage Swarm's capabilities. Documentation.

Docker Client

The most important interface you will encounter in Docker is the text-based client written in the GO language. Tasks that can be performed using it include: 

• Creating container images.
• Pulling a container image from an existing image registry.
• Pushing created images to an image registry.
• Running a container on a Docker server.
• Fetching logs from a remote server.
• Starting a command line inside a container on a remote server.

Beyond communication via the text client, it is also possible to use the API interface. 

API Documentation - https://docs.docker.com/engine/api/

Networking

Although container processes are located within the host system itself, their behavior is slightly different from standard processes in the network layer. As a reference, one can compare containers to individual computers in a private local network. The Docker server acts as a virtual network bridge, while containers are clients connected through it. You could say it is a small internal network with connected hosts.

Each container has its own network interface connected to the Docker network bridge, and then the server ports are mapped to the container ports, which makes the container visible from the outside. Traffic directed to the container passes through a proxy mechanism existing in the Docker server. For operation, a free block of a private subnet is used, assigned to Docker's own virtual network, bridged to the local network using the docker0 interface. This solution also ensures communication between containers. Outbound traffic is handled by the virtual interface of the docker0 virtual bridge.

Detailed documentation on Docker networking is available at:
https://docs.docker.com/engine/userguide/networking/

Where to apply the Docker solution?

The container technology offered by Docker will likely prove useful in many places. However, there are places where it fits better and others where it fits less. It is worth understanding how to fully utilize a given tool and be aware of what it will not be suitable for.

The architecture of this solution works excellently for stateless applications or those where state data is kept in internal data stores, e.g., cache or a database. In such cases, Docker forces the use of so-called programming best practices. The difference between stateful and stateless applications is that stateful ones store important data in memory, databases, or flat files and are exposed to data loss upon service restart if not permanently saved beforehand. The essence of stateless applications is that they are designed to respond quickly to individual client requests without storing any data.

General idea of Docker.

Using an analogy to other solutions, in the case of Docker, one should think of it as a separate space for storing individual Unix system processes. Such a process can also invoke other processes, and the whole thing is enclosed as if in a single separate package. One might consider it similar to virtual machines, but containers can be created and deleted much more easily. Compared to virtual machines, a container needs very few resources. There are examples where a container built from an existing image on disk takes up only 12 kilobytes. This happens because the container in this case only contains a pointer to the file system layer and metadata containing configuration information. The above boils down to the fact that you probably wouldn't use a new virtual machine just to execute a single SQL or curl request, but a container is perfect for that.

Although it is generally believed that containers are independent, isolated entities, in reality, it is more limited than one might expect. It is possible to limit their resources, but with default configuration, containers will behave like any Unix environment process, sharing and competing for the available resources of the host they are on. It is good to anticipate in advance whether many containers will share a single file system layer. The point is that if an update occurs for an image that is shared, many containers will then need to be recreated.

Processes running in containers also exist on the Docker server itself because they use the same Linux kernel. They can also be seen on the host operating system where Docker is running by using the ps command. This is a visible difference between the Docker solution and the hypervisor known from virtualization, where process isolation results from running them in a completely separate virtual machine operating system.

Security
  

The default configuration of containers is set up such that many of them use UID 0 to run processes, which does not raise objections, especially since we speak of a container as a closed, separate entity. Because the same Linux kernel is used for operation, even the simplest configuration errors can allow a container's root user to gain access to the system resources and processes of the host on which the container is located.

Earlier, I wrote that Docker works best with stateless applications. But what if such state must be saved and passed on? You can use environment variables stored in the metadata describing the container configuration for this purpose. This provides the ability to pass the same configuration to the container every time it is restarted.