Как вы взаимодействуете с общим томом, созданным Docker Compose в Dockerfile?
В моей настройке Docker Compose у меня есть том, общий для нескольких контейнеров. В compose.yml это выглядит так:
php:
volumes:
- type: bind
source: ./apps
target: /var/www
У меня есть сценарий bash, который взаимодействует с файлами в общем томе. Это называется setup.sh. Он включен в Dockerfile php.
Я хотел бы запустить его как команду RUN в Dockerfile:
COPY dockerfiles/php/setup.sh /usr/local/bin/setup.sh
RUN chmod +x /usr/local/bin/setup.sh
RUN /usr/local/bin/setup.sh
Однако это не работает, поскольку том не монтируется до самой последней команды — точки входа.
Это работает:
CMD sh -c /usr/local/bin/setup.sh && /usr/sbin/php-fpm && tail -f /dev/null
Однако проблема в том, что когда я запускаю контейнеры с помощью docker compose, они отображаются как Started, но запуск скрипта занимает около минуты, прежде чем PHP-FPM заработает. Не существует простого способа определить, когда сценарий завершен. Поэтому я бы предпочел запустить сценарий до точки входа, чтобы он просто ждал запуска PHP-FPM (что не занимает много времени).
Есть ли способ сделать это?
Ответы 1
Как вы взаимодействуете с общим томом, созданным Docker Compose в Dockerfile?
Вы не можете. Его еще не существует. Возможно, создаваемый образ будет запускаться несколько раз на разных машинах с разными смонтированными томами.
Описываемая вами установка звучит так, будто вы пытаетесь внедрить весь исходный код приложения через привязку. Это часто используется, чтобы заставить Docker эмулировать локальную среду разработки. Однако типичная установка Docker предполагает наличие неизменяемых, автономных образов: весь код приложения содержится в образе (и при необходимости компилируется), и вы можете запустить образ без показанного вами монтирования.
Если вы COPY вставите код приложения в образ, то он присутствует, и вы сможете RUN выполнить команду сборки.
COPY ./apps /var/www/
COPY dockerfiles/php/setup.sh /usr/local/bin/setup.sh
RUN setup.sh
CMD ["php-fpm", "-F"]
Если вы находитесь в другой ситуации – возможно, эти файлы представляют собой какие-то данные, специфичные для установки – тогда вы должны запустить это во время запуска контейнера; вы не можете запустить его раньше. В этом случае я предпочитаю сценарий-оболочку точки входа, поскольку он немного чище, чем расширенный CMD, который вы показываете. Этот сценарий может выглядеть так
#!/bin/sh
# run the setup script
setup.sh || exit 1
# switch to the main container command
exec "$@"
Проверьте сценарий в системе управления версиями как исполняемый файл, COPY его в своем изображении и сделайте этот сценарий ENTRYPOINT изображением. Для ENTRYPOINT необходимо использовать синтаксис массива JSON. Последняя строка скрипта запускает CMD, синтаксис которого может быть любым.
COPY entrypoint.sh /usr/local/bin/
ENTRYPOINT ["entrypoint.sh"]
CMD ["php-fpm", "-F"]
В обоих случаях я использую опцию php-fpm -F для запуска интерпретатора на переднем плане. Избегайте использования Tail(1) для «поддержания контейнера в живых».
С помощью подхода ENTRYPOINT можно переопределить CMD, чтобы сделать что-то другое. Например, если вы
docker run --rm your-image \
ls -l /var/www/extra_content
или аналогичный, вы можете запустить временный контейнер (--rm), запустив ls как основной процесс контейнера, и проверить, что было создано сценарием установки.
Отличный ответ! Много хороших советов. Особенно совет про PHP-FPM. Должно быть, я упустил эту возможность запустить его на переднем плане. Все ваши предположения верны. Причина, по которой я использую /var/www в качестве тома, заключается в том, что у меня есть другой контейнер web, в котором работает веб-сервер. setup.sh вносит кучу изменений в исходники приложения, которые затем должны обслуживаться веб-сервером. Единственный способ, которым я знал, как это могло произойти в правильном порядке, — это Том. Ваше предложение - гораздо более чистый способ сделать это, спасибо :)
Операторы RUN выполняются на этапе сборки образа, и тома в это время недоступны. Тома доступны только во время выполнения.