Chapter-1: Fundamentals of Container:
Let's start by understanding the basics of a Java JAR/WAR-based application to understand and compare Container based application. A JAR file, short for Java Archive file, is a file format used to package Java classes and resources into a single file. JAR files are commonly used to distribute Java applications and libraries. If you're deploying a server-based application, you typically require a Java Application Server or a Web Server for web applications.


In a traditional setup, you would follow these steps:
- Java Installation: You start by installing Java on your server. Java provides the runtime environment for your Java applications.
- Web Server Installation (For Web Applications): If you're deploying a web application (WAR file), you additionally need to set up a web server like Apache Tomcat or similar. This web server handles HTTP requests and serves your web application.
- Library Installation: Next, you install any required libraries or dependencies your application needs to run. This may include database drivers, external libraries, and more.
- Deploy Your JAR/WAR: Finally, you deploy your JAR or WAR file to the server, configuring it to work with the installed Java runtime and web server. This setup can be complex and involve various configurations.
Now, let's introduce the concept of a Container: A container is a self-contained environment that includes everything your application needs to run. This includes not only the Java runtime and web server but also any required libraries and dependencies. When using containers, you don't need to worry about the underlying server's environment.



Here's how it works with containers:
- Containerization: Your application and its dependencies are packaged together into a container image. This image contains the Java runtime, web server, libraries, and your application code.
- Container Runtime: You use a container runtime like Docker to manage and run your containers. The container runtime ensures that your application runs consistently across different environments.
- Simplified Deployment: With containers, you no longer need to install Java, set up a web server, or manage libraries separately. You simply provide your container image to the container runtime, which takes care of running your application.
- Microservices: Containers are often used to package individual microservices, allowing you to build and deploy complex applications composed of multiple smaller services. Each microservice can be a separate container.
In summary, a container is a self-contained unit that simplifies the deployment and management of applications. It includes all the necessary components, making it easier to deploy and run your Java applications, whether they are monolithic or microservices-based.
Basics of Docker Images:
As discussed, a Docker image is a lightweight, stand-alone, executable package that contains everything needed to run a piece of software, including the code, a runtime, libraries, and system tools. Docker provides a standard packaging format for containers, which allows them to run consistently on any environment that can execute Docker containers.
Here's a breakdown of key points related to Docker images:
- Packaging Format: Docker images serve as a packaging format for applications and services. They encapsulate an application and all its dependencies into a single, portable image file.
- Application Isolation: Docker images provide a high degree of application isolation. Each image is self-contained and runs in its own environment, isolated from other containers and the host system.
- Resource Efficiency: Docker leverages the resource isolation features of the Linux kernel, such as cgroups and namespaces, to run containers efficiently. Containers share the host OS kernel but operate as independent entities, minimizing resource overhead compared to traditional virtual machines.
- Portability: Docker images are designed to be highly portable. You can create an image on one system and run it on any other system that supports Docker, ensuring consistency in application behavior across different environments.
- Versioning: Images can have multiple versions, allowing you to maintain different releases of your application or service. This facilitates version control and rollbacks.
- Layered Structure: Docker images are built using a layered structure. Each layer represents a set of changes to the image, and layers are stacked on top of each other. This enables image sharing and efficient storage utilization.
- Container Orchestration: Docker images are often used in conjunction with container orchestration platforms like Kubernetes and Docker Swarm to automate the deployment, scaling, and management of containerized applications.
Docker images are a fundamental building block of containerization technology. They enable the creation, distribution, and execution of applications and services in a consistent and efficient manner, making it easier to manage complex software ecosystems across various environments.
Basics of Linux Control Groups (cgroups):
Control Groups (cgroups) in Linux are a kernel feature used by Docker for resource management and isolation. They enable Docker to allocate, limit, and monitor system resources, like CPU, memory, and I/O, among containers. Cgroups prevent resource monopolization, ensuring fair resource sharing and preventing one misbehaving container from affecting others. Docker leverages cgroups to set resource limits, allocate resources fairly, and dynamically manage resource allocations for running containers. This kernel-level control provides efficiency, reliability, and robust resource management for Docker, making it a powerful tool for containerization in multi-tenant environments. As per below diagram


- Server resources, including disk, memory, CPU, and network.
- The resources of server, allocated in 2 cgroups.
The diagram shows resources being allocated to each cgroup in equal measure, but it may have a combination of one or more resources. For example, cgroup2 could have just CPU and memory allocated, depending on how you configure the cgroups. As a result, by using cgroups, you gain more precise control over the allocation, prioritization, denial, management, and monitoring of system resources.
Basics of Namespace:
In the context of containerization and operating systems, namespaces are a feature that provides process isolation and resource separation for different processes running on the same system. Namespaces essentially create separate instances of global system resources for each process or group of processes, making them believe they have their own isolated view of the system.


Some common namespaces in Linux-based container technologies like Docker and Kubernetes include:
- PID Namespace: This isolates the process IDs, so processes in one namespace can't see or interfere with processes in another namespace.
- Network Namespace: This isolates network resources like network interfaces, routing tables, and firewall rules. Each network namespace has its own network stack, making it possible to have separate network configurations for different containers.
- Mount Namespace: This isolates the filesystem mount points. Processes in one mount namespace won't see the filesystem mounts of processes in other namespaces. This allows containers to have their own isolated filesystem.
- UTS Namespace: This isolates the hostname and NIS domain name. Each UTS namespace can have its own hostname.
- IPC Namespace: This isolates inter-process communication resources like System V IPC objects and POSIX message queues. Processes in different IPC namespaces can't communicate via these mechanisms.
These namespaces help in achieving process and resource isolation, which is crucial for containerization. They ensure that processes running in different containers or pods (in the case of Kubernetes) can't interfere with each other's resources or configurations, providing a level of security and isolation in a multi-tenant environment.
Virtualization and Docker:
Virtualization and Docker are both technologies used in the field of containerization and virtualization, but they serve different purposes and have distinct characteristics. Here's a comparison of virtualization and Docker:


Virtualization:
- Hypervisor-Based: Virtualization relies on a hypervisor, which is a software or hardware layer that creates and manages virtual machines (VMs). Examples of hypervisors include VMware, VirtualBox, and Hyper-V.
- Isolation: Each VM in virtualization is a complete guest operating system (OS) running on a hypervisor. It provides strong isolation between VMs, making it suitable for running different OS versions and applications on the same physical host.
- Resource Overhead: VMs consume more system resources because they include a full OS, including the kernel, system libraries, and drivers. This leads to higher resource overhead compared to containers.
- Portability: VMs are less portable than containers because they package an entire OS. Moving VMs between different environments or cloud providers can be more challenging.
Docker (Containerization):
- Container-Based: Docker is a containerization platform that uses lightweight containers instead of VMs. Containers share the host OS kernel, making them more efficient in terms of resource utilization.
- Isolation: Containers provide process-level isolation, meaning they run isolated processes within a shared OS kernel. While they offer strong isolation for most use cases, they share the same OS kernel.
- Resource Efficiency: Containers are highly resource-efficient because they share the host OS kernel. They are smaller in size, start faster, and consume fewer resources compared to VMs.
- Portability: Docker containers are highly portable. They package an application and its dependencies into a single container, making it easy to move and run the same container on different environments, from development to production.
Use Cases:
- Virtualization: Virtualization is well-suited for scenarios where you need to run multiple instances of different operating systems on the same physical hardware. It's commonly used in data centers for server consolidation and running legacy applications.
- Docker (Containerization): Docker and containers are ideal for microservices architectures, DevOps practices, and modern application deployment. Containers are used for packaging and deploying applications and services consistently across different environments.
Virtualization and Docker serve different purposes. Virtualization is suitable for running multiple VMs with different OSes, while Docker and containers are designed for lightweight and efficient packaging and deployment of applications. The choice between them depends on your specific use case and requirements. In many modern application scenarios, containers and Docker have become the preferred choice due to their efficiency and portability.
Docker Image vs Docker Container:
Docker Image: A Docker Image is a pre-packaged snapshot of a software application and its dependencies. It's a static, read-only file that contains all the necessary files, libraries, configurations, and code needed to run an application. Think of it as a blueprint or template for creating Docker Containers. To create Images you will be using Dockerfiles, which specify how to build them. Images are immutable, meaning they cannot be changed once created. You use Docker Images to create one or more Docker Containers.


