Проект CoreOS, развивающий основанное на идеях контейнерной изоляции серверное окружение, представил выпуск инструментария управления контейнерами rkt 1.0 (ранее известен как Rocket), который позиционируется как более безопасная, переносимая и адаптированная для серверного применения альтернатива инструментарию Docker. Код rkt написан на языке Go и распространяется под лицензией Apache 2.0.

Выпуск rkt 1.0 позиционируется как первый стабильный релиз, пригодный для промышленного применения. Формат данных на диске и интерфейс командной строки зафиксированы и в будущем будут развиваться без нарушения обратной совместимости. API пока стабилизирован не полностью, но уже пригоден для использования и начального внедрения.

Основные особенности rkt:

• Расширенные механизмы обеспечения безопасности: изоляция с использованием гипервизора KVM, поддержка SELinux, SVirt и seccomp, интеграция TPM (Trusted Platform Module), верификация образов по цифровой подписи, разделение привилегий.
• Помимо традиционных контейнеров на основе пространств имён (namespaces) и групп управления (cgroups) изолированные окружения могут создаваться и при помощи других технологий, включая обычный chroot (контейнеры fly) и виртуальные окружения Clear Linux (компактные и быстрые как обычные контейнеры, но предоставляющие более высокий уровень изоляции за счёт применения гипервизора KVM);
• Поддержка образов Docker и контейнеров, построенных в соответствии со спецификацией App Container. Таким образом, rkt может применяться в окружениях, изначально развёрнутых при помощи Docker, или для построении новой инфраструктуры на базе формата App Container;
• Модель выполнения без использования фонового управляющего процесса с применением методов разделения привилегий для минимизации кода, выполняемого с правами root. Операции загрузки контейнера, проверки целостности и верификации по цифровой подписи выполняются под непривилегированным пользователем (в docker все выполняется под root). Для управления контейнером используются средства запуска изолированных окружений, предоставляемые системами инициализации, такими как systemd, runit и upstart, или системами оркестровки кластеров (Nomad, Kubernetes). Rkt позволяет достигнуть значительно более высокого уровня защищённости по сравнению с Docker, в котором все операции проводятся с участием одного централизованного фонового процесса;
• Многоуровневая модульная архитектура, разделяющая операции работы с контейнером, на отдельные стадии, отдельно обрабатывающие этапы настройки файловой системы, подготовки исполняемого окружения и запуска приложений в контейнере. Кроме безопасности подобный подход также позволяет добиться хорошей расширяемости за счёт возможности реализации дополнительных функций через подключение дополнений. Выделяются три основные стадии запуска контейнера:
  • Нулевая стадия, обработка которой производится силами утилиты rkt без привлечения дополнительных средств. На данной стадии производится начальная подготовка контейнера: генерация UUID и манифеста, создания файловой системы для контейнера, настройка директорий для выполнения следующих стадий, копирование исполняемого файла первой стадии в ФС контейнера, извлечение заданных ACI (App Container Image), распаковка образов и копирование приложений в директории третьей стадии;
  • Первая стадия, работа которой обеспечивается отдельным исполняемым файлом, имеющим полномочия настройки cgroups, запуска процессов и выполнения операций под пользователем root. На данной стадии осуществляется создание исполняемой группы на основе ФС, подготовленной в нулевой стадии, установка cgroups, пространств имён и точек монтирования. Настройка производится через генерацию unit-файлов systemd и использование systemd-nspawn для организации работы окружения;
  • Вторая стадия, на которой производится непосредственный запуск приложения в подготовленном контейнере. В частности, на данной стадии выполняется процесс инициализации содержимого контейнера, описанный в манифесте запуска приложения (Application Manifest).