История управления конфигурациями

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

Предыдущее состояние

Примерно по состоянию на август 2015 года мы в Indix использовали различные инструменты и языки для создания, предоставления и развертывания инфраструктуры.

Создание инфраструктуры: Инструменты командной строки AWS, туман, нож-ec2
Предоставление: повар, повар-соло
Развертывание и оркестровка: Capistrano, ткань, сценарии оболочки, команды Go-CD, beanstalk и т. д.
У этого подхода были некоторые недостатки:

  1. Сбои происходили из-за отсутствия жесткой связи между созданием, инициализацией и развертыванием инфраструктуры. Сбой на одном этапе приводит к каскадным сбоям позже.

  2. Инструменты для запуска вещей в производство довольно сложны. Понимание нескольких инструментов и знакомство с новым языком (ruby/python) для большинства разработчиков не является оптимальным. Это приводит к меньшему участию большей группы разработчиков в создании систем. Кроме того, это вызывает сильное выгорание команды DevOps.

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

Наш опыт и обучение

  1. Слишком много инструментов для изучения, которые имеют значительную кривую обучения. Также очень тесная связь подготовки между разными командами/проектами.

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

  3. Трудно настроить аппаратное обеспечение (типы машин Amazon и типы томов), которое требуется для любой настройки и укрепления любой серверной системы.

  4. Нет согласованности или простого способа настройки некоторых основных вещей, таких как мониторинг, ведение журнала, проверка работоспособности системы.

  5. Ни идемпотентный, ни неизменяемый. Это означает, что завтра мы не сможем просто повторно запускать создание, подготовку и развертывание всей нашей инфраструктуры одним способом несколько раз и быть уверенными, что все будет работать нормально.

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

Итак, перефразируя, мы хотели систему, которая должна быть:

  1. Мертвый простой. Это означает очень низкую кривую обучения и большее участие разработчиков. Косвенным следствием этого является помощь людям в том, чтобы двигаться быстрее и выполнять задачи, а не полностью зависеть от команды devops.
    Единый (или минимальный) инструмент для создания, подготовки и развертывания инфраструктуры
    Один из способов сделать что-то. Не 5 разных языков и фреймворков. Что-то вроде YAML.

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

  3. Возможность быстро создавать локальные настройки разработки, тестовые среды и писать интеграционные тесты.

Экосистема Ansible

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

Основные проблемы, которые он решает:

  1. Единое место для создания инфраструктуры, подготовки, развертывания и координации.

  2. Вы пишете только в YAML.

  3. Основным режимом работы является режим принудительной отправки, что означает, что система после развертывания неизменна. Это также дает гибкость для использования в режиме на основе извлечения, который полезен, скажем, для кластера Hadoop, где узлы могут появляться и исчезать. Однако в обоих случаях источник github является единственным источником правды.

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

Текущее состояние :

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

Похожие записи

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *