Многоступенчатая сборка

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

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

Каждой ступени можно присвоить имя (в нашем примере — builder) или же указывать ступень по номеру (начиная с нуля).

Команда COPY позволяет копировать файлы из предыдущих ступеней (по имени или номеру) с помощью флага –from.

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

размер из всех языков!):

# первая ступень - компилятор и все необходимое для Go 1.17

FROM golang:1.17 as builder

# Соберем и запустим приложение в этой директории

WORKDIR /app

# Скопируем код программы в файловую систему контейнера

COPY main.go .

# Соберем программу из исходного кода в файл hello-go

# Необходимо указать дополнительные флаги сборки Go RUN CGO_ENABLED=0 GOOS=linux go build -a -o hello-go main.go

# вторая ступень - спартанская версия Linux Alpine

FROM alpine:3.15

# Используем такую же рабочую директорию

WORKDIR /app

# Скопируем собранный бинарный код из первой ступени

COPY –from=builder /app/hello-go .

# Запустим программу при запуске контейнера

CMD ["/app/hello-go"]

Метки образов

Гораздо лучшая практика работы с метками — указание точных версий и по возможности использование одной версии только для одного образа, с автоматическим увеличением номера версии при изменении функциональности приложения в образе. Особенно хорошо для этого подходят семантические версии (SemVer, детали можно найти в Интернете). В общем случае они начинаются с версии 0.1.0 и всегда следуют формату X.Y.Z, где

X — главная (major) версия, она увеличивается при больших изменениях функциональности и программных интерфейсов API, как правило, несовместимых с предыдущей главной версией;

Y — дополнительная (minor) версия, увеличивается при появлении новой функциональности, полностью совместимой с предыдущей главной версией;

Z - версия «патча» (patch), обычно прибавляют при исправлении мелких ошибок, без каких-либо новых возможностей системы, как еще называют такие исправления, «заплатки» (отсюда и слово patch).

Использованы материалы:

1. Программирование Cloud Native. Микросервисы, Docker и Kubernetes (Иван Портянкин, cloud-native-docker-k8s)
2. Сайт docker.com