Централизованное Непрерывное Развертывание В Год

В одном из предыдущих постов о DevOps мы обещали рассказать о технологической составляющей нашего CI/CD-конвейера.

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

Централизованное непрерывное развертывание в год

Обо мне

Я работаю в Райффайзен более пяти лет. Сначала я был внештатным специалистом, а сейчас руковожу отделом, который поддерживает конвейер CI/CD и занимается разработкой автоматизации.

За этот значительный период времени мы с моей командой успели поработать, наверное, с 90% всего программного обеспечения, используемого в банке, и накопить много полезного опыта, частью которого мне хотелось бы поделиться.

Какая технология и подход использовались два года назад и к чему мы пришли?

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

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

Группы поддержки также использовали то, что знали, с разной степенью успеха.

То есть у Dev были свои инструменты, у Ops — свои.

Автоматизация, если она и была, была на уровне «cmd вызывает батник, он запускает VBS-скрипт, создающий объект в COM+, который.

» НЕТ, ЭТО ВСЕ, Я НЕ ХОЧУ ЭТО ПОМНИТЬ! Итак, о технологии.

Начнем с компакт-диска, если его можно так назвать.

Несколько subversion-установок, в просторечии - SVN, пара подпольных GIT-установок, все это работает либо на чудесной Win 2003, либо на новенькой RHEL 5. И конечно, это не связано друг с другом, буквально НИКАК.

Многие люди предпочли вообще не использовать системы контроля версий.

База знаний и документации велась либо в SVN (да-да) в виде инструкций msdoc, либо на какой-то внутренней командной вики.

Стоит отметить, что было 3-4 команды, которые активно строили свой автоматизированный процесс.

Что не могло не радовать.

Но их опыт было сложно масштабировать из-за количества и различий в используемых технологиях.

Jenkins, TeamCity, Bamboo, Artifactory, Nexus, в общем, каждый делал что хотел и как умел.

«Мы построим свой конвейер, с блэкджеком и куртизанками»

Все эти инструменты поддерживались самими разработчиками, которые тратили на это часть своего времени вместо того, чтобы вырезать новые возможности.

В качестве системы управления билетами использовался Remedy, и это моя личная, ужасная, горькая боль.

Мне кажется, те, кто работал, поймут, и если вам посчастливилось не иметь дело с Remedy, я могу вам только позавидовать.

Не менее превосходной была система управления тестированием — HP ALM. К системе отслеживания ошибок у меня претензий нет, вся проблема в интеграции.

Но возможно, что это всего лишь моя личная «любовь» к программным продуктам HP. Первым важным изменением в нашем зоопарке, с моей точки зрения, стало появление Jira. После Remedy это был глоток свежего воздуха: легко, быстро, удобно! Сначала несколько команд разработчиков решили попробовать Jira, и в итоге она стала общебанковской системой.

Сначала на него была перенесена вся работа над непромышленными средами, а сейчас мы внедряем JIRA SD как систему управления инцидентами и изменениями.

Также важно, что JIRA начала вместе работать над задачами Dev и Ops. Слияние тоже не заставило себя долго ждать.

Централизованное непрерывное развертывание в год

Затем мы приступили к централизации всех систем хранения исходного кода.

Мы поставили централизованный стенд SVN, в который перенесли репозитории всех команд. Bitbucket также поднимался как альтернатива SVN, и многие команды сразу же перешли на него.

В результате весь самодельный код стал храниться в двух продуктах, и каждая команда самостоятельно решала, что использовать.

К этому времени уже созрела идея создания полноценного конвейера для автоматизации CI/CD. Жаркие споры развернулись вокруг выбора инструмента для автоматизации сборки и установки программного обеспечения, а также инструмента для хранения бинарных объектов.

Мы очень долго присматривались к тому, что было доступно на рынке, что-то сравнивали, читали, изучали, пробовали и тестировали, в том числе и самописный инструмент, разработанный в нашем головном офисе в Вене.

В итоге мы остановились на Bamboo по нескольким причинам:

Из коробки других вкусностей в интеграции с продуктами Atlassian.
Недостающие функции на 90% покрываются доступными плагинами.
Имеется подготовленный и разработанный SDK для написания собственных плагинов.
Поддержка от крупного поставщика.

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

При создании плана сборки необходимо указать в требованиях необходимые компоненты.

При запуске сборки происходит поиск свободного агента, соответствующего вашим требованиям, и на нем строится приложение.

Он разворачивается по тому же принципу.

При этом и сборка, и развертывание выполняются одинаково во всех средах, промышленных и непромышленных! В качестве инструмента для хранения бинарных объектов была выбрана Artifactory. На сравнение и выбор между Nexus и Artifactory у нас ушло около месяца.

Различные источники в Интернете говорили о превосходстве того или иного инструмента.

