Rocket (rkt)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 20:53, 16 февраля 2019.
rkt
Rkt logo.png
Разработчики: CoreOS
Выпущена: December 2014; 7 years ago (2014-12)
Постоянный выпуск: 1.30.0 / 16 April 2018 года; 4 years ago (2018-04-16)
Операционная система: Linux, Windows, macOS
Веб-сайт coreos.com/rkt

Rocket (rkt) является альтернативой Docker, разработанной для серверной среды с наиболее строгими требованиями к безопасности и производительности. rkt ориентирован на спецификацию App Container, набор простых и открытых инструкций для формата портативных контейнеров. Инструмент командной строки rkt позволяет запускать контейнеры App Container. App Container — это спецификации на формат образов, среда выполнения и механизм распространения. Rocket — это первая реализация App Container, разработчики надеются, что не единственная[Источник 1].

Отличия между rkt и Docker

rkt docker
Запуск образов Docker Да Да
Подпись образа Проверка подписей по умолчанию Клиентоориентированная; проверка подписи в демоне Docker
Права доступа Получение, подтверждение, проверка подписи на непривилегированного пользователя Все операции выполняются демоном Docker как суперпользователем
Компонуемость Правильная модель процессов Unix, управление процессами с systemd, стандартным sysv init, runit и т.д. Требуются пользовательские встроенные системы инициализации для управления дочерними процессами
Съемная изоляция Несколько сред изоляции stage1. От chroot до cgroups и KVM Изоляция только с точки зрения параметров демона Docker для сетевого моста или полного привилегированного режима
Создание образа Инструмент для сборки контейнеров на основе сценариев оболочки, использующей похожие инструменты Unix Сборка определена в Dockerfile, собрана демоном Docker (как суперпользователь)
Распределение контейнеров Контейнерные образы - это набор файлов в архиве, обслуживаемый обычным HTTPS. DNS-обнаружение пользовательских пространств имён и подписей Docker-реестр. Ограниченное пространство имен по умолчанию (docker.com)

Docker Engine, или просто Docker, это система контейнеров для приложений, реализованная в качестве API демона. Docker использует, так называемое имя "Docker Image", например Quay, для того чтобы скачивать, распаковывать и контролировать приложения. Функционально rkt очень похож на Docker, однако он может использовать не только "Docker Image", но и "App Container Images" (ACIs), используемое в спецификации App Container (appc)[Источник 2].

Кроме поддержки ACIs, rkt так же имеет другую архитектуру, разработанную с упором на компоновку и безопасность.

Модель процессов

В момент записи, демон Docker Engine загружает контейнер образа, запускает процессы контейнера, подключает удаленное Docker Engine, или просто Docker, это система контейнеров для приложений, реализованная в качестве API и далее работает в качестве демона логгирования, при этом все это реализуется в качестве одного централизованного процесса, запускаемого root пользователем. Такая централизованная структура весьма хороша для разработки, но она не является наилучшим решением для Unix, и ее системы разделения прав доступа; в дальнейшем это сделает Docker тяжело интегрируемым с системами инициализации Linux, такими как upstart и systemd. Запуская контейнер Docker из командной строки, мы обращаемся к его Docker Engine, или просто Docker, это система контейнеров для приложений, реализованная в качестве API демону, который в свою очередь создает контейнер, при этом системы инициализации не могут напрямую следить за тем или иным процессом контейнера.

Rocket не имеет централизованного демона "инициализации", вместо это он запускает процессы контейнера командами от клиента, что делает его совместимым с системами инициализации, такими как systemd, upstart и другими.

На рисунке 1 можно увидеть модель процессов Rocket.

Рисунок 1 – Модель процессов

Права доступа

Rkt использует стандартные групповые разрешения Unix для управления правами доступа для различных операций. После первой настройки директории rkt data (например с помощью команды rkt install), скачивание и проверка подписей могут осуществляется непривилегированными пользователями.

На рисунке 2 можно увидеть права доступа в Rocket.

Рисунок 2 – Права доступа

rkt и runC

runC это низкоуровневый контейнер, он является реализацией спецификации Open Container Initiative. runC создан, чтобы помочь пользователям понять низкоуровневые детали операционной системы и ее настроек. В runC требуется отдельно загружать или подписывать образы контейнеров и “высокоуровневые инструменты” для подготовки файловой системы для контейнера. runC так же не имеет централизованного демона и использует правильно сконфигурированный “набор OCI”, который может быть интегрирован с системами инициализации upstart и systemd. rkt по функционалу похож на runC, но при этом не требует от пользователя понимания низкоуровневых деталей функционирования операционной системы, он может быть просто запущен командой rkt run coreos.com/etcd, version=v2.2.0. Он может скачивать как “Docker Image”, так и “App Container Images”.

