Knative

Пойте вместе с нами станьте частью DevNation.



Ниже наша новая подборка полезных ссылок на живые мероприятия, видео, митапы и техтолки.

Сначала главная новость недели релиз OpenShift 4.5!

Основные изменения:

• Kubernetes 1.18.3
• vSphere IPI
• GCP UPI, поддерживается установка в общий VPC
• Поддерживается установка компактного (3 мастера) кластера
• openshift-install explain помогает составить install-config.yaml
• OpenStack: установка в готовые сети и подсети, поддерживается добавление сетей
• Spot Instances в AWS Machine API
• Descheduler (TP), VPA (TP)
• Отдельный Prometheus для пользовательских метрик (TP)
• Улучшения в поддержке Knative, Tekton и Helm в консоли разработчика
• Поддержка HTTP/2
• Автоматический перевыпуск устаревших сертификатов
• Билды с Jenkins Pipeline теперь Deprecated

Release notes тут. В ближайшее время выпустим подробнейший пост про это долгожданное чудо.

Начни новое:

• 20 июля: Master Course | Operations I
  Масштабирование кластера OpenShift и настройка функции агрегирования логов OpenShiftа.
• 20 июля: Master Course | Operations II
  Интеграция OpenShift с identity management и настройка пользователей, групп и RBAC.
• Записи двух уроков по циклу разработки с инструментами Red Hat
  Каким образом построить процесс сборки и вывода приложения в промышленную эксплуатацию, чтобы оставить комфортные условия для разработки, тестирования и отладки самого приложения, как построить защищенное соединение и упростить процесс идентификации и авторизации пользователей и сторонних приложений в своих микросервисах, как передать свое приложение на конвейер сборки эти и другие важные вопросы без регистрации, смс и биткоинов в двух частях:
  Часть первая Red Hat CodeReady, Часть вторая CI/CD и Kubernetes.

Строй:

• Kourier: A lightweight Knative Serving ingress
  Попробуйте Kourier, чтобы облегчить экспонирование Knative-приложений во внешние сети без дополнительных CRD.
• Мяу! Установите Apache Tomcat и разверните веб-приложение на Java в Red Hat OpenShift
  
  
  
  
  
  Установите Apache Tomcat из образа Docker, а затем используйте его для развертывания и управления веб-приложением Java в Red Hat OpenShift.
• Разработка приложений Eclipse MicroProfile в Red Hat JBoss Enterprise Application Platform Expansion Pack 1.0 с Red Hat CodeReady Workspaces
  Настройте среду Red Hat CodeReady Workspaces для разработки приложений MicroProfile с использованием Red Hat JBoss Enterprise Application Platform XP 1.0.
• Автоматизация workshop setup с Ansible playbooks и CodeReady Workspaces
  Узнайте, как создать Ansible playbook для автоматизации развертывания Quarkus Workshop в кластере OpenShift 4 с помощью CodeReady Workspaces и Keycloak.
• Создайте простой cloud-native конвейер для сбора данных изменений
  Несколько вариантов, как создать приложение таким образом, чтобы улучшить взаимодействие с разработчиком, а не мешать ему.
• Operatorhub.io и ваш Kubernetes cluster | DevNation Tech Talk
• Приключения на борту корабля Kluster Kruise

На сладкое:

• OpenShift Container Platform 4
  Все, что вам нужно для управления жизненным циклом разработки, включая стандартизированные workflows, поддержку нескольких сред, continuous integration и release management. Поставь меня! Твой OpenShift Container Platform 4

Почитать на досуге:

• Пять тысяч глаз в небо: как ученые и роботы наблюдают за далекими галактиками
• Управление контейнерами в namespaces, используя nsenter
• Про деньги. Как измерить и управиться с technical debt
• Правила хорошего тона для команд при использовании при использовании Gitа

По-русски:

• 21 июля, Сотрудничество для достижения успеха: Решения Fujitsu и Red Hat для SAP HANA
  Совместный вебинар про то, как построить решения для SAP HANA с использованием Red Hat на базе серверов и СХД Fujitsu.
• 23 июля, Red Hat Infrastructure Layer
  Вебинар про человеческое управление инфраструктурным слоем. В ролях: Red Hat Enterprise Linux, Red Hat Satellite и Red Hat Insights.
• 23 июля, RHEL + Smart Management + Insights
  RHEL + Smart Management + Insights связка, которая позволяет сделать операционную систему и ее управление действительно умным и удобным. В рамках вебинара мы расскажем вам об интеграции Red Hat Enterprise Linux, Red Hat Satellite и Red Hat Insights.

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

В настоящей статье, состоящей из двух частей, мы построим рабочий поток CI/CD, который продемонстрирует возможности совместного использования Tekton и GitOps. Вы также познакомитесь с Red Hat OpenShift Serverless, так как мы будем использовать ресурсы сервисов Knative в нашем CI/CD процессе. Начнем же мы с обзора процесса CI/CD, который мы внедрим для примера.

CI/CD процесс

На схеме ниже изображен CI/CD процесс. Коммит, инициированный в исходном коде приложения, запускает полный CI/CD процесс, который завершается тем, что новая версия бессерверного приложения развертывается в Dev, Stage и Prod средах.

Рисунок 1. Демонстрационный пример CI/CD процесса.

Давайте подробнее рассмотрим каждый шаг этого процесса:

1. Разработчик отправляет новое изменение в репозиторий исходного кода приложения.
2. Созданный в репозитории исходного кода вебхук запускает пайплайн Tekton.
3. Как только пайплайн запустился, первая задача вызывает исходный код из репозитория.
4. Задача Maven упаковывает код приложения в файл JAR и проводит тесты модулей до того, как построить образ контейнера.
5. Задача Buildah строит и отправляет образ контейнера в registry. И затем образ отправляется во внутренний registry OpenShift.
6. Пайплайн обновляет у себя репозиторий, в котором хранится желаемое состояние конфигурации приложения и описание развертывания. В методологии GitOps мы используем репозиторий Git в качестве единственного источника истины о том, что и куда развертывается.
7. Изначально Git-репозиторий может быть пуст, но это не проблема, и этот шаг, инициализирует репозиторий со всеми манифестами Kubernetes (в данном случае сервисы Knative и ConfigMaps), которые необходимы, чтобы впервые запустить приложение. Последующие коммиты репозитория будут лишь обновлять существующие дескрипторы новыми версиями приложения, настройки канареечного тестирования и связанные конфигурации. Как только все файлы манифеста были созданы или модифицированы, задача отправляет изменения в репозиторий. Этот шаг является связующим звеном между непрерывной интеграцией, производимой пайплайном Tekton, и непрерывным развертыванием, управляемым Argo CD.
8. Argo CD извлекает из репозитория конфигурации и синхронизирует существующие манифесты Kubernetes, которые заданы файлами Kustomize. Это действие создает последние объекты Kubernetes в неймспейсах development, stagingи production. Синхронизация может производиться автоматически или вручную в зависимости от требований неймспейса.
9. В финальной части процесса может понадобиться извлечь образы, на которые ссылались в развертывании манифеста Kubernetes из внутреннего registry OpenShift. Команда эксплуатации может также внести изменения в конфигурацию, например, сменив URL целевого микросервиса или определенную информацию, которая известна команде разработчиков. Последний шаг может также создать состояние OutOfSync, что приведет к новому процессу синхронизации (см. шаг 9 на схеме).

Далее мы настроим наш кластер с OpenShift Operators и сервисами, которые нам понадобятся.

Настройка кластера OpenShift

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

$ git clone https://github.com/dsanchor/rh-developers-cicd.git

Затем проверьте, что у вас в системе установлены все инструменты из списка ниже. Они понадобятся при запуске скриптов:

• Helm: helm version
• Git: git version
• oc: oc version
• kustomize не ниже v3.1.0: customize version
• envsubst (gettext): envsubst --help
• tkn (опционально Tekton CLI): tkn version

Проверив все вышеуказанные требования, залогиньтесь в ваш кластер OpenShift под пользователем с правами администратора кластера:

$ oc login -u USERNAME -p PASSWORD https://api.YOUR_CLUSTER_DOMAIN:6443

Операторы, неймспейсы и привязки ролей

Мы сначала установим OpenShift Pipelines и OpenShift Serverless операторов в неймспейс openshift-operators.

Также создадим четыре новых неймспейса: cicd, development, staging и production. Образы помещаются в границы неймспейса cicd, поэтому, чтобы получать новые образы, все остальные неймспейсы требуют привилегий system:image-puller.

Наконец, добавим новую роль view по умолчанию в сервисные аккаунты development, staging и production. Эта роль обеспечивает доступ из наших подов приложения Quarkus к ConfigMaps и Secrets. (Приложение Quarkus я представлю чуть-чуть попозже).

Вот скрипт, которой по сути использует три чарта Helm для необходимых установок:

$ ./bootstrap.sh---------------Installing openshift-pipelines operatorRelease "openshift-pipelines" does not exist. Installing it now.NAME: openshift-pipelinesLAST DEPLOYED: Thu Sep 10 10:55:14 2020NAMESPACE: defaultSTATUS: deployedREVISION: 1TEST SUITE: NoneInstalling openshift-serverlessRelease "openshift-serverless" does not exist. Installing it now.NAME: openshift-serverlessLAST DEPLOYED: Thu Sep 10 10:55:16 2020NAMESPACE: defaultSTATUS: deployedREVISION: 1TEST SUITE: NoneCreating cicd, development, staging and production namespacesAdded cicd system:image-puller role to default sa in development, staging and production namespacesAdded view role to default sa in development, staging and production namespacesRelease "bootstrap-projects" does not exist. Installing it now.NAME: bootstrap-projectsLAST DEPLOYED: Thu Sep 10 10:55:18 2020NAMESPACE: defaultSTATUS: deployedREVISION: 1TEST SUITE: None

Вы можете выполнить скрипты как есть или использовать чарты Helm независимо, переопределяя любые значения на ваш выбор. Например, вы можете переопределить значение канала подписки для каждого оператора OpenShift.

Рисунок 2 показывает текущее состояние установки: оба оператора установлены в неймспейсе openshift-operators.

Рис. 2. Операторы OpenShift Serverless и OpenShift Pipelines установлены в неймспейсе openshift-operators.

Проверьте, что OpenShift Pipelines Operator установлен не ниже версии 1.1.1.
Теперь завершим установку компонентов OpenShift Serverless, установив панель управления Knative Serving.

Установка экземпляра Knative Serving

Нам нужно установить экземпляр Knative Serving, который предоставит нашим приложениям набор бессерверных возможностей. Чтобы создать экземпляр Knative Serving и установить панель управления, выполните следующее:

$ ./add-knative-serving.sh------------------------------Creating knative-serving namespacenamespace/knative-serving createdInstalling basic knative serving control planeknativeserving.operator.knative.dev/knative-serving created

Мы запустили набор подов, которые представляют базовую контрольную панель Knative Serving в неймспейс knative-serving, как показано на Рисунке 3.

Рис. 3. Панель управления Knative Serving в неймспейсе knative-serving.

Как показано на Рисунке 4, мы также создали новый неймспейс knative-serving-ingress для установочных входных шлюзов Knative.

Рис. 4. Новый неймспейс knative-serving-ingress.

Мы установили операторов OpenShift и создали неймспейс и экземпляр Knative Serving для управления нашими бессерверными процессами. Теперь мы готовы создать ресурсы Tekton, которые нам понадобятся для запуска пайплайна непрерывной интеграции.

Настройка задач и пайплайна Tekton

OpenShift Pipelines Operator поставляется с набором готовых кластерных задач, которые можно использовать для создания пайплайна. В некоторых ситуациях вам понадобятся другие задачи для получения определенного функционала. Эти задачи можно легко создать в Tekton. Вы также можете найти повторно используемые задачи и готовые пайплайны на Tekton Hub.

Для нашего пайплайна мы будем использовать одну задачу из Tekton Hub и две пользовательские. Чтобы эти задачи были доступны нашему пайплайну, нам нужно создать их в неймспейсе cicd. (Обратите внимание, что вы можете создать ClusterTasks, если считаете, что повторно используете их в разных пайплайнах из разных неймспейсов). Запустите следующий скрипт, чтобы установить необходимые задачи и создать пайплайн в том же неймспейсе.

$ ./add-tekton-customs.sh cicd------------------------------Installing buildah task from https://hub-preview.tekton.dev/task.tekton.dev/buildah createdInstalling custom taskstask.tekton.dev/push-knative-manifest createdtask.tekton.dev/workspace-cleaner createdInstalling knative-pipelinepipeline.tekton.dev/knative-pipeline created

Перейдите в консоль OpenShift и откройте меню Pipelines и проект cicd. Там вы увидите свои новые задачи, как показано на Рисунке 5.

Рис. 5. Новые задачи Tekton в неймспейсе cicd.

На Рисунке 6 представлен ваш новый пайплайн в том же неймспейсе.

Рис. 6. Пайплайн Tekton в неймспейсе cicd.

Рабочие области Tekton

Некоторые наши задачи в пайплайне требуют либо загрузки определенных конфигураций из ConfigMaps, либо сохранения состояния полученного выполнения, чтобы разделить его с другими задачами. Например, задача Maven требует, чтобы мы включили определенный settings.xml в ConfigMap. С другой стороны, первая задача вызывает репозиторий исходного кода приложения. Задаче Maven, которая идет следующей, потребуются эти файлы, чтобы создать приложение JAR. Мы используем OpenShift PersistentVolume, чтобы поделиться этими исходными файлами.

Tekton для этих целей имеет концепцию рабочих областей. Запустите следующий скрипт, чтобы добавить набор ConfigMaps и PersistentVolumeClaim в неймспейс cicd:

$ ./add-tekton-workspaces.sh cicd-----------------------------------Creating knative-kustomize-base ConfigMap with base kustomize files for Knative servicesconfigmap/knative-kustomize-base createdCreating knative-kustomize-environment ConfigMap with environment dependent kustomize filesconfigmap/knative-kustomize-environment createdCreating maven ConfigMap with settings.xmlconfigmap/maven createdCreating PVC using default storage classpersistentvolumeclaim/source-pvc created

Заметьте, этот скрипт создает PersistentVolumeClaim, не определяя StorageClass. Если вы не выберете какой-то определенный, то будет использоваться StorageClass по умолчанию. Без проблем можете раскомментировать любые строки в этом скрипте, чтобы он удовлетворял вашим требованиям.

Демо-приложение

До сих пор я почти ничего не сказал о демо-приложении. Оно основано на Quarkus, который идеально подходит для бессерверных приложений благодаря короткому времени загрузки и низкому потреблению памяти. Само приложение представляет из себя простой REST API Hello, world, который приветствует пользователей при вызове URI /hello.

Приложение использует расширение kubernetes-config для того, чтобы упростить работу с ConfigMaps и Secrets в Kubernetes. Приложение Hello, world! читает список ConfigMaps, что дает нам возможность управлять конфигурацией на разных уровнях, отменяя дублируемые свойства.

Рисунок 7 показывает фрагмент application.yaml, который определяет список ConfigMaps.

Рис. 7. Приложение YAML со списком ConfigMaps.

Вы можете найти полный исходный код приложения в репозитории GitHub для этой статьи. Обратите внимание, что пайплайн также запускает и постоянно обновляет другой репозиторий, который декларативно содержит все манифесты Kubernetes для всех развертываний и конфигураций приложений. Далее в статье мы будем использовать Kustomize, чтобы декларативно настроить конфигурацию и развертывание приложения.

Создание собственного репозитория

На данном этапе вы должны создать репозиторий GitHub, который вы будете использовать для хранения файлов кастомизации, которые необходимы для демонстрации. Мой репозиторий называется quarkus-hello-world-deployment, и я буду использовать это имя для отсылок к данному репозиторию в следующих скриптах. Вы можете взять то же самое имя или придумать репозиторию свое.

GitHub изменил имя по умолчанию на main, что видно на Рисунке 8.

Рис. 8. Main задан веткой по умолчанию.

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

Чтобы пайплайн Tekton мог отправлять изменения в новый репозиторий, вам нужно будет предоставить валидные учетные данные GitHub. Учетные данные вы сохраните в Secret и свяжете их с пайплайном ServiceAccount, который был автоматически создан в неймспейсе cicd.

Запустите следующий скрипт:

$ ./add-github-credentials.sh cicd YOUR_GITHUB_USER YOUR_GITHUB_PASSWORD---------------------------------------------------------------------------Creating secret with github credentials for user dsanchorsecret/github-credentials createdLinking pipeline sa in namespace cicd with your github credentialsserviceaccount/pipeline patched

Ручной запуск пайплайна

Теперь мы готовы к тому, чтобы вручную протестировать работу пайплайна и увидеть результаты. Рабочий процесс пайплайна включает настройку вебхука, который автоматически запускает пайплайн. Описание этого этапа мы оставим на конец этой статьи (см. Часть 2). На данный момент просто протестируем рабочий процесс, запустив пайплайн вручную.

Я написал два варианта запуска пайплайна вручную:

• Создать пайплайн из yaml-файла;
• Запустить пайплайн, используя Tekton CLI: tkn.

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

$ cat tekton/pipelines/knative-pipeline-run.yaml | \  SOURCE_REPO=https://github.com/dsanchor/quarkus-hello-world.git \  COMMIT=9ce90240f96a9906b59225fec16d830ab4f3fe12 \  SHORT_COMMIT=9ce9024 \  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-54kpq 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=9ce90240f96a9906b59225fec16d830ab4f3fe12 \  -p short-source-revision=9ce9024 \  -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

Еще один вариант запустить пайплайн через консоль OpenShift.

Отслеживание работы пайплайна

Для проверки рабочего прогресса откройте панель Pipeline Runs на консоли OpenShift, как показано на Рисунке 9.

Рис. 9. Использование панели Pipeline Runs для проверки рабочего прогресса.

Если вы хотите увидеть подробности каждой задачи пайплайна, кликните на имя пайплайна. Вы получите логи по каждой задаче, как показано на Рисунке 10.

Рис.10. Просмотр логов каждой задачи пайплайна.

Если вдруг вы дважды запустите пайплайн с одними и теми же параметрами (например, используя оба примера, которые я описал), вы увидите, что второй запуск завершится ошибкой при отправке манифестов Kustomization. Ошибка происходит, потому что нет ничего нового для выполнения отлично!

Результаты работы пайплайна

Диаграмма на Рисунке 11 иллюстрирует, чего мы уже достигли:

Рис. 11. Выполнение процесса CI/CD.

Заметьте, мы заменили шаги, относящиеся к Отправке кода и вебхуку репозитория, на ручной запуск пайплайна, основанный на ID определенного коммита.

На данный момент мы уже отправили новый образ во внутренний registry OpenShift. Мы также запустили репозиторий, который будет содержать все манифесты конфигурации и развертывания вместе со всеми манифестами Kubernetes, которые требуются для запуска первой версии нашего бессерверного приложения.

Обзор структуры репозитория развертывания

Сейчас самое время для обзора структуры репозитория развертывания и того, что в итоге станет окончательными манифестами, которые мы создадим с помощью Kustomize. Если вы не знакомы с Kustomize и его возможностями, не стесняйтесь узнать о нем больше. Понимание Kustomize может помочь лучше разбираться в структуре репозитория.
Обновите репозиторий развертывания (git pull), вы должны увидеть похожий результат:

 base    global-ops-configmap.yaml    kservice.yaml    kustomization.yaml development    env-ops-configmap.yaml    kustomization.yaml    r9ce9024       configmap.yaml       revision-patch.yaml       routing-patch.yaml    traffic-routing.yaml production    env-ops-configmap.yaml    kustomization-r9ce9024.yaml    r9ce9024       configmap.yaml       revision-patch.yaml       routing-patch.yaml    traffic-routing.yaml README.md staging env-ops-configmap.yaml kustomization-r9ce9024.yaml r9ce9024    configmap.yaml    revision-patch.yaml    routing-patch.yaml traffic-routing.yaml

Для простоты я пока рассмотрю только папки base и development:

• Папка base содержит все ресурсы, общие для трех сред. В ней есть базовая структура сервиса Knative и карта глобальной конфигурации.
• Папка development содержит наложения для завершения генерации манифеста сервиса Knative в данной версии приложения (примером служит папка r9ce9024) и двух ConfigMap, связана с уровнем настроек самого окружения и уровнем настроек разработчика. То, что находится в папке ревизии, было скопировано из исходного кода приложения, что позволяет разработчику самому задавать гибкие настройки.

Мы пользуемся простотой сервисов Knative, чтобы определить независимые маршруты для каждой версии сервиса и распределить трафик между версиями. Таким образом, traffic-routing.yaml и routing-patch.yaml формируют окончательную секцию маршрутизации трафика сервиса Knative.

Каждый раз когда в development появляется новая версия, для нее создается независимый маршрут, чтобы она точно была доступна для тестирования. Основной маршрут остается неизменным (например, направленный на две предыдущие версии). Мы достигаем такого поведения не путем изменения основного traffic-routing.yaml автоматически из пайплайна, а благодаря добавлению нового маршрута (routing-patch.yaml) для новой версии.

Эти детали станет проще понимать, когда мы проведем дополнительные тесты в Части 2. На данный момент просто отметьте для себя существенную разницу между неймспейсами staging и production и средой development. Пайплайн CI не создает файл kustomization.yaml (именно с таким именем) для них. Всегда будет файл с дополнительным префиксом версии: kustomization-r9ce9024.yaml. Эти изменения не будут учитываться в процессе синхронизации, если только в kustomization.yaml нет отсылки на эту новую версию. Чтобы изменения стали видны Kustomize, это надо настроить вручную.

Примечание: Суть различий в именах файлов заключается в том, чтобы лучше различать наши демо-окружения. Я хотел, чтобы эти две среды вели себя по-разному, чтобы требовалось одобрение изменений от кого-то. Переименование файла простой подход к одобрению, который не делает демонстрацию слишком сложной. Я бы предпочел создавать отдельную ветку для каждой новой версии, а потом генерировать pull request, когда в ней завершена работа.

Kustomize: соберем все кусочки пазла вместе

Мы рассмотрели наполнение и структуру репозитория развертывания, но у нас до сих пор нет окончательной композиции сервиса Knative и ConfigMaps. Приведенный ниже скрипт использует kustomize для построения окончательных манифестов, чтобы мы смогли увидеть, как они выглядят:

$ kustomize build development------------------------------apiVersion: v1kind: ConfigMapmetadata:  name: env-ops-quarkus-hello-world---apiVersion: v1kind: ConfigMapmetadata:  name: global-ops-quarkus-hello-world---apiVersion: v1data:  application.yaml: |-    message: hola    environment:      name: devkind: ConfigMapmetadata:  name: quarkus-hello-world---apiVersion: serving.knative.dev/v1kind: Servicemetadata:  name: quarkus-hello-worldspec:  template:    metadata:      name: quarkus-hello-world-r9ce9024    spec:      containers:      - image: image-registry.openshift-image-registry.svc.cluster.local:5000/cicd/quarkus-hello-world:9ce90240f96a9906b59225fec16d830ab4f3fe12        livenessProbe:          httpGet:            path: /health/live        readinessProbe:          httpGet:            path: /health/ready  traffic:  - percent: 100    revisionName: quarkus-hello-world-r9ce9024  - revisionName: quarkus-hello-world-r9ce9024    tag: r9ce9024

Заключение

На данном этапе мы могли бы применить наш набор объектов в неймспейсе development, чтобы получить рабочее бессерверное приложение, но мы не хотим вручную запускать развертывание. Во второй части статьи я покажу, как интегрировать Argo CD в пайплайн CI/CD, который мы уже создали.

От редакции: Узнать о внедрении CI/CD и интеграции Gitlab CI с Kubernetes можно с помощью практического видеокурса Слёрма. На уроках курса инженеры компаний Tinkoff и Southbridge делятся лучшими практиками построения пайплайнов.

В первой части статьи я представил 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 operatorRelease "argocd" does not exist. Installing it now.NAME: argocdLAST DEPLOYED: Thu Sep 10 18:37:23 2020NAMESPACE: defaultSTATUS: deployedREVISION: 1TEST 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 instanceargocd.argoproj.io/argocd createdAdding edit role to argocd-application-controller ServiceAccount in projects development, staging and productionrolebinding.rbac.authorization.k8s.io/edit-rh-developers-dev createdrolebinding.rbac.authorization.k8s.io/edit-rh-developers-staging createdrolebinding.rbac.authorization.k8s.io/edit-rh-developers-production createdCreating rh-developers AppProject in namespace cicdappproject.argoproj.io/rh-developers createdCreating Applications in namespace cicd in rh-developers AppProjectapplication.argoproj.io/quarkus-hello-world-development createdapplication.argoproj.io/quarkus-hello-world-staging createdapplication.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            WILDCARDargocd-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    Noneroute-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/hellohola dev! Yeap!$ curl http://r9ce9024-quarkus-hello-world-development.apps.ocp4.mydomain.com/hellohola 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    Noneroute-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/hellohola staging! Yeap!$ curl http://r9ce9024-quarkus-hello-world-staging.apps.ocp4.mydomain.com/hellohola 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    Noneroute-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/hellohola production! Yeap!$ curl http://r9ce9024-quarkus-hello-world-production.apps.ocp4.mydomain.com/hellohola 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    Noneroute-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/hellohola dev! Yeap!$ curl rc076ee9-quarkus-hello-world-development.apps.ocp4.mydomain.com/hellohola 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 мы создадим три различных типа объектов, которые работают сообща:

• TriggerTemplate
• TriggerBinding
• EventListener

В 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 createdtriggertemplate.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 createdtriggerbinding.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   WILDCARDel-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/hellohola dev! Webhooks work!

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

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

Заключение

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

Мы собрали для вас короткий дайджест полезных материалов, найденных нами в сети за последние две недели. Оставайтесь с нами станьте частью DevNation!

Начни новое:

• Использование OpenAPI вместе с .NET Core
  Как с помощью OpenAPI описать API сервисов ASP.NET Core, а затем использовать эти описания для генерации клиентами со строгим типизированием (strongly-typed client).
• Переключаем Red Hat OpenShift Virtualization с аппаратной виртуализации на программную эмуляцию
  По умолчанию OpenShift Virtualization использует аппаратную виртуализацию, но мы покажем, как переключиться на программную эмуляцию QEMU.
• Как запускать Red Hat CodeReady Containers на Windows 10 Enterprise
  Автор этой статьи успешно проходит квест с запуском Red Hat CodeReady Containers на Windows 10 Enterprise и попутно набивает за вас все возможные шишки.
• Развертывание serverless-приложений Node.js applications на Red Hat OpenShift, ч.1
  Показываем, как настроить Red Hat OpenShift Serverless GA и Knative Serving для развертывания serverless-приложений Node.js, которые масштабируется в ноль (полностью выключаются, когда ими не пользуются).
• GitOps: Stop, collaborate and deploy (вебинар DevNation Tech Talk, 35 минут)
  Как использовать Git для развертывания инструментов GitOps, управления приложениями и кластерными ресурсами, а также для миграции приложений с нулевыми простоями.
• Облачная модернизация или смерть почему это ложная дилемма (вебинар DevNation Tech Talk, 1 час 13 минут)

Качай:

• Debezium на OpenShift
  Debezium это распределенная опенсорсная платформа для отслеживания изменений в данных. Благодаря ее надежности и скорости ваши приложения смогут реагировать быстрее и никогда не пропустят события, даже если что-то пойдет на так. Наша шпаргалка поможет с развертыванием, созданием, запуском и обновление DebeziumConnector на OpenShift.
  Загрузить шпаргалку
• Шпаргалка Quarkus & Observability (придется зарегистрироваться в девелоперской программе и стать частью community, мухахаха)
  
  
  
  
  

Почитать на досуге:

• Объясняем простым языком, что такое гибридное облачное хранилище
  Что это вообще и какие задачи оно решает в условиях постоянного роста объемы данных и эволюции приложений.
  Вкратце: гибридные облачные хранилища сейчас в тренде, и не зря. Майк Пих (Mike Piech), вице-президент и генеральный менеджер Red Hat по облачным хранилищам и дата-сервисам, а также другие эксперты рассказывают о преимуществах, сценариях использования и ограничениях этой технологии.
• 4 книги по цифровой трансформации, которые должен прочесть каждый руководитель
  Технологии это далеко не всё, на чем фокусируются руководители, успешно осуществляющие цифровую трансформацию. Представленные книги расширят ваше понимание путей развития корпоративные заказчиков, глобальных рынков и других важных тем.
  Вкратце: эти 4 книги помогут освежить понимание перспектив цифровой трансформации.
  
  
  
  
  
• 7 способов применения микрокомпьютеров Raspberry Pi на предприятии
  От тимбилдинга до сверхдешевых средств безопасности и экспериментов с Kubernetes рассказываем, как задействовать Raspberry Pi на предприятиях.
  Вкратце: крохотный Raspberry Pi способен придать большой импульс развитию корпоративной ИТ-системы.

Смотри в записи:

• jconf.dev (30 сентября)
  Бесплатная виртуальная Java-конференция прямо у вас на экране: четыре техно-трека с нашими комьюнити-экспертами по Java и облаку, 28 углубленных сессий и два потрясающих основных доклада.
• AnsibleFest (13-14 октября)
  Два дня интереснейших докладов, демонстраций и практических занятий. Отличная возможность узнать, как разработчики, администраторы и ЛПР в сфере ИТ отвечают на вызовы перемен с помощью гибких технологий автоматизации с открытым кодом, которые позволяют перейти от того, что есть, к тому, что нужно.
• J4K Conference (13-14 октября)
  Новая виртуальная конференция по Kubernetes, Java и облаку: 17 сессий с сотрудниками Red Hat, включая доклад Марка Литтла (Mark Little), главного человека в Red Hat по связующему ПО.
• График предстоящих мероприятия DevNation
  Ознакомьтесь с планом мероприятия DevNation на портале Red Hat Developer, включая все вебинары Tech Talks и мастер-курсы, чтобы заранее спланировать свое расписание и зарегистрироваться на заинтересовавшие вас мероприятия.

По-русски:

• DeploymentConfig vs Deployment
• Император Оператор: Операторы в OpenShift и Kubernetes
• OpenShift-специфичные волшебные вещи для сборки и развертывания приложений
• Red Hat OpenShift и Machine API

Автор нашей новой переводной статьи утверждает, что Knative лучшее, что только могли придумать во Вселенной! Вы согласны?

Если вы уже используете Kubernetes, то, вероятно, слышали о бессерверной архитектуре (serverless). Хотя обе платформы, Kubernetes и Knative, являются масштабируемыми, именно бессерверная архитектура делает всё возможное, чтобы предоставлять разработчикам работающий код и не беспокоить их проблемами инфраструктуры. Кроме того, такая архитектура сокращает расходы на инфраструктуру за счет виртуального масштабирования экземпляров приложения с нуля.


С другой стороны, вы можете использовать преимущества Kubernetes без ограничений, следуя традиционной модели хостинга и продвинутым методам управления трафиком. Благодаря этому, нам открываются различные возможности, например, сине-зеленый деплой (blue-green deployments) и A/B-тестирование.

Knative это попытка взять лучшее из обоих миров! Как облачная платформа с открытым исходным кодом, Knative позволяет запускать ваши serverless-приложения на Kubernetes, реализуя все возможности последнего, а также гарантирует простоту и гибкость бессерверной архитектуры.

Таким образом, разработчики могут сосредоточиться на написании кода и развертывании контейнера в Kubernetes с помощью одной команды, а Knative в это время управляет приложением, заботясь о сетевых нюансах, автоматическом масштабировании до нуля и отслеживании версий.

