Polina_Averina 27 янв 2021 в 07:40

Создание современных процессов CI/CD для бессерверных приложений с Red Hat OpenShift Pipelines и Argo CD. Часть 2

17 мин

Блог компании СлёрмDevOps*IT-инфраструктура*Программирование*Системное администрирование*

Перевод

В первой части статьи я представил Tekton в качестве фреймворка для «облачных» пайплайнов CI/CD и Argo CD в качестве идеальной пары для GitOps в Red Hat OpenShift. Наша цель — создать законченный процесс непрерывной интеграции и доставки, который начнется при коммите в репозитории GitHub и завершится, когда новое приложение будет развернуто в Dev, Staging и Prod средах.

В первой части мы использовали Tekton для реализации задач непрерывной интеграции (CI). Теперь мы завершим процесс CI/CD, реализовав задачи непрерывного развертывания (CD) с помощью Argo CD. Давайте посмотрим на схему на Рисунке 1, чтобы освежить в памяти процесс CI/CD.

Рис.1. Пример процесса CI/CD.

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

Во второй части мы воспользуемся возможностями Argo CD для полной автоматизации процесса развертывания приложения. Argo CD извлекает все изменения из файлов Kustomize, которые были отправлены в репозиторий развертывания пайплайном CI, и синхронизирует эти изменения в целевых неймспейсах. На последнем этапе нашей автоматизации мы напишем Tekton Trigger, который запустит весь процесс CI/CD.

Начало работы с Argo CD

Argo CD сейчас набирает популярность. Будучи первоклассным представителем экосистемы Kubernetes, он упрощает освоение GitOps, где команды используют декларативные описания конфигурации и инфраструктуры из Git в качестве единственного источника истины. Мы уже разработали задачи Tekton для нашего процесса CI/CD. Может ли Argo CD стать тем идеальным компонентом, которого сейчас не хватает в нашем процессе?

Установка Argo CD

Откройте веб-консоль OpenShift и перейдите в неймспейс cicd к нашему демонстрационному процессу. Используйте следующий скрипт, чтобы установить Argo CD Operator:

$ ./bootstrap-argo.sh cicd
------------------------------
Installing argo operator
Release "argocd" does not exist. Installing it now.
NAME: argocd
LAST DEPLOYED: Thu Sep 10 18:37:23 2020
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

Как показано на Рисунке 2, вы должны теперь видеть новый Operator в неймспейсе cicd:

Рис. 2: Argo CD установлен в неймспейс проекта CICD.

Создание экземпляра Argo CD

Далее создадим экземпляр Argo CD. Этот экземпляр будет управлять всеми AppProjects и Applications, которые мы создали в неймспейсе cicd. Скрипты, приведенные ниже, создают следующее:

Экземпляр Argo CD в неймспейсе cicd.
AppProject под названием rh-developers.
Три приложения в AppProject rh-developers. Каждое приложение ссылается на репозиторий развертывания в ветке master. Приложения синхронизированы с папками development, staging и production соответственно.

Выполните следующее (не забудьте использовать собственный репозиторий quarkus-hello-world-deployment):

$ ./add-argo-apps.sh cicd rh-developers https://github.com/dsanchor/quarkus-hello-world-deployment.git master
----------------------------------------------------------------------------------------------------------------
Installing basic Argo CD server instance
argocd.argoproj.io/argocd created
Adding edit role to argocd-application-controller ServiceAccount in projects development, staging and production
rolebinding.rbac.authorization.k8s.io/edit-rh-developers-dev created
rolebinding.rbac.authorization.k8s.io/edit-rh-developers-staging created
rolebinding.rbac.authorization.k8s.io/edit-rh-developers-production created
Creating rh-developers AppProject in namespace cicd
appproject.argoproj.io/rh-developers created
Creating Applications in namespace cicd in rh-developers AppProject
application.argoproj.io/quarkus-hello-world-development created
application.argoproj.io/quarkus-hello-world-staging created
application.argoproj.io/quarkus-hello-world-production created

