はじめに
はじめまして。Sreake事業部インターン生の荒木です。2023年10月から長期インターン生としてKubernetes関連技術の習得とSRE技術の調査・検証を行っています。
この記事の目的は、KubernetesクラスタのCDツールであるPipeCDに関する調査と検証の結果を共有することです。PipeCDの概要について詳しく説明し、特に注目すべきポイントや顕著な特徴に焦点を当てつつ、デメリットも併せて紹介します。具体的なインストール方法やカスタマイズに関する情報は、別の記事にまとめていますので、そちらも併せてご参照ください。
PipeCDとは
PipeCDはGitOpsの原則に基づいた、アプリケーションデプロイメントを自動化するツールです。ArgoCDと同様に継続的デプロイメントが可能ですが、マルチクラウド対応やデプロイ設定の表現力の高さの観点において、ArgoCDよりも有効に作用する場面があります。
このツールは株式会社サイバーエージェント様によって開発されたOSSで、現在はCNCFのサンドボックス プロジェクトの一部となっており、コミュニティ活動も積極的に行われています。
概要
前提としてPipeCDは2つの要素から成ります。
１．Control Plane
Control Plane は、デプロイを行うエージェントを統合管理するためのマスター。ブラウザ経由でアクセスできるWebフロントUIを含みます。
| Server | Webフロントを提供する |
|---|---|
| Cachehttps://pipecd.dev/docs-v0.45.x/user-guide/managing-controlplane/architecture-overview/#cache | Serverのキャッシュを格納する(redis) |
| Ops | プロジェクトの登録やAdminユーザーの生成などのオーナータスクを実行。 |
| Data Store | アプリケーションやデプロイモデルを保存する |
| File Store | ステージログ、アプリケーションライブステータスなどを保存する |
２．Piped
Pipedは、実際にリソース上にデプロイを行うエージェントです。
デプロイするアプリケーションの参照先の設定を含みます。
PipeCDはArgoCDとは異なり、マスター(Control Plane)とエージェント(Piped)の2要素から成るCDツールです。その分インストールが複雑になりますが、必ずしもマスターをデプロイしたクラスタにエージェントを置く必要がありません。そのため、上記の図のようにGKEやEKS、オンプレなど統一性のないプロバイダ上にPipedを配置したとしても共通のControl Planeからデプロイを一元管理することができます。
PipeCDの特徴
マルチクラウド対応
Control PlaneはKubernetesクラスタ上へのデプロイが必須ですが、上記の通り、複数のクラウドリソース上のアプリケーションの継続的デリバリーを管理することができます。
そして、エージェントについていうと、インストールできる対象はkubernetesクラスタに限らず、VMやCloud Runサービス、単一マシンン等へのインストールも可能です。
このマルチクラウドへの幅広い対応が特徴として挙げられます。
Pipedがインストール可能なプロバイダ
- Kubernetes クラスタ
- Google Cloud VM
- Cloud Run
- ECS Fargate
- 単一マシン
そして、扱うことのできるアプリケーションも多岐にわたります
- Kuernetes(マニフェスト, Helm Chart)
- Terraform
- Lambda
- CloudRun
- ECS
これらすべてを一つのControl Plane上のWebUIから参照・管理することができるのがPipeCDの大きな特徴の一つです。
CDのカスタマイズ性
ArgoCDもApplication カスタムリソースを設定することでデプロイの設定を行うことができますが、PipeCDはこれに準ずるapp.pipecd.yamlをリポジトリ内に必ず配置する必要があります。
GithubActionsのworkflowsのsteps単位での設定に似ていて、どのような過程を経てデプロイを行うかに詳細に記述することができます。この独自設定したデプロイによる同期をPipeCDではPipeline Syncと表現しています。
PipeCDでは高度なデプロイ戦略を元々のマニフェストを変更することなく設定できます。カナリアデプロイメントやBlue/Greenデプロイメント等ArgoCDであれば複雑な構成を要するデプロイメントも容易に行うことができます。
設定可能なデプロイ戦略の例
- カナリアアップデート
- Blue/Greenアップデート
- WebUI上での手動承認ステージの追加
- 手動承認を要求する際のSlack通知(Slack APIの使用)
Pod構成
以下、実際にPipeCDをインストールした際のpod構成について記します。Control PlaneとPipedはいずれも同一のクラスタにデプロイしており、Data Store: mysql 、File Store: minioのクイックスタート構成です。
$ kubectl get pods -n pipecd
NAME READY STATUS RESTARTS AGE
pipecd-cache-694d89d677-ktm78 1/1 Running 0 4h48m
pipecd-gateway-5c764c7665-7fzbn 1/1 Running 0 4h48m
pipecd-minio-bd49cc57b-2nzr9 1/1 Running 0 4h48m
pipecd-mysql-57874d8cf9-l9nfq 1/1 Running 0 4h48m
pipecd-ops-84677647f9-jwvvb 1/1 Running 0 4h48m
pipecd-server-57bc5bc8d4-t9wjc 1/1 Running 0 4h48m
piped-6864b98b58-4bn7p 1/1 Running 0 80m比較として、公式のHelmChartをデフォルトの値を用いてインストールしたArgoCDの構成を記します。
$ kubectl get pods -n argocd
NAME READY STATUS RESTARTS AGE
argocd-application-controller-0 1/1 Running 0 60s
argocd-applicationset-controller-659fdcd576-nzmdw 1/1 Running 0 60s
argocd-dex-server-6c8876f7db-kx44q 1/1 Running 0 60s
argocd-notifications-controller-6c9f6c94d6-l4sgm 1/1 Running 0 60s
argocd-redis-67cbc9d9ff-7fc2h 1/1 Running 0 60s
argocd-repo-server-6875f5bd7b-x4ppz 1/1 Running 0 60s
argocd-server-58f77d54f-4rxc2 1/1 Running 0 60s
エージェントのアップデートに関しては、Controle Planeから、登録されているPipedを選択してアップデートすることができます。
高信頼性
Data Store, File Storeに関してQuickStart構成では、MySQL+minio構成でデプロイされますが、この2つは各種クラウドリソース上に配置することもできます。
| QuickStart | 利用可能構成 | |
|---|---|---|
| Data Store | MySQL (mysql:8.0.33) | Firestore, Cloud SQL, AWS RDB |
| File Store | minio(オブジェクトストレージ) | CloudStorage , S3 |
分析プロバイダの使用
PipedはDataDogとPrometheusの分析プロバイダとの接続に対応しています。Pipeline Syncにこの分析プロバイダによるクエリの実行を設定することで、アップデートの自動承認を設定することができます。
デメリット
インストールの難易度
マスターとエージェントが分離しているので、Chart一つでインストールが完結するArgoCDよりもインストールの手間がかかります。加えて、以下の理由からインストールの難易度が高くなっています。
- ArtifacthubにHelm Chartのパラメータの説明ページがない
- PipedのHelmChartにリポジトリURLを与える必要がある。
- Control PlaneとPipedの同時インストールをコード化できない
手順フロー
- PipeCDコントロールプレーンのインストール
- Ownerページでプロジェクトを作成
- PipeCDのフロントサーバーにログイン
- Piped登録用ID, PWを発行
- Pipedのインストール
- フロントサーバーからアプリケーションを登録
まず、PipeCD公式のgithubリポジトリ上のHelm Chartを使用してデプロイすることになります。Artifacthubに見られるような詳細な説明などは存在しませんでした。私がインストールした際はテンプレートの中身を参照してパラメータの意味を必要があったので、導入には時間がかかる可能性があります。
そして、Pipedのインストール時点で、登録するアプリケーションのリポジトリURLやSSHキー等を登録するため、管理するリポジトリの数＝インストールする必要のあるPipedの数となります。一つのリポジトリに複数のアプリケーションを配置してそれらを1エージェントで管理することは可能ですが、すべてUIで完結するArgoCDと比較すると煩雑に感じるかもしれません。
PipeCDはインストールの過程でプロジェクトの作成やPipedのid, keyの発行等、必ずUI操作を必要とするため同じクラスタにControl Plane, Pipedをインストールする場合に限っていうと、ArgoCDを採用したほうが、作業量も格段に少ないでしょう。
その他
- プロジェクトの削除
プロジェクト削除のインターフェースが存在しない。
- アプリケーションの削除
ArgoCDとは異なりWebUI上でアプリケーションを削除クラウドリソース上のPodやサービスなどは残り続けてしまう仕様だと考えられる。
ただ、app.pipecd.yamlのspec.pipeline.stages.with.prune:trueを設定した上で、gitリポジトリ上のマニフェストの削除を適応する形で削除が行える。
- リポジトリ内シンボリックリンクの解釈
ArgoCDでは適切なアクセス権限があればGit submodule含めシンボリックリンクを適切に解釈することができる。しかし、PipeCDにはその機能がないためリポジトリの登録時は注意する必要がある。
- WebUIのリアルタイム性が悪い
操作感としてArgoCDよりも画面更新や同期の進捗のリアルタイム性などに劣る。
- 情報が少ない
関連する記事が少ない。
また、Control Planeの構成で用いるカスタムリソースのドキュメントは公式サイトに記述されているが、Chartのネイティブリソースに関係するドキュメントは存在しない。
ユースケース
PipeCD
- 様々なクラウドリソース上に分散するプロジェクト・アプリのCDを一つのサーバー、特定の役職の人が一元的に管理・確認できる状態にしたい。
- 特にマルチクラスタやGKE+Cloud Runのサービス、つまり大規模なインフラ構成になるサービス、アプリケーションを大規模なチームで作るときに効果を発揮する。
- 新規プロジェクトを開始する時はpipedをクラスタにインストールするだけで開発がスタートできる。
- デプロイの設定などもリポジトリに格納するのでUI上での操作はほとんど不要。
- アプリ開発者はUIの画面でデプロイの進捗を確認するだけにとどまる。
- マルチテナントクラスタや物理的に分離した複数のクラスタに対してCDが行えるのでパフォーマンス的に有効。
ArgoCD
- アプリケーションが一つのクラスタで完結するという前提での利用。
- UI操作がPipeCDよりも直感的で且つ強力なので、チームでスムーズに利用しやすい。
まとめ
以上を踏まえたPipeCDの要点は以下の通りです。
- PipeCDは大規模アプリケーション、プロジェクトに有効なデプロイツール。
- マルチクラウドへの幅広い対応を提供。
- 高度なデプロイ戦略を元々のマニフェストを変更することなく設定できる。
おわりに
以上、PipeCDの概要でした。マルチクラスタ、マルチプロバイダ環境下でその効果を発揮するCDツールです。そのため、シングルクラスタの環境ではArgoCDの利用がより適しているかもしれません。
次の記事ではインストールの具体的な方法と、カスタマイズ等についてまとめますので確認してみてください。