company_banner

Централизованный с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, введя одну команду в окно чата…

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


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

    Обещаем еще вернуться и поделиться новым интересным опытом.
    Райффайзенбанк 211,14
    Развеиваем мифы об IT в банках
    Поделиться публикацией
    Похожие публикации
    Комментарии 12
    • 0
      «но в конечном итоге победила лицензионная политика Jfrog»
      Подскажите, пожалуйста, что за такая политика, что выбор был сделан в пользу artifactory, а не nexus?
      • +1
        Детали, к сожалению, не помню, суть была в том, что артифактори в минимальной редакции удовлетворял всем нашим требованиям, а нексус — нет, нужно было брать более расширенную редакцию.
      • +2
        Статья не понравилась. Много воды и рекламы Atlassian(a).

        К чему эти слезы про то, что было раньше и как было плохо когда-то.

        Расскажите о том, как хорошо сейчас на примере одного production-проекта, который у Вас/вас там сейчас самый красивый в смысле CI/CD. Только расскажите подробно. В предыдущей статье была речь про Tomcat и memcached для сессий. Т.е. java-приложение. Вот на его примере расскажите все с самого начала:

        1. Вот build server построил артефакт (.jar или .war) или артефакты — а что происходит далее?
        2. Как вы разворачиваете инфраструктуру для запуска приложения? Какие компоненты (сервера для приложений, кластера баз данных)? Каким тулом (и почему именно им) и в какой системе виртуализации (я так понял, что только vmware, но может что-то еще или bare metal)?
        3. Как делаете provisioning инфраструктуры. Не только серверов с приложениями, но и серверов с зашаренными сервисами типа DB или того же memcached.
        4. Как происходит деплой? Кто нажимает кнопку(кнопки) и в каком туле? (или все само сразу приезжает на production)
        5. Могут ли девелоперы деплоить сами в production?
        6. Какие схемы деплоемента используются? (green/blue, rolling, canary итд). А что если надо откатиться?
        7. Как и кем принимается решение об успешном деплое? На основании каких параметров?
        8. Что делать если нагрузка увеличивается? Легко ли добавить больше серверов, чтобы удержать нагрузку? Если ли autoscaling?
        9. Каждый новый деплой происходит на вновь созданные сервера? Или на те же самые?
        10. Что с патчами на операционную систему?
        11. Есть ли где-то docker? Если нет, то почему именно?
        12. Какие-то системы оркестрации используются? Nomad(может не только контейнеры), k8s (только контейнеры)?
        13. А что с мониторингом и метриками? Приложений и системными (OS)?
        14. Что используется для алертов? Есть ли on-call инженер(ы) и какие вопросы они решают конкретно применительно к этому приложению?
        15. [важный вопрос] Что с секретами? (пароли, private keys сертификатов, API keys итд). Как и где храните? Как доступаетесь до секретов при деплое приложения?
        16. Что используете для Load balancing между копиями приложений? nginx/haproxy/etc?

        Вот примерный список того, чтобы лично мне было бы интересно услышать.

        Кстати, живой пример банка, который шарит кучу всего про используемые ими технологии (youtube, github etc) — Capital One. Я у тому, что порой и у банков есть нормальный взгляд на IT ;)
        • 0

          Отличный список вопросов — прямо как план на статью.

          • +2

            Добрый день, спасибо за детальный список вопросов. Мы изначально планировали серию постов, поэтому в первой достаточно много «воды». Следующую как раз сделаем с деталями по конкретному продукту.

            • 0
              Согласен!
            • –1

              Децентрализация и банки не совместимые вещи, нет конечно можно внедрить, но зачем? Банки это мертвая и неправильная во всех смыслах система. Даже наверное не стоило писать статью про это дело. Желаю всем банка скорейшего краха, вы зарабатываете деньги делая из людей рабов.

              • 0

                Ваше представление о банках выглядит как набор штампов из американских фильмов. Я понимаю что многим it специалистам кажется что любой крупный бизнес, а банки как раз львиная доля такого бизнеса, являются чем-то совсем не современным и там никогда не может быть современных технологий. Но это не всегда правда. Там просто все происходит медленнее чем в молодых стартапа. К тому же банковское дело существует с незапамятных времён, надо учитывать весь тот багаж технологий, которые работают десятилетиями.

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

                Оставляя в стороне вопрос законодательства, можно поискать как HSBC работает с GCP… то есть вопросы internal IT security каким-то образом решаются. Не к тому, что это нужно, а к тому, что это возможно и решаемо.
                • 0
                  Я не эксперт в нашем законодательстве, но что касается того же AWS так сейчас там encryption уже много где и at-rest, и at-transit.
                • –1

                  Отличный список вопросов. СБ банка будет в восторге если автор ответит на все )

                  • 0
                    > К тому моменту народ решил, что нам совершенно не нужен SVN, а вместе с ним и
                    > Fisheye+Crucible: у Bitbucket гораздо больше возможностей, он современнее и удобнее

                    Code review у вас нет? Bitbucket может современнее и удобнее, но в нем совершенно неудобно проводит ревью изменений больших, чем на пару строк

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

                    Самое читаемое