Следует избегать расширения прототипа. Глобальный объект тоже вариант плохой (ну может быть только в целях дебага). При Вашем подходе лучше уж бросить объект через provide/inject
Использования Supervisor да и в целом других дополнительных процессов внутри основного приложения это не "docker-way". К примеру для обработки очередей я бы предложил такую схему в Вашем случае:
Создать дополнительный entrypoint entrypoint-queue.sh
та пара опций всегда используется вместе и позволяет передать данные от компонента родителя во всю иерархию его потомков. Эти опции прежде всего используют для написания плагинов, официальная документация не рекомендует использовать их в приложениях.
Участники core-team сами говорят, что это утверждение спорное. Потому скорее всего формулировку «не рекомендуется использовать в приложениях» уберут к релизу 3 версии.
Разумнее было бы сделать белый список ресурсов куда можно стучаться из CI. Тот же npm к примеру.
Следует избегать расширения прототипа. Глобальный объект тоже вариант плохой (ну может быть только в целях дебага). При Вашем подходе лучше уж бросить объект через provide/inject
Использования Supervisor да и в целом других дополнительных процессов внутри основного приложения это не "docker-way". К примеру для обработки очередей я бы предложил такую схему в Вашем случае:
Создать дополнительный entrypoint entrypoint-queue.sh
В docker-compose.yml создать сервис обработки очередей на основе главного сервиса:
Готово. Супервайзер не нужен.
Похожим способом решается задача планирования (аля cron)
А зачем Вам нужен Supervisor в докер контейнере?
Участники core-team сами говорят, что это утверждение спорное. Потому скорее всего формулировку «не рекомендуется использовать в приложениях» уберут к релизу 3 версии.