Иногда прерывание лучших практик Docker действительно работает в вашу пользу
15 июля 2025 г.Мы можем управлять, обновлять, перезапустить и масштабировать каждый контейнер Docker отдельно. Это красота контейнеризации. Каждый контейнер должен нести единую ответственность. PHP, Java, Nodejs - каждый из них делает одну очевидную вещь. Создание контейнеров, которые включают несколько сервисов, считается анти-паттерном. Принцип единственной ответственности не применяется только к нашей кодовой базе.
Но значит ли это, что мы никогда не должны создавать такие анти-паттернные контейнеры только потому, что они нарушают SRP? Я считаю, что есть одна веская причина, чтобы нарушить это правило, и я покажу вам в этой статье.
Проблема
Я создал программную архитектурную платформу на вершине Symfony Framework и хотел интегрировать structurizr в мою систему. Моя платформа поставляется как SaaS, а Structurizr-это решение с открытым исходным кодом. Итак, я хотел объединить оба, чтобы позволить пользователям иметь одно место для управленияПрограммная архитектура, и их модель C4, сделанная с использованием DSL -структуры.
Мне нужно было две основные вещи для интеграции:
- Структурное изображение Docker - иметь возможность отображать диаграммы
- Structurizr CLI - для проверки DSL
Docker Image - это кусок торта. Потяните, зайдите и готов к использованию. Но CLI StructuRizr был немного проблематичным, потому что он написан на Java. Я мог бы использовать контейнер с Java, но CLI используется в терминале. Подключение между PHP и Java Container должно быть сделано, используя хотя бы SSH, что потребует большой конфигурации в обоих контейнерах (PHP в качестве клиента, Java в качестве сервера), а также требует большого количества кода внутри самого приложения, для подключения к SSH -серверу и выполнить команду CLI.
Я подумал -Разве не более быстрее справиться со всем этим?
Могу ли я установить Java непосредственно в контейнер PHP?
Вместо соединения SSH я подумал, что просто установил бы Java в контейнер PHP. Это позволило бы мне выполнить CLI Structureizr, просто используя оболочку в том же контейнере. Я мог бы просто использовать компонент процесса Symfony в качестве абстракции. Это решение позволит мне сэкономить много времени!
Но есть улов! Java и PHP теперь подключены. Я не могу масштабировать, обновлять, управлять и перезагрузить их независимо. Но мне это волнует?
Давайте подумаем о том, что мне нужно от каждого компонента:
- Мне нужна масштабируемость?Это новая платформа SaaS, и у меня нет десятков тысяч пользователей. Мне еще не нужно масштабировать.
- Мне нужно обновлять отдельно?Я бы, но это не критическая услуга. Это выполняет только одну команду CLI. Здесь нет критически важных операций.
- Нужна ли мне управлять?Приятно иметь, но Java используется только для одной команды CLI. Нет веб -сервера, нет подключения к базе данных - просто простая локальная команда CLI. Мне не нужно управлять им в больших масштабах. Если он не удается, модуль интеграции StructuRizR также потерпит неудачу, и у меня есть журналы внутри контейнера PHP.
- Мне нужен независимый перезапуск?Выполнение этой команды CLI строго подключено к модулю PHP. Java рассматривается как местная сервис, которая доступна только для этого контейнера - PHP. Когда PHP снизится, Java бесполезна. Так что нет - мне не нужна такая независимость.
Как видите, нет никаких оснований избегать установки Java в PHP. Но есть веская причина установить его - время и стоимость! Я могу сэкономить много времени. Вместо того, чтобы настраивать все эти вещи, я могу просто выполнить команду оболочки непосредственно из PHP. И это работает как очарование!
Как это работает в реальной практике?
Pistacy.io- Это название платформы - используетphp:8.3-fpmИзображение в качестве основания для контейнера PHP. Изображение построено с использованием Dockerfile, потому что мне нужно установить пользовательские расширения и либерации. Где -то внутри него есть только одна линия, которая устанавливает Java:
FROM php:8.3-fpm AS base
# ...
RUN apt-get install -y default-jre
# ...
В базе Code мне нужно выполнить команду CLI в оболочке, чтобы проверить синтаксис DSL Structurizr и, наконец, преобразовать ее в JSON. Как упомянуто выше,Pistacy.ioДля этого использует компонент процесса Symfony.
Решение выглядит следующим образом:
$process = new Process([
$this->projectDir . '/services/structurizr-cli/structurizr.sh',
'export',
'-workspace', $workingDirectory . '/workspace.dsl',
'-format', 'json',
]);
$process->run();
if (!$process->isSuccessful()) {
// Parse response error and decide what to do in case of error
}
Аstructurizr.shявляется официальным релизом Cli StructuRizr изhttps://github.com/structurizr/cliПолем Он установлен во время развертывания и устанавливается внутри изображения Docker, чтобы быть доступным для процесса PHP.
Вот и все! Никаких дополнительных сервисов, нет конфигурации, нет SSH -соединения. Просто исполнение оболочки старой школы. Я сэкономил много времени, и это того стоило!
Когда использует анти-паттерн хорошей идеей?
Помните, что такой подход является анти-паттерном. В некоторых случаях это стоит использовать:
- Ваш сервис второго класса (Java) зависит от первоклассного обслуживания (PHP). В Pistacy.io, если PHP не работает, Java бесполезна, потому что это нечего называть.
- Вам не нужно масштабировать или оба сервиса масштабируются на одном уровне. В Pistacy.io в настоящее время нет необходимости масштабироваться независимо.
- Вам не нужно управлять/перезапустить/обновить службу второго класса. В Pistacy.io Java полностью зависит от PHP - она не функционирует без него. Кроме того, это просто одна команда CLI.
- Операция, выполняемая услугой второго класса, не является критически важной. В Pistacy.io проверка DSL-DSL-это лишь одна особенность среди многих, а не высокоприоритетная.
Но вам нужно рассмотреть потенциальные проблемы:
Потенциальные сбои в службе второго класса могут сломать весь контейнер-и это наиболее важное соображение здесь. Например, Java, работающая внутри контейнера PHP, может снизить всю услугу PHP. Я должен быть готов к этому с надлежащим мониторингом и процессом восстановления.
Выталкивание слишком большого количества функций, которые полагаются на услугу второго класса-без в конечном итоге переносить его в отдельный контейнер Docker,-может привести к значительному техническому долгу. Pistacy.io в настоящее время использует только одну команду CLI в Java. Но если нам когда -нибудь понадобится несколько команд, или если Java начнет выполнять более сложные задачи за пределами простого выполнения CLI, ее следует перенести в свой собственный контейнер.
Другие соображения:
- Управление журналами: Служба второго класса может иметь свои собственные каталоги или файлы журнала. Вам нужно будет учитывать тех, кто будет должным образом отлаживать проблемы.
- Повышенная поверхность атаки: Больше программного обеспечения означает больше потенциальных пробелов в безопасности.
- Больший размер изображения: Это может негативно повлиять на время выполнения конвейера CI/CD, поскольку для окружающей среды необходимо получить больше данных.
Последние мысли
Это решение работает как очарование в моей системе, но это не значит, что оно будет работать для вашего. Всегда взвешивайте плюсы и минусы, чтобы не построить что -то хрупкое или накапливаться ненужным техническим долгами.
Если вам любопытно увидеть это решение в действии, я рекомендую посетитьhttps://pistacy.ioи импорт популярного рабочего пространства Big Bank PLC, которое вы можете найти здесь:https://github.com/structurizr/examples/blob/main/dsl/big-bank-plc/workspace.dslПолем
Когда вы сохраняете DSL, Pistacy выполняет CLI structurizr (Java), чтобы проверить его, и экземпляр StructuRizR локализации (узел) для отображения диаграмм на заднем плане-все в одном контейнере Docker, используя процесс Symfony.
Если вы ищете решение для управления документацией по архитектуре программного обеспечения, Pistacy.io позволяет создавать модели C4, голосовать за ADR и RFC, определять архитектурные драйверы и многое другое.
Оригинал