Вопрос или проблема
На сервере запущено 14 PHP контейнеров php_1, ..., php_14 и 14 NGINX контейнеров nginx_1, ..., nginx_14. PHP контейнер php_i подключен только к nginx_i, и все NGINX контейнеры подключены через общую внешнюю сеть. Поэтому php_i может видеть nginx_i, а nginx_i может видеть каждый nginx_j.
В систему добавлено новое требование, и нам необходимо иметь глобальный Elasticsearch для всех проектов, позволяющий всем PHP проектам записывать в эту единую инстанцию Elasticsearch, которая будет установлен через Docker.
Для выполнения этой задачи мне пришли в голову следующие методы, но я не уверен, какой из них лучший подход.
- Установить изолированный инстанс Elasticsearch и опубликовать его порт, скажем,
9200:9200, на хосте, и в конфигурации PHP я укажу IP адрес хоста, скажем,172.17.0.1, и порт9200 - Я могу создать выделенную внешнюю сеть для подключения PHP к Elasticsearch и включить эту выделенную сеть в директиву
networksфайла docker-compose.
Я хотел бы знать, какой метод является лучшей практикой.
#!/bin/bash
# Определение путей и переменных
WILDFLY_HOME=/opt/wildfly
CLI_SCRIPT=/tmp/cli-commands.cli
# Создание файла CLI скрипта
cat << EOF > $CLI_SCRIPT
# Запуск встроенного контроллера хоста с локальной конфигурацией домена
embed-host-controller --jboss-home=$WILDFLY_HOME --domain-config=domain.xml --host-config=host.xml
# Переход к конфигурации хоста
cd /host=master
# Настройка подключения к доменному контроллеру
/host=master/core-service=management/service=remote-domain-controller:write-attribute(name=host,name=master)
# Здесь вы можете добавить больше команд для настройки групп серверов, серверов и т.д.
# Например:
/server-group=main-server-group:write-attribute(name=profile,value=full-ha)
/server-group=main-server-group:write-attribute(name=socket-binding-group,value=full-sockets)
# Сохранение изменений
:shutdown --restart=true
# Выход из CLI
exit
EOF
# Выполнение CLI скрипта с встроенным контроллером хоста
$WILDFLY_HOME/bin/jboss-cli.sh --file=$CLI_SCRIPT
# Очистка временного файла скрипта
rm $CLI_SCRIPT
Ответ или решение
При решении задачи подключения множества PHP контейнеров к единому общему контейнеру Elasticsearch, необходимо выбрать метод, который будет наиболее эффективным и устойчивым в долгосрочной перспективе. Рассмотрим два предложенных метода и оценим их преимущества и недостатки.
1. Публикация порта Elasticsearch на хосте
В этом подходе вы устанавливаете изолированный экземпляр Elasticsearch и публикуете его порт (например, 9200:9200) на хост-машине, после чего настраиваете PHP контейнеры на использование IP адреса хоста и соответствующего порта для подключения к Elasticsearch.
Преимущества:
- Простота конфигурации: Этот метод достаточно прост в реализации и не требует сложных изменений в конфигурации существующих контейнеров.
- Прямая связь: PHP контейнеры обращаются напрямую к хосту, что может снижать задержки в сети.
Недостатки:
- Безопасность: Открытый порт на хосте может быть уязвим для внешних атак, если безопасность не обеспечена на должном уровне.
- Проблемы с адресацией: IP адрес хоста (например, 172.17.0.1) может вызывать проблемы при изменении сети или IP конфигурации.
- Масштабируемость: Модель может быть менее подходящей для больших систем, где более важны изоляция и безопасность.
2. Использование выделенной внешней сети для подключения PHP к Elasticsearch
Этот метод подразумевает создание выделенной внешней сети, через которую PHP контейнеры будут взаимодействовать с контейнером Elasticsearch.
Преимущества:
- Изоляция и безопасность: Создание выделенной сети позволяет лучше контролировать сетевой трафик и безопасность контейнеров.
- Гибкость: Простая интеграция новых сервисов или контейнеров в эту сеть без необходимости изменения конфигурации хоста.
- Масштабируемость: Подходит для систем с высоким трафиком и множественными интеграциями.
Недостатки:
- Сложность настройки: Требуется больше усилий и знаний для создания и управления отдельными сетями в Docker.
- Понадобится контроль за доступами: Нужно настроить доступ так, чтобы только нужные контейнеры имели необходимые права доступа к Elasticsearch.
Вывод
Рекомендуется использовать второй метод – создание выделенной внешней сети. Это обеспечит более высокий уровень безопасности и масштабируемости системы, что особенно важно при росте количества сервисов и пользователей. Несмотря на большую сложность настройки, гибкость и надежность, которые обеспечивает использование выделенных сетей, делают этот подход более предпочтительным для серьезных корпоративных решений.