kostyl.dev
Docker

Docker — що це і навіщо?

Історія Docker, екосистема, роль у сучасній розробці та причини популярності контейнерної платформи

Docker — що це і навіщо?

Від ідеї до інструменту

У попередній статті ми розглянули контейнеризацію як концепцію — ідею ізоляції застосунків на рівні операційної системи. Але ідея сама по собі не змінює індустрію. Потрібен інструмент, який зробить цю ідею доступною, зрозумілою та зручною для мільйонів розробників.

Docker — це саме той інструмент. Він не винайшов контейнери (Linux namespaces та cgroups існували задовго до Docker), але він зробив контейнеризацію простою. Там, де раніше потрібно було глибоке розуміння внутрішніх механізмів Linux, Docker запропонував інтуїтивний інтерфейс командного рядка та декларативний підхід до опису застосунків.

Docker до контейнерів — це як Git до систем контролю версій. Технологія існувала раніше, але саме зручний інструмент зробив її масовою.

Історія Docker: від PaaS до революції

Початок: dotCloud (2008–2013)

Історія Docker починається не з контейнерів, а з Platform-as-a-Service (PaaS). У 2008 році французький підприємець Solomon Hykes разом із Себастьяном Палем та Камілем Фурньє заснували компанію dotCloud — платформу для розгортання веб-застосунків, схожу на Heroku.

dotCloud дозволяла розробникам деплоїти застосунки на Python, Ruby, PHP без необхідності управляти серверами. Під капотом dotCloud використовувала Linux контейнери (LXC) для ізоляції застосунків клієнтів. Це було внутрішнє рішення, закрите від зовнішнього світу.

Але dotCloud не здобула очікуваного успіху на ринку PaaS. Конкуренція була жорсткою, а ринок вже мав лідерів. Команда зрозуміла, що найцінніша частина їхньої платформи — це не PaaS-сервіс, а внутрішній інструмент для управління контейнерами.

Народження Docker (2013)

У березні 2013 року на конференції PyCon у Санта-Кларі (Каліфорнія) Solomon Hykes представив Docker як open-source проєкт. Презентація тривала лише 5 хвилин, але вона змінила індустрію.

Docker пропонував те, чого не було раніше:

  • Простий CLI: docker run, docker build, docker push — команди, зрозумілі будь-якому розробнику
  • Dockerfile: декларативний спосіб опису застосунку та його залежностей
  • Docker Hub: публічний реєстр образів, де можна знайти готові контейнери для будь-якої технології
  • Портативність: образ, створений на ноутбуці, працює на будь-якому сервері з Docker

Реакція спільноти була вибуховою. За перший рік проєкт отримав понад 10,000 зірок на GitHub, сотні контрибуторів та тисячі компаній, які почали експериментувати з Docker.

Відкритий код та стандартизація (2015–2017)

У 2015 році Docker Inc. (перейменована dotCloud) разом з іншими лідерами індустрії (Google, Red Hat, Microsoft, IBM) заснували Open Container Initiative (OCI) — організацію для створення відкритих стандартів контейнерних технологій.

OCI визначила два ключові стандарти:

  • Image Specification: формат контейнерних образів
  • Runtime Specification: як контейнери мають запускатися та виконуватися

Це гарантувало, що контейнери не будуть прив'язані до одного вендора. Образ, створений для Docker, може працювати в інших OCI-сумісних runtime (Podman, containerd, CRI-O).

Відкритість Docker та створення OCI — це одна з причин його успіху. Компанії не боялися vendor lock-in, оскільки стандарти були відкритими.

Docker сьогодні (2020–2026)

Станом на 2026 рік Docker залишається найпопулярнішою платформою контейнеризації:

  • Понад 13 мільйонів розробників використовують Docker
  • Docker Hub містить понад 15 мільйонів контейнерних образів
  • Більшість CI/CD систем (GitHub Actions, GitLab CI, Jenkins) мають нативну підтримку Docker
  • Провідні хмарні провайдери (AWS, Azure, GCP) пропонують сервіси для запуску Docker-контейнерів

