Build once, promote many: неизменяемые артефакты

Одна сборка — одна идентичность: дайджест и есть артефакт

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

Модель 12-factor делит деплой на три стадии: build превращает репозиторий кода в исполняемый бандл на конкретном коммите; release соединяет ровно эту сборку с конфигом деплоя; run запускает процесс из релиза. Жёсткое правило — направленность: нельзя изменить код в рантайме так, чтобы это утекло обратно в сборку. «Релиз нельзя изменить после того, как он создан.» Каждый получает уникальный ID, поэтому ты всегда точно знаешь, что запущено.

Build-once-deploy-many — операционное следствие: стадия build выполняется ровно один раз на изменение, и порождает она неизменяемый артефакт. Для контейнера настоящая идентичность артефакта — не его тег, а его дайджест содержимого, sha256-хэш манифеста образа. Тег вроде :latest, :v1.4 или node:22 — это изменяемый указатель; его можно перенаправить на другое содержимое в любой момент. Дайджест адресуем по содержимому: sha256:9b2f… вычисляется из байтов, поэтому любое изменение — пусть на один байт — даёт другой дайджест. Pull по дайджесту гарантирует, что ты получишь ровно тот образ, который собрали и протестировали, на каждой ноде, в каждом окружении. Дайджест — это артефакт; тег — лишь стикер поверх него.

Продвижение (promotion), стало быть, — не пересборка. Это перенос того же дайджеста вперёд: staging провалидировал sha256:9b2f…, значит прод запускает sha256:9b2f…, те же байты, без изменений. А меняется между окружениями конфиг — и он инжектируется в рантайме.

Конфиг — на окружение; байты — нет

Если staging и прод гоняют один артефакт, где живут URL базы, API-ключи, фича-флаги? Не в образе. Фактор config из 12-factor прямолинеен: храни конфиг в окружении, держи строгое разделение конфига и кода, а лакмусовая бумажка — что ты мог бы открыть исходники сборки завтра, не утекнув ни единого секрета. Конфиг — это всё, что меняется между деплоями; артефакт — всё, что не меняется.

release = неизменяемый артефакт (sha256-дайджест)  +  конфиг на окружение (инжектится в рантайме)

Конкретно: тот же дайджест запускается в каждом окружении с конфигом, поданным как переменные окружения, примонтированный ConfigMap (объект конфигурации Kubernetes, монтируемый в контейнер) или секреты из vault — никогда не запечённым в слой. Запеки DATABASE_URL=staging-db в образ — и ты только что создал артефакт только-для-staging: теперь ты вынужден пересобирать под прод, что заново вносит ровно тот дрейф, ради устранения которого принцип и существует.

Rebuild drift: авария с пустым диффом

Вот провал, который стоит больше всего инцидент-часов — именно потому, что смотреть не на что. Когда пайплайн пересобирает артефакт отдельно под каждое окружение, каждая пересборка заново разрешает всё плавающее: подвижный base-тег, незапиненную транзитивную зависимость, latest какого-нибудь build-инструмента, даже преходящее состояние реестра. Популярные base-теги перезаливают часто — ради патчей безопасности ОС тег вроде node:22 или python:3.12 разрешается в другой дайджест в этом месяце, чем в прошлом, при том что строка тега не менялась. Так две сборки одного коммита с разницей в часы могут вшить разные glibc/musl, другой OpenSSL, другой патч рантайма. Бинарники расходятся, а изменения исходника, которое это объяснило бы, нет. Это «в staging работает, в проде падает» в чистейшей и самой бесящей форме.

Контраст в форме пайплайна:

# ПЛОХО — пересборка под окружение, деплой изменяемого тега
# джоба staging
docker build -t myapp:latest .          # разрешает node:22 -> дайджест A
docker push myapp:latest
kubectl set image deploy/app app=myapp:latest   # staging тянет A
# джоба прода, часами позже
docker build -t myapp:latest .          # разрешает node:22 -> дайджест B (базу перезалили!)
docker push myapp:latest                # :latest теперь указывает на B
kubectl set image deploy/app app=myapp:latest   # прод тянет B — другие байты, пустой git diff

# ХОРОШО — собрать один раз, поймать дайджест, продвигать его, конфиг в рантайме
docker buildx build --push -t registry/myapp:1.4.0 --metadata-file out.json .
DIGEST=$(jq -r '."containerimage.digest"' out.json)
# DIGEST = sha256:9b2f...  — неизменяемая идентичность, пойманная ОДИН раз
kubectl set image deploy/app app=registry/myapp@$DIGEST -n staging   # staging гоняет дайджест
# ...staging проходит свои гейты...
kubectl set image deploy/app app=registry/myapp@$DIGEST -n prod      # прод гоняет ТОТ ЖЕ дайджест
# конфиг различается по окружению через env vars / ConfigMap / секреты — не перезапекается в образ