В недавней статье выдвинуто предложение использовать 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.

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

В большинстве случаев требуется типовая задача: "сгенерировать YAML и положить его в Kubernetes". Собственно, с чем Argo CD замечательно и справляется.

Argo CD позволяет подключить Git-репозиторий и синкать его состояние в Kubernetes. По умолчанию есть поддержка нескольких видов приложений: Kustomize, Helm чарты, Ksonnet, голый Jsonnet или просто директории с YAML/JSON манифестами.

Большинству пользователей этого набора будет достаточно, но не всем. Для того чтобы удовлетворить потребности всех и каждого в Argo CD имеется возможность использовать custom tooling.

В первую очередь интересует возможность добавления поддержки qbec и git-crypt, которые с полна были рассмотренны в предыдущей статье.

---

Прежде чем приступить к конфигурации, нужно сначала разобраться с тем как именно Argo CD работает.

Для каждого добавленного приложения он имеет две фазы:

• init начальная подготовка перед деплоем, здесь может быть всё что угодно: скачивание зависимостей, распаковка секретов и другое.
• generate выполнение непосредственно команды генерации манифестов, вывод должен быть валидным YAML stream, это именно то, что будет применено в кластер.

Примечательно то, что Argo применяет этот подход для любого типа приложений, в том числе и для Helm. То есть в Argo CD Helm не занимается деплоем релизов в кластер, а используется только для генерации манифестов.

Со своей стороны Argo умеет нативно обрабатывать Helm-хуки, что позволяет не нарушать логики применения релизов.

---

QBEC

Qbec позволяет удобно описывать приложения с помощью jsonnet, а кроме того имеет возможность рендерить Helm-чарты, а так как Argo CD умеет нормально обрабатывать Helm-хуки, то использование этой возможности с Argo CD позволяет добиться ещё более корректных результатов.

Для того чтобы добавить поддержку qbec в argocd нужно две вещи:

• в конфиге Argo CD дожен быть определен ваш custom plugin и команды для генерации манифестов.
• нужные бинарники должны быть доступны в образе argocd-repo-server.

Первая задача решается довольно просто:

# cm.yamldata:  configManagementPlugins: |    - name: qbec      generate:        command: [sh, -xc]        args: ['qbec show "$ENVIRONMENT" -S --force:k8s-namespace "$ARGOCD_APP_NAMESPACE"']

(команда init не используется)

$ kubectl -n argocd patch cm/argocd-cm -p "$(cat cm.yaml)"

Для добавления бинарников предлагается собрать новый образ, или использовать трюк с init-контейнером:

# deploy.yamlspec:  template:    spec:      # 1. Define an emptyDir volume which will hold the custom binaries      volumes:      - name: custom-tools        emptyDir: {}      # 2. Use an init container to download/copy custom binaries into the emptyDir      initContainers:      - name: download-tools        image: alpine:3.12        command: [sh, -c]        args:        - wget -qO- https://github.com/splunk/qbec/releases/download/v0.12.2/qbec-linux-amd64.tar.gz | tar -xvzf - -C /custom-tools/        volumeMounts:        - mountPath: /custom-tools          name: custom-tools      # 3. Volume mount the custom binary to the bin directory (overriding the existing version)      containers:      - name: argocd-repo-server        volumeMounts:        - mountPath: /usr/local/bin/qbec          name: custom-tools          subPath: qbec        - mountPath: /usr/local/bin/jsonnet-qbec          name: custom-tools          subPath: jsonnet-qbec

$ kubectl -n argocd patch deploy/argocd-repo-server -p "$(cat deploy.yaml)"

Теперь посмотрим как будет выглядеть манифест нашего приложения:

apiVersion: argoproj.io/v1alpha1kind: Applicationmetadata:  name: qbec-app  namespace: argocdspec:  destination:     namespace: default    server: https://kubernetes.default.svc  project: default  source:     path: qbec-app    plugin:       env:         - name: ENVIRONMENT          value: default      name: qbec    repoURL: https://github.com/kvaps/argocd-play  syncPolicy:     automated:       prune: true

В переменной ENVIRONMENT мы передаём имя окружения для которого нужно выполнять генерацию манифестов.

применим и посмотрим что у нас получилось:

приложение задеплоилось, отлично!

---

git-crypt

Git-crypt позволяет настроить прозрачное шифрование репозитория. Это простой и безопасный способ хранить конфиденциальные данные прямо в git.

С имплементацией git-crypt оказалось сложнее.

Теоретически мы могли бы выполнять git-crypt unlock на init-стадии нашего custom-плагина, но это не очень удобно, так как не позволило бы использовать нативные методы деплоя. Например в случае Helm и Jsonnet, мы теряем гибкий GUI-интерфейс который позволяет упростить настройку приложения (values-файлы и прочее).

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

Так как на данный момент Argo CD не предоставляет возможности для описания каких-либо хуков для синхронизации репозитория, пришлось обойти это ограничение хитрым шелл скриптом-обёрткой, который заменяет собой команду git:

#!/bin/sh$(dirname $0)/git.bin "$@"ec=$?[ "$1" = fetch ] && [ -d .git-crypt ] || exit $ecGNUPGHOME=/app/config/gpg/keys git-crypt unlock 2>/dev/nullexit $ec

Argo CD выполняет git fetch каждый раз перед операцией деплоя. Именно на эту команду мы и повесим выполнение git-crypt unlock для разблокировки репозитория.

для тестов можете использовать мой docker-образ в котором уже есть всё необходимое:

$ kubectl -n argocd set image deploy/argocd-repo-server argocd-repo-server=docker.io/kvaps/argocd-git-crypt:v1.7.3

Теперь нам нужно подумать о том, как Argo будет расшифровывать наши репозитории. А именно сгенерировать gpg-ключ для него:

$ kubectl exec -ti deploy/argocd-repo-server -- bash$ printf "%s\n" \    "%no-protection" \    "Key-Type: default" \    "Subkey-Type: default" \    "Name-Real: YOUR NAME" \    "Name-Email: YOUR EMAIL@example.com" \    "Expire-Date: 0" \    > genkey-batch $ gpg --batch --gen-key genkey-batchgpg: WARNING: unsafe ownership on homedir '/home/argocd/.gnupg'gpg: keybox '/home/argocd/.gnupg/pubring.kbx' createdgpg: /home/argocd/.gnupg/trustdb.gpg: trustdb createdgpg: key 8CB8B24F50B4797D marked as ultimately trustedgpg: directory '/home/argocd/.gnupg/openpgp-revocs.d' createdgpg: revocation certificate stored as '/home/argocd/.gnupg/openpgp-revocs.d/9A1FF8CAA917CE876E2562FC8CB8B24F50B4797D.rev'

Сохраним имя ключа 8CB8B24F50B4797D для дальнейших шагов. Экспортируем сам ключ:

$ gpg --list-keysgpg: WARNING: unsafe ownership on homedir '/home/argocd/.gnupg'/home/argocd/.gnupg/pubring.kbx-------------------------------pub   rsa3072 2020-09-04 [SC]      9A1FF8CAA917CE876E2562FC8CB8B24F50B4797Duid           [ultimate] YOUR NAME <YOUR EMAIL@example.com>sub   rsa3072 2020-09-04 [E]$ gpg --armor --export-secret-keys 8CB8B24F50B4797D

И добавим его в виде отдельного секрета:

# argocd-gpg-keys-secret.yamlapiVersion: v1kind: Secretmetadata:  name: argocd-gpg-keys-secret  namespace: argocdstringData:  8CB8B24F50B4797D: |-    -----BEGIN PGP PRIVATE KEY BLOCK-----    lQVYBF9Q8KUBDACuS4p0ctXoakPLqE99YLmdixfF/QIvXVIG5uBXClWhWMuo+D0c    ZfeyC5GvH7XPUKz1cLMqL6o/u9oHJVUmrvN/g2Mnm365nTGw1M56AfATS9IBp0HH    O/fbfiH6aMWmPrW8XIA0icoOAdP+bPcBqM4HRo4ssbRS9y/i    =yj11    -----END PGP PRIVATE KEY BLOCK-----

$ kubectl apply -f argocd-gpg-keys-secret.yaml

Единственное что нам осталось, это пробросить его в контейнер argocd-repo-server, для этого отредактируем deployment:

$ kubectl -n argocd edit deploy/argocd-repo-server

И заменим существующий gpg-keys volume на projected, где и укажем наш секрет:

   spec:     template:       spec:         volumes:         - name: gpg-keys           projected:             defaultMode: 420             sources:             - secret:                 name: argocd-gpg-keys-secret             - configMap:                 name: argocd-gpg-keys-cm

Argo CD автоматически подгружает gpg-ключи из этой директории при старте контейнера, таким образом он загрузит и наш приватный ключ.

проверим:

$ kubectl -n argocd exec -ti deploy/argocd-repo-server -- bash$ GNUPGHOME=/app/config/gpg/keys gpg --list-secret-keysgpg: WARNING: unsafe ownership on homedir '/app/config/gpg/keys'/app/config/gpg/keys/pubring.kbx--------------------------------sec   rsa2048 2020-09-05 [SC] [expires: 2021-03-04]      ED6285A3B1A50B6F1D9C955E5E8B1B16D47FFC28uid           [ultimate] Anon Ymous (ArgoCD key signing key) <noreply@argoproj.io>sec   rsa3072 2020-09-03 [SC]      9A1FF8CAA917CE876E2562FC8CB8B24F50B4797Duid           [ultimate] YOUR NAME <YOUR EMAIL@example.com>ssb   rsa3072 2020-09-03 [E]

Отлично, ключ загружен! Теперь нам достаточно добавить Argo CD в наш репозиторий в качестве коллаборатора и он сможет автоматически расшифровывать его на лету.

Импортируем ключ на локальный компьютер:

$ gpg --armor --export-secret 8CB8B24F50B4797D > 8CB8B24F50B4797D.pem$ gpg --import 8CB8B24F50B4797D.pem

Настроим уровень доверия:

$ gpg --edit-key 8CB8B24F50B4797Dtrust5

Добавим argo в качестве коллаборатора в наш проект:

$ git-crypt add-gpg-user 8CB8B24F50B4797D

---

Ссылки по теме:

• GitHub: репозиторий с модифицированным образом
• Argo CD: Custom Tooling
• Argo CD: Config Management Plugins
• GitHub Gist: генерация gpg ключей без пароля в неинтерактивном режиме

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


Далее представлен текстовый пересказ видео.

Предисловие о терминологии

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

В сообществе бытуют два понимания GitOps:

1. Обобщенное как паттерна, при котором Git является единым источником правды и в котором через действия в Git мы управляем действительностью. Из самого названия GitOps любому, кто много работал с Git и IaC (Infrastructure as Code), интуитивно понятен этот паттерн. Именно такое обобщенное понимание мы и используем в нашем проекте werf.
2. Более конкретное понимание GitOps, в частности, определяющееся pull-моделью и обязательным промежуточным Git-репозиторием. Именно такую конкретную реализацию достаточно активно продвигают некоторые компании (включая авторов самого термина). Информацией именно об этой модели заполнен интернет.

В данном видео (и статье) под GitOps я подразумеваю именно второе, конкретное, понимание и пытаюсь разобрать, какие к нему есть вопросы.

Что такое GitOps

Какая картина возникает у вас в голове, когда вы слышите GitOps?

Все начинается с Git-репозитория. В нем есть YAML-файлы, описывающие желаемое состояние Kubernetes. Например:

• два Deployment'а,
• StatefulSet,
• Ingress.

Вместе они формируют некоторое простое приложение, которое располагается в кластере Kubernetes.

Единственная недостающая часть это GitOps-оператор. Он отвечает за синхронизацию состояния из Git в Kubernetes. Для этого он периодически (или по событию, которое может быть запущено, например, через webhook):

• считывает состояние из Git,
• считывает состояние из Kubernetes,
• сравнивает их,
• меняет состояние Kubernetes (если это необходимо).

Вот и все. Проще не бывает: репозиторий Git с (обычно предварительно скомпилированными) манифестами, кластер Kubernetes и штука, которая поддерживает синхронизацию между ними (GitOps-оператор).


Обычная схема GitOps в действии

NB. Хотя GitOps-оператор и может работать снаружи, почти всегда он находится внутри кластера Kubernetes. Но для упрощения мы изображаем его снаружи.

Само использование этого подхода уже предостерегает нас от некоторых вещей. Если по какой бы то ни было причине некоторый пользователь напрямую изменит что-то в Kubernetes, GitOps-оператор обнаружит изменение и вернет K8s в состояние, определенное в Git. Это создает своего рода забор, который мотивирует пользователей (вместо прямого внесения изменений в K8s) делать правки в единственном источнике правды, которым выступает Git.

Вместо небольшого забора можно построить и серьезную стену (полностью забрав у пользователя прямой доступ к K8s), и прозрачную стену (с доступом только для чтения). Но главное не в этом, а в том, что Git единственная точка входа.


Стена, предотвращающая прямой доступ пользователей к Kubernetes

Всё ли здесь учтено?

В представленной схеме не хватает одной важной части container registry. Если новый Docker-образ попадает в реестр, GitOps-оператор через некоторое время обнаружит изменение и распространит его в Kubernetes (новый образ будет доставлен в K8s).



Становится очевидно, что состояние Kubernetes на самом деле не полностью определено в Git. Состояние Kubernetes определяется Git'ом и container registry.

Преимущества и недостатки GitOps

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

