Innovative Software Technology-Въведение в Docker за Начинаещи: Пълно Ръководство на Български

This article aims to simplify some of the most powerful and intriguing technologies in software engineering, drawing from practical experience. While official documentation often exists, it can sometimes be overly complex, requiring multiple readings to grasp core concepts. The goal here is to present these topics in the most straightforward manner possible.

The first technology to be explored is Docker.

1. Understanding Docker: Streamlining Application Delivery

Docker is a transformative tool designed to simplify the packaging, distribution, and execution of software applications.

At its core, “packaging” with Docker means bundling an application with every single dependency it needs to run correctly. This complete package can then be easily shared and run by anyone with Docker installed, eliminating complex setup procedures. The user only needs Docker; everything else required by the application is “delivered” and managed through it.

In software development, applications move through phases like design, testing, maintenance, and deployment. Docker primarily optimizes the “deployment” phase but also significantly aids in development and even testing.

To put it another way, Docker effectively solves the classic developer’s lament: “It works on my machine!”

Modern applications are often complex, comprising numerous components: frontend, backend, databases, servers, libraries, and various dependencies. Getting such an application to run consistently across different environments—varying hardware, operating systems, or configurations—can be a monumental challenge. Docker mitigates this by making application execution consistent across different machines.

Imagine receiving deployment instructions that demand:

“First, install SQL Server (>1GB), configure it, create a database with this specific name, and set up an administrator user. If you’re on Windows, also install and configure X and Y components to ensure functionality. Then, install this server, start it, configure 100 other settings… and THEN it should work.”

A developer might grudgingly follow such a convoluted process, but a typical end-user would likely give up. The frustration peaks when, after meticulously following all instructions, errors still appear, and the software fails to launch as expected.

This scenario is common. For instance, a developer might painstakingly install a database like SQL Server, only to later discover the project includes a Docker configuration file that automates the entire setup, effortlessly pulling and running the necessary SQL Server instance. The initial manual setup becomes entirely redundant.

2. Deconstructing Docker: Images, Containers, and Workflows

To grasp Docker’s operational principles, consider a few analogies:

In logistics, the challenge of transporting diverse goods (varying in size, shape, and fragility) was revolutionized by shipping containers. Items are placed inside a standardized box, the box is transported universally (by air, sea, or land), and the recipient simply opens it to access the contents. Docker operates on a similar principle.

Think of vintage 8-bit game cartridges for consoles like NES. The cartridge itself contained everything needed for the game to run immediately when inserted into the console. You could lend it to a friend, and if they had the console, they could play without issues. Here, the cartridge is the “container,” and the console acts as Docker.

For Java developers, a JAR file serves as an apt comparison. It bundles all classes for a Java application. To run it, you only need Java (JRE) installed on your machine. The JAR file is the “container,” and Java (JRE) plays the role of Docker.

Finally, let’s look at Docker itself:

Within Docker, we have containers that encapsulate all necessary elements (components, libraries, servers, databases, etc.) for an application to function. Starting these containers immediately makes the application operational. Thus, an application can run anywhere Docker is installed.

The practical process unfolds as follows:

To run an application in a container, you first need to create a Docker “image.” An image is an immutable blueprint containing all the libraries, components, and configurations your application requires. These images can be stored in online registries like Docker Hub, from which you can “pull” and use them to create containers. Docker also supports version control for images, akin to Git, allowing for commits and updates.
To create an image, you write a file named ” Dockerfile” (without an extension). This simple text file outlines the step-by-step instructions for building your image. Docker then executes these instructions during a “build” process, resulting in a ready-to-use image.
Think of the Dockerfile as a RECIPE, and the image as the COOKED MEAL prepared by following that recipe.
Finally, you launch a Docker container from the image you’ve created. A container is a RUNNING INSTANCE of your image. When a container starts, your application becomes active and usable. Containers can also be stopped and restarted as needed.
In programming terms: if a Docker image is a CLASS, then a container is an INSTANCE of that class.

3. Docker’s Core Architecture: Containerization vs. Virtualization

At this point, you might wonder, “Is this just like a virtual machine?” or “Why not just use a VM?” To answer, we must delve into Docker’s internal structure and understand the distinctions between virtualization and containerization.

First, consider VIRTUALIZATION, as used in Virtual Machines (VMs):

There’s a Host OS (the operating system running on the physical hardware).
A Hypervisor acts as an emulator, allowing you to run multiple independent Virtual Machines, each with its own Guest OS.
When a VM runs, its Guest OS does not directly use the files or applications from the Host OS; it’s a completely isolated environment, including its own kernel.

Next, we have CONTAINERIZATION, which Docker employs:

The Host OS is the operating system on which containers are launched.
Instead of a Hypervisor and separate Guest OSes, a Container Engine (like Docker Engine) leverages the Host OS’s kernel to run applications (with their dependencies) within containers.

In VIRTUALIZATION, resources (disk space, memory) allocated to VMs are typically fixed, leading to significant overhead as each VM duplicates a full operating system.

In CONTAINERIZATION, resource allocation is dynamic and adapts to the application’s needs. Containers are lightweight and fast because they share the Host OS kernel, making Docker significantly more efficient for many application deployment scenarios.

It’s important to note that Docker is not a universal compatibility solution. For example, running a Windows application via Docker on a Linux host would still require a Windows virtual machine within which Docker can operate. Similarly, running Linux applications on Windows traditionally required a Linux VM, although modern solutions like WSL2 (Windows Subsystem for Linux 2) simplify this significantly by providing a lightweight Linux kernel directly on Windows.

A key advantage of containerization and Docker is “isolation.” Each application runs in its own container, preventing interference with other Docker applications/containers or the Host OS components. This means that even when a virtual machine is necessary (e.g., for cross-OS compatibility), you don’t need a separate VM for every single application.

Docker employs a client-server architecture. The client is the Docker CLI (Command Line Interface), while the server is known as the Docker Daemon. This Daemon receives instructions from the CLI, either as console commands or REST API requests. In the context of containerization, the “Container Engine” for Docker is the Docker Engine, which comprises both the CLI and the Daemon. Interestingly, the Docker client and server can reside on the same machine or on separate machines.

4. Expanding Docker Capabilities: Volumes, Compose, and Swarm

For many developers, understanding images, containers, and Docker’s fundamental architecture is sufficient. However, for those looking to deepen their expertise (or pursue a DevOps path), a few more advanced concepts can unlock the next level of Docker utilization: Docker Volumes, Docker Compose, and Docker Swarm Mode.

4.1. Docker Volumes

When creating Docker containers, they often handle data (e.g., a database container). This data is stored within a Virtual File System (VFS) inside the container itself.

However, if you delete the container, its data is also deleted, which is clearly undesirable for persistent data. Docker Volumes provide a robust solution to this problem.

Here’s how it works:

Your Host OS has its own Host File System (HFS), containing all folders and files on your computer.
You link a folder from the HFS to the container’s VFS (or “mount” the HFS folder into the VFS). Any file changes within the VFS are automatically mirrored to the HFS (and vice-versa).
This ensures your data remains available and usable, even if the container it was associated with is deleted.

Additionally, you can SHARE data between multiple containers by linking a single HFS folder to several containers.

In summary, Docker Volumes is a Docker feature used to detach data generated within a container from the container’s lifecycle and facilitate sharing that data with other containers.

Utilizing Docker Volumes typically involves specific Docker commands.

4.2. Docker Compose

As discussed, Docker allows us to run individual containers for application components. However, applications often consist of multiple interconnected containers (similar to microservices architectures, where small applications communicate to achieve a larger goal).

Docker Compose is a tool that simplifies the management and orchestration of multi-container applications.

It is also incredibly useful for setting up local development environments (as was the case in the project mentioned earlier).

Here’s how to use it:

Create a text file (using YAML syntax) named ” docker-compose.yml.”
Within this file, you define the “services” of your application using a specific syntax. You can think of these “services” as distinct parts of your application. For each service, you specify what needs to happen when the entire application starts.
Execute the command ” docker-compose up” to start your multi-container application (and ” docker-compose down” to stop it).

4.3. Docker Swarm Mode

