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

В конце прошлого года в Слёрме вышел видеокурс по CI/CD. Авторы курса инженер Southbridge Александр Швалов и старший системный инженер Tinkoff Тимофей Ларкин ответили на вопросы первых студентов.

В частности, обсудили:

• Как работает GitLab runner: сколько задач берёт и сколько ресурсов потребляет, где его лучше размещать и как настроить шаринг между проектами?
• Как настраиваются пайплайны для проектов в монорепозитории? А как в ситуации, когда для каждого микросервиса свой репозиторий?
• Как бороться с тем, что во время сборки артефакта в Docker очень быстро забивается свободное место на диске?
• Когда лучше использовать подход Docker-in-Docker?
• Как организовать доставку и развёртывание сервисов в закрытые окружения заказчика?

Видео с ответами на вопросы смотрите на YouTube. Под катом текстовая версия разговора.

С версии 20.10 Docker Engine стал rootless. Раньше эта фича была экспериментальной, а теперь оказалась в проде. Изменится ли что-то с точки зрения безопасности и сборки Docker-образов без root-привилегий?

Тимофей Ларкин: Я не думаю, что это сильно на что-то повлияет. Возможно, они идут к тому, чтобы появился отдельный сборщик образов от Docker. Но пока мы используем Docker-in-Docker, и, скорее всего, этот Docker-in-Docker в режиме rootless просто не будет запускаться.

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

Александр Швалов: В документации Gitlab есть открытый баг (issue), мол, давайте включим режим rootless, но официальной поддержки пока нет. Для сборки поддерживается kaniko, и мы добавили пример с kaniko в наш курс.

Дайте пример реального размещения репозиториев с кодом, секретами и helm-чартами где всё должно лежать в жизни? Как выглядит по умолчанию шаблон? Боевой deployment.yml не должен быть в репозитории сервиса?

Тимофей Ларкин: Ответ на такие вопросы всегда it depends зависит от ситуации. Если это open source проект, то там может и не быть деплойментов, там может быть makefile, который покажет, как собрать артефакт, как из него собрать Docker-образ. Но это репозиторий на Github, в лучшем случае он через github actions делает регулярные билды и кладёт их на Docker Hub или другой репозиторий образов контейнеров. Оно и понятно: это просто open source проект, куда его деплоить.

Другое дело, если это проект, который вы деплоите на инфраструктуре: своей, облачной неважно. Например, это приложение, которое разрабатывается и используется у вас в компании. Действительно, довольно простой способ держать и код, и скрипты сборки артефактов, и какой-нибудь helm-чарт в одном репозитории. Разнести по разным папкам, а GitLab CI будет и собирать, и сохранять артефакты, и пушить изменения в Kubernetes.

Подход не очень масштабируемый: когда приложений много, становится тяжело отслеживать, что задеплоено в Kubernetes. Чтобы решить проблему, подключают сервисы вроде Argo CD, а код и описание конфигурации хранят в разных репозиториях. Деплоят через CI (push-модель) или через кубы в Argo.

Когда компания занимается заказной разработкой, всё ещё сложнее. Встаёт вопрос, как деплоить код на инфраструктуру заказчика, и готов ли он принять Continuous Deployment исполнителя или хочет больше контроля? Надо смотреть на специфику.

Александр Швалов: У каждой команды свои стандарты, некоторые сложились исторически, некоторые появились на основе шаблонов или документации. В нашем курсе по CI/CD есть примеры, они рабочие можете адаптировать под свой проект. Исходите из своих потребностей.

Есть ли краткий справочник по полям gitlab-ci файла?

Александр Швалов: Краткого справочника нет, если нужна конкретная фича, лучше идти в документацию и смотреть, что там есть. Ну а базовые принципы как из большого набора кирпичиков собрать свой gitlab-ci.yml вы можете почерпнуть из курса или документации. Если в курсе нет, в документации точно будет.

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

Как можно привязать Jira к GitLab?

Александр Швалов: У бесплатной версии GitLab есть интеграция с Jira, ищите в соответствующем разделе.

Тимофей Ларкин: Более того, мы работали одновременно с двумя issue-трекерами: все проекты вязались в Jira, но отдельные команды настраивали для своих репозиториев привязку к YouTrack. Это было не очень удобно, потому что надо было ходить по каждому репозиторию, который хочешь привязать. Но да, такая функциональность действительно есть даже в бесплатном GitLab.

