Какова стратегия idiomati c для создания контейнера docker в системе сборки - PullRequest
Новая
       4

Какова стратегия idiomati c для создания контейнера docker в системе сборки

0 голосов
/ 17 февраля 2020

У меня несколько сложный проект - около десятка микросервисов, немного больше библиотек (общие объекты или stati c), некоторые stati c папки с html ресурсами. В проекте есть компоненты C ++ и Python. В конечном итоге проект поставляется в виде изображений Docker, которые передаются на docker хаб как часть процесса сборки.

Я использую cmake, чтобы сделать все это.

Интересно, разработало ли сообщество идиоматическую c стратегию для создания изображений. Что касается make-файла, я делаю что-то вроде: 

main_executable: a.cpp b.cpp
    gcc ...


docker_image: main_executable Dockerfile ... other stuff that gets into the containers
    docker build --tag my_image --file Dockerfile .

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

В идеале, я бы хотел сказать make, чтобы сравнить дату изображения docker (возможно, с 'docker image inspect ') с зависимостями.

Я буду удивлен, если я первый человек с этой проблемой. Какова ваша стратегия? Я доволен cmake, но знаком с кучей других (gradle, Scons, maven) и переключился бы при необходимости.

1 Ответ

2 голосов
/ 17 февраля 2020

Безопасно и эффективно повторять вслепую docker build, как вы показываете. Из-за Docker кэширования изображений , даже если он должен пройти все этапы Dockerfile, Docker может обнаружить, что ни один из входов не изменился (включая то, что main_executable - это тот же файл, что и раньше), и он пропустит всю работу, производя идентичный вывод изображения.

Если вы все еще хотите пропустить перестроение, разумно идиоматически c создать процесс сборки настоящий файл. ( GNU Make Manual имеет пример в другом контексте.) Этот подход работает лучше, если вы можете исчерпывающе перечислить все файлы, которые go включены в сборку образа (но это возможно, особенно если изображение в основном состоит из скомпилированного двоичного файла). 

main_executable: a.cpp b.cpp
        gcc -o $@ ...

# This is a phony convenience target
docker_image: .build.docker

# This is a real file, on success we touch it to update its timestamp
.build.docker: main_executable Dockerfile ...
        docker build --tag my_image --file Dockerfile .
        touch $@

clean:
        rm -f main_executable .build.docker

.PHONY: docker_image clean
...