Создание конвейера CI / CD
Введение
Мы решили разобраться в управлении изменениями и построить конвейер CI / CD. Ниже приведены некоторые вещи, которые мы узнали во время нашего увлекательного путешествия.
Что такое управление изменениями?
Никто не должен быть слишком занят, чтобы правильно управлять изменениями.
Чтобы определить управление изменениями, мы должны определить изменение. В нашем случае изменение относится к введению или обновлению кода, конфигурации или системных служб. Таким образом, управление изменениями - это методология или процедуры, используемые для обработки этих обновлений или новых элементов, вводимых в системы.
Зачем нам нужно управление изменениями?
Нам нужно управление изменениями, потому что оно описывает шаги, необходимые для обеспечения оптимизированного, прозрачного и эффективного способа внедрения и отслеживания изменений в системах.
Некоторые из преимуществ управления изменениями включают:
- Снижение риска, связанного с несчастными случаями, при внесении изменений
- Отслеживание прогрессивного состояния различных проектов
- Проверка предположений и повышение видимости проекта
- Отслеживание изменений, тем самым повышая безопасность проекта
- Повышенная уверенность в изменениях, поскольку есть более строгие требования к тестированию
Наши цели и задачи для этого проекта
В целом цель этого проекта управления изменениями заключалась в том, чтобы определить лучший способ управления изменениями и лучшие инструменты для этого. Конечная цель - разработать работающее доказательство концепции, способное развертывать изменения кода в промежуточных средах.
Элементы, участвующие в управлении изменениями
В ходе наших исследований мы определили следующие элементы, участвующие в управлении изменениями:
- Определение инициаторов изменений - пользователей или внутренних инструментов
- Авторизация пользователей на развертывание изменений
- Сообщение об изменении
- Обмен информацией между командами
- Отслеживание изменений с течением времени
Непрерывная интеграция и доставка (или развертывание)
Мы считаем, что конвейер CI / CD является ключом к управлению изменениями. Мы считаем, что это дает нам много преимуществ от упомянутого ранее управления изменениями. Само собой разумеется, что эффективный конвейер CI / CD должен иметь большую наблюдаемость и быть в значительной степени автоматизированным.
Непрерывная доставка в основном основана на автоматическом тестировании, поскольку оно дает вам быструю обратную связь, позволяя быстро выявлять проблемы и надежно отправлять.
В нашем случае мы решили объединить несколько мощных инструментов для создания конвейера CI / CD (непрерывная доставка в случае этой промежуточной среды).
Инструменты
Инструменты, которые мы решили использовать для построения нашего конвейера, были:
- Bitbucket - управление исходным кодом
- Конвейеры Bitbucket в качестве CI
- Интерактивный инструмент для компакт-дисков (тимбукту - внутренний инструмент)
- Marionette Collective (MCollective) - инструмент оркестровки
- Кукольный
Почему мы выбрали конвейеры Bitbucket
Мы уже используем Bitbucket для управления исходным кодом, поэтому интеграция с конвейерами Bitbucket была довольно простой. Это также доступная альтернатива для проведения этих тестов онлайн (10 долларов в месяц за 1000 минут).
Почему мы выбрали марионетку (и MCollective)
Мы выбрали Puppet в основном потому, что он имеет расширенные функции отчетности и надежный DSL, который можно расширить с помощью Ruby. Puppet дополнительно позволяет лучше контролировать порядок выполнения задач по сравнению с таким инструментом, как Ansible.
Помимо этого, Puppet также интегрируется с такими полезными инструментами, как r10k и MCollective. Вместе эти два инструмента добавляют в Puppet важные функции в качестве инструмента для управления изменениями.
С помощью r10k кодом Puppet можно управлять в центральном репозитории кода, а конкретная версия этого кода «развернута» с помощью r10k на Мастере Марионеток. Это упрощает совместную работу нескольких команд или отдельных лиц над одним и тем же кодом Puppet.
MCollective позволяет каталогам Puppet быть отправленными на узлы по желанию, вместо того, чтобы полагаться на узлы, извлекающие каталоги из мастера Puppet по адресу интервалы. Это особенно полезно в случае, когда вы хотите использовать Puppet только для отправки уникального развертывания на узлы в определенное время.
Подробнее о MCollective orchestration.
Наш конвейер CI / CD
Наш конвейер CI / CD начинается, когда код помещается в Bitbucket. Затем для этого кода запускаются тесты с помощью инструмента конвейеров Bitbucket. Если тесты пройдены / успешны, timbuktu (инструмент доставки) запрашивает информацию о следующем курсе действий.
Если в качестве следующего действия выбрана доставка, MCollective используется для запуска Puppet, который затем запускает сборку на сервере (ах), выделенном для сборки кода проекта. Следующим шагом в случае успешной сборки является развертывание нового кода (с помощью Puppet) на выбранных серверах или группах серверов. Доставка автоматизирована, но запускается инструкциями непосредственно от разработчика / команды.
Мы кратко рассмотрим различные этапы этого конвейера и интересные проблемы, с которыми мы сталкивались на каждом этапе.
Управление исходным кодом и тесты Bitbucket
Один из первых вопросов, который приходит на ум при рассмотрении вышеупомянутого конвейерного потока, - что произойдет, если произойдет случайная фиксация в главной ветви репозитория. Новый коммит может пройти тесты, но может привести к ошибкам в связанных / зависимых системах, если не будет хорошо скоординирован.
Решение простое: вместо того, чтобы разрешать коммиты напрямую в основную ветку, было бы лучше использовать рабочий процесс запроса на вытягивание, в котором разработчики создают push в ветку функции, например, nest-fix-major-account-bug . Любые новые коммиты затем должны быть просмотрены, одобрены и прошли тесты конвейеров Bitbucket, прежде чем они будут объединены с основной веткой.
Представленная выше модель ветвления не идеальна; без частых и ранних коммитов управлять репозиторием может быть очень сложно. Идея состоит в том, чтобы как можно чаще продвигать и проверять множество мелких изменений. Если ветвь находится слишком далеко вперед / назад, вероятнее всего возникнут конфликты слияния, особенно в более крупных командах.
Доставка / развертывание кода с помощью Timbuktu
Timbuktu - это инструмент для внутренней доставки / развертывания, написанный на Python. Он сочетает в себе параметры, задаваемые пользователем, с набором предопределенных правил, чтобы определить, какие действия и где применять.
Timbuktu получает уведомления build от различных проектов (на Bitbucket, которые были настроены для отправки таких уведомлений). На этом этапе разрешены только интегрированные изменения CI.
После получения уведомления он запрашивает следующий план действий у групп, уполномоченных развертывать новый код. Эти «агенты изменений» должны указать узлы, на которых они хотят развернуть «изменение».
После авторизации изменения и выбора «затронутых» узлов Timbuktu обращается к MCollective, чтобы инициировать запуск агента Puppet. Это фактически запускает новое развертывание на этих узлах.
Обмен информацией с Тимбукту
Информирование об изменениях - очень важная часть управления изменениями. После завершения запуска Puppet агенты Puppet отправляют отчет обратно мастеру Puppet, который, в свою очередь, отправляет отчет по HTTP в Timbuktu.
Затем Тимбукту представляет «агенту изменений» отчет о последовательности действий, примененных во время запуска агента Puppet, и текущем состоянии различных ресурсов. Если, например, файл конфигурации был изменен, отображается разница.
Timbuktu позволяет нам сообщать об изменениях при автоматизации доставки / развертывания.
Основным способом взаимодействия Timbuktu на данный момент является Slack, но его можно распространить на cli, USSD или SMS или что-то еще, что имеет смысл для соответствующих команд. Предпочтение было отдано Slack, потому что в нем есть очень мощные боты, которые предоставляют интерактивные команды.
Хотя Timbuktu стремится быть универсальным инструментом, его эффективность зависит от наличия поддерживающих систем мониторинга и тестового покрытия. Без них мы не сможем обнаружить и быстро решить проблемы, которые могут возникнуть, даже если они маловероятны.
Проблемы, с которыми мы столкнулись (и в основном преодолели)
Некоторые из проблем, возникших в ходе работы над этим проектом управления изменениями, подчеркнули необходимость изменения культуры, в то время как другие потребовали изменения технической реализации.
Мы уже обсуждали некоторые из них более подробно в разделах выше, но они кратко освещены здесь:
- Защита от случайной передачи кода в ветку master
- Написание кода с возможностью многократного использования для управления автоматизацией фактического развертывания изменений.
- Гарантия того, что изменение всегда выполняется правильно
- Обеспечение безопасности процесса внедрения изменений
- Безопасное распространение измененных артефактов (кода или конфигурации)
- Безопасное развертывание последовательных изменений или изменений в нескольких экземплярах
- Определение того, какие области развертывания изменений можно безопасно автоматизировать
- Возможность быстрого и легкого отката
Уроки выучены
Мы хотели бы поделиться всеми уроками, которые мы извлекли на этом пути, но у нас есть место только для основных моментов.
Защита от случайных толчков
Одним из первых и наиболее важных уроков, которые мы усвоили, было то, что нам пришлось отказаться от передачи кода непосредственно в основную ветку. Это, по крайней мере, защищает от случайных нажатий, а также гарантирует, что только тщательно протестированный код будет объединен с основной веткой.
Написание многоразового кода с помощью Puppet
Puppet, из-за его надежного DSL, оказался значительной частью конвейера развертывания. Поэтому мы быстро поняли, что важно написать многоразовый код Puppet, если мы когда-либо сможем масштабировать это доказательство концепции.
Это привело нас к изучению модели ролей и профилей, доступной в Puppet. Мы обнаружили, что эта модель позволяет нам писать код с возможностью многократного использования. Это также имело дополнительное преимущество в виде уменьшения количества переменных, которые нам приходилось хранить в Hiera.
Мы отметили, что переработка файлов конфигурации может в значительной степени использовать эту возможность многократного использования для лучшего управления конфигурацией и уменьшения количества ошибок из-за неправильной конфигурации.
Тестирование и контроль качества
Timbuktu в сочетании с Puppet позволил нам автоматизировать и быстро протестировать развертывание нового кода в промежуточной среде.
Команда, протестировавшая наш POC, смогла обнаруживать и устранять проблемы намного быстрее. Они, безусловно, могут подтвердить скорость и простоту этих развертываний. Это, естественно, способствовало повышению уверенности в их проектах, а также их общей работоспособности в производственной среде после более тщательного тестирования в тестовой среде.
Мы считаем, что есть еще кое-что, что можно сделать для использования этого конвейера в целях обеспечения качества.
Обеспечение правильного развертывания изменений
Автоматизация, реализованная в этом конвейере, естественно, позволила нам быстро и многократно протестировать правильность внедрения изменений.
Хотя Puppet гарантирует идемпотентность, мы узнали, что упорядочивание ресурсов в Puppet было абсолютно необходимо для обеспечения постоянного достижения указанного конечного состояния.
Мы также были рады узнать, что при правильном упорядочивании ресурсов можно избежать серьезных сбоев. Если изменение зависело от предыдущего изменения, которое не удалось, то это последующее изменение не будет применено. Таким образом, система останется в том состоянии, в котором она была до запуска развертывания.
Обеспечение внедрения изменений
Timbuktu был создан с учетом требований безопасности и поэтому позволяет вносить определенные изменения только лицам, уполномоченным на это. Помимо этого, интеграция со Slack служит полезным способом сообщать о внесении изменений, а также о том, что это за изменения и кто их инициировал.
В момент развертывания фактического кода мы обнаружили, что использование этого конвейера сразу же уменьшило количество людей, которым требуется root-доступ на серверах. Вместо этого все изменения были инициированы из Timbuktu, поэтому их легче регистрировать и отслеживать.
Это лишь некоторые из первых мер, которые мы приняли, но мы продолжим работу по обеспечению безопасности трубопровода от начала до конца.
Будущее
Мы считаем, что предстоит проделать значительный объем работы, чтобы изменить общую культуру управления изменениями в небольших организациях.
«Изобретения / улучшения рабочих процессов разработчика должны быть областью знаний и семейной работой в области разработки программного обеспечения» @rakyll
Нам также предстоит проделать большую работу, чтобы расширить это доказательство концепции. Есть ряд технических проблем, которые мы еще не смогли полностью решить.
Что наиболее важно, нам необходимо дополнительно защитить этот конвейер и убедиться, что он может управлять развертыванием изменений за пределами кода.
И последнее, но не менее важное: мы считаем, что контейнерные технологии могут сыграть важную роль в облегчении внедрения изменений. Потребуется дополнительная работа, чтобы увидеть, как это можно сделать наилучшим образом.
Мы будем рады услышать ваше мнение об этом сообщении.
Ссылки
