Исполнительский Оркестр

Вряд ли будет ошибкой сказать, что лучший из людей найти радость через страдания.

Людвиг ван Бетховен

Исполнительский оркестр

Я Сергей, работаю в Яндекс.

Деньгах в команде исследования эффективности.

Хочу рассказать начало истории о нашем пути к использованию оркестровки — как мы выбирали инструменты и что учитывали.

Все события из статьи происходят в реальном времени, поэтому вы, дорогие читатели, следите за развитием ситуации практически в прямом эфире.



Зачем нам в команде нужен дирижер?

Кто такой дирижер? От фр.

диригер - управлять, направлять, руководить - в мире музыки - это человек, который является руководителем обучения и исполнения ансамблевой музыки.

В нашем случае это место занимают системы оркестровки и автоматизации.

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

Как правило, у команды есть определенный набор мощностей — назовем их серверами, — на которых они реализуют свои проекты.

Подходы к получению и эксплуатации этих серверов различны.

Несколько примеров:

  • Команда делает запрос, например, в оперативную группу, чтобы предоставить им ресурсы с определенными параметрами.

  • Операционная группа обеспечивает их необходимым количеством — облаком или голым железом — и обязуется поддерживать их в надлежащем состоянии согласно SLA. Настройку также осуществляет оперативная группа.

  • Команда получает от операционной группы только облачные или «голые» ресурсы и настраивает их самостоятельно.

  • Команда сама «покупает» ресурсы и обслуживает/настраивает их совершенно самостоятельно.

Наша команда использует серверы, которые необходимо поддерживать – обновление ОС, установка новых пакетов и т.д. Для себя мы разделили их на два основных типа:
  • танковая группа,
  • группа обслуживания.

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

Танком.

В группу сервисов входит все, что связано с сопровождением — это различные сервисы по обеспечению поддержки цикла выпуска, формированию автоматических отчетов и т. д. В один момент всем этим стало неудобно управлять вручную, и мы задумались об автоматизации всего процесса, начиная от «загрузки» серверов и заканчивая разработкой, выпуском и запуском нашего внутреннего сервиса.



Зачем нужен дирижер, если даже оркестр сам умеет играть?

Для начала мы освоили Ansible и начали «заливать» наши голые сервера, чтобы меньше зависеть от сисадминов — здесь выигрывают все, мы получаем новые навыки и освобождаем администраторов от части работы, которой им и без нас всегда хватает. .

Мы стремимся максимально развиваться за пределы своей специализации и командной автономии.

В компании работа с Ansible настроена и регламентирована достаточно давно, поэтому мы легко интегрировали наше решение в этот процесс.

В настоящее время пул хостов состоит из трех ролей Ansible:

  • первая роль устанавливает ОС,
  • второй запускает базовые настройки хоста, авторизацию LDAP, например,
  • а третий устанавливает Яндекс.

    Танк и связанные с ним зависимости в докер-контейнер.

Перейдем к сервисам, которыми мы пользуемся внутри команды.

Для наших задач мы в равной степени используем 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, и вот почему:

  • Теперь докер не может использовать только с ipv6.
  • Наличие глобально маршрутизируемого адреса в каждом контейнере означает, что все порты (даже неопубликованные) доступны всем, если не будет выполнена дополнительная фильтрация.

  • пользовательский прокси для публикации портов, iptables только для ipv4 .

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-контейнерах? Несмотря на то, что каждый участник оркестра знает свою партию, он может запутаться и отклониться от первоначального замысла.

Здесь мы приходим к выводу, что без дирижера наш оркестр не сможет эффективно репетировать и слаженно играть.

Дирижер отвечает за все параметры исполнения, следя за тем, чтобы все было объединено единым темпом и настроением.



Как приобрести хороший проводник с минимальными вложениями?

Тема оркестровки довольно хорошо развита на рынке.

Но сначала поговорим о вспомогательных инструментах, которые могут помочь проводнику.

Консул - система, выполняющая две основные функции:

  • обнаружение услуг,
  • распределенное хранилище ключей и значений.

В нашем оркестре за регистрацию сервисов и хранение их конфигураций будет отвечать Consul. Есть два варианта регистрации:
  • Активен, когда служба регистрируется с использованием HTTP API;
  • Пассивный — услугу необходимо зарегистрировать вручную.

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

Вот преимущества, которые мы получим, используя этот инструмент:

  • Единый центр создания и хранения секретов и управления их жизненным циклом с помощью HTTP API.
  • Transit Secrets Engine — шифрование и дешифрование данных без их сохранения.

    Возможность передачи данных в зашифрованном виде по незащищенным каналам связи.

  • Политики доступа, которые легко настроить.

  • Аудит доступа к секретам.

  • Возможность создать собственный ЦС (центр сертификации) для управления самозаверяющими сертификатами в вашей инфраструктуре.

Учитывая все наши требования, на роль проводника подошли два варианта — Kubernetes и Nomad.

Кубернетес

Сколько о нем уже написано статей и книг (здесь так , например) есть отчеты, напишу кратко - это универсальный комбайн, который умеет практически все.

Платой за это является то, что настройка и поддержка кластера в Kubernetes не всегда проста.



Кочевник

Инструмент от HashiCorp, компании, известной упомянутым выше консулом и хранилищем.

Мы обнаружили, что Nomad гораздо проще установить и настроить, чем Kubernetes. Один двоичный файл работает как в серверном, так и в клиентском режиме.

При этом Nomad покрывает весь список задач, которые мы хотим с его помощью решить: управление кластером, быстрый планировщик, поддержку нескольких датацентров.

Кроме того, при использовании консула и хранилища мы получаем более тесную интеграцию для организации наших сервисов.

Что сейчас в процессе:

  • подготовленные серверы для развертывания Consul,
  • в Консул будет введена конфигурация кластера nomad, с помощью которой nomad должен быть развернут автоматически,
  • Параллельно мы установим хранилище для хранения секретов.

Вопрос к залу: стоит ли нанимать дирижера для таких задач или оркестр прекрасно справляется и без него? Расскажите нам в комментариях, что вы думаете по этому поводу.




Подписывайтесь на наш блог и оставайтесь на связи — скоро мы расскажем, что получилось в итоге и настроили ли мы кочевой кластер так, как хотели.

Приходите в наш уютный телеграмма чат , где всегда можно попросить совета, помочь коллегам и просто пообщаться об исследованиях производительности и многом другом.

Теги: #Kubernetes #Высокая производительность #DevOps #Тестирование веб-сервисов #Тестирование ИТ-систем #производительность #нагрузочное тестирование #nomad #исследование производительности #оркестрация

Вместе с данным постом часто просматривают: