17 шагов DevOps

Нет времени на видео? Краткое содержание ролика в статье: время прочтения 7 минут.

Что такое DevOps?

DevOps - это методология, набор практик. Методология DevOps была создана для связи отделов тестирования, эксплуатации и разработки в компаниях, чтобы продукт можно было обновлять чаще без потери качества.

Внутри практик DevOps можно выделить несколько профессий, но так как слово DevOps достаточно хайповое в последнее время, обычно все эти профессии объединяют в одну: DevOps-инженер - специалист с широким кругозором, который может решать любые задачи. И давайте договоримся, мы будем называть DevOps-инженером специалиста, который занимается внедрением и реализацией DevOps-практик.

В DevOps-инженеры часто идут системные администраторы. У них достаточно похожий бэкграуд в плане знаний.

В чем разница между системным администратором и DevOps-инженером?

Представьте, что в вашей компании есть 3 отдела: эксплуатации, тестирования и разработки. Разработка программного обеспечения идет по цепочке:

задача попадает в отдел разработки, где разработчики пишут код;
задача передается в отдел тестирования, где новую функциональность проверяют на тестовых стендах;
код уходит в эксплуатацию, где админы должны развернуть новый код на продакшн-серверах.

Системные администраторы в этой цепочке затрагивают только отдел эксплуатации. DevOps-инженер связывает все эти три отдела в единое целое. Он автоматизирует все рутинные действия. Он собирает код, который пишут разработчики. Он описывает всю инфраструктуру с помощью, например, Ansible и автоматически разворачивает тестовые среды. После чего автоматически обновляет продакшн без потери качества.

Главная задача DevOps-инженера - автоматизировать все, что автоматизируется, для того, чтобы бизнес имел возможность обновлять свой программный продукт быстро, качественно и стабильно.

Индустрия DevOps

За последний год порядка 2 млрд человек совершили покупки на 1,5 трлн $. И все это онлайн-проекты. К примеру онлайн-сервис Amazon, внедрив DevOps-практики, смог начать изменять свой продукт 7000 раз в сутки.

Количество интернет-проектов, стартапов и технологических компаний растет. И в каждый такой проект необходим DevOps-инженер, или целая команда специалистов по инфраструктуре, которые помогут бизнесу обновлять свой продукт очень быстро и качественно.

Пример на базе нашего агентства Fevlake. Мы работаем с 2012 года, и последние 2 года мы наблюдаем огромный ажиотаж вокруг DevOps-практик. Все компании хотят их внедрять, чтобы постоянно изменять свой продукт в лучшую сторону. Среди наших клиентов финтех-стартапы, криптобиржи, маркетплейсы, развлекательные сервисы, телеком, государственные компании.

17 шагов до DevOps-инженера

Чтобы войти в профессию, никаких специальных требований к DevOps-инженеру не предъявляется. Но я бы выделил 4 базовых пункта, без которых будет тяжело развиваться:

знание окружения, где вы планируете работать (Windows, Linux и др. на уровне Middle - Senior);
сети (на базовом уровне);
знания Junior developer (общее понимание);
Junior DBA.

Итак, переходим к 17 шагам. Общая идея такая - мы с вами будем настраивать весь процесс деплоимента от написания кода до развертывания его на продакшене.

1. API

Изучить, что такое API.
Какие виды API бывают, как с ними работать?

И реализовать их, например, сделать простой проект - интернет-магазин. То есть вам необходимо спроектировать API этого магазина и реализовать его на любом известном вам языке программирования. Если вы не знаете ни одного языка, можно изучить Golang - пройти тур на официальном сайте http://tour.golang.com/

2. Базы данных

Добавить базу данных MySQL или Postgress.
Поработать с запросами.

Усложним наше приложение и заставим его работать с базой данных. В код вашего приложения необходимо будет добавить работу с базой данных. MySQL или Postgress.
Чтобы при запросах пользователя, например, проверялись его токены, происходила аутентификация и авторизация, а список товаров магазина лежал внутри базы.

3. Git

Заливаем ваш код на любой хостинг Git-репозиториев.

