02 03 2016

Каждые несколько лет в ИТ появляется новая технология, которая приносит революцию. Десять лет назад это была виртуализация, которая проложила дорогу облачным сервисам и вычислениям. Сейчас это контейнеры и энергичная экосистема, которую они формируют. В этом статье мы расскажем, как управляют инфраструктурой Интернета вещей на базе Mesos и Docker в Samsung.

Причины этой контейнерной революции - рост DevOps в целом и успех Docker, в частности. Это прекрасное дополнение к популярной микросервисной архитектуре, что позволяет проектировать приложения как сервисы, независящие от платформы развертывания.

SAMI – это сложная платформа, которая включает много частей. На момент написания этой статьи платформа включает более 40 внутренних сервисов (и их число постоянно растет), а также ряд популярных технологий бэк-энд: хранилища данных NoSQL, брокеры сообщений, реестры сервисов, хранилища конфигураций , графовые базы данных, HDFS, обработчики Big Data, кеширование в памяти и традиционные базы данных SQL. Платформа постоянно развивается по мере того, как разработчики добавляют в неё новые технологии и приложения для решения задач обработки Big Data для Интернета вещей. В нашей службе DevOps мы отвечаем за проектирование и поддержку инфраструктуры, необходимой для этой нагрузки. Инфраструктура должна обеспечивать масштабируемость, безопасность, соответствие нормам, и при этом оставаться Agile!

Примерно месяц назад мы перевели нашу платформу SAMI на Mesos и Docker. Mesos можно считать ядром всего ЦОДа , позволяющего абстрагироваться от используемых аппаратных и виртуальных серверов, и программировать так, что весь ЦОД выступает как один гигантский вычислительный ресурс. Docker – это технология контейнеризации. Она упрощает процесс упаковки и отгрузки приложений во внешний мир.

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

Ещё до того, как контейнеры стали модной темой, у нас была хорошая система автоматизации на базе нашей системы управления конфигурацией (CM). Выделение ресурсов, соответствие стандартам, развертывание приложений – все было автоматизировано на базе Chef и Saltstack.

Однако, по мере роста нашей платформы стали проявляться некоторые недостатки и у этих инструментов. Для поддержки и масштабирования всё более усложняющейся системы, к которой постоянно добавляются новые функции, нам потребовался новый подход.

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

1. Подход с точки зрения вычислительных узлов/серверов.
2. Декларативность: выполнять "это" на "этой" виртуальной машине.
3. Статическое выделение разделов.
4. Мультиарендность требует ручной настройки.
5. Нерациональное использование ресурсов.
6. Отсутствие изоляции ресурсов.
7. Долгое время выделения ресурсов и развертывания.
8. Нет управления зависимостью/последовательностью: Нельзя указать “развернуть сервис B после сервиса A, но только после завершения проверки состояния сервиса A”.
9. Нет самовосстановления: если вычислительный узел отказывает, оператор должен заменить его вручную.
10. Сложности работы с гетерогенной инфраструктурой: почти никакие модули/cookbooks/playbooks не могут работать больше чем на двух дистрибутивах.
11. Сложны для изучения.

Для нашей современной платформы под Интернет вещей эти ограничения были неприемлемы. Переход на Mesos и Docker был предрешен.

Мы решили построить систему автоматизации, которая позволила бы нам:

• Построить устойчивую к отказам, самовосстанавливающуюся инфраструктуру.
• Использовать современную систему управления кластером/распределенной инициализации, которая обеспечивает постоянное выполнение реплик приложений.
• Использовать Git в качестве единственного "источника правды": все конфигурации заданийбудут храниться в Git. Это позволяет быстро и просто получить систему управления изменениями/аудита.
• Паковать приложения как образы Docker для более быстрого развертывания.
• Построить быструю и отзывчивую систему оркестрации.
• Вписать существующую инфраструктуру в систему.
• И, наконец, получить платформу непрерывной поставки, которая работает достаточно быстро и надежно, чтобы инженерные службы (включая контроль качества) могли развертывать production-версии! Нашей миссией в этом проекте было освободить себя от сложностей и проблем задач эксплуатации и сосредоточиться на разработке новых сервисов, принося пользу нашей компании.

С учетом всего сказанного архитектура выглядела так:

• Высокодоступный кластер Mesos обеспечит абстракцию на уровне ЦОДа, подобно тому, как операционная система обеспечивает абстракцию от аппаратного обеспечения компьютера. Теперь ЦОД - это новый форм-фактор вычислительного узла.
• Mesos будет выступать как менеджер ресурсов на уровне ЦОДа.
• Система сборки будет упаковывать приложения как образы Docker. Эти образы будут помещаться во внутренний Docker-реестр.
• Marathon будет выступать в качестве менеджера систем/процессов на уровне ЦОДа. Все долго выполняющиеся задачи развертываются и управляются через него.
• Chronos будет выступать в качестве системы cron на уровне ЦОД. Все краткосрочные задачи будут планироваться и управляться через него.
• Все конфигурации задач Marathon и Chronos будут размещаться в Git. Таким образом, любые изменения инфраструктуры можно будет отследить.
• Git2Consul будет использоваться для синхронизации репозиториев Git и хранилища Consul KV, обработчики Consul при появлении изменений в KV будут отправлять обновления в Marathon/Chronos через REST API.
• Consul по прежнему будет выступать в роли реестра сервисов. Registrator будет отслеживать события Docker и регистрировать изменения в Consul. В будущем это будет заменено на Mesos-DNS.

Теперь наш процесс можно описать так:

1. Разработчик выполняет commit, Post-Receive Hook в Git инициирует процесс сборки в Jenkins.
2. Jenkins использует модуль maven-docker для создания, маркировки и отправки имиджей Docker во внутренний реестр Docker. Также обновляется метка имиджа в Consul KV.
3. Consul Handler следит за изменениями этого KV и обновляет репозиторий Git с конфигурациями задач Marathon.
4. Gi2Consul подхватывает эти изменения и синхронизирует репозиторий с другим KV в Consul.
5. Другой обработчик, который следит за этим KV, отправляет конфигурации задач в Marathon. Если сервис еще не зарегистрирован, он создается. В противном случае он обновляется.
6. Marathon выступает как менеджер кластера и распределенная система инициализации.
7. Небольшой сервис под названием Registrator слушает события Docker и обновляет каталог сервисов в Consul.
8. Любые изменения в реестре сервисов подхватываются Consul-Template, который обновляет все конфигурации (в частности, HAProxy) и перезагружает зависимые сервисы.

Как можно видеть, приложения автоматически собираются, упаковываются и развертываются в разных окружениях без вмешательства человека. При этом обеспечивается полный аудит - каждый шаг фиксируется в Git. Это чрезвычайно важно, особенно когда у вас большая команда разработчиков и сложная система со множеством частей. Если к этом добавить требование, чтобы любой сотрудник инженерных служб имел возможность выпускать несколько релизов разных сервисов в течение одного дня, станет понятно, почему тщательный аудит процесса разработки критически важен!

Теперь группы разработчиков мгновенно получают сообщения об успехе или неуспехе своих задач (через почту, чаты и т.п.) На выходе - значительное ускорение получения обратной связи, причем процессы и службы эксплуатации в этом не участвуют вообще!

С Mesos мы можем использовать нашу инфраструктуру более эффективно и точнее оценивать затраты на облако. Мы можем обеспечить более высокое использование ресурсов, и, благодаря изоляции ресурсов, мы можем упаковать несколько сервисов (работающих в контейнерах Docker) на один хост. Это формирует действительно мультиарендное развертывание, где приложения могут сосуществовать с backend системами, например, Cassandra или Kafka.

Опыт перехода

Все перечисленное заняло у нас примерно три месяца от идеи до реализации в продакшене. Да, это было БЫСТРО! У нас на пути было много препятствий, как административных, так и технических.

Новые пользователи должны понимать многие концепции и нюансы решений на базе Mesos/Docker. Требуются определенные усилия, чтобы отойти от традиционного взгляда на приложения, серверы и ЦОДы. Нужны развитые навыки внутренних продаж, чтобы различные группы в компании приняли эту новую концепцию.

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

Выводы

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

С описанным выше подходом мы можем выдавать новый код раньше, легко масштабироваться, реализовывать мультиарендность, благодаря реальной изоляции ресурсов, а также обеспечивать оптимальное их использование. Мы можем достичь коэффициент использования ресурсов почти 80% во время значительной нагрузки на некоторых из наших пред-production системах. Это замечательный результат с учетом того, что стандартное использование ресурсов ЦОДа по отрасли - около 8 процентов!

Пример использования ресурсов на одном из наших кластеров Mesos в пред-production системе под значительной нагрузкой:

curl http://10.20.0.201:5050/metrics/snapshot
{
 ..
"master\/cpus_total":247,"master\/cpus_used":192,
"master\/mem_total":583573,"master\/mem_used":415378,
 ..
}

В целом, команда SAMI с энтузиазмом приняла этот сдвиг парадигмы. Однако, чтобы оказаться там, где мы теперь, нам пришлось провести значительные исследования, обучиться и много работать. Те из вас, кто хочет воспользоваться нашим опытом, помните, что новая система потребует изменений, которые отличаются от того, как вы делали это раньше. Однако, нам очень нравятся достигнутые на сегодняшний день результаты и уверены, что это изменения в правильном направлении!

(via)