Почему joba release триггерится при изменении тега, хотя в родительском пайплайне стоит only changes?

Александр Швалов: Я провёл небольшое исследование и выяснил: это не баг, это фича. В GitLab был заведён баг, и его закрыли с комментарием, что так задумано. Если вам нужно обойти это поведение, используйте один из двух вариантов, которые предлагает GitLab.

GitLab не обновляет статусы дочерних пайплайнов. Что с этим делать?

Александр Швалов: А вот это уже баг. Возможно, когда-нибудь починят.

Есть ли в GitLab профили переменных? Например, я хочу сделать переменную host, и чтобы она приезжала разная в зависимости от окружения. Есть ли какое-нибудь профилирование? Например, я не хочу называть переменную host_dev, host_prod и host_test, а хочу указать окружение, и оно определённый набор переменных вытащит? Можно ли такое сделать?

Тимофей Ларкин: С ходу на ум мало что приходит. Можно, наверное, какие-то env-файлы держать в репозитории и просто их сорсить в пайплайне.

Нормальная практика называть host_dev, host_prod, host_test и т. д?

Александр Швалов: Скорее всего, есть встроенные переменные. Если у вас описано разделение по окружениям, то встроенная переменная будет знать, как называется окружение.

Тимофей Ларкин: Я не сталкивался с таким наименованием переменных. Это кажется оправданным, только если один пайплайн должен работать одновременно с несколькими разными окружениями. Если просто хочется разного поведения пайплайна в зависимости от ветки или чего угодно ещё

У меня в пайплайне может быть стадия deploy и стадия release, и тогда эти переменные должны быть разные, иначе как?

Тимофей Ларкин: То есть сначала один job деплоит на stage, а потом следующий job деплоит на prod?

Нет, job, который на prod работает, он срабатывает, когда only text. Всё это описано в одном пайплайне.

Тимофей Ларкин: Я решал это ямловскими (YAML прим. редактора) якорями, у меня были очень однотипные jobы из трёх строчек. Или можно теми же extends, как в примере с Docker. А дальше в каждом job пишешь свой блок variables, поэтому основное тело jobа работает с одними и теми же скриптами, но в зависимости от значения переменной host или переменной environment, оно деплоит на разное окружение.

Мы не имеем разные переменные для разных jobов, мы используем одни и те же названия переменных, просто с разными значениями. Возможно, оправдано в репозиторий поместить какие-то скрипты, которые сами внутри себя это разруливают, чтобы не раздувать gitlab-ci.yml.

SSH executor создаётся по одному на сервер?

Тимофей Ларкин: Фактически да. Можно, разве что, поставить какой-нибудь tcp-балансировщик и рандомно попадать на тот или иной сервер.

Имеет смысл разделять раннеры, которые деплоят на test и staging, и раннеры, которые деплоят на prod?

Тимофей Ларкин: Наверное, можно. Действительно, запустить раннеры в разных сетевых сегментах, которые не могут общаться друг с другом. В моей практике это не было нужно. У нас была ориентированная на Kubernetes система, а если речь идёт про SSH на тот сервер, SSH на этот сервер наверное, это будет оправдано.

В Kubernetes вы, наверное, по разным namespace деплоили и всё?

Тимофей Ларкин: Да, но при этом все раннеры в одном и том же месте запускались. Был отдельный namespace для раннеров.

Правильно ли я понимаю, что раннер берёт только одну задачу? Потому что иначе переменные окружения пересекутся.

Тимофей Ларкин: Необязательно, это зависит от того, какой executor работает.

Александр Швалов: Есть параметр concurrency. Если раннер один и идёт долгий пайплайн, то получается, что остальные девелоперы сидят и курят бамбук мы такое проходили, и для обхода настраивали concurrency. В зависимости от ресурсов раннера: сколько jobов он потянет одновременно, можно настраивать.

Он под каждую jobу своё окружение создаст?

Тимофей Ларкин: Да, он либо свой инстанс в bash запустит, либо несколько SSH-подключений, либо несколько Docker-контейнеров или подов в Kubernetes.

Есть ли в Argo CD и других GitOps-инструментах возможность параметризации реакции на изменения? Например, обновлять prod окружение, только если мастер + тэг или если фича, то в dev окружении менять состояние/производить обновления?

Тимофей Ларкин: В вопросе есть очень распространённое заблуждение, я и сам на нём спотыкался. Надо запомнить: не бывает, чтобы у нас был тег на мастер-ветке. Тег никогда на ветке не бывает. Где-то в GitLab даже есть issue, который это очень подробно объясняет. Но это лирическое отступление.

В принципе, Argo CD может что-то похожее сделать. Но надо понимать, что он не совсем про это. Его основная и довольно простая функция это чтобы в таком-то месте (namespace или кластере Kubernetes) была задеплоена такая-то ветка, такой-то тег определённого репозитория.

Как мне показалось, в вопросе речь была о пайплайнах и CI/CD. Но это не основная функциональность Argo, и кажется, он такого не поддерживает. Можно посмотреть на другие GitOps-инструменты. По-моему, у werf от Фланта есть функционал отслеживания что там меняется в Docker-репозитории. Но в целом GitOps это не совсем про это. Вот как в гите опишите, то и будет задеплоено.

На коммит Argo увидит: О! Что-то поменялось, значит надо поменять это и в Kubernetes, но без какой-то сильно ветвистой логики.

Александр Швалов: Я добавлю, что тэг это не ветка, а по смыслу ближе к коммиту. Тут поможет семантическое версионирование, и можно настраивать шаблоны для Argo CD. Если для продакшена, то конкретный релиз: 1.2.0, 1.2.1. Для stage будет 1.2. любая циферка в конце приедет на stage. Для QA это 1. всё остальное приедет. Для совсем свежего, для локальной разработки просто звёздочка *, любой тег Argo CD будет сразу подтягивать.

Какой сканер посоветуете для Docker-образов? Мне trivy понравился, но может что удобнее есть?

Александр Швалов: Я использовал Trivy, нареканий не было.

Как настраиваются пайплайны для проектов в монорепе, и как в ситуации, когда для каждого микросервиса свой репозиторий?

Александр Швалов: Возможно, мы добавим такой пример в курс. Спасибо за запрос! Вообще, ходят слухи, что у Google и Microsoft всё хранилось или хранится в монорепах миллиарды строк кода. Здесь многое зависит от человеческого фактора, а не от инструментов. Если говорить о GitLab CI/CD, то всё просто: в шаге сборки какой-то части, например, фронтенда используем only changes, выбираем каталог и дальше поехали. Что-то изменилось, GitLab производит деплой. С тестами будет посложнее, потому что фронтенд (или какая-то часть, особенно, если это микросервисы) запустится и будет неполноценным. Поэтому для тестов придётся поднимать минимальные зависимости.

Тимофей Ларкин: Я не видел open source систем контроля версий, которые поддерживают такую модель работы, как монорепозиторий. У больших игроков свои системы, и разработчики даже рассказывают: Вот, я работал в Google/Amazon/Facebook, а потом я ушёл оттуда, пошёл в среднего размера компанию, и я не знаю, что делать. Нигде нет магии этих больших систем, которые сами решают все проблемы с версионированием кода. Внезапно я должен работать с тем же GitLab.

Поэтому если вы не огромная корпорация с ресурсом написать свою систему контроля версий, то можно костылить пайплайны, чтобы они были как монорепозитории писать кучу only changes на различные куски. До каких-то масштабов это, наверное, будет работать. Взять тот же Kubernetes, который выпускает свои известные 5 бинарей (и даже чуть больше) с параллельным версионированием. Нет такого, что один компонент в своём репозитории, другой в своём, и у них свой набор версий. Нет, они выпускаются из одного репозитория, поэтому у них хэши комитов, теги и всё остальное одинаковое. Да, так можно работать. Go позволяет собирать несколько бинарников из одного модуля, но в целом так не очень легко работать. Для какого-то проекта да.

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

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

Какие существуют best practices по размещению раннеров? Как лучше организовать размещение нескольких раннеров на одной машине, чтобы можно было добавлять новые? Стоит ли размещать раннеры в Docker-контейнерах, или лучше использовать виртуальные машины, например, kvm?

Александр Швалов: GitLab для раннеров по запросу предлагает использовать Docker Machine, и соответственно использует драйверы оттуда это всяческие облака и виртуализации (AWS, Azure, VirtualBox, Hyper V, vmWare). KVM в списке нет. Для множественных раннеров можно настраивать также шареный кэш. Например, в AWS S3 хранилище.

Однако этот подход через Docker Machine сам GitLab считает малость устаревшим. Есть открытый баг, где разработчики размышляют, куда лучше перейти, какие-то варианты есть. Самый очевидный перейти в Kubernetes. Ну а best practice в общем не размещать раннер на одном хосте с GitLab, чтобы они друг друга не аффектили. Ну и на продакшене раннер тоже лучше не размещать, потому что вдруг туда что-то прилетит критичное.

Для небольших проектов достаточно одного раннера (на своих проектах я так и делал). Просто настроить ему concurrency, чтобы разработчики не стояли в очереди друг за другом, и дать какое-то количество процессора и памяти, настроить опытным путём и так жить.

Тимофей Ларкин: Когда мы пайплайны гоняли в Kubernetes, то мы просто на несколько хостов вешали taint с эффектом PreferNoSchedule, чтобы пользовательские нагрузки приложения запускались преимущественно где-то на других хостах. Но при этом на раннеры мы вешали nodeSelector как раз на эти же самые хосты. Это к вопросу о разделении нагрузки от приложения и нагрузки от раннера.

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

Из-за всех этих неровностей лучше раннеры держать подальше от обычных приложений. И они достаточно много ресурсов требуют. Когда мы занимались ограничениями, мы ставили командам лимит 4 ядра, и у них сборка какой-нибудь тяжелой Java существенно замедлялась.

С Kubernetes всё понятно. Мне даже хотелось убрать раннеры из Kubernetes и где-то отжать два хоста, которые использовать как build-серверы, чтобы совсем всё отдельно было. Всякие деплои, понятно, это очень легковесная задача. Запушить ямлик в Kubernetes никаких ресурсов не требует. Ну а если у нас SSH или shell-раннер, то тогда сама ситуация диктует, где их размещать. А если вопрос про бинарь GitLab Runner, то он очень мало ресурсов потребляет, его можно где угодно расположить. Тут больше зависит от требований сетевой доступности.

Когда лучше использовать подход Docker-in-Docker? Какие еще есть инфраструктурные идиомы, связанные с GitLab?

Александр Швалов: Скажу очевидную вещь: использовать Docker-in-Docker стоит, когда у вас сам раннер запущен в Docker. Ну а если у вас нужно запускать какие-то команды в Docker как это задумывалось вообще: если раннер запущен в Docker, то вы можете просто в Docker-in-Docker брать другой Docker-образ (Python, например, и в нём выполнять какие-то действия из кода).

Тимофей Ларкин: Я буду чуть более категоричен. Docker-in-Docker стоит использовать почти никогда. Бывают случаи, когда мне надо собрать кастомный образ kaniko, но когда я пытаюсь собрать его через kaniko, то всё уходит в бесконечную рекурсию и падает (есть такие интересные особенности). Тогда приходится использовать Docker-in-Docker. Кроме того, Docker-in-Docker можно использовать на какой-нибудь виртуалке, которой мы сделали хорошую изоляцию ото всего, чтобы там вообще нельзя было дотянуться ни до инфраструктуры, ни до ещё чего-то, чтобы там можно было только Docker-образы собирать.

В остальных ситуациях Docker-in-Docker это огромная зияющая дыра в безопасности. Очень легко использовать: у тебя есть root-права, у тебя есть привилегии, ты можешь монтировать хостовую файловую систему. Накатал Dockerfile, в котором первым шагом устанавливаешь SSH-демон, прокидываешь туннель туда куда надо, потом заходишь на эту машину и с root-правами монтируешь на эту машину dev/sda1 и всё, у тебя доступ к хосту, ты делаешь что хочешь.

Александр Швалов: Лучше посмотреть в сторону новомодных Podman, Buildah и kaniko. Совсем недавно были новости, что Kubernetes хочет отказаться от Docker все схватились за голову, но это в принципе ожидаемо. И сам Docker (мы с этого начали) уже выкатил rootless mode. Поэтому всеми силами стоит уходить от выполнения от root.

Как можно бороться с тем, что когда происходит сборка артефакта в Docker, очень быстро забивается свободное место на диске (ну кроме docker prune -a)?

Александр Швалов: Только одно решение выделить больше диска, чтобы хватало этого запаса на тот период, когда у вас срабатывает по расписанию сборка мусора. Либо использовать одноразовые раннеры где-то в облаках.