Начнем работать с кодом, как должны работать с ним ваши разработчики.
Вы регистрируетесь на GitHub , Bitbucket , Gitlab или любом хостинге Git-репозиториев и заливаете туда свой код. Именно с этого момента начинается ваша автоматизация по работе с кодом.

4. Автоматизация / Jenkins / Teamcity / Gitlab CI

Jenkins / TeamCity / Gitlab CI
Сборка кода
Заготовка будущего Pipeline

Автоматизируем сборку вашего кода. Если вы выбрали в качестве языка программирования что-то компилируемое, то мы будем с помощью таких инструментов, как Jenkins, Teamcity, Gitlab CI, автоматизировать сборку кода. К концу этого шага вы должны получить небольшую заготовку вашего будущего pipeline. У вас уже будет код в репозитории, и мы будем автоматически собирать его с помощью CI/CD инструментов.

5. Автоматизация сборки кода

Теперь мы автоматизируем этот процесс. Как только код в Git-репозитории изменился, вам необходимо будет запускать сборку на выбранном инструменте.
Делать это можно различными способами:

Заставить CI/CD систему саму опрашивать Git-репозитории на наличие изменений.
Использовать web-хуки от облачных провайдеров.

6. QA

Вам будет необходимо добавить новый шаг к вашему pipeline. Сборка у нас уже есть, теперь мы будем автоматически проверять ваш код.

Вы можете посмотреть различные линтеры для вашего языка программирования. Также можно проверять синтаксис и проводить Unit-тесты.

7. Infrastructure as a code

Переключимся на эксплуатацию. Вы должны вооружиться такими инструментами как:

Ansible,
Puppet,
Chef

и описать свою инфраструктуру в виде кода. Сейчас в топе по различным проектам Ansible. Если интересно посмотреть в сторону кода, рекомендуем Chef.

Итогом этого шага должен стать еще один Git-репозиторий, в котором будет написана ваша инфраструктура. Благодаря этому репозиторию, вы сможете создавать свои тестовые и продакшн окружения в 1 клик.

8. Разворачиваем тестовые/продакшн среды.

Мы должны научиться быстро разворачивать тестовые/продакшн среды. Для этого есть несколько инструментов, например:

Vagrant,
Terraform.

Vagrant больше подходит для создания dev-сред разработчиков, хотя с внедрением Docker он отошел на второй план.

Советую посмотреть также на Terraform, который позволяет создавать виртуалки и прочие ресурсы в различных облачных сервисах.

Этот пункт нам понадобится для того, чтобы мы в 1 клик мыши могли поднять нашу инфраструктуру, поднять виртуальную машину и настроить ее с помощью Configuration System Management утилит (с помощью Ansible/ Chef / Puppet и др.) и дальше развернуть на это окружение наше приложение.

9. Автоматизируем процесс создания виртуалок и подключаем его к выбранному CI/CD инструменту.

Если вы используете Jenkins, то подключайте соответствующий плагин и после прогонов тестов на вашем приложении вы должны прогнать новую виртуалку, настроить ее с помощью Ansible и развернуть туда ваше приложение.

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

10. Best practices по деплою выбранного вами языка программирования

Наверное, это самый сложный поинт в 17 шагах, если вы только начинаете.
В этом блоке, вам будет нужно найти, именно найти, best practices по необходимому языку программирования. Сложность в том, что лучшие решения по разным языкам программирования сильно отличаются и вам нужно понимать, как запускаются различные проекты.

Обычно best practices находятся на официальных сайтах различных языков программирования.

11.Реализация best practices, которые вы нашли в предыдущем шаге.

Это может быть абсолютно любой деплоймент с применением различного стека технологий.

Это может быть деплоймент с помощью deb или rpm пакетов, деплоймент с использованием симлинков, таких инструментов, как Kapistrano / Ansistrano, Docker и др.

12. Вернемся к QA.

К 12 шагу у нас должен храниться код в репозитории, также должен быть создан отдельный репозиторий с описанием инфраструктуры. Должен быть настроен CI/CD инструмент, который автоматически, при изменении кода в репозитории, будет его собирать, тестировать, разворачивать новое окружение и выливать приложение на вновь созданное окружение.

