Windows containers vs linux containers

Контейнеры и Windows. От Hello World до Kubernetes. Часть первая, вводная

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

Контейнеры в Windows

Многие разработчики, пишущие на .NET или под SQL Server, кусали локти и завидовали своим коллегам по цеху из мира Linux

Действительно, контейнеры в Windows до недавнего времени были экзотикой. А хуже всего то, что документацию приходилось собирать по крохам, на каждом ресурсе будь то официальный сайт Docker или Microsoft, всё представлялось в обзорном виде без описания «как и почему», а через месяц-два и существующая информация устаревала. И в этом нет ничего сверхъестественного – контейнеры и технологии с ними связанные развиваются с какой-то нереальной скоростью.

В настоящий момент с документацией все стало лучше и что бы погрузится в мир контейнеров для Windows достаточно почитать официальную документацию от Microsoft и следить за её изменениями. Что интересно, документация написана хорошо и на русском языке, хотя при глубоком изучении вам не избежать переходов по ссылкам на различные ресурсы по типу https://www.docker.com/ или https://kubernetes.io/ где всё написано на старом добром английском языке.

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

Вы не можете запускать контейнеры Windows на Linux и на Windows*

Контейнерные технологии позволяют легко обращаться с окружением благодаря наличию переконфигурированных образов приложений. Это как Apple Appstore или Google Play, но только для инженеров и разработчиков. Как и в магазинах для мобильных приложений вы не можете поставить приложение из Google Play на iOS. Так и на Docker хосте с операционной системой Linux вы не можете запустить контейнер с операционной Windows. Верно и обратное утверждение, правда с некоторыми «но», так как Docker хост с Windows всё же может предоставить Linux окружение для запуска контейнеров.

Так же вы не можете запустить контейнер Windows в среде Windows не убедившись в совместимости версий операционной системы. Работая с контейнерами от Microsoft вам придется оглядываться на Windows Container Version Compatibility и периодически открывать данный документ.

Говоря о версионности — Microsoft с приходом контейнеров приняла решение о выпуске новых полугодовых версий Windows semi-annual. Это такие версии как windows server 1703, 1709, 1803, 1809, 1903. Цифры означают год и месяц выхода, а поддерживаются они по 18 месяцев. Первые две уже покоятся с миром и находятся в end of service. Кроме того, существуют версии LTS такие как Windows Server 2016 и Windows Server 2019. Список версий.

Так вот, если вы собрали контейнер на хосте с версией Windows 1803, то и запустить данный контейнер вы можете только на хостах с Windows 1803. Соответственно, чтобы не пересобирать каждый раз сам контейнер вам придется использовать LTS версию Windows, что при современных скоростях развития технологий не всегда оправдано. Либо всё же думать о версионности и таки постоянно пересобирать контейнеры следуя шаг в шаг за программой semi-annual.

Тэг latest в Dokerfile для Windows контейнеров присутствует не всегда и вообще он deprecated. По-хорошему вам всегда надо знать, что у вас за версия Windows и вносить соответствующие правки в Dockerfile.

Контейнеры — это часть подхода «Инфраструктура как код». Пересобирать контейнеры нужно постоянно, это не только просто и весело, но в этом и заключается основная магия, которая позволяет приложениям всегда работать на свежем улучшенном софте. Но в нашем случае мы сталкиваемся с ограничением: не получится держать универсальный Dockerfile под все системы Windows. Это необходимо учитывать.

Всё вышесказанное справедливо для контейнеров, запущенных в режиме process isolation. В режиме Hyper-V isolation действует обратная совместимость – вы можете запускать все контейнеры, которые собраны на текущей и предыдущей версиях. В общем-то с помощью Hyper-V isolation можно на хосте Windows запускать и Linux контейнеры. Но такой режим пока что поддерживает меньше плюшек, чего только стоит отсутствие Kubernetes.

Отличие process isolation и Hyper-V isolation это тема отдельной статьи. Сейчас скажу только то, что сценарии с Hyper-V isolation мне не совсем очевидны, а по умолчанию в Windows используется process isolation.

