PipeCD Good First Issues

PipeCDについての詳細な説明です
https://pipecd.connpass.com/event/288198/

Transcript

1. Kenta Kozuka
2. @kentakozuka @kenta_kozuka Engineer at CyberAgent / Developer Productivity / #PipeCD / #Bucketeer / ✈🎾🏃⛰ こづか けんた(@kentakozuka)
3. チャンコン カイン(@khanhtc1202) @khanhtc1202 @khanhtc1202 CyberAgent Developer Productivity室 Friendly neighborhood wizard!!! 󰞵📸🎧🌉👾🐈🎶🥤♟
4. 今日のスケジュール 1. レクチャー ❏ CD周りの概念 ❏ PipeCDの概要 ❏ アーキテクチャー ❏ ソースコードの詳細な説明 ❏ リリースサイクルやコミュニティへの参加方法 1. good first issuesを見てみよう！ 2. issueをアサイン 3. （時間があれば）PRつくろー
5. Code of Conduct PipeCDはCNCFのCode of Conductに従っています。 みんなが楽しくイベントが終われば最高です😆
6. 長いです。気楽にいきましょう スライド見てもらえば分かると思いますが、量がかなりあります。 適当に休みながら見てください。 途中で休憩入れると思います。
7. いつでも質問してください 書いていて、説明するのも理解するのも難しいなと思いましたｗ 説明中にぶった切っていいので、質問してください。 Zoomのチャットでも良いです。 CNCF Slack の #pipecd, #pipecd-jp チャンネルではいつでも質問募集中です！
8. Non-code contributions コードのコントリビューションは数あるコントリビューションの一つです。 ドキュメント、ブログエントリー、Slackチャンネルでの質問・回答、イベント への参加など、全て平等で重要なコントリビューションです。 是非コミュニティに参加してください！ すごく良い記事です👇 https://github.com/readme/featured/open-source-non-code-contributions
9. 9 CI, CD周りの 開発手法の紹介
10. 基本的なCI/CDの役割
11. gitops 11
12. GitOpsはCDの１つの手法
13. GitOpsのメリット • 直接環境にアクセスしなくてよい • 全ての構成変更はGit(PR)を通して行われる • 今Gitで確認できる構成 == 今動いている構成 • 全ての変更は追跡可能
14. プログレッシブデリバリー • 機能を段階的に公開していく • ユーザーへの影響を細かく制御する • 全てのプロセスを自動化 commit rollout analyze release deploy rollback
15. プログレッシブデリバリーのプロセス • トラフィック制御（カナリアデプロイメント） • 分析（カナリア分析） • 自動化されたロールバック
16. 16 PipeCDの概要
18. One CD for All 18 全ての環境 - dev, stg, prod... 全てのオペレーション - scaling, upgrading, config updating, rolling back, infra provisioning... 全てのアプリケーション - infra, kubernetes, serverless... 全てのインフラ - public clouds such as GCP, AWS, Azure, private cloud
19. マルチプロバイダ & マルチテナント 19 様々なプラットフォーム、アプリケーション、テレメトリーに対応 マルチクラスタ・テナンシーでの運用が可能
20. Kubernetesエコシステムとのインテグレーション 20
21. GitOps
22. シンプルなUIと可視性 22 UIはアプリケーションの状態をリアルタイムで可視化し、 どのタイミングで何が発生したかが明示される
23. Control Plane & Agentモデル • デプロイはクラスタ内のpiped agentが実行 • アプリケーションのクレデンシャルが外部に漏れるこ とがない • pipedはステートレスなシングルバイナリなので場所を 選ばず、メンテも簡単
24. セキュリティ • ビルトインのシークレット管理 • RBAC • SSO
25. 高度な自動化 25 エラーレートに基づく 自動ロールバック 構成変更の自動検知
26. DevOps指標の可視化
27. Plan Preview
28. プログレッシブデリバリー • 機能を段階的に公開していく • ユーザーへの影響を細かく制御する • 全てのプロセスを自動化 commit rollout analyze release deploy rollback
29. プログレッシブデリバリーのプロセス • トラフィック制御（カナリアデプロイメント） • 分析（カナリア分析） • 自動化されたロールバック
30. メトリクスの取得 ユーザーのモニタリングシステムからメトリクスを取得 - Prometheus - Datadog - CloudWatch - NewRelic - Google Cloud Monitoring
31. 分析
32. Pipedのリモートアップグレード Piped エージェントのアップグレードはUIで簡単に可能
33. EventWatcher UPDATE CIからCDへのデリバリープロセスの自動化
34. Wait-Approval 34 デプロイに必要な承認者を指定する
35. Deployment chain 35 dev stg prd asia us europe
36. 通知機能 36 • PipeCD内の各イベントを通知 • 現在はSlackに対応
37. 37 実際に見てみよう！ pipecd.dev
38. 38 PipeCDの アーキテクチャー
39. PipeCDの全体アーキテクチャー Control PlaneとAgentの２つ 複数のPipedを管理する 例えば • プラットフォームチームがControl Plane を運用 • 各チームはpiped agentをクラスタ内に配 置するだけ pipedはシングルバイナリなのでどこでもデプロ イ可能 各チームの運用が簡単 大きい組織でスケールする
40. Control Plane - アーキテクチャー 各種API、UIを提供 ５つのコンポーネント • Server - メインコンポーネント • Ops - サブコンポーネント • Cache - Redis • DataStore - DB • FileStore - S3, GCS, Minio
41. Control Plane - Server • APIサーバー ◦ gRPC (UI, pipectl) ◦ HTTP • UIを提供
42. Control Plane - Ops • 主にバッチ処理 ◦ データを収集 ◦ DBのインデックス • UIもある ◦ Projectの作成 ◦ Static Admin Userの作成
43. Control Plane - DataStore • データオブジェクトを永続化 • 各オブジェクトについてはあとで
44. Control Plane - FileStore • ファイル形式のデータを保存する • ログ • コマンドの出力結果 • 各種指標のデータ
45. コントロールプレーン構成 ー GKE • GKE上にHelmでデプロイ • Data storeはFirestore • File storeはGCS(Google Cloud Storage) • 管理画面、監視（Grafana）へはIAPを通して アクセス • GithubでOAuthログイン • Github Teamsを使ってRBAC • Slackチャンネルへアラートを通知
46. コントロールプレーン構成 ー ECS Fargate • GKE上にHelmでデプロイ • Data storeはRDS for MySQL • File storeはS3 • CacheはElastiCache for Redis • GithubでOAuthログイン • Github Teamsを使ってRBAC • Slackチャンネルへアラートを通知
47. Piped Agent • 各クラスタ内にデプロイされる • 必ずしもクラスタ内でなくてよい • ステートレス • 実際にアプリケーションをデプロイする • Gitから構成ファイルを取得する • デプロイに必要なクレデンシャルを持つ
48. 48 質問あれば🙋
49. 49 PipeCDの用語集 📗
50. 用語集 - 1 Control Plane - コントロールプレーン、たまにPipeCDと言ったらControl Planeを指すこともある。 Agent - Piped agent、piped、単にエージェントとも Application - 1つのapp.pipecd.yamlで管理するアプリやインフラの集合 Application Kind - Applicationの種類。k8s、Terraformとか Platform Provider - Applicationを提供するサービス。今のところApplication Kindと1対1 Deployment - Applicationを環境に適用すること。ApplicationとDeploymentは1対N Stage - Pipelineの中の１つの段階、ステップのこと。例）Quick Sync, Wait, Canary Rollout, Analysis Analysis - Analysis Stageで行う分析のこと Analysis Provider - Analysisのために必要なメトリクスやログを提供するサービス ADA - Automated Deployment Analysis、Analysis Stageで自動的に分析して次のStageに進む機能
51. 用語集 - 2 Plan Preview - Git commitの変更をマージ前にユーザーに通知する機能 Drift - GitとLive Stateの差異 Drift Detection - Driftを検知すること Sync - GitとLive Stateを同期させること Sync Strategy- Syncの方法、Quick Sync, Pipeline Syncとか Insight - PipeCDで収集・表示しているデプロイ周りの指標とその可視化機能 Event Watcher - CIからPipeCDに通知してGitのファイルを更新し、シームレスにCDの処理につなげる機能 Deployment Chain - DeploymentとDeploymentを鎖のように繋げて実行する機能
52. 52 Data Objects
53. Data Object • Piped - Piped Agentの情報 • Project - Projectの情報。Projectはデータの論理グループ。 • Application - Applicationの情報 • Deployment - Deploymentの情報 • API key - 外部からの通信に使用 • Deployment chain - Deployment chainの関係 • Event - EventWatcherで使用される。今日は省きます • Command - 後述 ※ Userという概念はPipeCDにはない
54. 54 Command
55. Command • PipeCDの各コンポーネント（UI、CLI, pipedなど）から非同期的にアクションが起こる。 ◦ ボタンクリック ◦ pipectl実行 ◦ Githubのプッシュ ◦ etc. • それらをすぐには実行せず、Commandという形でDBに保存する。 • ワーカーが定期的にCommandを取り出し、適切にスケジューリングして実行していく • @kentakozukaはシンプルなイベントドリブン・アーキテクチャーと思っている
56. Command Commandの種類 • SYNC_APPLICATION - ApplicationをSyncする • UPDATE_APPLICATION_CONFIG - Applicationの構成を更新する（EventWatcher） • CANCEL_DEPLOYMENT - 実行中のDeploymentをキャンセルする • APPROVE_STAGE - Wait-Approveステージで承認する • BUILD_PLAN_PREVIEW - Plan-Previewを実行する • CHAIN_SYNC_APPLICATION - ApplicationをSyncする（Deployment Chain） • SKIP_STAGE - Deploymentのステージをスキップする • RESTART_PIPED - Piped agentを再起動する https://github.com/pipe-cd/pipecd/blob/master/pkg/model/command.proto
57. Command Status Commandのステータスを表す • COMMAND_NOT_HANDLED_YET • COMMAND_SUCCEEDED • COMMAND_FAILED • COMMAND_TIMEOUT https://github.com/pipe-cd/pipecd/blob/master/pkg/model/command.proto
58. 58 Deployment
59. Deployment Applicationを環境に適用すること。ApplicationとDeploymentは1対N １つのApplicationを何回もDeployする Sync - GitとLive Stateを同期させること、ほぼDeploymentと同義 Sync Strategy- Syncの方法、2つある 1. Quick Sync - シンプルにConfigを環境に適用する 2. Pipeline Sync - ユーザーが指定した方法で行う 3. (Auto Sync) - PipeCD側のアルゴリズムに従ってQuick SyncかPipeline Syncか判断する
60. Deployment Pipeline ユーザーが自由に設定できるDeploymentの手順 Stage - Pipelineの中の１つの段階、ステップのこと。例）Wait, Canary Rollout, Analysis Quick Sync StrategyはQuick Syncという１つのステージのみを持つ
61. Deployment Status Deploymentの各ステータス PENDING - トリガーするとまずこのステータスになる PLANNED - 実行することが決定して、待っている状態 RUNNING - 実行中 ROLLING_BACK - ロールバック中 SUCCESS - 問題なく完了した状態 FAILURE - 実行中にエラーが発生して終了した状態 CANCELLED - なにかによってキャンセルされた デプロイメントはPENDINGから始まり、 SUCCESS/FAILURE/CANCELLEDのどれかで終わる
62. Deployment オブジェクト ApplicationId - ApplicationのID PipedId - Applicationを管理しているPipedのID ProjectId - Pipedが属しているProjectのID RunningCommitHash - Deploymentに使うGit commit hash GitPath - アプリケーション構成ファイルのパス PlatformProvider - k8s, Terraformなど Trigger - Deployementが誰によって、どのようにトリガーしたのかの情報 Versions - Deploymentで使用するアーティファクトの情報、例えば - Kind: CONTAINER_IMAGE, URL: https://registry.hub.docker.com, Version: ubuntu:20.04 Status - ステータス Stages - Deployment pipelineの各ステージの情報
63. 63 ソースコードの くわしい解説 👀
64. リポジトリ https://github.com/pipe-cd/pipecd
65. リポジトリのディレクトリ構成 cmd - 各コンポーネントのエントリーポイント docs - ドキュメント examples - 各フィーチャーを試すための簡単な構成ファイル hacks - いろんなスクリプト manifests - helm charts pkg - 実際のGoのコード quickstart - Quickstartで必要なコンフィグ test - インテグレーションテストのコード tool - 開発に使うGoのアプリコード web - WebUI CONTRIBUTING.md - コントリビュートについてのあれこれ Makefile - 開発中に使う便利コマンド集
66. cmd/ • 各コンポーネントのエントリーポイント ◦ launcher ◦ pipecd ◦ pipectl ◦ piped cobraを使ってます
67. launcher • pipedをUIから更新するリモートアップグレードを行う 詳しくはドキュメント参照
68. pipectl Command Line Interface • Control Planeと通信してPipeCDの設定を表示・変更可能 • シェルスクリプトと組み合わせて、PipeCDの設定をプログラム可能
69. 69 Deployment Deep Dive
70. piped - PipeCDの超重要コンポーネント • piped agent • PipeCDのdaemonだからpiped • シングルバイナリ • Deploymentを行う • 通信は基本全てoutbound ◦ Control PlaneとのgRPC ◦ Git client ◦ 各Application • 実はinboundもある ◦ admin server ▪ health status ▪ running version ▪ go profile ▪ monitoring metrics
71. pipedの重要人物たち 本当はもっとあります https://github.com/pipe-cd/pipecd/tree/master/pkg/app/piped
72. Application Live State Store • ApplicationのLive State（現在の状態）を取得してキャッシュとして保持する • 実装はPlatform Providerによって分かれている https://github.com/pipe-cd/pipecd/blob/master/pkg/app/piped/livestatestore/livestat estore.go
73. Application Live State Reporter • ApplicationのLive StateをApplication Live State Storeから受け取って、Control Plane に送る https://github.com/pipe-cd/pipecd/tree/master/pkg/app/piped/livestatereporter
74. Application Drift Detector • Gitリポジトリから構成ファイルを取得 • Application Live State StoreからApplication Live Stateを取得 • 両者を比較し、Drift（差異）をApplication.SyncStateというオブジェクトに入れて、 Controle Planeに送る https://github.com/pipe-cd/pipecd/tree/master/pkg/app/piped/driftdetector
75. Deployment Trigger デプロイメントをトリガーする 定期実行とオンデマンドの２つの処理がある https://github.com/pipe-cd/pipecd/tree/master/pkg/app/piped/trigger
76. Deployment Trigger 定期実行 - Control PlaneからApplicationを取得して必要であればDeploymentをトリガーする オンデマンド - Control PlaneからCommandを取得してDeploymentをトリガーする
77. Deployment Controller Control PlaneからDeploymentを取得し、適切にスケジューリングしつつApplicationをデプロ イする賢いやつ。例えるなら監督みたい？ https://github.com/pipe-cd/pipecd/tree/master/pkg/app/piped/controller
78. Deployment Controllerの内部 Controller - PlannersとSchedulersを内部に持ち、うまく協調させながらDeploymentを行う Planner - Deploymentをどのように実行するか決定する。 - 要はSync Strategyを決定する Scheduler - Deploymentを実行する https://github.com/pipe-cd/pipecd/blob/8ea515a42e7c129bf2bfd32396db5960b0283a 06/pkg/app/piped/controller/controller.go#L107
79. Deployment Controllerが定期的に実行するもの - syncPlanners() - syncSchedulers() - checkCommands() https://github.com/pipe-cd/pipecd/blob/8ea515a42e7c129bf2bfd32396db5960b0283a 06/pkg/app/piped/controller/controller.go#L231-L236
80. syncPlanners() 1. PENDING ステータスのDeploymentを取得する 2. Deployment１つにつき、１つのPlannerを作成 3. goroutineでplanner.Run() https://github.com/pipe-cd/pipecd/blob/8ea515a42e7c129bf2bfd32396db5960b0283a 06/pkg/app/piped/controller/controller.go#L291
81. planner.Run() - 各Platform ProviderのPlannerを呼び出す - Sync Strategyを決定する - Deployment Statusを PLANNED に変更する https://github.com/pipe-cd/pipecd/blob/8ea515a42e7c129bf2bfd32396db5960b0283a 06/pkg/app/piped/controller/controller.go#L499C23-L499C23
82. syncSchedulers() - Statusが PLANNED と RUNNING のDeploymentを取得 - Deployment１つにつき、１つのSchedulerを作成 - schedule毎に作業ディレクトリを作って、goroutineでscheduler.Run() FAQ - Q: なぜRUNNINGも取得している？ A: Pipedがdeploymentの実行中に再起動になった可能性もある
83. scheduler.Run() - 必要であればDeploymentステータスを RUNNING に変更 - 全ての完了していないStageをひとつずつ実行していく(code) - executeState() - 実行詳細は Platform Provider によって異なる - 最終的にステータスを SUCCESS, FAILURE, CANCELLED のどれかに変更して終了
84. checkCommands() code 実行されていないCommandを取得 必要ならばPlannerやSchedulerにGo channelを通してDeploymentをキャンセルする。
85. 85 Let’s take a 5min break
86. 86 How to Start Contributing
87. How to Start Contributing to PipeCD Contributing to PipeCDを読んでみよう！
88. 88 Good First Issues
89. PipeCD’s Good First Issues 最初にやるのにちょうどよいIssueにつけるラベル • Let’s browse PipeCD’s good first issues!
90. 90 Let’s Create a PR!
91. pipe-cd/pipe @pipecd_dev https://pipecd.dev/ We always welcome your contributions!