Docker Container: A Docker Container, on the other hand, is a running instance of a Docker Image. It's a lightweight, isolated environment where an application and its dependencies can run. Containers are dynamic, allowing you to start, stop, or delete them as needed. Each container created from the same Docker Image operates independently, with its own isolated file system, processes, and network stack. Containers provide process and file system isolation, making them suitable for running applications in various environments. A Dockerfile is a plain text file containing instructions and configurations. It acts on a base image to create a new Docker image, serving as the source code for Docker images. The Dockerfile outlines how to build the image, with the "FROM" command specifying the base image. Running the "Docker run" command uses the Dockerfile to build the image. Dockerfiles ensure you have the latest version, enhancing security by avoiding insecure application installations.
In summary, Docker Images are static, unchangeable templates, while Docker Containers are the active, runnable instances of those templates. Images are used to create Containers, and each Container based on the same Image runs independently. Think of Images as blueprints and Containers as the buildings constructed from those blueprints.
Multiple containers, based on the same or different images, can run concurrently, akin to virtual machines. Docker optimizes resource utilization, allowing more containers on a given hardware configuration than virtual machines. Docker containers can run within virtual machines, streamlining virtualization with added automation and abstraction. Below is sample dockerfile.


A Dockerfile is a set of instructions for creating a Docker image. It uses commands like "FROM," "PULL," "RUN," and "CMD" to build an image. Here's what these commands do:
- FROM: creates a layer based on Ubuntu 18.04.
- PULL: adds files from your Docker repository.
- RUN: constructs your container.
- CMD: specifies the command to run inside the container.
An image consists of multiple layers, like layers in a photo editor, each modifying the environment. It includes the app's code, runtimes, libraries, and more. Images depend on the core host OS. For instance, to create a web server image, you start with an image containing Ubuntu Linux (the base OS) and then add Apache and PHP.
You can create images manually with a Dockerfile, a text document with image-building instructions. Alternatively, use "docker pull [name]" to fetch images from a central repository like Docker Hub. When a Docker user runs an image, it creates one or more container instances. The container's setup can vary, from a configured web server to a simple bash shell. Most images come with preloaded software and config files. Docker images are immutable; once created, they can't change. To make modifications, create a new container with your changes and save it as another image.
Basics of Docker Registry and Docker Repository:
Docker Registry: A Docker Registry is a storage system that holds Docker images. It serves as a central hub where Docker images are stored and can be accessed by users. Think of it as a library where you can store and share your Docker images. Docker Hub is one of the most popular public Docker Registries, but you can also set up your private Docker Registry if needed.
Docker Repository: A Docker Repository is a collection of related Docker images with the same name, but different tags. It's like a folder within the Docker Registry that organizes images. Each image in a repository has a unique tag, which allows you to version and differentiate between different releases or configurations of the same software.


Example: Suppose you have developed a web application using Docker, and you want to share it with your team.
- You build a Docker image of your web application using a Dockerfile. You can tag this image with a name, let's say "my-web-app," and version it with a tag like "v1.0."
- Now, you have the "my-web-app: v1.0" Docker image, and you want to share it with your team members. You push this image to a Docker Registry, which can be a public one like Docker Hub or a private one hosted on your company's server.
- Your team members can pull the image from the Docker Registry using the same repository name and tag, like "my-web-app: v1.0." This allows them to run containers with your web application on their local machines or servers.
In this example:
- my-web-app is the Docker Repository name.
- v1. 0 is the tag associated with a specific version of your Docker image.
- The Docker Registry (e.g., Docker Hub) is the central hub where your my-web-app repository and its tagged images are stored.
So, in summary, the Docker Repository is a logical grouping of Docker images with similar names, while the Docker Registry is the storage location where these repositories and their images are hosted and made accessible to others.
Another Example: Imagine you have a Java project named "MyJavaApp," and you want to share it with your development team.
- You compile your Java code into JAR files, and you can tag them with version numbers like "v1.0" and "v2.0. "
- You push these JAR files (Docker images) to a Docker Registry, which can be public (like Docker Hub) or private (hosted on your company's servers).
- Inside the Docker Registry, you create a Docker Repository named "my-java-app" to group your project's different versions (tags) together.
- Your team members can pull these JAR files (Docker images) from the Docker Registry using the repository name and version tag, like "my-java-app: v1.0" or "my-java-app:v2.0."

Docker Hub and Docker Registry:
Docker Hub:
- Docker Hub is a public repository provided by Docker itself for storing and sharing Docker images.
- It serves as a central, public location where Docker users can push their images for others to use.
- When you request a Docker image using a `docker pull` command, Docker first checks your local system for the image. If it's not found locally, Docker will download it from Docker Hub by default.
- Docker Hub is designed for public use, and anyone can access and pull images from it without restrictions.
Docker Registry:
- Docker Registry, on the other hand, is a more generic term that refers to the broader concept of a repository for storing Docker images. It can be either public or private.
- Docker provides an official image called `Registry` (e.g., `Registry: 2.0`) that allows you to set up your own private Docker image repository.
- With Docker Registry, you can create your own private repositories to store Docker images. You can customize it with certificates and run it as a Docker container.
- Access to images stored in a private Docker Registry is controlled through authentication and permissions, making it suitable for organizations that want to restrict access to their Docker images.
- Docker Registry can be used for both public and private scenarios, depending on how it's configured. It provides enhanced security as access is limited to authorized users within the organization.
While both Docker Hub and Docker Registry serve the purpose of storing Docker images, Docker Hub is a public repository for sharing images with the Docker community, while Docker Registry can be used to create private repositories with controlled access for organizations.
How Docker Works Under the Hood:
Docker's Speedy Start: Imagine Docker as a tool that lets you start applications in a snap. It's lightning fast compared to traditional virtual machines that can take ages to boot up. Docker relies on the Linux kernel to do this magic, but remember, it only works on Linux. So, if you're on a Mac, you'll need a small Linux virtual machine to use Docker.
Docker's Simulated Environments: Once you dig into the technical details, Docker becomes less mysterious. Instead of running various Linux distributions, Docker pretends to be them. It's like taking an Ubuntu system and customizing it to look like another Linux flavor, say Gentoo. In reality, they both rely on the same Linux kernel. Different Linux distributions are like outfits worn by the same person!
What's an Operating System: Think of an operating system as a referee at a game. It watches over programs (players) running on hardware (the playing field). The operating system makes sure everyone gets a fair turn, switching between tasks so quickly that it seems like everything is happening at once. It's like old-school computers that could only do one thing at a time but were excellent at juggling tasks.
Virtualization Basics: Now, let's talk about virtualizing a processor. Processors understand specific instructions based on their type (e.g., Intel vs. ARM). If you try to run an instruction meant for one type on another, it usually crashes. But processors can catch these errors and send them to a virtual machine manager (VMM). The VMM can then emulate the instruction correctly, allowing the program to continue smoothly.
Docker makes launching apps lightning-fast, simulates various environments, and virtualizes processors intelligently, all with the help of the Linux kernel. This simplifies development and deployment, making it a favorite among developers.
Types of Virtualizations: QEMU, Hardware-Assisted, and Paravirtualization
QEMU (Full Virtualization): QEMU, short for Quick Emulator, is a software-based approach to virtualization. It can emulate different CPUs through dynamic binary translation and work on unmodified host operating systems. However, it has a significant drawback: it's slow. Translating instructions between CPU architectures, like converting x86 instructions to ARM, introduces performance overhead.
Hardware-Assisted Virtualization (Intel Virtualization Technology): Modern CPUs, like Intel and AMD x86 processors, come with hardware support for virtualization. This technology allows operating systems to run in privileged mode to access drivers efficiently. The Linux kernel, for instance, has specific instructions for this privileged mode. The goal is to execute most calls natively and only send a small subset to the virtualization system. This hardware-assisted virtualization significantly improves performance and responsiveness.
Paravirtualization (Xen Hypervisor): Paravirtualization takes a unique approach. Applications often make privileged system calls that only the kernel should make, like network operations or file access. Paravirtualization, exemplified by the Xen hypervisor, uses a microkernel design and communicates with guest operating systems (e.g., Ubuntu or Debian Linux) through a "hypercall" rather than a traditional system call. This hypercall leverages an ABI (application binary interface) instead of an API. When an application in a virtualized environment requests a file operation, it becomes a hypercall sent to Xen, which then uses the driver to perform the file operation. It's like an operating system for operating systems, optimizing communication and resource management.
In summary, QEMU offers full virtualization but at the cost of speed. Hardware-assisted virtualization, found in recent Intel and AMD x86 CPUs, provides excellent performance improvements. Paravirtualization, seen in Xen, takes a unique approach to system calls, enhancing efficiency and isolation in virtualized environments. Each type of virtualization has its strengths and trade-offs.
Basics of Containerization:
Containerization is a lightweight form of virtualization that allows you to package and run applications and their dependencies in isolated environments called containers. These containers are self-sufficient and can run consistently across various computing environments, such as development, testing, and production. Here's a breakdown of containerization:
- Isolation: Containers provide a way to isolate applications and their dependencies from the underlying host system and other containers. This isolation ensures that an application in one container does not interfere with or affect applications in other containers.
- Consistency: Containers encapsulate an application and everything it needs to run, including libraries, runtime environments, and configuration files. This ensures that an application runs consistently, regardless of where it's deployed.
- Efficiency: Containerization is lightweight compared to traditional virtualization. Containers share the same operating system kernel as the host, which reduces overhead and makes them more resource-efficient. This efficiency allows you to run many containers on a single host.
- Rapid Deployment: Containers can be started and stopped quickly, making them ideal for microservices architectures and DevOps practices. You can deploy new versions of applications or scale them up and down rapidly.
- Ecosystem: Containerization has a robust ecosystem of tools and platforms, with Docker being one of the most popular containerization platforms. Container orchestration tools like Kubernetes help manage and scale containers in production environments.
- Security: Containers provide a level of isolation, but they should still be managed securely. Security practices such as image scanning, network segmentation, and role-based access control are essential for containerized applications.
Containerization allows you to package applications and their dependencies into lightweight, portable, and isolated containers. This technology has revolutionized software development and deployment by improving consistency, portability, efficiency, and scalability while facilitating modern development practices like microservices and continuous integration/continuous deployment (CI/CD). Let’s take couple of Analogy to understand further, Imagine you're preparing lunch for work every day, and you have two options: a lunchbox or a full kitchen.
Lunchbox (Container):
- In this scenario, your lunchbox represents a container. It's a compact, self-contained box where you can pack your meal and all the necessary items like utensils, napkins, and condiments.
- Each day, you prepare a fresh lunch in your lunchbox. You put your sandwich, salad, and fruit inside, along with everything you need to enjoy your meal.
- The beauty of the lunchbox is that it's isolated from the rest of the office fridge. Your lunch doesn't mix with your coworker's lunch, and you don't need to worry about someone else accidentally taking your food.
- Your lunch is consistent and ready to eat wherever you go-no matter if you're at your desk, in the cafeteria, or outside.
- You can easily swap your lunchbox with a colleague's lunchbox, and they can enjoy your meal without any issues because everything they need is already inside the lunchbox.
Full Kitchen (Traditional Environment):
- On the other hand, the full kitchen represents a traditional computing environment. It's like having access to a complete kitchen with all the appliances, ingredients, and utensils.
- When you prepare lunch in a full kitchen, you have to use various shared resources. You might need to find a pot or pan, grab ingredients from the fridge, and make sure you don't accidentally use someone else's ingredients.
- The kitchen is a shared space, so you need to be careful not to interfere with others who are also trying to cook their meals. It's less isolated and can sometimes lead to conflicts or inefficiencies.
- If you want to enjoy your lunch elsewhere, you need to pack everything separately, including your utensils, plates, and food, and then carry it to your desired location.

Applying the Analogy to Containerization:
- The lunchbox is like a container in containerization technology (e.g., Docker). It encapsulates an application and all its dependencies (libraries, configurations, etc.) in an isolated, portable unit.
- Containers ensure that your application runs consistently, just like your lunch is always ready to eat, no matter where you are.
- They provide efficient resource usage, allowing you to run many containers (applications) on a single host (computer), just as you can store many lunchboxes in the office fridge.
- Containers are easy to share and deploy, similar to how you can swap lunchboxes with colleagues. They're also highly portable, like carrying your lunch to different locations.

Union File System in Docker:
Docker employs a union file system to construct and layer Docker images. This means that all images are constructed on top of a foundational image, and subsequent actions are added to that base image. For example, running the command `RUN apt install curl` creates a new image. Under the hood, the union file system enables the transparent overlay of files and directories from separate file systems, referred to as branches, to create a unified and coherent file system. When the contents of these branches overlap in the same directory, they are merged into a single view of that directory.
When building an image, Docker stores these branches in its cache. A notable advantage is that if Docker detects a command that would create a branch or layer already present in the cache, it reuses the existing branch rather than re-executing the command. This mechanism is known as Docker layer caching.
libcontainer/runC:
The underlying functionality of Docker is provided by a C library called libcontainer, which is now known as runC. For every execution, each container is assigned its own root file system, typically located at `/tmp/docker/[uuid]/`. The host system restricts the container's processes to remain within this directory, creating what's called a "chroot jail." When an operating system starts a process, one of the process variables is the current working directory. A chroot jail confines the process to prevent it from accessing parent directories like `../`.

In summary, Docker uses a union file system for efficient image construction and layering, with the ability to cache layers for faster image building. The libcontainer/runC library ensures that containers operate within isolated, restricted environments to enhance security and isolation.
Docker Daemon: The Docker daemon, often referred to as `dockerd`, is a crucial component of the Docker platform. It is a background service that runs on a host machine and is responsible for managing Docker containers. Here's a detailed explanation of what the Docker daemon is and what it does:


- Background Service: The Docker daemon operates as a long-running process in the background of a host machine. It starts automatically when the host system boots up and continues to run until the system is shut down.
- Container Management: The primary function of the Docker daemon is to create, manage, and monitor Docker containers. Containers are lightweight, isolated environments that package applications and their dependencies, making it easy to deploy and run them consistently across different environments.
- API Server: The Docker daemon exposes a REST API that allows users and client tools to interact with Docker. Users can send commands and requests to the Docker daemon via the API, and it will carry out these instructions.
- Resource Management: The Docker daemon is responsible for managing system resources such as CPU, memory, and storage for containers. It allocates resources to containers based on user-defined limits and constraints.
- Image Handling: Docker images, which serve as the blueprints for containers, are also managed by the Docker daemon. It can pull images from container registries, store them locally, and use them to create containers.
- Networking: Docker containers often require network connectivity to communicate with each other or external services. The Docker daemon manages container networking, including the assignment of IP addresses and port mapping.
- Security: Security is a critical aspect of containerization. The Docker daemon enforces isolation between containers and the host system, ensuring that containers cannot access or interfere with each other or the host OS.
- Logging and Monitoring: Docker containers generate logs and performance metrics. The Docker daemon collects and manages these logs, making them available for monitoring and troubleshooting purposes.
- Plugin Support: Docker is extensible through plugins, and the Docker daemon supports various plugins for storage drivers, networking, and other functionalities. This extensibility allows users to customize and extend Docker's capabilities.
- Compatibility: The Docker daemon is compatible with various operating systems, including Linux, Windows, and macOS. It provides a consistent interface for working with containers regardless of the host OS.
- Container Orchestration: In container orchestration platforms like Kubernetes and Docker Swarm, the Docker daemon plays a role in coordinating the deployment and scaling of containerized applications.
The Docker daemon is the core component of Docker that manages the complete container lifecycle, from image management and resource allocation to container creation and execution. It provides an interface for users and client tools to interact with Docker, enabling the seamless deployment and management of containerized applications.
Docker Engine:
Docker Engine is the software component responsible for running and managing Docker containers. It is sometimes referred to simply as "Docker." Docker Engine is an essential part of the Docker ecosystem and plays a central role in containerization. Here's a detailed explanation of Docker Engine:


- Core Component: Docker Engine is the core software component of the Docker platform. It provides all the necessary tools and services to create, run, and manage containers on a host system.
- Client-Server Architecture: Docker Engine follows a client-server architecture. It consists of two main parts: the Docker daemon (server) and the Docker CLI (client). The Docker daemon runs as a background service on the host machine and listens for requests from the Docker CLI.
- Docker CLI (Client): The Docker Command-Line Interface (CLI) is the user interface used to interact with Docker Engine. Users issue commands through the CLI to manage containers, images, networks, and other Docker resources.
- Docker Daemon (Server): The Docker daemon, also known as `dockerd`, is a long-running background process that performs container-related tasks. It is responsible for creating and managing containers based on user commands received from the CLI.
- Container Lifecycle: Docker Engine handles the entire container lifecycle, including building containers from images, starting and stopping containers, monitoring container health, and removing containers when they are no longer needed.
- Image Management: Docker Engine manages Docker images, which serve as the templates for creating containers. It can pull images from Docker registries, store them locally, and use them to create containers.
- Resource Isolation: Docker Engine ensures that containers are isolated from each other and from the host system. Containers share the host OS kernel but have their own isolated filesystems and processes.
- Networking: Docker Engine manages container networking, allowing containers to communicate with each other or external services. It handles the assignment of IP addresses, port mapping, and network configurations.
- Resource Allocation: Docker Engine allocates system resources such as CPU and memory to containers based on user-defined limits and constraints. This ensures fair resource distribution among containers.
- Security: Security is a top priority for Docker Engine. It enforces security mechanisms to prevent unauthorized access and ensures that containers run in a controlled and secure environment.
- Compatibility: Docker Engine is compatible with various operating systems, including Linux, Windows, and macOS. It provides a consistent interface for working with containers across different platforms.
- Plugin Support: Docker Engine supports plugins for extending its functionality. Users can add plugins for storage drivers, networking, and other features to customize Docker for specific use cases.
- Orchestration Integration: Docker Engine can be integrated with container orchestration platforms like Kubernetes, Docker Swarm, and others to manage the deployment and scaling of containerized applications in a clustered environment.
Docker Engine is the heart of the Docker platform, responsible for container management, image handling, resource allocation, and other key containerization tasks. It provides a user-friendly interface through the Docker CLI while running the Docker daemon as a background service to execute container-related operations. As mentioned before Docker Engine is a core of a Docker platform which acts as a lightweight runtime that runs Docker containers.
Basics of Docker Host:
Docker host refers to the physical or virtual machine where the Docker daemon is installed and actively running. The Docker daemon, often referred to as `dockerd`, is a crucial component of the Docker platform. Here's a more detailed explanation:
- Machine Running Docker Daemon: The Docker host is essentially the computer or server on which you've installed Docker. This can be a physical machine (e.g., a server in a data center) or a virtual machine (e.g. , a VM on a cloud provider's infrastructure). The Docker daemon runs as a background service on this machine.
- Docker Daemon Functionality: The Docker daemon is responsible for managing and overseeing Docker containers and their interactions with the host's operating system. It serves as the central control point for Docker-related operations.
- Isolation of Containers: Docker containers are designed to run in isolated environments. This isolation ensures that each container operates independently and doesn't interfere with other containers or the host system. The Docker daemon handles the creation, execution, and management of these isolated containers.
- Resource Allocation: One of the important tasks of the Docker daemon is managing system resources such as CPU, memory, and storage. It allocates and enforces resource limits for containers, ensuring fair and efficient resource utilization.
- Communication: Containers running on the same Docker host can communicate with each other, and they can also interact with the host's file system and network. The Docker daemon facilitates these interactions while maintaining the isolation of each container.
- Portability: Docker containers are highly portable. You can create a container on one Docker host and then transfer and run it on another Docker host, as long as the target host supports Docker. This portability is a key advantage of containerization.
- Supported Platforms: Docker is compatible with various operating systems, including Linux, Windows, and macOS. Regardless of the underlying host operating system, the Docker daemon ensures consistent container behavior.
- Application Deployment: Docker hosts are commonly used to deploy and manage containerized applications. These applications consist of one or more Docker containers, and they can be easily scaled up or down to meet changing demands.
- Cloud Environments: In cloud computing environments, Docker hosts can be virtual machines provisioned in the cloud. Many cloud providers offer Docker-specific services to simplify the deployment and management of Docker hosts and containerized applications.
The Docker host serves as the foundation for running Docker containers. It hosts the Docker daemon, which handles container management, resource allocation, and communication between containers and the host system. Docker containers are designed to be portable and can run consistently across different Docker hosts, making them a powerful tool for application development and deployment.
Docker Client and Docker Daemon/Engine:
Docker Client: The Docker Client is a command-line utility that serves as our interface to interact with Docker. When we run Docker commands like `docker run`, `docker images`, or `docker ps`, we are using the Docker Client. It provides a user-friendly way to communicate with the Docker system, allowing us to issue commands that are easy to understand for humans.
Docker Daemon/Engine: The Docker Daemon, also known as the Docker Engine, is the behind-the-scenes component responsible for performing the core tasks of Docker. It is the part of Docker that performs the "magic" and manages container operations. The Docker Daemon knows how to communicate with the kernel of the host operating system, making system calls to create, operate, and manage containers. This complex interaction with the system's kernel is something users of Docker typically don't need to concern themselves with. The Docker Daemon takes care of these low-level operations, ensuring that containers run smoothly and efficiently.
Docker Host, Guest Operating System and Host Operating System:
Docker Host, Guest Operating System, and Host Operating System are not the same thing and they refer to different components in the context of containerization. Let's clarify our concepts for each of these terms:
Docker Host (Host Machine):
- The Docker Host, also known as the Host Machine or Host OS, refers to the physical or virtual server where Docker is installed and where containers are created and run.
- It is the underlying operating system environment on which Docker Engine operates.
- The Docker Host provides the necessary resources, such as CPU, memory, and storage, for running Docker containers.
- Multiple containers can run concurrently on the same Docker Host, each isolated from one another.
Guest Operating System (Container OS):
- The Guest Operating System, also referred to as the Container OS, is the operating system that runs within a Docker container.
- Containers are designed to be lightweight and portable, so they do not include a full operating system. Instead, they share the host machine's kernel (the core part of the operating system).
- The Guest OS typically includes only the necessary components and libraries required to run the application or service packaged within the container.
- Containers running on the same Docker Host can have different Guest OS distributions or versions.
Host Operating System (Host OS):
- The Host Operating System, or simply Host OS, is the operating system that runs directly on the physical hardware or virtual machine.
- It is the operating system that provides the foundational services and resources for all software running on the Docker Host.
- Docker containers, which run as isolated processes, share the same kernel as the Host OS. However, they have separate filesystems and user spaces.
- The choice of the Host OS is independent of the Guest OS used within containers.
In summary, the Docker Host (Host Machine) is where Docker Engine is installed and manages containers. Containers run with their own Guest Operating System (Container OS) but share the same Host Operating System (Host OS) kernel. The Host OS is the foundation for both Docker and the containers it hosts, while the Guest OS inside containers is specific to each containerized application or service.
Also not that, the Host Operating System and Docker Host are not the same thing. They are related components in the context of containerization, but they refer to different aspects of the system.
Host Operating System (Host OS): The Host Operating System is the operating system that runs directly on the physical hardware or virtual machine. It provides the foundational services and resources for all software running on the system, including Docker. The Host OS is responsible for managing hardware resources such as CPU, memory, and storage. It is independent of Docker and existed before Docker was installed.
Docker Host (Host Machine): The Docker Host, also known as the Host Machine, is the system (physical or virtual) where Docker is installed and where Docker containers are created and managed. It is the environment where Docker Engine operates. While it relies on the Host Operating System for hardware management, it also includes the Docker runtime and tools necessary to run containers. Docker Host refers to the specific machine configured to run Docker containers.
Let’s further describe layered setup as below.
- Base Host Operating System: This is the underlying operating system that runs directly on the physical hardware or the virtualized hardware if you're using a hypervisor.
- Hypervisor: The hypervisor is a virtualization layer that allows you to run multiple virtual machines (VMs) on a single physical machine. Each VM is essentially a self-contained environment with its own operating system.
- Virtual Machines (VMs): These are instances of guest operating systems running on top of the hypervisor. Each VM can have its own guest operating system, which can be different from the base host operating system.
- Docker Host: The Docker Host, also known as the Host Machine or Docker Server, is a physical or virtual machine where Docker is installed. It provides the environment for running Docker containers. It uses the host operating system's kernel but isolates containers from each other.
- Docker Containers: Within each Docker Host, you can create multiple Docker containers. Docker containers share the same kernel as the Docker Host and do not contain a full guest operating system. Instead, they package the application code, runtime, libraries, and dependencies needed to run the application.
- The base host operating system runs directly on the physical hardware.
- The hypervisor enables the creation of multiple VMs, each with its own guest operating system.
- Docker Hosts are machines where Docker is installed and used for running containers.
- Docker containers share the host operating system's kernel and don't contain a full guest operating system; they package application code and dependencies. Docker containers do not typically include a full guest OS but share the kernel of the Docker Host.
Docker Mounting:
Docker, "mounting" refers to the process of attaching a directory from the Docker host (your local machine or server) into a Docker container. This allows data and files from the host system to be accessible and shared with the container. It's a way to provide data persistence and share files between the host and the container.
When you mount a directory into a Docker container, any changes made to the files within that directory from either the host or the container are reflected in both places. This can be especially useful for scenarios such as:
- Sharing Configuration Files: You can mount configuration files or directories from the host into a container, allowing you to configure containerized applications without modifying the container itself.
- Data Persistence: Mounting directories for data storage ensures that data generated or modified within the container is retained on the host even if the container is stopped or removed.
- Development Workflow: Developers often use mounting to map their source code from their local development environment into a container, enabling them to test and debug code changes in real time.
Here's an example of how you might use mounting in a Docker command:


In this command:
- -v specifies that you're creating a volume (mount).
- /path/on/host is the path to the directory on the host machine.
- /path/in/container is the path inside the container where the mounted directory will be accessible.
- my-image is the Docker image you're running.
This command would attach the host directory to the container at the specified path, allowing both the host and the container to read and write files in that directory.
Basics of Volume:
In Docker, a "volume" is a mechanism for persistently storing data generated by and used by Docker containers. Volumes are used to manage and share data between a Docker host and its containers. They are crucial for ensuring that data is preserved and can be easily accessed across container instances, even if the containers themselves are stopped or removed.


- Data Persistence: Containers in Docker are designed to be lightweight and ephemeral, meaning they can be easily created and destroyed. However, this can pose a challenge when you need to store and manage data, such as application logs, databases, or user uploads, that should persist even when containers are removed.
- Volume Types: Docker provides various types of volumes, including host-mounted volumes, named volumes, and anonymous volumes. Each type has its use case.
- Host-Mounted Volumes: Host-mounted volumes allow you to mount a directory from the Docker host's file system into a container. This means that the data in the mounted directory is accessible to both the container and the host. It's a straightforward way to share files or data.
- Named Volumes: Named volumes are managed by Docker and are not directly tied to the host's file system. Docker creates a named volume and manages its storage. Containers can then use these volumes to read and write data. Named volumes are often preferred for their ease of use and portability.
- Anonymous Volumes: Anonymous volumes are similar to named volumes, but Docker generates a unique identifier for them. These volumes are typically used for temporary or internal data storage within containers.
Use Cases:
- Volumes are commonly used for various purposes, such as:
- Storing application configuration files.
- Managing database data so that it persists across container restarts.
- Sharing log files with log analysis tools.
- Storing user uploads or other user-generated content.
- Ensuring data durability and portability in clustered or orchestrated container environments.
Benefits:
- Volumes provide data persistence, even if containers are removed or replaced.
- They enable data sharing between multiple containers or services.
- Volumes are isolated, secure, and efficient for handling data.
- They simplify backup and restore procedures for containerized applications.
Volumes in Docker are essential for managing and persisting data in containerized applications. They ensure that data remains available, shareable, and durable, making them a critical component of container orchestration and application deployment.
Docker Volume vs Bind Mounts vs tmpfs mount:
In Docker, there are several ways to manage and share data between containers and the host system. The three primary methods are Docker Volumes, Bind Mounts, and tmpfs Mounts. Each has its use cases and characteristics:
Docker Volumes:


- Docker volumes are a way to persist data outside of a container.
- They are managed by Docker and stored in a specific location on the host.
- Volumes can be easily shared among multiple containers, making them suitable for data that needs to be accessed by multiple services.
- Docker volumes are the recommended way to handle data that should persist even if containers are removed or recreated.


Bind Mounts:


- Bind mounts allow you to mount a directory from the host into the container.
- They are useful for sharing code or configuration files between the host and the container.
- Unlike volumes, bind mounts are not managed by Docker, and the data is directly accessible from the host filesystem.
- Changes made in the container are immediately reflected on the host, and vice versa.

tmpfs Mounts:


- tmpfs mounts are used to create an in-memory filesystem that exists only for the duration of a container's lifetime.
- They are ideal for cases where you want to store temporary or sensitive data that doesn't need to persist after the container stops.
- tmpfs mounts can be used to improve performance by storing temporary data in memory instead of writing to disk.
Choosing the right method depends on your specific use case:
- Use Docker volumes for persistent data that should survive container restarts or removals.
- Use bind mounts when you need to share files between the host and the container and want changes to be immediately reflected on both sides.
- Use tmpfs mounts for temporary or cache data that can be stored in memory for improved performance.
Each method provides flexibility and can be combined to meet the data management needs of your Docker containers.

