Учебное пособие по DevOps: Docker, Kubernetes и Azure DevOps

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

Вы узнаете

• Что такое Docker, Kubernetes и Azure DevOps
• Что такое DevOps и зачем он нам нужен?
• Чем DevOps отличается от Agile?
• Какие важные инструменты DevOps?
• Как Docker помогает DevOps?
• Как Kubernetes помогает DevOps?
• Как Azure DevOps помогает DevOps?
• Что такое Непрерывная Интеграция и Непрерывная Доставка (CI/CD)?
• Что такое Инфраструктура как Код?
• Как Terraform и Ansible помогают DevOps?

Docker

Docker — это инструмент с открытым исходным кодом, который используется для создания, тестирования и развертывания контейнеризированных приложений. Кстати, что такое Контейнеризация? Контейнеризация — это концепция объединения всех библиотек и файлов вместе с кодом приложения в единое целое, называемое “Контейнер”, чтобы оно могло работать на любой инфраструктуре.

Kubernetes

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

Азур ДевОпс – это продукт компании Microsoft, предоставляющий широкий спектр инструментов и функций, которые ускоряют и систематизируют процесс разработки и развертывания программного обеспечения. Он предлагает набор процессов, позволяющих разработчикам программного обеспечения, менеджерам проектов и другим участникам работать вместе над разработкой программного обеспечения. Его можно добавить к существующим редакторам или средам разработки, чтобы команда могла эффективно работать над проектами любого размера.

Давайте начнем с простого примера.

Бесплатные курсы – Учись за 10 шагов

• Учим Docker за 10 шагов
• Учим Kubernetes за 10 шагов
• Учим AWS за 10 шагов

Что такое DevOps?

Как и со многими модными терминами в сфере разработки программного обеспечения, нет общепринятого определения для DevOps.

Определения могут быть простыми, как нижеприведенное, или сложными, распространяющимися на целую страницу книги.

DevOps – это комбинация культурных философий, практик и инструментов, которая повышает способность организации поставлять приложения и услуги с высокой скоростью – Amazon Web Services (AWS)

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

Модель Waterfall

Модель Waterfall – это методология, следующая структурированному подходу. Она состоит из шести фаз: Требования, Проектирование, Реализация, Тестирование, Развертывание и Обслуживание. Каждая фаза строится на завершении предыдущей. Процесс прогрессирует через эти этапы без повторения более ранних процессов, что делает его линейным.

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

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

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

Ключевые элементы для создания отличного программного обеспечения

Пока мы работали в модели “водопада” несколько десятилетий, мы поняли несколько ключевых элементов в разработке отличного программного обеспечения:

• Коммуникация
• Обратная связь
• Автоматизация

Важность коммуникации

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

В модели “водопада” мы старались улучшить коммуникацию, подготавливая документы на 1000 страниц о требованиях, дизайне, архитектуре и развертывании.

Однако со временем мы обнаружили, что:

• Лучший способ улучшить коммуникацию в команде – это собрать их вместе. И объединить разнообразные навыки в одной команде.
• Команды с кросс-функциональными навыками – с широким спектром умений – работают отлично.

Важность ранней обратной связи

Получение быстрой обратной связи важно. Создание отличного программного обеспечения – это в основном получение быстрой обратной связи.

• Мы строим приложение, которое соответствует бизнес-ожиданиям?
• Будут ли проблемы с вашим приложением, если его развернуть в продакшн?

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

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

Важность автоматизации

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

Поняв ключевые элементы для разработки отличного программного обеспечения, давайте рассмотрим, как мы эволюционировали к Agile и DevOps.

Эволюция к Agile

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

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

Вместо того чтобы тратить недели или месяцы на каждый этап разработки, Agile сосредотачивается на том, чтобы за несколько дней, а иногда и в течение одного дня, пройти малые требования, называемые пользовательскими историями, через цикл разработки.

Как Agile улучшил коммуникацию между командами?

Agile объединил бизнес и команды разработки.

• Бизнес отвечает за определение того, что нужно создать. Каковы требования?
• Разработка отвечает за создание продукта, который соответствует требованиям. В разработку входят все, кто участвует в проектировании, кодировании, тестировании и упаковке вашего программного обеспечения.

В методологии Agile представитель бизнеса, называемый Владельцем Продукта, всегда присутствует в команде, и команда четко понимает бизнес-цели.

Когда команда разработки не понимает требования и идет по неправильному пути, Владелец Продукта помогает им изменить курс и оставаться на правильном пути.

Результат: окончательный продукт, который команда создает, – это то, что хочет бизнес.

