Высокая доступность ActiveMQ внутри Kubernetes - PullRequest
1 голос
/ 17 февраля 2020

У нас есть приложение, которое использует сервис-ориентированную архитектуру. Он использует Apache ActiveMQ в качестве шины сообщений. У нас есть серверные приложения, установленные на виртуальных машинах в двух географически разделенных центрах обработки данных. Кроме того, клиентские приложения, установленные на удаленных устройствах, обмениваются данными с серверными приложениями через шину сообщений. Кроме того, есть несколько веб-приложений, которые позволяют операторам взаимодействовать с серверными приложениями или управлять действиями на удаленных устройствах. Веб-приложения используют комбинацию веб-сокетов и HTTP для связи с серверами. Все соединения, конечно, зашифрованы.

Мы думаем о переносе серверных приложений в контейнеры, размещенные в Kubernetes или Swarm. Это поможет нам упростить развертывание. По большей части мы можем найти полезную информацию на различных веб-сайтах и ​​страницах документации. Однако для ActiveMQ нам все еще сложно найти правильную настройку.

В нашей текущей настройке используется сеть брокеров, что обеспечивает высокую доступность и масштабируемость. Масштабируемость (в настоящее время) не является действительно необходимой. Один брокер может легко обработать количество сообщений, проходящих через систему. В основном из-за требований к доступности у нас есть несколько брокеров (по одному на ВМ).

Что было бы хорошим способом удовлетворить эти требования при запуске ActiveMQ (или, возможно, Apache Artemis) внутри Kubernetes? Мы могли бы запустить один POD и позволить Kubernetes позаботиться о функциях HA. Но как клиенты узнали бы, что ActiveMQ-POD умер, и Kubernetes запустил новую реплику, возможно, в другом центре обработки данных?

Конечно, мы могли бы просто развернуть несколько POD, которые мы настраиваем как сеть брокеров, аналогично что мы имеем сейчас. Но тогда нам, вероятно, также необходимо сгенерировать сертификаты для каждого POD, чтобы обеспечить шифрование между клиентом и сервером.

В идеале у нас должен быть только один сертификат, связанный с одним DNS-именем, за которым находится весь наш набор приложений. это работает. Сертификат будет настроен в HAProxy или что-то в этом роде. Внутренне мы будем использовать только самоподписанный сертификат, который будет частью результатов. Таким образом, мы можем развернуть одно и то же приложение на каждом клиентском объекте точно таким же образом, единственной переменной является один сертификат SSL для шифрования трафика c снаружи к точке входа.

...