Какова обычная практика управления внешним IP-адресом роя Docker?
Я создаю рой докеров с 3 менеджерами и 2 рабочими. Служба работает в рое и предоставляет порт 80. Таким образом, мы можем подключиться к службе с помощью IP-адреса любого узла. Но что, если узел выйдет из строя? Ожидать, что пользователь всегда попробует ip другого узла, было бы очень громоздко.
Итак, какова общая практика управления этой внешней точкой доступа? Я могу подумать о настройке записи DNS для возврата IP-адресов нескольких узлов. Установка другого балансировщика нагрузки впереди кажется излишним.
1 ответ
Я вижу несколько вариантов здесь:
1) внешний балансировщик нагрузки.
Если вы работаете в AWS, GCE или других облачных провайдерах, вы можете использовать балансировщик нагрузки в качестве услуги, предоставляемой этими компаниями. Ваши DNS-имена будут указывать на IP-адрес балансировщика нагрузки, а ваш балансировщик нагрузки перенаправляет трафик на ваши узлы.
ПРОФИ: у вас всегда высокая доступность (балансировщик нагрузки избыточен, вам нужно как минимум 2 узла, и вы готовы к работе). Вы также получаете автоматическое переключение при сбое (если происходит сбой узла, запросы перенаправляются на другие узлы вашего кластера).
Минусы: балансировщики нагрузки стоят денег
2) балансировщик нагрузки "сделай сам".
Вы можете запустить другой сервер с haproxy, nginx или любым другим прокси-сервисом, который запускает сервис балансировки нагрузки для вас. DNS будет указывать на прокси-сервер (который на данный момент только один), и он перенаправляет на ваши узлы.
ПРОФИ: ограниченная дополнительная стоимость (прокси может даже быть одним из узлов вашего кластера).
Минусы: вам нужно настроить всю инфраструктуру (аварийное переключение, обнаружение узлов, просто чтобы назвать две вещи, которые вам следует позаботиться). Вы теряете высокую доступность (до тех пор, пока вы не делаете свой прокси избыточным, но я сохраняю вещи простыми)
3) несколько записей DNS.
Вы можете установить несколько IP-адресов в своих записях DNS. В этом случае клиент подключится к случайному узлу в вашем кластере.
ПРОФИ: бесплатно
Минусы: если узел выходит из строя, клиенты все равно будут пытаться подключиться к нему, пока вы не удалите его из DNS (и это требует времени из-за TTL).
Если у кого-то есть другие идеи, я рад услышать