1. Автоматизация Мы не производим вручную ни какие-либо правки в Kubernetes, ни синхронизацию состояния из Git. Для последнего есть GitOps-оператор, который отвечает за синхронизацию, выполняя ее полностью автоматически.
2. Конвергентность Система стремится прийти в желаемое состояние и, даже если время от времени происходит рассинхронизация, сама возвращается обратно в требуемое, синхронизированное состояние. Почему может произойти рассинхронизация? Две основные причины: а) что-то изменилось в Kubernetes (ручные или несанкционированные действия и подобное), б) изменения внесены в Git, но еще не доставлены в Kubernetes. В обоих случаях за восстановление синхронизации системы отвечает GitOps-оператор.
3. Идемпотентность Если мы повторим синхронизацию несколько раз, результат первой синхронизации не повлияет на результат второй, они оба не повлияют на третью, и так далее. Впрочем, если у нас имеются уже скомпилированные манифесты, коммитнутые в Git, эта идемпотентность обеспечивается в основном самим Kubernetes и его API, так что в этом смысле заслуги GitOps тут нет.
4. Детерминизм Состояние в Kubernetes целиком и полностью определяется тем, что написано в Git. Как я уже говорил, это неправда, потому что состояние зависит ещё от container registry. Если кто-то изменит состояние реестра, изменит образ в реестре развалится практически всё. Подробности будут ниже.
5. Наблюдаемость В любой момент времени мы хотим знать, синхронизирована ли наша система. Хотим иметь возможность получать алерт, если это не так. С одной стороны да, наблюдаемость присутствует: ведь мы знаем, соответствует ли текущий Kubernetes манифесту в Git. Однако мы в то же время не знаем, находится ли наша система в желаемом состоянии. Ведь что такое желаемое состояние? Это комбинация из манифестов (в репозитории Git) и образов контейнеров (в реестре). Вывод: только половина состояния определяется Git, и только половину состояния можно наблюдать.
6. Аудит Необходимо надежно и удобно просматривать все изменения, внесенные в Kubernetes, причем в одном месте. И это место Git. Но это неправда, потому что мы также должны полагаться на функции аудита используемого container registry. Сопоставление данных аудита из двух систем совсем не назовешь надежным или удобным.
7. Безопасность Речь про запрет прямого доступа CI-системы к кластеру Kubernetes. На первый взгляд, наличие оператора, который находится внутри кластера и pull'ит изменения (без прямого доступа к кластеру извне), кажется более безопасным. Однако CI-система (или пользователь) по-прежнему должны иметь возможность отправлять образы в container registry и обновлять манифесты в Git'е. А это означает, что CI-система (или пользователь) уже имеют весь возможный доступ к кластеру. Изменение доступа с прямого на опосредованный не улучшает безопасность, а создает неправильное ощущение безопасности, что делает всю среду только менее защищенной. Вы должны обеспечить безопасность своего CI, других способов тут нет.

С чем мы вообще сравниваем GitOps?

Как обычно осуществляется доставка в Kubernetes? Самый очевидный и наиболее часто используемый способ это просто деплой из CI-системы. Этот подход иногда называют CIOps.

Как работает CIOps

Всё тоже начинается с Git-репозитория, но на этот раз не просто репозитория с манифестами Kubernetes. Это репозиторий приложения, который содержит:

• исходный код;
• Dockerfile(s);
• Kubernetes-манифесты, но теперь они представлены Helm-чартом;
• и скорее всего здесь же располагаются некоторые тесты.

К этому репозиторию подключена CI-система. Это может быть что угодно: Jenkins, GitLab CI/CD, GitHub Actions и т.д. У этой CI-системы есть следующие задания (или jobs, tasks, actions, stages как бы они ни назывались):

• Build для сборки образа;
• Unit test для запуска тестов на образе;
• Publish для публикации образа (или скорее даже образов) в реестре;
• Deploy to stage

На первый взгляд, это задание просто выполняет helm, которому передается чарт из Git. Но одного чарта недостаточно. Обычно вам также необходимо передать в Helm информацию о только что созданных образах: новые теги этих образов. На основе таких тегов Helm рендерит манифесты и отправляет их в Kubernetes API. А K8s в свою очередь уже приводит себя к заданному состоянию и вытягивает новые образы.

NB. Кстати, вы можете заменить Helm на любой другой инструмент: разницы не будет. В любом случае у вас есть какие-то шаблоны и теги Docker-образов. И теги будут использоваться для рендеринга (компиляции) этих шаблонов.

Вернемся к нашим заданиям, осталась еще парочка:

• E2e test для запуска end-to-end-тестов на развернутом приложении;
• Deploy to production делает то же самое, что и Deploy to stage, но для production-окружения.

Вот как обычно выглядит деплой в Kubernetes из CI-системы.


Обычная схема CIOps

Преимущества и недостатки CIOps

Давайте быстро оценим, как работает эта схема, по тем же критериям, что мы использовали для GitOps.

Прежде всего, что с детерминизмом? Бывает по-разному, но обычно всё плохо:

1. Во многих реализациях этого подхода я видел проблему в области сборки Docker-образов. Даже имея исходный код и Dockerfile в одном репозитории, а также действительно стараясь заморозить все внешние зависимости в нём же, мы всё равно в конечном итоге не получаем гарантии воспроизводимости наших сборок. Если по какой-либо причине мы соберем образ дважды (из одного и того же коммита), можно получить не только небольшие бинарные различия (потому что это два разных образа), но и два действительно разных образа (образы с разными содержимым).
   
   В Kubernetes нет проблем с детерминизмом процесса применения манифестов, однако сложность в том, чтобы сделать манифесты непротиворечивыми, повторимыми, воспроизводимыми одними и теми же каждый раз. Поскольку повторимость отрендеренных результатов во многом зависит от повторимости этапов сборки (и публикации), от детерминированности этапов сборки и публикации, конечный результат не получается консистивным и воспроизводимым, поэтому весь workflow получается недетерминированным.
2. Другая проблема заключается в стратегии тегирования. Найти способ воспроизводимого тегирования далеко не так просто. Наиболее естественной реализацией видится использование ID коммитов из Git'а. Можно сделать проверку наличия образа (в реестре) и, если образ с таким коммитом уже есть, пропустить сборку и публикацию, а если образа нет собирать образ и публиковать его. При таком подходе, если вы вызовете сборку несколько раз, второй и последующие вызовы ничего не поменяют.
   
   Однако я никогда не видел, чтобы в реальной жизни это делали правильно. Либо тег используется повторно, поэтому при повторном выполнении существующий образ заменяется в реестре (что обычно дает непредсказуемые результаты), либо стратегия тегирования основана на некоторых данных из CI-системы (идентификаторы заданий или что-то подобное).

Это означает, что нет и идемпотентности. Кстати, если некоторые шаги полагаются на данные из CI-системы, то состояние Kubernetes будет определять не только Git и container registry, но еще и CI-система

NB. Повторюсь, что в процессе применения манифеста нет проблем с идемпотентностью: проблема заключается в воспроизводимости в консистентности данных, которые мы передаем в Helm (которые передаются процессу рендеринга).

Таким образом, несмотря на то, что Helm-чарт находится в Git, несмотря на то, что Helm сам по себе идемпотентен (вы можете заменить Helm на kubectl или другой аналогичный инструмент), несмотря на то, что Dockerfile и исходный код также находятся в том же Git, весь workflow не является детерминированным и идемпотентным. Нет гарантии восстановления кластера до состояния конкретного коммита в Git.

Как вы уже знаете, идемпотентность и детерминизм составляют основу всего процесса. А когда их нет, все остальное разваливается:

• Больше нет конвергентности и наблюдаемости, потому что нет согласованного и повторяемого способа получить желаемое, целевое состояние (а как его тогда наблюдать?).
• Git не полностью определяет состояние, поэтому нет и аудита. История Git может что-то сказать, но это далеко не окончательный или единственный источник истины.
• Нужно ли говорить о безопасности? Замена прямого доступа на опосредованный ничего не меняет.

Зато всё хорошо с автоматизацией. Ведь CI-системы они про автоматизацию. Так что здесь вопросов нет: да, мы доставляем наши изменения автоматически. Просто эти изменения нам неизвестны

NB. Говоря об автоматизации, важно упомянуть еще одну вещь: обратную связь. Чтобы автоматизация работала правильно, необходимо предоставить пользователю четкую обратную связь. Когда мы разворачиваем приложения в Kubernetes, довольно часто попадаем в ситуацию, когда Helm (или kubectl apply) сообщает: Успешно применено. Однако это вовсе не означает, что наши изменения развернуты. Это лишь говорит о том, что запрос на развертывание приложений был успешно получен. Если вы попадали в подобную ситуацию, вам могут пригодиться werf или kubedog.

Подводя итог по CIOps: если все сделать правильно, такая схема может работать. Необходимо уделить достаточно внимания этапу сборки и тегированию, сделав их идемпотентными и детерминированными. Тогда в большинстве случаев вы мгновенно получаете все остальное (более или менее). Особенно, если вы не забываете об обеспечении понятной обратной связи.

Вот с чем мы должны сравнивать GitOps.

Но сделаю еще один шаг. Будьте честны с собой: как часто вам нужно повторно разворачивать приложение? Или развернуть его в каком-нибудь историческом состоянии? Если наступят плохие времена (авария в кластере или неизвестное изменение в кластере), мы будем глубоко опечалены Но если накатываем только новые изменения и если делаем это только последовательно, то ведь вполне себе можно жить с недетерминированным и неидемпотентным подходом.

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

GitOps или CIOps

Итак, на бумаге GitOps почти идеален, а CIOps очень плох. Однако совершенство GitOps (само по себе) вызывает сомнения. А CIOps, если все сделано правильно, может сработать или даже вполне хорошо работать. Но это всё ещё не полная картина.

Дело в том, что CiOps описывает весь процесс: от изменений, внесенных в Git приложения, до их развертывания в production-кластере Kubernetes, а GitOps охватывает только некоторую часть этого процесса. Давайте же посмотрим на всю картину.

GitOps на более полной схеме

Вернемся к схеме с GitOps. На самом деле, в Git-репозитории есть нескольких веток и, вероятно, есть несколько кластеров, например, для staging и production.


GitOps с разными ветками и кластерами

Но по-настоящему важно то, что основной Git-репозиторий, содержащий весь исходный код нашего приложения и все сопутствующие вещи, отсутствовал. Это тот самый репозиторий, который мы видели в CIOps. В дальнейшем будем называть их как репозиторий приложения (Application repo) и кластерный репозиторий (Cluster repo).

Затем весь процесс практически полностью повторяет CIOps. Задания в CI-системе:

• Build,
• Unit test,
• Publish,
• Deploy: начинаем с тех же шагов, забирая информацию об образах из задания Publish и передавая ее в Helm, но затем вместо того, чтобы вносить изменения напрямую в Kubernetes, мы делаем коммит в кластерный репозиторий.
  
  В то же время работает GitOps-оператор. И он либо замечает новые образы в container registry, либо новые манифесты в кластерном Git-репозитории. И выполняет свою работу: приводит Kubernetes к целевому состоянию.

Еще несколько вещей, на которые стоит обратить внимание:

1. У нас нет обратной связи в CI-системе: задание Deploy говорит, что все хорошо, потому что успешно коммитнуло новые манифесты в кластерный репозиторий. Однако это не означает, что изменения были успешно применены в кластере. Поэтому нужно заглянуть в какую-то другую систему И мы вынуждены делать это даже для того, чтобы проверить совсем простые вещи например, чтобы убедиться, валидны ли новые манифесты.
2. Система стала асинхронной. Например, GitOps-оператор может заметить новый образ в container registry до того, как новые манифесты будут коммитнуты (и увидены им). Таким образом, GitOps-оператор может применить старые манифесты с новыми образами, а вдруг они не подойдут друг другу?

Наконец, происходит деплой в production. В GitOps, чтобы сделать выкат в production, нужно выполнить merge из ветки staging в ветку production. (Возможно, вам также потребуется сделать promote образам из stage в production в реестре, хотя этого можно избежать, используя правильные стратегии тегирования.)



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

Даже если GitOps-часть делает все то, что о ней написано (а это не совсем так), общий workflow наследует все проблемы от CIOps и добавляет дополнительный уровень сложности.


При оценке GitOps важно учитывать весь CI-пайплайн

GitOps это антипаттерн?

Я считаю, что GitOps, реализованный описанным или подобным способом, на самом деле является антипаттерном. Вся культура DevOps говорит о плавности и непрерывности потока потока изменений от идеи/Git'а к production и о совместной работе. Однако такая реализация GitOps обманывает нас, обещая прозрачность и удобство, а на самом деле препятствует потоку ненужным промежуточным репозиторием, ненужной стеной между разработкой и эксплуатацией.

Но это мое мнение. Что неопровержимо, так это то, что нельзя сравнивать GitOps и CIOps. Правильным будет сравнение всего процесса, построенного вокруг GitOps, с CIOps. То есть GitOps плюс конвейеры против CIOps.

И что мы получим в таком случае?

• CIOps может быть неидемпотентным и недетерминированным и, будучи таковым, может вредить.
• Используя GitOps, мы получаем идемпотентность и детерминизм. Но
• Детерминизм в GitOps посредственный, потому что половина правды лежит не в Git, а в container registry.
• Другие минусы отустствие обратной связи там, где нам это нужно (в CI-системе, где разработчики всё делают), и повышенная сложность из-за новых элементов и введенной асинхронности.

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

Готов поспорить, что стандартная реализация GitOps будет заменена чем-то, что даст вам идемпотентность и детерминизм, но более практичным и удобным способом. Способом, совместимым с существующими подходами CI. Способом, не создающим стену. Будет ли этот подход называться GitOps 2.0?..

Эпилог про werf

Последние несколько лет мы в компании Флант работали над Open Source-инструментом werf. Как мне кажется, у нас получилось решить главный вызов всей этой истории (как я его вижу): мы смогли превратить основной Git-репозиторий (репозиторий приложения) в единственный источник истины. Для этого werf реализован таким образом, чтобы гарантировать идемпотентность и детерминизм этапов сборки, тегирования и деплоя. А все остальное построено на этом.



Интересно? Попробуйте! А для разработчиков, только начинающих знакомиться с утилитой, мы подготовили онлайн-самоучитель.

P.S.

Читайте также в нашем блоге:

• Что такое GitOps [по версии Weaveworks]?;
• GitOps: сравнение методов Pull и Push;
• werf наш инструмент для CI/CD в Kubernetes (обзор и видео доклада).

Мы собрали для вас короткий дайджест полезных материалов, найденных нами в сети за последние две недели. Оставайтесь с нами станьте частью 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

Helm, как и Docker стал де-факто стандартом в индустрии. Когда мы обсуждаем Kubernetes (52%). И новость, что Docker is deprecated вызвало волну обсуждений в сообществе. Настолько все привыкли к Docker.

Для Docker есть замечательный по своей простоте docker-compose, в котором мы можем декларативно описать, что мы хотим от Docker.

Для Kubernetes набор yaml-tpl файлов упаковывается в архив. И затем этот архив называется Helm-чартом. Но как это часто бывает приложение не может быть описано лишь одним Helm чартом. Требуется как-то управлять/композить/настраивать/шаблонизировать такие сеты.

Одним из подходов по управлению является Umbrella Chart. Это helm chart который объединяет в себе все другие чарты.

Очевидные минусы данного решения:

• Требуется поддерживать дополнительный чарт
• Новый слой согласования имен values переменных.
• Umbrella-chart это все тот же чарт, поэтому о шаблонизации values и декларативном разделении на контуры (Окружения) не может быть и речи.
• Когда обновляется саб-чарт, нужно идти в umbrella и обновлять еще версию umbrella чарта.