Кроме того, Knative позволяет разработчикам писать слабо связанный (loosely coupled) код со своим фреймворком обработки событий, который обеспечивает универсальную подписку, доставку и управление событиями. Это означает, что вы можете объявить возможность подключения к событиям, и ваши приложения могут подписаться на определенные потоки данных.

Возглавляемая Google, данная open-source платформа была включена в Cloud Native Computing Foundation. Это подразумевает отсутствие привязки к вендору, что в противном случае является существенным ограничением текущих облачных бессерверных решений FaaS. Вы можете запустить Knative в любом кластере Kubernetes.

Для кого Knative?

Knative помогает самым разным специалистам, у каждого из которых свои знания, опыт и обязанности.



Инженеры могут сосредоточиться на управлении кластером Kubernetes, а также на установке и обслуживании экземпляров Knative с помощью kubectl, а разработчики занимаются созданием и развертыванием приложений с использованием интерфейса Knative API.

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

Почему Knative стоит использовать?

Большинство организаций, использующих Kubernetes, имеют сложный процесс управления развертыванием и поддержанием workloads. Это приводит к тому, что разработчики обращают внимание на детали, о которых им не нужно беспокоиться. Разработчикам следует сосредоточиться на написании кода, а не думать о сборках и развертываниях.

Kubeless помогает разработчикам упростить выполнение своего кода без необходимости слишком много знать о том, что происходит под капотом Kubernetes.

Кластер Kubernetes занимает ресурсы инфраструктуры, так как требует, чтобы у всех приложений был хотя бы один запущенный контейнер. Knative управляет этим аспектом за вас и заботится об автоматическом масштабировании контейнеров в кластере с нуля. Это позволяет администраторам Kubernetes упаковать множество приложений в один кластер.

Если у вас есть несколько приложений с разным временем пиковой нагрузки или у вас есть кластер с автоматическим масштабированием рабочих узлов, вы можете извлечь из этого большую пользу во время простоя.

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

Кроме того, он довольно хорошо интегрируется с движком Eventing и упрощает задачу в проектировании несвязанных систем. Код приложения может оставаться полностью свободным от какой-либо конфигурации конечной точки, и вы можете публиковать и подписываться на события, объявляя конфигурации на уровне Kubernetes. Это значительное преимущество для сложных микросервисных приложений!

Как Knative работает?

Knative предоставляет интерфейс kn API с помощью операторов Kubernetes и CRD. Используя их, вы можете развертывать приложения с помощью командной строки. В фоновом режиме Knative создаст все необходимое в Kubernetes (развертывание, сервисы, входящие данные и т. д.) для запуска приложений, и вам не придется об этом беспокоиться.

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



Knative предоставляет конечные точки приложения с использованием собственного домена в формате [app-name].[namespace].[custom-domain].

Это помогает однозначно идентифицировать приложение. Похоже на то, как Kubernetes обрабатывает сервисы, но вам нужно создать A-записи собственного домена, чтобы указать на шлюз Istio ingress. Istio управляет всем трафиком, который проходит через ваш кластер в фоновом режиме.

Knative это объединение множества продуктов CNCF и продуктов с открытым исходным кодом, таких как Kubernetes, Istio, Prometheus, Grafana, и движков потоковой передачи событий, таких как Kafka и Google Pub/Sub.

Установка Knative

Knative имеет разумную модульную структуру, и вы можете установить только необходимые компоненты. Knative предлагает компоненты событий, обслуживания и мониторинга. Установить их можно, применив пользовательские CRD.

Knative действительно имеет внешние зависимости и требования для каждого компонента. Например, если вы устанавливаете обслуживающий компонент, вам также необходимо установить Istio и надстройку DNS.

Установка Knative довольна сложна и достойна рассмотрения в отдельной статье. Но для демонстрации давайте начнем с установки обслуживающего компонента.

Для этого вам потребуется работающий кластер Kubernetes.

Установите Service CRD и основные обслуживающие компоненты (serving core components):

kubectl apply -f
https://github.com/knative/serving/releases/download/v0.17.0/serving-crds.yaml
kubectl apply -f
https://github.com/knative/serving/releases/download/v0.17.0/serving-core.yaml

Установите Istio для Knative:

curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.7.0 sh && cd istio-1.7.0 && export PATH=$PWD/bin:$PATH
istioctl install --set profile=demo
kubectl label namespace knative-serving istio-injection=enabled

Подождите, пока Istio будет готов, проверив, выделил ли Kubernetes внешний IP-адрес шлюзу Istio Ingress:

kubectl -n istio-system get service istio-ingressgateway

Определите собственный домен и настройте DNS, чтобы он указывал на IP-адрес шлюза Istio ingress:

kubectl patch configmap/config-domain --namespace knative-serving --type merge -p "{\data\:{\"$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}').xip.io\":\"\"}}"
kubectl apply -f https://github.com/knative/net-istio/releases/download/v0.17.0/release.yaml
kubectl apply -f https://github.com/knative/serving/releases/download/v0.17.0/serving-default-domain.yaml

Установите надстройку Istio HPA:

kubectl apply -f
https://github.com/knative/serving/releases/download/v0.17.0/serving-hpa.yaml

Установка Knative CLI

Установить Knative CLI просто. Необходимо загрузить последнюю версию бинарного файла Knative CLI в папку bin или указать соответствующий путь.

sudo wget https://storage.googleapis.com/knative-nightly/client/latest/kn-linux-amd64 -O /usr/local/bin/kn
sudo chmod +x /usr/local/bin/kn
kn version

