Методология DevOps призвана стратегически уменьшить время выхода программного продукта на рынок, т.е. в его жизненном цикле максимально ускорить процесс подготовки, разработки, тестирования и развертывания программного продукта путем всевозможной автоматизации. Тактически же - обеспечить разработчикам гибкий инструмент доставки кода конечным потребителям - пользователям.
DevOps-инженер сталкивается с очень обширным рядом задач и технологий, их столько, сколько есть программных продуктов и способов их разработки. У DevOps-инженера также должны быть разнообразные инструменты, которые позволят максимально упростить и автоматизировать разработку, тестирование и доставку кода. Конечно же, описать в одной статье все инструменты и методы - невозможно, но мы вспомним самые распространенные и часто используемыми на практике.
Инструменты DevOps
Схема 1 - Возможная классификация инструментов DevOps
Ansible (Puppet, Salt)
Puppet, Ansible и Salt были задуманы, чтобы упростить настройку и обслуживание десятков, сотен и даже тысяч серверов. Суть этих программных продуктов состоит в том, чтобы развернуть идентичную конфигурацию сразу нескольких серверов и не повторять много раз одни и те же операции.
Каждый из данных инструментов обладает своими преимуществами и недостатками, годен к использованию в различных конфигурациях. Например, Puppet в своей работе использует серверную часть и клиентские приложения, с помощью которых распространяет необходимые настройки на все серверы. Агенты периодически обращаются на сервер за списком изменений или же принудительно обновляются командой с сервера. Но в случае, когда вы - подрядчик и управляете ИТ-структурой клиента, политика безопасности которой не позволяет установку дополнительного ПО на обслуживаемые серверы, будет уместно использовать Ansible, который не использует агенты, а все настройки и команды выполняет исключительно по ssh, авторизируясь по ключам пользователя, от которого запущен.
Используя эти инструменты, вы сможете легко и непринужденно разворачивать и настраивать большое количество серверов в короткое время и с одинаковой конфигурацией.
Сравнительная характеристика Ansible, Puppet, Salt
Поддержка
Ansible works
Puppet Labs
Saltstack
Конфигурирование
Playbook (YAML, JSON)
Manifest (DSL)
SLS (Solt State/ YAML)
Архитектура
Standalene (Masterless)
Master/Agent Standalone
Master/Agent(minions) Standalone(Masterless)
Ядро системы
Python
Ruby
Python
Протокол взаимодействия
SSH/JSON
http, ssh / SSL
ZeroMQ
Gitlab, Bitbucket
Одним из основных инструментов разработчиков, в том числе и DevOps-инженеров, является система управления конфигурациями. Эти инструменты давно стали намного большим, чем просто системой для версионирования кода. Теперь это целая интеграционная единица, позволяющая интегрироваться с ITIL-системами типа Jira. Они включают встроенный функционал CI/CD, возможности совместной разработки, отслеживания ошибок, управления задачами, базу знаний и многое другое.
Выбор системы управления конфигурациями основывается на задачах, которые вы ставите перед программным продуктом, который разрабатываете, инфраструктурой на которой создаете продукт и куда потом его выкатываете. Основные отличия можно представить так:
Сравнительная характеристика систем управления конфигурациями
Bitbucket
Gitlab
Bitbucket
Gitlab
Bitbucket
Gitlab
Jenkins, Gitlab CI, TeamCity
Jenkins - это инструмент непрерывной интеграции с открытым исходным кодом, написан на Java. Jenkins предоставляет возможность тестирования кода в режиме реального времени, а также дает возможность получать отчеты об отдельных изменениях в обширной кодовой базе. Этот инструмент позволяет разработчикам быстро помечать и исправлять ошибки и баги в коде, а затем автоматически тестировать сборку кода, выпускать на dev-структуру либо на prod.
Аналогом Jenkins выступает TeamCity, который поддерживает большое количество функционала, а также имеет очень надежную бесплатную версию для маленьких проектов. Поставляется с обширной поддержкой множества плагинов с открытым исходным кодом – как собственных продуктов JetBrains (создателя системы), так и сторонних приложений и инструментов. Также TeamCity предлагает потрясающую поддержку .NET. Также стоит сказать об уже названном инструменте - Gitlab, который вместе с системой управления конфигурациями включает инструменты непрерывной интеграции с довольно широким функционалом.
Использование DevOps инструментов Ci/CD в различных компаниях
Jenkins
Facebook. Netflix. Instacart, Lyft
GitLabCi
WebbyLab, Dial Once, InfoxExchange, Redsmin
TeamCity
StackOverflow, Ebay, Apple, Intuit
Prometheus + Grafana, Zabbix
Важным инструментом DevOps-инженера являются системы мониторинга ИТ-инфраструктуры. Слежение за состоянием сервисов и серверов позволяет не только вовремя реагировать на неисправности, но и анализировать их работу. Наличие такой информации трудно переоценить, ведь она предоставляет дополнительные возможности по улучшению производительности и качества работы ПО.
Минимальная конфигурация системы мониторинга Prometheus состоит из сервера Prometheus и отслеживаемого приложения, достаточно только указать по какому адресу необходимо запрашивать метрики. Сбор метрик выполняется согласно pull-модели по протоколу HTTP, но существует и push-gateway компонент для слежения за короткоживущими сервисами. При использовании pull-модели, приложения не знают о системе мониторинга, а значит можно запускать несколько серверов Prometheus для мониторинга, тем самым застраховаться от возможных потерь данных.
Многие считают, что пользовательского интерфейса Prometheus недостаточно, поэтому устанавливают инструментарий визуализации данных Grafana, который позволяет графически отобразить производительность и загруженность сервисов, а AlertManager - позволит сформировать уведомление о превышении показателей через удобный для вас канал связи. Аналогом системы Prometheus является система мониторинга Zabbix, имеющая клиент-серверную архитектуру и чаще используемая для мониторинга серверных инфраструктур, чем микросервисных приложений и систем.
Схема 2 - Схема работы Zabbix
Docker
Docker - это платформа для контейнеризации ПО, которая решает проблему с неисправным кодом при коллективной работе над проектом. Docker переносит разработку в изолированные среды (контейнеры), которые содержат все, что нужно для работы с проектом. Docker позволяет «упаковать» приложение со всем его окружением и зависимостями в контейнер, который может быть скопирован и использован в многочисленных других аналогичных системах. Использование контейнеризации позволяет минимизировать ресурсные затраты системы на виртуализацию ОС, используя только необходимые ресурсы для компиляции и выполнения кода создаваемого программного продукта или его многочисленных микросервисов.
Схема 3 - Принцип работы Docker
Kubernetes
Kubernetes является проектом с открытым исходным кодом, предназначенным для управления кластером контейнеров Linux как единой системой. Kubernetes управляет и запускает контейнеры Docker на большом количестве хостов, а также обеспечивает совместное размещение и репликацию большого количества контейнеров. Проект преследует две цели. Если вы пользуетесь контейнерами Docker, возникает следующий вопрос о том, как масштабировать и запускать контейнеры сразу на большом количестве хостов Docker, а также как выполнять их балансировку. В проекте предлагается высокоуровневый API, определяющее логическое группирование контейнеров, позволяющее определять пулы контейнеров, балансировать нагрузку, а также задавать их размещение.
Схема 4 - Принципиальная схема кластера Kubernetes
Заключение
Главная задача DevOps-инженера — максимально увеличить предсказуемость, эффективность и безопасность разработки ПО.
Если рассматривать полный жизненный цикл ПО, то на этапе оценки DevOps-специалисты получают первичную информацию о необходимости нового кодирования и внесения изменений в ИТ-инфраструктуру. На этапе проектирования — определяют требования к инфраструктуре. На этапе разработки и тестирования — занимаются развертыванием продукта, а также поддержкой средств для разработки, интеграционным и нагрузочным тестированием ПО для проверки готовности операционной среды.
Основная часть работы DevOps инженера приходится на этап выпуска релиза — поставки продукта заказчику. В центре внимания находится производительность всех потоков процесса доставки. Такой специалист следит за тем, чтобы известные баги никогда не передавались на следующий этап работ, никогда не развивалась локальная оптимизация, приводящая к созданию глобальной деградации.
Какой инструментарий используется для выполнения данной задачи и работы - зависит от разрабатываемого программного продукта, его архитектуры, языка и принципов разработки и собственно квалификации команды разработки.