🥇Оркестър на представления

Малко вероятно е да се каже, че най-добрите от хората
намират радост чрез страдание.
Лудвиг ван Бетовен

Аз съм Сергей, работя в Яндекс.Такси в екипа по изследване на производителността. Искам да ви разкажа началото на историята за нашия път към използването на оркестрация - как избирахме инструментите и какво взехме предвид. Всички събития от статията се случват в реално време, така че вие, скъпи читатели, следите развитието на ситуацията почти на живо.

Защо ни е необходим диригент в екипа?

Кой всъщност е диригентът? От франц. diriger - управлявам, ръководя - в света на музиката, това е човек, ръководител на репетиции и изпълнение на ансамблова музика. В нашия случай това място се заема от системите за оркестрация и автоматизация.

Их ролята не се различава от ролята на диригента в музиката - те са необходими, за да помагат на екипа, да насочват и организират неговата игра.

Обикновено екипът разполага с определен набор от ресурси - да ги наречем сървъри, на които реализират своите проекти.

Подходът към получаването и експлоатацията на тези сървъри е разнообразен. Няколко примера:

Екипът отправя заявка, например до групата по експлоатация, за предоставяне на ресурси с определени параметри.
Групата по експлоатация предоставя необходимото количество - cloud или bare metal („чисто желязо“) - и се ангажира да ги поддържа в добро състояние съгласно SLA. Настройката също се извършва от групата по експлоатация.
Екипът получава само ресурси cloud или bare metal от групата по експлоатация, настройката извършва самостоятелно.
Екипът самостоятелно „закупува“ ресурси и ги поддържа/настройва напълно сам.

В нашия екип се използват сървъри, които трябва да се поддържат - обновяване на ОС, инсталиране на нови пакети и т.н.

За себе си ги разделихме на два основни типа:

танкова група,
сервизна група.

Танковата група се състои от хостове с Яндекс.Танк.

Сервизната група включва всичко, свързано с поддръжка - различни услуги за осигуряване на подкрепа на цикъла на релиза, генериране на автоматични отчети и т.н.

В един момент стана неудобно управлять всичко това ръчно, и започнахме да мислим за автоматизация на целия процес, от 'наливането' на сървъри до разработването, внедряването и стартирането на нашия вътрешен сервис.

Защо диригентът е необходим, дори когато оркестърът сам може да свири?

За начало, усвоихме Ansible и започнахме да 'наливаме' нашите bare metal сървъри, за да зависим по-малко от системните администратори — тук печелят всички, ние получаваме нови умения и освобождаваме администраторите от част от работата, която и без нас винаги им е достатъчно. Стремим се към развитие извън специалността си и автономност на екипа, доколкото е възможно.

В компанията работата с Ansible е организирана и регламентирана от доста време, затова лесно интегрирахме нашето решение в този процес.

Сега наливането на хостове се състои от три роли на Ansible:

първата роля инсталира операционната система,
втората извършва основни настройки за хоста, например 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 за публикуване на портове, iptables само за ipv4.

ipv6 NAT — това е docker контейнер, който сам управлява правилата в ip6tables и ги редактира при добавяне на нов контейнер.

За да проработи това решение, беше необходимо да се направят още няколко манипулации. Задължително е да се инициализира ip6table_nat в системата. Наличието на инсталиран модул не гарантира, че при стартиране модулът ще бъде зареден в ядрото. Столкувахме с това, когато получихме следната грешка при стартиране на контейнера с NAT на нов хост:

2019/01/22 14:59:54 изпълняване [/sbin/ip6tables -t filter -N DOCKER --wait]: exit status 3: modprobe: не може да се промени директорията на '/lib/modules': Няма такава файлова или директорийна структура
ip6tables v1.6.2: не може да инициализира ip6tables таблица `filter`: Таблицата не съществува (трябва ли да insmod?)

Проблемът беше решен след добавянето в ролята на Ansible инициализация с помощта на модула modprobe и зареждането му при стартиране на ОС с помощта на lineinfile:

- name: Добавяне на модула ip6table_nat
 modprobe:
   name: ip6table_nat
   state: present
- name: Добавяне на ip6table_nat в стартиране
 lineinfile:
   path: /etc/modules
   line: 'ip6table_nat'

Между другото, в Хабра има добра статия, която кратко и ясно описва предимствата и недостатъците на различните методи за работа с ipv6 в docker.

Но да се върнем на нашия въпрос, зададен в началото:
Защо диригентът е необходим, дори когато оркестърът сам може да свири?

Сега всички разбират как да играят в нашия отбор:

процесът на „наливане“ на сървъри е създаден,
разработката и деплойването на услуги са унифицирани.

Има основателен въпрос – как ефективно и максимално автоматизирано да деплойваме, обновяваме и контролираме нашите услуги в docker-контейнери?

Въпреки че всеки участник в оркестъра знае своята част, той може да се обърка, да се отклони от първоначалната идея. Тук ние стигаме до заключението, че без диригент нашият оркестър няма да репетира ефективно и да свири слажено. Диригентът отговаря за всички параметри на изпълнението, за да бъде всичко обединено в единен ритъм и настроение.

Как с минимални вложения да получим добър диригент?

Темата за оркестрацията е достатъчно добре развита на пазара. Но първо да поговорим за помощни инструменти, които могат да помогнат на диригента.

Consul — система, която предлага две основни функции:

откриване на услуги (service discovery),
разпределено хранилище ключ-стойност.

В нашия оркестър, Consul ще отговаря за регистрацията на услуги и съхранението на техните конфигурации. Има два варианта за регистрация:

Активна — когато услугата сама се регистрира, използвайки HTTP API;
Пасивна — услугата трябва да бъде упомената ръчно.

Vault е хранилище, което стандартизира и унифицира безопасното съхранение и работа с тайни — пароли, сертификати.
Ето предимствата, които ще получим, използвайки този инструмент:

Единен център за създаване и съхранение на тайни, управление на техния жизнен цикъл чрез HTTP API.
Transit Secrets Engine — криптиране и декриптиране на данни без тяхното съхранение. Възможност за предаване на данни в криптиран вид по незашифровани комуникационни канали.
Политики за достъп, които могат лесно да се настройват.
Аудит на достъпа до тайни.
Възможност за създаване на собствен CA (Certificate Authority) за управление на самоподписани сертификати в рамките на собствената инфраструктура.

Вземайки предвид всички наши изисквания, на ролята диригент бяха подходящи два варианта — Kubernetes и Nomad.

Kubernetes

Колко много статии и книги вече са написани за него (вижте тази, например), накарах описанията да звучат накратко — това е универсален комбайн, който може почти всичко. Цената за това е не винаги лесна настройка и поддръжка на кластера в Kubernetes.

Nomad

Инструмент от HashiCorp, компанията, известна с горепосочените consul и vault.

Nomad изглеждаше достатъчно прост за инсталиране и настройка в сравнение с Kubernetes. Един бинарен файл работи както в режим на сървър, така и в режим на клиент. При това Nomad покрива целия списък задачи, които искаме да реши: управление на кластера, бърз планиращ, поддръжка на multidatacenter. Освен това, при използване на consul и vault получаваме по-тясна интеграция за оркестрация на нашите услуги.

Какво е в работа в момента:

подготвихме сървърите за разгръщане на Consul,
в Consul ще бъде внесена конфигурацията на кластера nomad, с помощта на която nomad трябва да бъде разгрънат автоматично,
паралелно ще инсталираме vault за съхранение на тайни.

Въпрос в залата — струва ли си да създаваме диригент за такива задачи или оркестрацията и без него е добра? Споделете в коментарите какво мислите за това.

Следвайте нашия блог и оставайте на линия — скоро ще ви разкажем какво се случи в крайна сметка и дали настроихме кластера nomad така, както искахме.

Посетете нашия уютен телеграм-чат, където винаги можете да поискате съвет, да помогнете на колеги и просто да обсъждате теми, свързани с изследвания на производителността и не само.

Източник: habr.com