Helmwave возник, как инструмент для декларативного описания всех чартов в одном yaml.
Этот пост покажет как можно решить основные проблемы (use-cases) с помощью helmwave.

Что такое HelmWave?

• Это бинарь, который устанавливает helm release из helmwave.yml.
• Кладешь helmwave.yml в git и применяешь его через CI.
• Можно шаблонизировать все c помощью (Go template), начиная от helmwave.yml до values.
• Helmwave понимает какие helm-repositories ему понадобятся для деплоя. И вытесняет лишние.

Порядок комманд

graph TD;    Start(helmwave.yml.tpl) --render--> helmwave.yml;    helmwave.yml --planfile--> .helmwave;    .helmwave --sync--> Finish(Releases have been deployed!)

Быстрый старт

helmwave.yml.tpl имеет следующий вид

project: my-projectversion: 0.5.0repositories:  - name: bitnami    url: https://charts.bitnami.com/bitnami.options: &options  install: true  namespace: my-namespacereleases:  - name: redis-a    chart: bitnami/redis    options:      <<: *options  - name: redis-b    chart: bitnami/redis    options:      <<: *options

$ helmwave deploy

Поздравляю, вы задеплоили с помощью helmwave!

$ helm list -n my-namespaceNAME       NAMESPACE       REVISION     STATUS      CHART             APP VERSIONredis-a    my-namespace    1            deployed    redis-11.2.3      6.0.9      redis-b    my-namespace    1            deployed    redis-11.2.3      6.0.9  $ k get po -n my-namespace                                                                                                                         NAME               READY   STATUS    RESTARTS   AGEredis-a-master-0   1/1     Running   0          64sredis-a-slave-0    1/1     Running   0          31sredis-a-slave-1    1/1     Running   0          62sredis-b-master-0   1/1     Running   0          59sredis-b-slave-0    1/1     Running   0          32sredis-b-slave-1    1/1     Running   0          51s

Переменные окружения

$ helmwave help

• $HELMWAVE_TPL_FILE отвечает за путь к входному файлу для шаблонизации (helmwave.yml.tpl).
• $HELMWAVE_FILE указывает путь выходного файла после операции шаблонизации (helmwave.yml).
• $HELMWAVE_PLAN_DIR указывает путь к папке, в которой хранится или будет хранится план (.helmwave/).
• $HELMWAVE_TAGS массив строк, на основании которого будет проводится планирование.
• $HELMWAVE_PARALLEL включает/выключает многопоточность (рекомендуется включать).
• $HELMWAVE_LOG_FORMAT позволяет выбрать один из предустановленных форматов вывода.
• $HELMWAVE_LOG_LEVEL позволяет управлять детализацией вывода.
• $HELMWAVE_LOG_COLOR включает/выключает цвета для вывода.

Use-Cases

Примеры будут производиться, опираясь на gitlab-ci. Но это не помешает вам встроить helmwave в любой другой CI-инструмент.

Чем ниже, тем сложнее будут примеры.

Git tag > Docker tag

Допустим вы написали какой-то helm чарт для нашего приложения. Его values.yaml по умолчанию имеет вид:

image:  repository: registry.gitlab.local/example/app  tag: master

Необходимо чтобы image.tag брался из переменной CI

Приступим, создадим 2 файла.

. helmwave.yml.tpl values.yml

helmwave.yml.tpl

project: my-project # Имя проектаversion: 0.5.0 # Версия helmwavereleases:  - name: my-release    chart: my-chart-repo/my-app    values:      - values.yml    options:      install: true      namespace: my-namespace

values.yml

image:  tag: {{ env "CI_COMMIT_TAG" }}

Git commit --> PodAnnotations

Требуется чтобы deployment обновлялся только если у нас есть новый коммит.

deployment имеет примерно этот вид:

    ...    metadata:        {{- with .Values.podAnnotations }}        annotations:          {{- toYaml . | nindent 8 }}        {{- end }}    ...

Поэтому мы можем легко расширить предыдущий пример values.yml

image:  tag: {{ requiredEnv "CI_COMMIT_TAG" }}podAnnotations:    gitCommit: {{ requiredEnv "CI_COMMIT_SHORT_SHA" | quote }}

Контуры, окружения, environments

Структура каталога

. helmwave.yml.tpl values     _.yml     prod.yml     stage.yml

helmwave.yml.tpl

project: my-project  version: 0.5.0  releases:    - name: my-release      chart: my-chart-repo/my-app      values:        # Default        - values/_.yml        # For specific ENVIRONMENT        - values/{{ env "CI_ENVIRONMENT_NAME" }}.yml      options:        install: true        namespace: {{ env "CI_ENVIRONMENT_NAME" }}

values/_.yml Будет запускаться для любого окружения

image:  tag: {{ requiredEnv "CI_COMMIT_TAG" }}podAnnotations:    gitCommit: {{ requiredEnv "CI_COMMIT_SHORT_SHA" | quote }}

values/prod.yml Будет запускаться только для prod

replicaCount: 6

values/stage.yml Будет запускаться только для stage

replicaCount: 2

Используем внешний yaml и .Release.Store

Store это просто хранилище, которое можно задавать в helmwave.yml и передавать дальше в шаблонизацию values.

Допустим мы хотим связать путь к секрету в vault и путь к проекту в gitlab или вы хотите переопределять путь к image.repository. Это можно удобно сделать через Store.

. helmwave.yml.tpl values    _.yml vars     my-list.yaml

values/_.yml

vault: secret/{{ .Release.Store.path  }}/{{ requiredEnv "CI_ENVIRONMENT_NAME"  }}image:  repository: {{ env "CI_REGISTRY" | default "localhost:5000" }}/{{ .Release.Store.path }}

Добавим произвольный yaml файл.

vars/my-list.yaml

releases:  - name: adm-api    path: main/product/adm/api  - name: api    path: main/product/api

helmwave.yml.tpl

project: my-projectversion: 0.5.0.options: &options  install: true  wait: true  timeout: 5mreleases:  {{- with readFile "vars/my-list.yaml" | fromYaml | get "releases" }}  {{- range $v := . }}  - name: {{ $v | get "name" }}    chart: my-project/{{ $v | get "name" }}    options:      <<: *options    store:      path: {{ $v | get "path" }} # Set .Release.Store.path    tags:      - {{ $v | get "name" }}      - my    values:        # Default        - values/_.yml        # For specific ENVIRONMENT        - values/{{ env "CI_ENVIRONMENT_NAME" }}.yml  {{ end }}  {{- end }}

Запускаем!

$ CI_ENVIRONMENT_NAME=stage helmwave planfile

Появится helmwave.yml и папка .helmwave

$ tree .helmwave.helmwave planfile values     _.yml.adm-api@.plan     _.yml.api@.plan$ cat .helmwave/values/_.yml.api@.plan                            vault: secret/main/product/api/stage                                                               image:  repository: localhost:5000/main/product/api$ cat .helmwave/values/_.yml.adm-api@.plan                                  vault: secret/main/product/adm/api/stageimage:  repository: localhost:5000/main/product/adm/api

helmwave.yml

