Introduction to Docker

What is Docker?
According to the IBM analysis, the definition of Docker is- “Docker is an open source containerization platform. It enables developers to package applications into containers—standardized executable components combining application source code with the operating system (OS) libraries and dependencies required to run that code in any environment.”

Developers can create containers without Docker, but the platform makes it easier, simpler, and safer to build, deploy and manage containers. And one of the main advantages of Docker is that the source code becomes compatible with any of the environments once placed in it. Docker is essentially a toolkit that enables developers to build, deploy, run, update, and stop containers using simple commands and work-saving automation through a single API.

Brief History of Docker:
In 2008, Docker was known as DotCloud and was first founded by Solomon Hykes in Paris. It started out as a platform as a service (PaaS) before pivoting in 2013 to focus on democratizing the underlying software containers its platform was running on.
Hykes first demoed Docker at PyCon in March 2013, where he explained that Docker was created because developers kept asking for the underlying technology powering the DotCloud platform. “We always think it would be cool to be able to say, ‘Yes, here is our low-level piece. Now you can do Linux containers with us and go do whatever you want, go build your platform.’ So that’s what we are doing.”
And so Docker was born, with the open source project quickly picking up traction with developers and attracting the attention of high-profile technology providers like Microsoft, IBM, and Red Hat, as well as venture capitalists willing to pump millions of dollars into the innovative startup. The container revolution had begun.

What is a container & how does it work?
A container is a standard unit of software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another.
Containers are made possible by process isolation and virtualization capabilities built into the Linux kernel. These capabilities - such as control groups (Cgroups) for allocating resources among processes, and namespaces for restricting a processes access or visibility into other resources or areas of the system - enable multiple application components to share the resources of a single instance of the host operating system in much the same way that a hypervisor enables multiple virtual machines (VMs) to share the CPU, memory and other resources of a single hardware server.
As a result, container technology offers all the functionality and benefits of VMs - including application isolation, cost-effective scalability, and disposability - plus important additional advantages:
1.Lighter weight.
2.Greater resource efficiency.
3.Improved developer productivity.
Docker containers provide a way to get a grip on software. You can use Docker to wrap up an application in such a way that its deployment and runtime issues—how to expose it on a network, how to manage its use of storage and memory and I/O, how to control access permissions—are handled outside of the application itself, and in a way that is consistent across all “containerized” apps. You can run your Docker container on any OS-compatible host (Linux or Windows) that has the Docker runtime installed.

The Docker platform:
Docker provides the ability to package and run an application in a loosely isolated environment called a container. The isolation and security allow you to run many containers simultaneously on a given host. Containers are lightweight and contain everything needed to run the application, so you do not need to rely on what is currently installed on the host. You can easily share containers while you work, and be sure that everyone you share with gets the same container that works in the same way.
Docker provides tooling and a platform to manage the lifecycle of your containers:

• Develop your application and its supporting components using containers.
• The container becomes the unit for distributing and testing your application.
• When you’re ready, deploy your application into your production environment, as a container or an orchestrated service. This works the same whether your production environment is a local data center, a cloud provider, or a hybrid of the two.

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, which lets you work with applications consisting of a set of containers.

The Docker daemon:
The Docker daemon (dockerd) listens for Docker API requests and manages Docker objects such as images, containers, networks, and volumes. A daemon can also communicate with other daemons to manage Docker services.

The Docker client:
The Docker client (docker) is the primary way that many Docker users interact with Docker. When you use commands such as docker run, the client sends these commands to dockerd, which carries them out. The docker command uses the Docker API. The Docker client can communicate with more than one daemon.

Docker registries:
A Docker registry stores Docker images. Docker Hub is a public registry that anyone can use, and Docker is configured to look for images on Docker Hub by default. You can even run your own private registry.
When you use the docker pull or docker run commands, the required images are pulled from your configured registry. When you use the docker push command, your image is pushed to your configured registry.

Docker objects:
When you use Docker, you are creating and using images, containers, networks, volumes, plugins, and other objects. This section is a brief overview of some of those objects.

Images:
An image is a read-only template with instructions for creating a Docker container. Often, an image is based on another image, with some additional customization. For example, you may build an image which is based on the Ubuntu image, but install the Apache web server and your application, as well as the configuration details needed to make your application run.
You might create your own images or you might only use those created by others and published in a registry. To build your own image, you create a Docker-file with a simple syntax for defining the steps needed to create the image and run it. Each instruction in a Docker-file creates a layer in the image. When you change the Docker-file and rebuild the image, only those layers which have changed are rebuilt. This is part of what makes images so lightweight, small, and fast, when compared to other virtualization technologies.

Containers:

A container is a runnable instance of an image. You can create, start, stop, move, or delete a container using the Docker API or CLI. You can connect a container to one or more networks, attach storage to it, or even create a new image based on its current state.
By default, a container is relatively well isolated from other containers and its host machine. You can control how isolated a container’s network, storage, or other underlying subsystems are from other containers or from the host machine.
A container is defined by its image as well as any configuration options you provide to it when you create or start it. When a container is removed, any changes to its state that are not stored in persistent storage disappear.