Тимофей Ларкин: Регулярно подчищать за собой: docker prune -a. Совершенно точно плохая практика использовать хостовый Docker-демон для этих сборок. Потому что доступ к хостовому демону это огромная дыра в безопасности, мы можем делать всё что угодно на хосте от имени рута. Ну и плюс, если мы для сборки используем хостовый Docker-демон, то он моментально забивается всяким мусором.

Допустим, даже не используя никакой хостовый Docker-демон, даже имея политику подчистки Docker-образов в GitLab registry, когда мы только стартовали, у нас был раздел под GitLab на 250 Гб. Потом мы стали упираться, сделали отдельный раздел под GitLab на 250 Гб, а под GitLab registry ещё один на 250 Гб. У нас GitLab Omnibus подключал два persistent volume одновременно. Потом раздел под registry разросся до 500 Гб, сейчас он, кажется, 750 Гб и надо узнать у бывших коллег, что у них там происходит хватает места или надо ещё что-то придумывать. И это при том, что есть политика удаления всех, кроме последних пяти тегов какого-то образа. И это без всяких артефактов сборок, это просто конечные образы, которые дальше запускаются на каких-то окружениях.

Как организовать мирроринг стороннего репозитория (например, из GitHub) в GitLab средствами самого GitLab? То есть чтобы автоматически в GitLab подтягивались все изменения, обновления из стороннего репозитория, новые теги и т. д. Без необходимости периодически делать pull руками, без использования скриптов или сторонних решений для автоматизации этого процесса. Если нельзя обойтись без сторонних решений, то какое из них вы бы порекомендовали?

Александр Швалов: Сразу скажу, что полная поддержка этой функциональности есть в платной версии Starter. Для ускорения автоматики можно дополнительно использовать вебхуки в GitHub, чтобы он при каждом чихе тыкал палочкой в GitLab и GitLab в ответ на это делал pull из GitHub. Если надо обойтись исключительно бесплатной версией, то мне не приходилось этим заниматься, скорее всего, придётся использовать дополнительные сторонние скрипты. Сходу можно порекомендовать настроить для этого CI/CD пайплайн: грубо говоря, можно делать операции с гитом на уровне раннера и запускать это всё по расписанию. Но это, конечно, костыль.

Тимофей Ларкин: Я бы не брал этот подход. Это очень способствует плохим практикам. Чаще всего проблемы возникали, когда мы работали с внешними подрядчиками, которые упорно не хотели хранить свой код в нашем GitLab, а хранили его в своём. Поскольку это большая корпорация, собственные TLS-сертификаты самоподписные и так далее, то подрядчик не знает, как их себе в системное хранилище добавить, или ещё какая-то беда в результате всегда было довольно тяжело получить от подрядчика не просто артефакт, а код. Потому что а зачем? а мы попытаемся помиррорить! не работает ладно, тогда будем на своём GitLab работать. Возможно, есть ситуации, когда это важная и нужная функциональность, но частенько это абьюзится.

Какой аппаратный ресурс наиболее востребован для инстанса GitLab в docker-контейнере: процессор, оперативная память или хранилище? А для раннеров?

В случае, если есть только один мощный сервер с мощным процессором, большим объемом оперативной памяти и большим хранилищем и еще один-два сервера меньшей мощности с процессорами послабее, как наиболее оптимально задействовать первый сервер для развертывания GitLab-инфраструктуры
(то есть самого GitLab и раннеров) и что лучше перенести на сервера меньшей мощности? Как целесообразно в этом случае размещать раннеры: в Docker-контейнерах на хосте или в виртуальных машинах (например, kvm)?
Ориентировочная нагрузка на инстанс GitLab: 100 пользователей, 200 проектов.

Александр Швалов: Как адепт классических решений, я бы предложил KVM как более проверенное решение. Docker-контейнеры для меня это до сих пор что-то эфемерное: сейчас запустил, через 15 минут можно грохнуть. GitLab же должен работать и работать, там вы храните свою конфигурацию. Зачем его поднимать, гасить?

Требования по железу есть у самого GitLab. Для 100 пользователей нужно 2 ядра (хватит до 500 юзеров) и 4 Гб памяти (до 100 юзеров). При расчёте объема диска лучше исходить из простой математики: объём всех репозиториев, которые есть, умножить на 2. И не забыть продумать, как вы будете добавлять к серверу новые диски, если репозитории разрастутся.

