От переводчика

Это перевод статьи ссылка

Автор оригинальной  статьи: Ian Lewis.

Сылка на прошлую часть

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

Высокоуровневые среды являются наивысшим звеном. Low-level среды отвечают за запуск контейнеров, высокоуровневые же отвечают за транспорт и менеджмент образов контейнеров, распаковку и передачу контейнера низкоуровневым средам для запуска. Обычно high-level runtimes состоят из демона и API, которое позволяет приложениям запускать контейнеры и мониторить их, они передают необходимые команды низкоуровневым или другим высокоуровневым средам.

High-level runtimes поддерживают функции низкоуровневых сред, но для этого они используют отдельный контейнер. Например, одной из таких функций является управление сетью, и разрешение использовать контейнером сеть другого немспейса.

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

Примеры высокоуровневых сред запуска

Для лучшего понимания высокоуровневых сред, лучше всего посмотреть на живые примеры. Как и низкоуровневые, каждая high-level среда имеет особенности.

Docker

Докер это один из первых опенсорс проектов container runtime. Он был разработан компанией dotCloud в рамках “Платформа как услуга” и использовался для запуска веб приложений в контейнерах.

Docker умеет собирать, упаковывать, делиться и запускать контейнеры. Docker представляет собой клиент серверную архитектуру и является монолитным приложением – состоит из демона dockerd и docker client application. Вместе с API демон отвечает за логику сборки контейнеров, управлением образов и запуск самих контейнеров. Клиент отвечает за отправку команд и работу с информацией, приходящей в ответ от демона.

Это была первая популярная среда запуска объединившая все особенности необходимые для жизненного цикла сборки и запуска контейнеров.

Докер одновременно включает в себя функции низкоуровневых и высокоуровневых сред запуска, но он разделился на два отдельных проекта runc и containerd. Сейчас Docker состоит из демонов dockerd, docker-containerd, docker-runc. docker-containerd, docker-runc это ванильная версия пакетов containerd и runc.

Dockerd отвечает за сборку образов и использует docker-containerd для управления ими и запуска контейнеров. Сборка образа контейнера — это логическая интерпретация команд из Dockerfile при помощи containerd, и сохранение результата в файловую систему контейнера в виде образа.

containerd

containerd это высокоуровневая среда запуска, которая была отделана от Docker в отдельный проект. Как и runc, которая была отделена как низкоуровневая среда, так и containerd была отделена от Docker в самостоятельную высокоуровневую среду запуска. Containerd позволяет скачивать образы, управлять ими, и запускать контейнеры. Когда необходимо запустить контейнер, Containerd распаковывает образ, используя стандарт OCI и передает необходимую информацию runc для запуска.

Containerd есть API и клиентское приложение чтобы можно было взаимодействовать со средой запуска. Этот клиент - ctr.

Crt используется для скачяивания образов:

$ sudo ctr images pull docker.io/library/redis:latest

Просмотр всех образов:

$ sudo ctr images list

Запуска контейнера:

$ sudo ctr container create docker.io/library/redis:latest redis

Просмотра запущенных контейнеров:

$ sudo ctr container list

И остановки контейнеров:

$ sudo ctr container delete redis

Эти команды показывают, как просто пользователь использует Docker. В отличии от Docker Containerd ориентирован исключительно на запуск контейнеров, поэтому он не предоставляет механизма для создания контейнеров. Docker был ориентирован на варианты использования пользователеми и разработчиками, в то время как containerd ориентирован на определенный функционал, например, запуск контейнеров на серверах. Для создания образов контейнеров, используются другие инструменты.

rkt

В прошлом посте я упоминал что rkt вклчючает в себя функции сред двух типов (low-level high-level). Как и Docker, rkt позволяет собирать, управлять образами в локальном репозитории и запускать контейнеры всего одной командой. Rkt не достает до функциональности Docker, он не располагает API.

Вы можете скачивать образы из других репозиториев:

$ sudo rkt fetch coreos.com/etcd:v3.3.10

Вы можете посмотреть локальные образы:

$ sudo rkt image list
ID                      NAME                                    SIZE    IMPORT TIME     LAST USED
sha512-07738c36c639     coreos.com/rkt/stage1-fly:1.30.0        44MiB   2 minutes ago   2 minutes ago
sha512-51ea8f513d06     coreos.com/oem-gce:1855.5.0             591MiB  2 minutes ago   2 minutes ago
sha512-2ba519594e47     coreos.com/etcd:v3.3.10                 69MiB   25 seconds ago  24 seconds ago

И удалить их:

$ sudo rkt image rm coreos.com/etcd:v3.3.10                       
successfully removed aci for image: "sha512-2ba519594e4783330ae14e7691caabfb839b5f57c0384310a7ad5fa2966d85e3"
rm: 1 image(s) successfully removed

Хотя rkt, уже не очень активно развивается, это интересный инструмент и важная часть истории контейнерных технологий.

Onward, Upward

В следующем посте мы поговорим об оркестраторах, и я расскажу о перспективах Kubernetes и как он работает. Обязательно добавь мой RSS канал или подпишетесь в твиторе, чтобы получать уведомление о новых постах.

А пока вы можете по изучать кубер тут:

• Ответы на вопросы Stack Overflow

• Кубер в твиторе @Kubernetesio 

• Заходите в Slack чат. (Я ianlewis)

• Вносите свой вклад в Кубернетс GitHub

Если у вас есть какие-либо предложения или идеи для блога, присылайте их мне в Твиттере  @IanMLewis

Спасибо Craig Box, Marcus Johansson, Steve Perry, and Nicolas Lacasse за проверку черновиков этого поста..