Example docker-run command:
The following command runs an ubuntu container, attaches interactively to your local command-line session, and runs /bin/bash.
$ docker run -i -t ubuntu /bin/bash
When you run this command, the following happens (assuming you are using the default registry configuration):

1. If you do not have the ubuntu image locally, Docker pulls it from your configured registry, as though you had run docker pull ubuntu manually.
2. Docker creates a new container, as though you had run a docker container create command manually.
3. Docker allocates a read-write filesystem to the container, as its final layer. This allows a running container to create or modify files and directories in its local filesystem.
4. Docker creates a network interface to connect the container to the default network, since you did not specify any networking options. This includes assigning an IP address to the container. By default, containers can connect to external networks using the host machine’s network connection.
5. Docker starts the container and executes /bin/bash. Because the container is running interactively and attached to your terminal (due to the -i and -t flags), you can provide input using your keyboard while the output is logged to your terminal.
6. When you type exit to terminate the /bin/bash command, the container stops but is not removed. You can start it again or remove it.

The underlying 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.
These namespaces provide a layer of isolation. Each aspect of a container runs in a separate namespace and its access is limited to that namespace.

Docker deployment and orchestration:
If you’re running only a few containers, it’s fairly simple to manage your application within Docker Engine, the industry de facto runtime. But if your deployment consists of thousands of containers and hundreds of services, it’s nearly impossible to manage that workflow without the help of these cause-constructed tools.

Docker Compose ->
If you’re building an application out of processes in multiple containers that all reside on the same host, you can use Docker Compose to manage the software’s architecture. Docker Compose creates a YAML file that specifies which services are included in the application and can deploy/install and run containers with a single command. Using Docker Compose, you can also outline continual volumes for storage, specify base nodes, and document and configure service dependencies.

Kubernetes ->
To monitor and manage container lifecycles in more complex environments, you’ll need to turn to a container orchestration tool. While Docker includes its own orchestration tool (called Docker Swarm), most developers choose Kubernetes as an alternative.
Kubernetes is an open-source container orchestration platform descended from a project developed for internal use at Google. Kubernetes schedules and automates tasks integral to the management of container-based architectures, along with container deployment, updates, service discovery, storage provisioning, load balancing, health monitoring, and more. Furthermore, the source ecosystem of tools for Kubernetes—including Istio and Knative—enables organizations to deploy a high-productivity Platform-as-a-Service (PaaS) for containerized applications and a faster on-ramp to serverless computing.

Docker Advantages:

• Docker containers provide a way to build applications that are simpler to assemble, maintain, and move around than previous methods allowed. That provides several advantages to software developers.
• Docker containers are minimalistic and permit portability. Docker lets applications and their environments be kept clean and minimal by isolating them, which allows for more granular control and greater portability.
• Docker containers enable composability. Containers make it easier for developers to compose the building blocks of an application into a modular unit with easily interchangeable parts, which can speed up development cycles, feature releases, and bug fixes.
• Docker containers ease orchestration and scaling. Due to the fact that the containers are lightweight, developers can launch lots of them for better scaling of services. These clusters of containers do then need to be orchestrated, that’s where Kubernetes generally comes in.

Docker Drawbacks:

• Containers solve a great many problems, but they don’t solve all developer ills.
• Docker containers are not virtual machines. Unlike virtual machines, containers use controlled portions of the host operating system’s resources, which means that the elements aren’t as strictly isolated as they would be on a VM.
• Docker containers don’t provide bare-metal speed. Containers are significantly more lightweight and closer to the metal than virtual machines, but they do incur some performance overhead. If your workload requires bare-metal speed, a container will get you close but not all the way there.
• Docker containers are stateless and immutable. Containers boot and run from an image that describes their contents. That image is immutable with the aid of default—once created, it doesn’t change. But a container instance is transient. When it is removed from system memory it’s gone forever. If you want your containers to persist state across sessions, like a virtual machine, you need to design for that persistence.

What is Docker Today?
Container usage continues to grow as cloud-native development techniques become the mainstream model for building and running software, but Docker is now only a part of that puzzle.
Docker became mainstream by making it easy to move the code for an application and all of its dependencies from the developer’s pc to a server. But the upward thrust of containers led to a shift in the way applications are built—from monolithic stacks to networks of microservices. Soon many users needed a way to orchestrate and manage groups of containers at scale.
Born out of Google, the Kubernetes open source project quickly emerged as the best option to do this, superseding Docker’s own attempts to solve this problem with its Swarm orchestrator (RIP). Amidst increasing funding trouble, Docker ultimately offered its organization enterprise to Mirantis in 2019, which has been the reason that absorbed Docker Enterprise into the Mirantis Kubernetes Engine.
The remains of Docker—which includes the original open source Docker Engine container runtime, Docker Hub image repository, and Docker Desktop application—live on under the leadership of company veteran Scott Johnston, who is trying to reorient the enterprise around its core center purchaser base of software developers.