Пропишите маршрут для Argo CD, который вам нужен для доступа к главной панели управления Argo CD:

$ oc get routes argocd-server -n cicd
---------------------------------------
NAME            HOST/PORT                                             PATH   SERVICES        PORT    TERMINATION            WILDCARD
argocd-server   argocd-server-cicd.apps.ocp4.mydomain.com          argocd-server   https   passthrough/Redirect   None

Дождитесь, пока запустится сервер Argo CD, затем авторизуйтесь, используя свои данные OpenShift. И вуаля! Вы должны получить текущий статус ваших приложений, как показано на Рисунке 3.

Рис 3: Войдите в панель управления Argo CD для просмотра всех версий приложений и их соответствующих рабочих статусов.

Примечание: Вы можете заметить, что и приложение development, и приложение staging показывают свой статус как Synced, а приложение production — OutOfSync. Первые два сконфигурированы с активированной функцией автосинхронизации, а для production мы используем ручную конфигурацию.

Запуск первой версии приложения

В следующих нескольких разделах мы проведем пару ревизий нашего приложения quarkus-hello-world на этапах development, staging и production цикла развертывания. Информацию о приложении Quarkus, которое мы используем для этого примера, вы можете прочитать в первой части этой статьи.

Первая версия приложения в среде development

Кликните на приложение quarkus-hello-world-development и увидите, что каждый объект в этой версии был синхронизирован, как показано на Рисунке 4.

Рисунок 4: Кликните на версию приложения, чтобы проверить его рабочий статус.

То, что все объекты синхронизированы, означает, что первая версия приложения была успешно развернута. Теперь получите маршруты, чтобы мы могли иметь доступ к сервису (обратите внимание, что маршруты для сервисов Knative автоматически создаются в неймспейсе knative-serving-ingress):

$ oc get routes -n knative-serving-ingress | grep development
--------------------------------------------------------------
route-e387d9ca-9f1b-4c15-9b83-7bea4d2d290c-313361326363   quarkus-hello-world-development.apps.ocp4.mydomain.com                   kourier    http2   edge/Allow    None
route-e387d9ca-9f1b-4c15-9b83-7bea4d2d290c-613962613835   r9ce9024-quarkus-hello-world-development.apps.ocp4.mydomain.com          kourier    http2   edge/Allow    None

Команда get routes должна выдать, как минимум, два маршрута: основной маршрут (quarkus-hello-world-development.apps.ocp4.mydomain.com) и один для новой версии, которую мы только что развернули (r9ce9024-quarkus-hello-world-development.apps.ocp4.mydomain.com). Обратите внимание, что основной маршрут может иметь за собой несколько версий, но, поскольку это наше первое развертывание, за ним закреплена только одна.

Протестируем оба маршрута и посмотрим на результаты. Если ни один под не работает, это происходит, потому что Knative уменьшает размер неактивных подов. Первый запрос может занять больше времени, чем обычно, если приходится создавать под заново.
Добавьте /hello, затем используйте curl, чтобы протестировать эндпоинт:

$ curl http://quarkus-hello-world-development.apps.ocp4.mydomain.com/hello
hola dev! Yeap!

$ curl http://r9ce9024-quarkus-hello-world-development.apps.ocp4.mydomain.com/hello
hola dev! Yeap!

Теперь вы можете перейти в меню Serverless веб-консоли OpenShift, выбрать проект development и рассмотреть его, как показано на Рисунке 5.

Рис 5: Просмотрите проект development в меню OpenShift Serverless.

Первая версия приложения в среде staging

Снова зайдите в панель управления Argo CD и взгляните на приложение staging. Вы должны увидеть единственный файл ConfigMap, который показан на Рисунке 6.

Рис. 6: Посмотрим на приложение staging в панели управления Argo CD.

У нас есть только ConfigMap, потому что мы еще не создали kustomization.yaml. Возможно, вы помните из первой части статьи, что у нас есть файл под названием kustomization-REVISION.yaml. Чтобы синхронизировать изменения с файлом REVISION, нужно переименовать этот файл и отправить изменения в Git.
Перейдите в папку, где вы проверяли репозиторий развертывания и запустите:

$ git pull && \
mv staging/kustomization-r9ce9024.yaml staging/kustomization.yaml && \
git add  staging && git commit -m "Revision 9ce9024 is now active in staging" && \
git push

Подождите пару минут, чтобы Argo CD синхронизировал все изменения. Если не терпится, можно нажать Sync, чтобы версия автоматически запустилась в staging, как показано на Рисунке 7.

Рис. 7: Argo CD синхронизирует и развертывает изменения, которые вы только что внесли.

Точно так же, как мы делали с приложением development, получите маршруты и проведите несколько тестов

$ oc get routes -n knative-serving-ingress | grep staging
------------------------------------------------------------
route-fd38a613-ea42-4809-af13-cd02503980bf-346238393864   quarkus-hello-world-staging.apps.ocp4.mydomain.com                       kourier    http2   edge/Allow    None
route-fd38a613-ea42-4809-af13-cd02503980bf-623763373761   r9ce9024-quarkus-hello-world-staging.ocp4.mydomain.com              kourier    http2   edge/Allow    None

$ curl http://quarkus-hello-world-staging.apps.ocp4.mydomain.com/hello
hola staging! Yeap!
$ curl http://r9ce9024-quarkus-hello-world-staging.apps.ocp4.mydomain.com/hello
hola staging! Yeap!

Первая версия приложения в среде production

Теперь мы переносим приложение в производственную среду, где ещё не настроена автоматическая синхронизация. Таким образом, все объекты нашего приложения сейчас в состоянии OutOfSync, как показано на Рисунке 8.

Рис. 8: Объекты в среде production должны быть синхронизированы вручную.

Чтобы новая версия приложения стала доступна для синхронизации, нам нужно одобрить это вручную. Проведите те же самые действия, что и для приложения в staging:

$ git pull && \
mv production/kustomization-r9ce9024.yaml production/kustomization.yaml && \
git add production && git commit -m "Revision 9ce9024 is now ready to be sync in production" && \
git push

Через одну-две минуты вы увидите новые объекты, которые в данный момент помечены как OutOfSync, что видно на Рисунке 9.

Рис. 9: Добавьте новые объекты для текущего пересмотра и подтвердите действие на консоли Argo CD.

Если изменения совпадают с вашими ожиданиями, вы можете провести ручную синхронизацию, чтобы запустить новую версию в production. Нажмите кнопку Sync, и у вас, наконец, появится новая версия, которую можно тестировать. Этот этап показан на Рисунке 10.

Рис. 10: Нажмите кнопку Sync для синхронизации ваших изменений в текущей версии.

Теперь проведите несколько тестов production-маршрутов, используя ту же процедуру, которую вы использовали для циклов development и staging:

$ oc get routes -n knative-serving-ingress | grep production
------------------------------------------------------------
route-8c948175-70a8-4c1c-ae70-846aa3b2081f-643262313638   quarkus-hello-world-production.apps.ocp4.mydomain.com                    kourier    http2   edge/Allow    None
route-8c948175-70a8-4c1c-ae70-846aa3b2081f-663561353830   r9ce9024-quarkus-hello-world-production.apps.ocp4.mydomain.com           kourier    http2   edge/Allow    None

$ curl http://quarkus-hello-world-production.apps.ocp4.mydomain.com/hello
hola production! Yeap!
$ curl http://r9ce9024-quarkus-hello-world-production.apps.ocp4.mydomain.com/hello
hola production! Yeap!

Как показано на Рисунке 11, все приложения Argo CD сейчас синхронизированы.

Рис. 11: Все ваши объекты находятся на панели управления Argo CD.

Развертывание новой версии приложения

Давайте теперь посмотрим, что происходит при развертывании новой версии нашего приложения quarkus-hello-world. В этом случае мы просто снова запускаем пайплайн CI/CD с другим ID коммита. Заметьте: пока что мы продолжаем запускать пайплайн вручную. Мы установим вебхуки для пайплайнов в последнем разделе статьи.
Перейдите в репозиторий rh-developers-cicd и запустите пайплайн, используя следующие параметры:

$ cat tekton/pipelines/knative-pipeline-run.yaml | \
  SOURCE_REPO=https://github.com/dsanchor/quarkus-hello-world.git \
  COMMIT=c076ee940b1f1d9576b7af3250bbbd7114e82263 \
  SHORT_COMMIT=c076ee9 \
  DEPLOYMENT_REPO=https://github.com/dsanchor/quarkus-hello-world-deployment.git \
  IMAGES_NS=cicd envsubst | \
  oc create -f - -n cicd
------------------------------------------------------------------------------------
pipelinerun.tekton.dev/knative-pipeline-run-j5knc created

Если вы предпочитаете запускать пайплайн через tkn CLI, выполните следующее:

$ tkn pipeline start knative-pipeline -p application=quarkus-hello-world \
  -p source-repo-url=https://github.com/dsanchor/quarkus-hello-world.git \
  -p source-revision=c076ee940b1f1d9576b7af3250bbbd7114e82263 \
  -p short-source-revision=c076ee9 \
  -p deployment-repo-url=https://github.com/dsanchor/quarkus-hello-world-deployment.git \
  -p deployment-revision=master \
  -p dockerfile=./src/main/docker/Dockerfile.jvm \
  -p image-registry=image-registry.openshift-image-registry.svc.cluster.local:5000 \
  -p image-repository=cicd \
  -w name=source,claimName=source-pvc \
  -w name=maven-settings,config=maven \
  -w name=knative-kustomize-base,config=knative-kustomize-base \
  -w name=knative-kustomize-environment,config=knative-kustomize-environment \
  -n cicd

Примечание: Выполнение пайплайна может занять до пяти минут. В это время предлагаю вам прочитать статью об ускорении сборки Maven в Tekton.
Когда пайплайн закочит работу, новый образ (quarkus-hello-world:c076ee940b1f1d9576b7af3250bbbd7114e82263) будет отправлен во внутренний registry OpenShift в неймспейсе cicd. Также новые Kustomization-файлы будут отправлены в репозиторий quarkus-hello-world-deployment.

Логи выполнения

Проверка логов пайплайна позволяет нам увидеть изменения, которые отправляются в Git. В особенности обратите внимание на записи задачи push-knative-manifest:

add 'development/kustomization.yaml'
remove 'development/r9ce9024/configmap.yaml'
remove 'development/r9ce9024/revision-patch.yaml'
remove 'development/r9ce9024/routing-patch.yaml'
add 'development/rc076ee9/configmap.yaml'
add 'development/rc076ee9/revision-patch.yaml'
add 'development/rc076ee9/routing-patch.yaml'
add 'production/kustomization-rc076ee9.yaml'
add 'production/rc076ee9/configmap.yaml'
add 'production/rc076ee9/revision-patch.yaml'
add 'production/rc076ee9/routing-patch.yaml'
add 'staging/kustomization-rc076ee9.yaml'
add 'staging/rc076ee9/configmap.yaml'
add 'staging/rc076ee9/revision-patch.yaml'
add 'staging/rc076ee9/routing-patch.yaml'

Подведем итог:

Новая версия доступна в development путем замены файла kustomization.yaml, который содержит ссылки на ресурсы новой версии. Заметьте, что в файле traffic-routing.yaml нет никаких изменений, так мы сохраняем все существующие правила маршрутов. (Например, мы можем сохранить все blue/green или canary правила маршрутов, сконфигурированные в предыдущей версии, если таковые были).
Мы только добавляем новый маршрут для новой версии, и мы убираем все ссылки на предыдущие версии. В основном маршруте все еще может быть ссылка на предыдущую версию, в таком случае эта версия может быть временно доступна через основной маршрут. После того, как версия становится не маршрутизируемой, Knative по истечению заранее установленного промежутка времени очистит ее как мусор. Использование Knative уменьшает трудозатраты на эксплуатацию и обслуживание и делает нас чуточку счастливее.
Мы также создаем необходимые файлы Kustomize для этой новой версии в средах staging и production, но на них еще нет ссылок в kustomization.yaml.

Вторая версия приложения в среде development

У нас есть новая версия сервиса Knative, но основной маршрут все еще ведет к предыдущему приложению, что показано на Рисунке 12.

Рис. 12: Основной маршрут указывает на предыдущую версию приложения.

Получите текущие маршруты для приложения, запущенного в среде development:

$ oc get routes -n knative-serving-ingress | grep development
--------------------------------------------------------------
route-e387d9ca-9f1b-4c15-9b83-7bea4d2d290c-313361326363   quarkus-hello-world-development.apps.ocp4.mydomain.com                   kourier    http2   edge/Allow    None
route-e387d9ca-9f1b-4c15-9b83-7bea4d2d290c-353136303164   rc076ee9-quarkus-hello-world-development.apps.ocp4.mydomain.com          kourier    http2   edge/Allow    None

Протестируйте оба, и вы заметите, что основной маршрут ведет к предыдущей версии:

$ curl http://quarkus-hello-world-development.apps.ocp4.mydomain.com/hello
hola dev! Yeap!

$ curl rc076ee9-quarkus-hello-world-development.apps.ocp4.mydomain.com/hello
hola dev! Nice to see you back!

Если вы хотите направить часть трафика на новую версию по главному маршруту, просто измените traffic-routing.yaml. Зайдите в репозиторий quarkus-hello-world-deployment и выполните git pull. Затем переключитесь на папку development и отредактируйте файл traffic-routing.yaml.

Измените файл с этого:

- op: add
  path: /spec/traffic
  value:
    - revisionName: quarkus-hello-world-r9ce9024
      percent: 100

На этот:

- op: add
  path: /spec/traffic
  value:
    - revisionName: quarkus-hello-world-r9ce9024
      percent: 50
    - revisionName: quarkus-hello-world-rc076ee9
      percent: 50

И затем примените изменения:

$ git add development/traffic-routing.yaml && git commit -m "Splitted traffic between r9ce9024 %50 and rc076ee9 50" && \
git push

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

Если вы проверите основной маршрут, вы увидите, что он возвращает ответы от обеих версий:

$ watch -n1 curl http://quarkus-hello-world-production.apps.ocp4.mydomain.com/hello

Если вы хотите убедиться, что трафик не пойдет к какой-то старой версии приложения, просто уберите эту версию из файла traffic-routing.yaml. В итоге Knative ее очистит, что вы можете протестировать и самостоятельно.

Вторая версия приложения в среде staging

Мы еще не получили новую версию приложения в среде staging. Причина этого в том, что пайплайн CI еще не изменил файл kustomization.yaml. Вместо этого он только создал возможного кандидата:

kustomization-REVISION.yaml.

Давайте развернем эту новую версию (mv staging/kustomization-rc076ee9.yaml staging/kustomization.yaml). Мы пропишем тот же самый маршрут, что и в development, разделив трафик между двумя нашими текущими версиями:

$ git pull && \
mv staging/kustomization-rc076ee9.yaml staging/kustomization.yaml && \
cp development/traffic-routing.yaml staging/traffic-routing.yaml && \
rm -rf staging/r9ce9024 && \
git add  staging && git commit -m "Split traffic between r9ce9024 %50 and  rc076ee9 50%" && \
git push

Заметьте, что мы также удалили папку более старой версии (rm -rf staging/r9ce9024). Пайплайн CI проделал это автоматически в development, но не в staging или production. Удаление предыдущей версии отличает development от двух других сред в демоверсии.
Окончательный результат приложения в staging будет таким же, как и в среде development, как показано на Рисунке 13.

Рис. 13: Приложения в development и staging синхронизированы.

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

$ watch -n1 curl http://quarkus-hello-world-staging.apps.ocp4.mydomain.com/hello

Вторая версия приложения в среде production

Как мы уже ранее отмечали, сценарий в production отличается от staging, потому что автоматическая синхронизация не предусмотрена для продакшена. Мы проделаем те же самые шаги, что и в staging, и посмотрим на результат:

$ git pull && \
mv production/kustomization-rc076ee9.yaml production/kustomization.yaml && \
cp staging/traffic-routing.yaml production/traffic-routing.yaml && \
rm -rf production/r9ce9024 && \
git add production && git commit -m "Split traffic between r9ce9024 %50 and rc076ee9 50%" && \
git push

OutOfSync

Посмотрев на панель управления Argo CD, как на Рисунке 14, вы должны увидеть, что статус приложения quarkus-hello-world-production OutOfSync. Затронутый объект — объект сервиса Knative.

Рис. 14: Объект сервиса Knative не синхронизирован.

Кликните на поле OutOfSync под quarkus-hello-world и проверьте вкладку DIFF, как показано на Рисунке 15.

Рис. 15: Используйте инструмент Diff, чтобы найти различия между версиями приложения.

Интерфейс на Рис. 15 показывает различия между действующим и желаемым манифестом, действующая версия представлена слева. Различия именно те, которые мы и предполагали, поэтому давайте синхронизируем их вручную и развернем новую версию и правила маршрутизации в production.
Проведя синхронизацию, протестируйте основной маршрут:

$ watch -n1 curl http://quarkus-hello-world-production.apps.ocp4.mydomain.com/hello

Откат к предыдущему состоянию

До сих пор вы смотрели, как развертывать новые версии приложения в каждой среде. А что если вы обнаружите непредвиденное поведение в последней версии приложения в production? Давайте используем Argo CD для отката к предыдущему состоянию приложения.
С Argo CD мы можем сделать откат к любой версии кода или приложения в истории нашего репозитория Git. Например, сделаем откат к предыдущей версии. Щелкните на History and Rollback на панели управления Argo CD, как показано на Рисунке 16.

Рис. 16: Использование функции History and Rollback, чтобы вернуться к предыдущей версии приложения.

Как только вы нашли ту версию, к которой хотите совершить откат, нажмите на меню в верхнем правом углу экрана и выберите там единственное действие: Rollback.

Рис. 17: Выберите нужную версию и нажмите Rollback.

Как показано на Рисунке 17, в результате приложение имеет текущий статус OutOfSync, но оно синхронизировано с версией, которую мы выбрали для отката. Проверьте, что откат сработал, проведя следующие тесты:

$ watch -n1 curl http://quarkus-hello-world-production.apps.ocp4.mydomain.com/hello

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

Примечание: Если у вас была активирована опция автосинхронизации для среды production, вам надо ее отключить перед проведением отката. Иначе все снова автоматически синхронизируется с последней версией.

Замыкаем круг: полностью автоматизированный CI/CD

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

Я сознательно оставил эту часть на конец статьи, чтобы мы могли использовать весь исходный репозиторий для запуска пайплайна. Мы добавим к этому репозиторию вебхук, который автоматически запустит пайплайн, когда новые коммиты будут отправляться в репозиторий.

Перед началом сделайте форк репозитория исходного кода по адресу: https://github.com/dsanchor/quarkus-hello-world.git. Мы используем его для финального примера.

Добавление триггера Tekton

На стороне Tekton мы создадим три различных типа объектов, которые работают сообща:

В EventListener мы добавим два перехватчика:

Перехватчик GitHub добавляет простую проверку, основанную на общем токене.
Перехватчик CEL применяет базовую функцию для сокращения ID коммита, чтобы он стал доступен для пайплайна.

Первым шагом создайте secret со случайным токеном:

$ oc create secret generic webhook --from-literal=token=XXXXXXXXXXXXXX -n cicd

Затем создайте общие для разных приложений TriggerTemplate и TriggerBinding:

$ oc apply -f tekton/webhook/knative-pipeline-trigger.yaml -n cicd
--------------------------------------------------------------------
triggerbinding.triggers.tekton.dev/webhook-body-binding created
triggertemplate.triggers.tekton.dev/knative-pipeline-template created

