Попрощайтесь с Kubernetes и поприветствуйте Nomad!

Попрощайтесь с Kubernetes и поприветствуйте Nomad!

16 ноября 2022 г.

Можно утверждать, что принятие двух наших основных ценностей в Lob — двигаться быстро и amp; Примите меры и будьте смелыми — сделали нас крупным игроком в области автоматизации прямой почтовой рассылки. Но возможный недостаток такой смелости заключается в том, что она может привести к разнородным технологиям и процессам (или, другими словами, к беспорядку).

Чтобы избежать такого беспорядка, когда команды разработчиков растут в размерах, необходимо стандартизировать разработку и операции. Одно из направлений деятельности Lob связано с оркестровкой контейнеров и стандартизацией того, как мы запускаем сервисы в Lob, путем перехода с Convox, Heroku и on-off инфраструктуры на Кочевник. Установив приоритет одних технологий над другими, мы можем улучшить опыт разработчиков и не перегружать себя и тех, кого мы поддерживаем. По сути, Nomad поможет нам не изобретать велосипед с каждым новым приложением в Lob. .

Но переосмыслить сложно. Наша команда разработчиков платформы в Lob столкнулась с конструктивными вопросами, например: «Зачем нам нужен один контейнерный оркестратор? Почему я не могу просто понять, как разместить свое приложение самостоятельно?» и "Почему именно Nomad, а не эта замечательная технология?"

Поскольку «потому что я так сказал» действует на группу разработчиков так же хорошо, как и на малыша (то есть не на всех), нам нужно было дать лучший ответ. TL;DR: скалы кочевников; оно не только лучше нашего текущего решения, но и превосходит другие варианты.

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

3 столпа силы

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

* Развертывание контейнеров. Nomad развертывает ваши контейнеры на основе манифеста задания (спецификации)

* Масштабирование развертываний: в зависимости от нагрузки и/или показателей Nomad масштабирует ваше приложение по горизонтали, чтобы справляться с изменениями нагрузки.

* Последовательные выпуски. Nomad занимается выпуском последовательных выпусков, включая проверки работоспособности, синее/зеленое развертывание и канареечное развертывание.

Nomad выполняет задачу развертывания Dockerized-приложений, и делает это вместе с другими функциями, которые делают его полезным. В простейшей версии любого оркестратора контейнеров вы даете ему образ, и он запускает этот контейнер для вас. К сожалению, это действительно ограничивает, потому что если у вас есть только один контейнер, если он по какой-то причине умирает, то ваше приложение не работает. Оркестратор контейнеров должен делать больше; он должен масштабировать ваши контейнеры по горизонтали, что легче сказать, чем сделать; если мы слишком агрессивно масштабируемся, мы тратим деньги на контейнеры, которые используются недостаточно, но если мы недостаточно масштабируем, это влияет на производительность и наших клиентов.

Nomad решает для нас эту проблему «масштабирования» гибким, но мощным способом. Мы предоставляем Nomad минимальное и максимальное количество контейнеров, которые мы хотим запустить. Затем мы предоставляем политику автомасштабирования, которая включает в себя запрос, некоторый внешний источник данных и стратегию действий на основе этих данных. Используя это, мы можем масштабировать нашу службу вверх и вниз на основе простых показателей, таких как ЦП и память, но мы также можем масштабировать на основе таких показателей, как количество сообщений в очереди, количество входящих запросов или фаза луны.

Еще один важный элемент, который нам нравится, — это последовательные выпуски. В нашем текущем инструменте выпуск будет распространяться; ваше приложение будет развернуто, и на самом деле не так много нюансов в том, как это изменение будет развернуто. С Nomad вы можете диктовать, как вы хотите развернуть свой релиз. Вы можете сказать: «Я хочу автоматически продвигать свой выпуск, если он проходит проверку работоспособности» или «У меня есть несколько канареек, которые работают, и в зависимости от того, как эти канареек работают, мы будем продвигать или откатывать». При ручном повышении вы можете указать: «Разверните канареек, но затем позвольте мне нажать кнопку, чтобы завершить продвижение». Столько контроля!