Оба варианта нам подходили, но в итоге победила лицензионная политика Jfrog. И мы до сих пор ни разу не пожалели о своем выборе; инструмент удобен и активно развивается.

За пару месяцев мы подняли и интегрировали непромышленную и промышленную трубопроводную среду.

Недолго думая, в качестве ОС для всех продуктов мы выбрали RHEL 7, а в качестве СУБД — PostgreSQL. Начался захватывающий процесс перевода команд на централизованный конвейер CI/CD. Чем больше они пересылали, тем больше программного обеспечения нужно было установить на агентов Bamboo. Поясню: на установку и отладку около 45 компонентов на 10 агентах ушло около 5 месяцев.

Вся эта история подтолкнула нас к пересмотру большинства внутренних командных процессов и некоторых общебанковских процессов.

Но одна лишь оптимизация не помогла добиться необходимой скорости.

И однажды мы поняли, что стало невозможно поддерживать и устанавливать необходимое командам программное обеспечение вручную.

Мы пообщались с разработчиками, приостановили установку нового и обновление текущего ПО и пошли изучать автоматизацию.

Команда поддержки автоматизации не знает, как автоматизировать! Что за черт?!

Учитывая, что со временем агентов Bamboo станет гораздо больше, чем 25, мы решили использовать комбинацию Bamboo и Ansible для создания и обновления агентов.

Почему Ansible оказался для нас интереснее других инструментов управления конфигурациями:

простота обучения,
отсутствие серверной части,
ну и все остальные преимущества такого ПО.

На подготовку первой бета-версии скриптов для агентов RHEL ушло около двух месяцев.

Как всегда было много проблем с Windows; мы уже провели здесь 3-4 месяца.

В то же время мы все еще ведем войну с нугетом и шоколадом.

Но вместо двух недель создание и настройка агента теперь занимает всего два часа.

Кстати, сегодня у нас ~50 агентов, а количество установленных компонентов приближается к 120. Казалось бы, вот это счастье, два часа — и новый агент готов! Но нет. Создание нового сервера – не менее замечательная история, если учесть количество команд, участвующих в этом процессе.

Проведя все согласования и управление изменениями, мы потратили около недели на создание нового сервера RHEL. А потом еще пару дней на перенос рута.

С большой властью приходит большая ответственность.

Что-то нужно было изменить.

Мы начали думать.

Тем временем мы добавили в конвейер SonarQube — инструмент для статического анализа кода и управления техническим долгом.

Крутой софт! Но вернемся к нашим овцам: в эпоху IaaS было очень больно осознавать, что мы неделю создаем виртуальную машину.

Почему бы не использовать AWS/GoogleCloud/Azure или любое другое облако? Ответ прост — российское законодательство это запрещает, а наша служба безопасности (мягко говоря) не в восторге от идеи использования внешнего облака.

Тогда мы сделаем свое! К тому времени банк уже экспериментировал с vRealize, мы воспользовались этой возможностью и присоединились к эксперименту.

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

Создание десятка серверов вместо недели стало занимать час, и нашей радости не было предела.

Но мы решили не останавливаться на достигнутом.

Если вы занимаетесь автоматизацией, вам необходимо научиться создавать серверы в vRealize из Bamboo. Неделя исследований и еще неделя реализации собственного плагина — и первый сервер был создан непосредственно из проекта развертывания Bamboo. К тому времени люди решили, что SVN нам вообще не нужен, и вместе с ним Fisheye+Crucible: у Bitbucket было гораздо больше возможностей, он был более современным и удобным.

Мы помогли командам перейти на Bitbucket и отключили «устаревший» SVN. Что еще вы могли бы автоматизировать? Dev/Ops/DevOps/BizDevOps — что мешает всем этим людям автоматизировать сборку и установку? Работа с запросами системы управления изменениями! Но что же делать без управления изменениями, это важная вещь! Если посмотреть на ситуацию более внимательно, то станет понятно, что нам мешает не сам процесс, а необходимость планировать, согласовывать и фиксировать результат изменения ВРУЧНУЮ! И возможность писать собственные плагины для Bamboo снова приходит на помощь! Неделя исследований, две недели внедрения, и на основе того же проекта развертывания мы создаем первый заранее согласованный CRQ в промышленной среде.

Что мы делаем сейчас?

Мы опробовали несколько инструментов для ChatOps. Тащим с собой HipChat, потому что, несмотря на все его недостатки, лучшего onpremise решения я пока не нашел.

Опять же, используя большой стек продуктов Atlassian, мы получим кучу вкусностей.

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

Включение HipChat в процесс позволит, например, установить конкретный релиз в конкретной среде, запустить автотесты, вернуть результат в чат и отправить пользователям уведомления о том, что они могут запустить UAT, введя одну команду в окно чата.

Наш конвейер теперь выглядит так:

Централизованное непрерывное развертывание в год

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