Запуск приложения Hello, World!

А теперь давайте запустим наше первое Hello, World! приложение, чтобы понять, насколько просто оно разворачивается с помощью Knative.

Воспользуемся образцом приложения Hello, World! на Go для демонстрации. Это простой REST API, который возвращает Hello $TARGET, где $TARGET это переменная среды, которую вы можете установить в контейнере.

Выполните следующую команду, чтобы начать:

$ kn service create helloworld-go --image gcr.io/knative-samples/helloworld-go --env TARGET="World" --annotation autoscaling.knative.dev/target=10Creating service 'helloworld-go' in namespace 'default':0.171s Configuration "helloworld-go" is waiting for a Revision to become ready.  6.260s ...  6.324s Ingress has not yet been reconciled.  6.496s Waiting for load balancer to be ready  6.637s Ready to serve.Service 'helloworld-go' created to latest revision 'helloworld-go-zglmv-1' is available at URL:http://helloworld-go.default.34.71.125.175.xip.io

kubectl get podNo resources found in default namespace.

Запустим сервис helloworld.

$ curl http://helloworld-go.default.34.71.125.175.xip.io
Hello World!

И через некоторое время мы получаем ответ. Давайте посмотрим на поды.

$ kubectl get podNAME                                               READY   STATUS    RESTARTS   AGEhelloworld-go-zglmv-1-deployment-6d4b7fb4f-ctz86   2/2     Running   0          50s

Итак, как вы можете видеть, Knative развернул под в фоновом режиме за одно движение. Получается, что мы буквально масштабировали с нуля.

Если мы дадим немного времени, мы увидим, что под начинает завершаться. Давайте посмотрим, что происходит.

$ kubectl get pod -wNAME                                               READY   STATUS    RESTARTS   AGEhelloworld-go-zglmv-1-deployment-6d4b7fb4f-d9ks6   2/2     Running   0          7shelloworld-go-zglmv-1-deployment-6d4b7fb4f-d9ks6   2/2     Terminating   0          67shelloworld-go-zglmv-1-deployment-6d4b7fb4f-d9ks6   1/2     Terminating   0          87s

Пример выше показывает, что Knative управляет подами согласно нашим требованиям. Хотя первый запрос выполняется медленно, поскольку Knative создает workloads для его обработки, последующие запросы будут выполняться быстрее. Вы можете точно настроить время замедления подов в зависимости от ваших требований или при наличии более жесткого SLA.

Давайте пройдем еще немного дальше. Если вы посмотрите на аннотации, мы ограничили каждый под обработкой до 10 одновременных запросов. Итак, что произойдет, если мы загрузим наши функции сверх этого? Сейчас выясним!

Мы воспользуемся утилитой hey для нагрузки на приложение. Следующая команда отправляет 50 одновременных запросов к конечной точке в течение 30 секунд.

$ hey -z 30s -c 50 http://helloworld-go.default.34.121.106.103.xip.io  Average:      0.1222 secs  Requests/sec: 408.3187Total data:   159822 bytes  Size/request: 13 bytesResponse time histogram:  0.103 [1]     |  0.444 [12243] |  0.785 [0]     |  1.126 [0]     |  1.467 [0]     |  1.807 [0]     |  2.148 [0]     |  2.489 [0]     |  2.830 [0]     |  3.171 [0]     |  3.512 [50]    |Latency distribution:  10% in 0.1042 secs  25% in 0.1048 secs  50% in 0.1057 secs  75% in 0.1077 secs  90% in 0.1121 secs  95% in 0.1192 secs  99% in 0.1826 secsDetails (average, fastest, slowest):  DNS+dialup:   0.0010 secs, 0.1034 secs, 3.5115 secs  DNS-lookup:   0.0006 secs, 0.0000 secs, 0.1365 secs  req write:    0.0000 secs, 0.0000 secs, 0.0062 secs  resp wait:    0.1211 secs, 0.1033 secs, 3.2698 secs  resp read:    0.0001 secs, 0.0000 secs, 0.0032 secsStatus code distribution:  [200] 12294 responses

Теперь посмотрим на поды.

$ kubectl get podNAME                                                READY   STATUS    RESTARTS   AGEhelloworld-go-thmmb-1-deployment-77976785f5-6cthr   2/2     Running   0          59shelloworld-go-thmmb-1-deployment-77976785f5-7dckg   2/2     Running   0          59shelloworld-go-thmmb-1-deployment-77976785f5-fdvjn   0/2     Pending   0          57shelloworld-go-thmmb-1-deployment-77976785f5-gt55v   0/2     Pending   0          58shelloworld-go-thmmb-1-deployment-77976785f5-rwwcv   2/2     Running   0          59shelloworld-go-thmmb-1-deployment-77976785f5-tbrr7   2/2     Running   0          58shelloworld-go-thmmb-1-deployment-77976785f5-vtnz4   0/2     Pending   0          58shelloworld-go-thmmb-1-deployment-77976785f5-w8pn6   2/2     Running   0          59s

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

Заключение

Knative сочетает в себе лучшие характеристики бессерверной архитектуры и возможности Kubernetes. Он постепенно движется к стандартному способу реализации FaaS. Поскольку Knative входит в CNCF и вызывает всё больший интерес среди технических специалистов, возможно, скоро мы обнаружим, что облачные провайдеры внедряют Knative в свои бессерверные продукты.

Спасибо, что прочитали мою статью! Надеюсь, она вам понравилась.