PHP Composer и другие проблемы последовательности запуска сервисов Docker - PullRequest
Новая
       10

PHP Composer и другие проблемы последовательности запуска сервисов Docker

1 голос
/ 09 мая 2019

sp-composer - это разовая служба, которая объединяет том поставщика PHP Composer в том composer;загрузка пакетов занимает несколько минут.Насколько я понимаю (частично), зависимые службы в одном и том же файле компоновщика / стека не ждут завершения задачи RUN, поэтому они запускаются с пустым томом composer и никогда не видят его впоследствии заполненным (для некоторыхпричина).

Текущее решение - это 8-секундный спящий режим в последовательности запуска производства, когда файл стека Swarm разделен на один только для Composer, а другой для остальных.Иногда нам нужно увеличить задержку.Это, конечно, ужасно и должно быть исправлено.

Существует много сообщений об использовании проверки работоспособности для задержки сервиса, основанного на зависимости, такой как сетевой сервис (например, база данных), но sp-composer - это сервис, которыйпросто запускается и затем выходит.

Нам просто нужно отложить оставшуюся часть последовательности, начиная с тех пор, пока не выйдет sp-composer.Мне пришло в голову, что docker wait (должен?) Решить половину проблемы, но нам все еще нужно разбить файл стека на две части и два раза docker stack deploy.

Какую текущую лучшую практику исправитьэта ситуация?

Для справки, это рассматриваемый файл Docker: 

FROM php:7.1
RUN apt-get update \
    && DEBIAN_FRONTEND=noninteractive \
    && apt-get install -y libxml2-dev zlib1g-dev \
    && docker-php-ext-install soap zip
COPY . /composer
WORKDIR /composer
RUN php ./composer.phar install --no-dev --no-interaction --optimize-autoloader

1 Ответ

1 голос
/ 10 мая 2019

Я думаю, что правильным подходом является редактирование Docker-файлов контейнеров, которые зависят от контейнера PHP Composer, так что они немного ждут перед запуском.

Простым решением было бы добавить sleep к команде RUN (например, RUN sleep 5s; entrypoint.sh).

Более чистое решение - периодически проверять внутри скрипта точки входа, что том заполнен правильно.Примерно так: 

$VOLUME_POPULATED = false
while [[ $VOLUME_POPULATED != true ]]
do
# check if volume is populated
sleep 5s
done

# execute rest of command

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

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

...