Под капотом

Чтобы полностью оценить Nomad, полезно понять несколько основных принципов. Есть намного больше, но это те, о которых, как мы думаем, вам нужно знать.

* Манифесты заданий – это простые текстовые файлы, описывающие, как развертывать службу и управлять ею, включая контейнеры, доступ к сети, автомасштабирование, стратегию обновления и дополнительные компоненты! Вы можете думать об этом как о спецификации того, как запускать ваше приложение. (Версия Nomad для всех файлов манифеста Kubernetes *.yaml)

* Nomad Группы — это наборы связанных контейнеров, которые должны планироваться вместе (аналогично K8 Pod). Группы контейнеров одновременно масштабируются вверх и вниз на одних и тех же виртуальных машинах. Пример: ваш основной контейнер API + вспомогательная панель мониторинга + задача запуска.

* Задачи – это контейнеры Docker. Nomad Tasks может указать образ Docker, команду запуска, файлы динамической конфигурации и распределение ЦП и памяти.

* Службы предоставляют Задаче доступ к входящему сетевому трафику. Сервисы регистрируются в Consul, а сетевой трафик маршрутизируется через Traefik. Служба может масштабироваться в зависимости от использования ЦП и памяти, а также любого запроса Datadog.

* Ограничения (и Affinity) позволяют планировать приложения на определенных вычислительных клиентах в кластере Nomad. Подумайте: архитектура процессора, есть графический процессор, регион AWS, версия Docker и т. д. Это довольно мощная функция, которую мы еще не используем в Lob, но когда придет время выжать максимум из нашего оборудования, мы ею воспользуемся.

Так почему бы не что-то еще?

Давайте обратимся к слону в комнате: Kubernetes, также известному как K8s. Мы не будем вдаваться в причины, по которым это может вам не подойти (Маттиас Эндл привел отличный пример здесь), но для нас Nomad — лучший выбор. Эта статья от HashiCorp дает представление о том, почему, но суммирует вверх, мы поместили значок лобстера (для Lob) на рисунок ниже.

Короче говоря, Nomad предлагает богатый набор функций, который дает нам все преимущества K8s, как с точки зрения эксплуатации, так и с точки зрения разработчика, без каких-либо сложностей

Наш текущий инструмент хорошо служил нам в течение многих лет, но технические требования Лоба переросли его набор функций. Например, он поддерживает только балансировщики нагрузки приложений уровня 7, что ограничивает нашу способность самостоятельно обрабатывать сети более низкого уровня. Это также ограничивает наши возможности по развертыванию обновлений, включая синее/зеленое развертывание, канареечное развертывание и автоматическое продвижение на основе сложных проверок службы.

Лямбда-выражения — это еще один вариант, который предлагает действительно полезные функции масштабирования, но в большинстве случаев контейнерный сервис предлагает лучшее соотношение цены и производительности. Многие приложения Lambda можно помещать в контейнеры, но не все приложения из контейнеров можно преобразовать в Lambdas, поэтому по умолчанию используется контейнеризация.

Наконец, нам не помешало наличие в штате инженеров, имеющих опыт работы с Nomad, что дало нам быстрый старт.

По этим причинам наша команда считает, что Nomad способен разместить 90 % рабочих нагрузок в Lob, заменив все наши существующие инструменты оркестровки и заменив многие виды использования голых инстансов EC2 и Lambdas. Или, говоря языком компьютерщиков, , Nomad достаточно мощен, чтобы быть этой единственной платформой… чтобы управлять ими всеми.

Друзья Кочевника

