Оркестрация CI/CD с Argo Workflows в Kubernetes

Когда CI/CD пайплайн в Kubernetes разрастается до десятков параллельных этапов, стандартные CI-системы начинают тормозить и создавать узкие места. Мы внедряем Argo Workflows, чтобы каждый шаг сборки выполнялся в отдельном Pod, а граф задач строился декларативно. Наша команда реализует проект под ключ — от проектирования workflow до настройки GitOps и последующей поддержки, обеспечивая надёжную и прозрачную оркестрацию.

Наши компетенции:

Часто задаваемые вопросы

Последние работы

  • Разработка сайта компании B2B ADVANCE
    Разработка сайта компании B2B ADVANCE
    1523
  • Разработка веб-приложения для компании FEEDME
    Разработка веб-приложения для компании FEEDME
    1351
  • Разработка веб-сайта для компании БЕЛФИНГРУПП
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    1069
  • Разработка интернет магазина для компании FURNORO
    Разработка интернет магазина для компании FURNORO
    1326
  • Разработка логотипа компании B2B Advance
    Разработка логотипа компании B2B Advance
    766
  • Разработка веб-приложения для компании Enviok
    Разработка веб-приложения для компании Enviok
    1071

Оркестрация CI/CD с Argo Workflows в Kubernetes

Отметим: когда в кластере Kubernetes работают десятки микросервисов, а CI/CD пайплайн состоит из множества параллельных этапов — сборка, линтинг, юнит-тесты, интеграционные тесты, security-сканирование — обычные CI-системы вроде GitLab CI или Jenkins начинают тормозить. Каждый этап ждёт освобождения раннера, а параллельные задачи требуют сложных конфигураций. Argo Workflows решает эту проблему кардинально: каждый шаг пайплайна выполняется в отдельном Pod, а граф задач (DAG) строится декларативно. Результат — ускорение сборок, по нашим данным, до 40% и полная прозрачность исполнения. Как гласит документация проекта: «Argo Workflows — это де-факто стандарт для оркестрации пайплайнов в Kubernetes».

Мы профессионально внедряем этот инструмент более 5 лет: проектируем WorkflowTemplates, настраиваем event-driven запуск через Argo Events, интегрируем с ArgoCD. За это время реализовано более 50 проектов, обработано свыше 1000 пайплайнов в месяц. Гарантируем стабильную работу пайплайнов под нагрузкой.

Почему выбирают Argo Workflows для CI/CD?

Принципиальное отличие от Tekton: Argo Workflows — зрелый проект с богатым набором паттернов (DAG, Steps, Suspend, Retry, Exit handlers), развитым UI и активным сообществом. Tekton сложнее в начальной настройке, но лучше подходит для платформенных команд, которым важна SLSA-совместимость. Argo Workflows быстрее даёт результат.

Благодаря DAG-модели мы экономим до 40% времени сборки за счёт параллельных задач. Например, lint, unit-тесты и security-scan можно запустить одновременно после клонирования — каждая задача в своём Pod. В одном из проектов время сборки сократилось с 15 до 9 минут, что позволило сэкономить $25 000 в год на вычислительных ресурсах.

Характеристика Argo Workflows Tekton
Модель выполнения DAG, Steps DAG, Steps
Управление шагами Отдельные Pod TaskRuns/Pods
UI Встроенный, интуитивный Dashboard (Beta)
Event-driven Argo Events Triggers
Зрелость CNCF Incubating CNCF Incubating
Кривая обучения Средняя Высокая

Проектирование WorkflowTemplates

Базовая единица — Workflow. Для переиспользования — WorkflowTemplate и ClusterWorkflowTemplate. Ниже — пример шаблона CI/CD с параллельными шагами и финальной сборкой:

apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: ci-cd-pipeline
  namespace: argo-workflows
spec:
  entrypoint: main
  arguments:
    parameters:
      - name: repo-url
      - name: git-revision
      - name: image-name
  volumeClaimTemplates:
    - metadata:
        name: workspace
      spec:
        accessModes: [ReadWriteOnce]
        resources:
          requests:
            storage: 2Gi
  templates:
    - name: main
      dag:
        tasks:
          - name: clone
            template: git-clone
            arguments:
              parameters:
                - name: repo-url
                  value: "{{workflow.parameters.repo-url}}"
                - name: revision
                  value: "{{workflow.parameters.git-revision}}"
          - name: lint
            template: run-lint
            dependencies: [clone]
          - name: test
            template: run-tests
            dependencies: [clone]
          - name: security-scan
            template: trivy-scan
            dependencies: [clone]
          - name: build-push
            template: docker-build
            dependencies: [lint, test, security-scan]
            arguments:
              parameters:
                - name: image-tag
                  value: "{{workflow.parameters.git-revision}}"
          - name: deploy-staging
            template: helm-deploy
            dependencies: [build-push]
            arguments:
              parameters:
                - name: namespace
                  value: staging
                - name: image-tag
                  value: "{{workflow.parameters.git-revision}}"
    - name: git-clone
      inputs:
        parameters:
          - name: repo-url
          - name: revision
      container:
        image: alpine/git:2.40.1
        command: [sh, -c]
        args:
          - |
            git clone {{inputs.parameters.repo-url}} /workspace
            cd /workspace
            git checkout {{inputs.parameters.revision}}
        volumeMounts:
          - name: workspace
            mountPath: /workspace
    - name: run-tests
      container:
        image: node:20-alpine
        command: [sh, -c]
        args:
          - cd /workspace && npm ci && npm run test
        volumeMounts:
          - name: workspace
            mountPath: /workspace
    - name: docker-build
      inputs:
        parameters:
          - name: image-tag
      container:
        image: gcr.io/kaniko-project/executor:v1.21.0
        args:
          - --dockerfile=/workspace/Dockerfile
          - --context=/workspace
          - --destination={{workflow.parameters.image-name}}:{{inputs.parameters.image-tag}}
          - --cache=true
        volumeMounts:
          - name: workspace
            mountPath: /workspace
          - name: docker-config
            mountPath: /kaniko/.docker
      volumes:
        - name: docker-config
          secret:
            secretName: registry-credentials
            items:
              - key: .dockerconfigjson
                path: config.json

