Docker linux container runtime

Среды запуска контейнеров (container runtimes) Часть 1: Введение в среды запуска контейнеров

Один из терминов, который вы часто слышите, имея дело с контейнерами — «container runtime» (далее «runtime» переводится как «среда запуска» — прим. переводчика). «Среда запуска контейнеров» может иметь различные значения для разных людей, так что нет ничего удивительного в том, что это такой сбивающий с толку и смутно понятный термин, даже в самом сообществе пользователей и разработчиков Docker.

Этот пост — первый в серии, которая состоит из 4 частей:

1. Часть 1: Введение в среды запуска контейнеров: почему они так сбивают с толку?
2. Часть 2: Глубокое погружение в низкоуровневые среды запуска (eng)
3. Часть 3: Глубокое погружение в высокоуровневые среды запуска
4. Часть 4: Среды запуска в Kubernetes и CRI

(На картинке игра слов: Не уверен относится ли это к средам запуска Kubernetes контейнера, низкоуровневой среде запуска контейнера или продолжительности фильма — примечание переводчика)

По традиции, программист может понимать «runtime» либо как фазу жизненного цикла программы, во время которой она выполняется, либо как среду языка, которая поддерживает это выполнение. Примером здесь служит среда выполнения Java HotSpot. Последнее значения является ближайшим к «runtime» контейнера. Среда запуска контейнера ответственна за все фазы запуска контейнера, которые не занимаются непосредственным запуском самой программы. Как мы увидим далее в этой серии, среды запуска осуществляют различные уровни функций, но функция «запускает контейнер» для инструмента — в сущности всё, что нужно, чтобы назвать его средой запуска контейнера.

Если вы не слишком хорошо знакомы с контейнерами, познакомьтесь сначала с этими материалами и возвращайтесь:

Почему среды выполнения контейнеров так сбивают с толку?

Docker был выпущен в 2013 и решил множество проблем разработчиков тем, что запускал контейнеры непрерывной цепочкой. Он включал в себя:

• Формат образа контейнера
• Метод для построения образов контейнеров (Dockerfile/docker build)
• Возможность управлять образами контейнеров (docker images, docker rm, etc.)
• Возможность управлять экземплярами контейнеров (docker ps, docker rm, etc.)
• Возможность делиться образами контейнеров (docker push/pull)
• Возможность запускать контейнеры (docker run)

Из-за этого, Docker, Google, CoreOS и другие поставщики создали Open Container Initiative (OCI). После этого они отделили свой код для запуска контейнеров как инструмент и библиотеку, названную runc, и передали его OCI, как эталонную реализацию OCI спецификации среды запуска.

По началу вопрос что именно Docker передал OCI сбивал с толку. То что они передали было стандартным способом запуска контейнеров и больше ничем иным. Они не включили формат образа или протоколы получения/выгрузки образа контейнера из/в регистр образов (хранилище образов). Когда вы запускаете Docker контейнер, вот какие действия Docker на самом деле выполняет:

1. Загрузка образа.
2. Распаковка образа в «пакет» (bundle). Это действие выравнивает слои в одну файловую систему.
3. Запуск контейнера из пакета.

Низкоуровневые и высокоуровневые среды запуска контейнеров.

Когда разработчики думают о средах запуска контейнеров, то, вот, список некоторых примеров, которые могут прийти в голову: runc, lxc, lmctfy, Docker (containerd), rkt, cri-o. Каждый из них разработан для различных ситуаций и осуществляет различные функции. Некоторые, такие как containerd и cri-o, на самом деле используют runc для запуска контейнера, но осуществляют управление образами и имеют API поверх этого. Вы можете думать об этих функциях — которые включают в себя перенос образов, управление образами, распаковка образов и API — как о высокоуровневых функциях по сравнению с низкоуровневой реализацией в runc.

Держа это в уме, вы можете увидеть, что область среды запуска контейнера довольно сложна. Каждая среда запуска покрывает разные части этого спектра от низкоуровневого к высокоуровневому. Вот очень субъективная диаграмма:

На практике, среды запуска контейнеров, которые фокусируются просто на запуске контейнеров, обычно упоминаются как «низкоуровневые среды запуска контейнеров». Другие же среды запуска, поддерживающие функции более высокого уровня, такие как управление образами и различные gRPC/Web API, обычно упоминаются как «высокоуровневые инструменты контейнера», «высокоуровневые среды запуска контейнеров» или обычно просто как «среды запуска контейнеров». Я буду ссылаться на них как на «высокоуровневые среды запуска контейнеров». Важно заметить, что низкоуровневые и высокоуровневые среды запуска фундаментально различные вещи, которые решают различные проблемы.

Контейнеры реализованы с помощью механизмов пространств имен и cgroups Linux. Пространства имен дают вам возможности виртуализации системных ресурсов, таких как файловая система или работа с сетью, для каждого контейнера. Cgroups предоставляет путь ограничения количества ресурсов, таких как CPU и память, которые каждый контейнер может использовать. На самом низком уровне среды запуска контейнеров ответственны за настройку этих пространств имен и cgroups. Поддержка низкоуровневых сред запуска использует именно эти функции операционной системы.

Обычно разработчики, которые хотят запускать приложения в контейнерах, нуждаются в больших возможностях, чем предоставляют низкоуровневые среды запуска. Им необходимы API и функции вокруг форматов образов, управление образами и возможность делиться образами. Эти функции предоставляют высокоуровневые среды запуска. Низкоуровневные среды запуска просто не имеют достаточно возможностей для подобных ежедневных нужд. По этим причинам единственными кто будут использовать низкоуровневыми средами запуска будут разработчики высокоуровневых сред запуска и инструментов для контейнеров.

Разработчики низкоуровневых сред запуска скажут, что высокоуровневые среды запуска, такие как containerd и cri-o, на самом деле не среда запуска контейнера, так как с их точки зрения они делегируют выполнение запуска контейнера runc. Но с точки зрения пользователя они являются полноценными инструментами, которые предоставляют возможность запускать контейнеры. Одна реализация может поменяться на другую, так что имеет смысл называть их средой запуска с этой точки зрения. Несмотря на то, что containerd и cri-o оба используют runc — это два очень разных проекта с поддержкой очень разных функций.

В следующий раз.

Я надеюсь, что помог разобраться в том, что такое среды запуска контейнеров и почему их так сложно понять. Не стесняйтесь оставлять мне комментарии к статье (на сайте автора — прим. переводчика) или на Twitter и дайте мне знать, что в средах запуска контейнеров было самым трудным для понимания.

В следующем посте я уйду с головой в низкоуровневые среды запуска контейнеров. В нём я расскажу о том, что именно делают низкоуровневые среды запуска контейнеров. Я буду говорить как о популярных низкоуровневых средах запуска (таких как runc и rkt), так и о непопулярных, но важных (таких как lmctfy). Я даже пройдусь по тому, как запустить простую низкоуровневую среду запуска. Убедитесь, что подписались на мою RSS ленту или Twitter, чтобы получить оповещение когда выйдет следующий пост.

До этих пор вы можете включиться в сообщество Kubernetes через эти каналы:

• Отправляя и отвечая на вопросы на Stack Overflow
• Подписавшись на Twitter @Kubernetesio
• Присоединившись к Kubernetes Slack и общаясь с нами. (Я ianlewis так что скажи «Привет»!)
• Сделав вклад в Kubernetes на GitHub

От переводчика: я в свою очередь выражаю благодарность за проверку черновиков перевода пользователю GDApsy.

Источник

The Industry-Leading Container Runtime

Docker Engine Sparked the Containerization Movement

Docker Engine is the industry’s de facto container runtime that runs on various Linux (CentOS, Debian, Fedora, RHEL, and Ubuntu) and Windows Server operating systems. Docker creates simple tooling and a universal packaging approach that bundles up all application dependencies inside a container which is then run on Docker Engine. Docker Engine enables containerized applications to run anywhere consistently on any infrastructure, solving “dependency hell” for developers and operations teams, and eliminating the “it works on my laptop!” problem.

Why Docker Engine?

Accelerate Innovation

Docker Engine forms the common foundation underlying many cloud-native applications, letting developers turn ideas into reality quickly and securely.

Freedom of Choice

Docker Engine supports any type of application – legacy to cloud-native, monolithic to 12-factor – and works with multiple operating systems, across hybrid/multi-cloud and validated to work with Kubernetes CRI.

Intrinsic Security

Docker Engine is built with security in mind. With Docker Content Trust and FIPS 140-2 validation, Docker Engine users can run containerized applications in highly regulated environments.

Источник