The next level involves different Docker machines communicating with each other.

Docker Swarm Mode is a native Docker feature for managing a group of Docker-enabled machines (known as a “cluster”) that work together as a “swarm.”

It’s a container orchestration tool (similar to Kubernetes) designed for managing many containers at scale. It significantly simplifies large-scale container operations such as monitoring container health, performing updates, ensuring security, distributing resources, rolling back to previous versions, deployment, and scheduling.

Here’s how it operates:

Every swarm consists of ” nodes” (machines running Docker and participating in the cluster). There are two types:
- A) ” Manager node“: A machine that instructs “worker nodes” on what tasks to perform and monitors their progress. This machine governs the swarm.
- B) ” Worker nodes“: Machines that run application containers. They receive instructions from the manager node and report back on task status.
You submit ” services” to the manager node. These services are definitions of your desired state (i.e., which Docker images to use and what operations to perform with them).
The manager node dispatches ” tasks” to the worker nodes, which then execute them. These tasks are the concrete steps to achieve the desired state defined in your services (i.e., these are the Docker containers and commands to be executed within them).

(Note that a manager node can also have tasks assigned to it, as by default it often acts as a worker too.)

Practically, Docker Swarm Mode is controlled via specific Docker commands.

5. Getting Hands-On with Docker: Essential Commands and Tools

Let’s explore some practical examples:
5.1) Basic Docker Commands
5.2) Image Management
5.3) Container Management
5.4) Using Dockerfiles
5.5) Utilizing Volumes
5.6) A Quick Look at Docker Compose & Docker Swarm Mode
5.7) An Overview of Docker Desktop, Docker on Windows (with WSL2), and Podman

5.1. Basic Docker Commands

docker: Typing docker alone in your terminal lists all available Docker commands.
docker version: Displays the installed Docker version and information about its components.
docker -v (or docker --version): Shows only the installed Docker client version.
docker info: Provides comprehensive system information related to Docker.
docker images --help: Appending --help to any command shows its usage and options.
docker system df: Reports disk usage for Docker objects (images, containers, volumes).

5.2. Image Management

For a quick test, run docker run hello-world. Docker will first check locally for the “hello-world” image; if not found, it pulls it from Docker Hub, then starts a container, which prints a success message.

To see all downloaded images: docker images. This shows image size, version (tag), and other details.

To download a specific image: docker pull my-image. For instance, docker pull ubuntu downloads the latest Ubuntu image. For a specific version, use docker pull ubuntu:18.04 (ensure the version exists on Docker Hub).

Most images have a default command executed when a container starts. For Ubuntu, you might run docker run -it ubuntu to start an interactive container where you can input commands.

To delete an image: docker rmi image-name. If a container is using the image, this command will fail unless you use docker rmi -f image-name (or stop and remove the container first).

5.3. Container Management

Useful commands include docker ps (lists currently running containers) and docker ps -a (lists all containers, including stopped ones).

To start a container, use docker run my-image. Docker assigns a random name by default. You can assign a custom name with docker run --name my-container my-image.

If a container is stopped, restart it with docker start my-container. To stop a running container: docker stop my-container (graceful shutdown) or docker kill my-container (immediate, forceful shutdown).

To interact with a running container (e.g., the Ubuntu example): docker attach my-ubuntu-container. Alternatively, docker exec -it my-ubuntu-container bash executes the bash command inside the container, giving you a terminal session.

You can pause a container: docker pause my-ubuntu-container. If you were in an interactive session, input would cease. Unpause it with docker unpause my-ubuntu-container to resume.

Delete a container: docker rm my-container. Get statistics with docker stats my-container.

5.4. Using Dockerfiles

A Dockerfile is a text file containing instructions to build an image. Its syntax is well-documented (e.g., on docs.docker.com).

A basic Dockerfile example:

FROM ubuntu
RUN apt-get update
CMD ["echo", "Hello from my new image!"]

FROM ubuntu: Sets the base image (Ubuntu in this case). scratch can be used to start from nothing.
RUN apt-get update: Executes a command during the image build (updates package lists).
CMD ["echo", "Hello from my new image!"]: Specifies the command to run when a container is started from this image.

