Уместно ли использовать Docker для длительных и краткосрочных процессов вместе?
Предположим, я создаю микросервис, который изменяет размер и оптимизирует файлы изображений. Это давно работающий демон, который предоставляет HTTP API, отвечающий на стандартные ответы GET / POST . Исходя из моих знаний о Docker, это идеальный вариант использования для контейнеризации - один процесс (демон HTTP-сервера) работает неопределенно долго в выделенном контейнере.
Для меня все становится неясным, если мы на один уровень глубже посмотрим на возможный способ построения этой службы. Предположим, что для каждого поступающего запроса служба запускает процесс ImageMagick для изменения размера изображения, а затем другой pngquant или аналогичный процесс для уменьшения размера файла. Поскольку эти программы будут обрабатывать потенциально ненадежные данные изображений, предоставленные пользователем, важно иметь возможность обновлять каждый компонент до последней доступной версии, как только эти новые версии будут выпущены. Но как разделить эти компоненты на образы и контейнеры Docker?
Я придумал несколько разных подходов, но все равно кажется, что я чего-то упускаю:
1. Один большой контейнер. При создании контейнера HTTP API установите / скомпилируйте утилиты ImageMagick / pngquant одновременно. Насколько известно демону API, он работает как на любом другом компьютере. Чтобы обновить один из двоичных файлов, перестройте весь контейнер (даже если сам API-демон не изменился). Если необходимо протестировать / разработать против ImageMagick независимо, это может быть неудобно, потому что это не является целью макета этого контейнера.
2. Контейнеры с контейнерами. HTTP API - это собственный контейнер, ImageMagick - это собственный контейнер, pngquant - это собственный контейнер и так далее. Когда API обрабатывает запрос, требующий вызова одной из этих утилит, код API запускает контейнер для преобразования одного файла изображения, и этот контейнер уничтожается после завершения преобразования. Насколько я понимаю, коду HTTP API потребуются довольно высокие разрешения, чтобы иметь возможность создавать новый контейнер; может быть неразумным подходом с точки зрения безопасности.
3. Обертки и клей. Оберните ImageMagick и pngquant в пользовательский долго работающий код демона, чтобы эти контейнеры никогда не выходили. Попросите контейнер HTTP API обмениваться данными с другими по сети Docker по мере необходимости. Похоже, много бессмысленных косвенных указаний и сложности без реальной выгоды.
4. Что-то о композиции изображения мне не хватает. Не похоже, что существует чистый способ «кусочно» собрать контейнер из нескольких независимо заменяемых изображений. Было бы интересно, если бы существовал способ объединить несколько изображений, каждое из которых содержит одно из ImageMagick, pngquant и HTTP API, в единый контейнер. Основываясь на том, что я видел, замена / изменение изображения также изменяет все изображения, которые были созданы на его основе, делая этот подход не так уж сильно отличным от № 1.
То, что я действительно ищу, прежде всего в противном случае - иметь возможность самостоятельно разрабатывать / строить / тестировать / развертывать компоненты программного стека контейнера без перекомпоновки или переустановки частей, которые не изменились. Если это слишком сильно противоречит философии проектирования Docker, я бы хотел либо изменить свой взгляд на подход, либо поискать другие инструменты.
Просто спроектируйте это с несколькими «независимыми» контейнерами, некоторые из которых зависят от других через удаленный API.
Нет необходимости, чтобы «контейнеры запускали контейнеры». У вас просто есть контейнер, принимающий запросы для обработки с помощью ImageMagick, и он просто ожидает непрерывной обработки запросов. Если вам нужно обновить этот контейнер отдельно, сделайте это. Этот непрерывно выполняющийся процесс похож на вашу точку «обертки и клея».
Обратите внимание, что вы можете структурировать его, где он просто запускает ImageMagick как пакетный процесс. Это может быть все, что вам нужно. Однако структурирование ImageMagick в контейнере дает вам возможность подключать разные экземпляры контейнеров ImageMagick, запускающих разные версии ImageMagick, для одновременного сравнения и тестирования.
Что касается сборки изображения из частей других изображений, да, нет прямой способ сделать это, но в DockerHub есть примеры образов, состоящих, возможно, из двух разных фреймворков в базовом образе (например, tomcat и JDK), и для интеграции дополнительных изменений для установки и настройки другого конкретного фреймворка в образе просто требуется взяв отрывок из общедоступного Dockerfile, который показывает, как это сделать.