Docker Toolbox: как Docker сделал контейнеры удобными

Docker часто называют технологией, которая принесла контейнеры в массовую разработку, хотя сами механизмы изоляции появились намного раньше. Его главный вклад состоял не в изобретении отдельного способа ограничить процесс, а в объединении сборки приложения, его зависимостей, передачи готового образа и запуска одной командой. Именно этот цельный рабочий процесс превратил контейнеризацию из набора системных возможностей в понятный инструмент для разработчика.

Контейнеры появились задолго до Docker

Одним из ранних предшественников контейнеров был chroot, включённый в Version 7 Unix в 1979 году. Он менял для процесса видимый корневой каталог и помогал отделить одну файловую среду от другой, но не скрывал все процессы, сеть и другие ресурсы системы. Поэтому chroot полезен как строительный блок, однако сам по себе не создаёт полноценную границу безопасности.

Следующий важный шаг сделали системы, которые начали изолировать не только файловое дерево. Появившиеся во FreeBSD 4.0 Jails добавили отдельное представление пользователей, процессов и сети, а Solaris Zones развили похожую идею в сторону управляемой виртуализации на уровне операционной системы. В отличие от виртуальной машины, такая среда не загружает собственное ядро: все изолированные процессы продолжают работать на ядре хоста, поэтому накладные расходы обычно меньше, но модель безопасности и совместимости остаётся связанной с этим общим ядром. Это различие сохраняется и у современных контейнеров.

В Linux контейнер сложился не из одной функции, а из нескольких механизмов ядра, которые развивались в разное время. Namespaces дают группе процессов собственное представление идентификаторов процессов, точек монтирования, сети, пользователей и других системных ресурсов. Control groups, или cgroups, объединяют процессы в иерархические группы и позволяют учитывать либо ограничивать их потребление памяти, процессорного времени и других ресурсов. Namespaces отвечают прежде всего на вопрос «что процесс видит», а cgroups на вопрос «сколько ему разрешено использовать»; для практического контейнера нужны обе части, а также capabilities, правила сети, файловая система и дополнительные средства защиты.

К концу 2000-х проект LXC собрал эти возможности в пользовательские библиотеки и команды для создания Linux-контейнеров. Это уже был полноценный и полезный инструментарий, поэтому называть LXC лишь «почти Docker» неправильно. Различие лежало в назначении: LXC в первую очередь создавал среду, похожую на отдельную Linux-систему, тогда как будущий Docker сосредоточился на упаковке и доставке конкретного приложения.

Задача dotCloud

Компания dotCloud, основанная Соломоном Хайксом, разрабатывала платформу как сервис и запускала приложения клиентов, написанные на разных языках и собранные из разных зависимостей. Для такой платформы изоляция была только половиной задачи. Команде требовался воспроизводимый способ принять приложение, собрать окружение, перенести получившийся артефакт между машинами и запустить его одинаковым образом, не заставляя каждого пользователя разбираться в деталях LXC и конфигурации хоста.

Решение, выросшее внутри dotCloud, команда выделила в открытый проект. 15 марта 2013 года Хайкс публично показал Docker на PyCon, сформулировав проблему очень приземлённо: разработчикам трудно доставлять код на сервер. Первые версии Docker использовали LXC как среду выполнения, но проект не был просто графической или командной оболочкой над LXC. Он предлагал собственную модель образов и единый интерфейс, который связывал сборку, хранение, передачу и запуск приложения.

Что именно изменил Docker

Удобство Docker возникло из сочетания нескольких решений. Dockerfile позволил хранить рецепт окружения рядом с кодом и повторять сборку вместо ручной настройки сервера. Слои образа сделали возможными повторное использование и кеширование неизменившихся частей. Реестр дал образам общий адрес и превратил команды push и pull в привычный способ передавать готовое приложение между ноутбуком, CI и сервером. Наконец, команды docker build и docker run скрыли значительную часть системной настройки за коротким и достаточно последовательным интерфейсом.