Так как rkt не имеет централизованного демона, он может быть интегрирован с системами инициализации, такими как upstart и systemd[Источник 3].

rkt и LXC/LXD

Это системный контейнер, разработанный для извлечения “полносистемные” контейнеров, предназначенных для хранения всей операционной системы в одном образе. Процесс LXC обычно используется для запуска дистрибутивов Linux, таких как Debian, Fedora, Arch и других, при этом для пользователя работа с LXC почти ничем не отличается от работы с образами Virtual Machine.

LXC так же может использоваться для запуска (но не для скачивания) контейнеров приложений, но это требует понимания низкоуровневых аспектов системы и как правило не используется для этого. LXC может скачивать и подписывать “полносистемные” контейнеры. LXC не имеет централизованного демона, он может быть интегрирован с системами инициализации, такими как upstart и systemd.

LXD похож на LXC, но использует REST API поверх liblx для управления процессом контейнера. Это гарантирует то, что демон LXD не станет причиной падения процесса, ведь даже если что-то случится с ним, процесс контейнера не пострадает. В остальном он идентичен LXC.

rkt может скачивать, подписывать, и запускать образы контейнеров приложений. Он не создан для запуска “полносистемные” контейнеров, а вместо этого используется для индивидуальных приложений таких как web-приложения, базы данных, кэшы[Источник 4].

rkt и OpenVZ

Как и LXC, OpenVZ это системный контейнер, разработанный для извлечения “полносистемные” контейнеров, предназначенных для хранения всей операционной системы в одном образе, используемый для дистрибутивов Linux, таких как Debian, Fedora, Arch.

OpenVZ может использовать как для запуска и подписи контейнеров, так и для скачивания их с различных зеркал. OpenVZ также не имеет централизованного демона, он может быть интегрирован с системами инициализации, такими как upstart и systemd[Источник 5].

Отличия от rkt соответственно те же, что и у LXC.

rkt и systemd-nspawn

Systemd-nspawn это контейнер, разработанный для взаимодействия с процессами внутри контейнеров Linux. System-nspawn получает имя контейнера из “namespace spawn”, что означает использование только хэндла процесса, но не его ресурсов, таких как память, CPU и другие. Systemd-nspawn может запускать контейнеры приложений и системные контейнеры, но не может сам их загружать и подписывать. Systemd-nspawn также не имеет централизованного демона, он может быть интегрирован с системами инициализации, такими как upstart и systemd.

По умолчанию rkt использует systemd-nspawn для настройки пространства имен для контейнеров приложений[Источник 6].

rkt и machinectl

Machinectl это системный менеджер, который используют для контроля состояния системы, на которой запущен systemd, и реализации запросов к ней. Эти системы могут являться зарегистрированными виртуальными машинами, контейнерами system-nspawn, или других runtime контейнеров, которые можно зарегистрировать менеджером регистрации systemd или system-machined. Кроме этого machinectl может загружать, подписывать, извлекать и запускать контейнеры systemd-nspawn из уже извлеченных материалов образа. Обычно эти образы являются “полносистемными” контейнерами, в контейнерах systemd-spawn уже пройден этап исполнения аргумента “--boot”.

На хосте с systemd, rkt интегрируется с systemd-machined так же как и machinectl: все поды[1], создаваемые rkt будут зарегистрированы как машины на хосте, после чего с ними можно будет взаимодействовать с помощью команд machinectl. Хотя rkt больше ориентирован на приложения, он абстрагирует жизненный цикл своих подов от пользователей. Так же rkt предоставляет более удобную и настраиваемую среду, позволяющую находить, загружать и подписывать образы, наряду с поддержкой нескольких типов образов. В отличие от machinectl, rkt работает с system-nspawn напрямую, вместо создания сервиса systemd, позволяющего взаимодействовать с любой операционной системой. Более того, кроме выделения пространства имен, rkt может так же выделять ресурсы и другие необходимые компоненты, определенные в спецификации appc[Источник 7].

rkt и qemu-kvm, lkvm

