Код
#статьи

Что такое DevOps и зачем он нужен?

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

 vlada_maestro / shutterstock

Алексей Климин


Фронтенд, Бэкэнд, Админ, DevOps. Обожаю все оптимизировать и автоматизировать. Постоянно ищу новые технологии и способы их внедрения.


Ссылки


Что это за технология

Термин DevOps образован от английских слов development и operations. Это подход, методология и даже культура и философия процесса разработки, при котором программисты, тестировщики и системные администраторы могут работать над продуктом быстрее и эффективнее. Подход помогает снизить ошибки при передаче проекта от разработчиков к тестировщикам и сисадминам и наладить между ними взаимодействие. В основе лежит идея, что разработка, тестирование и эксплуатация цифровых продуктов — это единый, бесшовный и циклический процесс.

Сама по себе тема DevOps довольно объемная. Это автоматизация процессов подготовки инфраструктуры как для разработки, так и для тестирования приложения, а также для его эксплуатации. Сюда же входят автоматизация деплоя и мониторинг.

Наиболее ярко DevOps раскрывается при разработке приложения с применением микросервисной архитектуры1.

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

Проблемы при работе без DevOps

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

Много действий при передаче на тестирование

Разработчик устанавливает у себя на машине все необходимое: язык программирования, на котором будет вестись разработка, например PHP 7.0, базу данных, MySQL 5.7 и веб-сервер, Apache. Какая операционная система и какие версии библиотек и зависимостей будут установлены на сервере, неизвестно.

После того как нужная функциональность приложения реализована, требуется ее протестировать.

Программист упаковывает в архив свой код, копию базы данных, информацию о требуемом ПО и инструкцию по установке всего необходимого для запуска и работы приложения. После этого он передает архив тестировщику.

QA-специалист устанавливает все необходимое на тестовый стенд, разворачивает приложение и принимается тестировать.

Если в процессе тестирования появляется новая версия разработки, то приходится повторять процедуру. Разработчику нужно снова создать архив, передать тестировщику; а тому, в свою очередь, снова развернуть приложение.

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

Несовместимость версий в тестовой среде и на сервере заказчика

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

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

В итоге при использовании на продакшне другого веб-сервера приходится настраивать приложение заново. А это дополнительное время.

Как DevOps улучшает процесс разработки

У нас в digital-агентстве «Атвинта» я настроил процессы таким образом, что сборка проекта, запуск автотестов и деплой на тестовый сервер происходят автоматически, а на продакшн — полуавтоматически. Если какой-либо из этапов завершился неудачно, разработчик получит оповещение.

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

Для подготовки серверов используются инструменты наподобие Ansible. Они позволяют быстро настроить окружение, в котором приложение будет работать в автоматическом режиме. На это тратится несколько минут, а не несколько часов.

Для единообразия окружения используем инструмент Docker.

После того как разработчик сделал определенный функционал, он отправляет код в репозиторий. Там вступает в работу процесс, называемый Continuous Integration/Continuous Delivery — непрерывная интеграция и непрерывная доставка (далее CI/CD).

Если процесс сборки и автоматического тестирования прошел успешно, приложение разворачивается на тестовом сервере (staging server), где специалист по QA проводит ручное тестирование либо тестирование с применением инструментов вроде Selenium — для автоматизации действий веб-браузера в случае веб-приложения.

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

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

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

Инструментарий для DevOps

Разнообразие инструментов DevOps невероятно велико, так что я перечислю лишь некоторые из них, которые применяю в своей работе.

  • Управление конфигурацией серверов: Ansible, Chef, Puppet.
  • Для непрерывной интеграции и доставки (CI/CD): GitLab, Jenkins, TeamCity, Drone.
  • Сбор данных для мониторинга: Prometheus, Telegraf, LogStash.
  • Для отображения собранных данных: Grafana, Kibana, Zabbix.
  • Мониторинг ошибок: Sentry, Rollbar.

Ansible


Cистема управления конфигурациями, написанная на Python с использованием декларативного языка разметки (yaml) для описания конфигураций.

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

GitLab


Cистема контроля версий со встроенной CI/CD.

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

Для мониторинга нагрузки серверов используется довольно популярный стек: Grafana + InfluxDB + Telegraf.

Grafana


Это платформа с открытым исходным кодом для визуализации, мониторинга и анализа данных.

InfluxDB — база данных для хранения собранной статистики.

Telegraf — агент, который устанавливается на сервер и пересылает метрики, а также логи в базу InfluxDB.

Кому и для чего применять

  • Разработчикам. Позволит сконцентрироваться на коде приложения и не задумываться об инфраструктуре, которая будет на продакшне.
  • Тестировщикам. Предоставит больше простора в тестировании приложения на разных конфигурациях систем и с разным набором библиотек.
  • Системным администраторам. Снимет с них работы по развертыванию и мониторингу приложения.
  • Бизнесу в цифровой среде. Поможет быстрее адаптировать продукт под запросы рынка, выпускать новые версии и улучшать пользовательский опыт клиентов.

Применение методологии DevOps поможет наладить бизнес-процессы и ускорить выход обновлений.

Научитесь: Профессия Веб-разработчик Узнать больше
Понравилась статья?
Да

Пользуясь нашим сайтом, вы соглашаетесь с тем, что мы используем cookies 🍪

Ссылка скопирована