Едва ли будет неверным сказать, что лучшие из людей
обретают радость через страдание.
Людвиг ван Бетховен
Я Сергей, работаю в Яндекс.Деньгах в команде по исследованию производительности. Хочу поведать вам начало истории о нашем пути к использованию оркестровки — как мы выбирали инструменты и что при этом учитывали. Всё события из статьи происходят в реальном времени, поэтому вы, дорогие читатели, следите за развитием ситуации практически в прямом эфире.
Зачем нам дирижёр в команде?
Кто же такой дирижёр? От фр. 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
Сколько уже написано про него статей и книг (вот , к примеру), рассказано докладов, что напишу коротко — это универсальный комбайн, который может практически всё. Плата за это — не всегда легкие настройка и поддержка кластера на Kubernetes.
Nomad
от HashiCorp, компании, известной по упомянутым выше consul и vault.
Nomad показался нам достаточно простым в установке и настройке, чем Kubernetes. Один бинарный файл работает как в режиме сервера, так и клиента. При этом Nomad покрывает весь список задач, которые мы хотим, чтобы он решал: управление кластером, быстрый планировщик, поддержка multidatacenter. Плюс при использовании consul и vault мы получаем более тесную интеграцию для оркестровки наших сервисов.
Что сейчас в работе:
- подготовили серверы для развертывания Consul,
- в Consul будет занесена конфигурация кластера nomad, с помощью которой nomad должен быть развернут автоматически,
- параллельно будем устанавливать vault для хранения секретов.
Вопрос в зал — стоит ли заводить дирижёра для таких задач или оркестру и без него хорошо? Расскажите в комментариях, что вы думаете по этому поводу.
Подписывайтесь на наш блог и оставайтесь на связи — скоро расскажем, что в итоге получилось, и настроили ли мы кластер nomad, так как нам этого хотелось.
Заходите в наш уютный , где вы всегда можете попросить совета, помочь коллегам и просто пообщаться на тему исследований производительности и не только.
Источник: habr.com