Использование haproxy/iptables+etcd+confd для автоматического service...
TRANSCRIPT
Использование haproxy/iptables + etcd + confd для автоматического service-discovering’а в переменчивых сетях Сергей Пузырёв
Service-oriented architecture 1. Приложение состоит из множества слабо связанных
сервисов, которые общаются друг с другом с использованием четко определённого API.
2. Сервисы ничего не знают о клиентах, их задача – оказывать сервис.
3. Клиента не волнует, каким образом работает сервис. 4. Сервисы используют другие сервисы.
Service-oriented architecture Что такое сервис? 1. У сервиса есть интерфейс – API. 2. Сервис имеет точку входа (endpoint) – обычно пара
IP:port. 3. Сервис может пользоваться другими сервисами. В этом
случае он должен быть правильно сконфигурирован.
Service-oriented architecture Пример сервиса - memcached: 1. API: стандартный протокол memcached. 2. Endpoint: например, 10.0.0.7:11211. 3. Сервисы, которыми пользуется memcached, отсутствуют.
Client Memcached
Service-oriented architecture Пример сервиса - mcrouter: (github.com/facebook/mcrouter) 1. API: стандартный протокол memcached. 2. Endpoint: например, 10.0.0.6:11211. 3. Mcrouter пользуется двумя сервис memcached. Endpoint
сервиса memcached забит в конфиг mcrouter.
Client Mcrouter
Memcached Memcached
Service-oriented architecture Несложное PHP-приложение:
Php-fpm
Memcached
MySQL slave
Nginx
Php-fpm
MySQL master Memcached
Mcrouter
Static storage
16 отношений client<->service
Service-oriented architecture Сложное приложение (мопед не мой):
Как связывать сервисы друг с другом? Дешево и сердито: хардкод endpoint’ов в конфиги. Плюсы: 1. Очень быстрый старт. 2. Просто, нужен только vim. 3. Ничего не ломается само. Минусы: 1. Не работает в большом проекте. 2. Требуется вручную поддерживать документацию. 3. Сложно вносить массовые изменения, подключать
новые инстансы сервисов, мигрировать сервисы.
Как связывать сервисы друг с другом? Дешево и сердито: DNS + хардкод. Плюсы: 1. Лишь немного сложнее хардкода IP-адресов. 2. Почти так же просто, нужен только vim и DNS-сервер. 3. Проще вносить массовые изменения. Минусы: 1. По прежнему не работает в большом проекте. 2. Так же требуется вручную поддерживать документацию. 3. Сложно подключать новые инстансы сервисов. 4. Асинхронность внесения изменений, лаги. 5. Софт часто не перерезолвливает записи.
Появляются сотни сервисов. Потом тысячи.
Как связывать сервисы друг с другом? Системы управления конфигурацией (Puppet, SaltStack, etc.). Плюсы: 1. При правильной организации проще вносить
изменения. 2. Один инструмент для всего. Минусы: 1. Медленно! 2. При неправильной организации вносить изменения
становится очень сложно. 3. Неактуальная документация продолжает существовать.
Как связывать сервисы друг с другом? Пусть роботы всё делают за нас! Системы service-discovering’а.
Service-discovering Что это такое? Система обнаружения сервисов (СОС) – специальный сервис, в котором другие сервисы могут делать две вещи: 1. Регистрироваться (записывать свой endpoint). 2. Находить другие сервисы (читать предварительно
зарегистрированные endpoint’ы других сервисов).
Часто системы обнаружения сервисов предоставляют также сервис распределённых блокировок. Примеры: Zookeeper, etcd, consul, SkyDNS, etc.
Service-discovering Etcd: что это такое и как с этим жить? github.com/coreos/etcd Etcd - высоконадёжное распределенное хранилище параметров конфигурации, задаваемых в форме key->value. Etcd также можно использовать как систему распределенных блокировок.
Service-discovering Confd: что это такое и зачем оно нужно? www.confd.io Confd - легковесная система конфигурации, специально созданная для отслеживания данных в etcd, шаблонизирования конфигов и перезапуска приложений при изменении данных в etcd. NB: нередко вместо Confd можно использовать скрипт на bash, наподобие while true ; do smth ; done .
Service-discovering
Etcd
Client
Confd
Announcer
Mcrouter
Announcer
Memcached
Announcer
Memcached
Confd
Как связывать сервисы друг с другом? Системы service-discovering’а: Плюсы: 1. Очень быстрое внесение изменений. 2. Не требуется документировать, что где работает и как
должно быть сконфигурировано. Минусы: 1. Сложно. 2. Страшно – “а вдруг развалится?”. 3. Внешние сущности в виде confd и announcer’а. В идеале
нужно обучать сервисы общаться с etcd напрямую.
Как связывать сервисы друг с другом? Что мы хотели? 1. Приложения не должны постоянно перезапускаться (до
свидания, confd). 2. Мы не хотели привязывать тонны legacy-кода наших
приложений к СОС. 3. Облегчить миграцию сервисов на новые endpoint’ы, не
требующую переконфигурации тысяч других сервисов (ради чего и затевалось).
4. Приложение не должно деградировать в условиях сломавшейся СОС, выключившегося датацентра, тормозящей сети и т.п. более, чем деградировало бы без СОС.
Как связывать сервисы друг с другом?
Как связывать сервисы друг с другом? Трудно связать сервисы друг с другом? Давайте инкапсулируем связь между сервисами в отдельный сервис!
Etcd + iptables/HAproxy + confd Было так:
Etcd
Client
Confd
Announcer
Mcrouter
Announcer
Memcached
Announcer
Memcached
Confd
Etcd + iptables/HAproxy + confd А стало так:
Etcd
Client
Confd
Announcer
Mcrouter
Announcer
Memcached
Announcer
Memcached
Confd
HAProxy
Etcd + iptables/HAproxy + confd Почему так? 1. Некоторые приложения трудно перезапускать. 2. Постоянно писать шаблоны к разному софту утомляет. 3. Бесплатная статистика от HAproxy. 4. В простых кейсах получаем еще и бесплатную
балансировку.
Что плохо? 1. HAproxy не умеет в UDP.
Etcd + iptables/HAproxy + confd А iptables DNAT умеет:
Confd Confd
Etcd
iptables DNAT
iptables DNAT
Client statsd Carbon (Graphite)
Результат 1. Миграции сервисов становятся безболезненными. 2. Добавление новых инстансов сервисов в простых кейсах
(когда можно просто добавить инстанс в пул HAProxy) происходит очень легко.
3. Нельзя забыть что-то переконфигурировать. 4. Новых конфигов требуют только новые типы сервисов.
