Есть много шаблонов построения контейнеров. Контейнер – это всего лишь выполняемая версия своего же образа. Поэтому способ построения контейнера тесно связан с тем, как он запускается.
Одни образы контейнеров прекрасно работают без каких-либо особых привилегий, другим в обязательном порядке требуются права root. Причем один и тот же образ/контейнер может объединять в себе сразу несколько шаблонов построения и сценариев использования.
Ниже мы рассмотрим наиболее типовые сценарии использования контейнеров.
(Введение в терминологию контейнеров см. в первой части)
Контейнеры приложений – это самый распространенный вид контейнеров. Ими занимаются разработчики и владельцы приложений, а сами они содержат исходный код, плюс вещи наподобие MySQL, Apache, MongoDB и Node.js.
В настоящее время формируется обширная экосистема контейнеров приложений. Проекты наподобие Software Collections предоставляют безопасные и поддерживаемые образы контейнеров приложений для Red Hat Enterprise Linux. В то же время участники сообщества Red Hat развивают и поддерживают новаторские контейнеры приложений.
Мы в Red Hat считаем, что контейнерам приложений обычно не нужны особые привилегии. Тем не менее, при построении контейнерных продакшн-сред возникает потребность и в других контейнерах.
Контейнер операционной системы – это контейнер, который гораздо больше напоминает полноценную виртуальную ОС. Такие контейнеры также используют ядро хоста, но запускают полную систему init, что позволяет им легко выполнять несколько процессов. Примерами контейнеров операционной системы являются LXC и LXD.
Контейнеры операционной системы можно в принципе эмулировать средствами контейнеров docker/OCI при условии, что внутри них можно запускать system, чтобы конечный пользователь мог устанавливать ПО внутри таких контейнеров обычным способом и воспринимал их как полноценную виртуальную ОС.
Это значительно упрощает контейнеризацию имеющихся приложений. Red Hat прилагает все усилия, чтобы упростить работу с контейнерами операционных систем за счет возможности запускать systemd внутри контейнера и использовать демон machined. Хотя многие не все заказчики пока готовы к микросервисной архитектуре, переход к модели доставки ПО на основе контейнерных образов все равно способен дать им массу преимуществ.
Хотя Red Hat настоятельно рекомендует, пропагандирует и поддерживает использование облачно-ориентированных шаблонов при разработке новых приложений, мы прекрасно понимаем, что далеко не все из уже имеющихся приложений будут переписаны подобным образом. В частности, потому, что многие из них являются настолько уникальными и неповторимыми, что по сравнению с типовыми приложениями выглядят примерно как домашние питомцы (Pets) на фоне стада коров. Именно для таких приложений и предназначены специальные Pet-контейнеры.
Pet-контейнеры объединяют переносимость и удобство контейнерной инфраструктуры, построенной на основе серверов реестра, контейнерных образов и контейнерные хостов, с гибкостью традиционной ИТ-среды, реализованной внутри отдельного контейнера. Идея здесь в том, чтобы упростить контейнеризацию существующих приложений за счет той же возможности использовать systemd внутри контейнера, чтобы применять уже имеющиеся средства автоматизации, установки ПО и прочие инструменты для простого создания готовых к запуску контейнерных образов.
При построении контейнерной инфраструктуры на основе выделенных контейнерных хостов наподобие Red Hat Enterprise Linux Atomic Host системным администраторам все равно приходится заниматься управлением. И суперпривилегированные контейнеры SPC (Super Privileged Containers) оказываются весьма полезными в таких распределенных средах, будь то Kubernetes, OpenShift или даже автономные контейнеры. SPC даже могут загружать специализированные модули ядра, например, systemtap.
В инфраструктуре, созданной для запуска контейнеров, SPC-контейнеры, скорее всего, понадобятся администраторам для выполнения таких задач, как мониторинг, резервное копирование и т. п. Важно понимать, что поскольку SPC-контейнеры обычно гораздо сильнее связаны с ядром хоста, администраторы должны уделять особое внимание вопросам надежности и стандартизации при выборе ОС хостов, особенно в больших кластерных и распределенных средах, затрудняющих устранение неполадок. Кроме того, администраторам нужно следить, чтобы пользовательское пространство внутри SPC было совместимо с ядром хоста.
Linux-дистрибутивы всегда предоставляли пользователю системный софт, такой как Rsyslogd, SSSD, sadc и т. п. Традиционно этот софт устанавливался в виде пакетов RPM или DEB, но с появлением контейнерных форматов упаковки его стало легче и удобнее устанавливать с помощью контейнерных образов. В частности, Red Hat предлагает в виде готовых контейнеров такие вещи, как средства виртуализации Red Hat, rsyslog, sssd и sadc.
По мере того, как контейнерная доставка ПО набирает обороты, формируются и новые шаблоны конструирования контейнеров. В этом разделе мы расскажем о некоторых из них.
То, как контейнер сохраняется на диске (иначе говоря, формат образа), может сильно влиять на то, как он запускается. Например, контейнер, предназначенный для запуска sssd, должен иметь особые привилегии при каждом запуске, иначе он не сможет выполнять свою работу. Ниже мы кратко рассмотрим основные шаблоны, которые в настоящее время переживают этап активного формирования.
Именно с этими образами имеют дело конечные пользователи. Сценарии использования таких образов варьируются от СУБД и веб-серверов до отдельных приложений и сервисных шин. Эти образы могут создаваться как собственными силами организации, так и предоставляться поставщиками ПО. Поэтому конечные пользователи зачастую относятся к содержимому таких автономных контейнеров довольно настороженно и щепетильно. Кроме того, хотя это и самый простой вариант для конечного потребителя контейнеров, автономные образы гораздо сложнее проектировать, собирать и патчить.
Базовый образ – это один из самых простейших типов образов. Однако люди могут обозначать этим термином самые разные вещи, например, стандартную корпоративную сборку или даже образ приложения. Хотя это, строго говоря, не базовые, а промежуточные образы.
Поэтому просто уясните, что базовый образ – это образ, у которого нет родительского слоя. Базовые образы обычно содержат чистую копию ОС, а также инструменты, необходимые для установки программных пакетов или последующего обновления образа (yum, rpm, apt-get, dnf, microdnf). Базовые образы могут собираться конечным пользователем вручную, однако на практике они обычно создаются и выпускаются сообществами разработки (например, Debian, Fedora или CentOS) или поставщиками ПО (к примеру, Red Hat). Происхождение базового образа имеет критическое значение для безопасности. Суммируя, главное и единственное назначение базового образа – предоставить базис, на основе которого вы сможете создавать свои дочерние образы. При использовании dockerfile выбор используемого базового образа производится явным образом:
Это специальный тип образов, на основе которых затем создаются дочерние образы контейнеров приложений. Builder-образы включают в себя все, кроме исходного кода, написанного разработчиками, а именно: библиотеки ОС, языковые среды выполнения, связующее ПО и инструменты source-to-image.
При запуске builder-образ подтягивает исходный код приложения, написанный разработчиками, и создает готовый к запуску дочерний образ контейнера приложения, который затем можно запускать в девелоперской или продакшн-среде.
Допустим, разработчики написали PHP-код приложения и хотят запускать его в контейнере. Для этого они просто берут builder-образ PHP и передают ему URL на сайте GitHub, где хранится их код. На выходе разработчики получают готовый к запуску образ контейнера приложения, который содержит Red Hat Enterprise Linux, PHP из состава Software Collections и, конечно же, исходный PHP-код приложения.
Builder-образы – это мощный, простой и быстрый способ превратить исходный код в контейнер, построенный на базе доверенных компонентов.
Контейнер, прежде всего, предназначен для развертывания в качестве компонента более крупной программной системы, а не как самодостаточная единица. И на это есть две основные причины.
Во-первых, микросервисная архитектура повышает свободу выбора компонентов, а также ведет к росту числа компонентов, из которых компонуются приложения и программные системы. Контейнеризованные же компоненты помогают развертывать такие системы быстрее и проще. Например, контейнерные образы позволяют легко решить проблему сосуществования разных версий одного и того же компонента. А средства определения приложений, такие как deployments yaml/json в Kubernetes/OpenShift, open service broker, OpenShift Templates и Helm Charts обеспечивают создание высокоуровневых описаний приложений.
Во-вторых, далеко не всегда все части программной системы легко поддаются контейнеризации. Поэтому имеет смысл выполнять контейнеризацию лишь для отдельных, наиболее подходящих для этого или наиболее перспективных в плане результатов компонентов. В мультисервисных приложениях одна часть сервисов может развертываться в качестве контейнеров, а другая – с использованием традиционных методов, наподобие RPM или сценариев установки, см. pet-контейнеры. Кроме того, какие-то компоненты могут плохо поддаваться контейнеризации, поскольку они плохо разбиваются на составные части, либо привязаны к какому-то специальному железу, либо используют низкоуровневые API-вызовы ядра и т. п. Поэтому в большой программной системе, скорее всего, будут части, которые можно контейнеризовать, и части, которые контейнеризовать нельзя. Контейнеризованные компоненты – это то, что может быть контейнеризованно и уже контейнеризованно. Контейнеризованные компоненты предназначены запускаться как часть конкретного приложения, а не сами по себе. Важно понимать, что они не предназначены для автономной работы, поскольку приносят пользу лишь в составе более крупной программной системы и в отрыве от нее практически бесполезны.
Например, в OpenShift Enterprise 3.0 большая часть основного кода развертывалась с помощью RPM, но после ее установки администраторы развертывали маршрутизатор и реестр в качестве контейнеров. В OpenShift 3.1 появилась опция контейнеризованного развертывания master, node, openvswitch и etcd, и после ее установки администраторы также могли развертывать в качестве контейнеров elasticsearch, fluentd и kibana.
И хотя установщик OpenShift по-прежнему вносит изменения в файловую систему сервера, все основные программные компоненты теперь могут устанавливаться с использованием контейнерных образов. Поэтому эти контейнеризованные компоненты, например, экземпляр встроенного в OpenShift образа etcd, никогда не должны – и не будут – использоваться для хранения данных исходного кода приложения, с которым работают ваши заказчики, просто потому, что эти контейнеризованные компоненты предназначены для запуска в качестве составной части OpenShift Container Platform.
В новых версиях OpenShift тренд на контейнеризацию компонентов только усиливается, и такой подход все активнее используют и другие разработчики ПО.
Deployer-образ – это специальный вид контейнера, который при запуске выполняет развертывание других контейнеров или управляет ими. Deployer позволяет реализовать сложные схемы развертывания, например запуск контейнеров в определенном порядке или выполнение каких-то действий при первом запуске, наподобие генерации схемы данных или первоначального наполнения БД.
Например, в OpenShift шаблон «image/container type» используется для развертывания журналов и метрик. Развертывание этих компонентов с использованием deployer-образов позволяет инженерам OpenShift управлять порядком запуска различных компонентов и проверять корректность их работы.
Промежуточный образ – это любой образ контейнера, который опирается на базовый образ. Сборки ядра, связующее ПО и языковые среды выполнения обычно реализуются в виде дополнительных слоев поверх базового образа и затем указываются в директиве FROM с указанием этого базового образа. Промежуточные образы обычно используются не сами по себе, а в качестве строительных блоков при создании автономного образа.
Разными слоями образа, как правило, занимаются разные группы специалистов. Например, системные администраторы отвечают за слой сборок ядра, а разработчики – за слой связующего ПО. При этом нижележащие слои, подготовленные одной командой, выступают в качестве промежуточного образа для тех, кто отвечает за слои более высокого уровня. Хотя иногда такие промежуточные образы могут использоваться и автономно, особенно при тестировании.
Многоцелевые контейнерные образы – это образы с гибридной архитектурой. Например, многие образы из состава Red Hat Software Collections можно использовать двумя способами. Во-первых, в качестве обычных контейнеров приложений, имеющих полноценный Ruby on Rails и сервер Apache. Во-вторых, их можно использовать как builder-образы для платформы OpenShift Container Platform и создавать на их основе дочерние образы, содержащие Ruby on Rails, Apache, и код приложения, который вы передали процессу source to image при сборке такого дочернего образа.
Отметим, что многоцелевые образы набирают популярность, поскольку позволяют решать две принципиально разные задачи с помощью одного и то же образа.
При развертывании системного ПО в виде контейнеров последним зачастую требуются привилегии суперпользователя. Чтобы упростить данный вариант развертывания и обеспечить запуск таких контейнеров до запуска среды выполнения контейнеров и системы оркестрации, Red Hat разработала специальный шаблон под названием системные контейнеры. Эти контейнеры запускаются в ходе процесса загрузки ОС с использованием systemd и команды atomic, что делает их независимыми от какой-либо среды выполнения или системы оркестрации контейнеров. Сегодня Red Hat предлагает системные контейнеры для rsyslog, cockpit, etcd и flanneld и в будущем расширит этот список.
Системные контейнеры значительно упрощают выборочное добавление перечисленных служб в состав Red Hat Enterprise Linux и Atomic Host.
Конечному потребителю контейнеры представляются довольно простой штукой, но при построении контейнерной продакш-среды возникает масса вопросов. Чтобы плодотворно обсуждать архитектуру и методы построения таких сред, требуется единая для всех участников терминология. Чем больше вы углубляетесь в вопросы проектирования и строительства таких сред, тем больше возникает подводных камней. Напоследок мы напомним лишь парочку из них.
Люди часто не видят разницы между терминами «образ контейнера» и «репозиторий», особенно когда используют их в командах docker. Но если командами можно пользоваться, не понимая различий, то при работе над архитектурой контейнерных сред надо четко осознавать, что репозиторий – это действительно главная структура данных.
Также довольно легко неверно понять разницу между пространствами имен, репозиториями, слоями образа и тегами. У каждой из этих вещей есть свое предназначение в контейнерной архитектуре. И хотя поставщики и пользователи используют их для самых разных целей, они являются всего лишь инструментами.
Цель этой статьи – помочь вам разобраться в терминологии, чтобы вы могли создавать более продвинутые архитектуры. Например, представьте, что вам только что поручили разработку инфраструктуры, которая должна разграничивать доступность пространств имен, репозиториев и, более того, тегов и слоев в зависимости от ролей и бизнес-правил. И последнее – помните, что способ сборки контейнера во многом определяет то, как он запускается (оркестрация, привилегии и т. п.).
Одни образы контейнеров прекрасно работают без каких-либо особых привилегий, другим в обязательном порядке требуются права root. Причем один и тот же образ/контейнер может объединять в себе сразу несколько шаблонов построения и сценариев использования.
Ниже мы рассмотрим наиболее типовые сценарии использования контейнеров.
(Введение в терминологию контейнеров см. в первой части)
Сценарии использования контейнеров
Контейнеры приложений
Контейнеры приложений – это самый распространенный вид контейнеров. Ими занимаются разработчики и владельцы приложений, а сами они содержат исходный код, плюс вещи наподобие MySQL, Apache, MongoDB и Node.js.
В настоящее время формируется обширная экосистема контейнеров приложений. Проекты наподобие Software Collections предоставляют безопасные и поддерживаемые образы контейнеров приложений для Red Hat Enterprise Linux. В то же время участники сообщества Red Hat развивают и поддерживают новаторские контейнеры приложений.
Мы в Red Hat считаем, что контейнерам приложений обычно не нужны особые привилегии. Тем не менее, при построении контейнерных продакшн-сред возникает потребность и в других контейнерах.
Контейнеры операционных систем
Контейнер операционной системы – это контейнер, который гораздо больше напоминает полноценную виртуальную ОС. Такие контейнеры также используют ядро хоста, но запускают полную систему init, что позволяет им легко выполнять несколько процессов. Примерами контейнеров операционной системы являются LXC и LXD.
Контейнеры операционной системы можно в принципе эмулировать средствами контейнеров docker/OCI при условии, что внутри них можно запускать system, чтобы конечный пользователь мог устанавливать ПО внутри таких контейнеров обычным способом и воспринимал их как полноценную виртуальную ОС.
yum install mysql
systemctl enable mysqlЭто значительно упрощает контейнеризацию имеющихся приложений. Red Hat прилагает все усилия, чтобы упростить работу с контейнерами операционных систем за счет возможности запускать systemd внутри контейнера и использовать демон machined. Хотя многие не все заказчики пока готовы к микросервисной архитектуре, переход к модели доставки ПО на основе контейнерных образов все равно способен дать им массу преимуществ.
Pet-контейнеры
Хотя Red Hat настоятельно рекомендует, пропагандирует и поддерживает использование облачно-ориентированных шаблонов при разработке новых приложений, мы прекрасно понимаем, что далеко не все из уже имеющихся приложений будут переписаны подобным образом. В частности, потому, что многие из них являются настолько уникальными и неповторимыми, что по сравнению с типовыми приложениями выглядят примерно как домашние питомцы (Pets) на фоне стада коров. Именно для таких приложений и предназначены специальные Pet-контейнеры.
Pet-контейнеры объединяют переносимость и удобство контейнерной инфраструктуры, построенной на основе серверов реестра, контейнерных образов и контейнерные хостов, с гибкостью традиционной ИТ-среды, реализованной внутри отдельного контейнера. Идея здесь в том, чтобы упростить контейнеризацию существующих приложений за счет той же возможности использовать systemd внутри контейнера, чтобы применять уже имеющиеся средства автоматизации, установки ПО и прочие инструменты для простого создания готовых к запуску контейнерных образов.
Контейнеры с суперпривилегиями
При построении контейнерной инфраструктуры на основе выделенных контейнерных хостов наподобие Red Hat Enterprise Linux Atomic Host системным администраторам все равно приходится заниматься управлением. И суперпривилегированные контейнеры SPC (Super Privileged Containers) оказываются весьма полезными в таких распределенных средах, будь то Kubernetes, OpenShift или даже автономные контейнеры. SPC даже могут загружать специализированные модули ядра, например, systemtap.
В инфраструктуре, созданной для запуска контейнеров, SPC-контейнеры, скорее всего, понадобятся администраторам для выполнения таких задач, как мониторинг, резервное копирование и т. п. Важно понимать, что поскольку SPC-контейнеры обычно гораздо сильнее связаны с ядром хоста, администраторы должны уделять особое внимание вопросам надежности и стандартизации при выборе ОС хостов, особенно в больших кластерных и распределенных средах, затрудняющих устранение неполадок. Кроме того, администраторам нужно следить, чтобы пользовательское пространство внутри SPC было совместимо с ядром хоста.
Инструменты и системный софт
Linux-дистрибутивы всегда предоставляли пользователю системный софт, такой как Rsyslogd, SSSD, sadc и т. п. Традиционно этот софт устанавливался в виде пакетов RPM или DEB, но с появлением контейнерных форматов упаковки его стало легче и удобнее устанавливать с помощью контейнерных образов. В частности, Red Hat предлагает в виде готовых контейнеров такие вещи, как средства виртуализации Red Hat, rsyslog, sssd и sadc.
Архитектура контейнеров
По мере того, как контейнерная доставка ПО набирает обороты, формируются и новые шаблоны конструирования контейнеров. В этом разделе мы расскажем о некоторых из них.
То, как контейнер сохраняется на диске (иначе говоря, формат образа), может сильно влиять на то, как он запускается. Например, контейнер, предназначенный для запуска sssd, должен иметь особые привилегии при каждом запуске, иначе он не сможет выполнять свою работу. Ниже мы кратко рассмотрим основные шаблоны, которые в настоящее время переживают этап активного формирования.
Образы приложений
Именно с этими образами имеют дело конечные пользователи. Сценарии использования таких образов варьируются от СУБД и веб-серверов до отдельных приложений и сервисных шин. Эти образы могут создаваться как собственными силами организации, так и предоставляться поставщиками ПО. Поэтому конечные пользователи зачастую относятся к содержимому таких автономных контейнеров довольно настороженно и щепетильно. Кроме того, хотя это и самый простой вариант для конечного потребителя контейнеров, автономные образы гораздо сложнее проектировать, собирать и патчить.
Базовые образы
Базовый образ – это один из самых простейших типов образов. Однако люди могут обозначать этим термином самые разные вещи, например, стандартную корпоративную сборку или даже образ приложения. Хотя это, строго говоря, не базовые, а промежуточные образы.
Поэтому просто уясните, что базовый образ – это образ, у которого нет родительского слоя. Базовые образы обычно содержат чистую копию ОС, а также инструменты, необходимые для установки программных пакетов или последующего обновления образа (yum, rpm, apt-get, dnf, microdnf). Базовые образы могут собираться конечным пользователем вручную, однако на практике они обычно создаются и выпускаются сообществами разработки (например, Debian, Fedora или CentOS) или поставщиками ПО (к примеру, Red Hat). Происхождение базового образа имеет критическое значение для безопасности. Суммируя, главное и единственное назначение базового образа – предоставить базис, на основе которого вы сможете создавать свои дочерние образы. При использовании dockerfile выбор используемого базового образа производится явным образом:
FROM registry.access.redhat.com/rhel7-atomicBuilder-образы
Это специальный тип образов, на основе которых затем создаются дочерние образы контейнеров приложений. Builder-образы включают в себя все, кроме исходного кода, написанного разработчиками, а именно: библиотеки ОС, языковые среды выполнения, связующее ПО и инструменты source-to-image.
При запуске builder-образ подтягивает исходный код приложения, написанный разработчиками, и создает готовый к запуску дочерний образ контейнера приложения, который затем можно запускать в девелоперской или продакшн-среде.
Допустим, разработчики написали PHP-код приложения и хотят запускать его в контейнере. Для этого они просто берут builder-образ PHP и передают ему URL на сайте GitHub, где хранится их код. На выходе разработчики получают готовый к запуску образ контейнера приложения, который содержит Red Hat Enterprise Linux, PHP из состава Software Collections и, конечно же, исходный PHP-код приложения.
Builder-образы – это мощный, простой и быстрый способ превратить исходный код в контейнер, построенный на базе доверенных компонентов.
Контейнеризованные компоненты
Контейнер, прежде всего, предназначен для развертывания в качестве компонента более крупной программной системы, а не как самодостаточная единица. И на это есть две основные причины.
Во-первых, микросервисная архитектура повышает свободу выбора компонентов, а также ведет к росту числа компонентов, из которых компонуются приложения и программные системы. Контейнеризованные же компоненты помогают развертывать такие системы быстрее и проще. Например, контейнерные образы позволяют легко решить проблему сосуществования разных версий одного и того же компонента. А средства определения приложений, такие как deployments yaml/json в Kubernetes/OpenShift, open service broker, OpenShift Templates и Helm Charts обеспечивают создание высокоуровневых описаний приложений.
Во-вторых, далеко не всегда все части программной системы легко поддаются контейнеризации. Поэтому имеет смысл выполнять контейнеризацию лишь для отдельных, наиболее подходящих для этого или наиболее перспективных в плане результатов компонентов. В мультисервисных приложениях одна часть сервисов может развертываться в качестве контейнеров, а другая – с использованием традиционных методов, наподобие RPM или сценариев установки, см. pet-контейнеры. Кроме того, какие-то компоненты могут плохо поддаваться контейнеризации, поскольку они плохо разбиваются на составные части, либо привязаны к какому-то специальному железу, либо используют низкоуровневые API-вызовы ядра и т. п. Поэтому в большой программной системе, скорее всего, будут части, которые можно контейнеризовать, и части, которые контейнеризовать нельзя. Контейнеризованные компоненты – это то, что может быть контейнеризованно и уже контейнеризованно. Контейнеризованные компоненты предназначены запускаться как часть конкретного приложения, а не сами по себе. Важно понимать, что они не предназначены для автономной работы, поскольку приносят пользу лишь в составе более крупной программной системы и в отрыве от нее практически бесполезны.
Например, в OpenShift Enterprise 3.0 большая часть основного кода развертывалась с помощью RPM, но после ее установки администраторы развертывали маршрутизатор и реестр в качестве контейнеров. В OpenShift 3.1 появилась опция контейнеризованного развертывания master, node, openvswitch и etcd, и после ее установки администраторы также могли развертывать в качестве контейнеров elasticsearch, fluentd и kibana.
И хотя установщик OpenShift по-прежнему вносит изменения в файловую систему сервера, все основные программные компоненты теперь могут устанавливаться с использованием контейнерных образов. Поэтому эти контейнеризованные компоненты, например, экземпляр встроенного в OpenShift образа etcd, никогда не должны – и не будут – использоваться для хранения данных исходного кода приложения, с которым работают ваши заказчики, просто потому, что эти контейнеризованные компоненты предназначены для запуска в качестве составной части OpenShift Container Platform.
В новых версиях OpenShift тренд на контейнеризацию компонентов только усиливается, и такой подход все активнее используют и другие разработчики ПО.
Deployer-образы
Deployer-образ – это специальный вид контейнера, который при запуске выполняет развертывание других контейнеров или управляет ими. Deployer позволяет реализовать сложные схемы развертывания, например запуск контейнеров в определенном порядке или выполнение каких-то действий при первом запуске, наподобие генерации схемы данных или первоначального наполнения БД.
Например, в OpenShift шаблон «image/container type» используется для развертывания журналов и метрик. Развертывание этих компонентов с использованием deployer-образов позволяет инженерам OpenShift управлять порядком запуска различных компонентов и проверять корректность их работы.
Промежуточные образы
Промежуточный образ – это любой образ контейнера, который опирается на базовый образ. Сборки ядра, связующее ПО и языковые среды выполнения обычно реализуются в виде дополнительных слоев поверх базового образа и затем указываются в директиве FROM с указанием этого базового образа. Промежуточные образы обычно используются не сами по себе, а в качестве строительных блоков при создании автономного образа.
Разными слоями образа, как правило, занимаются разные группы специалистов. Например, системные администраторы отвечают за слой сборок ядра, а разработчики – за слой связующего ПО. При этом нижележащие слои, подготовленные одной командой, выступают в качестве промежуточного образа для тех, кто отвечает за слои более высокого уровня. Хотя иногда такие промежуточные образы могут использоваться и автономно, особенно при тестировании.
Многоцелевые (интермодальные) образы
Многоцелевые контейнерные образы – это образы с гибридной архитектурой. Например, многие образы из состава Red Hat Software Collections можно использовать двумя способами. Во-первых, в качестве обычных контейнеров приложений, имеющих полноценный Ruby on Rails и сервер Apache. Во-вторых, их можно использовать как builder-образы для платформы OpenShift Container Platform и создавать на их основе дочерние образы, содержащие Ruby on Rails, Apache, и код приложения, который вы передали процессу source to image при сборке такого дочернего образа.
Отметим, что многоцелевые образы набирают популярность, поскольку позволяют решать две принципиально разные задачи с помощью одного и то же образа.
Системные контейнеры
При развертывании системного ПО в виде контейнеров последним зачастую требуются привилегии суперпользователя. Чтобы упростить данный вариант развертывания и обеспечить запуск таких контейнеров до запуска среды выполнения контейнеров и системы оркестрации, Red Hat разработала специальный шаблон под названием системные контейнеры. Эти контейнеры запускаются в ходе процесса загрузки ОС с использованием systemd и команды atomic, что делает их независимыми от какой-либо среды выполнения или системы оркестрации контейнеров. Сегодня Red Hat предлагает системные контейнеры для rsyslog, cockpit, etcd и flanneld и в будущем расширит этот список.
Системные контейнеры значительно упрощают выборочное добавление перечисленных служб в состав Red Hat Enterprise Linux и Atomic Host.
Заключение
Конечному потребителю контейнеры представляются довольно простой штукой, но при построении контейнерной продакш-среды возникает масса вопросов. Чтобы плодотворно обсуждать архитектуру и методы построения таких сред, требуется единая для всех участников терминология. Чем больше вы углубляетесь в вопросы проектирования и строительства таких сред, тем больше возникает подводных камней. Напоследок мы напомним лишь парочку из них.
Люди часто не видят разницы между терминами «образ контейнера» и «репозиторий», особенно когда используют их в командах docker. Но если командами можно пользоваться, не понимая различий, то при работе над архитектурой контейнерных сред надо четко осознавать, что репозиторий – это действительно главная структура данных.
Также довольно легко неверно понять разницу между пространствами имен, репозиториями, слоями образа и тегами. У каждой из этих вещей есть свое предназначение в контейнерной архитектуре. И хотя поставщики и пользователи используют их для самых разных целей, они являются всего лишь инструментами.
Цель этой статьи – помочь вам разобраться в терминологии, чтобы вы могли создавать более продвинутые архитектуры. Например, представьте, что вам только что поручили разработку инфраструктуры, которая должна разграничивать доступность пространств имен, репозиториев и, более того, тегов и слоев в зависимости от ролей и бизнес-правил. И последнее – помните, что способ сборки контейнера во многом определяет то, как он запускается (оркестрация, привилегии и т. п.).
