В этой статье мы расскажем, как настроить отдельные стадии, составляющие эталонный цикл 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
с опубликованными артефактами релиза.