Source-to-Image¶

Source-to-Image (S2I) — это инструмент и процесс сборки контейнерных образов, при котором исходный код приложения автоматически компилируется, настраивается и упаковывается в готовый к запуску образ контейнера, без необходимости написания Dockerfile вручную. S2I объединяет базовый образ (среду выполнения) и исходный код, создавая воспроизводимый и оптимизированный образ, который может быть развёрнут в среде оркестрации контейнеров, например, в Kubernetes. Технология была разработана компанией Red Hat и является ключевым компонентом платформы OpenShift.

¶История

Идея автоматизации сборки контейнерных образов из исходного кода возникла как ответ на сложность и рутинность ручного написания Dockerfile для каждого приложения. В 2011 году компания Red Hat начала разработку платформы OpenShift, которая должна была упростить развёртывание приложений в облаке. В рамках этого проекта в 2013 году был создан инструмент Source-to-Image (S2I). Первоначально он был реализован как часть OpenShift v2, но впоследствии стал самостоятельным проектом с открытым исходным кодом.

В 2015 году S2I был переписан на языке Go и интегрирован в OpenShift v3. С этого момента он стал стандартным механизмом сборки для платформы. В 2016 году проект был передан сообществу и размещён на GitHub под лицензией Apache 2.0. На протяжении последующих лет S2I развивался, поддерживая всё больше языков программирования и фреймворков, включая Java, Python, Node.js, Ruby, PHP и Go. В 2020-х годах, с ростом популярности бессерверных вычислений и GitOps, S2I стал использоваться не только в OpenShift, но и в других CI/CD-системах, таких как Jenkins и GitLab CI.

¶Принцип работы

S2I состоит из двух основных компонентов: образа сборщика (builder image) и исходного кода. Образ сборщика содержит базовую операционную систему, среду выполнения (например, JVM, интерпретатор Python), а также набор скриптов, которые определяют, как именно обрабатывать исходный код. Эти скрипты называются S2I-скриптами и включают:

• assemble — отвечает за компиляцию, установку зависимостей и настройку приложения.
• run — запускает приложение после сборки.
• save-artifacts — сохраняет артефакты для последующего инкрементального кэширования.
• usage — выводит справку по использованию образа.

Процесс сборки выглядит следующим образом:

1. S2I берёт базовый образ сборщика.
2. Исходный код (обычно из Git-репозитория) копируется внутрь контейнера.
3. Выполняется скрипт assemble, который компилирует код, устанавливает зависимости (например, npm install, mvn package) и копирует результат в нужную директорию.
4. Создаётся новый образ, который содержит только скомпилированное приложение и минимально необходимые для его работы библиотеки.
5. Этот образ может быть сразу же запущен или отправлен в реестр контейнеров.

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

¶Классификация

¶По типу сборщика

• Официальные образы — поддерживаются Red Hat и сообществом. Включают образы для Java (OpenJDK, WildFly), Node.js, Python, Ruby, PHP, Go, Perl и других.
• Пользовательские образы — создаются разработчиками для специфических фреймворков или сред, например, для .NET Core, Rust, Elixir.

¶По способу использования

• Локальный режим — S2I запускается как CLI-инструмент на машине разработчика.
• Режим OpenShift — S2I интегрирован в платформу как объект BuildConfig. Сборка запускается автоматически при изменении кода в репозитории.
• Режим CI/CD — S2I используется в пайплайнах Jenkins, GitLab CI или других системах.

¶Устройство и характеристики

¶Архитектура S2I

S2I состоит из двух частей: клиентской утилиты s2i и серверной части, реализованной в OpenShift. Клиентская утилита написана на Go и может быть установлена на Linux, macOS и Windows. Она взаимодействует с Docker-демоном для выполнения сборок.

¶Технические характеристики

• Размер образа — итоговый образ обычно в 2–3 раза меньше, чем при ручной сборке, так как S2I удаляет временные файлы и зависимости, не нужные для выполнения.
• Скорость сборки — для простых приложений (например, статический HTML) сборка занимает 10–20 секунд; для сложных (например, Java-приложение с Maven) — 1–3 минуты.
• Безопасность — S2I по умолчанию запускает контейнеры с ограниченными правами (non-root), что соответствует лучшим практикам безопасности.
• Воспроизводимость — при одинаковом исходном коде и версии сборщика результат сборки будет идентичным, что важно для отладки и аудита.