Docker перестав бути просто інструментом — він став стандартом де-факто для упаковки та розповсюдження застосунків.

Що таке Docker?

Docker — це відкрита платформа для розробки, доставки та запуску застосунків у контейнерах. Він складається з кількох компонентів, які працюють разом, щоб забезпечити повний життєвий цикл контейнерних застосунків.

Docker як платформа

На відміну від простого інструменту, Docker — це екосистема, яка охоплює:

Створення: інструменти для побудови контейнерних образів (Dockerfile, BuildKit)

Розповсюдження: реєстри для зберігання та обміну образами (Docker Hub, приватні реєстри)

Запуск: runtime для виконання контейнерів (Docker Engine)

Оркестрація: інструменти для управління багатоконтейнерними застосунками (Docker Compose)

Loading diagram...
@startuml
skinparam style plain
skinparam backgroundColor #ffffff
skinparam ArrowColor #3b82f6
skinparam ParticipantBorderColor #1e3a8a
skinparam ParticipantBackgroundColor #eff6ff

participant "Source Code\n(Dockerfile)" as Src
participant "Docker Image\n(Build output)" as Img
database "Docker Registry\n(Docker Hub / MCR)" as Reg
participant "Docker Container\n(Running App)" as Box

Src -> Img : docker build
note over Src, Img: Упаковка коду, середовища\nта залежностей у легкий образ

Img -> Reg : docker push
note over Img, Reg: Публікація та шаринг образу\nу хмарі або приватному реєстрі

Reg -> Box : docker pull / run
note over Reg, Box: Запуск ізольованого контейнера\nна будь-якій системі
@enduml

Ця повнота екосистеми — одна з причин, чому Docker став настільки популярним. Розробник отримує все необхідне в одному пакеті.

Ключові компоненти Docker

Docker складається з кількох взаємопов'язаних компонентів, кожен з яких відповідає за певний аспект роботи з контейнерами.

Docker Engine — це серце Docker, клієнт-серверний застосунок, який складається з:

  • Docker Daemon (dockerd) — фоновий процес, який управляє контейнерами, образами, мережами та томами
  • REST API — інтерфейс для взаємодії з демоном
  • Docker CLI (docker) — інструмент командного рядка, який використовує API для спілкування з демоном

Docker CLI — це основний інтерфейс для розробників. Команди на кшталт docker run, docker build, docker ps перетворюються на API-виклики до Docker Daemon.

Docker Hub — це публічний реєстр контейнерних образів. Тут можна знайти офіційні образи для популярних технологій (Node.js, PostgreSQL, Redis) або опублікувати власні образи для команди чи спільноти.

Docker Compose — інструмент для визначення та запуску багатоконтейнерних застосунків через YAML-файл. Замість запуску кожного контейнера окремою командою, ви описуєте всю архітектуру в docker-compose.yml.

Loading diagram...
@startuml
skinparam style plain
skinparam backgroundColor #ffffff

package "Docker Client (CLI)" {
  [docker CLI] as CLI
}

package "Docker Host" {
  node "Docker Daemon (dockerd)" as Daemon
  database "Images" {
    [ubuntu] as img1
    [redis] as img2
  }
  folder "Containers" {
    [web_app] as c1
    [db_cache] as c2
  }
}

package "Docker Registry" {
  [Docker Hub] as Hub
}

CLI -right-> Daemon : REST API / gRPC
Daemon -down-> img1 : manages
Daemon -down-> c1 : runs & monitors
c1 -left-> img1 : instances of
c2 -left-> img2 : instances of
Daemon -right-> Hub : pull / push
@enduml
У цьому курсі ми зосередимося на Docker Engine та Docker CLI. Docker Compose буде детально розглянуто в окремих статтях. Kubernetes та інші оркестратори залишаються за межами курсу.

Docker vs альтернативи

Docker не є єдиною контейнерною технологією. Існують альтернативи, кожна з яких має свої переваги та недоліки.

Podman: Docker без демона

