
Начиная с Docker 17.05, стало возможно определять порядок шагов сборки образов Docker одним-единственным файлом Dockerfile!
Это особенно актуально для приложений, которые пишутся на компилируемых языках программирования, так как позволяет радикально уменьшить размер итогового образа, не прибегая к хитрым трюкам, о которых мы говорили в статье «Шесть советов по уменьшению образа Docker». Такой подход позволяет не думать о количестве слоев, получающихся в процессе сборки приложения, и копировать результаты сборки из одного образа в другой. Сегодня мы рассмотрим, как это реализуется на практике, для чего обратимся к готовым примерам из официальной документации.
Одной из самых сложных задач по созданию 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 скрипт, он создает первый образ, делает из него контейнер, чтобы скопировать артефакты, а затем создать второй образ. Оба образа занимают место на вашей системе, и еще какое-то место у вас занимают артефакты приложения на вашем локальном диске.
Многоэтапные сборки значительно упрощают эту ситуацию!
При многоэтапной сборке вы используете несколько операторов 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 поддержки многоэтапных сборок управлять процессами самих сборок стало значительно проще. Надеюсь, вы это тоже оцените! Побольше вам автоматизации и поменьше ручных операций!