Отдельной головной болью является поиск правильных по версии образов на Docker Hub. Некоторые образы вообще отсутствуют для Windows. Например, официальной сборки Nginx, MySQL, Nodejs, как и сотни других приложений под Windows вы не найдете и вам придется собирать контейнеры самостоятельно либо использовать контейнеры, собранные и предоставленные участниками сообщества.

Windows стоит денег.

Не стоит забывать и о том, что Windows это по-прежнему платная штука. К примеру, Semi-annual версии доступны по подписке Visual Studio или при наличии Software Assurance в действующем лицензионном контракте Microsoft. Ссылка.

Но у Microsoft есть большое количество способов получит платное за бесплатно. Это и программа BizSpark и всякие trial версии Windows Server 2019 на 180 дней и прочее и прочее.

Контейнеры Windows не легковесны.

Принято считать, что контейнеры легковесны, но что правда для Linux не всегда правда для Windows. Подавляющее большинство контейнеров Windows, на первый взгляд весит непозволительно много. Да и на второй взгляд впечатление не меняется. Например, базовый образ aspnet:4.8 весит порядка 7.5 Гб.

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

Да вы можете в некоторых сценариях использовать легковесный Windows Nano Server, но увы он имеет кучу ограничений. И тем более вам не по пути с Windows Nano Server если вы разрабатываете под .Net Framework.

Для управления надо хорошо знать CMD и Powershell.

Скорее всего работать вам придется с core версией Windows Server на Docker хостах. Windows Server имеет огромное количество возможностей по удаленному управлению. Общий подход такой, что имея Windows Server с графическим интерфейсом вы можете подключатся всеми графическими оснастками к любому core серверу.

Данный подход не работает в сценариях с контейнерами, хотя в контейнере и находится полноценная версия Windows Server. Внутрь контейнера Windows теоретически можно подключится по WMI, но это не так просто, хотя бы потому что хостовая ОС будет перехватывать данный трафик на себя. Контейнеров на хосте может быть несколько десятков и сотен, и в таком случае направлять трафик в нужный контейнер это целое дело.

CMD и Powershell понадобятся как для администрирования контейнеров так и самого хоста на котором установлен Docker. Так же знание данных оболочек необходимо для написания Dockerfile, так как все инструкции RUN будут выполнятся в вышеупомянутых командных оболочках.

Запомнить все длинные командлеты Powershell довольно сложно. Это вам не лаконичные команды bash. Хотя сейчас большинство командлетов имеет понятные любому Linux инженеру алиасы. В powershell можно использовать:

Из крайне полезных вещей, это то, что с помощью Powershell можно запустить в контейнере простой веб сервер для целей тестирования. В Powershell всё представляется в виде объектов. Если вы сторонник ООП, то вы быстро оцените преимущества этой командной оболочки.

В качестве заключения вводной статьи хочу сказать что я нарочно не касался вопроса оркестрации и управления кластерам. Docker на Windows находится в роли догоняющего и приложения по оркестрации такие как Swarm и Kubernetes на Windows реализуют не полный свой функционал.

Так же на текущий момент если вы хотите поднять кластер Docker, то он скорее всего будет мульти платформенный. То есть вам придется иметь в кластере один или более хостов с операционной системой Linux. Например, для Kubernetes, мастер ноды обязаны быть на Linux. А в Swarm, Linux контейнеры понадобятся, например, для реализации балансировщика на Nginx или запуска других популярных приложений для кластера, которые доступны только для Linux.

P.S. Использование Windows в контейнерах имеет весьма ограниченный набор сценариев для применения. Тем не менее эти сценарии могут оказаться крайне продуктивными. Конечно, первое что приходит на ум это web приложения на IIS, но мой опыт показывает, что в контейнерах хорошо изолируются самописные службы Windows и некоторые сервисы такие как MSMQ.

UPD. В статье есть небольшая неточность, кластер Docker на одних только Windows хостах собрать можно. Причем, это не только Swarm, но и развиваемый самим Micrisoft продукт для оркестрации кластера Service Fabric

UPD2. Docker контейнеры для Windows 10 доступны только в режиме Hyper-V isolation и используют отличные от Windows Server базовые образы.

Источник

Недостающее введение в контейнеризацию