Железные требования для раннеров предсказать сложно. Зависит от проектов, что вы там собираете: html-страницы или java-код. Надо взять изначальные требования к сборке и от них отталкиваться. Возможно, стоит взять что-то виртуальное, докинуть ресурсов и настраивать по необходимости.

Тимофей Ларкин: Увидев этот вопрос, я специально попросил у коллег графики по потреблению GitLab. Там всё не так весело. Их инстанс GitLab так-то на 500 пользователей, но реально что-то разрабатывают не более 200 человек. Там безупречно ровная полка ну как, колеблется от 1,5 до 2 ядер на протяжении нескольких дней, возможно, по ночам чутка потише. Полка по памяти в районе 50 Гб тоже довольно стабильно.

То есть возвращаясь к рекомендациям: по ядрам, наверное, они реальны, а по памяти занижены. 4 Гб хватит только для запуска, а для активной работы понадобится гораздо больше. И это даже вместе с тем, что базы данных PostgreSQL, которые под этим GitLab, они сейчас живут на отдельных хостах. Раньше, по моим наблюдениям, процессор загружался гораздо сильнее.

Независимо от способа деплоя я бы запустил GitLab на жирном хосте: нам важна надёжность GitLab, многие его компоненты достаточно прожорливы. На других хостах поменьше, наверное, можно было бы гонять Docker executor.

Интересует деплой не в Kubernetes. Допустим, по SSH или же docker\docker-compose.

Александр Швалов: Да, это популярный запрос. Мы планируем добавить это в наш курс (на момент публикации статьи уже добавили прим. редактора) деплой в простой Docker. Всё делается очень просто: раннер с предварительно настроенными ключами заходит по SSH на хост, делает там docker stop, docker rm (удаляет старый контейнер) и docker run с прямым указанием на конкретный образ, который мы только что собрали. В результате поднимается новый образ.

Голый Docker это не оркестратор, и репликации там нет, поэтому при таком CI/CD у вас будет перерыв в обслуживании. Если у вас нет образа контейнера, в моём примере лучше его запустить самостоятельно.

Тимофей Ларкин: Если интересует совсем голый SSH, то пишите скрипты и запускайте. Можем, наверное, минимальный пример в курс добавить. Но надо понимать, что Kubernetes уйму проблем с оркестрацией решает, ну и Docker тоже достаточно можно решает (перезапуски, healthcheck, что угодно).

Если я был вынужден описывать голый SSH, наверное, я бы запускал что-нибудь через systemd. Да, можно Ansible использовать, но опять же, через тот же systemd.

Александр Швалов:Если ещё нет образа контейнера на хосте (я вспомнил, как это у меня делалось), там тоже через Bash проверяется, есть что-нибудь или нет. Если нет, то делаем docker run без всего; docker run, и конкретный образ из registry, который только что создан. Если что-то есть, то сначала останавливаем это всё, и после этого docker run.

Можно ли контейнер с раннером создавать динамически (только на момент сборки)?

Александр Швалов: Да. Очень популярно брать дешёвые инстансы AWS и запускать раннеры там, а потом их глушить по прошествии какого-то времени. Пошла активная сборка, пошёл деплой, насоздавались раннеры и через какое-то время, когда нагрузки нет, они сами по себе схлопнутся. Это всё реализуется через Docker compose.

Тимофей Ларкин: Мы говорим про GitLab runner, который управляющий бинарник, или мы про сами пайплайны? Ну да, пайплайны, наверное. А сам управляющий бинарь? Тогда что будет триггерить создание этого самого бинаря? Опять возникают проблемы курицы и яйца.

Александр Швалов: В Kubernetes, насколько я знаю, можно через какие-то метрики, когда нагрузка есть, он создаёт Так же для OpenShift я нашёл, есть оператор, который управляет раннерами. Как-то можно автоматизировать, люди движутся в этом направлении. Но, как правило, на простых проектах, если что-то нужно, мы берём и виртуалке добавляем ресурсов, а когда проходит час пик убираем ресурсы.

Тимофей Ларкин: Автоскейлинг нод можно делать. Потому что так-то Docker-контейнеры с пайплайнами создаются автоматически только на время существования пайплайна по дефолту. Управляющий бинарь должен существовать по дефолту. Иначе как кто-то узнает, что надо создавать управляющий бинарь?

Как можно настроить шаринг раннера только между определённым количеством проектов?

Александр Швалов: Для этого в GitLab есть группы, создаёте группу, привязываете раннер и в эту группу добавляете проекты. Доступ юзеров, соответственно, распределяется. Всё просто!

Тимофей Ларкин: Ссылка на issue, где описывается, как это делать. Необязательно даже, чтобы это был раннер на группу. Можно делать раннер на конкретный список репозиториев. Первый создаётся через регистрационный токен на какой-то конкретный репозиторий, но потом, через UI GitLab можно добавить его ещё нескольким. Можно ещё тегами всё это разрулить.

Прошу рассказать, если есть опыт, о практике организации доставки и развертывания сервисов в закрытые окружения заказчика, когда нет возможности прорубить доступ до внутренних репозиториях заказчика. Как при этом упростить доставку артефактов и по максимуму автоматизировать развертывание в условиях, когда Git находится далеко снаружи runtime-окружения?

Александр Швалов: У меня, к сожалению, не было такого опыта. Я знаю, что в серьезных организациях такое сплошь и рядом практикуется. Я могу лишь придумать такой способ: взять артефакт, сделать архив с релизной веткой репозитория, принести на флешке, там есть внутренний GitLab, сделать push в нужную ветку и сделать CI/CD как обычно, только в локальной сети.

Тимофей Ларкин: Вообще, я к таким историям скептически отношусь. Когда заказчик говорит, что у него невероятно секретно, гостайна (номера карт лояльности клиентов) и всё такое, то надо посмеяться и понять, что он врёт, и не работать с такими заказчиками. Но если работать очень надо (в конце концов, нам всем надо счета оплачивать и еду покупать), то есть вариант разместить раннер (управляющий бинарь; и пайплайны тоже будут где-то рядом запускаться) именно внутри контура заказчика.

Раннер умеет работать за NAT, умеет постучаться во внешний GitLab. Главное, чтобы сам GitLab не был за NAT, чтобы была нормальная доступность до GitLab. Поэтому да, раннер может изнутри контура заказчика сходить в ваш GitLab, стянуть код и делать сборку уже внутри инфраструктуры заказчика. И тогда чуть легче: артефакт сборки кладётся во внутренний репозиторий заказчика и оттуда уже деплоится всё хорошо. Не исключено, что там будет много сложностей. Наверняка, у заказчика свои самоподписные TLS-сертификаты, у него интернет недоступен на большинстве хостов (надо будет согласовать proxy, которая позволит раннеру ходить до вашего GitLab) и так далее.

Александр Швалов: Если proxy, NAT недопустимы, то в таком варианте остаётся паковать всё на своей стороне, собирать в инсталлятор, приходить к заказчику и обновлять приложение инсталлятором. Это уже другая задача, к CI/CD она вряд ли относится. Хотя можно настроить CI/CD, чтобы на выходе получался инсталлятор.

Тимофей Ларкин: Ну да, или держать все эти артефакты у себя в инфраструктуре, заказчику выдать публичный или приватный ключ, и просто ему на почту писать: Мы сделали новый этап работы, выложили новую версию, приходите забирайте.

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

Может нам как-то помочь CI/CD GitLab, если поставщик сам присылает собранные бинари в zip-архиве, и эти бинари необходимо распределить на нужное количество нод? Где это будет работать?

Александр Швалов:Речь о том, что есть в качестве исходного кода бинари в zip-архиве, и GitLab CI будет их каким-то образом распределять? В принципе, такое возможно. Почему нет? Можно это как-то сканировать, тестировать и деплоить, просто по SSH закидывать. В принципе, можно обойтись и без GitLab, одними скриптами.

Тимофей Ларкин: Можно какую-нибудь регулярную jobу запилить, которая, допустим, смотрит на папку, проверяет сумму у zip-архива, если обновилась, распаковывает, раскладывает его на внутренние nexus (приватный docker registry прим. редактора) в виде артефактов. Если надо, деплоит. Да, я думаю, GitLab может помочь в плане автоматизации этого процесса.

Узнать больше о курсе по CI/CD

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

Традиционно короткий дайджест полезных материалов, найденных нами в сети за последние две недели.

Начни новое:

• Опенсорсная виртуализация: Linux на Macе
  Как запустить Fedora под macOS с помощью виртуальной машины QEMU.
• Практический учебник по awk
  Бесплатная электронная книга по скриптовому языку awk.
• Ваяем консоль удаленного управления на Python и Jupyter Notebooks
  Как превратить Jupyter в консоль удаленного администрирования.
  
  
  
  
  
• Создаем обложку книги в опенсорсном аналоге Adobe InDesign
• 4 причины использовать Jamstack при веб-разработке
• Как правильно открывать порты и маршрутизировать трафик через брандмауэр
• OpenShift Pipelines и Argo CD: путь от кода в продакшн:
  Как использовать Argo CD, Tekton и OpenShift Pipelines для управления рабочими процессами CI/CD в тестовой и продакшн-средах.
• Eclipse JKube 1.0.0 разрабатывать Java-приложения для облака стало проще
  Eclipse JKube 1.0.0 это наследник проекта Fabric8 Maven Plugin, и он предлагает много нового для сборки Java-контейнеров Maven, например, поддержку стратегий сборки S2I.
• Ставим Red Hat OpenShift Operators на ноутбук с помощью Red Hat CodeReady Containers и Red Hat Marketplace
  Учимся устанавливать контейнеризованные продукты из магазина приложений Red Hat Marketplace в локальный девелоперский OpenShift-кластер CodeReady.
• Quarkus и Jakarta EE: таки вместе или нет?
  Будет ли Quarkus совместим с Jakarta EE? Простым да или нет тут не обойдешься, так что разбираем в деталях.
• 5 советов по разработке Kubernetes Operators с помощью нового Operator SDK
  Секреты-советы по разработке Kubernetes Operators с использованием Operator SDK 1.0 и Helm, Ansible или Go (даже если вы не пишите на Go), включая массу примеров.
• Как держать в секрете Kubernetes-секреты (видеоурок DevNation Tech Talk, 35 минут)

Качай:

• Шпаргалка по Ansible k8s
  Ansible k8s это специальный модуль для управления объектами Kubernetes из плейбуков Ansible. Как объединить Ansible и Kubernetes при автоматизации облака? Ответ: использовать модуль Ansible k8s, чтобы управлять объектами Kubernetes прямо из плейбуков. И поможет в этом наша шпаргалка, которая содержит полезные советы и сведения по ключевым командам этого модуля.
• Шпаргалка по тестированию приложений Quarkus
  
  
  
  
  
• Книжка-раскраска Контейнерные супергерои
  Децентрализованная команда опенсорсных контейнерных супергероев в лице Podman, CRI-O, Buildah, Skopeo и OpenShift спасает Землю от атаки астероидов, развертывая над планетой защитный экран.
  
  
  
  
  

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

• Девелоперские инструменты в магазине приложений Red Hat Marketplace
• Введение в корпоративный Kubernetes
• Бесплатный онлайн-курс Технический обзор RHEL
• Kubernetes-операторы: как сделать эксплуатационный регламент частью контейнеризованных приложений
• Как успешно пройти первые 90 дней на новой работе в режиме удаленки

Мероприятия:

• 30 сентября, jconf.dev
  Бесплатная виртуальная Java-конференция прямо у вас на экране. Четыре технотрека с экспертами по Java и облаку, 28 углубленных сессий и два потрясающих основных доклада.
• 13-14 октября, AnsibleFest
  Выступления, демонстрации, практические занятия и все это в онлайне. Отличная возможность виртуально пообщаться с девелоперами, админами и ЛПР-ами, которые успешно справляются с вызовами перемен с помощью опенсорсных технологий ИТ-автоматизации.

По-русски:

Мы продолжаем серию пятничных вебинаров про нативный опыт использования Red Hat OpenShift Container Platform и Kubernetes. Регистрируйтесь и приходите:

Император Оператор: Операторы в OpenShift и Kubernetes
Упс, вебинар прошел, но есть запись.

OpenShift-специфичные волшебные вещи для сборки и развертывания приложений
Вебинар кончился, но остался в истории ловите запись.

• 25 сентября
  Red Hat OpenShift и Machine API
• 9 октября
  Как справиться с внезапным ростом нагрузки
• 23 октября
  Встроенный Jenkins, Pipeline-builds, Tekton в Red Hat OpenShift Container Platform