Многоступенчатая сборка
Многоступенчатая сборка — не что иное, как возможность использовать промежуточные, временные образы, использовать для них любые, не обязательно одинаковые базовые образы в процессе сборки и использовать файлы из предыдущих этапов, копируя их в следующий этап.
Каждая ступень сборки начинается с инструкции 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).
Использованы материалы:
- Программирование Cloud Native. Микросервисы, Docker и Kubernetes (Иван Портянкин, cloud-native-docker-k8s)
- Сайт docker.com