Podman (Pod Manager) — це контейнерний runtime від Red Hat, який позиціонується як "daemonless" альтернатива Docker. Ключові відмінності:

  • Без демона: Podman не потребує фонового процесу, кожна команда запускається як окремий процес
  • Rootless за замовчуванням: контейнери можуть запускатися від непривілейованого користувача без додаткових налаштувань
  • Сумісність з Docker: команди Podman майже ідентичні Docker (podman run замість docker run)
  • Підтримка Kubernetes YAML: Podman може запускати Kubernetes pods локально

Podman популярний у корпоративному середовищі (особливо Red Hat Enterprise Linux), але Docker залишається домінуючим у більшості сценаріїв розробки.

Loading diagram...
@startuml
skinparam style plain
skinparam backgroundColor #ffffff

together {
  package "DOCKER (Daemon-based)" {
    [User / CLI] as DocCLI
    node "Docker Daemon\n(dockerd - Root)" as DocDaemon
    node "Container 1" as DocC1
    node "Container 2" as DocC2

    DocCLI -down-> DocDaemon : API call
    DocDaemon -down-> DocC1 : fork & monitor
    DocDaemon -down-> DocC2 : fork & monitor
  }
}

together {
  package "PODMAN (Daemonless)" {
    [User / CLI] as PodCLI
    node "Container 1" as PodC1
    node "Container 2" as PodC2

    PodCLI -down-> PodC1 : Direct fork/exec\n(user space)
    PodCLI -down-> PodC2 : Direct fork/exec\n(user space)
  }
}
@enduml

containerd: низькорівневий runtime

containerd — це високопродуктивний контейнерний runtime, який спочатку був частиною Docker, але в 2017 році був виділений в окремий проєкт під егідою Cloud Native Computing Foundation (CNCF).

containerd використовується як базовий runtime у:

  • Docker (Docker Engine використовує containerd під капотом)
  • Kubernetes (через Container Runtime Interface)
  • AWS Fargate, Google Cloud Run

containerd — це низькорівневий інструмент, призначений для інтеграції в інші системи, а не для безпосереднього використання розробниками.

LXC/LXD: системні контейнери

LXC (Linux Containers) — це оригінальна технологія контейнеризації Linux, яка існувала до Docker. LXC створює "системні контейнери" — середовища, які більше схожі на віртуальні машини, ніж на контейнери застосунків.

LXD — це сучасний інтерфейс для LXC від Canonical (Ubuntu). LXC/LXD використовуються для сценаріїв, де потрібна повноцінна ОС у контейнері (наприклад, для тестування дистрибутивів Linux).

Чому Docker став стандартом?

Docker переміг у "війні контейнерів" завдяки кільком факторам:

Простота використання: Docker CLI інтуїтивний та зрозумілий. Dockerfile — це простий текстовий файл, який може прочитати будь-хто.

Екосистема: Docker Hub з мільйонами готових образів знизив поріг входу до нуля. Потрібен PostgreSQL? docker run postgres. Потрібен Redis? docker run redis.

Документація та спільнота: Docker має вичерпну документацію, тисячі туторіалів, активну спільноту на Stack Overflow та GitHub.

Підтримка індустрії: Microsoft, Google, AWS, IBM інвестували в Docker-екосистему, створивши інтеграції та сервіси.

Правильний час: Docker з'явився в момент, коли індустрія переходила до мікросервісів та DevOps-практик. Контейнери ідеально вписалися в цю парадигму.

Вибір між Docker та альтернативами часто залежить від контексту. Для локальної розробки та CI/CD Docker залишається найзручнішим варіантом. Для корпоративних середовищ з високими вимогами до безпеки Podman може бути кращим вибором.

Сценарії використання Docker

Docker знайшов застосування в різних сферах розробки та експлуатації програмного забезпечення.

Локальне середовище розробки

