Создайте один раз CI, разверните несколько раз для современных веб-приложений, используя Docker, Kubernetes и Spinnaker. | Мохит Ядав | декабрь 2020 г.

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

Диаграмма.jpg

На приведенной выше диаграмме, как вы можете видеть, у нас есть следующие компоненты

Система контроля версий, например Github/Gitlab/Bitbucket.
Конвейер непрерывной интеграции, т. е. Jenkins, Travis CI, CircleCI (предварительно настроенный с помощью Docker).
Реестр контейнеров, то есть реестр контейнеров Amazon ECR/ Azure.
Один или несколько конвейеров непрерывного развертывания в зависимости от вашей инфраструктуры, эти конвейеры должны иметь агента, который подписан на реестр контейнеров (Спинакер рекомендуется, если вы используете кластер Kubernetes).

Чтобы понять этот шаблон:

Данный: у нас есть приложение под названием Lucifer, которое сейчас работает на версии 1.1.0 на стадии подготовки и производства.

Цель: Чтобы развернуть новую функцию, сохраните Lucifer в промежуточной стадии -> контроль качества. Эта функция -> разверните в рабочей среде, если контроль качества прошел успешно.

Предположения: Наша основная ветка — это master, и мы хотим избежать множественных сборок, потому что модульный тест + lint занимает более 30 минут, а также мы хотим избежать отправки отдельных образов для подготовки и производства.
Для достижения вышеуказанной цели мы можем сделать шаг назад и разбить проблему на 2 части.

Создайте приложение.
Запустите приложение.

Создание приложения

Для нашего сценария мы хотим построить Lucifer, что означает, что когда функция объединяется с основной веткой, мы запускаем конвейер CI, который запускает тесты + линтер и проверки качества кода, и в случае успеха он создает образ докера, помеченный как lucifer-v1.2.0 с тегом save-lucifer.

Один известный подход, который я использовал в прошлом для CI, был:

Сделайте 2 ветки git staging и master, здесь это будет означать запуск CI Pipeline 2 раза и отправку изображений lucifer-v1.2.0-stg при слиянии кода с staging и lucifer-v1.2.0-prod при слиянии кода с master.
Хотя описанный выше подход кажется довольно интуитивным и простым, подход с Build one CI имеет перед ним множество преимуществ.

Мы всегда создаем функцию один раз, даже если у нас есть несколько сред, таких как промежуточное тестирование или производство, что экономит ресурсы CI и время сборки для разных сред.
У нас всегда есть один образ для каждой функции в реестре докеров, поэтому мы экономим затраты на хранение, а также упрощаем стратегию отката и управления версиями.
Кроме того, мы избегаем проблем с управлением версиями зависимостей, поскольку наш образ докера всегда будет содержать одну и ту же сборку с одной и той же версией зависимых пакетов (это очень важно, поскольку иногда некоторые пакеты неосознанно вносят критические изменения, что приводит к критическим изменениям, если у нас есть отдельные сборки).
Если мы создадим разные образы для каждой среды, то нет гарантии, что образы «достаточно похожи», чтобы убедиться, что они ведут себя одинаково. Это также открывает множество возможностей для злоупотреблений, когда разработчики/операторы встраивают дополнительные инструменты отладки в непроизводственные образы, создавая еще больший разрыв между образами для разных сред.

Двигаясь дальше, после сборки lucifer-v1.2.0 мы отправляем его в реестр докеров, например Amazon ECR/Azure Container Registry, где он находится вместе с lucifer-v1.1.0.
Основной мотив для выполнения этого шага — разделить поток CI и CD, а также поддерживать версии нашего приложения в случае откатов.

Запуск/развертывание приложения

Следующим шагом нашей задачи является развертывание нашей новой функции lucifer-v1.2.0.
Обычно этот шаг должен быть отделен от шага CI, и один из способов добиться этого — использовать агент, который подписывается/опрашивает реестр контейнеров. Если вы используете Kubernetes, то Spinnaker весьма полезен.

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

Таким образом, в нашем случае мы можем определить стратегию для наблюдения за изменениями версии в lucifer и 2 конвейера, один для промежуточной установки, а другой для производства, промежуточный конвейер будет иметь триггер для развертывания в Kubernetes, как только будет опубликован новый образ, но для производственный конвейер, мы можем установить ручной триггер, который ожидает, пока QA/Business-менеджер развернет эту функцию, как только она будет проверена QA на стадии подготовки.

Таким образом, как только реестр контейнеров получает образ lucifer-v1.2.0, агент спинакера запускает промежуточный конвейер и развертывает приложение в кластере Kubernetes, где его можно подвергнуть контролю качества. После прохождения контроля качества бизнес-менеджер может запустить производство. конвейер, и образ lucifer-v1.2.0 будет развернут в рабочей среде за считанные секунды.

Этот процесс довольно прост и интуитивно понятен благодаря таким инструментам, как Spinnaker, Docker, Kubernetes.

Вкратце плюсы такого подхода:

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