Чи буде невірним сказати, що найкращі з людей
знаходять радість через страждання.
Людвіг ван Бетховен
Я Сергій, працюю в Яндекс.Грошах у команді з дослідження продуктивності. Хочу розповісти вам початок історії про наш шлях до використання оркестрування – як ми вибирали інструменти і що при цьому враховували. Усі події зі статті відбуваються у реальному часі, тому ви, дорогі читачі, стежите за розвитком ситуації практично у прямому ефірі.
Навіщо нам диригент у команді?
Хто ж такий диригент? Від фр. diriger — керувати, спрямовувати, керувати — у світі музики — це людина, керівник розучування та виконання ансамблевої музики. У нашому випадку це місце займають системи оркестрації та автоматизації.
Їхня роль нічим не відрізняється від ролі диригента в музиці — вони потрібні, щоб допомагати команді, спрямовувати та організовувати її гру.
Як правило, команда має деякий набір потужностей — назвемо їх серверами, на яких вони реалізують свої проекти.
Підхід до отримання та експлуатації цих серверів різноманітний. Декілька прикладів:
- Команда запитує, наприклад у групу експлуатації, на надання їм ресурсів з певними параметрами.
- Група експлуатації надає їм необхідну кількість - cloud або bare metal ("голе залізо") - і зобов'язуються підтримувати їх у належному стані згідно з SLA. Налаштування також виконується силами групи експлуатації.
- Команда отримує лише ресурси cloud або bare metal від групи експлуатації, налаштування вона робить самотужки.
- Команда сама «закуповує» ресурси та підтримує/налаштовує їх повністю самостійно.
У нашій команді використовуються сервери, які потрібно підтримувати — оновлювати ОС, встановлювати нові пакети тощо.
Для себе ми виділили їх у два основні типи:
- танкова група,
- Сервісна група.
Танкова група складається з хостів з Яндекс.Танком.
Сервісна група має у своєму складі все, що пов'язане з обслуговуванням, - це різні сервіси забезпечення підтримки релізного циклу, генерації автоматичних звітів і т.п.
Одного разу всім цим стало незручно керувати в ручному режимі, і ми задумалися про автоматизацію всього процесу, починаючи від «наливки» серверів і закінчуючи розробкою, викладенням та запуском нашого внутрішнього сервісу.
Чому диригент потрібний, навіть якщо оркестр сам уміє грати?
Для початку ми освоїли Ansible і стали «наливати» наші сервери bare metal, щоб бути менш залежними від системних адміністраторів — тут виграють усі, ми отримуємо нові навички та позбавляємо адміністраторів частини роботи, якої у них і без нас завжди вистачає. Ми прагнемо розвитку поза своєю спеціальністю та автономністю команди, наскільки це можливо.
У компанії робота з Ansible вже досить давно налаштована та регламентована, тому ми легко вбудували своє рішення у цей процес.
Зараз налив хостів складається з трьох ролей Ansible:
- перша роль встановлює OS,
- друга прокочує базові налаштування для хоста, LDAP-авторизацію, наприклад,
- і третя встановлює у docker-контейнері Яндекс.Танк та супутні залежності.
Перейдемо до послуг, які ми використовуємо всередині команди.
Для своїх завдань ми однаково використовуємо Kotlin і Python, а ще трохи Golang. Щоб уніфікувати розробку та розгортання наших сервісів, ми вирішили пакувати їх у docker-контейнери. Це дає свободу вибору мови програмування та одночасно регулює єдиний формат постачання своєї програми.
Невелика ремарка про ipv6 в Docker
Частина сервісів, з якими ми взаємодіємо, доступна лише ipv6, тому довелося розібратися, як зробити ipv6 для контейнерів.
Згідно з документацією ipv6 на офіційному сайті Docker, ipv6 включається додаванням параметрів в daemon.json:
{
"ipv6": true,
"fixed-cidr-v6": "2001:db8:1::/64"
}При цьому провайдер повинен видати підмережу ipv6, яку ви пропишете в fixed-cidr-v6.
Однак ми вибрали інший варіант - ipv6 NAT, і ось чому:
- Зараз docker лише з ipv6.
- Наявність у кожному контейнері адреси, що глобально маршрутизується, означає, що всі порти (навіть неопубліковані) стають доступними всім, якщо не виконується додаткова фільтрація.
- userland proxy для опублікування портів, .
ipv6 NAT - це що сам управляє правилами в ip6tables і редагує їх при додаванні нового контейнера.
Щоб це рішення коректно запрацювало, необхідно було зробити ще низку маніпуляцій. Обов'язково ініціалізувати ip6table_nat у системі. Наявність встановленого в системі модуля не гарантує, що під час запуску модуль буде завантажений у ядро. Ми зіткнулися з цим, коли отримали таку помилку при запуску контейнера з NAT на свіжому хості:
2019/01/22 14:59:54 running [/sbin/ip6tables -t filter -N DOCKER --wait]: exit status 3: modprobe: can't change directory to '/lib/modules': No such file or directory
ip6tables v1.6.2: can't initialize ip6tables table `filter': Table does not exist (do you need to insmod?)Проблема вирішилася після додавання в роль Ansible ініціалізації за допомогою модуля modprobe і завантаження при старті ОС за допомогою lineinfile:
- name: Add ip6table_nat module
modprobe:
name: ip6table_nat
state: present
- name: Add ip6table_nat to boot
lineinfile:
path: /etc/modules
line: 'ip6table_nat'До речі, на хабрі є гарна , яка коротко і ясно описує переваги та недоліки того чи іншого методу для роботи ipv6 у docker.
Але повернемося до нашого питання, поставленого на початку:
Чому диригент потрібний, навіть якщо оркестр сам уміє грати?
Тепер усі уявляють, як грати в нашій команді:
- процес «наливки» серверів створено,
- розробка та деплой сервісів уніфіковані.
Постає резонне питання — як ефективно та максимально автоматизовано деплоїти, оновлювати, контролювати наші сервіси у docker-контейнерах?
Незважаючи на те, що кожен учасник оркестру знає свою партію, він може збиватися, відходити від початкового задуму. Тут ми й приходимо до того, що без диригента наш оркестр не ефективно репетируватиме і злагоджено гратиме. Диригент відповідає за всі параметри виконання, за те, щоб все об'єднувалося єдиним темпом і настроєм.
Як з мінімальними вкладеннями отримати хорошого диригента?
Тема оркестрації досить добре розвинена над ринком. Але спочатку поговоримо про допоміжні інструменти, які можуть допомогти диригенту.
- Система, яка надає дві основні функції:
- виявлення сервісів (service discovery),
- розподілене сховище ключ-значення.
У нашому оркестрі Consul буде відповідати за реєстрацію сервісів та збереження їх конфігурацій. Є два варіанти реєстрації:
- Активна - це коли сервіс сам реєструє себе використовуючи HTTP API;
- Пасивна – сервіс необхідно прописати вручну.
Vault – це сховище, яке стандартизує та уніфікує безпечне зберігання та роботу з секретами – паролі, сертифікати.
Ось переваги, які ми отримаємо, використовуючи цей інструмент:
- Єдиний центр створення та зберігання секретів, управління їх життєвим циклом за допомогою HTTP API.
- Transit Secrets Engine - шифрування-дешифрування даних без їх збереження. Можливість передачі даних у зашифрованому вигляді незахищеними каналами зв'язку.
- Політики доступів, які зручно налаштовувати.
- Аудит доступу до секретів.
- Можливість створення власного CA (Certificate Authority) для управління самопідписаними сертифікатами всередині своєї інфраструктури.
Враховуючи всі наші вимоги, на роль диригента підходили два варіанти – Kubernetes та Nomad.
Кубернетес
Скільки вже написано про нього статей та книг (ось , Приміром), розказано доповідей, що напишу коротко - це універсальний комбайн, який може практично все. Плата за це – не завжди легкі налаштування та підтримка кластера на Kubernetes.
Кочівник
від HashiCorp, компанії, відомої за згаданими вище consul та vault.
Nomad здався нам досить простим у встановленні та налаштуванні, ніж Kubernetes. Один бінарний файл працює як у режимі сервера, і клієнта. При цьому Nomad покриває весь список завдань, які ми хочемо, щоб він вирішував: управління кластером, швидкий планувальник, підтримка multidatacenter. Плюс при використанні consul та vault ми отримуємо тіснішу інтеграцію для оркестрування наших сервісів.
Що зараз у роботі:
- підготували сервери для розгортання Consul,
- у Consul буде занесена конфігурація кластера nomad, за допомогою якої nomad має бути розгорнутий автоматично,
- паралельно встановлюватимемо vault для зберігання секретів.
Питання в зал — чи варто заводити диригента для таких завдань чи оркестру і без нього добре? Розкажіть у коментарях, що ви думаєте з цього приводу.
Підписуйтесь на наш блог і залишайтеся на зв'язку — незабаром розповімо, що в результаті вийшло, і чи ми налаштували кластер nomad, тому що нам цього хотілося.
Заходьте у наш затишний де ви завжди можете попросити поради, допомогти колегам і просто поспілкуватися на тему досліджень продуктивності і не тільки.
Джерело: habr.com
