[Перевод] Kubernetes и CI/CD пайплайн

image-loader.svg

Сегодня мы поговорим об Azure DevOps и процессах непрерывной интеграции/развертывания.

Можно использовать множество функций, которые интегрированы с Azure DevOps. Если подходить ко всему «как к коду» для развертывания, то вместо классического Azure DevOps в качестве решения можно применить Azure DevOps yaml deployment. В этом примере будет рассказано о шагах по развертыванию в среде kubernetes.

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

image-loader.svg

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

Рассмотрим создание шаблона Helm и установку стандартов в отдельной статье.

Мы создаем файл deployment.yaml в Azure DevOps.

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

image-loader.svg

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

image-loader.svg

Мы подготовили этапы для работы в созданном нами пайплайне yaml.

Прежде всего, настроили наши приложения, которые были собраны в соответствии с их dockerfile, на прохождение следующих этапов.

image-loader.svg

Этапы:

  1. Сборка

  2. Внедрение в разработку

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

  4. Тест на откат последней версии в случае неудачи

  5. Если тестирование конечной точки прошло успешно, продолжается развертывание в продакшн

  6. Тестирование конечной точки в продакшн

  7. Откат в случае неудачи

image-loader.svg

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

image-loader.svg

Этап, на котором создаются наши файлы манифеста;

image-loader.svg

Артефакты, созданные в процессе сборки, перемещаются по этапам в средах.

image-loader.svg

Наше развертывание завершено, и мы перешли к этапу тестирования.

image-loader.svg

Для этого примера мы использовали Postman, а тесты конечных точек запускали с помощью newman в командной строке. Если наши тесты не сработают, следующий шаг автоматически откатит обратно последнее успешное развертывание для этой среды.

image-loader.svg

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

Итак, что нам делать, если он успешен:

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

image-loader.svg

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

image-loader.svg

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

image-loader.svg

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

«Закон Вирта: Программное обеспечение становится более медленным быстрее, чем аппаратное обеспечение становится более быстрым»

Материал подготовлен в рамках курса «Инфраструктурная платформа на основе Kubernetes».

Всех желающих приглашаем на demo-урок «Шаблонизация манифестов. Helm и его аналоги». На этом бесплатном уроке будем шаблонизировать манифесты Kubernetes разными способами. Установим и посмотрим, как использовать community Helm charts. Создадим собственные Helm chart. Узнаем, как использовать альтернативные подходы к шаблонизации — jsonnet-ориентированные решения и Kustomiz. >> регистрация

© Habrahabr.ru