Эта статья помогла мне немного углубится в устройство и принцип работы контейнеров. Поэтому решил ее перевести. «Экосистема контейнеров иногда может сбивать с толку, этот пост может помочь вам понять некоторые запутанные концепции Docker и контейнеров. Мы также увидим, как развивалась экосистема контейнеров». Статья 2019 года.

Docker — одна из самых известных платформ контейнеризации в настоящее время, она была выпущена в 2013 году. Однако использование изоляции и контейнеризации началось раньше. Давайте вернемся в 1979 год, когда мы начали использовать Chroot Jail, и посмотрим на самые известные технологии контейнеризации, появившиеся после. Это поможет нам понять новые концепции.

Все началось с того, что Chroot Jail и системный вызов Chroot были введены во время разработки версии 7 Unix в 1979 году. Chroot jail предназначен для «Change Root» и считается одной из первых технологий контейнеризации. Он позволяет изолировать процесс и его дочерние элементы от остальной части операционной системы. Единственная проблема с этой изоляцией заключается в том, что корневой процесс может легко выйти из chroot. В нем никогда не задумывались механизмы безопасности. FreeBSD Jail была представлена в ОС FreeBSD в 2000 году и была предназначена для обеспечения большей безопасности простой изоляции файлов Chroot. В отличие от Chroot, реализация FreeBSD также изолирует процессы и их действия от Файловой системы.

Chroot Jail. Источник: https://linuxhill.wordpress.com/2014/08/09/014-setting-up-a-chroot-jail-in-crunchbang-11debian-wheezy

Когда в ядро Linux были добавлены возможности виртуализации на уровне операционной системы, в 2001 году был представлен Linux VServer, который использовал chroot-подобный механизм в сочетании с «security contexts (контекстами безопасности)», так и виртуализацию на уровне операционной системы. Он более продвинутый, чем простой chroot, и позволяет запускать несколько дистрибутивов Linux на одном VPS.

В феврале 2004 года Sun (позже приобретенная Oracle) выпустила (Oracle) Solaris Containers, реализацию Linux-Vserver для процессоров X86 и SPARC. Контейнер Solaris — это комбинация элементов управления ресурсами системы и разделения ресурсов, обеспечиваемых «zone».

Подобно контейнерам Solaris, первая версия OpenVZ была представлена в 2005 году. OpenVZ, как и Linux-VServer, использует виртуализацию на уровне ОС и был принят многими хостинговыми компаниями для изоляции и продажи VPS. Виртуализация на уровне ОС имеет некоторые ограничения, поскольку контейнеры и хост используют одну и ту же архитектуру и версию ядра, недостаток возникает в ситуациях, когда гостям требуются версии ядра, отличные от версии на хосте. Linux-VServer и OpenVZ требуют патча ядра, чтобы добавить некоторые механизмы управления, используемые для создания изолированного контейнера. Патчи OpenVZ не были интегрированы в ядро.

В 2007 году Google выпустил CGroups — механизм, который ограничивает и изолирует использование ресурсов (ЦП, память, дисковый ввод-вывод, сеть и т. д.) для набора процессов. CGroups были, в отличие от ядра OpenVZ, встроены в ядро ​​Linux в 2007 году.

В 2008 году была выпущена первая версия LXC (Linux Containers). LXC похож на OpenVZ, Solaris Containers и Linux-VServer, однако он использует CGroups, которые уже реализованы в ядре Linux. Затем в 2013 году компания CloudFoundry создала Warden — API для управления изолированными, эфемерными средами с контролируемыми ресурсами. В своих первых версиях Warden использовал LXC.

В 2013 году была представлена первая версия Docker. Он выполняет виртуализацию на уровне операционной системы, как и контейнеры OpenVZ и Solaris.

В 2014 году Google представил LMCTFY, версию стека контейнеров Google с открытым исходным кодом, которая предоставляет контейнеры для приложений Linux. Инженеры Google сотрудничают с Docker над libcontainer и переносят основные концепции и абстракции в libcontainer. Проект активно не развивается, и в будущем ядро этого проекта, вероятно, будет заменено libcontainer.

LMCTFY запускает приложения в изолированных средах на том же ядре и без патчей, поскольку он использует CGroups, namespases и другие функции ядра Linux.

Фото Павла Червиньского для Unsplash

