Хабрахабр

Контейнеры для взрослых: Практический гид по терминологии (Часть 02)

Есть много шаблонов построения контейнеров. Контейнер – это всего лишь выполняемая версия своего же образа. Поэтому способ построения контейнера тесно связан с тем, как он запускается.

Причем один и тот же образ/контейнер может объединять в себе сразу несколько шаблонов построения и сценариев использования. Одни образы контейнеров прекрасно работают без каких-либо особых привилегий, другим в обязательном порядке требуются права 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-контейнеры.

Идея здесь в том, чтобы упростить контейнеризацию существующих приложений за счет той же возможности использовать systemd внутри контейнера, чтобы применять уже имеющиеся средства автоматизации, установки ПО и прочие инструменты для простого создания готовых к запуску контейнерных образов. Pet-контейнеры объединяют переносимость и удобство контейнерной инфраструктуры, построенной на основе серверов реестра, контейнерных образов и контейнерные хостов, с гибкостью традиционной ИТ-среды, реализованной внутри отдельного контейнера.

Контейнеры с суперпривилегиями

При построении контейнерной инфраструктуры на основе выделенных контейнерных хостов наподобие 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-atomic

Builder-образы

Это специальный тип образов, на основе которых затем создаются дочерние образы контейнеров приложений. Builder-образы включают в себя все, кроме исходного кода, написанного разработчиками, а именно: библиотеки ОС, языковые среды выполнения, связующее ПО и инструменты source-to-image.

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

Для этого они просто берут builder-образ PHP и передают ему URL на сайте GitHub, где хранится их код. Допустим, разработчики написали PHP-код приложения и хотят запускать его в контейнере. На выходе разработчики получают готовый к запуску образ контейнера приложения, который содержит Red Hat Enterprise Linux, PHP из состава Software Collections и, конечно же, исходный PHP-код приложения.

Builder-образы – это мощный, простой и быстрый способ превратить исходный код в контейнер, построенный на базе доверенных компонентов.

Контейнеризованные компоненты

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

Контейнеризованные же компоненты помогают развертывать такие системы быстрее и проще. Во-первых, микросервисная архитектура повышает свободу выбора компонентов, а также ведет к росту числа компонентов, из которых компонуются приложения и программные системы. А средства определения приложений, такие как deployments yaml/json в Kubernetes/OpenShift, open service broker, OpenShift Templates и Helm Charts обеспечивают создание высокоуровневых описаний приложений. Например, контейнерные образы позволяют легко решить проблему сосуществования разных версий одного и того же компонента.

Поэтому имеет смысл выполнять контейнеризацию лишь для отдельных, наиболее подходящих для этого или наиболее перспективных в плане результатов компонентов. Во-вторых, далеко не всегда все части программной системы легко поддаются контейнеризации. pet-контейнеры. В мультисервисных приложениях одна часть сервисов может развертываться в качестве контейнеров, а другая – с использованием традиционных методов, наподобие RPM или сценариев установки, см. п. Кроме того, какие-то компоненты могут плохо поддаваться контейнеризации, поскольку они плохо разбиваются на составные части, либо привязаны к какому-то специальному железу, либо используют низкоуровневые API-вызовы ядра и т. Контейнеризованные компоненты – это то, что может быть контейнеризованно и уже контейнеризованно. Поэтому в большой программной системе, скорее всего, будут части, которые можно контейнеризовать, и части, которые контейнеризовать нельзя. Важно понимать, что они не предназначены для автономной работы, поскольку приносят пользу лишь в составе более крупной программной системы и в отрыве от нее практически бесполезны. Контейнеризованные компоненты предназначены запускаться как часть конкретного приложения, а не сами по себе.

0 большая часть основного кода развертывалась с помощью RPM, но после ее установки администраторы развертывали маршрутизатор и реестр в качестве контейнеров. Например, в OpenShift Enterprise 3. 1 появилась опция контейнеризованного развертывания master, node, openvswitch и etcd, и после ее установки администраторы также могли развертывать в качестве контейнеров elasticsearch, fluentd и kibana. В OpenShift 3.

Поэтому эти контейнеризованные компоненты, например, экземпляр встроенного в OpenShift образа etcd, никогда не должны – и не будут – использоваться для хранения данных исходного кода приложения, с которым работают ваши заказчики, просто потому, что эти контейнеризованные компоненты предназначены для запуска в качестве составной части OpenShift Container Platform. И хотя установщик OpenShift по-прежнему вносит изменения в файловую систему сервера, все основные программные компоненты теперь могут устанавливаться с использованием контейнерных образов.

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

Deployer-образы

Deployer-образ – это специальный вид контейнера, который при запуске выполняет развертывание других контейнеров или управляет ими. Deployer позволяет реализовать сложные схемы развертывания, например запуск контейнеров в определенном порядке или выполнение каких-то действий при первом запуске, наподобие генерации схемы данных или первоначального наполнения БД.

Развертывание этих компонентов с использованием deployer-образов позволяет инженерам OpenShift управлять порядком запуска различных компонентов и проверять корректность их работы. Например, в OpenShift шаблон «image/container type» используется для развертывания журналов и метрик.

Промежуточные образы

Промежуточный образ – это любой образ контейнера, который опирается на базовый образ. Сборки ядра, связующее ПО и языковые среды выполнения обычно реализуются в виде дополнительных слоев поверх базового образа и затем указываются в директиве 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.

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

Например, представьте, что вам только что поручили разработку инфраструктуры, которая должна разграничивать доступность пространств имен, репозиториев и, более того, тегов и слоев в зависимости от ролей и бизнес-правил. Цель этой статьи – помочь вам разобраться в терминологии, чтобы вы могли создавать более продвинутые архитектуры. п.). И последнее – помните, что способ сборки контейнера во многом определяет то, как он запускается (оркестрация, привилегии и т.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»