Замість встановлення PostgreSQL, Redis, RabbitMQ та інших залежностей безпосередньо на робочу машину, розробник може запустити їх у контейнерах. Це дає:

  • Чисту систему: немає конфліктів версій, немає "сміття" після видалення проєкту
  • Швидке перемикання: працюєте над проєктом A з PostgreSQL 15, потім перемикаєтесь на проєкт B з PostgreSQL 13 — просто зупиняєте один контейнер і запускаєте інший
  • Ідентичність з продакшеном: якщо на продакшені PostgreSQL 15.2, локально ви використовуєте той самий образ

CI/CD пайплайни

Continuous Integration та Continuous Deployment системи масово використовують Docker:

  • Ізольоване середовище для кожної збірки: кожен тест запускається у свіжому контейнері, немає впливу попередніх запусків
  • Паралельне виконання: можна запустити десятки тестових контейнерів одночасно
  • Відтворюваність: збірка, яка пройшла локально, пройде і в CI, оскільки середовище ідентичне

GitHub Actions, GitLab CI, Jenkins, Azure DevOps — всі ці системи мають нативну підтримку Docker-контейнерів.

Мікросервісна архітектура

Docker та мікросервіси — це природна комбінація. Кожен мікросервіс упаковується у власний контейнер з усіма залежностями:

  • Незалежне розгортання: можна оновити один сервіс, не зачіпаючи інші
  • Технологічна різноманітність: один сервіс на Node.js, інший на C#, третій на Python — кожен у своєму контейнері
  • Масштабування: популярний сервіс можна масштабувати горизонтально, запустивши більше його екземплярів

Ізольоване тестування

Контейнери ідеальні для інтеграційних тестів:

  • Запустити тестову базу даних у контейнері
  • Виконати міграції та заповнити тестовими даними
  • Запустити тести
  • Знищити контейнер — жодних слідів не залишається

Це набагато швидше та надійніше, ніж використання спільної тестової бази даних, яка може бути в непередбачуваному стані.

Демонстрація та навчання

Docker спрощує демонстрацію застосунків:

  • Замість інструкції "встановіть Node.js 20, PostgreSQL 15, Redis 7, налаштуйте змінні оточення..." — просто docker compose up
  • Студенти та нові члени команди можуть запустити проєкт за хвилини, а не години
Docker не вирішує всі проблеми. Він не замінює правильну архітектуру, не усуває баги в коді та не робить повільний застосунок швидким. Docker — це інструмент для управління середовищами, а не панацея.

Docker та .NET: ідеальне поєднання

Microsoft є одним з найбільших прихильників Docker. Починаючи з .NET Core (2016), всі версії .NET мають офіційні Docker-образи, які підтримуються командою .NET.

Офіційні образи .NET

Microsoft публікує образи на Microsoft Container Registry (MCR) — mcr.microsoft.com:

  • mcr.microsoft.com/dotnet/sdk — повний SDK для розробки та збірки
  • mcr.microsoft.com/dotnet/aspnet — runtime для ASP.NET Core застосунків
  • mcr.microsoft.com/dotnet/runtime — runtime для консольних застосунків
  • mcr.microsoft.com/dotnet/runtime-deps — мінімальний образ з лише системними залежностями

Кожен образ доступний у кількох варіантах:

  • Debian-based (за замовчуванням): повнофункціональний, але більший за розміром
  • Alpine-based: мінімалістичний Linux-дистрибутив, образи в 2-3 рази менші
  • Ubuntu-based: для сценаріїв, де потрібна сумісність з Ubuntu

Loading diagram...
@startuml
skinparam style plain
skinparam backgroundColor #ffffff

node "mcr.microsoft.com/dotnet/sdk" as SDK {
  [Компілятор, MSBuild, NuGet] as sdk_tools
}

node "mcr.microsoft.com/dotnet/aspnet" as ASP {
  [Kestrel, Middleware, MVC] as asp_tools
}

node "mcr.microsoft.com/dotnet/runtime" as Run {
  [.NET CoreCLR, BCL] as run_tools
}

node "mcr.microsoft.com/dotnet/runtime-deps" as Deps {
  [Системні залежності .NET] as dep_tools
}