Кочевник не работает в одиночку; ниже приведен наш «стек задач» приложений, которые работают вместе, а также указано, как это сделать. Обратите внимание, что это все инструменты с открытым исходным кодом, которые мы используем; мы не создавали их, и это связано с нашим выбором и причудами, которые отличают нас от других компаний, использующих Nomad.

* Nomad: оркестратор контейнеров

* Консул: Каталог услуг, хранилище конфигурации "ключ-значение"

* Traefik: балансировка нагрузки контейнера, ПО промежуточного слоя [Auth]

* Действия Github: сборка релизов, развертывание артефактов релиза

(PS. Пока мы копаем Traefik, я думаю, мы все согласимся, что это ужасное имя. Если вам тоже придется урегулировать внутренний спор, произносится как «трафик». )

Переход на Nomad

Для перехода на Nomad нам пришлось внести несколько изменений. Оба являются хостинговыми услугами в AWS. Это означает, что разрешения и вспомогательные службы работают одинаково в обеих средах. Nomad использует контейнеры Docker, поэтому способ упаковки и развертывания приложения практически не изменился.

Системы сборки между двумя платформами сильно различаются. Наш существующий инструмент выполняет сборку и развертывание в каждой «стойке», обрабатывая весь выпуск. Nomad не заботится о вашем коде; он принимает только образы Docker. Nomad занимается только развертыванием, поэтому мы создаем и передаем Nomad артефакт релиза для развертывания. Раньше наш инструмент перестраивал ваш код каждый раз, когда вы его развертывали — черт с ним — теперь Lob создает один раз и развертывает везде!

Еще одно изменение — это синтаксис, который мы используем для выражения того, как запускать наш код. Наш существующий инструмент использует YAML, например Docker Compose; это делает файлы конфигурации простыми, но это не так выразительно, как хотелось бы (например, мы не можем сказать ему развернуть canary). С другой стороны, Nomad использует HCL и передает переменные конфигурации во время развертывания.

Раньше наши переменные среды сохранялись в базе данных нашим инструментом, тогда как у Nomad на самом деле не было базы данных для этого. Вместо этого у нас есть файлы переменных (JSON), которые передаются в конфигурацию Nomad. Nomad также может использовать Consul для хранения данных динамической конфигурации, но Lob не нужно использовать эту интеграцию.

Последнее отличие, о котором стоит упомянуть, — это аппаратная конструкция. Наш существующий инструмент имеет одну стойку для каждого варианта оборудования, что создает нежелательную изоляцию и неизбежное «Где Уолдо?» пытаться найти и найти, где работает ваше приложение. По сравнению с Nomad, который может запускать сочетание вычислительных узлов, таких как различное оборудование, разные операционные системы, спотовые экземпляры — все в одном кластере с приложениями, которые выбирают, где и как их приложение запускается в этом кластере! (Примечание: Nomad запускает Docker на виртуальных машинах; наш существующий инструмент использует ECS.)

Подведение итогов

Единый оркестратор контейнеров — и, в частности, мощное средство Nomad — предлагает нашей команде стандартизированную платформу и процесс для более быстрой и простой установки приложений. Nomad также предлагает нам гибкий, надежный набор функций и беспрецедентную масштабируемость в наших приложениях и операциях. Представив подробности о новом решении и связав его конкретно с нашим текущим состоянием, мы смогли заручиться поддержкой наших инженерных групп. Мы ожидаем, что к концу второго квартала большинство сервисов (более 50) будет перенесено на Nomad, а все приложения будут готовы к четвертому кварталу. 🤞

Чтобы узнать больше о Nomad, посетите Learn Nomad Orchestration: DevOps и Docker Live Show. Брет Фишер берет интервью у Эрика Велда, менеджера по защите прав разработчиков в HashiCorp, который рассказывает об основах Nomad, демонстрациях и о том, что происходит в проекте Nomad.

Содержание адаптировано из презентации старшего инженера платформы Элайджи Фойгта.


Оригинал
PREVIOUS ARTICLE
NEXT ARTICLE