Вернемся к тестированию. Добавим в наш pipeline очень простой тест - smoke-тест, который будет определять, запустилось ли наше приложение или нет.

Большинство приложений прекрасно собираются, но при запуске возникают проблемы. Этот тест позволяет их увидеть на раннем этапе. В этом же пункте вы можете прочитать про нагрузочное тестирование и про различные онлайн-сервисы для него.

Loader IO
Yandex Tank
Apache Benchmark

На этом этапе самое главное дать быстрый фидбек разработчику - работает приложение или нет.

Зачем это нужно?
Если у разработчиков релизы выходят не 1 раз в 2 недели, а, например, 5 раз в день, им надо оперативно понимать, работает приложение или нет, иначе они запутаются и не смогут оперативно найти проблему. 12 шагом мы позволяем узнавать, работает приложение или нет, за 5 минут после запуска.

13. Feedback

Вам будет необходимо постоянно мониторить ваше приложение. Соответственно, вам придется разговаривать с разработчиком о добавлении необходимой функции мониторинга внутрь приложения. Я бы советовал вам почитать про:

time series database
попробовать Prometheus
попробовать Graphite
InfluxDB

Сравнить их и посмотреть, что будет лучше для вашего проекта. Они все работают немного по-разному и по-разному хранят данные. Например, с Graphite вам придется использовать StatsD, потому что Graphite в диапазоне меньше 1 секунды. В InfluxDB вы столкнетесь с тем, что вам придется настраивать различные сборщики.

Главная задача в 13 пункте - подключить ваше приложение к мониторингу.

14. Добавляем и улучшаем мониторинг.

Попробуйте такие сервисы, как:

pagerduty
slack
opsgenie

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

15. Переключаемся на Docker - на новую абстракцию.

К 15-му шагу у вас должен получиться жирный Pipeline:

ваш код хранится в Git-репозитории;
вы его автоматически собираете, тестируете;
разворачивается новое окружение;
прогоняете smoke-тесты;
прогоняете нагрузочное тестирование;
выкладываете его в продакшн.

На 15-м шаге можно все это забыть и переключиться на Docker - новую абстракцию. На этом шаге придется изучить Docker file. Что такое Docker образы, как их собрать. Основная задача на этом шаге - написать Docker file для вашего приложения, чтобы собирался образ и выкатывался в registry.

16. Docker compose и системы оркестрации

Необходимо почитать про Docker compose - как поднимать и объединять несколько контейнеров в один, чтобы вы, например, могли поднимать для своего окружения базу данных или redis для кэширования.

После чего стоит посмотреть в сторону систем оркестрации. Что они делают? Можно посмотреть swarm или Kubernetes. Kubernetes сейчас популярен, но достаточно сложен в изучении.

17. Переделываем весь наш pipeline и переводим его на Docker.

С помощью Jenkins, Teamcity или Gitlab CI (любой инструмент, который вы выбрали в начале) собираем ваше приложение в Docker контейнер.
Закидываем получившийся образ в Docker registry.
Запускаем этот образ на системе оркестрации Kubernetes.
Прогоняем на нем smoke-тесты, нагрузочное тестирование.
Деплоим в продакшн.

По окончанию этих 17 шагов у вас должен получиться pipeline - полностью автоматический, с помощью которого ваше приложение попадает от разработчика к конечному пользователю, минуя такие этапы, как сборка, тестирование, нагрузочное тестирование, развертывание новых сред и т. д.

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

Необходимый минимум для работы DevOps-инженером (по данным hh.ru)

Docker
Git
Python
Bash
Linux

Также растет спрос на Microsoft Azure и Kubernetes.

Как видите, вся эта история завязана на практике. Потому что теоретического материала в интернете более, чем достаточно. А вот практических кейсов нет и не совсем понятно, как научиться и какие задачи перед собой ставить, потому что можно начать выдумывать себе задания, но в реальной жизни, на проектах, они будут абсолютно не нужны.