Управление зависимостями apt-get на Docker

Question

В нашей компании имеется большой код на основе c ++, и мы пытаемся перейти на микросервисную инфраструктуру на основе докера.

У нас есть несколько библиотек, которые помогают нам с такими вещами, как вспомогательные функциии утилита, которую мы регулярно используем в нашем коде.Наша идея заключалась в том, чтобы создать базовый образ для разработчиков с уже установленной библиотекой и сделать его доступным для использования в качестве нашего «базового» образа.Это даст нам преимущество всего нашего программного обеспечения, всегда использующего последнюю версию нашей собственной библиотеки.

Мои вопросы касаются системы кеширования Docker в связи с CI и внешними зависимостями.Допустим, у нас есть файл Docker, подобный следующему:

FROM ubuntu:latest

# Install External dependencys
RUN apt update && apt install -y\
boost-libs \
etc...

# Copy our software
...
# Build it
...
# Install it
...

Если наш код изменится, мы можем вызвать CI, и Docker поймет, что он может использовать кэшированное изображение, которое было создано до того момента, когда оно было скопированонаше программное обеспечение.Что произойдет, если одна из наших внешних зависимостей предложит более новую версию?Будет ли кэшированный автоматически признан недействительным?Как мы можем запустить сборку CI, если какой-либо из наших пакетов получит новую версию?

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

Пожалуйста, имейте в виду, что вышеприведенный Dockerfile является лишь примером, иллюстрирующим, что мы пытаемся использовать другие приемы в книге игр, такие как использование более легкого базового образа (не Ubuntu) и многоступенчатых сборок, чтобы избежать dev-пакетов в наших производственных контейнерах.

Answer 1

Алгоритм кэширования Docker довольно прост.Он просматривает предыдущее состояние сборки образа и строку команды, которую вы запускаете.Если вы выполняете COPY или ADD, он также просматривает хэш копируемых файлов.Если предыдущая сборка найдена на сервере с тем же предыдущим состоянием и выполняемой командой, она будет повторно использовать кеш.

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

Вариант 1. Измените вашу команду, добавив версии в зависимости.Когда одна из этих зависимостей изменится, вам нужно будет обновить свою сборку.Это добавленная работа, но также гарантирует, что вы извлекаете только те версии, к которым готовы.Это будет выглядеть так (исправление boost-libs на номер версии 1.5):

# Install External dependencys
RUN apt update && apt install -y\
boost-libs=1.5 \
etc...

Вариант 2: изменить аргумент сборки.Они внедряются как переменные среды в команды RUN, и docker видит изменение в среде как другую команду для запуска.Это выглядело бы так:

# Install External dependencys
ARG UNIQUE_VAR
RUN apt update && apt install -y\
boost-libs \
etc...

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

docker build --build-arg "UNIQUE_VAR=$(date +%Y%m%d)" ...

Обратите внимание, есть такжевозможность строить без кеша в любое время с помощью:

docker build --no-cache ...

Это приведет к игнорированию кеша для всех шагов (кроме строки from).