project: my-projectversion: 0.5.0.options: &options  install: true  wait: true  timeout: 5mreleases:  - name: adm-api    chart: my/adm-api    options:      <<: *options    store:      path: main/product/adm/api    tags:      - adm-api      - my    values:        # Default        - values/_.yml        # For specific ENVIRONMENT        - values/stage.yml  - name: api    chart: my/api    options:      <<: *options    store:      path: main/product/api    tags:      - api      - my    values:        # Default        - values/_.yml        # For specific ENVIRONMENT        - values/stage.yml

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

Структура проекта

Создадим в папке values 2 папки

• product здесь будут values для продуктов
• infrastructure здесь будет инфарструктурные values

values/infrastructure

• adminer веб морда для подключения к базе, полезна в основном только в dev-контурах
• postgresql база данных
• ns-ready здесь LimitRange, ResourcseQuota, Secrets, NetworkPolicy, etc
• rabbitmq общая шина между chat и api

values/product
Приложение состоит из 3 микросервисов

• api
• chat
• frontend

И еще нам понадобятся 2 отдельных файла описывающие массив product и массив infrastructure.

Структура проекта:

. helmwave.yml.tpl values    infrastructure       adminer          _.yml          dev.yml          stage.yml       ns-ready          _.yml       postgresql          _.yml          dev.yml       rabbitmq           _.yml           dev.yml           stage.yml    product        _           _.yml           dev.yml           prod.yml           stage.yml        api           _.yml           dev.yml           prod.yml           stage.yml        chat           _.yml        frontend            _.yml            dev.yml            prod.yml            stage.yml vars     infrastructure.yaml     products.yaml

vars/infrastructure.yaml

releases:  - name: postgresql    repo: bitnami    version: 8.6.13  - name: adminer    repo: cetic    version: 0.1.5  - name: rabbitmq    repo: bitnami    version: 7.6.6  - name: ns-ready    repo: my-project    version: 0.1.1

vars/products.yaml

releases:  - name: adm-api    path: rdw/sbs/adm/api  - name: frontend    path: my-project/internal/frontend  - name: api    path: my-project/internal/api  - name: chat    path: my-project/internal/chat

helmwave.yml.tpl

project: my-projectversion: 0.5.0repositories:  - name: bitnami    url: https://charts.bitnami.com/bitnami  - name: cetic    url: https://cetic.github.io/helm-charts.options: &options  install: true  wait: true  timeout: 5m  atomic: false  maxhistory: 10  namespace: {{ requiredEnv "HELM_NS" }}releases:  {{- with readFile "vars/products.yaml" | fromYaml | get "releases" }}  {{- range $v := . }}  - name: {{ $v | get "name" }}    chart: my-project/{{ $v | get "name" }}    options:      <<: *options    store:      path: {{ $v | get "path" }}    tags:      - {{ $v | get "name" }}      - product    values:      # all products & all envs      - values/product/_/_.yml      # all products & an env      - values/product/_/{{ requiredEnv "CI_ENVIRONMENT" }}.yml      # a product & all envs      - values/product/{{ $v | get "name" }}/_.yml      # a product & an env      - values/product/{{ $v | get "name" }}/{{ requiredEnv "CI_ENVIRONMENT" }}.yml  {{ end }}  {{- end }}  {{- with readFile "vars/infrastructure.yaml" | fromYaml | get "releases" }}  {{- range $v := . }}  - name: {{ $v | get "name" }}    chart: {{ $v | get "repo" }}/{{ $v | get "name" }}    options:      <<: *options      chartpathoptions:        version: {{ $v | get "version" }}    tags:      - {{ $v | get "name" }}      - infrastructure    values:      # a svc & all envs      - values/infrastructure/{{ $v | get "name" }}/_.yml      # a svc & an env      - values/infrastructure/{{ $v | get "name" }}/{{ requiredEnv "CI_ENVIRONMENT" }}.yml  {{ end }}  {{- end }}

Контуры в Store

Допустим у нас есть 2 окружения dev и prod.
И в prod'e нам не нужна база данных

vars/infrastructure.yaml

releases:  - name: rabbitmq    repo: stable    version: 6.18.2    envs:      - _ # all environments    tags:      - queue  - name: postgresql    repo: bitnami    version: 8.6.13    envs:      - dev # only dev    tags:      - db

# vim: set filetype=yaml:{{- $env := requiredEnv "CI_ENVIRONMENT" }} # Look at this firstproject: insiderversion: 0.5.0repositories:  - name: stable    url: https://kubernetes-charts.storage.googleapis.com  - name: bitnami    url: https://charts.bitnami.com/bitnami.options: &options  install: true  wait: true  force: false  timeout: 5m  atomic: false  maxhistory: 10  namespace: {{ requiredEnv "HELM_NS" }}releases:  {{- with readFile "vars/infrastructure.yaml" | fromYaml | get "releases" }}  {{- range $v := . }}  {{- $envs := $v | get "envs" }}  {{- if or (has "_" $envs) (has $env $envs) }}  - name: {{ $v | get "name" }}    chart: {{ $v | get "repo" }}/{{ $v | get "name" }}    options:      <<: *options      chartpathoptions:        version: {{ $v | get "version" }}    tags:      - {{ $v | get "name" }}      - infrastructure      {{- if $v | hasKey "tags" }}      - {{ $v | get "tags" | toYaml }}      {{- end }}    values:      # a svc & all envs      - values/infrastructure/{{ $v | get "name" }}/_.yml      # a svc & an env      - values/infrastructure/{{ $v | get "name" }}/{{ $env }}.yml  {{ end }}  {{- end }}  {{- end }}

База по умолчанию выключена

$ helmwave planfile

Чтобы postgresql включился

$ CI_ENVIRONMENT=dev helmwave planfile

Giltab-CI Pipelines

Рассмотрим шаблон gitlab-ci с использованием helmwave из проекта g-ci

variables:  HELMWAVE_LOG_LEVEL: debug.helmwave-deploy:  stage: deploy  environment:    name: ref/$CI_COMMIT_REF_SLUG  image:    name: diamon/helmwave:0.5.0    entrypoint: [""]  script:    - helmwave deployhelmwave deploy:  extends: .helmwave-deploy

С использованием include

include: https://gitlab.com/g-ci/deploy/-/raw/master/helmwave.ymlhelmwave deploy:  environment:    name: prod

P.S.

Helmwave source: https://github.com/zhilyaev/helmwave/
G-CI: https://gitlab.com/g-ci
Приходите к нам в telegram с любыми вопросами!

Взрывной рост использования контейнеров на предприятиях впечатляет. Контейнеры идеально совпали с ожиданиями и потребностями тех, кто хочет снизить затраты, расширить свои технические возможности и продвинуться вперед по пути agile и devops. Контейнерная революция открывает новые возможности и для тех, кто подзадержался с обновлением ИТ-систем. Контейнеры и Kubernetes это абсолютно и принципиально новый способ управления приложениями и ИТ-инфраструктурой.



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

Многие решают ускорить переход на контейнеры с помощью Red Hat OpenShift Container Platform, ведущей отраслевой Kubernetes-платформы для корпоративного сектора. Это решение автоматически берет на себя множество задач первого дня и предлагает лучшую Kubernetes-экосистему на базе единой, тщательно протестированной и высоко защищенной платформы. Это наиболее комплексное и функциональное решение для предприятий, которое содержит всё необходимое для начала работы и устраняет массу технических барьеров и сложностей при построении Kubernetes-платформы.

