DevOps – одна из самых актуальных и динамично развивающихся областей в ИТ. ПСБ организовал митап для специалистов этой отрасли, на которым выступили эксперты банка, а также приглашенные гости из Т1-Иннотех и IT Enduro.
Участники смогли узнать о последних трендах в DevOps, полезных инструментах, импортозамещении, лучших практиках и реальных кейсах, которые помогут сделать работу еще более эффективной и продуктивной. На встрече выступили ключевые DevOps-эксперты. Они поделились своими знаниями и опытом. Краткое содержание их докладов – в этой статье.
DevOps – культура и методология практик, объединяющих разработку и эксплуатацию. Основная цель – ускорить доставку качественного программного обеспечения, улучшить его стабильность и надежность, повысить удовлетворенность клиентов.
Подготовка к митапу
Митап прошел на платформе Codenrock. Площадка предоставила все необходимые инструменты для привлечения аудитории и проведения трансляции:
- Для мероприятия была создана отдельная страница, на которой пользователи могли ознакомиться со всей информацией о встрече и зарегистрироваться в качестве участника.
- Дополнительно были созданы страницы со сведениями о расписании, программе и спикерах митапа.
- Смотреть прямую трансляцию можно было прямо на Codenrock.
- Участники могли задать свои вопросы докладчикам через платформу. Для этого было необходимо выбрать соответствующий пункт в меню мероприятия на сайте и ввести свой вопрос. Модератор митапа сразу же получал информацию о новом вопросе и мог оперативно передать его спикерам.
- После завершения мероприятия организаторы могли получить статистику и обратную связь. На митап зарегистрировалось 347 человек, на пике трансляцию смотрели 49 участников.
ПСБ пригласил на выступление пятерых DevOps-экспертов, которые подготовили доклады. В конце митапа спикеры собрались за одним столом, чтобы ответить на вопросы и обсудить актуальные проблемы отрасли: применение ML в задачах, поиск и обучение специалистов, оценку результатов работы коллег, применение облачных технологий.
Serverless: новый путь в разработке
С докладом выступил Лев Немировский, руководитель направления по развитию инструментов внедрения Центра непрерывной поставки программного обеспечения ПСБ. Serverless – это модель предоставления серверных услуг без аренды или покупки оборудования.
Термин многих путает. Дословно он переводит как «бессерверный». Но мы люди взрослые, в сказки и Деда Мороза не верим и понимаем, что без серверов инфраструктуры быть в принципе не может.
Serverless – следующий этап развития технологии контейнеризации. При таком подходе почти все задачи берет на себя провайдер. Клиент занимается только написанием кода приложения и CI/CD, хотя и здесь поставщик услуги предлагает дополнительные инструменты, упрощающие интеграцию и развертывание.
Провайдер предоставляет:
- Serverless Functions;
- Serverless Containres;
- Object Storage;
- Message Queue;
- Database;
- API Gateway.
Где применяется Serverless:
- Микросервисы.
- Интернет вещей.
- Чат-боты.
- Решение периодических задач.
- Интеграция с платформами.
Главное преимущество Serverless, и его же недостаток – отсутствие платы за использование во время простоя. Подход будет выгоден для проектов с непостоянной нагрузкой. Но для приложений с высоким RPS метод не подойдет, и будет лучше сделать выбор в пользу виртуального или физического сервера.
Таким образом, Serverless облегчает работу разработки и уменьшает стоимость. Если нагрузка постоянна, то облачные функции окажутся затратными, но при этом остальной Serverless можно использовать. При этом важно осознанно подходить к выбору провайдера.
Это как минимум стоит попробовать. Serverless не просто технология – это новая философия построения и развертывания приложений, которая может радикально изменить подходы в разработке и эксплуатации ПО. Она открывает двери для инноваций, позволяя разработчикам сосредоточиться на создании ценности, а не на поддержке инфраструктуры.
Со своим самоваром: как мы переносили распределенный монолит из одной CI-системы в другую
С докладом выступил Петр Галонза, управляющий эксперт отдела внедрения системных сервисов ПСБ. Спикер рассказал о нестандартном кейсе переноса проекта с Jenkins в GitLab CI.
Исходные данные: распределенный монолит в моно-репозитории. Основной компонент – платформа Documentum, вокруг которой происходит разработка на языке Java с различными фреймворками, двумя серверами приложений Tomcat и Weblogic, а также сборщиками Maven и Gradle.
Зачем был нужен перенос с Jenkins на GitLab CI:
- GitLab CI был выбран целевым CI-инструментом.
- Jenkins был поднят силами самих разработчиков и никем не поддерживался.
- Проблемы безопасности.
И с этим надо было что-то делать. Это была моя первая задача как DevOps-инженера. Я воодушевился, пришел в команду и сказал: «Вы живете неправильно. Мы с релиз-менеджером принесли вам новые процессы, все переделаем, доступы отнимем, деплой на свою сторону заберем». Команда отнеслась к идее настороженно.
Первое, что бросилось в глаза: у проекта есть четкая взаимосвязь с установкой компонентов. Когда ставилось время установки, артефакты сразу собирались и несли информацию о контуре – это не позволяло их переиспользовать.
Процесс выглядел следующим образом. Я что-то делал, радовался, показывал команде. Команда говорит: «Нет, не подходит, переделывай». Огорчался, принимал это и повторял процесс заново.
Для переноса pipeline был реализован на Groovy. Также была подготовлена диаграмма, на которой был представлен весь процесс деплоя, так как не все разработчики знали последовательность – она была скрыта в логике на Groovy. Все задачи были оформлены в GitLab CI. Были созданы два пайплайна:
- Основной для сборки с возможностью выбора контура.
- Дочерний с конкретной задачей на установку.
Сперва разработчики пробовали новый процесс вручную. Поэтому следующим шагом была автоматизация установки. Для этого нужна была следующая информация:
- Состав релиза.
- Ветка или сборка к деплою.
- Контур для деплоя.
Для автоматизации была задействована функция GitLab «Динамические пайплайны». Для возможности выбора компонентов и веток была написана утилита на Python с окном информации о состоянии пайплайна. Дополнительно были настроены оповещения в Mattermost с информацией и начале и окончании деплоя.
Мы смогли перенести этот непростой проект на сторону GitLab.
Почему у нас свое железо
С докладом выступил Александр Татаринцев, старший инженер отдела внедрения бизнес-сервисов ПСБ (г. Севастополь). Спикер рассказал о преимуществах и недостатках использования собственного оборудования по сравнению с облачными технологиями.
Изначальная идея – направить банк в сторону готовых решений. Опытные разработчики тратят много времени на создание того, что уже существует. При этом есть ограничения со стороны федеральных законов, отдельных статей, стандартов Центробанка, внутренних регламентов ПСБ и других правовых актов.
Я вам достоверно могу сказать, что я все это прочитал и исследовал. И среди этих документов нет ничего, что запрещает банку размещаться в облаках.
Банк может использовать следующие возможности облачных технологий:
- Полный цикл обработки данных любого типа.
- Инструменты разработки.
- Мониторинг и управление ресурсами.
- Сервисы управления облачной инфраструктурой.
- Бессерверные вычисления.
- Машинное обучение.
- Разработка и администрирование контейнерных приложений.
- Инструменты для управления безопасностью.
- Бизнес-инструменты.
Применение облачных технологий дешевле, чем содержание собственного железа, и требует гораздо меньше трудозатрат на развертывание и поддержание. Кроме того, такой подход уменьшает время отклика при сравнении с центральным размещением серверов в Москве.
Однако не стоит переносить сразу всю банковскую инфраструктуру в облачные сервисы. Можно взять проект, и, например, развернуть в облаке только приложение, а базу данных оставить у себя.
Виртуальные машины внутри контейнеров
С докладом выступил Руслан Гайнанов, руководитель команды DevOps-инженеров на проекте Службы управления конфигурациями «Осмакс» в Т1-Иннотех. Спикер поделился опытом поиска решений для запуска тестовых стендов с виртуальными машинами на базе отечественной операционной системы в кластере Kubernetes.
«Осмакс» – это система распространения и обновления ПО, а также массового управления конфигурациями устройств в гетерогенной среде. Основные требования к этому продукту:
- Микросервисы не подходят. Все должно упаковываться в стандартные deb/rpm пакеты.
- Для запуска требуются system-службы.
- Работа с отечественными и иностранными операционными системами и физическими устройствами.
- Поддержка оборудования без ОС.
- Графический интерфейс для удаленного доступа.
Вывод такой: никаких контейнеров не будет. Привычный путь разработчика, когда мы все упаковываем в docker-файлы и оно запускается одинаково что у разработки, что на сервере, не подходит.
Использование физического железа – дорого. Но есть решение на базе виртуальных систем, позволяющих эмулировать множество устройств на одном сервере. От закрытых коммерческих гипервизоров отказались сразу. Есть открытый продукт KVM – модуль ядра Linux, который предоставляет возможности для аппаратной виртуализации. В связке с ним применяется QEMU – эмулятор платформ, позволяющий запускать гостевые ОС.
Для управления гипервизорами можно использовать libvirt – open-source проект, который предоставляет интерфейс взаимодействия через набор XML-файлов и возможность автоматизации через API. Также есть иные варианты: bash-скрипты, Ansible, Vagrant или Terraform.
Но больше всего заинтересовало открытое решение KubeVirt для запуска виртуальных машин в Kubernetes, потому что в компании уже был рабочий нагруженный кластер. Модуль представляет собой набор virt-операторов, которые позволяют создавать ресурсы внутри кластера:
- virt-api – интерфейс для запуска и обслуживания манифестов виртуальных машин;
- virt-controller – следит за преобразованием машин и их запуском на рабочих нодах;
- virt-handler – позволяет передавать внутрь контейнера с виртуальной машиной определенные физические ресурсы;
- virt-launcher – исполняемый файл, который запускает виртуальную машину.
После настройки и запуска в Kubernetes стало возможно:
- подключиться к виртуальной машине;
- управлять ее данными через эфемерные или долгосрочные хранилища;
- управлять ресурсами с помощью Kubernetes Scheduler, который позволяет задавать архитектуру, загрузчик, модель материнской платы и процессор;
- контролировать доступ к виртуальной машине;
- отслеживать состояние машин инструментами Kubernetes.
Главные достоинства решение:
- Одновременное использование виртуальных машин и контейнеров.
- Эффективная утилизация ресурсов.
- Поддержка со стороны сообщества.
- Отказоустойчивость из коробки.
Очумелые ручки: делаем свой Helm Chart Repository из подручных средств
С докладом выступил Алексей Романов, Co-founder Ed-Tech стартапа IT Enduro. Эксперт рассказал, как легко и просто организовать свой Helm Chart Repository, а также как сделать тесты и поддержку документации для charts.
Helm – менеджер пакетов для Kubernetes, который развертывает приложения в структурирует их в чарты. Его основная задача – предоставить инструмент для шаблонизации манифестов, чтобы их можно было переиспользовать в других задачах.
Для того, чтобы сделать свой репозиторий Helm Chart, можно использовать GitHub Pages – общедоступные статические веб-страницы, размещенные и опубликованные через GitHub. Чтобы начать работу с этим инструментом, достаточно создать ветку gh-pages и добавить в нее файлы:
- index.md – содержимое страницы;
- _config.yaml – файл конфигурации с настройками.
Вы удивитесь, но очень много документации в среднего размера open-source проектах хостятся именно на GitHub Pages.
Для создания репозитория необходимо собрать все чарты в архив и опубликовать их как Release. Затем собрать файл index.md c информацией о чартах и сделать коммит в ветку gh-pages. Чтобы проектом мог пользоваться кто-то еще, следует разместить его на ArtifactHub – веб-приложении, которое позволяет находить, устанавливать и публиковать Helm Charts.
Для создания документации лучше всего использовать автоматическую генерацию на базе кода. Для этой задачи подойдет Helm Docs – он собирает информацию о проекте из Charts.yaml и параметров values.yaml. Markdown генерируется с помощью go templates на основе шаблона, описанного в README.md.gotmpl.
Стандартизировать репозиторий поможет менеджер скриптов Pre-commit Framework, который позволяет легко переносить их между проектами.
Выводы:
- Если вы работаете с k8s, то helm – ваш лучший друг.
- Чтобы переиспользовать helm charts в других проектах, можно легко и просто сделать свой собственный репозиторий.
- Linters и прочие валидаторы помогают поддерживать код в чистоте и порядке.
- Helm docs позволяет поддерживать актуальную документацию без лишних усилий.
Клуб DevOps
В первую очередь, база администрирования, работа с bash-скриптами, знание какого-либо языка программирования. Самый важный навык – умение решать проблемы. У разных компаний разные технологии, поэтому DevOps-специалисту важно разобраться в задаче и самостоятельно предложить решение.
Должен ли DevOps быть больше dev, чем ops?
Знаниями dev обладать необходимо, потому что инженеру приходится взаимодействовать с другими разработчиками. Владение языком программирования поможет автоматизировать задачи или написать необходимый скрипт. Но в крупных компаниях на больших проектах DevOps-специалист не может и не должен делать все, поэтому ему необходимо также хорошо владеть навыками администрирования.
Где и как искусственный интеллект помогает DevOps в рабочих задачах?
Основной кейс: автоматизация рутинных задач, таких как составление служебных записок или написание протоколов. Из прикладного применения – подготовка CI/CD пайплайнов, формирование базы данных, генерация документации. Для передачи ИИ чувствительной информации можно развернуть локальные решения.
Лучше выращивать DevOps-специалиста внутри команды или искать на рынке?
Внутри компании в любом случае нужен центр компетенций, который будет заниматься обучением сотрудников. Команда опытных экспертов должна не только хорошо выполнять свои задачи, но и передавать свои знания. У начинающих специалистов большой плюс – они более лояльны, не тянут за собой опыт предыдущих мест работы и готовы реально разобраться в особенностях конкретного технологического стека.
Как построить надежную инфраструктуру в условиях санкций?
Требования к надежности отличаются в зависимости от компании. В первую очередь стоит брать проверенные инструменты. Начать лучше с open-source решений, протестировать и изучить их, а затем уже выбирать коммерческие продукты. Ориентироваться стоит на количество доработок, которые необходимо внести для поддержания бизнес-проблематики.
Как оценивать эффективность DevOps, по каким показателям и критериям?
Есть DORA-метрики, которые позволяют оценить результативность работы команды. Для конкретного специалиста главный критерий – работают его решения или нет.
Будут ли компании активно переходить на облачные решение, или свое железо надежнее?
Да, свое железо как будто бы надежнее. Однако многое зависит от проекта. При наличии средств и желании быстро выйти на рынок однозначно не нужен свой ЦОД. Облака дешевле, быстрее и надежнее. Крупной устоявшейся компании переходить полностью на облачные решения не стоит. Лучше начать плавный переезд или остаться на своем железе, если хорошо налажена собственная инфраструктура.
Делегировать ли часть своей работы разработчикам?
В банке – нет, у специалистов четко разделена ответственность, и они не занимаются работой друг друга. С другой стороны, разработчикам полезно знать о том, что происходит в команде DevOps. У сотрудников должна быть хорошо налаженная коммуникация, чтобы оперативно решать возникшие проблемы и делиться опытом.
Как убедить руководителя в необходимости той или иной технологии?
С бизнесом нужно говорить на языке денег. Вам нужно обосновать экономическую выгоду – объяснить, во сколько обойдется внедрение решения и сколько оно поможет сэкономить в долгосрочной перспективе. Не всегда инженер может напрямую определить прибыльность. В таких случаях необходимо помнить, что в деньги можно превратить все вокруг, например, посчитать, как технология увеличит скорость выполнения задачи и пересчитать время на зарплату в компании. В идеале приходить к руководителю с готовым пилотным проектом.
Можно ли настроить статический IP для виртуальной машины?
В Kubernetes есть интересная особенность – контейнеры не имеют постоянного IP-адреса. Если для виртуальной машины необходим статический адрес, то для этого есть container network interface инструмент Multus.
Сколько ресурсов на раннере нужно, чтобы реализовать полноценное тестирование чартов на кластере Kubernetes?
Необходимо запустить Minikube или Kind и все ресурсы направить на него. Обычно такие решения не потребляют много мощности. На бесплатном сервисе GitHub Actions предоставляется 8 ГБ оперативной памяти и 2 ЦПУ – этого достаточно для большинства задач.
