Объяснение CI/CD-конвейеров в Kubernetes

Kubernetes (другое название «K8s») — инструмент оркестрации контейнеров с открытым исходным кодом, который изначально разработала компания Google.

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

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

Так как Kubernetes изначально является инструментом оркестрации, позволяющим еще сильнее абстрагироваться от уровня контейнеров (например, Docker), он по своей сути «заточен» под автоматизацию.

Поэтому логично использовать Kubernetes как платформу для создания CI/CD-контейнеров, упрощая выполнение задач по управлению, сборке и тестированию приложения.

Немного о CI/CD

Традиционная разработка

Традиционную модель разработки можно поделить на несколько последовательных этапов, каждый из который довольно обширен:

• Продуктовый менеджер описывает желаемое поведение ПО и формализует требования к будущей реализации

• Команда разработки проектирует архитектуру ПО, пишет код и подготавливает все необходимое для модульного тестирования

• Инженеры-тестировщики проверяют созданное ПО с помощью ряда тестов исходя из ранее описанного желаемое поведение

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

Так как начало выполнения следующего этапа происходит строго после завершения выполнения предыдущего, у такого подхода возникает ряд существенных недостатков:

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

• Коммуникация между разными командами увеличивает задержки и тормозит разработку

• Время до выпуска минимально рабочей версии (или обновления к уже готовому ПО) довольно велико
  

DevOps и CI/CD

Конвейер CI/CD (непрерывной интеграции и непрерывного развертывания) — это последовательность автоматизированных этапов, через которые проходит ПО от старта разработки (как всего приложения, так и отдельного обновления) до развертывания на платформе пользователя.

До появления конвейеров CI/CD разработчики вручную встраивали новый код в приложение, а затем развертывали его на тестовых серверах. После одобрения тестировщиков разработчики также вручную переустанавливали обновленное приложение на рабочих серверах. Однако, это хорошо работало только с монолитными приложениями, когда частота развертывания составляла раз в несколько месяцев.

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

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

Поэтому конвейеры CI/CD (особенно в контексте DevOps-методологии) позволяют реализовать регулярное автоматическое обновление ПО по определенному триггеру — например, когда разработчик вносит изменения в код.

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

При таком подходе все этапы работы над ПО превращаются в короткие итерации, а написание кода имеет ряд дополнительных свойств:

• Система контроля версий (VCS)

• Стандартизация инструментов разработки и тестирования

• Стирание границ между отдельными командами разработчиков

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

Ручная поддержка Kubernetes

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

Тем не менее, есть несколько недостатков, связанных с ручным управлением Kubernetes:

• Конфигурация YAML-файлов, определяющих паттерн работы Kubernetes, сопряжена с периодическим возникновением ошибок (во многом из-за синтаксиса пробелов) — особенно когда существует несколько разных YAML-файлов под каждое конкретное приложение на Kubernetes.

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

• Ручное отслеживание истории изменений, выполнение откатов новых или старых развертываний (версий), особенно в большом проекте — довольно сложное занятие.

• Управление секретами членов команды в Kubernetes требует особой осторожности для исключения возможных утечек данных.
  

Автоматизация Kubernetes

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

Обозначим лишь самые основные аспекты (компоненты), необходимые для создания CI/CD-конвейеров на базе Kubernetes:

• Инструмент CI/CD. Универсальный (или в некоторых случаях специализированный) облачный (редко локальный) инструмент для реализации CI/CD-конвейеров. Инструмент должен иметь обширные возможности для настройки пайплайнов (например, за счет скриптинга) и коммуникации с внешними сервисами для чтения репозиториев, отправки уведомлений, выполнения тестов, загрузки медиа-ресурсов и т.д. Самыми популярными решениями являются GitHub CI/CD, GitLab CI/CD, Jenkins X.

• Контейнеризатор. Инструменты контейнеризации (например, Docker) помогают инкапсулировать друг от друга отдельные функциональные компоненты приложения, тем самым предотвращая хаос внутри инфраструктуры.

• Кластеры. Набор связанных между собой контейнеров (узлов), объединенных в кластер Kubernetes, автоматически развертывается (и запускается) после того, как CI/CD-инструмент выполнит все этапы сборки, тестирования и деплоя.

• Тесты. Библиотеки или фреймворки для модульного тестирования и проверка синтаксиса кода. Инструмент автоматического тестирования — один из основных компонентов CI/CD, который обеспечивает стабильную сборку с высоким качеством кода.

• Система контроля версий (VCS). Позволяет создавать «слепки» удачных состояний кодовой базы и выполнять отказы в случае ошибок. К тому же контроль версий позволяет разворачивать стабильные версии приложения в других окружениях.

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

1. Написание кода

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

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

Возможные инструменты:

• GitHub. Облачный сервис для хранения и управления Git-репозиториями.

• GitLab. Аналогичный GitHub, но с рядом отличий, облачный сервис для удаленных репозиториев Git.

• BitBucket. Еще одно облачное хранилище для репозиториев Git, разработанное и поддерживаемое компанией Atlassian.

2. Сборка

После внесения изменений в репозиторий автоматически запускается процесс сборки.

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

Возможные инструменты:

• GitHub CI/CD. Облачный сервис организации DevOps от GitHub.

• GitLab CI/CD. Облачный сервис организации DevOps от GitLab.

• Jenkins X. Облачный сервис для организации CI/CD-конвейеров в Kubernetes, представленный в виде расширяемого сервера.

• Apache Maven. Инструмент автоматизации сборки, используемый для проектов Java, а также C#, Ruby, Scala и некоторых других языков.

• Argo CD. Инструмент непрерывной доставки, специально созданный для Kubernetes, который устанавливается в качестве контроллера и отслеживает состояние приложения — различия между удаленным репозиторием и локальной системой контроля версий.
  

3. Тестирование

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

• Модульные тесты гарантируют, что небольшие фрагменты кода (модули или функции) работают правильно

• Интеграционные тесты проверяют, насколько общая логика приложения (построенная на функциях, которые тестируются в модульных тестах) корректна и бесперебойна.

Кстати, на этом этапе DevOps-специалисты могут дополнительно проводить 2 дополнительных анализа:

• Статическое тестирование безопасности приложения (SAST)

• Динамическое тестирование безопасности приложения (DAST)

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

Возможные инструменты:

• JUnit. Среда модульного тестирования для языка программирования Java, которая подключается как JAR-файл во время компиляции приложения.

• Selenium. Инструмент для для тестирования web-приложений с помощью записи действий пользователя внутри браузера.
  

4. Развертывание

Готовый и протестированный образ контейнера извлекается из репозитория и развертывается в кластере Kubernetes, который работает либо в тестовой, либо в производственной среде.

Развертывание образа в рабочей среде является «выпуском» — приложение начинает работать в среде конечного пользователя.

В отличие от монолитных приложений, развертывание многокомпонентного (с множеством сервисов) приложения является, наверное, наиболее сложной частью в Kubernetes.

Для этого есть ряд причин:

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

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

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

Возможные инструменты:

• Kubectl. Инструмент командной строки для взаимодействия с кластерами Kubernetes.

• Helm Charts. Своего рода пакетный менеджер для Kubernetes, через который можно делиться и обмениваться ресурсами.

• Timeweb Cloud Kubernetes. Облачное решение, которое позволяет реализовать отдельный кластер Kubernetes для сборки, тестирования и развертывания приложения, а также реализации DevOps-подходов в разработке.

Полезные практики CI/CD в Kubernetes

Унификация через GitOps и IaC

GitOps — это подход организации проекта, при котором Git-репозиторий используется как единственный источник определения всей инфраструктуры проекта.

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

В итоге определение проекта выглядит лаконично и имеет мало внешних зависимостей, а запуск CI/CD-конвейера на основе данных из Git имеет множестве преимуществ с точки зрения совместной работы и простоты использования.

GitOps — это частный случай DevOps, который фокусируется на использовании репозиториев Git для управления и развертыванием кода инфраструктуры приложения.

Основное различие в том, что в GitOps источником информации о развертывании является репозиторий Git, а в DevOps — файлы конфигурации приложения.

Вот ряд основных принципов GitOps:

• Декларативность. Определение инфраструктуры описывается исключительно в декларативном стиле.

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

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

Использование пакетного менеджера

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

Например, Helm Charts многократно упрощает управление пакетами, которые называются «чартами» («chart»).

Полезными решениями также могут стать:

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

• Kustomize. Декларативно конфигурирует приложение Kubernetes без задействования шаблонов, тем самым упрощая развертывание и использование инфраструктуры.

Дополнительное тестирование контейнеров

Тестирование всех новых образов контейнера очень важно для выявления багов и предотвращения потенциальных сбоев в рабочей среде.

При этом запущенные из образа контейнеры должны иметь ожидаемое содержимое и поведение.

Заключение

Конвейеры CI/CD улучшают процесс доставки ПО за счет автоматизации ключевых этапов разработки — сборки, тестирования, анализа безопасности, развертывания, получения обратной связи.

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

При этом вы получите наибольшую отдачу при использовании CI/CD, если выберите правильный набор инструментов для конкретно вашей команды или проекта.

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