Для чего нужен Argo Workflows в DevOps-практиках?

Я использую Argo Workflows для оркестрации сложных, нелинейных задач, которые выходят за рамки стандартного CI/CD-пайплайна сборки и деплоя. Это инструмент для workflow-автоматизации внутри Kubernetes.

Конкретные кейсы из моей практики:

1. Сборка и сканирование образов (Multi-arch): Когда нужно собрать Docker-образ под amd64 и arm64, просканировать его на уязвимости (Trivy), протестировать (Conftest), а затем отправить в registry только если все проверки пройдены. Это идеально ложится на DAG (Directed Acyclic Graph) в Argo Workflows.

2. Восстановление базы данных из бэкапа в тестовое окружение: Еженочный workflow, который:

   • Останавливает тестовое приложение.
   • Скачивает последний снепшот из S3.
   • Восстанавливает его в тестовую RDS/базу в k8s.
   • Запускает миграции.
   • Запускает приложение.
   • Отправляет уведомление в Slack.

Пример реального workflow для обработки данных (YAML):

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: data-pipeline-
spec:
  entrypoint: main
  templates:
  - name: main
    dag:
      tasks:
      - name: extract
        template: extract-data
      - name: transform
        template: transform-data
        dependencies: [extract] # Запустится только после extract
      - name: load
        template: load-to-warehouse
        dependencies: [transform]
      - name: notify
        template: send-slack-notification
        dependencies: [load]
        arguments:
          parameters: [{name: status, value: "{{tasks.load.status}}"}]

  - name: extract-data
    container:
      image: our-data-extractor:latest
      command: [python, /app/extract.py]
      env:
        - name: DATE
          value: "{{workflow.creationTimestamp}}"
    outputs:
      artifacts:
        - name: raw-data
          path: /output/data.json
          s3:
            endpoint: s3.amazonaws.com
            bucket: our-data-bucket
            key: "raw/{{workflow.name}}/data.json"

Почему Argo, а не просто скрипт в Jenkins? Потому что он нативно работает в k8s, имеет встроенную отказоустойчивость, визуальный интерфейс для мониторинга, и workflow можно описывать декларативно и хранить в Git.