Рабочий процесс разработки докеры для скомпилированных компонентов в настройке компоновки докеров

Question

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

Я пробовал 2 'workflows', оба полагаются на связь с исходным каталогом через volume:, чтобы получить последний источник.

А.

• Всплывающие все опорные контейнеры с docker-compose up -d
• остановки контейнера для службы в стадии разработки
• Выполнить новый контейнер с использованием изображения docker-compose run --name SERVICE --rm SERVICE /bin/bash
• В этом контейнере запуска компиляции и запуска приложение в открытом порту.
• Перезапустите, прекратив работу, а затем перестройте.

B.

• (требуется Dockerfile CMD строить, а затем запустить службу)
• Остановите службу: docker-compose kill SERVICE
• Перезапустите службу docker-compose up -d --no-deps SERVICE

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

Answer 1

Я хотел бы сделать это:

Run docker-compose up но:

• использовать объем узла для каталога скомпилированного бинарного вместо источника
• использовать entrypoint, что делает что-то вроде

entrypoint.sh:

trap "pkill -f the_binary_name" SIGHUP 
trap "exit" SIGTERM 

while [[ 1 ]]; do 
    ./the_binary_name; 
done 

Напишите сценарий, чтобы восстановить бинарный файл и скопировать его в объем используемого сервиса в docker-compose.yml:

# Run a container to compile and build the binary 
docker run -ti -v $SOURCE:/path -v $DEST:/target some_image build_the_binary 

# copy it to the host volume directory 
copy $DEST/... /volume/shared/with/running/container 

# signal the container 
docker kill -s SIGHUP container_name 

Так компилировать двоичный код вы используете этот скрипт, который монтирует источник и в качестве томов. Вы можете пропустить шаг копирования, если $DEST совпадает с каталогом томов, совместно используемым контейнером «запустить». Наконец, скрипт будет сигнализировать запущенному контейнеру, чтобы он убил старый процесс (который запускал старый двоичный файл) и начал новый.

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

Это решение обладает дополнительным преимуществом, при котором вашему образцу «runtime» не нужны все зависимости dev. Это может быть очень худое изображение с простой базой ОС.