Настройка CI/CD | Argo CD | Построение процесса CI/CD | Go

В этой статье мы расскажем, как настроить отдельные стадии, составляющие эталонный цикл CI/CD:

Внимание! Необходимо предварительно настроить container registry и использовать во всех командах werf один и тот же параметр CONTAINER_REGISTRY.

Сборка и публикация образов

Собрать и опубликовать образы, описанные в werf.yaml, можно с помощью следующей команды:

werf build --repo CONTAINER_REGISTRY

Быстрое тестирование коммитов

Быстрое тестирование (unit-тесты или линтеры) можно запустить с помощью следующей команды werf (она запускает одноразовый контейнер с указанной командой TEST_COMMAND):

werf kube-run IMAGE_NAME -- TEST_COMMAND

При ее выполнении в контейнере в кластере Kubernetes будет выполнена указанная команда. IMAGE_NAME должно быть определено в werf.yaml — это может быть образ, собранный специально для таких тестов, или стандартный образ приложения.

Подготовка артефактов релиза

На этом этапе необходимо опубликовать бандл werf в container registry. Команда werf bundle publish автоматически убедится, что все необходимые образы собраны и опубликованы в container registry, и опубликует бандл как OCI-совместимый Helm-чарт с указанным тегом SEMVER:

werf bundle publish --repo CONTAINER_REGISTRY --tag SEMVER

Использование тегов SEMVER с OCI-совместимыми Helm-чартами обязательно на текущий момент (статические теги типа main / latest пока не поддерживаются). В зависимости от используемой модели CI/CD:

Если приложение выпущено под Git-тегами SEMVER, рекомендуется публиковать бандл под тем же тегом SEMVER.
Если приложение развертывается в production из главной ветки (автоматически из HEAD-коммита либо из вручную пользователем из некоторого коммита), рекомендуется публиковать бандл под искусственным тегом типа 0.0.${CI_PIPELINE_ID}. В данном случае CI_PIPELINE_ID — некоторая встроенная переменная CI/CD системы, которая представляет собой монотонно возрастающее число, идентифицирующее шаги CI/CD пайплайна для каждого Git-коммита.

Приемочное тестирование

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

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

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

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

В следующих разделах будет описано, как это можно сделать

Запуск с помощью werf converge

В случае, если специальный тест-Job выполняется в test-окружении как post-install Helm-хук, выполните следующую команду в Git worktree проекта:

werf converge --repo CONTAINER_REGISTRY --env test

Эта команда развернет production-идентичное окружение в пространстве имен Kubernetes PROJECT_NAME-test с релизом PROJECT_NAME-test и запустит сам тест с помощью post-install хука Job (может быть один или несколько Job’ов) с тестами. Также она автоматически соберет результаты тест-Job’а (или Job’ов) и завершит весь процесс в случае провала тестирования.

Для завершения работы тестового окружения воспользуйтесь командой dismiss:

werf dismiss --env test

Запуск с использованием артефакта релиза и werf

В данном случае команда werf bundle apply развертывает ранее опубликованный артефакт релиза.

В случае, если специальный тест Job выполняется в окружении test как post-install Helm-хук, выполните следующую команду:

werf bundle apply --repo CONTAINER_REGISTRY --env test --namespace TEST_NAMESPACE --release TEST_RELEASE

Обратите внимание, что для этой команды (в отличие от werf converge) не нужно указывать Git worktree проекта, иначе ее результаты и выходные данные будут такими же, что и у werf converge.

Переменные TEST_NAMESPACE и TEST_RELEASE должны быть указаны явно. Не забудьте удалить их после использования:

werf helm uninstall TEST_RELEASE -n TEST_NAMESPACE
kubectl delete ns TEST_NAMESPACE

Запуск с использованием артефакта релиза и Argo CD

Прежде всего необходимо создать специальный Application CRD Argo CD:

spec:
  destination:
    namespace: TEST_NAMESPACE
  source:
    chart: PROJECT_NAME
    repoURL: REGISTRY
    targetRevision: SEMVER

Для запуска тестов выполните следующую команду в CI/CD:

argocd app sync TEST_APPNAME --revision SEMVER

— где SEMVER — обычная версия или искусственный тег вроде 0.0.${CI_PIPELINE_ID} (см. подготовка артефактов релиза).

Развертывание в production

Настройка приложения Argo CD

Создавая Application CRD Argo CD, обратите внимание на следующие поля:

spec:
  destination:
    namespace: TEST_NAMESPACE
  source:
    chart: PROJECT_NAME
    repoURL: REGISTRY
    targetRevision: SEMVER

ПРИМЕЧАНИЕ. Bundle должен быть опубликован в формате werf bundle publish --repo REGISTRY/PROJECT_NAME --tag SEMVER и соответствовать параметрам, указанным в CRD. REGISTRY/PROJECT_NAME — адрес репозитория в container registry, который содержит опубликованный werf bundle в виде OCI-совместимого Helm-чарта.

Установите targetRevision на некоторую начальную загрузочную версию вашего приложения. В следующих разделах будет описано, как обновлять targetRevision при появлении нового релиза.

Развертывание вручную

Включите приведенную ниже команду в систему CI/CD. Она будет вызываться каждый раз, когда пользователь захочет вручную развернуть приложение в production:

argocd app sync APPNAME --revision SEMVER

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

Непрерывное развертывание

Непрерывное развертывание означает, что последний (latest) артефакт релиза, например, для ветки main, будет автоматически развернут в production-кластер Kubernetes.

Чтобы настроить непрерывное развертывание артефактов релиза, дополните Application CRD Argo CD следующими аннотациями:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  annotations:
    argocd-image-updater.argoproj.io/chart-version: ~ 0.0
    argocd-image-updater.argoproj.io/pull-secret: pullsecret:NAMESPACE/SECRET

Значение argocd-image-updater.argoproj.io/chart-version="~ 0.0" означает, что оператор должен автоматически развернуть чарт до последней версии патча в диапазоне SEMVER 0.0.*.

Также необходимо создать секрет NAMESPACE/SECRET (рекомендуется использовать секрет type: kubernetes.io/dockerconfigjson) для доступа к CONTAINER_REGISTRY с опубликованными артефактами релиза.