To build the image: docker build -t my-image:1.0 . (The -t flag tags it with a name and version; . indicates the Dockerfile is in the current directory). Then, run a container from it using docker run my-image:1.0.

5.5. Utilizing Volumes

Docker Volumes commands start with docker volume. You can docker volume create my-vol (where “my-vol” is your chosen name). Inspect a volume with docker volume inspect my-vol for details, especially the “Mountpoint” (the actual directory on your host filesystem where the data lives). List all volumes with docker volume ls.

To use a volume: when running a container, use the -v (or --volume) argument. Example with BusyBox:

docker run --name my-busybox -it -v my-vol:/app busybox

Here, my-vol:/app links the my-vol volume (on your HFS) to the /app directory inside the busybox container’s VFS.

If you create a file (e.g., echo "Hello World!" >> hello-world.txt) inside /app within the container, you’ll find it mirrored in the HFS directory identified by docker volume inspect my-vol.

Delete the container (docker rm my-busybox), then create a new one linking to my-vol (e.g., docker run --name my-new-busybox -it -v my-vol:/app busybox). You’ll find hello-world.txt still present, demonstrating data persistence. This also enables data sharing if multiple containers mount the same volume.

Changes made from either the host filesystem or within any attached container will synchronize. Data persists until the volume itself is deleted with docker volume rm my-vol.

5.6. A Quick Look at Docker Compose & Docker Swarm Mode

5.6.1. Docker Compose

Docker Compose is invaluable for local development environments. It uses a docker-compose.yaml file to define a multi-container application.

Example docker-compose.yaml (simplified for a SQL Server and Mailhog setup):

version: '3.8'
services:
  sqlserver:
    image: mcr.microsoft.com/mssql/server:2019-latest
    environment:
      SA_PASSWORD: "YourStrongPassword!"
      ACCEPT_EULA: "Y"
    ports:
      - "1433:1433"
    volumes:
      - sqlserver-data:/var/opt/mssql # Persistent data for SQL Server
  mailhog:
    image: mailhog/mailhog
    ports:
      - "8025:8025" # Web UI
      - "1025:1025" # SMTP port
volumes:
  sqlserver-data: # Define the volume

This file defines two services: sqlserver and mailhog, specifying their images, environment variables, exposed ports, and even a persistent volume for the SQL Server data. With this setup, you can access Mailhog via `http://localhost:8025` and connect to the SQL Server from your application.

Start the application with docker-compose up (run from the directory containing the file) and stop it with docker-compose down.

5.6.2. Docker Swarm Mode

Docker Swarm Mode commands begin with docker swarm.

Initialize a swarm: docker swarm init. This makes the current machine a manager node and provides instructions for other machines to join as workers (docker swarm join) or additional managers (docker swarm join-token manager).

Once the swarm is active, you can create services using docker service create and inspect them with docker service inspect. For a deeper dive, the official Docker Swarm tutorial is an excellent resource.

5.7. An Overview of Docker Desktop, Docker on Windows (with WSL2), and Podman

Docker Desktop provides a graphical interface for managing Docker containers, images, and volumes, making it easier to interact with Docker without relying solely on command-line tools. While it transitioned to a paid model for larger enterprise usage, it remains free for personal projects. More info at docker.com/products/docker-desktop.

For Docker on Windows, there’s an interesting evolution. It can use either a built-in Linux virtual machine or leverage WSL2 (Windows Subsystem for Linux 2), which is generally considered the superior option. WSL2 significantly streamlines running Linux applications on Windows, despite some lingering bugs. It’s worth exploring as it improves the overall developer experience. Details at docs.microsoft.com/en-us/windows/wsl/about.

Due to Docker Desktop’s licensing changes, Podman has emerged as a popular open-source alternative. Podman offers a similar command-line experience to Docker (e.g., podman ps, podman images), providing a daemon-less container engine. Running Podman on Windows also relies on WSL2. Learn more at podman.io.

Hopefully, this comprehensive overview of Docker and its ecosystem has been helpful. Feel free to leave comments if you have any questions or spot any inaccuracies.