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

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

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