DevOps — хайп или реально востребованная вещь?
В августе 2018 года я выступал на конференции «Найди себя в Digital» с докладом на тему «DevOps для разработчика». Общаясь со слушателями после выступления, я ещё раз осознал для себя хайповость слова DevOps.
Откуда пошла проблема
Начать стоит с корней проблемы, как и всегда. Не так давно, когда DevOps ещё даже не появился на рынке в виде жизненно важного требования, мир программирования делился на воинов ордена IDE и ордена Консоли, то бишь на программистов и сисадминов. И фраза «а у меня работает» была притчей во языцах большинства команд, которые выходили в мир больших продуктов с различными уровнями окружений.
Именно появление множества сред создало потребность в более гибком управлении инфарструктурой и конфигурациями окружений, нежели судорожное терзание vim в холодном поту по всему телу, когда при выкатке почему-то упала мастер-база.
Современная экосистема разработки состоит из нескольких слоёв. Их число в зависимости от стека, задач и команд может меняться, но базовая картина такова: 1. Production. Он же «прод» или «бой». Сервер, с которым взаимодействуют живые клиенты и реальные системы интеграции. Святая святых, куда не надо лазить грязными руками и вообще пускать лишних людей. На нём хранится последняя стабильная (всегда хочется в это верить) версия продукта, самые актуальные данные (если это хранилище) и вообще всё самое новое и красивое. 2. Stage. Он же QA, «квас». Пре-продакшн сервер, где проверяются кандидаты к релизу, проводится приёмочное тестирование со стороны пользователей или тестировщиков. Версии ПО здесь меняются гораздо чаще, чем на проде, но всё же данный слой должен быть достаточно стабилен, чтобы не мешать пользователям проверять соответствие того, что напрограммировали программисты, тому, что сами пользователи вообще хотели в начале. Лазить сюда голыми руками тоже не очень желательно. После того, как сборка прошла цикл тестирования на Stage, она отправляется на Production. 3. Development. Он же «дев» или «тест». Кухня с шипящим маслом и летающими ножами. Тут сливаются ветки, гоняются и падают тесты и творится то, что перемотанное скотчем передаётся пользователям для теста. Тут на стабильность смотрят сквозь пальцы, а за плохой код, обнаруженный на ревью, бьют линейкой. В общем, это последний оплот, где можно поправить код относительно быстро, не запуская сложных процессов и не задевая бизнес-пользователей. 4. Sandbox. Он же «песочница» или «локалка». Райская бухта разработчика, где он безраздельно правит свой код, творит новое и исправляет старое. Это личная среда разработки, которая должна хотя бы с определённым уровнем допущений копировать Production, чтобы не вызывать сюрпризов при выкатке.
Если абстрагироваться от частностей, то мы уже имеем 4 слоя. И это точно не 4 сервера, ведь продакшн требует отказоустойчивости, а разработчиков явно более одного при таком-то количестве слоёв. Совершенно логично здесь возникает вопрос о том, как ставить обновления, доставлять новые версии ПО, да и вообще контролировать весь этот зоопарк. А ведь вскоре появились микросервисы, которые стали умножать количество атомарных крохотных серверов, а значит — творя хаос и увеличивая энтропию.
Исчезновение границ
Даже если взять стек современного web-приложения, то это уже далеко не тот домашний зверёк под именем LAMP, к которому все привыкли в начале десятых. Сейчас это несколько фронт-энд узлов с логикой показа страничек (то есть NGINX, PHP-FPM или чем там кто обрабатывает запросы), перед которыми есть балансировщик (можно тот же NGINX). Базы стабильно уезжают на отдельные сервера ввиду своей прожорливости и часто также разнесены на ноды (значит, будет, к примеру, Percona + XtraDB Cluster). А ещё добавляются кэши (Redis, Memcached). Да и про интеграцию не надо забывать — там случаются всяческие Kafka с Rabbit, а то и GridGain, появляются Java и Go. А ещё надо как-то анализировать всё это — тут ELK-стек подъезжает. Как видите, всё разрастается с бешеной скоростью, и это я только по верхам пробежался. Контролировать это руками просто нереально.
С подходом классического системного администратора, который работал исключительно с консолью без понимания продукта в целом, в такой ситуации далеко не уедешь. Поэтому неравнодушные люди от мира IT стали придумывать пути решения непростой задачи, выработав в итоге прекрасный подход под названием Development Operations или DevOps. Принято считать, что направление DevOps появилось в 2009 году в результате совместной работы нескольких IT-сообществ.
Началось всё с того, что инженерам надоело бешено долбить команды в консоль, и они подтянули свои скилы в написании кода, чтобы автоматизировать рутинные задачи. С другой стороны, разработчики поняли, что вместо постоянного дёргания админов ради очередной пачки логов, стоит самим немного разобраться в среде, которая является средой исполнения для их систем. Так граница начала стираться и становиться невидимой.
Как следствие этого процесса, на свет появились замечательные инструменты — например, Ansible, который позволяет не собирать конфигурации для каждого элемента системы руками, а хранить их в так называемом Playbook-е (файл описания состояния компонентов системы, в котором они должны находиться в указанный момент времени, учитывая установленные пакеты, работающие службы, физические файлы и другие нюансы), который можно «проиграть» на чистой операционке и получить готовую машину с нужным набором свойств.
Для разработчиков стало нормой понимание устройства ландшафта и инфраструктуры, в которой работает их код. Тем не менее, для того чтобы новая киллер-фича не оказалась киллером для самого бизнеса, приложения стали ограничивать в ресурсах. Сначала это делали установленные лимиты на память, затем фермы виртуальных машин с ограниченным ресурсом, а сейчас это контейнеры, самой популярной системой управления которыми является Docker.
Поскольку инфраструктура получила формальное описание, то и её изменения стали поддаваться удобному версионированию, что привело к входу в обиход инженеров таких систем, как Git.
Когда всё довольно хорошо описано и автоматизировано, то и путешествие изменений в коде и/или инфраструктуре становится автоматизируемой задачей. Точкой, где инженерная часть плотно сходится с кодом — это системы непрерывной интеграции или Continuous Integration. Сама по себе CI является практикой достижения максимально быстрого обнаружения дефектов кода и доставки кода до Production в атоматическом режиме. Если говорить об упрощённой схеме, то действие происходит следующим образом: 1. Программист доводит код до конечного состояния, которое можно тестировать, коммитит его в функциональную ветку и отдаёт на слияние. 2. При успешном слиянии веток происходит сборка кода (загружаются библиотеки, зависимости и прочие ресурсы), готовится пакет файлов, который можно положить на сервер методом «копировать-вставить» и запустить. 3. При сборке запускаются автоматические тесты разных уровней, которые покрывают не только новый, но и уже существующий функционал. Если тесты не проходят, сборка рушится, а ветка возвращается на доработку с информацией о непройденных тестах. 4. При успешных тестах сборка доставляется на Production, где разворачивается согласно установленным правилам.
В момент, когда окружение программного обеспечения достаточно богато описано кодом, развёртывание окружения и становится частью CI. И под новую версию ПО разворачивается новый экземпляр окружения. Но DevOps мир пошёл дальше и создал Docker, который позволяет не просто создавать код, а создавать микроокружения (так называемые контейнеры), которые доставляются на Production с Development в неизменном состоянии, созданном, изменённом и протестированном самими программистами. Либо доставляются правила создания кластера таких контейнеров, по которым создаётся несколько единиц одинаковых обработчиков логики.
Так что же надо знать?
Таким образом, мы видим, что DevOps — это не какой-то конкретный набор инструментов, а философия организации процесса разработки и доставки ПО, которая подразумевает тесное взаимодействие между разработчиками и инженерами, управление инфраструктурой через код, а также позволяет гибко управлять системами, насчитывающими сотни серверов.
Если вы хотите погрузиться в философию DevOps глубже, то начать стоит с прекрасной книги за авторством Джина Кима, Кевин Бер и Джорджа Спаффорда «Проект «Феникс». Роман о том, как DevOps меняет бизнес к лучшему», которая в художественной форме подробно описывает проблемы, стоящие перед отделами, внедряющими современные практики разработки, и пути их решения.
Разработчикам точно стоит посмотреть в сторону организации инфраструктур на платформе Docker с применением Kubernetes, созданием stateless-приложений, способных работать в отвязке от конкретного сервера запуска, да и просто быть в используемой в компании ОС, как дома.
Инженерам стоит погружаться в автоматизацию рутинных процессов, создания экземпляров серверов и систем, а также особенностей работы используемого в компании стека ПО. Всё это, разумеется, должно быть хорошо наблюдаемо, что требует подробного мониторинга, например, на Zabbix, и не менее подробного анализа логов, где начинается ELK-стек.
Как видите, пространство для развития очень большое. Выбирать направление вам, а я надеюсь, что моя статья помогла лучше понять философию модного нынче течения.
