Именованный контейнер, совместно используемый различными docker -композитными файлами

Question

Я видел несколько похожих вопросов, но не нашел решения для себя.

У меня есть 2 docker -композитные файлы, я создал именованный том и в настоящее время использую его следующим образом:

app:
    ...
    volumes:
      - volume_static:/path/to/container
    ...
...
volumes:
  ...
  volume_static:
    external:
      name: static
  ...
...

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

Это правильный подход?

Мне просто нужно извлечь sh какой-то новый файл в томе из одного docker -compose, и увидеть их непосредственно на втором docker -compose (да, я знаю, docker, но высказывание указания compose дает лучшее представление о том, в чем заключается моя проблема) без перезапуска и сборки службы

Возможно ли это?

Спасибо!

Answer 1

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

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

Наилучший подход здесь чтобы не делиться файлами вообще. Если файлы представляют собой что-то вроде ресурсов stati c для бэкэнд-приложения, вы можете COPY --from этих файлов из образа бэкэнда в изображение прокси, используя имя изображения и тег вашего бэкэнд-приложения (COPY --from=my/backend ...). Это полностью исключает необходимость в томе.

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

#!/bin/sh
set -e

# Populate (or update) the shared static tree
cp -r ./app/assets /static

# Now run the image CMD
exec "$@"

Сделайте этот скрипт ENTRYPOINT в вашем файле Docker; он должен использовать синтаксис JSON -array. Вы можете оставить свой CMD без изменений. Если вы разбили интерпретатор и имя файла на отдельные ENTRYPOINT и CMD, вы можете объединить их в одну строку CMD (и, вероятно, в любом случае).

...
ENTRYPOINT ["entrypoint.sh"]
CMD ["python", "manage.py", "runserver", "0.0.0.0:8000"]

С точки зрения жизненного цикла сборки изображения создаются без какой-либо окружающей экосистемы Compose; они не знают о сетевом окружении, томах, переменных окружения, привязках, и c. ; поэтому, когда вы перестраиваете изображение, вы создаете новое измененное изображение, но не изменяете громкость вообще. При первом запуске всего файла, поскольку указанный том пуст, он заполняется содержимым тома, но это происходит только при первом запуске.

Восстановление изображений и перезапуск контейнеров очень обычная в Docker, и я бы не стал этого избегать. (Это настолько обычная процедура, что повторный запуск docker-compose up -d удалит и заново создаст существующий контейнер, если это потребуется для изменения настроек.)