GitHub Actions vs Argo Workflows: CI vs K8s エンジン
これらは異なる問題を解決します。Argo Workflows は Kubernetes ネイティブの DAG エンジンで、GitHub Actions は git イベント駆動のCIです。
Argo Workflows はコンテナベースの DAG を Kubernetes 上で実行し、データ/ML パイプラインによく使われます。GitHub Actions はリポジトリイベントで起動する CI/CD です。両者はときに比較されるため、それぞれがどこに合うかを示します。
| GitHub Actions | Argo Workflows | |
|---|---|---|
| 主な用途 | git イベントでの CI/CD | K8s 上のコンテナ DAG / バッチ |
| 設定 | .github/workflows/*.yml | Workflow の CRD (YAML) |
| ホスティングモデル | GitHubホスト型またはセルフホスト | 自前の Kubernetes クラスタで実行 |
| トリガーモデル | Push、PR、schedule、dispatch | API、イベント、schedule、sensors |
| エコシステム | Actions Marketplace | Argo エコシステム (Events、CD) |
| メンテナンス | 低 (マネージドランナー) | K8s 上で自分で運用 |
異なる仕事
Kubernetes に属する重い並列コンテナ DAG (ML トレーニング、ETL) には Argo Workflows を使いましょう。コード変更で起動する build/test/deploy には GitHub Actions を使いましょう。多くのチームは両方を動かします。
設定と運用
Argo は Kubernetes ネイティブで、fan-out/fan-in のバッチ処理に強力ですが、クラスタとコントローラーは自分で運用します。Actions はマネージドで git 中心、大規模なマーケットプレイスを持ちます。
マネージドランナーが合う場面
CI が GitHub Actions で、バッチジョブだけが Argo を必要とするなら、CI は Actions のままにし、そのコストをマネージドランナー (例: Latchkey) で削減しましょう。GitHubホスト型より約70%低く、ウォームプールと自己修復リトライを備えます。
Migrating between CI platforms: what actually costs time
- Pipeline syntax is the easy part and the part every comparison focuses on. Budget for it, then expect it to be the smallest line item.
- Secrets, OIDC trust relationships, and deploy credentials have to be recreated and re-approved, usually by a different team.
- Caching semantics differ enough that a naive port produces a pipeline that is correct and much slower.
- Required status checks and branch protection reference check names. Renaming them mid-migration blocks merges until the rules are updated.
- Run both in parallel on the same commits until the new one has been green for a full sprint. Cutting over on a green first run is how migrations get rolled back.
結論
Kubernetes ネイティブなバッチ/DAG 処理には Argo Workflows を、コード起動の CI/CD には GitHub Actions を選びましょう。両者は競合するより補完し合います。マネージドランナーは Actions 側を安価に保ちます。