Имеют ли многоступенчатые образы докеров одинаковые слои?

Question

Допустим, я решил сделать следующую многоступенчатую сборку:

FROM node:8.6-alpine AS build1
#some other commands
FROM node:8.5-alpine AS build2
# yet another commands

определенно есть несколько слоев, которые будут общими для build1 и build2. Будет ли Docker дублировать слои или добавлять ссылки на уже созданные слои?

Answer 1

Я полагаю, что будет применяться обычное docker build кэширование слоев, но есть и другие лучшие ответы.

FROM ubuntu:18.04 AS first
RUN apt-get update \
 && DEBIAN_FRONTEND=noninteractive \
    apt-get install -y --no-install-recommends \
      python3
RUN echo first

FROM ubuntu:18.04 AS second
RUN apt-get update \
 && DEBIAN_FRONTEND=noninteractive \
    apt-get install -y --no-install-recommends \
      python3
RUN echo second

Правила таковы, что вы должны начинать с точного того же базового образа (в вашем примере ничего не передается) и вы должны повторять точные те же команды (или КОПИРОВАТЬ точное того же содержимого файла); как только вы отклоняетесь от этого пути, ничто не передается, в том числе в любых последующих идентичных командах.

Вы можете использовать псевдоним AS в последующих директивах FROM , поэтому, если вы действительно хотите использовать некоторый базовый уровень, лучше сделать это явно

FROM ubuntu:18.04 AS base
RUN apt-get update \
 && DEBIAN_FRONTEND=noninteractive \
    apt-get install -y --no-install-recommends \
      python3

FROM base AS first
RUN echo first

FROM base AS second
RUN echo second

Более распространенный случай с многоэтапной сборкой, в котором используются очень разные образы "сборки" и "времени выполнения", поэтому это не часто применяется.

FROM golang:1.11 AS build
WORKDIR /go/src/github.com/me/myapp
COPY ./ ./
RUN go install .

FROM alpine
COPY --from=build /go/bin/myapp /usr/bin
CMD ["myapp"]

Answer 2

Далее приведен результат сборки вашего файла Dockerfile на новой машине:

# docker build -t test:1 .
Sending build context to Docker daemon  2.048kB
Step 1/2 : FROM node:8.6-alpine AS build1
8.6-alpine: Pulling from library/node
88286f41530e: Pull complete
d0e8a23136b3: Pull complete
5ad5b12a980e: Pull complete
Digest: sha256:60cd58a7a2bd9fec161f53f8886e451f92db06b91f4f72d9188eeea040d195eb
Status: Downloaded newer image for node:8.6-alpine
 ---> b7e15c83cdaf
Step 2/2 : FROM node:8.5-alpine AS build2
8.5-alpine: Pulling from library/node
88286f41530e: Already exists
aa0be12c5610: Pull complete
719d346e6de2: Pull complete
Digest: sha256:945cf56668d3e58a3b045291564963ccde29a68da9c1483e19d8a0b06749db06
Status: Downloaded newer image for node:8.5-alpine
 ---> 7a779c246a41
Successfully built 7a779c246a41
Successfully tagged test:1

Из вывода вы можете видеть, что id изображения 88286f41530e был повторно использован как Already exists.

Иdocker images output:

REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
node                8.6-alpine          b7e15c83cdaf        13 months ago       67.2MB
node                8.5-alpine          7a779c246a41        14 months ago       67MB

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

И из этого post :

Начиная с Docker v1.10, изображения и слои больше не являются синонимами.Вместо этого изображение напрямую ссылается на один или несколько слоев, которые в конечном итоге вносят вклад в файловую систему производного контейнера.

Таким образом, при повторном использовании некоторого изображения слои, несомненно, будут использоваться повторно.

Конечно,это зависит от базовых образов, которые вы использовали в multibuild, им нужно что-то для повторного использования.

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