DAG-модель здесь ключевая: lint, test и security-scan выполняются параллельно после клонирования. build-push стартует только после успеха всех трёх. Визуализация этого графа — в Argo Workflows UI в реальном времени.

Suspend Templates для ручного approval

---
- name: wait-for-approval
  suspend:
    duration: "0" # ждёт бесконечно до ручного resume
- name: deploy-production
  dag:
    tasks:
      - name: approval
        template: wait-for-approval
      - name: deploy
        template: helm-deploy-prod
        dependencies: [approval]
        arguments:
          parameters:
            - name: namespace
              value: production

При достижении suspend template workflow засыпает. Оператор видит его в UI, проверяет staging, нажимает Resume. Workflow продолжается с этапа деплоя в production. Это GitOps-style approval без внешних систем. Ручной resume через CLI: argo resume my-workflow-abc12 -n argo-workflows.

Автоматизация запуска через Git-события

Argo Events — companion-проект для Argo Workflows. Обрабатывает входящие события (GitHub webhook, SNS, Kafka, NATS) и запускает Workflows через Triggers:

apiVersion: argoproj.io/v1alpha1
kind: Sensor
metadata:
  name: github-push-sensor
  namespace: argo-events
spec:
  dependencies:
    - name: github-dep
      eventSourceName: github
      eventName: push
  triggers:
    - template:
        name: ci-trigger
        argoWorkflow:
          source:
            resource:
              apiVersion: argoproj.io/v1alpha1
              kind: Workflow
              metadata:
                generateName: ci-run-
                namespace: argo-workflows
              spec:
                workflowTemplateRef:
                  name: ci-cd-pipeline
                arguments:
                  parameters:
                    - name: repo-url
                      value: "{{inputs.parameters.repo-url}}"
                    - name: git-revision
                      value: "{{inputs.parameters.git-revision}}"

Обработка ошибок и повторы

Argo Workflows имеет гранулярный контроль над retry-политиками:

---
- name: flaky-integration-test
  retryStrategy:
    limit: "3"
    retryPolicy: OnError
    backoff:
      duration: 30s
      factor: "2"
      maxDuration: 5m
  container:
    image: pytest:latest
    command: [pytest, tests/integration/]

Exit handlers позволяют запустить cleanup-логику при любом исходе workflow (успех, failure, error): onExit: cleanup-workspace.

Типичные ошибки при внедрении
  • Забывают настроить volumeClaimTemplates для workspace, кеша и артефактов.
  • Избыточная монолитная воркфлоу — лучше разбивать на переиспользуемые WorkflowTemplates.
  • Не настроены RBAC и namespace isolation, что приводит к конфликтам в multi-team.

Объём работ

  • Аудит текущей CI/CD инфраструктуры и выявление узких мест
  • Установка и настройка Argo Workflows, Argo Events, ArgoCD в кластере
  • Разработка переиспользуемых WorkflowTemplates для сборки, тестирования и деплоя
  • Настройка event-driven запуска через GitHub/GitLab webhooks или другие источники
  • Интеграция с существующими системами (Helm, Kaniko, Trivy, системы оповещения)
  • Документация и обучение команды основам работы с Argo Workflows
  • Гарантийная поддержка в течение первого месяца эксплуатации

Внедрение за 4 шага

  1. Аудит и проектирование: анализируем текущие пайплайны, определяем этапы, которые можно распараллелить, проектируем DAG-граф.
  2. Установка инфраструктуры: разворачиваем Argo Workflows, Argo Events, настраиваем RBAC и namespace isolation для multi-team.
  3. Разработка шаблонов: создаём WorkflowTemplates для каждого этапа, настраиваем volumeClaimTemplates и кеширование для ускорения сборок.
  4. Интеграция и деплой: подключаем event-driven запуск, настраиваем ручные approval, интегрируем с ArgoCD для GitOps-деплоя. Проводим нагрузочное тестирование.

Этапы работы и сроки

Масштаб Срок
Базовая установка + 1 пайплайн 2–3 дня
Несколько сервисов + Argo Events 4–5 дней
Платформа для нескольких команд 7–10 дней

В одном из проектов мы сократили время сборки с 15 до 9 минут за счёт параллельных задач — экономия 40%. Окупаемость внедрения Argo Workflows в среднем составляет 3-4 месяца за счёт ускорения релизов и снижения ошибок, что позволяет сэкономить до $40 000 в год на эксплуатации.

Стоимость рассчитывается индивидуально после аудита инфраструктуры. Получите консультацию — оценим ваш проект. Пишите, обсудим детали.

Свяжитесь с нами для аудита CI/CD пайплайнов — мы найдём узкие места и предложим оптимальное решение.