[Перевод] Как мы управляем контейнерной платформой: история adidas о прошлом, настоящем и будущем
10 мая 2022 года компания adidas начала переводить конфигурацию своей платформы на GitOps. Спустя почти два года в блоге компании опубликовали цикл статей об эволюции контейнерной платформы adidas, которые мы перевели и объединили в один материал. В этих статьях инженер компании Анхель Баррера Санчес рассказал, как платформа adidas переходила на GitOps, а также что было до перехода, как они работают сейчас и какие у них планы. Дальше идет текст автора.
Переход на GitOps — один из самых значительных стратегических шагов, сделанных в рамках контейнерной платформы adidas (на момент написания статьи). Хотя нам есть куда расти, этот шаг стал важным в нашем технологическом прогрессе.
Введение
Целевая аудитория
Статья не требует глубоких технических знаний. Неважно, разбираетесь вы в технических аспектах или лучше ориентируетесь в бизнесе, в этой статье вы найдёте полезную информацию.
Мы в курсе
Мы знаем, что GitOps стал важной тенденцией в последние годы. Но если учитывать масштабы нашей работы и ограничения, с которыми мы сталкиваемся, мы решили поделиться своими соображениями после использования этой системы в продакшене на протяжении года.
Контекст и масштаб
Мы создаём и совершенствуем контейнерную платформу более 5 лет (с конца 2018 года). adidas — это не стартап и даже не технологическая компания, но мы используем технологии для повышения эффективности работы команд. От реальных магазинов до сайта на .com-домене и даже команд разработчиков продуктов — все так или иначе используют контейнерные технологии. Наша контейнерная платформа должна правильно работать, так как это важно для сохранения позиций adidas как лидера в индустрии моды.
Понятно, что контейнерная платформа adidas должна быть глобальной. Наша инфраструктура охватывает Китай, Сингапур, Европу, Северную и Южную Америки. Мы управляем тысячами (эфемерных) облачных серверов, на которых круглосуточно работают контейнеры. Мы обеспечиваем работу сотен команд и тысяч разработчиков по всему миру.
Что было раньше
Что было до GitOps
Учитывая десятки кластеров, разбросанных по всему миру, и необходимость поддерживать всю конфигурацию как код, команда разработала фреймворк для гранулярной настройки каждого кластера. Для этого были созданы хранилища конфигураций для каждого кластера, а вместе с ними и репозиторий с конфигурациями, общими для всех кластеров.
Идеального мира не существует: у каждой географической зоны свои особенности, поэтому нам приходилось настраивать конфигурацию для каждого кластера и переопределять некоторые значения. Для этого использовались ветки (branches) в репозиториях конфигураций:
Также у нас были собственные наработки по интеграции различных систем adidas в контейнерную платформу, которые хранились в разных репозиториях с кодом.
Система непрерывной доставки отвечала за распространение этих изменений по кластерам с учетом окон обслуживания критически важных систем (опять же, каждая географическая зона налагает свои ограничения).
В общем, у нас были:
репозиторий для каждого кластера;
несколько веток в кластерных репозиториях;
отдельный пайплайн для применения конфигурации для каждой ветки;
репозиторий с общими конфигурациями;
ветки в этом репозитории для переопределения различных конфигураций в зависимости от окружения и/или географической зоны;
репозитории кода для интеграции с внутренними системами adidas;
центральный репозиторий для хранения развёртываемых пакетов этих внутренних разработок.
При обновлении компонента нам приходилось править от 4 до N репозиториев (где N могло достигать ~50) и открывать различные запросы на изменения (merge requests) с их циклами рассмотрения и утверждения (по принципу четырёх глаз).
Всё это требовало запуска кучи (~50) пайплайнов проверки и развёртывания. В результате на применение новых конфигураций на всех кластерах уходили часы (да ещё и приходилось попадать в установленные окна обслуживания). Бывали случаи, когда мы не могли вовремя развернуть изменения в критически важных окружениях из-за слишком медленной работы системы. В результате в разных окружениях/кластерах использовались разные конфигурации.
Назрела необходимость меняться. Мы хорошо подумали и составили следующий список целей:
Сократить время, затрачиваемое на эксплуатацию.
Повысить эффективность управления кластерами.
Повысить устойчивость процессов.
Улучшить прозрачность состояния конфигурации на глобальном и локальном уровнях.
Что есть сейчас
GitOps!
Мы столкнулись с серьёзной проблемой: как последовательно применять конфигурации по всей платформе? Из-за неё возникали сложности с синхронизацией и неожиданное поведение в различных регионах/кластерах. В первую очередь это было связано с:
сложным процессом установки каждого компонента;
трудностями с масштабируемостью системы непрерывного развёртывания, которые усугублялись ограничениями на время, когда можно было проводить обслуживание (окнами обслуживания).
Поэтому мы решили перейти от режима push (когда система «скармливает» конфигурацию другой системе) к режиму pull (когда система сама извлекает конфигурацию из репозитория с конфигурациями).
Структура конфигурации
Одним из самых сложных аспектов разработки и внедрения был, как уже упоминалось ранее, глобальный операционный масштаб контейнерной платформы adidas. Учитывая, что у нас работает большое количество внутренних клиентов в разных средах исполнения, подход к конфигурации должен быть многоуровневым:
Первый уровень включает в себя настройки, общие для всех кластеров платформы — глобальную конфигурацию.
Следующий уровень относится к среде выполнения, обычно встречающейся в разработке, QA или production.
Затем идёт уровень конфигурации, привязанный к географическим зонам. Те, кто управляет платформами в Китае, понимают, что здесь есть свои особенности, например необходимость перезаписи конфигураций из-за более низкой скорости получения образов из хранилищ контейнеров в США или Европе, а также обеспечение получения данных из локальных источников.
Последний слой (мы стремимся его устранить) — конфигурации, специфические для кластеров. Некоторые кластеры требуют особого внимания, например кластер для закрытых распродаж или VIP-мероприятий с высокими требованиями к стабильности.
Такая структура обеспечивает гибкость, которая позволяет проводить тонкую настройку на всех четырёх слоях. Она напрямую решает одну из задач, которые мы обозначили ранее, — сократить время, затрачиваемое на эксплуатацию. Изменения могут применяться глобально (затрагивая все кластеры), для каждой среды и географического региона или индивидуально для каждого кластера (при этом конфигурации для конкретного кластера будут иметь приоритет над географическими, настройками окружения и глобальными настройками).
Нам удалось сократить время, которое тратится на эксплуатацию, благодаря объединению конфигураций в одном месте (всего в нескольких репозиториях). Теперь их не приходится разбрасывать по большому количеству хранилищ. Консолидация значительно сократила количество ручных операций, с помощью которых ранее проверялась правильность применения конфигураций (больная тема для нас).
Более того, переход от push-модели к pull-модели повысил эффективность. Раньше система непрерывного развёртывания сама пушила конфигурации, сейчас все кластеры платформы самостоятельно извлекают конфигурации и делают это одновременно. Тем самым минимизируется время, которое тратится на применение конфигураций или новых функций по всей платформе.
Повысить эффективность управления кластерами.
Следуя классическому подходу «кластеры — это скот» (отношение к кластерам, как к вещам, которые можно легко заменить — Прим. ред.), мы получили возможность масштабировать контейнерную платформу вверх или вниз и не беспокоиться о количестве кластеров. Конечно, совершенству в этой области нет предела, но наше нынешнее положение значительно превосходит то, что было пару лет назад.
Учитывая большое количество внутренних систем adidas и разнообразных интеграций, при создании нового кластера всё равно приходится решать некоторые задачи вручную. Например, добавлять кластеры во внутреннюю сеть adidas. Сотрудничество с различными командами помогает упорядочить и обезопасить эти действия, а также сделать процессы более эффективными и автоматизированными.
Повысить устойчивость процессов.
В дополнение к более эффективному управлению кластерами платформы мы включили в процесс тщательно подобранный набор алертов. Идея была в том, чтобы отобрать только те алерты, которые действительно важны и могут потенциально повлиять на стабильность платформы.
Кроме того, теперь мы можем прогнозировать изменения ещё до того, как они произойдут. Это стало возможным благодаря системе непрерывной интеграции, которая проводит пробные запуски на платформе. В результате мы получаем представление о том, каким изменениям подвергнутся различные кластеры, если предложенные модификации будут приняты командой:
Также была реализована предварительная проверка, которая предотвращает применение неверно структурированных конфигураций из хранилища конфигураций. Раньше из-за того, что конфигурация была разбросана по разным репозиториям с различными структурами, это было невыполнимо.
Наконец, был реализован механизм, с помощью которого каждый кластер самостоятельно определяет время применения новых конфигураций (окна обслуживания). Хотя бóльшая часть платформы работает без каких-либо временных ограничений, во время критических событий — например распродаж — эти механизмы предотвращают любые потрясения, способные повлиять на бизнес adidas (помните, adidas — это не только технологии?).
Улучшить прозрачность состояния конфигурации на глобальном и локальном уровнях.
Помимо более эффективного и безопасного управления кластерами платформы, мы значительно улучшили весь процесс: повысили прозрачность и отслеживаемость состояния конфигурации каждого кластера и всей платформы в целом.
Агрегируя метрики всех кластеров платформы, мы получаем полную информацию о её состоянии:
Это позволяет узнавать подробности в случае, если какой-то конкретный кластер работает не так, как ожидалось.
А дашборды дают бесценные сведения:
Кроме того, мы получаем оповещения по нескольким каналам в зависимости от их уровня критичности:
Также мы развернули ещё один дашборд, который облегчает выполнение некоторых ручных операций, чем избавляет нас от необходимости что-то делать в командной строке:
Наконец, мы внедрили автоматическую генерацию changelog’а в самом репозитории с конфигурациями. Это очень важно для понимания того, как платформа менялась и развивалась:
Дополнительные соображения
Как и полагается в такой компании, как adidas, на контейнерной платформе работают компоненты, за которые мы отвечаем и которые используются сразу несколькими командами. Например, весь стек мониторинга, отслеживаемость, безопасность, API… Они работают в рамках платформы, но принадлежат другим командам, которые специализируются на соответствующих областях.
Структура конфигурации позволяет этим периферийным командам запрашивать изменения и использовать все упомянутые механизмы. Результат: укрепление связей с этими командами, поскольку их процессы были усовершенствованы без каких-либо затрат с их стороны. Фактически теперь они могут выбирать подходящие для себя окна обслуживания.
Планы на будущее
Теперь поговорим о планах по улучшению нашей платформы на ближайшие месяцы и годы. Самогенерирующиеся changelog’и, разработка рабочего CLI, оптимизация кластерных конфигураций — подумаем, как сделать управление платформой более гибким и эффективным.
Автоматическая генерация changelog’ов для каждого кластера
Классический CHANGELOG.md показывает, когда в хранилище конфигурации было внесено изменение. Но, принимая во внимание наши автоматические окна обслуживания, было бы полезно точно знать, когда новая конфигурация была автоматически применена к кластеру. Для этого можно обрабатывать события синхронизации и пушить новый сгенерированный файл в хранилище.
CLI для эксплуатации
Поскольку у нас много кластеров по всему миру, очень важно управлять ими всеми из одного места. Раздельное управление приводит к проблемам с обновлениями, мониторингом и единообразным применением правил. Централизованный подход сильно упрощает работу: изменения и правила единообразно применяются ко всей глобальной инфраструктуре.
Избегайте конфигураций, привязанных к кластерам
В настоящее время мы копируем/вставляем шаблоны из каталога, а затем меняем значения полей на нужные для конкретного кластера. Однако этого можно избежать с помощью функции Flux, известной как «замена переменных после сборки» (см.: https://fluxcd.io/flux/components/kustomize/kustomizations/#post-build-variable-substitution).
Этот подход очень похож на наш текущий процесс, но базируется на функции Flux. Есть в нём некоторые риски, например зависимость от этой конкретной функции, то есть если мы решим перейти на другую реализацию GitOps, сделать это будет непросто.
Однако есть и преимущества:
Значительную часть конфигурации можно перенести в configmap, который у нас уже есть. Далее можно подставлять значения непосредственно из configmap.
Это поможет стандартизировать конфигурации кластеров. Сейчас при правках шаблона кластера приходится тиражировать изменения на весь список кластеров. Новый подход упростит процесс и обеспечит согласованность всех конфигураций.
Расширение самообслуживания
Уже сейчас наши пользователи могут автоматически создавать свои тенанты на платформе, следуя определенному процессу утверждения, основанному на внутренней политике adidas. Тем не менее многое ещё можно улучшить. Например, удаление тенантов и их вывод из эксплуатации пока не автоматизированы.
Также мы фокусируемся на заказе выделенных тенантов (кластеров), а не общих. Этот переход позволит расширить возможности нашей платформы и более эффективно удовлетворять конкретные потребности пользователей.
Эфемерные кластеры
Мы работаем над тем, чтобы пользователи могли создавать эфемерные кластеры — как подключённые к нашей внутренней сети, так и отключённые от нее. Для этого необходимо обеспечить автоматическое развёртывание инфраструктуры внутри кластера. После создания нового кластера тот подключится к нашей сети, настроит необходимые ресурсы AWS и запросит внутренние правила для фаервола.
Онбординг новых команд
Команды знакомятся с конфигурационной платформой, которая является основой для всего, что мы делаем в контейнерной системе. Цель — помочь этим командам использовать платформу более эффективно. Команды не просто добавляются. Создаётся единая среда, в которой различные специализированные группы, такие как группы мониторинга, API и безопасности, могут слаженно работать. Такая совместная работа помогает совершенствовать систему.
Наша задача — создать пространство, где каждая команда привносит свой опыт на благо общего дела. Сотрудничество способствует обмену идеями, взаимному обучению и раскрытию потенциала платформы.
Платформа приложений
Этот проект занимает важное место в нашем списке задач. Мы стремимся создать новую схему, которая будет контролировать рост и изменение платформы и некоторых приложений с течением времени. Платформа постоянно развивается, и приложениям порой сложно угнаться за этими изменениями. Идея в том, чтобы платформа сама занималась обновлениями, обеспечивая бесперебойную работу даже в условиях роста.
Спасибо
Спасибо, что присоединились к путешествию по эволюции нашей контейнерной платформы. Мы рассмотрели множество вопросов, начиная с улучшения принципов работы и заканчивая повышением удобства работы команд.
Мы показали, как командная работа и инновации двигают нас вперёд. Но это не конец, а лишь промежуточный пункт на пути к ещё более совершенной платформе. Так что давайте и дальше расширять границы, мыслить масштабно и поддерживать друг друга. Впереди ещё много интересного, и мы рады двигаться вместе.
P. S.
Читайте также в нашем блоге:
Habrahabr.ru прочитано 10235 раз
