Централизованный сontinuous deployment за год
В одном из предыдущих постов про DevOps мы обещали рассказать про технологическую составляющую нашего CI/CD-конвейера.
Чтобы описать всю картину в красках и полноценно поделиться своими эмоциями (живописать боль и кровавые слезы), расскажу о том, с чего мы начинали пару лет назад и к чему пришли сегодня.
О себе
Я работаю в Raiffeisen более пяти лет. Сначала был внештатным специалистом, а сейчас руковожу подразделением, которое поддерживает CI/CD-конвейер и развивает автоматизацию. За этот немаленький промежуток времени мне и команде удалось поработать, наверное, с 90% всего используемого в банке ПО, получить много полезного опыта, частью которого я и хотел бы поделиться.
Что было в части используемых технологий и подхода два года назад и к чему мы пришли
Как и в любой крупной компании, не имевшей утверждённого набора Middle и Software, мы со временем пришли к огромному стеку используемых технологий.
Команды разработки использовали совершенно разные языки программирования, фреймворки и инструменты. Команды поддержки тоже пользовались тем, чем умеют, с разной долей успешности. То есть у Dev были свои инструменты, у Ops — свои. Автоматизация если и была, то на уровне «cmd вызывает батник, тот запускает VBS-скрипт, который создает объект в COM+, который…» НЕТ, ВСЁ, НЕ ХОЧУ ЭТО ВСПОМИНАТЬ!
Итак, про технологии. Начнем с CD, если это можно так назвать.
Несколько инсталляций subversion, в простонародье — SVN, парочка подпольных инсталляций GIT, всё это крутится либо на замечательной Win 2003, либо на новеньком <иронично> RHEL 5. И конечно же не связано между собой, от слова НИКАК. Многие предпочитали вообще не использовать системы контроля версий. База знаний и документации велась либо там же в SVN (да-да) в виде инструкций msdoc, либо на каких-то внутрикомандных wiki.
Нужно отметить, что были 3–4 команды, которые активно выстраивали свой автоматизированный процесс. Что не могло не радовать. Но их опыт трудно было масштабировать из-за количества и различий в используемых технологий. Jenkins, TeamCity, Bamboo, Artifactory, Nexus, в общем, каждый делал что хотел и как умел.
«Мы построим свой конвейер, с блэкджеком и куртизанками»
Поддерживались все эти инструменты самими разработчиками, которые тратили на это часть своего времени вместо того, чтобы пилить новые фичи.
В качестве системы управления тикетами использовалась Remedy, и это моя личная, жуткая, лютая боль. Мне кажется, те, кто работал, поймут, а если вам посчастливилось не иметь дела с Remedy, могу только позавидовать.
Система управления тестированием была не менее прекрасна — HP ALM. Как к системе отслеживания багов претензий у меня к ней нет, вся беда в интеграции. Но возможно, что это просто моя личная «любовь» к программным продуктам HP.
Первым важным изменением в нашем зоопарке, с моей точки зрения, стало появление Jira. После Remedy это был глоток свежего воздуха: легкая, быстрая, удобная! Сначала Jira решили попробовать несколько команд разработчиков, и в итоге она стала общебанковской системой. На первых порах в неё перенесли все работы по непромышленным средам, а сейчас мы внедряем JIRA SD в качестве системы управления инцидентами и изменениями. Важно и то, что в JIRA начали совместно работать над задачами как Dev, так и Ops. Не заставила себя долго ждать и Confluence.
Затем мы взялись за централизацию всех систем хранения исходного кода. Подняли централизованный стенд SVN, в который перенесли репозитории всех команд. Также в качестве альтернативы SVN подняли Bitbucket, и многие команды сразу перешли туда. В результате весь самописный код стал храниться в двух продуктах, и каждая команда решала самостоятельно, чем ей пользоваться.
К этому моменту уже созрела идея создания полноценного конвейера для автоматизации CI/CD. Самые жаркие споры шли вокруг выбора инструмента для автоматизации сборки и установки ПО, а также инструмента для хранения бинарных объектов. Мы очень долго присматривались к имевшемуся на рынке, сравнивали, читали, изучали, что-то пробовали и проверяли, в том числе разработанный в нашем головном офисе в Вене самописный инструмент.
В итоге по нескольким причинам остановились на Bamboo:
- Из коробки иного плюшек в интеграциях с продуктами Atlassian.
- Отсутствующие возможности на 90% покрываются доступными плагинами.
- Есть подготовленный, развиваемый SDK для написания своих плагинов.
- Поддержка от крупного вендора.
Немного расскажу про архитектуру Bamboo. В ней используются сервер приложений с ПО, сервер с базой данных, и так называемые Bamboo-агенты. То есть это набор серверов (количество зависит от купленной лицензии), на которых устанавливается ПО, нужное для ваших сборок и установок. При создании плана сборки нужно указать в требованиях необходимые компоненты. При запуске сборки ищется свободный агент, удовлетворяющий вашим требованиям, на котором и собирается приложение. Развёртывается оно по тому же принципу. При этом и сборка, и развёртывание выполняются одинаково во всех средах, промышленных и не промышленных!
В качестве инструмента для хранения бинарных объектов выбрали Artifactory. На сравнение и выбор между Nexus и Artifactory у нас ушло около месяца. Разные источники в интернетах говорили о превосходстве то одного, то другого инструмента. Нам подходили оба, но в конечном итоге победила лицензионная политика Jfrog. И мы до сих пор ни разу не пожалели о своем выборе, инструмент удобный, активно развивающийся.
За пару месяцев мы подняли и интегрировали непромышленные и промышленные среды конвейера. В качестве ОС для всех продуктов без особых размышлений выбрали RHEL 7, а в качестве СУБД — PostgreSQL.
Начался увлекательный процесс перехода команд на централизованный CI/CD-конвейер. Чем больше их переходило, тем больше ПО нужно было установить на агенты Bamboo. Поясню: на установку и отладку около 45 компонентов на 10 агентах ушло примерно 5 месяцев.
Вся эта история подтолкнула нас к пересмотру большинства внутрикомандных и части общебанковских процессов. Но одна лишь оптимизация не помогла достичь нужной скорости работы. И однажды мы поняли, что поддерживать и устанавливать необходимое командам ПО в ручном режиме стало невозможно. Обсудили с разработчиками, приостановили установку нового и обновление текущего ПО, и пошли учиться автоматизации.
Команда поддержки автоматизации не умеет автоматизировать! WTF?!
Учитывая, что со временем Bamboo-агентов станет гораздо больше 25, для создания и обновления агентов решили использовать связку Bamboo и Ansible. Чем Ansible для нас оказался интереснее других инструментов управления конфигурациями:
- легкостью в освоении,
- отсутствием серверной части,
- ну и всеми остальными преимуществами подобного ПО.
На подготовку первой бета-версии сценариев для RHEL-агентов ушло около двух месяцев. С Windows, как всегда, было много проблем, здесь уже потратили 3–4 месяца. При этом до сих пор ведём войну с nuget и chocolatey. Но зато на создание и конфигурацию агента теперь уходит вместо двух недель всего два часа. К слову, сегодня у нас ~50 агентов, а количество устанавливаемых компонентов приближается к 120. Казалось бы, вот оно счастье, два часа — и новый агент готов! Но нет. Создание нового сервера — не менее прекрасная история, учитывая количество команд, вовлеченных в этот процесс. Со всеми согласованиями и управлением изменениями, мы тратили на создание нового RHEL-сервера около недели. А потом еще пару дней на передачу рута.
With great power comes great responsibility.
Надо было что-то менять.
Начали думать. Между делом добавили в конвейер SonarQube — инструмент для статического анализа кода и управления техническим долгом. Классное ПО!
Но вернёмся к нашим баранам: в эпоху IaaS было очень больно осознавать, что неделю создаём виртуалку. А почему не использовать AWS/GoogleCloud/Azure или любое другое облако? Ответ прост — законодательство РФ запрещает, да и наша служба безопасности была не в восторге (мягко говоря) от идеи использования внешнего облака.
Тогда сделаем своё!
В банке к тому времени уже экспериментировали с vRealize, мы ухватились за такую возможность и присоединились к эксперименту. В итоге получили пул ресурсов, которым могли управлять и создавать из шаблонов серверы с нужной ОС.
На создание десятка серверов вместо недели стал уходить час, и радости нашей не было предела.
Но на этом мы решили не останавливаться. Если автоматизировать, то нужно научиться создавать серверы в vRealize из Bamboo. Неделя исследований и еще неделька на реализацию собственного плагина — и первый сервер создан прямо из deploy-проекта Bamboo. К тому моменту народ решил, что нам совершенно не нужен SVN, а вместе с ним и Fisheye+Crucible: у Bitbucket гораздо больше возможностей, он современнее и удобнее. Мы помогли командам переехать на Bitbucket и выключили «отслуживший своё» SVN.
Что бы еще автоматизировать?
Dev/Ops/DevOps/BizDevOps — что мешает всем этим людям при наличии автоматизированной сборки и установки? Работа с запросами системы управления изменениями! Но как же нам быть без управления изменениями, это же важная штука! <лукаво> Если рассмотреть ситуацию внимательнее, то становится понятно, что мешает не сам процесс, а необходимость планировать, согласовывать и фиксировать результат изменения ВРУЧНУЮ!
И на помощь снова приходит возможность написания собственных плагинов для Bamboo! Неделя исследований, две недели на реализацию, и мы создаем из того же deploy-проекта первый предсогласованный CRQ в промышленной среде.
Чем занимаемся сейчас?
Мы запустили пилотное использование нескольких инструментов для ChatOps. Тащим за HipChat, потому что несмотря на все его недостатки, лучшего onpremise-решения я пока не нашел. Опять же, за счет использования большого стека продуктов Atlassian мы получим кучу плюшек. Например, интеграция всех инструментов позволяет в Jira-задаче отслеживать все коммиты, сборки и развёртывания, выполненные при реализации этой фичи. Включение в процесс HipChat позволит, например, устанавливать определенный релиз в конкретное окружение, прогонять автотесты, возвращать результат в чатик и отправлять пользователям уведомления о том, что можно приступать к UAT, введя одну команду в окно чата…
Наш конвейер сейчас выглядит так:
Взаимная интеграция всех этих приложений позволяет нам автоматизировать практически все рутинные действия, связанные с производством ПО. У нас остаётся больше времени для улучшения качества наших продуктов или для каких-то исследований.
Обещаем еще вернуться и поделиться новым интересным опытом.
