Пропоную ознайомитись із розшифровкою доповіді Олександра Сігачова Service Discovery у розподілених системах на прикладі Consul.
Service Discovery створений для того, щоб з мінімальними витратами можна підключити нову програму до нашого оточення. Використовуючи Service Discovery, ми можемо максимально розділити або контейнер як докера, або віртуальний сервіс від оточення, у якому він запущений.
Я вітаю всіх! Я Сігачов Олександр, працюю в компанії Inventos. І сьогодні я познайомлю вас з таким поняттям як Service Discovery. Розглянемо ми Service Discovery з прикладу Consul.
Які проблеми вирішує Service Discovery? Service Discovery створений для того, щоб з мінімальними витратами можна підключити нову програму до нашого оточення. Використовуючи Service Discovery, ми можемо максимально розділити або контейнер як докера, або віртуальний сервіс від оточення, у якому він запущений.
Як це виглядає? На класичному прикладі в Інтернеті - це фронтенд, який приймає запит користувача. Далі виконує маршрутизацію його на backend. На даному прикладі це load-balancer балансує на два backend.
Тут ми бачимо, що ми запускаємо третій екземпляр програми. Відповідно, коли програма запускається, вона здійснює реєстрацію в Service Discovery. Service Discovery повідомляє load-balancer. Load-balancer змінює свій конфіг автоматично і вже новий backend підключається до роботи. Таким чином, можуть додаватися backend, або, навпаки, виключатися з роботи.
Що ще зручно робити за допомогою Service Discovery? У Service Discovery можуть зберігатися конфіги nginx, сертифікати та список активних backend-серверів.
Також Service Discovery дозволяє виявити збій, виявити відмови. Які можливі схеми виявлення відмов?
- Ця програма, яку ми розробили, сама повідомляє Service Discovery, що вона ще досі працездатна.
- Service Discovery зі свого боку опитує програму на факт доступності.
- Або ж використовується сторонній скрипт або програма, яка перевіряє нашу програму на доступність і повідомляє Service Discovery, що все добре і можна працювати, або, навпаки, що все погано і необхідно цей екземпляр програми виключити з балансування.
Кожна зі схем може застосовуватись залежно від того, яке ми використовуємо. Наприклад, ми тільки почали розробляти новий проект, ми без проблем можемо забезпечити схему, коли наша програма повідомляє Service Discovery. Або можемо підключити, що Service Discovery проводить перевірку.
Якщо ж програма дісталася нам у спадок або розроблена кимось стороннім, то тут підходить третій варіант, коли ми пишемо обробник, і все це встає в нашу роботу автоматично.
Це один із прикладів. Load-balancer як nginx перезавантажується. Це додаткова утиліта, яка надається разом із Consul. Це consul-template. Ми описуємо правило. Говоримо, що використовуємо шаблон (шаблонізатор Golang). При здійсненні подій, при сповіщеннях, що відбулися зміни, він перегенерується і Service Discovery надсилається команда "reload". Найпростіший приклад, коли події переконфігурується nginx і перезапускається.
Що таке Consul?
-
Перш за все це Service Discovery.
-
Він має механізм перевірки доступності – Health Checking.
-
Також має KV Store.
-
І в його основу закладено можливість використати Multi Datacenter.
Навіщо все це можна використовувати? У KV Store ми можемо зберігати приклади конфігів. Health Checking ми можемо проводити перевірку локального сервісу та повідомляти. Multi Datacenter використовується для того, щоб можна було збудувати карту сервісів. Наприклад, Amazon має кілька зон і маршрутизує трафік найбільш оптимально, щоб не було зайвих запитів між дата-центрами, які тарифікуються окремо від локального трафіку і, відповідно, мають меншу затримку.
Трохи розберемося з термінами, які у Consul використовуються.
- Consul – сервіс, написаний Go. Однією з переваг програми на Go є 1 бінарний файл, який ти просто скачав. Запустив із будь-якого місця і в тебе жодних залежностей немає.
- Далі за допомогою ключів ми можемо запустити цей сервіс у режимі клієнта або в режимі сервера.
- Також атрибут «datacenter» дозволяє поставити прапор якого дата-центру належить даний сервер.
- Consensus - базується на протоколі raft. Якщо комусь цікаво, то про це можна прочитати детальніше на сайті Consul. Це протокол, який дозволяє визначити лідера та визначити які денні вважати валідними та доступними.
- Gossip – це протокол, який забезпечує взаємодію між нодами. Причому ця система децентралізована. В рамках одного дата-центру всі ноди спілкуються із сусідами. І, відповідно, передається одна одній інформація про актуальний стан. Можна сказати, що це плітки між сусідами.
- LAN Gossip – локальний обмін даних між сусідами у межах одного дата-центру.
- WAN Gossip – використовується, коли необхідно синхронізувати інформацію між двома дата-центрами. Інформація йде між нодами, які позначені як сервер.
- RPC дозволяє виконувати запити через клієнта на сервері.
Опис RPC. Допустимо, на віртуальній машині або фізичному сервері запущений Consul у вигляді клієнта. До нього локально звертаємось. А далі локальний клієнт запитує інформацію у сервера та синхронізується. Інформація залежно від налаштувань може видаватися з локального кеша, або може бути синхронізована з лідером, із майстром сервера.
У цих двох схем є як плюси, і мінуси. Якщо ми працюємо з локальним кешем, це швидко. Якщо ми працюємо з даними, які зберігаються на сервері, це довше, але отримуємо більш актуальну інформацію.
Якщо це зобразити графічно, то така картинка сайту. Ми бачимо, що у нас запущено трьох майстрів. Один зірочкою позначений як лідер. У цьому прикладі три клієнти, які між собою обмінюються локально інформацією UDP/TCP. А інформація між дата-центрами передається між серверами. Тут клієнти взаємодіють між собою локально.
Який API надає Consul? Для того, щоб отримати інформацію, є два види API у Consul.
Це DNS API. За промовчанням Consul запускається на 8600 портів. Ми можемо налаштувати проксіювання запиту і забезпечити доступ через локальний резолвінг, через локальний DNS. Ми можемо запросити по домену і отримаємо у відповідь інформацію про IP-адресу.
HTTP API - або ми можемо локально на 8500 порту запитати інформацію про конкретний сервіс і отримаємо JSON відповідь, який IP має сервер, який host, який порт зареєстрований. І додаткову інформацію можна передати через token.
Що потрібно, щоб запустити Consul?
У першому варіанті в режимі розробника вказуємо прапор, що це режим розробника. Agent стартує як сервер. І всю функцію виконує вже самостійно на одній машині. Зручно, швидко і ніяких додаткових налаштувань для першого старту не потрібно.
Другий режим – це запуск у production. Тут запуск трохи ускладнюється. Якщо ми не маємо жодної версії консула, то ми повинні привести в bootstrap першу машину, тобто ця машина, яка візьме на себе обов'язки лідера. Ми піднімаємо її, потім піднімаємо другий екземпляр сервера, передаючи йому інформацію, де у нас знаходиться майстер. Третій піднімаємо. Після того, як у нас піднято три машини, ми на першій машині із запущеного bootstrap, перезапускаємо її у звичайному режимі. Дані синхронізуються, і початковий кластер вже піднято.
Рекомендується запускати від трьох до семи екземплярів у режимі сервера. Це зумовлюється тим, що й кількість серверів зростає, то збільшується час на синхронізацію інформації з-поміж них. Кількість нід повинна бути непарною, щоб забезпечити кворум.
Як забезпечують Health Checks? У директорію конфігурації Consul ми у вигляді Json пишемо правило перевірки. Перший варіант – це доступність у цьому прикладі домену google.com. І кажемо, що через інтервал у 30 секунд потрібно виконувати цю перевірку. Таким чином, ми перевіряємо, що наша нода має доступ до зовнішньої мережі.
Другий варіант – це перевірка себе. Ми звичайним curl смикаємо localhost по вказаному порту з інтервалом у 10 секунд.
Ці перевірки підсумовуються та надходять до Service Discovery. З доступності ці ноди або виключаються, або з'являються списку доступних і коректно працюючих машинок.
Також Consul надає UI-інтерфейс, який з окремим прапором запускається та буде доступний на машинці. Це дозволяє переглядати інформацію, а також можна вносити деякі зміни.
У цьому прикладі відкрито вкладку «Сервіс». Показано, що запущено три сервіси, один із них Consul. Кількість виконаних перевірок. І є три дата-центри, в яких знаходяться машини.
Це приклад вкладки "Nodes". Бачимо, що вони мають складові імена за участю дата-центрів. Тут також показано, які послуги запущені, тобто ми бачимо, що теги не задані. У цих додаткових тегах можна встановити якусь інформацію, яку розробник може використовувати для вказівки додаткових параметрів.
Також можна передавати інформацію в Consul про стан дисків, про середнє завантаження.
Питання
Питання: У нас є докер-контейнер, як його використовувати з Consul?
Відповідь: Для докер-контейнера є кілька підходів. Один із найпоширеніших – це використовувати сторонній докер-контейнер, який відповідає за реєстрацію. Під час запуску йому прокидається сокет докера. Усі події з реєстрації та депублікації контейнера заносяться до Consul.
Запитання: Т. е. Consul сам запускає докер-контейнер?
Відповідь: Ні. Ми запускаємо докер-контейнер. І за конфігурації вказуємо – слухай такий сокет. Це приблизно так само, як іде робота з сертифікатом, коли ми прокидаємо інформацію, де і що у нас лежить.
Питання: Виходить, що всередині докер-контейнера, який ми намагаємося підключити до Service Discovery, має бути якась логіка, яка вміє віддавати дані Consul?
Відповідь: Не зовсім. Коли він стартує, ми через змінне оточення передаємо змінні. Допустимо, сервіс name, сервіс порт. У регістрі слухає цю інформацію та заносить до Consul.
Питання: У мене ще UI питання. Ми розгорнули UI, скажімо, на production-сервері. Що з безпекою? Де зберігаються дані? Чи можна якось акумулювати дані?
Відповідь: У UI якраз дані з бази та з Service Discovery. Паролі ми ставимо в налаштуваннях самостійно.
Запитання: Це можна публікувати в інтернеті?
Відповідь: За замовчуванням Consul стартує localhost. Щоб публікувати в цьому інтернеті, треба буде поставити якийсь проксі. За правила безпеки ми відповідаємо самі.
Питання: Історичні дані із коробки видає? Цікаво подивитися статистику з Health Checks. Можна ж діагностувати проблеми, якщо сервер часто виходить з ладу.
Я не впевнений, що там є деталі перевірок.
Питання: Не так важливий поточний стан, як важлива динаміка.
Відповідь: Для аналізу – так.
Питання: Service Discovery для докера Consul краще не використовувати?
Відповідь: Я не рекомендував би його використовувати. Мета доповіді – познайомити, що таке поняття. Історично він пройшов шлях, по-моєму, до першої версії. Наразі вже є більш повноцінні рішення, наприклад, Kubernetes, який все це має під капотом. У складі Kubernetes Service Discovery поступається Etcd. Але я з ним не так щільно знайомий, як із Consul. Тому Service Discovery я вирішив зробити на прикладі Consul.
Питання: Схема з сервером лідером не гальмує старт програми загалом? І як Consul визначає нового лідера, якщо це лежить?
Відповідь: Вони описують цілий протокол. Якщо цікаво, можна почитати.
Питання: Consul у нас є повноцінним сервером і всі запити літають через нього?
Відповідь: Він виступає не повноцінним сервером, а бере певну зону. Вона зазвичай закінчується service.consul. І далі ми вже за логікою йдемо. Ми не використовуємо в production доменні імена, а саме внутрішню інфраструктуру, яка зазвичай ховається за кешування сервера, якщо ми працюємо через DNS.
Питання: Тобто, якщо ми хочемо звернутися до бази даних, то ми в будь-якому випадку будемо смикати Consul, щоб знайти цю базу спершу, правильно?
Відповідь: Так. Якщо працюємо за DNS, це працює як без Consul, коли використовуємо DNS імена. Зазвичай сучасні програми не в кожному запиті смикають доменне ім'я, тому що ми connect встановили все працює і найближчим часом ми практично не використовуємо. Якщо connect розірвався, то так, ми знову запитуємо, де у нас лежить база і йдемо до неї.
- Чат користувачів Hashicorp: Consul, Nomad, Terraform
PS З приводу health checks. У Consul як і Kubernetes використовується однакова система перевірки стану живучості сервісу з урахуванням статус коду.
200 OK for healthy
503 Service Unavailable for unhealthyДжерела:
Джерело: habr.com