Docker deep level with architecture — part 1

Why you need to read this post?

You know the docker but you don’t know how docker work in background (architecturally) .

working on the best technologies, you need to know Docker and containers.

If you are not the developer and still you want to see/check docker.

Let’s start from beginning.

What Happend Old Days?

As you know old days we one application run one a one server if we use server to host applications. But you know linux and windows, didn’t have safely and securely run multiple applications on the same server.

Those days if company want new application with new features, IT team (devops not came to the table on those day I feel) blindly guess the server performance and buy the server. As a result, they will buy big servers(high performance servers)

But is resulted in over-powered servers operating as low as few percentage of their potential capacity. A tragic waste of company capital and environmental resources..

Wow (wow for those days) VMs

Several companies. But first I think VMware, Inc.

Virtual machine is a gift and game changer. Now IT team don’t need to buy big server for new applications and can run multiple applications is same server with much secured way.

But ………

Every VMs are required dedicated Operating system. That is main issue. So every OS has their own CPV , RAM and some other resources.

Not only that,

How about managing(patching) and monitoring. That will get Headache to IT team. Slow booting, moving VM workload is additional headache what IT team and dev team face.

Okay next Docker….. ! No next container.

Big companies like Google used some containertechnologies to address the shortcomings of the VM model.

container don’t need their own full blow OS. all containers can share the host’s OS. In that way can reduces patching and maintains as well since it has only one OS.

New Containers

Google helped a lot to improve containers. Thats how new containers came for us.

eg : kernel namespaces, control groups, union filesystems

Now Docker. What is the Docker?

Docker is an open-source engine that automates the deployment of applications into containers. It was written by the team at Docker, Inc (formerly dotCloud Inc, an early player in the Platform-as-a-Service (PAAS) market), and released by them under the Apache 2.0 license

Docker runs on Linux and Windows. It creates, manages, and can even orchestrate containers.

Do you know how the name came as Docker?

British expression meaning dock worker — somebody who loads and unloads cargo from ships.

Docker Technology

Docker is written in the Go programming language and takes advantage of several features of the Linux kernel to deliver its functionality. Docker uses a technology called namespaces to provide the isolated workspace called the container. When you run a container, Docker creates a set of namespaces for that container.

You have to aware at least following three.

1. The runtime
2. The daemon(a.k.a.engine)
3. The orchestrator

Docker Engine

The runtime operates at the lowest level and is responsible for starting and stopping containers

The low-level runtime is called runc and is the reference implementation of Open Containers Initiative (OCI) runtime-spec.

The higher-level runtime is called containerd. containerd does a lot more than runc. It manages the entire lifecycle of a container, including pulling images, creating network interfaces, and managing lower-level runc instances. containerd is pronounced “container-dee’ and is a graduated CNCF project used by Doer and Kubernetes as a container runtime.

runc

As previously mentioned, runc is the reference implementation of the OCI container-runtime-spec.

containerd

As part of the effort to strip functionality out of the Docker daemon, all of the container execution logic was ripped out and refactored into a new tool called containerd . Its sole purpose in life was to manage container lifecycle operations — start | stop | pause | rm….

containerd is available as a daemon for Linux and Windows, and Docker has been using it on Linux since the 1.11 release. In the Docker engine stack, containerd sits between the daemon and runc at the OCI layer.

The Open Container Initiative (OCI)

The OCI is a governance council responsible for standardising the low-level fundamental components of container infrastructure. In particular it focusses on image format and container runtime

Docker architecture🔗

Docker uses a client-server architecture. The Docker client talks to the Docker daemon, which does the heavy lifting of building, running, and distributing your Docker containers. The Docker client and daemon can run on the same system, or you can connect a Docker client to a remote Docker daemon. The Docker client and daemon communicate using a REST API, over UNIX sockets or a network interface. Another Docker client is Docker Compose, that lets you work with applications consisting of a set of containers.

Image and content copy from docker website.

shim is new for now. What is that?

the shim is integral to the implementation of daemonless container

How to secure client and daemon(server) communication ?

the client application call as docker (docker.exe on windows) and server called dockerd (dockerd.exe on windows). default installation puts on the same host and communicate over the IPC socket.By default, network communication occur over an unsecured HTTP socket on port 2375/tcp.

The high-level process will be as follows:

1. Configure a CA and certificates
2. Create a CA
3. Create and sign keys for the Daemon
4. Create and sign keys for the Client
5. Distribute keys
6. Configure Docker to use TLS
7. Configure daemon mode
8. Configure client mode

More details will provided by later post if need more details.

More topics to talk . Will go one by one for the deeper in next few posts.

1. images
2. Docker containers
3. Docker compose
4. Docker swarm
5. Docker networking
6. Volumes
7. Docker stacks