Выполнение кода из одного контейнера в другой (то есть выполнение сценария на рабочем контейнере из контейнера API)

Question

У меня есть docker-compose, состоящий из четырех контейнеров, каждый из которых выполняет одну функцию:

Прокси-сервер nginx, который перенаправляет запросы пользовательского интерфейса и API в соответствующие контейнеры (контейнер-узел, контейнер-фляжка), как показано на рисунке ниже.

Существует также отдельный контейнер, который выполняет долго работающие скрипты Python и работает независимо от других контейнеров. Теперь я хотел бы создать возможность выполнять сценарии в контейнере «долго выполняющиеся сценарии» (LRS) через API:

Каков наилучший способ сделать это?

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

1. Передача docker.sock в контейнер API; из API-контейнера выполните exec в LRS и выполните нужный сценарий
   • Разве это не создает серьезных уязвимостей безопасности?
   • Разве для этого не требуется, чтобы docker был установлен на контейнере API для выполнения, нарушая принцип разделения интересов Docker?
2. HTTP-прослушиватель на контейнере LRS, прослушивающий команды от API для выполнения сценария на LRS
   • Опять же, не нарушает ли это разделение интересов, поскольку теперь мне по сути понадобится легкий API в контейнере LRS для прослушивания действий основного API?

Ни одно из этих решений не кажется идеальным. Я что-то пропустил? Как мне достичь предполагаемой функциональности?

Answer 1

Как правило, решение для запуска долгосрочных сценариев - модель pub-sub. Ваш API поместит сообщение в очередь сообщений. Рабочий экземпляр подпишется на эту очередь, а при появлении сообщений выполнит ваш долгосрочный скрипт / запрос / и т. Д. Когда выполнение будет завершено, либо сообщение вернется в другую очередь, либо результаты будут помещены в заранее определенное место (URL).

У этого есть несколько преимуществ:

1. Два решения эффективно изолированы друг от друга
2. Вы можете масштабировать решение LRS (рабочий), если вам требуется больше ресурсов, добавив дополнительных работников
3. если экземпляр LRS выйдет из строя, API не будет зависеть от его работоспособности. Работа будет поставлена ​​в очередь, когда экземпляр станет доступным.