Использование многоэтапных (multi-stage) сборок в Docker
О технологиях

Использование многоэтапных (multi-stage) сборок в Docker

2124
5 минут

С Docker 17.05 появилась возможность использовать один единственный Dockerfile для определения последовательности шагов сборки Docker образов!

Это особенно актуально для приложений, разработка которых ведется на компилируемых языках программирования. Используя эту возможность, вы сможете существенно сокращать размер вашего итогового образа не, прибегая к хитрым трюкам, которые я описывал в статье «6 советов по уменьшению Docker образа» Суть подхода заключается в том, чтобы не заботиться о количестве получающихся слоев в процессе сборки вашего приложения и копировать результаты сборки из одного образа в другой. В этой статье я покажу, как это реализуется на практике. Выдумывать ничего не буду, а просто покажу вам это на уже готовых примерах из официальной документации.

Внедряем и поддерживаем Kubernetes/DevOps
Развертываем и сопровождаем инфраструктуру для бизнес-приложений на базе микросервисов и контейнеров

Процесс до появления многоэтапных сборок

Одной из самых сложных задач по созданию Docker образов является уменьшение размера итогового образа, ведь каждая команда в Dockerfile добавляет отдельный слой к итоговому образу. Поэтому нам всегда нужно помнить, что необходимо очищать любые не нужные нам артефакты в текущем слое, прежде чем перейти к следующему. Чтобы написать действительно эффективный Dockerfile, нам традиционно необходимо было использовать кучу shell-трюков, чтобы с одной стороны сделать как можно меньше слоев, а с другой, чтобы оставить в каждом созданном слое минимальное количество артефактов.

Вообще говоря, это очень распространенная практика использовать несколько Dockerfile-ов в одном проекте: один для разработки (содержит все необходимое для создания вашего приложения), другой оптимизированный для создания итогового образа, который будет использоваться в продуктиве, в котором должно быть только ваше приложение и все то, что необходимо для его запуска. Эта практика в свое время получила название «шаблон строителя». Однако, поддержание в актуальном состоянии двух Dockerfile-ов не есть что-то удобное.

Вот пример двух Dockerfile-ов (Dockerfile.build и Dockerfile), речь о которых идет выше:

Dockerfile:


FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY app .
CMD ["./app"]

Dockerfile.build:


FROM golang:1.7.3
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go .
RUN go get -d -v golang.org/x/net/html \
  && CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

И конечно же скрипт, автоматизирующий всю работу:

build.sh:


#!/bin/sh
echo Building alexellis2/href-counter:build

docker build --build-arg https_proxy=$https_proxy --build-arg http_proxy=$http_proxy \  
    -t alexellis2/href-counter:build . -f Dockerfile.build

docker create --name extract alexellis2/href-counter:build  
docker cp extract:/go/src/github.com/alexellis/href-counter/app ./app  
docker rm -f extract

echo Building alexellis2/href-counter:latest

docker build --no-cache -t alexellis2/href-counter:latest .
rm ./app

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

Многоэтапные сборки значительно упрощают эту ситуацию!

Использование многоэтапных (multi-stage) сборок

При многоэтапной сборке вы используете несколько операторов FROM в вашем Dockerfile. Каждая инструкция FROM использует произвольный базовый образ и начинает новый этап сборки. Вы можете выборочно копировать артефакты с одного этапа на другой, оставляя только то, что вам необходимо в конечном образе. Чтобы показать, как это работает, давайте адаптируем Dockerfile из предыдущего раздела для этого процесса.

Dockerfile:


FROM golang:1.7.3
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=0 /go/src/github.com/alexellis/href-counter/app .
CMD ["./app"]

Теперь вам нужен только один Dockerfile. Более того, вам больше не нужен и отдельный скрипт сборки. Просто запустите сборку образа привычной командой.

docker build -t avmaksimov/href-counter:latest .

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

Как это работает? Вторая команда FROM начинает новый этап сборки с базового образа alpine:latest. Инструкция COPY — from = 0 копирует артефакты с предыдущего этапа сборки на текущий этап, благодаря чему необходимые для сборки Go SDK и любые промежуточные артефакты не сохраняются в конечном образе.

Именование этапов сборки

По умолчанию этапы никак не называются, и вы ссылаетесь на них по их целочисленному номеру, начиная с 0 для первой инструкции FROM. Тем не менее, у вас есть возможность давать своим этапам понятные имена, добавив как в команду FROM. Этот пример улучшает предыдущий, используя имена для этапов. Это также означает, что даже если порядок инструкций в вашем Dockerfile со временем изменится, инструкции COPY не сломаются.

Dockerfile:


FROM golang:1.7.3 as builder
WORKDIR /go/src/github.com/alexellis/href-counter/
RUN go get -d -v golang.org/x/net/html  
COPY app.go    .
RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o app .

FROM alpine:latest  
RUN apk --no-cache add ca-certificates
WORKDIR /root/
COPY --from=builder /go/src/github.com/alexellis/href-counter/app .
CMD ["./app"] 

С появлением в Docker поддержки многоэтапных сборок управлять процессами самих сборок стало значительно проще. Надеюсь, вы это тоже оцените! Побольше вам автоматизации и поменьше ручных операций!

15 ноября 2022
OpenShift остался без поддержки – как решить проблему российским клиентам
Интерес к семейству ПО для контейнеризации OpenShift был довольно высоким в корпоративном сегменте в прежние годы. По данным мониторинговой службы Datadog, только за прошлый год во всем мире количество пользователей платформ от RedHat увеличилось на 28%. Весной IBM объявил об уходе из России и прекращении поддержки всех программных продуктов для текущих клиентов. Разберемся, насколько критичной оказалась данная ситуация для заказчиков, и какие варианты действий существуют, чтобы минимизировать возможные риски отключения от сервиса.
0 минут
623
25 февраля 2021
Свидетели DevOps: мифы и байки про девопсов и тех, кто их нанимает
Те, кто решил стать девопсом, видят в этой профессии заманчивые перспективы. Это новый уровень мышления, это творчество и возможность создавать, это безграничные просторы для самосовершенствования. Не секрет также, что девопсам хорошо платят. Вместе с тем, вокруг понятия DevOps сформировался некий культ, овеянный мифами и легендами.
0 минут
843
4 декабря 2020
Дайджест обновлений К2 Облака осень 2020 г.
За осень в К2 Облаке многое изменилось. Мы активно писали код и не успевали сообщать обо всех переменах. Постараемся исправиться и информировать вас ASAP, чтобы вы могли сразу же использовать новые фичи.
1 минута
256
scrollup