node "Base OS Image (Alpine / Debian / Ubuntu)" as OS {
  [Базові Linux бібліотеки & пакетний менеджер] as os_tools
}

SDK -up-|> ASP : розширює
ASP -up-|> Run : розширює
Run -up-|> Deps : розширює
Deps -up-|> OS : розширює
@enduml

Чому .NET та Docker добре працюють разом?

.NET є кросплатформним: застосунок, зібраний на Windows, працює в Linux-контейнері без змін.

Оптимізація для контейнерів: .NET 8 та новіші версії мають спеціальні оптимізації для контейнерного середовища (швидший старт, менше споживання пам'яті).

Інтеграція з інструментами: Visual Studio, Rider, VS Code мають вбудовану підтримку Docker — можна налагоджувати застосунок безпосередньо в контейнері.

Офіційна документація: Microsoft надає детальні гайди з контейнеризації .NET застосунків.

У статті "Контейнеризація .NET додатків" ми детально розглянемо, як створювати production-ready Docker-образи для C# застосунків з оптимізацією розміру та безпеки.

Резюме

Docker — це не просто інструмент, а екосистема, яка змінила спосіб розробки, доставки та експлуатації програмного забезпечення. Він зробив контейнеризацію доступною для мільйонів розробників, стандартизувавши процес упаковки застосунків.

Ключові тези:

  • Docker виник як внутрішній інструмент компанії dotCloud та став open-source у 2013 році
  • Docker складається з Docker Engine (daemon + CLI), Docker Hub (реєстр образів) та Docker Compose (оркестрація)
  • Альтернативи існують (Podman, containerd, LXC), але Docker залишається стандартом де-факто завдяки простоті та екосистемі
  • Docker використовується для локальної розробки, CI/CD, мікросервісів, тестування та навчання
  • Microsoft активно підтримує Docker, надаючи офіційні образи для всіх версій .NET

У наступній статті ми заглибимося в архітектуру Docker Engine, щоб зрозуміти, що відбувається під капотом, коли ви виконуєте команду docker run.

Практичні завдання

Завдання 1: Дослідження Docker Hub

Відвідайте Docker Hub та знайдіть офіційні образи для наступних технологій:

  1. PostgreSQL — яка остання версія? Скільки завантажень має цей образ?
  2. .NET SDK — які варіанти образів доступні (Debian, Alpine, Ubuntu)?
  3. Redis — яка різниця між тегами latest, 7-alpine, 7-bookworm?

Питання для роздумів:

  • Чому офіційні образи мають значок "Docker Official Image"?
  • Що означає кількість завантажень (pulls) — чи це показник якості?

Завдання 2: Порівняння Docker та Podman

Створіть таблицю порівняння Docker та Podman за критеріями:

КритерійDockerPodman
Архітектура (daemon/daemonless)??
Rootless за замовчуванням??
Сумісність команд??
Підтримка Docker Compose??
Популярність у спільноті??

Додаткове питання: У яких сценаріях ви б обрали Podman замість Docker?

Завдання 3: Аналіз сценаріїв використання

Для кожного сценарію визначте, чи підходить Docker, та обґрунтуйте відповідь:

  1. Команда з 10 розробників працює над монолітним .NET застосунком, який використовує SQL Server
  2. Стартап розробляє SaaS-платформу з 30 мікросервісами на різних технологіях
  3. Університетський курс з веб-розробки для 100 студентів
  4. Legacy Windows Forms застосунок на .NET Framework 4.8
  5. CI/CD система, яка виконує 1000 тестових запусків на день
Ці завдання допоможуть вам краще зрозуміти екосистему Docker та його місце в сучасній розробці. Немає "правильних" відповідей — важливо обґрунтування вашого вибору.

Контейнеризація — від проблеми до рішення

Концепція контейнеризації: проблеми розгортання ПЗ, еволюція від bare metal до контейнерів, принципи ізоляції Linux (namespaces, cgroups)

Архітектура Docker Engine

Детальний розбір внутрішньої архітектури Docker — клієнт-серверна модель, Docker Daemon, containerd, runc та OCI стандарти