Многопользовательские контейнеры для кластеров Azure Container DC/OS

Question

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

Azure, похоже, не поддерживает развертывание в нескольких регионах прямо сейчас. Исходя из этого предположения, я полагаю, что единственным моим вариантом является создание нескольких одинаковых кластеров во всех регионах, в которых я хочу быть доступным, а затем использовать Azure Traffic Manager для маршрутизации входящего трафика в ближайший доступный кластер.

Хотя это решение работает, это также вызывает несколько проблем, на которых я не уверен на 100%, как я должен работать.

1. Наши развертывающие трубопроводы должны развертываться во всех регионах при развертывании новой версии сервиса. Если у нас есть регион Восточной Америки и Северной Европы, во время развертывания нашего инструмента CI я должен подключиться к API Marathon в обоих регионах для запуска новых развертываний. Если развертывание завершается с ошибкой в ​​одном регионе и преуспевает в другом, у меня внезапно возникает несоответствие между этими двумя регионами.
2. Если у меня есть служба, использующая локальные постоянные тома, скажем, PostgreSQL или ElasticSearch, она должна иметь экземпляры в обоих регионах, так как обнаружение службы будет находить только службы, локальные для региона. Это ставит проблему репликации между регионами, чтобы сохранить все государства во всех регионах; это, по-видимому, требует некоторых/много ручной настройки, чтобы работать.

Кто-нибудь когда-либо использовал настройку, подобную этой, используя Azure Container Service (или, действительно, Amazon Container Service, поскольку я предполагаю, что там могут быть обнаружены те же проблемы) и есть некоторые указания относительно того, как подойти к этому?

Answer 1

Вы правы ACS в настоящее время не поддерживает многорегиональные развертывания.

Ваша первая проблема касается Marathon в DC/OS, я буду пинговать некоторых инженеров, чтобы узнать, есть ли у них какой-либо вклад в лучшую практику.

Ваш второй пункт - это то, что мы (я - АС АС) смотрят. Существуют некоторые решения, которые можно использовать в определенных сценариях (например, ArangoDB находится в юниверсе DC/OS и обеспечит репликацию). Команда DC/OS может иметь что сказать и здесь. В ACS мы оцениваем лучшие подходы к предоставлению решений для этого варианта использования, но, боюсь, я не могу дать никаких указаний о сроках.

Альтернативное решение заключается в том, чтобы ваша база данных была предложена компанией SaaS. Это устраняет всю сложность управления резервированием и репликацией.

Answer 2

У вас есть несколько вариантов поворота по регионам. Я бы использовал пользовательскую установку вместе с terraform для каждого из них. Это отличная отправная точка: https://github.com/bernadinm/terraform-dcos

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

Распространение мастеров (дающих вам контроль над службами во время сбоев) немного более сложно, так как включает в себя распределение кворума zookeeper по ссылкам с высокой задержкой, поэтому вы должны быть осторожны при выборе «расстояния» между регионами.

Для получения дополнительной информации см. documentation.