qemu-kvm и lkvm это пользовательские инструменты для извлечения “полносистемных” образов из виртуальных машин, используя инфраструктуру Linux KVM. Образ системы как правило включает в себя бутлоадер, ядро, root файловую систему и предустановленные приложения. Обычно qemu-kvm используется для систем IaaS, таких как OpenStack, Eucalyptus и других. Инфраструктура Linux KVM является достаточно доверенной для запуска арендованных виртуальных машин, так же она достаточна надежна для запуска образов систем, точное происхождение которых вы не знаете. qemu-kvm и lkvm не имеют централизованных демонов, и могут быть интегрированы с системами инициализации, такими как upstart и systemd.

rkt может использовать lkvm для обеспечения большей безопасности контейнеров Linux, с небольшими жертвами в плане производительности и гибкости; это опция может быть настроена при использовании lkvm (Clear Containers) stage1[Источник 8].

Примеры

Создание приложения "hello go"

package main

import (
	"log"
	"net/http"
)

func main() {
	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
		log.Printf("request from %v\n", r.RemoteAddr)
		w.Write([]byte("hello\n"))
	})
	log.Fatal(http.ListenAndServe(":5000", nil))
}

Построение статически связанного двоичного файла Go:

Далее нам нужно построить наше приложение. Мы собираемся статически связать наше приложение, чтобы мы могли отправить образ контейнера приложения без внешних зависимостей.

$ CGO_ENABLED=0 go build -ldflags '-extldflags "-static"'

Прежде чем продолжить, убедитесь, что созданный двоичный файл связан статически:

$ file hello
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped
$ ldd hello
	not a dynamic executable

Создание образа

Для создания образа можно использовать acbuild.

Следующие команды создадут ACI, содержащий наше приложение и важные метаданные.

acbuild begin
acbuild set-name example.com/hello
acbuild copy hello /bin/hello
acbuild set-exec /bin/hello
acbuild port add www tcp 5000
acbuild label add version 0.0.1
acbuild label add arch amd64
acbuild label add os linux
acbuild annotation add authors "Carly Container <carly@example.com>"
acbuild write hello-0.0.1-linux-amd64.aci
acbuild end

Запуск

Запуск локального образа приложения

# rkt --insecure-options=image run hello-0.0.1-linux-amd64.aci

Обратите внимание, что --insecure-options=image требуется, потому что по умолчанию rkt ожидает, что наши изображения будут подписаны.

На данный момент наше приложение hello работает и готово к обработке HTTP-запросов.

Чтобы остановить контейнер, передайте три escape-символа ( ^]^]^]), которые генерируются Ctrl-] на клавиатуре US. Вы также можете запустить rkt в качестве демона. По умолчанию rkt назначает работающему контейнеру IP-адрес. Используйте rkt list, чтобы узнать, что это такое:

# rkt list
UUID		APP	IMAGE NAME		STATE	NETWORKS
885876b0	hello	example.com/hello:0.0.1	running	default:ip4=172.16.28.2

После этого вы можете использовать тот IP на порте 5000:

$ url 172.16.28.2:5000
hello

Примечания

  1. Базовая единица выполнения

Источники

  1. Rocket (rkt) - Overview // CoreOS. Дата обновления: 15.01.2018. URL: https://coreos.com/rkt (дата обращения: 09.11.2018)
  2. Rocket (rkt) - rkt vs Docker // CoreOS. Дата обновления: 23.11.2017. URL: https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html#rkt-vs-docker (дата обращения: 09.11.2018)
  3. Rocket (rkt) - rkt vs runC // CoreOS. Дата обновления: 23.11.2017. URL: https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html#rkt-vs-runc (дата обращения: 09.11.2018)
  4. Rocket (rkt) - rkt vs LXC/LXD // CoreOS. Дата обновления: 23.11.2017. URL: https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html#rkt-vs-lxclxd (дата обращения: 09.11.2018)
  5. Rocket (rkt) - rkt vs OpenVZ // CoreOS. Дата обновления: 23.11.2017. URL: https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html#rkt-vs-openvz (дата обращения: 09.11.2018)
  6. Rocket (rkt) - rkt vs systemd-nspawn // CoreOS. Дата обновления: 23.11.2017. URL: https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html#rkt-vs-systemd-nspawn (дата обращения: 09.11.2018)
  7. Rocket (rkt) - rkt vs machinectl // CoreOS. Дата обновления: 23.11.2017. URL: https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html#rkt-vs-machinectl (дата обращения: 09.11.2018)
  8. Rocket (rkt) - rkt vs qemu-kvm, lkvm // CoreOS. Дата обновления: 23.11.2017. URL: https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html#rkt-vs-qemu-kvm-lkvm (дата обращения: 09.11.2018)