- PVSM.RU - https://www.pvsm.ru -
Привет! В этой статье расскажу, как мы в Positive Technologies создавали и развивали отдел автоматизации разработки, внедряли идеи DevOps в практику разработки и какие инструменты и технологии для этого использовали, а также как организовали процессы CI/CD. В том числе поделюсь успехами и планами на будущее.
Positive Technologies [1] ― мультипродуктовый вендор в области информационной безопасности. Продукты Positive Technologies поставляются по традиционным моделям (в виде устанавливаемого ПО), SaaS, виртуальных машин и «bare metal appliance». Наш отдел, неформально называемый у нас отделом DevOps, занимается автоматизацией и поддержкой процессов разработки всех наших продуктов: сетевого сканера ИБ XSpider [1], системы контроля защищенности и соответствия стандартам MaxPatrol 8 [2], решения для управления событиями, активами и инцидентами ИБ MaxPatrol SIEM [3], системы управления инцидентами кибербезопасности АСУ ТП ― PT ISIM, защитного экрана уровня приложений PT Application Firewall [4], анализатора кода PT Application Inspector [5], многопоточной системы выявления вредоносного контента PT MultiScanner [6] и всех остальных продуктов компании.
Мы считаем, что работа по принципам DevOps и обязанности соответствующих отделов автоматизации сильно зависят от специфики работы конкретной компании. Специфика работы нашей компании накладывает на нас обязанность по организации поставки конечным заказчикам коробочного продукта и поддержку нескольких версий каждого продукта одновременно.
На данный момент наш отдел отвечает за весь конвейер по серийному производству продуктов компании и сопутствующую инфраструктуру, начиная от сборки отдельных компонент продуктов и интеграционных сборок, до их отправки на тестирование на наших серверах и доставку обновлений на географически распределенную инфраструктуру серверов обновлений и затем ― на инфраструктуру заказчиков. Несмотря на большой объем задач, с ними справляется всего 16 человек (10 человек решает задачи Continuous Integration и 6 — задачи Continuous Delivery), при этом количество людей, участвующих в разработке продуктов, более 400.
Ключевым принципом для нас является «DevOps as a Service». DevOps в современном IT уже давно выделился в самостоятельную инженерную дисциплину — очень динамичную и технологичную. И мы должны оперативно приносить эти технологии нашим разработчикам и тестировщикам. Кроме того, мы делаем их работу более комфортной, эффективной и продуктивной. Также мы разрабатываем внутренние вспомогательные инструменты, регламентируем и автоматизируем процессы разработки, сохраняем и распространяем технологические знания внутри компании, проводим технические воркшопы и делаем еще много всего полезного.
О наших первых шагах в развитии идей DevOps у нас в компании можно почитать в статье «Миссия выполнима: как развить DevOps в компании со множеством проектов [7]».
Когда мы в Positive Technologies решили развивать идеи DevOps, то столкнулись с необходимостью их внедрения в ситуации, при которых десятки команд одновременно работали над проектами как публичными, так и непубличными. Они сильно отличались по размеру, использовали различные релизные модели и технологический стек. К нам пришло понимание того, что централизованные решения и высокий уровень организации автоматизации разработки — это лучше, чем «творческий хаос» обычной разработки. Кроме того, любая автоматизация призвана сокращать себестоимость процесса разработки и внедрения продуктов. В компаниях, где есть выделенная служба для реализации методик DevOps, обеспечивается серийность всех внедряемых инструментов, благодаря чему разработчики могут более эффективно работать, используя готовые шаблоны автоматизации.
Continuous Integration ― это лишь один из процессов, соединяющих разработчиков и конечных пользователей продуктов. Инфраструктура Continuous Integration в Positive Technologies развивалась вокруг связки из трех базовых сервисов:
Исторически сложилось так, что для хранения кода, организации сборок и хранения их артефактов мы выбрали GitLab, TeamCity, Artifactory. GitLab мы начали использовать очень давно из-за его удобства по сравнению с svn, который у нас был раньше. Преимущества GitLab были в том, что в нем стало проще применять изменения (merge). Что касается Artifactory, то ему нет серьезной альтернативы для хранения бинарей (компонент и инсталляторов). Впрочем, можно использовать файловые шары или MS SharePoint, но это, скорее, для тех, кто не ищет легких путей, а не для автоматизаторов. На TeamCity мы перешли после долгого периода эксплуатации и сборок на MS TFS. Переезд долго тестировался, обкатывался на небольших продуктах, и лишь затем его провели полностью. Основная причина — необходимость в простых типовых решениях и масштабируемости сборочной и тестовой инфраструктуры для многокомпонентных продуктов, написанных на различных языках программирования. TFS этого нам дать не мог.
Отдельное внимание мы уделили разработке типовых проектов для системы непрерывной интеграции. Это позволило нам добиться унификации проектов, выделив так называемую релизную схему сборок с продвижениями в TeamCity. Все проекты при этом выглядят одинаково: они включают в себя конфигурации для сборок, артефакты которых попадают в Artifactory, оттуда их можно взять для развертывания, тестирования и продвижения в релизный репозиторий проекта (см. схему на рисунке 1). Подробнее об используемой терминологии и организации типового CI-процесса мы написали в статье «DevOps best practices: рекомендации по организации конфигураций в TeamCity [8]».
Рисунок 1. Базовые элементы типового проекта для релизной схемы сборок с продвижениями (по клику откроется в полном размере)
Мы развивали нашу систему Continuous Integration более двух лет, и к настоящему моменту, помимо стандартных конфигураций для сборки, деплоя, тестирования и продвижения сборок, мы дополнили ее разработанной нами системой Continuous Delivery, названной SupplyLab, для публикации протестированных релизных сборок на Global Update-серверы, откуда они забираются и распространяются через Front Update-серверы дальше, вплоть до инфраструктуры заказчиков, на которой разворачиваются и обновляются.
Как было отмечено выше, все решения, предоставляемые нашей DevOps-командой, — типовые, масштабируемые и построенные на шаблонах. Несмотря на то, что пожелания к инфраструктуре, языки программирования и алгоритмы сборки, используемые командами, различаются, общая концепция CI/CD процесса остается неизменной (см. схему на рисунке 2):
коммит в git — автоматическая сборка — деплой на тестовые серверы — функциональное и прочие виды автотестирования — продвижение сборки в стабильные — публикация на GUS — распространение через FUS на инфраструктуре заказчика — установка или обновление продукта на конкретных серверах.
На каждом из этих этапов DevOps-отдел помогает разработчикам решать конкретные задачи:
Каждый этап мы контролируем через систему мониторинга. В случае сбоя разработчики могут написать заявку в нашу службу, мы постараемся локализовать проблему и исправить ее.
Рисунок 2. Верхнеуровневая IDEF0-модель процессов Continuous Integration и Continuous Delivery в компании Positive Technologies
Подробнее о том, как мы строили и развивали нашу систему CI/CD в начале 2017 года, — в статье «Личный опыт: как выглядит наша система Continuous Integration [10]».
В нашей команде выделены ответственные за направление работ, связанное с мониторингом: от заявки на подключение сервера или сервиса на мониторинг, до конечного красивого дашборда системы управления (графики, метрики, система оповещения), предоставляемого в команды. Функциональные обязанности этой группы: настройка и предоставление службы мониторинга как сервиса, предоставление типовых шаблонов для мониторинга серверов и служб различных типов, проектирование иерархической системы мониторинга, прогнозирование нехватки ресурсов.
Мы используем систему мониторинга Zabbix. Для упрощения постановки служб на мониторинг, мы решили разграничить зоны ответственности между командой DevOps, разработчиками и тестировщиками, а также написали собственные инструменты для взаимодействия с Zabbix (zabbixtools [11]) и используем подход «monitoring as code». Поясним на примере: так, если у нас есть тестовый стенд, который нужно мониторить, то тестировщик назначает ему определенную роль. У каждого хоста — только одна роль, в которой может быть несколько профилей для мониторинга процессов, служб, API и другие — их предоставляет команда DevOps (см. отношения между сущностями Zabbix на рисунке 3).
Рисунок 3. Модель отношений между сущностями в Zabbix
Для упрощения конфигурирования реализована система, при которой Zabbix забирает с целевого сервера как можно больше данных о наблюдаемых показателях. Для этого в zabbixtools используется функциональность Low Level Discovery (LLD). Это позволяет вносить любые настройки мониторинга на самом отслеживаемом сервере, а не в админке Zabbix. Файлы настроек сохраняются и обновляются при этом через git.
Про внедрение системы мониторинга можно почитать в статье «Zabbix для DevOps: как мы внедряли систему мониторинга в процессы разработки и тестирования [12]».
Все обнаруженные проблемы и недостатки элементов наших CI/CD-систем мы фиксируем в нашей базе знаний DevOps. Обобщить проблемы каждого конкретного сервиса в пределах одной статьи довольно сложно, поэтому отмечу только наиболее показательные, например, для CI-системы TeamCity.
На данный момент все сборочные конфигурации в TeamCity сопровождаются только силами нашего отдела. Мы вносим изменения в них по заявке от разработчиков, чтобы избежать проблем с поломкой ими конфигураций из-за незнания наших шаблонов и инструментов. Также наша команда следит за окружением на сборочных серверах — агентах TeamCity. У разработчиков к ним нет доступа. Мы ограничили его для того, чтобы избежать внесения несанкционированных изменений на серверах и для упрощения локализации возможных проблем и отладки сборок: раз есть гарантия, что конфигурации и окружение не меняются самовольно, значит проблема может быть либо в коде, либо сетевая. Получается, что мы не можем предоставить разработчикам возможность самостоятельно отлаживать на TeamCity сборочный процесс и настраивать окружение на сборочном агенте.
Таким образом, первая проблема заключается в том, что нам не хватает возможности делегирования сборочного процесса в команды, используя подход «build as a code». У TeamCity нет простого для использования DSL (специфического языка описания сборки). Хотелось бы, чтобы код описания сборки хранился в репозитории рядом с кодом продукта, как, например, в Travis CI. Сейчас эту проблему мы решаем путем разработки своей системы сборки — CrossBuilder. Планируется, что она предоставит разработчикам возможность давать простое описание сборки, хранить и изменять его в своем проекте, а также не будет зависеть от используемой CI-системы, реализуя сборку через систему плагинов. Кроме того, эта система позволит запускать сборки локально, через standalone-клиент.
Вторую проблему с внесением изменений в сборочные окружения, как и многие другие инженеры, мы решили для Linux с переходом на docker-образы, за подготовку которых, в том числе хранение dockerfiles, команды отвечают самостоятельно. Это позволило выделить нам пул однотипных сборочных Linux-серверов, на каждом из которых может запуститься сборка любой команды в собственном окружении. Для Windows аналогичную схему мы только начинаем прорабатывать и сейчас проводим эксперименты.
Мы перепробовали множество различных сервисов и инструментов и со временем эволюционным путем сложился их определенный набор. Для решения задач нашего отдела мы используем: TeamCity и GitLab CI как CI-системы, GitLab для хранения кода, Artifactory как хранилище бинарных артефактов и проксирующий репозиторий, SaltStack для автоматизации сценариев развертывания окружений, Docker для изолированного сборочного окружения, SonarQube для анализа качества кода, UpSource для проведения командного код-ревью, TeamPass для безопасного хранения секретов, VMware как средство виртуализации, Zabbix для мониторинга всей нашей инфраструктуры, TestRail для хранения результатов тестранов, Kubernetes для управления контейнерами Linux и некоторые другие.
Из почтовых клиентов по корпоративному стандарту мы используем Outlook/OWA и Skype for Business, во всем остальном мы не ограничены регламентами, поэтому все используют то, что им удобно: браузеры Chrome, Thunderbird (Mozilla), Opera; файловые менеджеры Total Commander, FAR, ConEmu и обычный shell; редакторы MS Word, Notepad++ и, конечно, vim; ssh-клиенты Putty, WinSCP; снифферы и анализаторы трафика (tcpdump, windump, wireshark, burpsuite etc); из IDE любим PyCharm, Visual Studio, WebStorm; для целей виртуализации используем vSphere Client и VirtualBox.
Следуя за разработчиками нашей компании нам приходится автоматизировать процессы в основном под Linux (Debian, Ubuntu) и Windows (2003-2016). Соответственно, языковая экспертиза у нас такая же, как и у разработчиков, — это Python, C#, batch/bash. Для разработки типовых модулей, например, скриптов-метараннеров для TeamCity, у нас предусмотрен регламент, который четко описывает все шаги разработки: начиная от именования скриптов, методов, код-стиля и заканчивая правилами подготовки юнит-тестов на новый модуль и функционального тестирования всей сборки devops-tools (наши внутренние скрипты для автоматизации). В процессе разработки скриптов мы придерживаемся стандартной модели git-flow [13] с релизными и фича-сборками. Перед тем как слить ветки, код в них обязательно проходит код-ревью: автоматический, при помощи SonarQube, и ручной от коллег.
Особых преимуществ для организации CI/CD процессов на базе open-source решений мы не видим. На эту тему множество споров, но каждый раз приходится выбирать, что лучше: коробочное решение, заточенное под конкретные цели, или решение «as is», которое придется допиливать и поддерживать, но предоставляющее широкие возможности кастомизации. Однако, в прошлом году на завершении нашего митапа Op!DevOps! 2016 [14] мы рассказали о том, что нам разрешили выкладывать часть кода инструментов компании в open-source. Тогда мы только анонсировали [15] сообщество DevOps-разработчиков Open DevOps Community [16]. А уже в этом году, на митапе Op!DevOps! 2017 мы подвели промежуточные итоги [17] по его развитию.
В этом сообществе мы пытаемся объединить труд различных специалистов в единую систему лучших практик, знаний, инструментов и документации. Мы хотим делиться с коллегами тем, что умеем сами, а также перенимать их опыт. Согласитесь, ведь бывает так полезно обсудить сложную задачу с понимающим коллегой. Все, что мы делаем, — открытые инструменты. Приглашаем всех пользоваться ими, улучшать, делиться знаниями и подходами в DevOps. Если у вас есть идеи или инструменты для автоматизации чего-либо, давайте делиться ими через сообщество Open DevOps Community под MIT-лицензией! Это модно, почетно, престижно.
Цель сообщества Open DevOps Community — сформировать открытые готовые решения для управления полным циклом процесса разработки, тестирования и смежных процессов, а также доставки, развертывания и лицензирования сложных, многокомпонентных продуктов.
На данный момент сообщество находится в начальной стадии своего развития, но уже сейчас в нем можно найти некоторые полезные инструменты, написанные на Python. Да, мы его любим.
Каждый инструмент имеет автоматическую сборку в Travis CI с выкладкой в PyPI-репозиторий, где их можно найти и установить через стандартный механизм: python pip install.
Готовятся к публикации еще несколько инструментов:
Мы приглашаем всех желающих к участию в развитии сообщества! У нас есть типовой проект ExampleProject [29], в котором содержатся общая структура и подробная инструкция по созданию собственного проекта в сообществе. Достаточно его скопировать и сделать свой проект по аналогии (см. шаги для подготовки на рисунке 4).
Рисунок 4. Несколько простых шагов для подготовки своего инструмента к публикации в Open DevOps Community
Подходит к концу 2017 год и уже можно провести небольшой ретроспективный анализ проделанной нашей командой работы по развитию идей DevOps в Positive Technologies:
Так зачем же нужен отдел автоматизации в нашей компании? Мы так же, как и другие подразделения, работаем на конечный полезный результат, поэтому основная цель, преследуемая от внедрения идей DevOps в наши производственные процессы, — это обеспечить последовательное снижение себестоимости производства КПР.
В качестве основной функции нашего DevOps-отдела мы видим макросборку отдельных частей в единый полезный продукт и сокращение себестоимости цепочки: производство — доставка — развертывание ПО.
У нас продуктовая компания и исходя из ее будущих потребностей были определены глобальные задачи для нашего отдела на 2018 год:
Нас иногда спрашивают, что нам особенно запомнилось в нашей работе, какие ситуации из нашей практики внедрения DevOps были примечательны и чем. Однако, сложно выделить какой-то один случай, ведь, как правило, запоминаются авралы и их разрешение. Мы не приветствуем авралы, а любим четко запланированную работу по выстроенному процессу — когда все стабильно, предсказуемо, ожидаемо, а в случае форс-мажоров предусмотрены запасные варианты. Именно по такому принципу мы и стараемся строить наш сервис год за годом.
Нам интересно работать с любыми задачами по автоматизации: выстраивать CI/CD, обеспечивать отказоустойчивость релизных сборочных процессов, заниматься мониторингом и оптимизацией ресурсов, а также помогать людям выстраивать процессы в командах и разрабатывать полезные инструменты. Для нас важен планомерный, последовательный процесс построения DevOps как сервиса — ведь это стремление к лучшему.
P.S. А вот немного наших Telegram-стикеров для DevOps-ов [31].
Статья подготовлена на основе интервью [32] в журнале Системный администратор и доклада [17] на Op!DevOps! 2017 (слайды [33]).
Автор: Тимур Гильмуллин [34], руководитель группы поддержки процессов разработки, Positive Technologies
Автор: ptsecurity
Источник [35]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/razrabotka/270008
Ссылки в тексте:
[1] Positive Technologies: https://www.ptsecurity.com/ru-ru/products/xspider/
[2] MaxPatrol 8: https://www.ptsecurity.com/ru-ru/products/mp8/
[3] MaxPatrol SIEM: https://www.ptsecurity.com/ru-ru/products/mpsiem/
[4] PT Application Firewall: https://www.ptsecurity.com/ru-ru/products/af/
[5] PT Application Inspector: https://www.ptsecurity.com/ru-ru/products/ai/
[6] PT MultiScanner: https://www.ptsecurity.com/ru-ru/products/multiscanner/
[7] Миссия выполнима: как развить DevOps в компании со множеством проектов: https://habrahabr.ru/company/pt/blog/310584/
[8] DevOps best practices: рекомендации по организации конфигураций в TeamCity: http://forworktests.blogspot.ru/2014/11/devops-best-practices-teamcity.html
[9] Image: https://habrastorage.org/webt/tt/vl/vz/ttvlvz_rmze6xps7ypxas1lny-s.png
[10] Личный опыт: как выглядит наша система Continuous Integration: https://habrahabr.ru/company/pt/blog/313616/
[11] zabbixtools: https://github.com/devopshq/zabbixtools
[12] Zabbix для DevOps: как мы внедряли систему мониторинга в процессы разработки и тестирования: https://habrahabr.ru/company/pt/blog/325276/
[13] git-flow: http://nvie.com/posts/a-successful-git-branching-model/
[14] Op!DevOps! 2016: https://www.youtube.com/playlist?list=PLEl1NAXHTFNxcKRN09VQThNbQ33neUyfn
[15] анонсировали: https://www.youtube.com/watch?v=BeIeaeVVRbc&t=1s&list=PLEl1NAXHTFNxcKRN09VQThNbQ33neUyfn&index=16
[16] Open DevOps Community: https://github.com/devopshq
[17] промежуточные итоги: https://www.youtube.com/watch?v=fYjV-eZlvVA&list=PLEl1NAXHTFNyUW3toSkHLL4Jl1cw4vWkc&index=8
[18] crosspm: https://github.com/devopshq/crosspm
[19] по ссылке: https://www.youtube.com/watch?v=PNzGyUw04Io&list=PLEl1NAXHTFNxcKRN09VQThNbQ33neUyfn&index=13
[20] vspheretools: https://github.com/devopshq/vspheretools
[21] по ссылке: https://www.youtube.com/watch?v=LNakwC1t2AU&list=PLEl1NAXHTFNxcKRN09VQThNbQ33neUyfn&index=6
[22] YouTrack Python 3 Client Library: https://github.com/devopshq/youtrack
[23] TFS API Python client: https://github.com/devopshq/tfs
[24] Artifactory: https://github.com/devopshq/artifactory
[25] FuzzyClassificator: https://github.com/devopshq/FuzzyClassificator
[26] видео: https://www.youtube.com/watch?v=7umbbsKXk6M&index=9&list=PLEl1NAXHTFNxcKRN09VQThNbQ33neUyfn
[27] статье: http://math-n-algo.blogspot.ru/2014/08/FuzzyClassificator.html
[28] на видео: https://www.youtube.com/watch?v=C7kkcqazL9E&list=PLEl1NAXHTFNyUW3toSkHLL4Jl1cw4vWkc&index=3
[29] ExampleProject: https://github.com/devopshq/ExampleProject
[30] на видео: https://www.youtube.com/watch?v=hjVD9kxNOyY&index=1&list=PLEl1NAXHTFNxcKRN09VQThNbQ33neUyfn
[31] Telegram-стикеров для DevOps-ов: https://telegram.me/addstickers/opdevops
[32] интервью: http://samag.ru/archive/article/3543
[33] слайды: https://www.slideshare.net/phdays/open-devops-community
[34] Тимур Гильмуллин: https://plus.google.com/u/0/+TimurGilmullin
[35] Источник: https://habrahabr.ru/post/343884/
Нажмите здесь для печати.