Как удалить промежуточные образы из сборки после сборки?

Question

Когда вы создаете свой многоступенчатый Dockerfile с

docker build -t myimage .

создает конечное изображение с тегом myimage, а также промежуточные изображения. Чтобы было совершенно ясно, мы говорим здесь не о контейнерах, а об изображениях. Это выглядит так:

Видите эти <none> изображения? Это то, о чем я говорю.

Теперь этот «вопрос» обсуждался в некоторой степени здесь и здесь .

Вот некоторые важные части:

Если эти промежуточные изображения будут очищаться / удаляться автоматически, кэш сборки будет отсутствовать при каждой сборке, поэтому вам придется каждый раз перестраивать весь образ.

Так, ладно, тогда нет смысла обрезать автоматически .

Некоторые люди делают это:

Сейчас я использую docker image prune -f после команды docker build -t app . для очистки этих промежуточных изображений.

Но, к сожалению, я не могу это сделать. Как прокомментировал один из участников дискуссии:

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

И это сценарий, в котором я оказался.

Так что нечего "исправлять" на стороне Докера. Но как я могу удалить эти дополнительные изображения, только из одной конкретной сборки ?

Обновление

После прочтения очень хорошего ответа из d4nyll ниже, что является большим шагом вперед, я хотел бы добавить еще несколько ограничений к вопросу;) Сначала позвольте мне подвести итог ответа:

• Можно использовать ARG для передачи идентификатора сборки из CI / CD в Dockerfile builder
• Затем можно использовать синтаксис LABEL для добавления метаданных идентификатора сборки к создаваемым изображениям сцены
• Затем можно использовать опцию --filter команды docker image prune , чтобы удалить только изображения с текущим идентификатором сборки

Это - это большой шаг вперед, но я все еще пытаюсь приспособить его к моему сценарию использования, не добавляя ненужной сложности.

В моем случае требование заключается в том, чтобы разработчики приложений, которые создают файлы Docker и регистрируют их в системе управления версиями, несут ответственность за то, чтобы их файлы Docker создавали образы для своего удовлетворения. От них не требуется создавать все свои файлы Docker особым образом, «чтобы процесс CI / CD не прерывался». Они просто должны предоставить Dockerfile, который выдает правильный образ докера.

Таким образом, я на самом деле не в состоянии просить их добавлять материал в Dockerfile для каждого отдельного приложения, просто ради конвейера CI / CD. Это то, что конвейер CI / CD должен обрабатывать сам по себе.

Единственный способ увидеть эту работу - написать синтаксический анализатор Dockerfile, который будет обнаруживать многоэтапную сборку и вставлять метку для каждой стадии, а затем собирать измененную Dockerfile. Это сложность, которую я очень не решаюсь добавить в конвейер CI / CD.

У меня есть лучшие (читай проще) варианты?

Answer 1

Как ZachEddy и thaJeztah упомянули в одной из проблем, с которыми вы связаны, вы можете пометить промежуточные изображения и docker image prune эти изображения на основе этого ярлыка.

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

FROM node as builder
LABEL stage=builder
...

FROM node:dubnium-alpine
...

После того как вы построили свой образ, запустите:

$ docker image prune --filter label=stage=builder

---

Для серверов автоматизации (например, Jenkins)

Если вы запускаете сборки на сервере автоматизации (например, Jenkins) и хотите удалить только промежуточные образы из этой сборки, вы можете

1. Установите уникальный идентификатор сборки в качестве переменной среды внутри сборки Jenkins
2. Добавьте инструкцию ARG для этого идентификатора сборки внутри вашего Dockerfile
3. Передайте идентификатор сборки на docker build через флаг --build-arg

FROM node as builder
ARG BUILD_ID
LABEL stage=builder
LABEL build=$BUILD_ID
...

FROM node:dubnium-alpine
...

$ docker build --build-arg BUILD_ID .
$ docker image prune --filter label=stage=builder --filter label=build=$BUILD_ID

Если вы хотите сохранить идентификатор сборки в образе (возможно, в виде формы документации, доступной внутри контейнера), вы можете добавить еще одну инструкцию ENV, которая принимает значение аргумента ARG build. Это также позволяет использовать аналогичную замену среды для установки значения метки для идентификатора сборки.

FROM node as builder
ARG BUILD_ID
ENV BUILD_ID=$BUILD_ID
LABEL stage=builder
LABEL build=$BUILD_ID
...

FROM node:dubnium-alpine
...