Еще одним важным фактором является то, что у гибких команд есть кросс-функциональные навыки: навыки программирования (фронтенд, API и базы данных), навыки тестирования и бизнес-навыки. Это способствует улучшению коммуникации между людьми, которым приходится работать вместе для создания отличного программного обеспечения.

Гибкие методы и автоматизация

На какие области автоматизации сосредотачиваются гибкие команды?

Программные продукты могут иметь различные дефекты:

• Функциональные дефекты означают, что продукт не работает, как ожидалось.
• Технические дефекты делают обслуживание программного обеспечения сложным. Например, проблемы с качеством кода.

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

Гибкие команды также акцентируют внимание на качестве кода. Инструменты, такие как SONAR, используются для оценки качества кода приложений.

Достаточно ли иметь отличные автоматизированные тесты и проверки качества кода? Ключевым моментом является частое запускание этих процессов. Команды Agile акцентируют внимание на Continuous Integration, где коммиты в систему контроля версий запускают цепочку действий. Это включает выполнение модульных тестов, автоматизированных тестов и проверок качества кода, все это без прерываний интегрировано в процесс Continuous Integration Pipeline. Jenkins, широко используемый инструмент CI/CD в начале эпохи Agile, сыграл ключевую роль в оркестрации этих автоматизированных процессов.

Как Agile содействовал моментальной обратной связи?

Самым важным фактором является то, что бизнесу не нужно ждать месяцами, чтобы увидеть конечный продукт. В конце каждого спринта продукт демонстрируется всем заинтересованным сторонам, включая архитектурные и бизнес-команды. Все отзывы учитываются с приоритетом на пользовательские истории для следующего спринта. Результат: конечный продукт, который создаёт команда, — это то, чего хочет бизнес.

Ещё одним важным фактором, позволяющим получить моментальную обратную связь, является непрерывная интеграция. Предположим, что я коммичу некоторый код в систему контроля версий. В течение 30 минут я получу обратную связь, если мой код вызывает сбой модульного теста или интеграционного теста. Я получу отзыв, если мой код не соответствует стандартам качества кода или не имеет достаточного покрытия кода в модульных тестах.

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

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

Но останавливается ли эволюция? Нет.

Появились новые вызовы.

Эволюция архитектур микросервисов

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

Каков был новый вызов?

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

Пришло время для нового модного слова в разработке программного обеспечения. DevOps.

Возникновение DevOps

На чем был сосредоточен DevOps?

Основное внимание DevOps было направлено на улучшение коммуникации между командами разработки и эксплуатации.

• Как мы можем упростить развертывание?
• Как мы можем сделать работу команды операций более видимой для команды разработки?

Как DevOps улучшил коммуникацию между командами?

DevOps сблизил команды эксплуатации с командами разработки.

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

На каких областях автоматизации сосредоточены команды DevOps?

В дополнение к областям фокуса Agile — непрерывной интеграции и автоматизации тестирования — команды DevOps были сосредоточены на помощи в автоматизации нескольких задач команды эксплуатации, таких как provision серверов, настройка программного обеспечения на серверах, развертывание приложений и мониторинг производственных сред. Некоторые ключевые термины — это непрерывное развертывание, непрерывная поставка и инфраструктура как код.

Непрерывное развертывание заключается в том, чтобы постоянно развертывать новую версию программного обеспечения в тестовых средах. В еще более зрелых организациях, таких как Google и Facebook, непрерывная поставка помогает постоянно развертывать программное обеспечение в производственной среде — возможно, сотни развертываний в день.

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

Как DevOps способствовал немедленной обратной связи?

DevOps объединяет команды операций и разработки. Поскольку операции и разработка являются частью одной команды, вся команда понимает проблемы, связанные с операциями и разработкой.

• Любые оперативные проблемы быстро привлекают внимание разработчиков.
• Любые трудности с запуском программного обеспечения получают раннее внимание со стороны команды операций.

DevOps способствует непрерывной интеграции, непрерывной доставке и инфраструктуре как коду.

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

Я рассматриваю Agile и DevOps как две фазы, которые помогают нам улучшить процесс создания отличного программного обеспечения. Они не конкурируют друг с другом, а вместе помогают нам создавать удивительные программные продукты.

Что касается меня, то цель совместной работы Agile и DevOps заключается в том, чтобы делать вещи, которые:

• Содействуют общению и обратной связи между бизнесом, командами разработки и операциями.
• Упрощают решение проблем с помощью автоматизации.

История DevOps

Вот пример истории:

• Вы звёздный разработчик в команде, и вам нужно быстро сделать исправление.
• Вы переходите к репозиторию на GitHub.
• Вы быстро проверяете проект.
• Вы быстро создаете свою локальную среду.
• Вы вносите изменения. Вы тестируете это. Вы обновляете модульные и автоматизированные тесты.
• Вы фиксируете изменения.
• Вы получаете электронное письмо с сообщением, что это развернуто в QA.
• Некоторые интеграционные тесты автоматически запускаются.
• Ваша команда QA получает электронное письмо с просьбой об одобрении. Они проводят ручное тестирование и одобряют.
• Ваш код становится активным в продакшене через несколько минут.
• Вы можете подумать, что это идеальный сценарий. Но знаете ли вы, что именно это происходит в инновационных компаниях, таких как Netflix, Amazon и Google, день за днем?

Это история DevOps.

DevOps = Разработка + Операции

DevOps — это естественная эволюция разработки программного обеспечения. DevOps — ЭТО НЕ ТОЛЬКО инструмент, рамка или просто автоматизация. Это сочетание всего этого.

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

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

У них были разные цели.

• Цель команды разработки — как можно больше новых функций вывести в продакшен.
• Целью команды операций было обеспечить наиболее стабильную рабочую среду.

Как видите, если выкладывать продукт в продакшн сложно, разработка и операции не согласованы.

DevOps нацелен на согласование целей команд разработки и операций.

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

Как это можно сделать? Разрушьте стену между разработкой и операциями!

Объединение Разработки и Операций

Вариант 1

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

Вариант 2

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

Вот несколько вещей, которые можно сделать:

• Заставьте команду разработки разделить некоторые обязанности команды операций. Например, команда разработки может взять на себя ответственность за новые релизы в первую неделю после выпуска в продакшн. Это поможет команде разработки понять проблемы, с которыми сталкиваются операции при выпуске новых релизов, и поможет им объединиться и найти лучшие решения.
• Еще одна вещь, которую можно сделать, – вовлечь представителя команды операций в мероприятия scrum. Включите его в стендапы и ретроспективы.
• Следующим шагом, который можно сделать, является повышение видимости проблем, с которыми сталкивается команда Операций, для команды Разработки. Когда возникают проблемы в операциях, вовлекайте команды разработки в работу над решениями.

Каким бы путем вы ни пошли, найдите способы преодоления барьера и объедините команды разработки и операций.

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

Практический случай использования DevOps

Рассмотрим нижеприведенное изображение:

Это изображение демонстрирует два простых рабочих процесса

1. Инфраструктура как Код с использованием Terraform и Azure DevOps для предоставления кластеров Kubernetes.
2. Непрерывное развертывание микросервисов с использованием Azure DevOps для сборки и развертывания образов Docker для микросервисов в кластерах Kubernetes.

Звучит сложно?

Давайте разберемся и попробуем их понять.

Начнем с #2 — Непрерывное Развертывание первым.

#2: Непрерывное Развертывание DevOps с использованием Azure DevOps и Jenkins

Для чего нужны отличные тесты и проверки качества кода, если вы их не запускаете часто?

Для чего нужна автоматизация развертывания, если вы не разворачиваете программное обеспечение достаточно часто?

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

• Модульные тесты
• Проверки качества кода
• Интеграционные тесты
• Упаковка приложений — создание разворачиваемой версии приложения. Инструменты — Maven, Gradle, Docker
• Развертывание приложений — запуск новых приложений или новых версий приложения в рабочем режиме
• Электронное письмо команде тестирования с просьбой протестировать приложение

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

Это называется непрерывным развертыванием. Если вы постоянно разворачиваете до производства, это называется непрерывной поставкой.

Наиболее популярные инструменты CI/CD — Azure DevOps и Jenkins.

#1: Инфраструктура DevOps как код с помощью Terraform

Ранее мы создавали среды и развертывали приложения вручную.

Каждый раз, когда вы создаете сервер, это нужно делать вручную.

• Версию программного обеспечения необходимо обновлять
• Патчи безопасности необходимо устанавливать вручную

Вы делаете это вручную, и вот какие результаты:

• Высокая вероятность ошибок
• Сложности с репликацией сред

Инфраструктура как код

Инфраструктура как код — относитесь к инфраструктуре так же, как к коду приложения.

Вот некоторые важные вещи, которые нужно понять об инфраструктуре как код:

• Команда инфраструктуры сосредотачивается на работе с добавленной стоимостью (вместо рутинной работы)
• Меньше ошибок и быстрая восстановимость после сбоев
• Серверы последовательно настроены (избегает расхождения в конфигурации)

Наиболее популярные инструменты IaC — Ansible и Terraform.

Обычно шаги в IaC следующие:

• Предоставление серверов (включено в облако) из шаблона
• Установка программного обеспечения
• Настройка программного обеспечения

Предоставление серверов

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

С помощью Terraform вы можете предоставлять серверы и остальную часть вашей инфраструктуры, такую как балансировщики нагрузки, базы данных, сетевые настройки и т.д. Вы можете создавать серверы, используя заранее созданные образы, созданные с помощью таких инструментов, как Packer и AMI (Amazon Machine Image).

Управление конфигурацией

Инструменты управления конфигурацией используются для:

• Установки программного обеспечения
• Настройки программного обеспечения

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

Роль Docker и Kubernetes в DevOps

В мире микросервисов несколько микросервисов могут быть созданы на Java, несколько на Python и несколько на JavaScript.

Разные микросервисы будут иметь разные способы создания приложений и развертывания их на серверах. Это усложняет работу команды операций. Как мы можем иметь схожий способ развертывания нескольких типов приложений? Здесь на помощь приходят контейнеры и Docker.

С помощью Docker вы можете создавать образы микросервисов — независимо от их языка. Вы можете запускать эти образы одинаково на любой инфраструктуре. Это упрощает операции.

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

Kubernetes также предоставляет:

• Обнаружение сервисов
• Балансировка нагрузки
• Централизованная конфигурация

Docker и Kubernetes делают DevOps простым.

Важные метрики DevOps

Ниже приведены некоторые из важных метрик DevOps, которые вы можете отслеживать и улучшать со временем.

• Частота развертывания — Как часто приложения развертываются в производственной среде?
• Время выхода на рынок — Сколько времени вам нужно, чтобы перенести функцию от кодирования до производства?
• Процент неудач новых релизов — Сколько из ваших релизов терпят неудачу?
• Время на исправления — Сколько времени вам нужно, чтобы сделать исправление в производственной среде и выпустить его?
• Среднее время восстановления — Сколько времени вы тратите на восстановление производственной среды после серьезной проблемы?

Лучшие практики DevOps

Гибкое управление проектами

Гибкое управление проектами — это итеративный подход к разработке программных приложений. Благодаря этой практике команды могут повысить скорость разработки и хорошо реагировать на изменяющиеся потребности клиентов. Гибкая методология отличается от традиционного метода “водопада”, в котором были долгие циклы релизов. Agile использует фреймворки Scrum и Kanban для доставки программного обеспечения в соответствии с потребностями клиента.

Использование правильного набора инструментов

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

Ниже приведены некоторые примеры инструментов, которые могут использовать инженеры DevOps, системные администраторы и другие заинтересованные стороны:

1. Инструменты, такие как Jira, могут помочь команде разделить задачи на более мелкие и управляемые части, что, в свою очередь, способствует повышению производительности команды.
2. Инструменты, такие как Jenkins и Bitbucket, могут помочь вам автоматизировать потоки кода, начиная с тестирования и заканчивая этапом развертывания.
3. Инструменты, такие как Slack, GetFeedback и др., могут помочь командам DevOps интегрировать чаты с платформами опросов для сбора и анализа обратной связи в реальном времени.

Непрерывная интеграция/Непрерывная доставка

Непрерывная интеграция (CI) и непрерывная доставка (CD) — это современные практики разработки программного обеспечения, которые помогают организациям быстро и эффективно поставлять программное обеспечение. С помощью CI разработчики постоянно коммитят код приложения в общий репозиторий несколько раз. С помощью CD код быстро и без проблем доставляется в продукцию. CD также обеспечивает интеграцию без задержек и сбоев.

Интеграция безопасности

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

Наблюдаемость

Наблюдаемость важна при разработке сложных приложений, использующих микросервисы и облачные архитектуры. Наблюдаемость помогает командам DevOps понять сложную структуру различных приложений (микросервисов, облачных приложений и т. д.) и помогает удовлетворить потребности будущей среды. Наблюдаемость Kubernetes и Splunk – одни из лучших платформ наблюдаемости.

Сигналы зрелости DevOps

Как измерить зрелость ваших реализаций DevOps?

• Время, затраченное на процесс разработки до развертывания, должно быть в целом удовлетворительным
• Определение частоты развертывания нового кода
• Среднее время восстановления (MTTR) после инцидента или неожиданного события должно быть как можно меньше
• Успешные развертывания должны превышать неудачные развертывания
• Быстрые и надежные релизы должны привести к высокому возврату инвестиций (ROI).

Лучшие практики трансформации DevOps

• Поддержка руководства критически важна
• Требует предварительных затрат
• Организуйте Центры Ответственности (COE), чтобы помочь командам
• Выберите правильное приложение и команду
• Начните маленькими шагами
• Обмен знаниями (новостные бюллетени, коммуникации, Центры Ответственности)
• Поощряйте людей с исследовательским и автоматизированным мышлением
• Признавайте команды DevOps