Developer

Альтернативные CI-CD системы: Tekton, Argo Workflows, Woodpecker и Dagger

↑ Этап 3 · CI-CD

Обязательно~11 мин чтенияУровень: middle

Зачем это на собесе

«А если не GitLab CI и не GitHub Actions?» Проверяют, что вы понимаете идеи, а не один синтаксис: пайплайн как код, изолированные шаги в контейнерах, артефакты, секреты, runners. Умение сказать, чем Tekton отличается от Jenkins, показывает кругозор.

Подтемы

  • Что общего у всех CI-систем
  • Kubernetes-нативные: Tekton и Argo Workflows
  • Лёгкие self-hosted: Woodpecker и Drone
  • TeamCity и Jenkins
  • Dagger: пайплайн как код, независимый от CI
  • Как выбрать

Объяснение

Общая модель

У любой CI-системы одни и те же части: триггер (push, pull request, расписание), пайплайн из стадий и шагов, исполнитель (runner, агент, под), артефакты и кэш, секреты, окружения. Различается то, где работает исполнитель и как описывается пайплайн.

Сравнение

СистемаГде исполняетсяКак описываетсяОсобенности
GitLab CI, GitHub ActionsrunnersYAML в репозиториивстроены в платформу
JenkinsагентыJenkinsfile (Groovy)гибкость и плагины, требует ухода (обзор Jenkins)
TeamCityагентыинтерфейс и Kotlin DSLкоммерческий продукт JetBrains, удобные отчёты
Tektonподы в KubernetesCRD: Task, Pipeline, PipelineRunконструктор для собственной CI-платформы
Argo Workflowsподы в KubernetesCRD: Workflow (DAG)общие рабочие процессы: CI, данные, ML
Woodpecker / Droneконтейнеры на хосте или в KubernetesYAML в репозиториилёгкие, простые, каждый шаг в контейнере
Daggerконтейнеры (движок)код на Go, Python, TypeScript и другиходин пайплайн запускается и локально, и в любой CI

Tekton

Набор ресурсов Kubernetes для CI/CD. Task — последовательность шагов (каждый шаг контейнер), Pipeline — граф задач, PipelineRun — конкретный запуск. Всё хранится как объекты кластера, запускается подами, удобно для GitOps и платформенных команд. Есть готовые задачи (Tekton Hub), но требуется настройка триггеров и интерфейса.

Argo Workflows

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

Woodpecker и Drone

Простая CI: каждый шаг выполняется в контейнере, конфигурация в .woodpecker.yaml (у Drone .drone.yml). Woodpecker это сообщественный форк Drone. Легко разворачивается на одном сервере, хорошо подходит небольшим командам и self-hosted.

Dagger

Подход «пайплайн как программа»: вы пишете шаги на языке программирования с помощью SDK, а движок запускает их в контейнерах с кэшированием. Тот же пайплайн запускается на ноутбуке и в любой CI-системе, поэтому вы не привязаны к YAML конкретной платформы и можете отлаживать пайплайн локально.

Как выбрать

flowchart TD
    A["Нужна CI-система"] --> B{"Код уже на GitLab или GitHub?"}
    B -- да --> C["GitLab CI / GitHub Actions"]
    B -- нет --> D{"Есть Kubernetes и платформенная команда?"}
    D -- да --> E{"Задачи: только CI или общие процессы/данные?"}
    E -- "CI/CD" --> F["Tekton"]
    E -- "процессы, данные, ML" --> G["Argo Workflows"]
    D -- нет --> H{"Маленькая команда, self-hosted?"}
    H -- да --> I["Woodpecker"]
    H -- "нужны отчёты и поддержка" --> J["TeamCity"]

Примеры

Woodpecker: тесты и сборка образа

# .woodpecker.yaml
when:
  - event: [push, pull_request]
 
steps:
  - name: test
    image: mcr.microsoft.com/dotnet/sdk:10.0
    commands:
      - dotnet test
 
  - name: build-image
    image: woodpeckerci/plugin-docker-buildx
    settings:
      repo: registry.example.com/team/app
      tags: latest
    when:
      - branch: main

Tekton: задача и пайплайн

apiVersion: tekton.dev/v1
kind: Task
metadata:
  name: dotnet-test
spec:
  workspaces:
    - name: source
  steps:
    - name: test
      image: mcr.microsoft.com/dotnet/sdk:10.0
      workingDir: $(workspaces.source.path)
      script: |
        dotnet test
---
apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: ci
spec:
  workspaces:
    - name: shared
  tasks:
    - name: test
      taskRef:
        name: dotnet-test
      workspaces:
        - name: source
          workspace: shared

Argo Workflows: зависимости шагов

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: ci-
spec:
  entrypoint: main
  templates:
    - name: main
      dag:
        tasks:
          - name: build
            template: run
            arguments:
              parameters: [{ name: cmd, value: "dotnet build" }]
          - name: test
            dependencies: [build]
            template: run
            arguments:
              parameters: [{ name: cmd, value: "dotnet test" }]
    - name: run
      inputs:
        parameters:
          - name: cmd
      container:
        image: mcr.microsoft.com/dotnet/sdk:10.0
        command: [sh, -c]
        args: ["{{inputs.parameters.cmd}}"]

Шаблон run переиспользуется с разными параметрами, а шаг test запустится только после успешного build.

Нюансы и подводные камни

  • Не выбирайте инструмент ради новизны. Для большинства команд встроенные GitLab CI или GitHub Actions проще и дешевле в поддержке.
  • Kubernetes-нативные системы требуют платформенной работы: триггеры, интерфейс, права, хранилище артефактов и кэша придётся собирать.
  • Воспроизводимость. Какую бы систему вы ни взяли, фиксируйте версии образов шагов, не latest.
  • Секреты. Доступ к секретам только у доверенных веток и шагов, не из pull request чужих форков (секреты и окружения).
  • Портируемость. Логику сборки выносите в скрипты (Makefile, dotnet, Dagger), а CI оставляйте тонкой оболочкой: миграция между системами станет простой.
  • Безопасность исполнителей. Self-hosted агенты с доступом к Docker socket эквивалентны root на хосте.

Вопросы с ответами

Связанные темы

Вид графа

Обратные ссылки