Google — лидер в контейнерной индустрии. Все в Google работает на контейнерах. Каждую неделю в инфраструктуре Google работает более 2 миллиардов контейнеров.

В декабре 2014 года CoreOS выпустила и начала поддерживать rkt (первоначально выпущенную как Rocket) в качестве альтернативы Docker.

Jails, VPS, Zones, контейнеры и виртуальные машины

Изоляция и управление ресурсами являются общими целями использования Jail, Zone, VPS, виртуальных машин и контейнеров, но каждая технология использует разные способы достижения этого, имеет свои ограничения и свои преимущества.

До сих пор мы вкратце видели, как работает Jail, и представили, как Linux-VServer позволяет запускать изолированные пользовательские пространства, в которых программы запускаются непосредственно в ядре операционной системы хоста, но имеют доступ к ограниченному подмножеству его ресурсов.

Linux-VServer позволяет запускать VPS, и для его использования необходимо пропатчить ядро ​​хоста.

Контейнеры Solaris называются Zones.

«Виртуальная машина» — это общий термин для описания эмулируемой виртуальной машины поверх «реальной аппаратной машины». Этот термин был первоначально определен Попеком и Голдбергом как эффективная изолированная копия реальной компьютерной машины.

Виртуальные машины могут быть «System Virtual Machines (системными виртуальными машинами)» или «Process Virtual Machines (процессными виртуальными машинами)». В повседневном использовании под словом «виртуальные машины» мы обычно имеем в виду «системные виртуальные машины», которые представляют собой эмуляцию оборудования хоста для эмуляции всей операционной системы. Однако «Process Virtual Machines», иногда называемый «Application Virtual Machine (Виртуальной машиной приложения)», используется для имитации среды программирования для выполнения отдельного процесса: примером является виртуальная машина Java.

Виртуализация на уровне ОС также называется контейнеризацией. Такие технологии, как Linux-VServer и OpenVZ, могут запускать несколько операционных систем, используя одну и ту же архитектуру и версию ядра.

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

Источник: https://fntlnz.wtf/post/why-containers

Системные контейнеры (например, LXC) предлагают среду, максимально приближенную к той, которую вы получаете от виртуальной машины, но без накладных расходов, связанных с запуском отдельного ядра и имитацией всего оборудования.

VM vs Container. Источник: Docker Blog

Контейнеры ОС vs контейнеры приложений

Виртуализация на уровне ОС помогает нам в создании контейнеров. Такие технологии, как LXC и Docker, используют этот тип изоляции.

Здесь у нас есть два типа контейнеров:

Контейнеры ОС, в которые упакована операционная система со всем стеком приложений (пример LEMP).

Контейнеры приложений, которые обычно запускают один процесс для каждого контейнера.

В случае с контейнерами приложений у нас будет 3 контейнера для создания стека LEMP:

сервер PHP (или PHP FPM).

Докер: контейнер или платформа?

Коротко: и то и другое

Подробный ответ:

Когда Docker начал использовать LXC в качестве среды выполнения контейнера, идея заключалась в том, чтобы создать API для управления средой выполнения контейнера, изолировать отдельные процессы, выполняющие приложения, и контролировать жизненный цикл контейнера и ресурсы, которые он использует. В начале 2013 года проект Docker должен был создать «стандартный контейнер», как мы можем видеть в этом манифесте.

Манифест стандартного контейнера был удален.

Docker начал создавать монолитное приложение с множеством функций — от запуска облачных серверов до создания и запуска образов / контейнеров. Docker использовал libcontainer для взаимодействия с такими средствами ядра Linux, как Control Groups и Namespaces.

Давайте создадим контейнер с использованием СGroups и Namespaces

В этом примере я использую Ubuntu, но это должно работать для большинства дистрибутивов. Начните с установки CGroup Tools and утилиты stress, поскольку мы собираемся выполнить некоторые стресс-тесты.

Эта команда создаст новый контекст исполнения:

Команда «unshare» разъединяет части контекста исполнения процесса

Теперь, используя cgcreate, мы можем создать группы управления и определить два контроллера: один в памяти, а другой — в процессоре.

Следующим шагом будет определение лимита памяти и его активация:

Теперь давайте запустим stress для изолированного namespace, которое мы создали с ограничениями памяти.

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

Выполнение этих шагов поможет понять, как средства Linux, такие как CGroups и другие функции управления ресурсами, могут создавать изолированные среды в системах Linux и управлять ими.

Интерфейс libcontainer взаимодействует с этими средствами для управления контейнерами Docker и их запуска.

runC: Использование libcontainer без Docker

В 2015 году Docker анонсировал runC: легкую портативную среду выполнения контейнеров.

runC — это, по сути, небольшой инструмент командной строки для непосредственного использования libcontainer, без использования Docker Engine.

Цель runC — сделать стандартные контейнеры доступными повсюду.

Этот проект был передан в дар Open Container Initiative (OCI).

Репозиторий libcontainer сейчас заархивирован. На самом деле, libcontainer не забросили, а перенесли в репозиторий runC.

Перейдем к практической части и создадим контейнер с помощью runC. Начните с установки среды выполнения runC (прим. переводчика: если стоит docker то этого можно (нужно) не делать):

Давайте создадим каталог (/mycontainer), в который мы собираемся экспортировать содержимое образа Busybox.

Используя команду runC, мы можем запустить контейнер busybox, который использует извлеченный образ и файл спецификации (config.json).

Команда runc spec изначально создает этот файл JSON:

Альтернативой для создания кастомной спецификации конфигурации является использование «oci-runtime-tool», подкоманда «oci-runtime-tool generate» имеет множество опций, которые можно использовать для выполнения разных настроек.

Для получения дополнительной информации см. Runtime-tools.

Используя сгенерированный файл спецификации JSON, вы можете настроить время работы контейнера. Мы можем, например, изменить аргумент для выполнения приложения.

Давайте посмотрим, чем отличается исходный файл config.json от нового:

Давайте теперь снова запустим контейнер и заметим, как он ожидает 10 секунд, прежде чем завершится.

Стандарты сред исполнения контейнеров

С тех пор, как контейнеры стали широко распространенными, различные участники этой экосистемы работали над стандартизацией. Стандартизация — ключ к автоматизации и обобщению передового опыта. Передав проект runC OCI, Docker начал использовать containerd в 2016 году в качестве среды выполнения контейнера, взаимодействующей с базовой средой исполнения низкого уровня runC.

Containerd полностью поддерживает запуск пакетов OCI и управление их жизненным циклом. Containerd (как и другие среды выполнения, такие как cri-o) использует runC для запуска контейнеров, но реализует также другие высокоуровневые функции, такие как управление образами и высокоуровневые API.

Интеграция containerd со средами выполнения Docker и OCI

Сontainerd, Shim и RunC, как все работает вместе

runC построен на libcontainer, который является той же библиотекой, которая ранее использовалась для Docker Engine.

До версии 1.11 Docker Engine использовался для управления томами, сетями, контейнерами, образами и т. д.

Теперь архитектура Docker разбита на четыре компонента:

Бинарные файлы соответственно называются docker, docker-containerd, docker-containerd-shim и docker-runc.

Давайте перечислим этапы запуска контейнера с использованием новой архитектуры docker:

Docker engine создает контейнер (из образа) и передает его в containerd.

Containerd вызывает containerd-shim

Containerd-shim использует runC для запуска контейнера

Containerd-shim позволяет среде выполнения (в данном случае runC) завершиться после запуска контейнера

Используя эту новую архитектуру, мы можем запускать «контейнеры без служб» (“daemon-less containers”), и у нас есть два преимущества:

runC может завершиться после запуска контейнера, и нам не нужны запущенными все процессы исполнения.

containerd-shim сохраняет открытыми файловые дескрипторы, такие как stdin, stdout и stderr, даже когда Docker и /или containerd завершаются.

«Если runC и Containerd являются средами исполнения, какого черта мы используем оба для запуска одного контейнера?»

Это, наверное, один из самых частых вопросов. Поняв, почему Docker разбил свою архитектуру на runC и Containerd, вы понимаете, что оба являются средами исполнения.

Если вы следили за историей с самого начала, вы, вероятно, заметили использование сред исполнения высокого и низкого уровня. В этом практическая разница между ними.

Обе они могут называться средами исполнения, но каждая среда исполнения имеет разные цели и функции. Чтобы сохранить стандартизацию экосистемы контейнеров, среда исполнения низкоуровневых контейнеров позволяет запускать только контейнеры.

Среда исполнения низкого уровня (например, runC) должна быть легкой, быстрой и не конфликтовать с другими более высокими уровнями управления контейнерами. Когда вы создаете контейнер Docker, он фактически управляет двумя средами исполнения containerd и runC.

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

передача и хранение образов,

завершение и наблюдение за контейнерами,

Мы можем добавить новую среду исполнения с помощью Docker, выполнив:

Интерфейс среды исполнения контейнера (Container Runtime Interface)

Kubernetes — одна из самых популярных систем оркестровки. С ростом числа сред выполнения контейнеров Kubernetes стремится быть более расширяемым и взаимодействовать с большим количеством сред выполнения контейнеров, помимо Docker.

Первоначально Kubernetes использовал среду исполнения Docker для запуска контейнеров, и она по-прежнему остается средой исполнения по умолчанию.

Однако CoreOS хотела использовать Kubernetes со средой исполнения RKT и предлагала патчи для Kubernetes, чтобы использовать эту среду исполнения в качестве альтернативы Docker.

Вместо изменения кодовой базы kubernetes в случае добавлении новой среды исполнения контейнера создатели Kubernetes решили создать CRI (Container Runtime Interface), который представляет собой набор API-интерфейсов и библиотек, позволяющих запускать различные среды исполнения контейнеров в Kubernetes. Любое взаимодействие между ядром Kubernetes и поддерживаемой средой выполнения осуществляется через CRI API.

Вот некоторые из плагинов CRI:

CRI-O:

CRI-O — это первая среда исполнения контейнера, созданная для интерфейса CRI kubernetes. Cri-O не предназначен для замены Docker, но его можно использовать вместо среды исполнения Docker в Kubernetes.

Containerd CRI :

С cri-containerd пользователи могут запускать кластеры Kubernetes, используя containerd в качестве базовой среды исполнения без установленного Docker.

gVisor CRI:

gVisor — это проект, разработанный Google, который реализует около 200 системных вызовов Linux в пользовательском пространстве для дополнительной безопасности по сравнению с контейнерами Docker, которые работают непосредственно поверх ядра Linux и изолированы с помощью namespace.

Google Cloud App Engine использует gVisor CRI для изоляции клиентов.

Среда исполнения gVisor интегрируется с Docker и Kubernetes, что упрощает запуск изолированных контейнеров.

CRI-O Kata Containers

Kata Containers — это проект с открытым исходным кодом, создающий легкие виртуальные машины, которые подключаются к экосистеме контейнеров. CRI-O Kata Containers позволяет запускать контейнеры Kata в Kubernetes вместо среды выполнения Docker по умолчанию.

Проект Moby

От проекта создания Docker как единой монолитной платформы отказались и родился проект Moby, в котором Docker состоит из множества компонентов, таких как RunC.

Источник: Solomon Hykes Twitter

Moby — это проект по организации и разделения на модули Docker. Это экосистема разработки. Обычные пользователи Docker не заметят никаких изменений.

Источник: Solomon Hykes Twitter

Moby помогает в разработке и запуске Docker CE и EE (Moby — это исходный код Docker), а также в создании среды разработки для других сред исполнения и платформ.

Open Containers Initiative

Как мы видели, Docker пожертвовал RunC Open Container Initiative (OCI), но что это?

OCI — это открытая структура, запущенная в 2015 году Docker, CoreOS и другими лидерами контейнерной индустрии.

Open Container Initiative (OCI) направлена на установление общих стандартов для контейнеров, чтобы избежать потенциальной фрагментации и разделения внутри экосистемы контейнеров.

Он содержит две спецификации:

runtime-spec: спецификация исполнения

image-spec: спецификация образов

Контейнер, использующий другую среду исполнения, можно использовать с Docker API. Контейнер, созданный с помощью Docker, должен работать с любым другим движком.

На этом статья заканчивается.

Буду рад замечаниям и возможно неточностям в статье оригинального автора. Это позволит избежать заблуждений в понимании внутреннего устройства контейнеров. Если нет возможности комментирования на Хабре, можете обсудить тут в комментариях.

Источник