Проект CoreOS (https://www.opennet.ru/opennews/art.shtml?num=40275), развивающий основанное на идеях контейнерной изоляции серверное окружение, представил (https://coreos.com/blog/rkt-hits-1.0.html) выпуск инструментария управления контейнерами rkt 1.0 (https://coreos.com/rkt/) (ранее известен как Rocket), который позиционируется как более безопасная, переносимая и адаптированная для серверного применения альтернатива инструментарию Docker. Код rkt написан на языке Go и распространяется (https://github.com/coreos/rkt) под лицензией Apache 2.0.

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

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

-  Расширенные механизмы обеспечения безопасности: изоляция с использованием гипервизора KVM (https://coreos.com/rkt/docs/latest/running-lkvm-stage1.html), поддержка SELinux, SVirt и seccomp, интеграция TPM (https://tectonic.com/trusted-computing) (Trusted Platform Module), верификация образов по цифровой подписи,  разделение привилегий.

-  Помимо традиционных контейнеров на основе пространств имён (namespaces) и групп управления (cgroups) изолированные окружения могут создаваться и при помощи других технологий, включая обычный chroot (контейнеры fly) и виртуальные окружения Clear Linux (https://www.opennet.ru/opennews/art.shtml?num=42272) (компактные и быстрые как обычные контейнеры, но предоставляющие более высокий уровень изоляции за счёт применения гипервизора KVM);

-  Поддержка образов Docker и контейнеров, построенных в соответствии со спецификацией App Container (https://github.com/coreos/rocket/blob/master/app-container/S...). Таким образом, 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).

URL: https://coreos.com/blog/rkt-hits-1.0.html
Новость: https://www.opennet.ru/opennews/art.shtml?num=43824