PipeCD史上最大級の革命!プラグイン化構想をざっくり紹介
この記事では、PipeCDで絶賛開発中かつ大きな進歩である「プラグイン化」の概要を紹介します。
先にまとめ
- プラグイン化とは、デプロイ処理をPiped本体ではなくプラグインが行うようにする構想
- プラグインは自分で開発してもいいし、誰かが開発したものを利用してもいい
- 効果として、「より多様なデプロイ先に対して、より多様なStageで」デプロイ可能に
- 新たなデプロイ先の例)Cloudflare、Azure、AWS CloudFormation/CDK
- 新たなStageの例)New Relic、Amazon CloudWatchによる Analysis(デプロイ成否判断)
以下、順を追って説明していきます。
プラグイン化とはどんなものか?
プラグインの位置付け
まず「プラグイン」がPipeCD全体でどこに位置付けられるかというと、「Pipedのデプロイ処理を代理する」立ち位置になります。
現在: Pipedが各デプロイ先へのデプロイ全てを担っている
現在のPiped
プラグイン対応後: 各デプロイ先へのデプロイはプラグインが担う
Piped本体は主にデプロイのフロー制御を担います。
Piped本体とプラグインとで分担
プラグインはどこから来るのか?
各プラグインはPipeCD組込みのコードではなく、外部から取得します。
GitHubなどにプラグインのバイナリが配置され、それをPipedが起動時にロードする形式です。
設定イメージ:
# Pipedのconfig YAMLファイル
apiVersion: pipecd.dev/v1beta1
kind: Piped
spec:
plugin: # [新設項目]
- name: k8s_plugin
# [ここに指定] ※ URLの指定方法は今後変更の可能性もあります
sourceURL: https://github.com/xxxx/k8s-plugin
...
ポイントとして、プラグインは自作でもよいし、他の誰かが開発したものも利用可能です。
なお、現在PipeCDがサポートしているK8s/CloudRun/Terraform/ECS/Lambdaへのデプロイについては、公式プラグインとしてサポートします。
プラグインはどう動くのか?
プラグインは、gRPCサーバとして動作します。
- 起動方法: Piped起動時に、指定されたプラグインをロードしてgRPCサーバとして起動
- デプロイ中: Piped本体とプラグイン間でgRPC通信しながらデプロイを進行
動作時のイメージ
プラグインの作り方
プラグインは誰でも自由に開発可能です。
実装方法の詳細は、プラグイン開発ガイドを追って公開予定なので、そちらを参照してください。
プラグイン開発のハードルが下がりそうなポイントを3点紹介します。
-
プラグインの実装は「このStageでこんなデプロイ処理をする」が中心[1]
- フロー制御やGit操作などはPiped本体が行うので、Pull型デプロイの仕組みは深く理解しなくても大丈夫です。
-
プラグインはGo言語以外でも開発可能
- ただしLoggerなどの共通ライブラリの都合上、Go言語が楽だと思います。
- 作ったプラグインはPipeCD公式リポジトリに置く必要はない
- レビューポリシーやリリースタイミングなどを自由に決められます。
プラグイン化によって何ができるようになるのか?
大きく3点のメリットがあります。共通するのは「拡張性が格段に高まる」ということです。
メリット1. K8s/CloudRun/Terraform/ECS/Lambda以外にもデプロイできる
- 例)Cloudflare、Azure、Amazon CloudFormation/CDK
- デプロイ先の種類が増えた時も、対応するプラグインがあればデプロイツールをPipeCD以外に増やさないで済む
メリット2. ビルトインとは異なる挙動も実現できる
- 例)標準ではK8sはXXなデプロイだが、YYな挙動でデプロイしたい
メリット3. 独自のStageを開発・利用できる
- 例1)Analysis Stageで、New RelicやAmazon CloudWatchによってデプロイ成否分析
- 例2)K8s JobやLambda関数を起動して、ジョブを実行する
他者が開発したプラグインも利用可能なので、プラグインが増えるほどに、これらのメリットはより強力になっていきます。
今後の大まかなスケジュール
プラグイン版PipeCDは、2025年初頭にリリース予定です。
新しいプラグインが登場するのは、開発ガイドが公開される3月以降の見込みです。
新機能はプラグイン版に追加されていくので、既存のPipeCDユーザは移行をお願いします🙇
移行方法の詳細は追って公開しますが、主にPiped configとapp.pipecd.yamlの変更が必要となる見込みで、作業が極力少なく済むように考慮しています。
おわりに
プラグイン化は、PipeCDのビジョン "The One CD for All {applications, platforms, operations}" に向けた大きな一歩です。
開発過程が気になる方は、RFCや、タスク管理用Issueを参照してください。
ご質問・ご意見があれば、CNCF Slackの#pipecd-jp や PipeCD Community Meeting からいつでもよろしくお願いします🙇
-
正確にはPlan PreviewやDrift Detection機能もプラグイン側の責務となるため、必要であれば実装します ↩︎
Discussion