Тем не менее, OpenShift это не волшебная палочка, которая решает все проблемы сама. Да, благодаря своим возможностям, эта платформа способна принести и приносит своим заказчикам массу пользы и быстро окупается, но при условии, что на момент ее запуска у вас есть хорошо продуманный план. Чтобы добиться успеха, надо тщательно проработать семь областей, прежде чем приступать к переносу каких-либо рабочих нагрузок на OpenShift.

1. Стандартизация правил именования и метаданных

В компьютерных науках есть только две трудные вещи: аннулирование кэша и именование сущностей.
Фил Карлтон (Phil Karlton)

У всякой сущности в OpenShift и Kubernetes есть свое имя. И у каждого сервиса должно быть свое DNS-имя, единственное ограничение здесь правила именования DNS. А теперь представьте, что монолитное приложение разложилось на 100500 отдельных микросервисов, каждый с собственной базой данных. И да, в OpenShift всё является либо иерархическим, связанным, либо должно соответствовать шаблону. Так что именовать придется массу и массу всего. И если заранее не подготовить стандарты, это получится настоящий Дикий Запад.

Вы уже распланировали схему реализации сервисов? Допустим, это будет одно большое пространство имен, например, databases, в котором все будут размещать свои базы данных. OK, и даже допустим, что все так и будут делать, но потом-то они начнут размещать свои кластеры Kafka в своих собственных пространствах имен. Да, а нужно ли заводить пространство имен middleware? Или лучше назвать его messaging? И как обычно, в какой-то момент появляются ребята, которые всегда идут своим путем и считают себя особенными, и говорят, что им нужны собственные пространства имен. И слушайте, у нас же в организации 17 подразделений, может надо приделать ко всем пространствам имен наши стандартные префиксы подразделений?

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

Другая мегаполезная вещь это метаданные. Стандартизируйте, какие активы хотите отслеживать, и убедитесь, что на соответствующих ресурсах прописаны нужные метаданные. Начните с рекомендованных меток. Например, аннотация support_email в метаданных пространства имен может сэкономить драгоценное время при выходе на техподдержку второго уровня в случае серьезного отказа. Кроме того, метаданные можно использовать, чтобы сократить имена ресурсов до вменяемой длинны, а не прописывать туда всю необходимую информацию через дефис. Привлеките всех, от архитекторов приложений до ИТ-эксплуатантов, устройте мозговой штурм и просчитайте наперед, что может здесь понадобиться, чтобы иметь продуманные стандарты к моменту запуска OpenShift.

2. Стандартизация корпоративных базовых образов

Одна из ключевых фишек контейнеров это возможность миксовать и подбирать все составляющие программного стека. Можно, конечно, взять любимую разновидность ОС и строить все на ней, но действуя подобным образом организация упускает огромные возможности. Ведь что по-настоящему круто в контейнерных образах? Многослойность. Вы можете снять с разработчиков массу критичных задач и решать их за счет стандартизации образов.

Возьмем, к примеру, базовое java-приложение. Ваши разработчики вряд ли ошибутся с выбором OpenJDK, а вот с управлением уязвимостями, обновлением библиотек и прочими вопросами ИТ-гигиены вполне могут. Мы все знаем, что бизнес-задачи зачастую решаются ценой технических компромиссов, вроде намеренного использования старых версий Java. К счастью, такие задачи легко автоматизируются и управляются на уровне предприятия. Вы по-прежнему может использовать базовые образы вендора, но одновременно задавать и контролировать свои циклы обновления, создавая собственные базовые образы.

Возвращаясь к примеру выше, допустим, разработчикам нужна Java 11, а вам, соответственно, надо, чтобы они всегда использовали самую последнюю версию Java 11. Тогда вы создаете корпоративный базовый образ (registry.yourcompany.io/java11), используя в качестве отправной точки базовый образ от вендора ОС (registry.redhat.io/ubi8/openjdk-11). А когда этот базовый образ обновляется, вы автоматом помогаете разработчикам задействовать последние обновления. К тому же, таким образом реализуется уровень абстракции, позволяющий бесшовно дополнять стандартный образ необходимыми библиотеками или Linux-пакетами.

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

Контроль исправности, он нужен практически везде. Считается, что для человека достаточно ежегодного медосмотра. Исправность приложений надо проверять, понятно, гораздо чаще, и контролировать две ключевые вещи:

• Запущено ли приложение (health check работоспособность).
• Готово ли приложение (readiness check готовность).

Существует масса и других метрик, чтобы облегчить мониторинг приложений, но вот эти две это основа основ не только мониторинга, но и масштабирования. Работоспособность обычно определяется наличием сетевого подключения и способностью узла, на котором выполняется приложение, отозваться на запрос. Что касается готовности, то здесь уже каждое приложение должно реагировать на запросы по своим стандартам. Например, запуск приложения с очень низкими задержками может сопровождаться длительным обновлением кэша или прогревом JVM. И соответственно, пауза между ответами Запущено и Готово может достигать нескольких минут. А вот, например, для stateless REST API с реляционной базой данных эти ответы будут приходить одновременно.

Самое главное в этих проверках не отходить от сугубо двоичной логики. Запущено значит запущено, без всяких там как бы запущено. Готово значит готово, и никаких градаций, вроде на такие запросы готово отвечать, а на такие нет. Принцип простой: всё или ничего.

Второй аспект таких проверок это стандартизация. Как проверить готовность? Если у вас нет стандартов, то даже такой простой вопрос может стать настоящим кошмаром для мониторинга. Просто сравните, как разошлись друг от друга стандарты Quarkus и стандарты Spring Boot. А ведь никто этого не хотел, но со стандартами всегда так. Единственная разница в том, что теперь ваша организация сама имеет власть разрабатывать и вводить стандарты.
Примечание на полях. Не изобретайте свои стандарты. Просто найдите и используйте какой-нибудь готовый.

4. Стандартизация логов

Продолжая тему мониторинга, отметим, что сочетание недорогих хранилищ и решений класса big data породило на предприятиях нового монстра тотальное журналирование. Раньше это были неструктурированные и архаичные консольным логи, которые жили недолго и создавались от случая к случаю. Теперь норовят запротоколировать всё подряд и выстроить датасайнс с машинным обучением, чтобы самым революционным образом оптимизировать операции и мониторинг. Увы, надо признать очевидное: любые попытки начать собирать логи сотен приложений, не имея при этом абсолютно никаких стандартов и даже не задумываясь о них, неизменно приводят к бессмысленным и непомерным тратам на инструменты для управления логами и трансформации данных лишь для того, чтобы только начать работу. То есть еще до того, как вы поймете, что сообщения Выполнен переход или Этот блок сработал вряд имеют хоть какое-то отношение к вашим операциям.

Стандартизировать надо структуру. Повторимся: целостность стандартов важнее их правильности. Вы должны быть способы написать отдельный лог-парсер для каждого приложения, которое есть на предприятии. Да, это будут сугубо штучные, не тиражируемые вещи. Да, у вас будет куча исключений, которые нельзя контролировать, особенно для коробочных приложений. Но не выплескивайте ребенка вместе с водой, уделите внимание деталям: например, временная метка в каждом логе должна отвечать соответствующему стандарту ISO; сам вывод должен быть в формате UTC с точностью до 5-го знака в микросекундах (2018-11-07T00:25:00.07387Z). Уровни журнала должны быть оформлены CAPS-ом и там должны быть элементы TRACE, DEBUG, INFO, WARN, ERROR. В общем, задайте структуру, а уже затем разбирайтесь с подробностями.

Стандартизация структуры заставит всех придерживаться одних правил и использовать одни и те же архитектурные шаблоны. Это верно для логов как приложений, так и платформ. И не отклоняйтесь от готового решения без крайней нужды. EFK-стек (Elasticsearch, Fluentd и Kibana) платформы OpenShift должен быть в состоянии обработать все ваши сценарии. Он ведь вошел в состав платформы не просто так, и при ее обновлении это еще одна вещь, о которой не надо беспокоиться.

5. Переход на GitOps

Одна из главных прелестей OpenShift заключается в том, что здесь всё буквально: всё в конечном является либо конфигурацией, либо кодом, а значит, может контролироваться через систему управления версиями. Это позволяет революционизировать способы доставки и избавиться от бюрократии при запуске в продакшн.

В частности, традиционную схему на основе тикетов можно полностью заменить на модель с pull-запросами git. Допустим, владелец приложения хочет подкорректировать выделяемые приложению ресурсы после реализации в нем новых функций, например, увеличить память с 8 до 16 ГБ. В рамках традиционной схемы разработчику для этого надо создать тикет и ждать, пока кто-то другой выполнит соответствующую задачу. Этим кем-то другим чаще всего оказывается ИТ-эсплуатант, который лишь вносит ощутимую задержку в процесс реализации изменений, никак не повышая ценность этого процесса, или хуже того, навешивая на этот процесс лишние дополнительные циклы. В самом деле, у эсплуатанта есть два варианта действий. Первое: он рассматривает заявку и решает ее выполнить, для чего входит в продакшн-среду, вносит затребованные изменения вручную и перезапускает приложение.
Помимо времени на проведение самой работы здесь возникает и дополнительная задержка, поскольку у эксплуатанта, как правило, всегда есть целая очередь заявок на выполнение. Кроме того, возникает риск человеческой ошибки, например, ввод 160 ГБ вместо 16 ГБ. Второй вариант: эксплуатант ставит заявку под сомнение и тем самым запускает цепную реакцию по выяснению причин и последствий запрашиваемых изменений, да так, что иногда уже приходится вмешиваться начальству.

Теперь посмотрим, как это делается в GitOps. Запрос на изменения попадает в репозиторий git и превращается в pull-запрос. После чего разработчик может выставить этот pull-запрос (особенно, если это изменения в продакшн-среде) для утверждения причастными сторонами. Таким образом, специалисты по безопасности могут подключиться уже на ранней стадии, и всегда есть возможность отследить последовательность изменений. Стандарты в этой области можно внедрять программно, используя соответствующие средства в инструментальной цепочке CI/CD. После того, как его утвердили, pull-запрос версионируется и легко поддается аудиту. Кроме того, его можно протестировать в среде pre-production в рамках стандартного процесса, полностью устранив риск человеческой ошибки.

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

6. Схемы приложений (Blueprints)

Переход от монолитных приложений к микросервисам усиливает роль шаблонов проектирования (паттернов) приложений. В самом деле, типичное монолитное приложение не особо поддается классификации. Как правило, там есть и REST API, и пакетная обработка, и событиями оно управляется. HTTP, FTP, kafka, JMS и Infinispan? Да пожалуйста, а еще оно одновременно работает с тремя разными базами данных. И как прикажете создавать схему, когда здесь намешана целая куча шаблонов интеграции корпоративных приложений? Да никак.

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

• REST API для управления данными в СУБД.
• Пакетная обработка, которая проверят FTP-сервер на предмет обновления данных и отправляет их в топик kafka.
• Camelадаптер, берущий данные из этого kafka-топика и отправляющий их в REST API
• REST API, которые выдают обобщенную информацию, собираемую из Data Grid, которая действует как конечный автомат.

Итак, теперь у нас есть схемы, а схемы уже можно стандартизировать. REST API должны отвечать стандартам Open API. Пакетные задания будут управляться как пакетные задания OpenShift. Интеграции будут использовать Camel. Схемы можно создавать для API, для пакетных заданий, для AI/ML, для multicast-приложений, да для чего угодно. А затем уже можно определять, как развертывать эти схемы, как их конфигурировать, какие шаблоны использовать. Имея такие стандарты, не надо будет каждый раз изобретать колесо, и вы сможете лучше сфокусироваться на действительно важных задачах, вроде создания нового бизнес-функционала. Проработка схем может показаться пустой тратой времени, но затраченные усилия сторицей вернутся в будущем.

7. Подготовьтесь к API

Вместе с микросервисной архитектурой приходят и API. Ими тоже придется управлять и лучше подготовиться к этому заранее.

Во-первых, здесь опять понадобятся стандарты. В качестве отправной точки можно взять стандарты Open API, но придется углубиться в дебри. Хотя здесь важно соблюсти баланс и не впасть в чрезмерную зарегламентированность с кучей ограничений. Посмотрите на эти вопросы: когда новая сущность создается с помощью POST, что надо возвращать, 201 или 200? разрешается ли обновлять сущности с помощью POST, а не PUT? В чем разница между 400-ми и 500-ми ответами? примерно такой уровень детализации вам нужен.

Во-вторых, понадобится сервисная сетка service mesh. Это реально сильная вещь и со временем она станет неотъемлемой частью Kubernetes. Почему? Потому что трафик рано или поздно превратится в проблему, и вам захочется управлять им как внутри дата-центра (т.н. трафик восток-запад), так и между дата-центром и внешним по отношению к нему миром (север-юг). Вам захочется вытащить из приложений аутентификацию и авторизацию и вывести их на уровень платформы. Вам понадобятся возможности Kiali по визуализации трафика внутри service mesh, а также сине-зеленые и канареечные схемы развертывания приложений, или, к примеру, динамический контроль трафика. В общем, service mesh без вопросов входит в категорию задач первого дня.

В-третьих, вам понадобится решение для централизованного управления API. Вам захочется иметь одно окно для поиска и повторного использования API. Разработчикам понадобится возможность зайти в магазин API, найти там нужный API и получить документацию по его использованию. Вы захотите единообразно управлять версиями и deprecation-ами. Если вы создаете API для внешних потребителей, то такое решение может стать конечной точкой север-юг во всем, что касается безопасности и управления нагрузкой. 3Scale даже может помочь с монетизицией API. Ну и рано или поздно ваше руководство захочет получить отчет, отвечающий на вопрос Какие у нас есть API?.

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

Однако, надежда есть, и она заключается в автоматизации. Любой из перечисленных выше стандартов можно внедрить с помощью автоматизации. Процесс GitOps может проверять, что во всех соответствующих yaml-файлах присутствуют все требуемые метки и аннотации. Процесс CI/CD может контролировать соблюдение стандартов на корпоративные образы. Все может быть кодифицировано, проверено и приведено в соответствие. Кроме того, автоматизацию можно доработать, когда вы вводите новые стандарты или меняете существующие. Безусловное преимущество стандартизации через автоматизацию заключается в том, что компьютер не избегает конфликтов, а просто констатирует факты. Следовательно, при достаточной проработанности и инвестициях в автоматизацию, платформа, в которую вы вкладываете столько средств сегодня, может принести гораздо больший возврат инвестиций в будущем в виде повышения производительности и стабильности.