Используйте эфемерные среды для приемочного тестирования, тестирования на проникновение, сквозного тестирования или нагрузочного тестирования.
В этом посте я хочу продемонстрировать, как настроить эфемерные среды для запросов на вытягивание, созданных на GitHub. Это можно применить к любому SCM, поддерживаемому генератором запросов на вытягивание Argo CD. Не существует одного способа и одного набора инструментов для реализации такого рода функций.
Я буду использовать две разные разновидности Kubernetes в качестве среды запросов на вытягивание: первая — это пространства имен Kubernetes, а вторая — виртуальные кластеры Kubernetes, которые могут обеспечить лучшую изоляцию.
Используемые инструменты
- Генератор запросов на вытягивание Argo CD: Генератор запросов на вытягивание Argo CD — это один из генераторов приложений, реализованных для наблюдения за вашим SCM на наличие новых запросов на вытягивание, а затем для создания необходимых определений приложений в соответствии с этими запросами на вытягивание.
- Действия Github: действия Github используются для части CI этой функции. Всякий раз, когда генерируется новый запрос на вытягивание, запускается действие Github, которое создает и отправляет образ контейнера для функциональной ветки запроса на вытягивание.
- Vcluster: Vcluster используется для части виртуального кластера Kubernetes этой функции. Это отличный инструмент, разработанный Loft Labs поверх любого из K3S, K0S или vanilla K8S. Для этой демонстрации я пробовал K3S и K0S. Из-за проблем, с которыми я столкнулся при установке K3S, окончательная версия зависит от K0S.
- ArgoCD Secret Synchronizer: Пользовательский оператор, разработанный мной для экспериментальных целей, который синхронизирует секреты, созданные Vcluster, с секретами Argo CD Cluster. При использовании этого ручного вмешательства оператора отпадает необходимость, а созданный виртуальный кластер автоматически добавляется в список управляемых кластеров Argo CD.
В дополнение к вышеперечисленным вам необходимо иметь кластер Kubernetes с правами администратора (можно использовать Killercoda, см. раздел артефактов для примера сценария), репозитории Github для кода вашего приложения, диаграммы управления, Argo CD CRD и Argo CD. определения ресурсов приложения.
Репозитории Github
ephemeralenvironments: этот репозиторий git содержит CRD Argo CD, определения запросов на вытягиваниеapplicationsetи определения ресурсов секретного синхронизатора Argo CD. Все эти ресурсы управляются кастомизацией.kustomization.yamlфайлов можно увидеть в каждой папке.
Если вы хотите запустить этот пример, клонируйте этот репозиторий git и выполните две команды ниже:
kubectl apply -k ephemeralenvironments/managementstack/argocdkubectl apply -k ephemeralenvironments/managementstack/argocdapplications
Первый применяет CRD и ресурсы Argo CD к кластеру управления, указанному kubeconfig файлом, а второй создает applicationset определение, которое генерирует приложения Argo CD для пяти папок выше. Сценарий Killecoda создан для демонстрации этих шагов, если вы хотите им следовать.
2. ephemeralcluster:Этот репозиторий git содержит диаграмму управления для декларативного развертывания Vcluster. Существует определение applicationset, указывающее на этот репозиторий в каталоге pullrequests репозитория ephemeralenvironments выше.
3. app-ephemeraltest: этот репозиторий содержит пример кода приложения (простой dotnet API), файл докер-файла, диаграмму управления, определение действий GitHub для создания и отправки изображений для каждого запроса на вытягивание, а также образец запроса на вытягивание для демонстрации в примере сценария. Для этого примера используется ветка f-ephemeralpullrequest, и из этой ветки создается образец запроса на включение, который будет объединен с веткой main.
Генератор запросов на вытягивание
Генератор запросов на вытягивание – это один из генераторов шаблонов компакт-дисков Argo, который использует API-интерфейсы SCM для получения информации о запросах на вытягивание и создания необходимых определений приложений. По умолчанию контроллер applicationset опрашивает SCM API с 30-секундным интервалом, который при необходимости можно изменить. В дополнение к этому, если требуется, веб-перехватчик SCM также можно настроить для запуска контроллера applicationset, чтобы исключить это время ожидания.
Развертывание в виртуальном кластере
Генератор запросов на вытягивание, который используется для развертывания примера приложения в виртуальном кластере, приведен ниже:
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: sampleapps
namespace: argocd
spec:
generators:
- pullRequest:
github:
owner: a1tan
repo: app-ephemeraltest
requeueAfterSeconds: 120
template:
metadata:
name: 'sampleapp-{{branch}}-{{number}}'
spec:
source:
repoURL: 'https://github.com/a1tan/app-ephemeraltest.git'
targetRevision: '{{head_sha}}'
path: charts/sampleapp
helm:
parameters:
- name: "image.tag"
value: "pull-{{head_sha}}"
- name: "environment"
value: "PR-Vcluster-Dev"
project: default
destination:
server: https://cluster-{{branch}}-{{number}}.cluster-{{branch}}-{{number}}-namespace.svc.cluster.local
namespace: 'sampleapp-{{branch}}-{{number}}-namespace'
syncPolicy:
automated:
allowEmpty: true
prune: true
selfHeal: true
Этот генератор запросов на вытягивание прослушивает запросы на вытягивание в учетной записи Github «a1tan» и репозитории app-ephemeraltest.
Он также изменяет интервал опроса на 120 секунд, что может раздражать в реальном сценарии. Когда он обнаруживает новый запрос на вытягивание, он создает приложение с именем с шаблоном sampleapp-{{branch}}-{{number}}. Он возьмет последнюю фиксацию в этой ветке с targetRevision: ‘{{head_sha}} и путь с path: charts/sampleapp. Он также устанавливает тег изображения как pull-{{head_sha}}, который указывает на последний образ запроса на вытягивание, созданный конвейером Github Actions CI. Существует также еще один параметр helm, чтобы отличить это развертывание от версии namespace ниже.
Для назначения этот applicationset использует ссылку на кластер как server: https://cluster-{{branch}}-{{number}}.cluster-{{branch}}-{{number}}-namespace.svc.cluster.local, которая отличается от основного кластера kubernetes. Он применяет это приложение к вновь созданному эфемерному экземпляру виртуального кластера.
Этот экземпляр также развертывается генератором запросов на вытягивание ниже:
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: ephemeralcluster
namespace: argocd
spec:
generators:
- pullRequest:
github:
owner: a1tan
repo: app-ephemeraltest
requeueAfterSeconds: 120
template:
metadata:
name: 'cluster-{{branch}}-{{number}}'
spec:
source:
repoURL: 'https://github.com/a1tan/ephemeralcluster.git'
targetRevision: 'main'
path: charts/vcluster
helm:
parameters:
- name: "syncer.extraArgs[0]"
value: "--out-kube-config-server=https://cluster-{{branch}}-{{number}}.cluster-{{branch}}-{{number}}-namespace.svc.cluster.local"
- name: "syncer.extraArgs[1]"
value: "--tls-san=cluster-{{branch}}-{{number}}.cluster-{{branch}}-{{number}}-namespace.svc.cluster.local"
project: default
destination:
server: https://kubernetes.default.svc
namespace: 'cluster-{{branch}}-{{number}}-namespace'
syncPolicy:
automated:
allowEmpty: true
prune: true
selfHeal: true
В этом applicationset ссылка на сервер определений отличается, server: https://kubernetes.default.svc. Vcluster развертывается в пространстве имен в основном кластере. Он также имеет два параметра управления — out-kube-config-server и — tls-san, чтобы сделать созданный Vcluster доступным из экземпляра Argo CD.
Это приложение создает все ресурсы Vcluster в пространстве имен cluster-{{branch}}-{{number}}-namespace кластера main. Секрет, содержащий kubeconfig для доступа к этому экземпляру виртуального кластера, также создается в этом пространстве имен.
Оператор ArgoCDSecretSynchronizer берет этот kubeconfig и создает необходимый секрет кластера Argo CD. Таким образом, экземпляр Argo CD в основном кластере может управлять образцом приложения в виртуальном кластере.
Развертывание в пространстве имен
Существует также третье определение генератора запросов на вытягивание, которое используется для развертывания примеров приложений в пространстве имен в основном кластере.
Если вам нужно более простое решение и вы не хотите создавать виртуальный кластер для каждого запроса на вытягивание, вы можете использовать эту настройку.
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: sampleapps-ns
namespace: argocd
spec:
generators:
- pullRequest:
github:
owner: a1tan
repo: app-ephemeraltest
requeueAfterSeconds: 120
template:
metadata:
name: 'sampleapp-ns-{{branch}}-{{number}}'
# namespace: 'myapp-{{branch}}-{{number}}-namespace'
spec:
source:
repoURL: 'https://github.com/a1tan/app-ephemeraltest.git'
targetRevision: '{{head_sha}}'
path: charts/sampleapp
helm:
parameters:
- name: "image.tag"
value: "pull-{{head_sha}}"
- name: "environment"
value: "PR-Namespace-Dev"
project: default
destination:
server: https://kubernetes.default.svc
namespace: 'sampleapp-ns-{{branch}}-{{number}}-namespace'
syncPolicy:
automated:
allowEmpty: true
prune: true
selfHeal: true
Единственным отличием от другого образца определения applicationset является селектор сервера server: https://kubernetes.default.svc. С помощью этого селектора серверов образец приложения развертывается в пространстве имен sampleapp-ns-{{branch}}-{{number}}-namespace в кластере main. Параметр среды Helm также устанавливается по-другому, чтобы проверить, правильно ли развернуто приложение.
Советы
Следует иметь в виду одну вещь: если вы используете имя ветки в качестве имени службы в своей диаграмме управления, будьте осторожны со стратегией именования веток, это должно быть действительное DNS-имя. Таким образом, вместо именования feature/blabla вы можете предпочесть именование типа «f-blabla».
Вы можете найти ошибку, которую я получил из-за этой ошибки ниже.
Ограничения скорости Github также являются критической проблемой. Для первого запуска этого примера я использовал значение по умолчанию, равное 30 секундам. После слишком большого количества неудачных попыток синхронизации получена приведенная ниже ошибка ограничения скорости, после чего я увеличил период запроса до 120 секунд. Конфигурация веб-перехватчика является лучшим выбором для этих ограничений скорости.
Не забудьте использовать ${{ github.event.pull_request.head.sha }} в действиях github для фиксации запроса на вытягивание sha. Пометьте свой образ этим выражением, чтобы успешно получить определенный образ запроса на вытягивание на компакт-диске Argo.
Заключение
Создание сред запросов на вытягивание является важным шагом, если вы хотите, чтобы ваши функции соответствовали определению готовности перед слиянием с основной веткой.
Вы можете использовать эфемерные среды для приемочного тестирования, тестирования на проникновение, сквозного тестирования или нагрузочного тестирования. Управление зависимостями — еще одна важная проблема, которую мы не упомянули в этом посте.
Конечно, недостаточно развернуть простое приложение в среде. Это приложение имеет множество зависимостей, включая базу данных, таблицы базы данных, службу распределенного кэширования, хранилище ключей, поставщика удостоверений, брокера сообщений и даже другие службы в соответствии со сценарием, который мы хотим протестировать.
Все эти части должны быть определены таким образом, чтобы их можно было применить к этой эфемерной среде. Методы упаковки и инструменты также были определены для выполнения такого требования. В следующем посте я хочу более подробно остановиться на этой теме.
Артефакты
- Сценарий Киллеркоды
- Репозиторий Github для определений приложений
- Репозиторий Github для примера приложения
- Репозиторий Github для ресурсов Vcluster
