#Введение

#Что такое Pipelines as Code?

Pipelines-as-Code (PAC) — это компонент, который позволяет определять и управлять рабочими процессами Tekton Pipeline непосредственно в вашем репозитории исходного кода. Вместо того чтобы поддерживать пайплайны в Kubernetes-кластере, вы можете:

• Хранить определения пайплайнов в Git вместе с вашим кодом
• Управлять версиями конфигураций пайплайнов
• Просматривать изменения пайплайнов через Merge Requests
• Автоматически запускать пайплайны по событиям Git (Pull Request, Merge Request или Push)
• Получать отчёты о статусе выполнения обратно в ваш Git-провайдер

PAC построен на базе Tekton Pipeline, используя его мощный движок выполнения пайплайнов и добавляя возможности интеграции с Git.

#Поддержка платформ

PAC поддерживает развертывание на платформах Kubernetes. Несмотря на то, что имя ресурса содержит "OpenShift" (по историческим причинам), PAC можно развернуть и использовать на стандартных Kubernetes-кластерах через Tekton Operator.

#Предварительные требования

Для использования PAC необходимы:

Требования к инфраструктуре:

• Kubernetes-кластер версии 1.24 и выше
• Установленный Tekton Operator
• Git-репозиторий с правами администратора (для настройки webhook)
• Установленный и настроенный kubectl
• CLI tkn с плагином pac (для настройки репозитория)

Требования к знаниям:

• Базовое понимание концепций Kubernetes (Pods, Services, Namespaces, Custom Resources)
• Базовое понимание концепций Tekton (Pipeline, PipelineRun, Task)
• Знакомство с Git и Git-провайдерами (GitHub, GitLab, Bitbucket)

Подробные требования см. в разделе Quick Start.

#Основные возможности

PAC предоставляет широкий набор функций из коробки, включая:

• Отслеживание статуса пайплайна: Отслеживание и управление статусом пайплайнов в Git-провайдерах при обработке Pull Request или Merge Request
• Поддержка событий: Поддержка событий Pull Request, Merge Request и Push
• Команды в комментариях: Поддержка команд в комментариях Pull Request или Merge Request, например /retest для повторного запуска тестов
• Фильтрация событий: Поддержка фильтрации Git-событий и настройка отдельных пайплайнов для разных событий
• Разрешение задач: Автоматическое разрешение задач в пайплайнах (включая локальные задачи, Tekton Hub и удалённые URL)
• Инструменты CLI: Предоставление плагина tkn pac для управления ресурсами PAC Repository и регистрации webhook. См. tkn pac Command Reference для установки и использования
• Интеграция с Git-провайдерами: Полная поддержка нескольких Git-провайдеров (GitHub, GitLab, Bitbucket Cloud, Bitbucket Data Center), webhook и отчётов о статусе

#Как это работает

PAC работает с использованием следующих основных компонентов, которые взаимодействуют между собой:

1. Repository CR (Custom Resource): Пользовательский ресурс Kubernetes, который определяет связь между Git-репозиторием и контроллером PAC. Хранит конфигурацию репозитория, учётные данные Git-провайдера и настройки webhook.
2. PAC Webhook: Принимает HTTP-запросы (webhook) от Git-провайдеров и проверяет подписи webhook
3. PAC Controller: Обрабатывает события webhook от Git-провайдеров, получает определения пайплайнов из Git-репозиториев и создаёт ресурсы PipelineRun в Kubernetes
4. PAC Watcher: Отслеживает статус выполнения PipelineRun и отправляет результаты обратно Git-провайдерам

#Последовательность работы компонентов

Когда происходит событие Git (push, pull request, merge request):

1. Git-провайдер отправляет webhook → PAC Webhook принимает и проверяет событие
2. PAC Webhook пересылает событие → PAC Controller обрабатывает событие
3. PAC Controller получает определение пайплайна из Git → Создаёт PipelineRun в Kubernetes
4. Tekton Pipeline выполняет PipelineRun
5. PAC Watcher отслеживает выполнение → Отправляет статус обратно Git-провайдеру

Подробнее см. в разделе Core Concepts.

#Сценарии использования

PAC подходит для следующих сценариев:

1. Управление пайплайнами на основе кода

   • Поддержка определений пайплайнов в репозиториях исходного кода
   • Управление версиями конфигураций пайплайнов
   • Просмотр изменений пайплайнов через Merge Requests

2. Автоматизация CI/CD

   • Автоматический запуск пайплайнов при пуше кода
   • Запуск тестов при Merge Requests
   • Развёртывание приложений после слияния

3. Рабочие процессы с несколькими репозиториями

   • Управление пайплайнами для нескольких репозиториев
   • Совместное использование шаблонов пайплайнов между проектами
   • Централизованное управление пайплайнами

#Ключевые преимущества

1. Управление версиями: Определения пайплайнов хранятся в Git, что обеспечивает контроль версий и возможность просмотра изменений
2. Удобство для разработчиков: Разработчики могут изменять пайплайны без доступа к кластеру
3. Прозрачность: Изменения пайплайнов видны в Merge Requests
4. Последовательность: Стандартизированные определения пайплайнов в разных проектах
5. Гибкость: Поддержка нескольких Git-провайдеров (GitHub, GitLab, Bitbucket Cloud, Bitbucket Data Center) и различных типов событий

#Начало работы

Если вы новичок в PAC, следуйте этому пути обучения:

1. Core Concepts — Изучите архитектуру PAC и основные концепции
2. Quick Start — Разверните PAC и настройте первый репозиторий
3. Manage PAC Component — Узнайте, как развертывать, обновлять и обслуживать PAC
4. Configure Repository — Настройте интеграцию с Git-репозиторием

#Связанная документация

• Pipeline As Code — Официальная документация Pipelines As Code
• Maintain Pipeline Code — Определение и поддержка пайплайнов в коде
• Troubleshooting — Распространённые проблемы и решения