Docker Toolbox:
Docker Toolbox was a legacy solution provided by Docker, Inc. for running Docker on older versions of Windows and macOS that did not support Docker natively. It was particularly useful for users who had Windows 7 or macOS versions earlier than macOS Catalina (10.15), as these operating systems lacked the required components for running Docker containers directly.
Docker Toolbox included the following components:
- Docker Machine: Docker Machine was a tool for creating and managing Docker hosts on virtual machines (VMs). It allowed users to create and manage VMs with Docker Engine installed.
- Docker Engine: Docker Engine is the core component of Docker that enables the creation and management of containers. Docker Toolbox included an older version of Docker Engine that was compatible with the older operating systems.
- Docker Compose: Docker Compose was included in Docker Toolbox, enabling users to define and run multi-container applications using a YAML file.
- Kitematic: Kitematic was a graphical user interface (GUI) tool that simplified the management of Docker containers and images.
- Oracle VirtualBox: Docker Toolbox used Oracle VirtualBox as the virtualization platform to create and manage VMs running Docker.
Please note that Docker Toolbox has been deprecated and is no longer recommended for use. As of my last knowledge update in September 2021, Docker Desktop for Windows and Docker Desktop for Mac became the preferred solutions for running Docker on Windows and macOS, respectively. Docker Desktop provided a more integrated and user-friendly experience for Docker users on these platforms.
If you're running a newer version of Windows or macOS, it's advisable to use Docker Desktop. However, if you have specific requirements or are using older operating systems, you may need to explore alternative solutions or consider upgrading your operating system to a version that supports Docker natively.

Unikernels in Docker:
To understand the future of Docker, we should consider the current landscape. Much of the Internet operates within AWS data centers, utilizing virtual machines known as EC2 (Elastic Compute Cloud). These EC2 machines often run Docker containers, which serve as the foundation for many web services and applications we use daily. However, this setup involves multiple middleware layers before an application can access the physical processor.
The concept behind unikernels is to simplify this structure by removing unnecessary components from the kernel and software stack. Traditional operating systems are designed to be generic and versatile, capable of performing various tasks. Unikernels, on the other hand, are tailored to run a specific application with only the essential kernel modules and drivers needed for that application. For instance, if an application doesn't require network functionality, unikernels exclude network drivers and related kernel code.
Around few years ago, Docker made an interesting move by acquiring a company called Unikernel Systems. This acquisition hinted at Docker's ambition to explore and potentially implement the concept of unikernels. Docker's overarching goal has always been to provide high-quality tools and documentation for software development on their platform.
One of Docker's notable advantages lies in its ability to offer user-friendly virtualization without a significant performance overhead, as it doesn't rely on traditional virtualization technologies. Now, Docker seems to be pushing the boundaries further by aiming to make applications developed within Docker run even faster than they would on their native operating systems. This approach seeks to combine Docker's developer-friendly tools with performance optimization, potentially leading to enhanced application execution within Docker containers.

Docker Compose: Simplifying Multi-Container Applications
Docker Compose is a tool for defining and running multi-container Docker applications. It allows you to define a multi-container environment using a simple, declarative YAML file, making it easier to manage complex applications and their dependencies. With Docker Compose, you can define, configure, and run multiple containers as a single application stack.
Here's a detailed explanation of Docker Compose:
- Multi-Container Applications: Docker Compose is particularly useful when you have applications that require multiple containers to work together. For example, a web application might need a web server, a database server, and a cache server, each running in its own container. Docker Compose simplifies the orchestration of these containers.
- Declarative YAML File: Docker Compose uses a YAML file (usually named `docker-compose.yml`) to define the configuration of your application stack. In this file, you specify the services, networks, volumes, and their configurations. This declarative approach makes it easy to understand and manage your application's structure.
- Service Definitions: You define the services that make up your application stack within the YAML file. Each service corresponds to a container. You can specify various settings for each service, such as which Docker image to use, environment variables, ports to expose, and links to other services.
- Networking: Docker Compose creates a default network for your application stack, allowing containers defined within the same Compose file to communicate with each other using service names as hostnames. You can also define custom networks if needed.
- Volumes: Docker Compose allows you to specify volumes for persisting data or sharing files between containers. This is especially useful for databases or applications that require shared storage.
- Orchestration: Once you've defined your multi-container environment in the YAML file, you can use Docker Compose commands to orchestrate the containers. Common commands include `docker-compose up` (to start the services), `docker-compose down` (to stop and remove the containers), and `docker-compose logs` (to view container logs).
- Portability: Docker Compose files are portable and can be shared across different environments and systems. This makes it easy to reproduce your application stack on different servers or development machines.
- Environment Variables and Secrets: You can define environment variables directly in the Compose file or load them from external `. env` files. This allows you to manage configuration separately from the Compose file.
- Scaling: Docker Compose supports scaling services, meaning you can run multiple instances of a service with a single command. For example, if you have a web application, you can scale the web service to run multiple containers behind a load balancer.
- Integration with Other Tools: Docker Compose can be used in conjunction with other tools, such as Docker Swarm or Kubernetes, for orchestration and scaling in larger environments.
Docker Compose simplifies the management of multi-container applications by providing a clear and structured way to define, configure, and run containers as a single application stack. It's a valuable tool for both development and production environments, streamlining the process of working with complex containerized applications.
Let’s Consider a Scenario: Imagine you have a food court with different food vendors, and each vendor specializes in a specific type of dish. You want to organize a meal where you can enjoy a burger, fries, and a milkshake from different vendors, but you want everything to arrive together so you can enjoy your meal.
- Docker Containers as Food Vendors: In the food court, each food vendor is like a Docker container. They specialize in preparing a specific type of food (e.g., burgers, fries, milkshakes), just like Docker containers focus on running specific parts of your application (e.g., web server, database, caching).
- Docker Compose as Your Meal Order: Docker Compose is like your meal order at the food court. You create a list specifying what items you want (e.g., burger from vendor A, fries from vendor B, milkshake from vendor C). Similarly, in a Docker Compose file (the order), you specify which containers (food vendors) you want to run together as part of your application stack.
- YAML Configuration as Your Order Details: Your meal order details (e.g., "I want a double cheeseburger with extra pickles") are similar to the YAML configuration in a Docker Compose file. You specify how each container should be configured, what image to use (vendor's specialty), and any additional settings (like ports to expose).
- Docker Network as Food Court Tables: Docker sets up a virtual network, like the tables in the food court. All the containers (food vendors) can communicate with each other on this network, just as you can easily move between food court tables to enjoy your meal.
- Docker Volume as Sharing Napkins: If you need to share something (like napkins) between your meal items, think of Docker volumes. It's like having a shared resource (napkins) between containers.
- Docker Compose Commands as Meal Instructions: Finally, you use Docker Compose commands like `docker-compose up` (start the meal), `docker-compose down` (finish the meal), and `docker-compose logs` (check the meal's quality) to orchestrate your meal experience.
So, in this analogy, Docker Compose helps you order and enjoy a coordinated meal experience from different food vendors (containers) in the food court (Docker environment), ensuring everything arrives together and is well-organized.
Reiterate: Docker Image vs. Docker Container:
Docker Host:
- Think of the Docker host as the big, powerful computer that's in charge of running your applications (containers).
- It's like the stage where actors perform in a theater.
- The Docker host manages all the resources, like CPU, memory, and storage.
- It's responsible for making sure the containers run smoothly, just like a theater director ensures the play goes well.
- You can have multiple Docker hosts, like multiple stages in different theaters.
Docker Container:
- Now, think of a Docker container as a small, self-contained, and portable package.
- It's like an actor in a play, ready to perform its role.
- Each container has everything it needs inside it: the application, its tools, and dependencies.
- It runs independently, like an actor on stage, without interfering with other containers.
- Containers can be moved from one Docker host to another, like moving an actor from one stage to a different theater.
- They are like little worlds that don't affect the big theater (Docker host) they perform in.
The Docker host is like the theater where everything happens, managing resources and coordination. Docker containers are like actors, each with their own role and props, ready to perform on the Docker host's stage. The host takes care of everything to make sure the show runs smoothly.
Question: Why does Docker need a daemon?
Answer: Docker needs a daemon for two main reasons:
- Resource Management: The daemon acts like a manager for Docker containers. It keeps track of resources like CPU, memory, and storage. When you want to run a container, the daemon ensures it gets the right amount of resources.
- Simplified Usage: Having a daemon means you don't need to worry about starting and managing the Docker engine every time you want to use Docker. The daemon is always running in the background, ready to handle your container requests.
Imagine you're running a restaurant, and Docker is like a chef who cooks various dishes (containers). The Docker daemon is your restaurant manager. It makes sure the chef (Docker) has all the ingredients (resources) needed for cooking, and it keeps the kitchen running smoothly. This way, you, as the owner (user), can simply order dishes without having to hire and manage the chef every time.
Question: Docker Cloud vs. Docker Hub: What's the Difference in Simple Terms?
Answer: Docker Hub is like a big storehouse for containerized apps. It's where you find all sorts of pre-made containers ready to use, like apps for your computer. You can also keep your own secret stash of containers in there.
Docker Cloud, on the other hand, is like a control center for your containers. It helps you manage and organize your containers, making it easy to build, test, and use them. It even takes care of grouping containers together and makes sure they work well.
Docker Hub is where you find containers, and Docker Cloud is how you organize and use them, like a container superhero headquarters!
Docker Swarm: Making Containers Work Together Easily.
Imagine you have a bunch of small worker bees (containers) in your garden (computer). They each have a job to do, like collecting nectar (processing data). But you need a way to coordinate them all efficiently.
Docker Swarm is like the queen bee that organizes everything. It's a tool that helps you manage a group of containers (the bee swarm) and makes sure they work together harmoniously.
With Docker Swarm, you can:
- Create a Swarm: Think of this as forming your bee colony. You tell Swarm which computers (nodes) are part of the swarm.
- Deploy Services: Services are like tasks for your bees. You can tell Swarm what work each container needs to do.
- Load Balancing: Swarm ensures that tasks are spread evenly across your containers, like bees sharing the workload.
- Scalability: When you need more worker bees (containers) because your garden (workload) is getting bigger, Swarm can quickly add new ones.
- Resilience: If a bee (container) gets tired or sick, Swarm can replace it with a healthy one so that the work continues without interruption.
In a nutshell, Docker Swarm makes it easy to manage and scale your containers, just like a skilled beekeeper tending to their hive.
Top of Mind Questions and Answer for Docker Technology:
Question: How Containers Work?
Answer: In a containerized environment, the host operating system controls each container’s access to computing resources (i.e. , storage, memory, CPU) to ensure that no container consumes all the host’s resources.
A container image file is a static, complete, executable version of a service or application. Different technologies use different image types. A Docker image comprises several layers starting with the base image that contains the necessary dependencies to execute the container’s code. It has static layers topped with a readable and writable layer. Every container has a specific, customized container layer, so the underlying image layers are reusable—developers can save and apply them to other containers.
A container engine executes the container images. Most organizations use container orchestration or scheduling solutions like Kubernetes to manage their container deployments. Containers are highly portable because every image contains the dependencies required to execute the code stored in the appropriate container.
The main advantage of containerization is that users can execute a container image on a cloud instance for testing and then deploy it on an on-premises production server. The application performs correctly in both environments without requiring changes to the code within a container.
Question: What Is a Container Image?
Answer: A container image is a static immutable file with instructions that specify how a container should run and what should run inside it. An image contains executable code that enables containers to run as isolated processes on IT infrastructure. It consists of platform settings, such as system libraries and tools, that enable software programs to run on a containerization platform like Docker.

Container images are compiled from file system layers built onto a base or parent image. The term base image usually refers to a new image with basic infrastructure components, to which developers can add their own custom components. Compiling a container image using layers enables you to reuse components rather than creating each image from scratch.
Question: What Is Docker?
Answer: Docker is an open-source platform for creating, deploying, and managing virtualized application containers. It provides an ecosystem of tools that provide various capabilities to package, provision, and run containers.
Docker utilizes a client-server architecture. Here is how it works:
- The daemon deploys containers—a Docker client talks to a daemon that builds, runs and distributes Docker containers.
- Clients and daemons can share resources—a Docker daemon and client can run on the same system. Alternatively, you can connect the client to a remote daemon.
- Clients and daemons communicate via APIs—A Docker daemon and client can communicate via a REST API over a network interface or UNIX sockets.
Question: What Are Windows Containers?
Answer: In the past, Docker Toolbox, a variant of Docker for Windows, used to run a VirtualBox instance with a Linux operating system on top of it. It allowed Windows developers to test containers before deploying them on production Linux servers.
Recently, Microsoft adopted container technology, enabling containers to run natively on Windows 10 and Windows Server. Microsoft and Docker worked together to build a native Docker for Windows variant. Kubernetes and Docker Swarm shortly followed.
It is now possible to create and run native Windows and Linux containers on Windows 10 devices. You can also deploy and orchestrate these on Windows servers or Linux servers if you use Linux containers.
Question: What Is Windows Subsystem for Linux?
Answer: The Windows Subsystem for Linux (WSL) lets you run a Linux file system, Linux command-line tools, and GUI applications directly on Windows. WSL is a feature of the Windows operating system that enables you to use Linux with the traditional Windows desktop and applications.
Here are common WSL use cases:
- Use Bash, Linux-first frameworks like Ruby and Python, and common Linux tools like sed and awk alongside Windows productivity tools.
- Run Linux in a Bash shell with various distributions, such as Ubuntu, OpenSUSE, Debian, Kali, and Alpine. It enables you to use Bash while running command-line Linux tools and applications.
- Use Windows applications and Linux command-line tools on the same set of files.
- WSL requires less CPU, memory, and storage resources than a VM. Developers use WSL to deploy to Linux server environments or work on open-source web development projects.

Question: What are Container Runtimes?
Answer: Containers are lightweight virtual, isolated entities that include dependencies. They require a container runtime (which typically comes with the container engine) that can unpack the container image file and translate it into a process that can run on a computer.
You can find various types of available container runtimes. Ideally, you should choose the runtime compatible with the container engine of your choice. Here are key container runtimes to consider:
- containerd—this container runtime manages the container lifecycle on a host, which can be a physical or virtual machine (VM). containerd is a daemon process that can create, start, stop, and destroy containers. It can also pull container images from registries, enable networking for a container, and mount storage.
- LXC—this Linux container runtime consists of templates, tools, and language and library bindings. LXC is low-level, highly flexible, and covers all containment features supported by the upstream kernel.
- CRI-O—this is an implementation of the Kubernetes Container Runtime Interface (CRI) that enables you to use Open Container Initiative (OCI)-compatible runtimes. CRI-O offers a lightweight alternative to employing Docker as a runtime for Kubernetes. It lets Kubernetes use any OCI-compliant runtime as a container runtime for running pods. CRI-O supports Kata and runc containers as container runtimes, but you can plug any OCI-conformant runtime.
- Kata—a Kata container can improve the isolation and security of container workloads. It offers the benefits of using a hypervisor, including enhanced security, alongside container orchestration functionality provided by Kubernetes. Unlike the runC runtime, the Kata container runtime uses a hypervisor for isolation when spawning containers, creating lightweight VMs and putting containers inside.
The Open Container Initiative (OCI) is a standard that helps develop container runtimes that will support Kubernetes and other container orchestrators. It includes configurations, several file-system layers, and a manifest that specifies how a runtime should funtion. OCI also includes a standard specification for container images.
Question: What is the Difference between Containers and Virtual Machines?
Answer: A virtual machine (VM) is an environment created on a physical hardware system that acts as a virtual computer system with its own CPU, memory, network interfaces, and storage. It is a “guest operating system” running within the “host operating system” installed directly on the host machine.
Containerization and virtualization are similar in that applications can run in multiple environments. The main differences are size, portability, and the level of isolation:
VMs—Each VM has its own operating system, which can perform multiple resource-intensive functions at once. Because more resources are available on the VM, it can abstract, partition, clone, and emulate servers, operating systems, desktops, databases, and networks. A VM has strong isolation because it runs its own operating system.
Containers—runs specific package applications, their dependencies and the minimal execution environment they require. A container typically runs one or more applications, and does not attempt to emulate or replicate an entire server. A container has inherently weaker isolation because it shares the operating system kernel with other containers and processes.
Question: What is the relation between Containers and Kubernetes?
Answer: Containers and Kubernetes
Kubernetes is a container orchestration platform provided as open source software. It enables you to unify a cluster of machines as a single pool of computing resources. You can employ Kubernetes to organize applications into groups of containers. Kubernetes uses the Docker engine to run the containers, ensuring your application runs as intended.
Here are key features of Kubernetes:
- Compute scheduling—Kubernetes automatically considers the resource needs of containers to find a suitable place to run them.
- Self-healing—when a container crashes, Kubernetes creates a new one to replace it.
- Horizontal scaling—Kubernetes can observe CPU or custom metrics and add or remove instances according to actual needs.
- Volume management—Kubernetes can manage your application’s persistent storage.
- Service discovery and load balancing—Kubernetes can load balance IP addresses, multiple instances, and DNS.
- Automated rollouts and rollbacks—Kubernetes monitors the health of new instances during updates. The platform can automatically roll back to a previous version if a failure occurs.
- Secret and configuration management—Kubernetes can manage secrets and application configuration.
Containers serve as the foundation of modern, cloud native applications. Docker offers the tools needed to create container images easily, and Kubernetes provides a platform that runs everything.
Question: What are the best Practices for Building Container Images?
Answer: Use the following best practices when writing Dockerfiles to build images:
- Ephemeral—you should build containers as ephemeral entities that you can stop or delete at any moment. It enables you to replace a container with a new one from the Dockerfile with minimal configuration and setup.
- dockerignore—a .dockerignore file can help you reduce image size and build time. You achieve this by excluding any unnecessary files from the build context. By default the Docker image includes the recursive contents of a directory in which the Dockerfile resides, and .dockerignore lets you specify files that should not be included.
- Size—you should reduce image file sizes to minimize the attack surface. Use small base images such as Alpine Linux or distroless Linux images. However, you do need to keep Dockerfiles readable. You can apply a multi-stage build (available only for Docker 17.05 or higher) or a builder pattern.
- Multi-stage build—this build lets you use multiple FROM statements within a single Dockerfile. It enables you to selectively copy artifacts from one stage to another, leaving behind anything unneeded in the final image. You can use it to reduce image file sizes without maintaining separate Dockerfiles and custom scripts for a builder pattern.
- Packages—never install unnecessary packages when you build images.
- Commands—do not use multiple RUN commands. When possible, use multi-line commands for faster builds, for example, when you need to install a list of packages.
- Linters—use a linter to automatically catch errors in your Docker file and clean up your syntax and layout.
Question: What are the best Practices for Container Security?
Answer: Container security is a process that includes various steps. It covers container building, content and configuration assessment, runtime assessment, and risk analysis. Here are key security best practices for containers:
- Prefer slim containers—you can minimize the application’s attack surface by removing unnecessary components.
- Use only trusted base images—the CI/CD process should only include usable images that were previously scanned and tested for reliability.
- Harden the host operating system—you should use a script to configure the host properly according to CIS benchmarks. You can use a lightweight Linux distribution for hosting containers like CoreOS or Red Hat Enterprise Linux Atomic Host.
- Remove permission—you should never run a privileged container because it allows malicious users to take over the host system. It threatens your entire infrastructure.
- Manage secrets—a secret can include database credentials, SSL keys, encryption keys, or API keys. You must manage secrets to ensure it is impossible to discover them.
- Run source code tests—software composition analysis (SCA) and static application security testing (SAST) tools have evolved to support DevOps and automation. They are integral to container security, helping you track open source software, license restrictions, and code vulnerabilities.




ReadioBook.com