¶Преимущества перед ручным Dockerfile

• Автоматизация — не требуется писать Dockerfile для каждого приложения.
• Оптимизация — образы получаются меньше и безопаснее.
• Стандартизация — все приложения на одном языке собираются одинаково.
• Кэширование — инкрементальные сборки экономят время.

¶Применение

¶Платформа OpenShift

S2I является основным механизмом сборки в OpenShift. Разработчик может создать приложение одной командой oc new-app, указав репозиторий с кодом, и OpenShift автоматически подберёт подходящий образ сборщика, выполнит сборку и развернёт приложение. Это позволяет реализовать концепцию «GitOps», когда любое изменение в коде автоматически приводит к обновлению работающего приложения.

¶CI/CD-системы

S2I используется в Jenkins, GitLab CI и других системах для создания контейнерных образов на этапе сборки. Например, в GitLab CI можно добавить шаг:

```yaml build: image: registry.access.redhat.com/ubi8/s2i-core script:

• s2i build https://github.com/user/app.git registry.access.redhat.com/ubi8/python-38 my-app

```

¶Локальная разработка

Разработчики могут использовать S2I локально для быстрой проверки, как приложение будет выглядеть в контейнере, без необходимости писать Dockerfile. Команда s2i build позволяет собрать образ и сразу запустить его.

¶Примеры

¶Пример 1: Сборка Python-приложения

``bash s2i build https://github.com/user/python-app.git registry.access.redhat.com/ubi8/python-38 my-python-app ``

После выполнения команды будет создан образ my-python-app, который можно запустить:

``bash docker run -p 8080:8080 my-python-app ``

¶Пример 2: Сборка Node.js-приложения

``bash s2i build https://github.com/user/node-app.git registry.access.redhat.com/ubi8/nodejs-14 my-node-app ``

¶Пример 3: Создание пользовательского образа сборщика

Для создания собственного образа сборщика необходимо написать S2I-скрипты и поместить их в корень базового образа. Например, для Go-приложения:

``dockerfile FROM golang:1.19 COPY s2i/bin/ /usr/libexec/s2i/ ``

Скрипт assemble может выглядеть так:

```bash

¶!/bin/bash

cd /tmp/src go build -o /opt/app-root/app main.go ```

¶Критика

Несмотря на популярность, S2I имеет ряд недостатков:

• Зависимость от образов сборщика — для каждого языка или фреймворка требуется поддерживать отдельный образ. Если образ устарел, сборка может сломаться.
• Сложность отладки — ошибки в скриптах assemble или run трудно диагностировать, так как они выполняются внутри контейнера.
• Ограниченная гибкость — S2I предполагает определённую структуру проекта (например, наличие package.json для Node.js). Для нестандартных проектов может потребоваться написание собственного сборщика.
• Конкуренция с Buildpacks — в 2020-х годах популярность набрали Cloud Native Buildpacks (CNB), которые предлагают более гибкий и автоматизированный подход к сборке образов. Buildpacks не требуют написания скриптов и автоматически определяют язык приложения. Некоторые эксперты считают, что Buildpacks являются более современной альтернативой S2I.

¶Интересные факты

• S2I был вдохновлён идеей «Heroku buildpacks», но адаптирован для контейнерной экосистемы.
• В 2018 году Red Hat передала S2I в фонд CNCF (Cloud Native Computing Foundation), но проект не был принят из-за низкой активности сообщества.
• S2I поддерживает не только Git-репозитории, но и локальные директории, а также архивы (tar/zip).
• В OpenShift 4.x S2I постепенно вытесняется Buildah и Podman, но остаётся доступным для обратной совместимости.

¶Источники

• Red Hat. «Source-to-Image (S2I) Build». OpenShift Documentation.
• GitHub. «openshift/source-to-image». Репозиторий проекта.
• Kubernetes Documentation. «Builds with Source-to-Image».
• Cloud Native Computing Foundation. «Cloud Native Buildpacks».
• Статья «Source-to-Image: A New Approach to Container Builds» на сайте Red Hat Developer (2015).