CoreOS и rkt 0.6: смотрим на альтернативу Docker

На прошлой неделе CoreOS официально анонсировала rkt 0.6, и это хороший повод разобраться что вообще такое CoreOS-подход - не только rkt, но и сама операционная система под ним. Мы потратили пару дней на чтение документации, поднятие тестового стенда и честный разговор о том, имеет ли это отношение к нашим задачам прямо сейчас.

Что такое CoreOS как ОС

CoreOS - это не очередной дистрибутив в традиционном смысле. Там нет пакетного менеджера - ни apt, ни yum. Нет стандартного способа поставить что-то руками. Вся идея в том, что хост - это иммутабельная платформа для контейнеров, и ничего лишнего там не живёт.

Несколько вещей, которые сразу бросаются в глаза:

• Автоматические обновления ОС. CoreOS обновляется автоматически по A/B-схеме: пишет обновление на неактивный раздел, при следующей перезагрузке переключается. Если что-то пошло не так - откатывается на предыдущий раздел. Для нас, привыкших к ручному yum update и тщательной проверке перед апгрейдом на CentOS 7, это выглядит и как освобождение, и как источник тревоги одновременно.
• etcd и fleet из коробки. etcd - распределённое key-value хранилище для конфигурации кластера. fleet - systemd-юниты поверх etcd, распределённый scheduler на уровне ОС. Это не Docker Swarm и не Mesos - другой уровень абстракции.
• Минимальный footprint. CoreOS весит значительно меньше стандартного CentOS или Debian. По сути там ядро, systemd, etcd и больше ничего из привычного набора.

rkt 0.6: в чём отличие от Docker

Docker использует демон - долгоживущий процесс, который управляет всеми контейнерами на хосте. rkt работает иначе: каждый запуск контейнера - это отдельный процесс без центрального демона. Никакого docker.sock, никаких прав на сокет.

Команда CoreOS называет это daemon-less подходом и приводит в качестве аргумента безопасность: у Docker-демона root-привилегии, и компрометация демона даёт атакующему полный контроль над хостом. С rkt каждый процесс изолирован, права на запуск контролируются через стандартные механизмы Unix.

Второй аргумент - криптографическая подпись образов. rkt при загрузке образа проверяет GPG-подпись. Для Docker сейчас это не обязательный шаг - можно запустить непроверенный образ с Docker Hub и никто тебя не остановит. В rkt это встроено в процесс по умолчанию.

Третье - pod-модель. rkt запускает не отдельные контейнеры, а pods - группы контейнеров, которые разделяют namespace сети и storage. Это ближе к тому, как Kubernetes думает о задачах.

Выглядит базовый запуск примерно так:

# Запуск контейнера через rkt
sudo rkt run --insecure-skip-verify coreos.com/etcd:v2.0.4

# Или с проверкой подписи (как задумано)
sudo rkt trust --prefix coreos.com/etcd
sudo rkt run coreos.com/etcd:v2.0.4

Синтаксис проще, чем кажется, но непривычно - особенно если последние полгода работал с docker run.

Что мы попробовали

Подняли CoreOS alpha-канал на трёх виртуалках в нашем KVM-кластере. CoreOS ставится через cloud-config - YAML-файл с конфигурацией etcd, fleet и SSH-ключами. Это приятно: стандартный способ описать первоначальную конфигурацию без Ansible-плейбуков поверх.

Запустили несколько контейнеров через rkt, покрутили fleet - как он раскидывает юниты по нодам. Fleet думает в терминах systemd-юнитов, что для нас после работы с systemd на CentOS 7 достаточно понятно. Unit-файл для fleet-а выглядит как обычный systemd-юнит с несколькими дополнительными директивами для размещения.

Что понравилось: стек очень целостный. etcd, fleet, rkt, CoreOS - это одна команда с единым видением. Нет ощущения что несколько независимых проектов склеены скотчем.

Что насторожило:

• Отсутствие пакетного менеджера реально ограничивает. Нужен специфический инструмент на хосте - нужно либо упаковывать его в контейнер, либо использовать systemd-nspawn. Для нашего стека, где часть задач выполняется host-level утилитами, это изменение подхода, а не просто смена дистрибутива.
• Автообновления требуют доверия. Idempotent-перезагрузки и A/B-разделы - хорошая архитектура, но «ОС обновляется автоматически» в production требует либо полного доверия к CoreOS, либо настройки locksmith (утилита для управления окном обновлений). Без неё все ноды могут обновиться и перезагрузиться в разное время - нехорошо для кластерных сервисов.
• Экосистема вокруг rkt значительно беднее Docker. Docker Hub, Docker Compose, Swarm, registry-инфраструктура - это годы работы сообщества. rkt поддерживает Docker-образы через --insecure-skip-verify, что в общем-то обнуляет весь аргумент про подпись, если команда тащит образы с Hub без проверки.

Насколько это применимо у нас прямо сейчас

Честный ответ: интересно, но не готово для нашего стека в текущем виде.

Docker с Compose мы используем активно - локальные окружения разработчиков, тестовые стенды, начинаем разворачивать на prod. Переходить на rkt означало бы переписать всю инфраструктуру образов и инструментарий - ради чего? Аргумент про daemon-less безопасность реальный, но Docker 1.6 работает стабильно, и мы умеем его контролировать.

CoreOS как ОС интересна для сценария «чистый лист» - нового кластера под контейнерную нагрузку, где нет груза существующих практик. Для наших CentOS 7-серверов с Ansible-провизионингом это не замена, это другой мир.

rkt 0.6 - это версия 0.6. Нет смысла делать выводы про production-готовность на основе 0.6.

Оставляем тестовый стенд жить, будем смотреть как развивается. Kubernetes уже использует Pod-модель близкую к rkt; если CoreOS и Kubernetes движутся в одну сторону, это может стать аргументом пересмотреть оценку позже. Но сейчас - скорее академический интерес.