Контейнеры приложений — самая популярная форма контейнеров. Именно о них заботятся разработчики и владельцы приложений. Контейнеры приложений содержат код, над которым работают разработчики. К ним относятся, например, MySQL, Apache, MongoDB и Node.js.

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

При создании инфраструктуры контейнеров на выделенных хостах контейнеров, таких как Atomic Host, системным администраторам по-прежнему необходимо выполнять административные задачи. Независимо от того, используются ли они с распределёнными системами, такими как Kubernetes или OpenShift, или с отдельными хостами контейнеров, суперпривилегированные контейнеры (SPC) являются мощным инструментом. SPC могут даже загружать специализированные модули ядра, например, с помощью systemtap. В инфраструктуре, построенной для запуска контейнеров, администраторам, скорее всего, понадобятся SPC для выполнения таких задач, как управление, мониторинг, резервное копирование и т. д. Важно понимать, что обычно существует более тесная связь между SPC и ядром хоста, поэтому администраторам необходимо выбирать надёжный хост контейнеров и стандартизировать его, особенно в крупных кластерных/распределённых средах, где устранение неполадок более сложно. Затем им необходимо выбрать пользовательское пространство в SPC, совместимое с ядром хоста.

Базовый образ — один из самых простых типов образов, но вы найдёте множество определений. Иногда пользователи также называют образ приложения «базовым образом». Однако технически это не базовый образ, это промежуточные образы.

Проще говоря, базовый образ — это образ, у которого нет родительского слоя. Обычно базовый образ содержит свежую копию операционной системы. Базовые образы обычно включают основные системные инструменты, такие как bash или coreutils, а также инструменты, необходимые для установки пакетов и обновления образа с течением времени (yum, rpm, apt-get, dnf, microdnf…​). Хотя базовые образы могут быть «созданы вручную», на практике они обычно производятся и публикуются проектами с открытым исходным кодом (такими как Debian, Fedora или CentOS) и вендорами (такими как Red Hat). Происхождение базовых образов критически важно для безопасности. Короче говоря, единственная цель базового образа — предоставить отправную точку для создания ваших производных образов. При использовании Dockerfile выбор базового образа явный: ` FROM registry.fedoraproject.org/fedora `

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

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

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

Некоторые образы-сборщики созданы таким образом, что позволяют разработчикам предоставлять не только свой исходный код, но и пользовательскую конфигурацию для программного обеспечения, встроенного в образ. Одним из таких примеров является образ-сборщик Nginx в репозитории source-to-image вышестоящего проекта.

Промежуточный образ — это любой образ контейнера, который зависит от базового образа. Обычно основные сборки, промежуточное программное обеспечение и среды выполнения языков создаются как слои «поверх» базового образа. Затем на эти образы ссылаются в директиве FROM другого образа. Эти образы не используются сами по себе; они обычно используются как строительный блок для создания автономного образа.

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

Интермодальные образы контейнеров — это образы, имеющие гибридные архитектуры. Например, многие образы Red Hat Software Collections можно использовать двумя способами.

Во-первых, их можно использовать как простые контейнеры приложений, запускающие полностью автономный сервер Ruby on Rails и Apache.

Во-вторых, их можно использовать как образы-сборщики в платформе контейнеров OpenShift. В этом случае дочерние образы содержат Ruby on Rails, Apache и код приложения, на который был направлен процесс source-to-image во время фазы сборки.

Интермодальный шаблон становится всё более распространённым для решения двух бизнес-задач с помощью одного образа контейнера.

Образ-развёртыватель — это специализированный вид контейнера, который при запуске развёртывает или управляет другими контейнерами. Этот шаблон позволяет использовать сложные методы развёртывания, такие как определение порядка запуска контейнеров или логика первого запуска, например, заполнение схемы или данных.

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

Во-первых, микросервисы стимулируют использование лучших компонентов — это также стимулирует использование большего количества компонентов, объединённых вместе для создания одного приложения. Контейнеризированные компоненты удовлетворяют потребность в более быстром и лёгком развёртывании растущего количества сложного программного обеспечения.

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

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