Эти возможности появились не все в момент первого показа. Например, журнал выпусков Docker отмечает появление сборщика Dockerfile в версии 0.4 летом 2013 года, а центральный реестр и возможность поднять собственный registry развивались в том же году. Docker Compose вырос из отдельного проекта Fig и вошёл в экосистему позднее, поэтому относить docker compose up к первоначальным нововведениям Docker нельзя.

Менялась и внутренняя реализация. В марте 2014 года Docker 0.9 сделал средой выполнения по умолчанию libcontainer, который обращался к namespaces, cgroups, capabilities и сетевым механизмам Linux напрямую, без обязательной зависимости от LXC. Этот переход хорошо показывает, почему Docker и контейнеры не являются синонимами: пользовательский процесс сборки и запуска мог сохраниться, даже когда нижележащая реализация была заменена.

Практический эффект оказался важнее отдельной команды. Разработчик получил переносимый артефакт с явными зависимостями, CI мог тестировать тот же образ, который затем отправлялся в реестр, а сервер запускал его по одной и той же инструкции. Это не устранило различия процессорных архитектур, конфигурации ядра, секретов, хранилищ и сетей, поэтому обещание «работает везде» всегда имеет условия. Однако число неявных различий между средами заметно сократилось.

От одного продукта к общим стандартам

По мере роста экосистемы стало опасно связывать формат образа и правила запуска с одним поставщиком. В июне 2015 года Docker, CoreOS и другие участники отрасли создали под эгидой Linux Foundation Open Container Initiative. Docker передал проекту свой формат контейнера и runC, а дальнейшая работа привела к открытым спецификациям runtime, image и distribution.

OCI не делает все контейнерные инструменты одинаковыми: Docker, containerd, Podman, CRI-O и оркестраторы по-прежнему решают разные задачи и имеют собственные функции. Стандарты определяют совместимые границы между образом, его распространением и средой выполнения, благодаря чему образ перестал быть привязан только к одной реализации. В этом смысле наследие Docker состоит не только в популярности команды docker run, но и в закреплении контейнерного образа как переносимой единицы доставки приложения.

Что умеет Docker Toolbox

Docker Toolbox помогает не собирать образы, а работать с уже готовыми командами запуска. В основном режиме он разбирает команду docker run и превращает поддерживаемые параметры в docker-compose.yml. Сейчас конвертер понимает имя контейнера, образ, публикацию портов, тома, переменные окружения и политику перезапуска.

Второй режим служит небольшой шпаргалкой для обслуживания Docker. В нём можно получить команды для очистки неиспользуемых ресурсов, остановки и удаления всех контейнеров, входа в оболочку выбранного контейнера и просмотра последних строк журнала. Перед запуском команд очистки стоит проверить их параметры: например, docker system prune -a --volumes удаляет не только остановленные контейнеры, но также неиспользуемые образы, сети и тома.

Для быстрой конвертации вставьте команду наподобие docker run -d --name web -p 8080:80 -e NODE_ENV=production nginx:alpine. Инструмент сформирует сервис Compose с тем же образом, портом, именем и переменной окружения; результат можно скопировать и затем дополнить сетями, зависимостями или другими настройками, которые не выражены в исходной команде.

Похожие инструменты

Инструменты DockerКонвертер консольных команд docker run в файлы docker-compose.yml и шпаргалка команд очистки ресурсов и входа в контейнеры.Конструктор Nginx конфиговГенератор site config или полного nginx.conf с reverse proxy routes, upstream-балансировкой, TLS, proxy cache, rate limiting, security и advanced HTTP-настройками.Генератор Systemd сервисовГенератор файлов служб systemd (/etc/systemd/system/*.service) и консольных команд управления systemctl.Конвертер YAML, JSON, TOML и .envКонвертируйте между YAML, JSON, TOML, .env и shell-экспортом с автоопределением входного формата, настраиваемым отступом и явным предупреждением там, где целевой формат не умеет что-то выразить — null в TOML, вложенность в .env.