Что такое Docker и почему его история важна для DevOps
Docker впервые показали публике 15 марта 2013 года на конференции PyCon в Санта-Кларе. Solomon Hykes вышел на сцену с пятиминутной демонстрацией «The future of Linux Containers» и запустил контейнер за считанные секунды. Зал ответил овацией, а репозиторий проекта на GitHub начал набирать звёзды быстрее почти всех аналогов того периода.
Создала Docker команда PaaS-стартапа dotCloud, а сам инструмент вырос из внутренней утилиты для упаковки клиентских приложений. Контейнеры к 2013 году уже существовали: механизмы изоляции появились в Unix за тридцать с лишним лет до этого. Вклад Hykes и его коллег в другом. Они превратили системную технологию в продукт, которым разработчик пользуется без чтения мануалов на сотни страниц.
Знание истории помогает в работе. Оно объясняет, почему Docker Engine и containerd сегодня разделены, зачем нужен стандарт OCI и в каких задачах выбирают Podman. Если вы только начинаете, начните с пошагового руководства по установке Docker на Ubuntu и CentOS, а затем возвращайтесь к хронологии: она даёт контекст для всех последующих решений.
Предпосылки: контейнеризация до Docker
Контейнеры не появились на пустом месте. Идея изолировать процессы друг от друга старше Linux и старше самого термина «контейнер». К 2013 году у инженеров был набор работающих технологий, каждая из которых закрывала часть задачи.
chroot, Jails и Zones: первые попытки изоляции
Раньше всех появился chroot. Он вошёл в Version 7 Unix в 1979 году и позволял подменить корневую директорию процесса: программа видела только свою часть файловой системы и не могла дотянуться до остальной. Ограничение было заметным: chroot изолировал файлы, но не процессы, сеть и права. Процесс с правами root легко покидал такую «клетку».
Следующий шаг сделали в FreeBSD. В 2000 году Poul-Henning Kamp добавил Jails, которые изолировали не только файловую систему, но и список процессов, сетевые адреса и учётные записи. Один экземпляр ядра обслуживал десятки независимых окружений, и это уже походило на современный контейнер.
В 2004 году Sun выпустила Solaris Zones вместе с Solaris 10. Технология давала изоляцию на уровне ОС, ограничивала ресурсы и применялась в продакшене крупных заказчиков. Через год появился OpenVZ: проект для Linux с отдельным патчем ядра, который поддерживал сотни контейнеров на одном физическом сервере. В 2008 году стартовал LXC, объединивший наработки OpenVZ и новые механизмы ядра.
Все эти решения объединяла одна проблема. Их настраивали вручную, документация была разрозненной, а готового формата для переноса окружения между машинами не существовало. LXC-контейнер собирали скриптами под конкретный дистрибутив, и повторить сборку на другом сервере удавалось с трудом.
Роль ядра Linux: cgroups и namespaces
Почву для массовой контейнеризации подготовили инженеры Google. В 2006 году Paul Menage и Rohit Seth начали работу над control groups, или cgroups. Механизм попал в основное ядро Linux в версии 2.6.24 (2008 год) и научился ограничивать процессор, память, дисковый ввод-вывод и сетевой трафик для группы процессов.
Второй половиной фундамента стали namespaces. Они дают процессу собственное представление о системе: отдельные PID, сетевые интерфейсы, точки монтирования, имена хостов и пользователей. PID namespace появился в ядре 2.6.24, сетевой namespace добавили в 2.6.29 (2009 год), остальные пространства имён подтягивались постепенно.
К 2013 году оба механизма были стабильны. Docker сначала использовал их через LXC, а в версии 0.9 (март 2014 года) перешёл на собственную библиотеку libcontainer. Именно тогда платформа перестала зависеть от внешних инструментов и получила прямой доступ к возможностям ядра.
Кто создал Docker: Solomon Hykes и dotCloud
Компанию dotCloud основали в 2010 году Solomon Hykes, Kamel Founadi и Julien Barbier. Стартап прошёл через акселератор Y Combinator (летний набор 2010 года) и занялся платформой как услугой: клиент загружал код, а dotCloud разворачивал его на своей инфраструктуре.
dotCloud: от PaaS к контейнерам
Бизнес-модель требовала запускать приложения сотен клиентов на общем железе. Каждый заказчик приносил свой стек: Python, Ruby, Node.js, базы данных, системные библиотеки. Держать под каждого отдельную виртуальную машину выходило дорого, а совмещать приложения в одном окружении мешали конфликты зависимостей.
Команда выбрала контейнеры LXC как компромисс: они легче виртуальных машин и дают нужную изоляцию. Вокруг LXC инженеры dotCloud написали внутренний инструмент, который упаковывал приложение вместе с зависимостями в переносимый образ и запускал его одной командой. Этот инструмент и стал прототипом Docker.
Hykes позже описывал ситуацию прямо: Docker появился как побочный продукт, потому что основной продукт dotCloud продавался плохо, а внутренняя разработка оказалась интереснее рынку, чем сама платформа.
Публичный анонс на PyCon 2013
15 марта 2013 года Hykes выступил в Санта-Кларе на PyCon. Доклад шёл в формате lightning talk и занял около пяти минут. Демонстрация показала, как упаковать Python-приложение в контейнер и запустить его на другой машине без установки зависимостей. Видео разошлось по сообществу за несколько дней.
Интерес оказался настолько высоким, что в октябре 2013 года dotCloud переименовали в Docker Inc., а саму PaaS-платформу постепенно свернули. Компания сменила фокус: вместо продажи хостинга она стала развивать открытый инструмент контейнеризации.
Почему Docker «выстрелил»: ключевые инновации
К 2013 году контейнеры умели запускать и без Docker. Разница была в опыте работы. LXC требовал понимания ядра, OpenVZ накладывал ограничения на дистрибутивы, а перенос окружения оставался ручной операцией. Docker собрал всё в один последовательный сценарий и добавил то, чего не хватало.
Образы и слои: переносимость и версионирование
Образ Docker собран из слоёв. Каждый слой фиксирует изменения файловой системы: установленные пакеты, скопированные файлы, правки конфигурации. Слои кэшируются и переиспользуются, поэтому повторная сборка после правки одной строки проходит за секунды, а не за минуты.
Слоистая структура дала два эффекта. Первый: образ стал версионируемым артефактом, который передаётся между средами без потерь. Второй: базовые слои хранятся на диске и в сети в единственном экземпляре. Образ на основе Ubuntu с установленным Nginx весит немного больше самой базовой системы, потому что общие слои не дублируются.
Разобраться в устройстве движка и работе с образами поможет разбор архитектуры Docker Engine с примерами развёртывания.
Dockerfile и Docker Hub: стандартизация и обмен
Dockerfile описывает сборку образа текстом: базовый образ, команды установки, порты, точку входа. Файл читается человеком, хранится в репозитории рядом с кодом и проверяется на код-ревью. Это сняло главную боль LXC, где сборка жила в голове администратора и в наборе скриптов.
Второй частью экосистемы стал публичный реестр. Docker Hub открыли в 2014 году вместе с релизом Docker 1.0, и он запустил сетевой эффект: чем больше готовых образов, тем полезнее платформа для нового пользователя. Сегодня в реестре миллионы образов, от официальных сборок PostgreSQL и Nginx до нишевых инструментов.
Оставалась простота командной строки. Одна команда запуска скачивает образ, создаёт контейнер и стартует процесс, а флаги отвечают за порты, тома и переменные окружения. Порог входа упал до уровня разработчика, который никогда не работал с ядром Linux.
Эволюция Docker: от стартапа до стандарта индустрии
Путь проекта после 2013 года шёл не по прямой. Быстрые релизы сменялись стратегическими ошибками, а часть технологий Docker отдал сообществу.
- 2013: анонс на PyCon, выход Docker 0.1, переименование dotCloud в Docker Inc.
- 2014: релиз Docker 1.0 в июне, запуск Docker Hub, переход на libcontainer.
- 2015: создание Open Container Initiative, первые версии Docker Swarm.
- 2016: публичные сборки Docker для Mac и Windows, вывод containerd в отдельный проект.
- 2017: проект Moby, передача containerd в CNCF, поддержка Kubernetes в Docker Enterprise.
- 2019: продажа бизнес-подразделения Docker Enterprise компании Mirantis.
- 2021: смена условий лицензирования Docker Desktop для крупных компаний.
Docker Swarm и противостояние с Kubernetes
В 2015 году Docker представил Swarm, встроенный оркестратор для управления кластером контейнеров. Идея была логичной: один инструмент закрывает и запуск, и координацию. Но Google в 2014 году открыл Kubernetes, а в 2015-м передал его в Cloud Native Computing Foundation. К 2017 году Kubernetes стал де-факто стандартом оркестрации.
Показательный момент наступил в 2017 году, когда Docker Inc. объявила о поддержке Kubernetes внутри Docker Enterprise. Признание чужого стандарта вместо продвижения Swarm подвело черту в споре. Swarm до сих пор работает в небольших кластерах и на периферийных устройствах, где его простота оправдана.
OCI и containerd: стандартизация контейнеров
В июне 2015 года появилась Open Container Initiative под эгидой Linux Foundation. Задача: зафиксировать открытые стандарты формата образов и среды выполнения. Docker передал в OCI спецификации и код runc, и это дало совместимость: образ, собранный Docker, запускается в Podman, containerd и Kubernetes.
Отдельная линия связана с containerd. Низкоуровневый runtime выделили в самостоятельный проект в 2016 году, в 2017-м передали в CNCF, а в 2019-м он получил статус graduated. Сегодня containerd работает под капотом Docker Engine и Kubernetes: сам Docker отвечает за сборку образов и удобный CLI, а запуск контейнеров выполняет демон containerd.
Для продакшена важны и детали безопасности. Сканирование образов на уязвимости, отказ от запуска под root и тонкая настройка сетей описаны в гайде по безопасности и оптимизации контейнеров.
Что история Docker даёт современному DevOps-инженеру
Хронология отвечает на вопросы, которые возникают в реальной работе чаще, чем кажется.
- Docker это не вся экосистема. Под капотом работают containerd и runc, формат образов задаёт OCI, а оркестрацией занимается Kubernetes. Понимание границ объясняет, куда смотреть при сбое: в CLI, в демон или в runtime.
- Выбор инструмента становится осознанным. В кластере с Kubernetes отдельный Docker Engine часто не нужен: containerd уже установлен. На машине разработчика удобнее Docker Desktop. Там, где важен запуск без демона и root-прав, применяют Podman.
- Аргументы для команды и заказчика. История Swarm и Kubernetes показывает, почему стандартизация важнее привязки к одному вендору. Этот довод пригодится при защите архитектурных решений.
- Лицензирование тоже часть истории. Смена условий Docker Desktop в 2021 году заставила крупные компании пересмотреть бюджеты и перейти на альтернативы в части рабочих мест.
Актуальное сравнение инструментов с учётом их эволюции собрано в материале про выбор между Docker, Podman и LXC: там разобраны архитектура, безопасность и интеграция с Kubernetes.
Проверка фактов и источники
Даты, имена и версии в статье сверены по нескольким группам документов. Основу даёт официальная документация Docker: разделы о релизах Engine, истории проекта и текущей архитектуре. Контекст анонса восстанавливается по архиву конференции PyCon 2013, где сохранена запись доклада Solomon Hykes «The future of Linux Containers».
Роли основателей и история dotCloud описаны в интервью Hykes разных лет, а также в материалах Y Combinator о наборе 2010 года. Технические детали стандартизации проверяются по спецификациям Open Container Initiative, документации containerd и релизам CNCF. Даты появления cgroups и namespaces подтверждаются документацией ядра Linux и заметками разработчиков.
Если какой-то факт вызывает сомнения, проверяйте его по первоисточникам, а не по пересказам: детали релизов и лицензий менялись, и вторичные материалы часто отстают от реального состояния проектов.