rkt: контейнеры без daemon, или как CoreOS видит безопасный runtime

В ноябре CoreOS объявил о Rocket как идее - публичный анонс с критикой Docker-daemon. Теперь, в начале декабря, вышел официальный релиз rkt 0.1 с нормальным репозиторием, README и хоть каким-то кодом, который можно пощупать. Мы потратили несколько вечеров, чтобы разобраться, что именно CoreOS собрал и зачем.

Архитектурная суть

Главное отличие rkt - отсутствие центрального daemon. В Docker схема такая: есть долгоживущий процесс dockerd, запущенный от root, и к нему ходит CLI. Все контейнеры - дочерние процессы этого daemon.

В rkt схема другая: rkt run - это просто бинарь, который запускается, делает свою работу и порождает контейнер напрямую. Контейнер живёт как дочерний процесс init (или systemd, если хост на systemd). Никакого посредника, никакого долгоживущего привилегированного процесса между вами и ядром.

С точки зрения Unix-модели - честнее. Контейнер - это обычный процесс с namespace-изоляцией, его можно увидеть в ps, его можно убить через kill, его ресурсы видны через обычные инструменты. Не надо идти в docker ps через socket, который требует root-доступа.

Что это даёт на практике

Безопасность выглядит иначе, и в лучшую сторону:

• Права на запуск - в момент запуска. rkt требует привилегий только когда вы вызываете rkt run, и не держит постоянный процесс с этими привилегиями. После старта контейнера привилегированный процесс завершился.
• Аудит. Любой запуск контейнера - это запуск бинаря с аргументами. Это логируется обычными средствами аудита, как любой другой sudo-вызов. Не надо объяснять аудиторам, что такое docker socket и почему к нему нет лога.
• Интеграция с systemd. Контейнер как child process init - это то, чего в Docker приходится добиваться через --restart и workaround-ы. Тут это работает нативно: systemd видит контейнер как unit, может управлять его lifetime напрямую.

Мы уже писали про systemd в продакшне, и эта интеграция выглядит как честный ответ на реальную проблему.

Что с этим не так прямо сейчас

rkt 0.1 - это 0.1 в прямом смысле слова.

Формат образов - ACI, не Docker. App Container Image - отдельная спецификация. rkt не читает Docker Image Format. Наш внутренний реестр набит docker-образами, и запустить их через rkt нельзя. Конвертации нет. Работа с образами - через actool, который существует примерно с прошлой недели.

Экосистема нулевая. Вокруг Docker за последние полгода выросло - Fig, Compose, Registry, сторонние системы оркестрации, интеграции с CI. Вокруг rkt - пока только CoreOS-документация и README. Ни одного внешнего инструмента, который бы умел с ним работать.

Сетевая модель не доделана. В Docker есть bridge-сеть, port mapping, с недавних пор - overlay-сети. В rkt 0.1 сетевая конфигурация описана в спецификации, но реализована частично. Запустить контейнер без сети - можно. Пробросить порты с нормальной конфигурацией - надо читать исходники.

User namespaces. Одна из заявленных фич - поддержка user namespaces, когда root внутри контейнера не является root на хосте. Это реально важно для безопасности. В релизе это задокументировано, но ещё не полностью работает из коробки.

Наш вывод

Docker остаётся выбором для всех наших проектов. Не потому что мы не читаем анонсы, а потому что переход потребует: нового формата образов, нового инструментария, нового понимания того, как отлаживать сетевые проблемы - и всё это ради преимуществ, которые пока работают в теории лучше, чем на стенде.

Архитектура rkt при этом - не маркетинг. Daemon-free подход с контейнерами как дочерними процессами init - это честная инженерная идея, и критику модели Docker-daemon мы считаем обоснованной. Проблема в том, что хорошая идея и готовый инструмент - разные вещи.

Пощупаем rkt на стенде. Если за несколько месяцев появится нормальная работа с сетью, какой-то путь для существующих Docker-образов и хотя бы один внешний инструмент с поддержкой - разговор станет предметным. Пока смотрим.