Оркестрація CI/CD з Argo Workflows у Kubernetes

Оркестрація 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 краще за Tekton?

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

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

Як проектувати 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.

Що входить в роботу

• Аудит поточної CI/CD інфраструктури з виявленням вузьких місць (до 2 сторінок звіту).
• Документування архітектури пайплайнів (діаграми DAG, список етапів).
• Встановлення та налаштування Argo Workflows, Argo Events, ArgoCD у кластері.
• Розробка 5-10 перевикористовуваних WorkflowTemplates для збірки, тестування та деплою.
• Налаштування event-driven запуску через GitHub/GitLab webhooks або інші джерела.
• Інтеграція з наявними системами (Helm, Kaniko, Trivy, системи сповіщення).
• Доступ до репозиторію з усіма шаблонами (GitHub/GitLab).
• Документація з експлуатації (файл README, інструкція для розробників).
• Навчання команди (2-3 години воркшопу) основам роботи з Argo Workflows.
• Гарантійна підтримка протягом першого місяця експлуатації (відповіді на питання, усунення інцидентів).

Впровадження за 4 кроки

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

Етапи роботи та терміни

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

Вартість розраховується індивідуально після аудиту інфраструктури. Отримайте консультацію — підготуємо оцінку вашого проекту. Пишіть, обговоримо деталі.

Зв'яжіться з нами для аудиту CI/CD пайплайнів — ми знайдемо вузькі місця та запропонуємо оптимальне рішення.