После этого создайте специфические для каждого приложения EventListener и TriggerBinding. Важно: используйте собственный репозиторий развертывания в DEPLOYMENT_REPO_URL:

$ cat tekton/webhook/app-custom-trigger.yaml | \
  GITHUB_SECRET=webhook \
  APPLICATION=quarkus-hello-world \
  NS=cicd \
  DEPLOYMENT_REPO_URL=https://github.com/dsanchor/quarkus-hello-world-deployment \
  DEPLOYMENT_REPO_REVISION=master \
  envsubst | oc apply -f - -n cicd
-------------------------------------------------------------------------------------
eventlistener.triggers.tekton.dev/quarkus-hello-world-listener created
triggerbinding.triggers.tekton.dev/quarkus-hello-world-binding created

Сделайте expose для сервиса event-listener, который будет целевым эндпоинтом вашего вебхука в GitHub:

$ oc expose svc el-quarkus-hello-world-listener -n cicd

И получите маршрут:

$ oc get route el-quarkus-hello-world-listener -n cicd
--------------------------------------------------------
NAME                              HOST/PORT                                                               PATH   SERVICES                          PORT            TERMINATION   WILDCARD
el-quarkus-hello-world-listener   el-quarkus-hello-world-listener-cicd.apps.ocp4.mydomain.com          el-quarkus-hello-world-listener   http-listener                 None

Настройка вебхука в GitHub

Теперь перейдите в репозиторий вашего приложения на GitHub. В пункте меню Settings выберите Webhooks -> Add Webhooks, как показано на Рисунке 18.

Рис. 18: Добавление вебхука в вашего приложения на GitHub проекта.

Добавьте маршрут в качестве URL-адреса полезной нагрузки, установите тип контента как JSON и, наконец, скопируйте содержание токена в раздел secret, как показано на Рисунке 19.

Рис. 19: Конфигурация вебхука.

Как только вы добавили эти финальные элементы, вы должны увидеть на экране единственный вебхук.

Проверим, что получилось

Я внесу простое изменение в класс GreetingResource. Вам нужно внести те же самые изменения в ваш Greeting Resource Test. В моем случае я меняю последнюю часть сообщения на “Webhooks work”.

После прохождения всех локальных тестов отправьте свои изменения в удаленный репозиторий:

$ git add src  && \
git commit -m "Changed greeting message" && \
git push

Пайплайн уже должен был запуститься. Если вы столкнетесь с ошибкой, вам стоит проверить event listener — под в кластере, который мы создали для управления событиями для EventListener. Чтобы получить имя пода, выполните:

$ oc get pod -l eventlistener=quarkus-hello-world-listener -n cicd

Дождитесь завершения работы пайплайна. После этого у вас должна появиться новая версия сервиса Knative в окружении development. Вы можете использовать новинку: developer perspective в веб-консоли OpenShift для того, чтобы убедиться, что сервис Knative работает. Выберите проект development и проверьте его топологию, как показано на Рисунке 20.

Рис. 20: Используйте developer perspective OpenShift для того, чтобы убедиться в работе сервиса Knative.

Вы должны увидеть три работающие версии (хотя все они свёрнуты до минимума из-за неактивности). Две версии, которые мы с вами развернули за первые этапы этой статьи, лежат на основном маршруте, каждая из них берет на себя половину трафика. Последняя версия имеет свой маршрут, созданный нашим пайплайном. Давайте отправим на него запрос и посмотрим на результаты:

$ curl r1b644f0-quarkus-hello-world-development.apps.ocp4.mydomain.com/hello
hola dev! Webhooks work!

Knative автоматически смасштабировал эту версию до одного пода, что показано на Рисунке 21.

Рис. 21: Knative провел автоматическое масштабирование последней версии приложения.

Заключение

Вторая часть статьи, посвященной введению в построение современных процессов CI/CD, познакомила вас с использованием Argo CD для реализации непрерывной доставки в бессерверном процессе CI/CD. Совмещение Tekton и GitOps при помощи Argo CD, становится все более популярным решением для полностью автоматического CI/CD.

Теги:

Хабы: