Tweet
Tweet

Slide 1

Slide 1 text

Kenta Kozuka

Slide 2

Slide 2 text

@kentakozuka @kenta_kozuka Engineer at CyberAgent / Developer Productivity / #PipeCD / #Bucketeer / ✈🎾🏃⛰ こづか けんた(@kentakozuka)

Slide 3

Slide 3 text

チャンコン カイン(@khanhtc1202) @khanhtc1202 @khanhtc1202 CyberAgent Developer Productivity室 Friendly neighborhood wizard!!! 󰞵📸🎧🌉👾🐈🎶🥤♟

Slide 4

Slide 4 text

今日のスケジュール 1. レクチャー ❏ CD周りの概念 ❏ PipeCDの概要 ❏ アーキテクチャー ❏ ソースコードの詳細な説明 ❏ リリースサイクルやコミュニティへの参加方法 1. good first issuesを見てみよう！ 2. issueをアサイン 3. （時間があれば）PRつくろー

Slide 5

Slide 5 text

Code of Conduct PipeCDはCNCFのCode of Conductに従っています。 みんなが楽しくイベントが終われば最高です😆

Slide 6

Slide 6 text

長いです。気楽にいきましょう スライド見てもらえば分かると思いますが、量がかなりあります。 適当に休みながら見てください。 途中で休憩入れると思います。

Slide 7

Slide 7 text

いつでも質問してください 書いていて、説明するのも理解するのも難しいなと思いましたｗ 説明中にぶった切っていいので、質問してください。 Zoomのチャットでも良いです。 CNCF Slack の #pipecd, #pipecd-jp チャンネルではいつでも質問募集中です！

Slide 8

Slide 8 text

Non-code contributions コードのコントリビューションは数あるコントリビューションの一つです。 ドキュメント、ブログエントリー、Slackチャンネルでの質問・回答、イベント への参加など、全て平等で重要なコントリビューションです。 是非コミュニティに参加してください！ すごく良い記事です👇 https://github.com/readme/featured/open-source-non-code-contributions

Slide 9

Slide 9 text

9 CI, CD周りの 開発手法の紹介

Slide 10

Slide 10 text

基本的なCI/CDの役割

Slide 11

Slide 11 text

gitops 11

Slide 12

Slide 12 text

GitOpsはCDの１つの手法

Slide 13

Slide 13 text

GitOpsのメリット ● 直接環境にアクセスしなくてよい ● 全ての構成変更はGit(PR)を通して行われる ● 今Gitで確認できる構成 == 今動いている構成 ● 全ての変更は追跡可能

Slide 14

Slide 14 text

プログレッシブデリバリー ● 機能を段階的に公開していく ● ユーザーへの影響を細かく制御する ● 全てのプロセスを自動化 commit rollout analyze release deploy rollback

Slide 15

Slide 15 text

プログレッシブデリバリーのプロセス ● トラフィック制御（カナリアデプロイメント） ● 分析（カナリア分析） ● 自動化されたロールバック

Slide 16

Slide 16 text

16 PipeCDの概要

Slide 17

Slide 17 text

17

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

マルチプロバイダ & マルチテナント 19 様々なプラットフォーム、アプリケーション、テレメトリーに対応 マルチクラスタ・テナンシーでの運用が可能

Slide 20

Slide 20 text

Kubernetesエコシステムとのインテグレーション 20

Slide 21

Slide 21 text

GitOps

Slide 22

Slide 22 text

シンプルなUIと可視性 22 UIはアプリケーションの状態をリアルタイムで可視化し、 どのタイミングで何が発生したかが明示される

Slide 23

Slide 23 text

Control Plane & Agentモデル ● デプロイはクラスタ内のpiped agentが実行 ● アプリケーションのクレデンシャルが外部に漏れるこ とがない ● pipedはステートレスなシングルバイナリなので場所を 選ばず、メンテも簡単

Slide 24

Slide 24 text

セキュリティ ● ビルトインのシークレット管理 ● RBAC ● SSO

Slide 25

Slide 25 text

高度な自動化 25 エラーレートに基づく 自動ロールバック 構成変更の自動検知

Slide 26

Slide 26 text

DevOps指標の可視化

Slide 27

Slide 27 text

Plan Preview

Slide 28

Slide 28 text

プログレッシブデリバリー ● 機能を段階的に公開していく ● ユーザーへの影響を細かく制御する ● 全てのプロセスを自動化 commit rollout analyze release deploy rollback

Slide 29

Slide 29 text

プログレッシブデリバリーのプロセス ● トラフィック制御（カナリアデプロイメント） ● 分析（カナリア分析） ● 自動化されたロールバック

Slide 30

Slide 30 text

メトリクスの取得 ユーザーのモニタリングシステムからメトリクスを取得 - Prometheus - Datadog - CloudWatch - NewRelic - Google Cloud Monitoring

Slide 31

Slide 31 text

分析

Slide 32

Slide 32 text

Pipedのリモートアップグレード Piped エージェントのアップグレードはUIで簡単に可能

Slide 33

Slide 33 text

EventWatcher UPDATE CIからCDへのデリバリープロセスの自動化

Slide 34

Slide 34 text

Wait-Approval 34 デプロイに必要な承認者を指定する

Slide 35

Slide 35 text

Deployment chain 35 dev stg prd asia us europe

Slide 36

Slide 36 text

通知機能 36 ● PipeCD内の各イベントを通知 ● 現在はSlackに対応

Slide 37

Slide 37 text

37 実際に見てみよう！ pipecd.dev

Slide 38

Slide 38 text

38 PipeCDの アーキテクチャー

Slide 39

Slide 39 text

PipeCDの全体アーキテクチャー Control PlaneとAgentの２つ 複数のPipedを管理する 例えば ● プラットフォームチームがControl Plane を運用 ● 各チームはpiped agentをクラスタ内に配 置するだけ pipedはシングルバイナリなのでどこでもデプロ イ可能 各チームの運用が簡単 大きい組織でスケールする

Slide 40

Slide 40 text

Control Plane - アーキテクチャー 各種API、UIを提供 ５つのコンポーネント ● Server - メインコンポーネント ● Ops - サブコンポーネント ● Cache - Redis ● DataStore - DB ● FileStore - S3, GCS, Minio

Slide 41

Slide 41 text

Control Plane - Server ● APIサーバー ○ gRPC (UI, pipectl) ○ HTTP ● UIを提供

Slide 42

Slide 42 text

Control Plane - Ops ● 主にバッチ処理 ○ データを収集 ○ DBのインデックス ● UIもある ○ Projectの作成 ○ Static Admin Userの作成

Slide 43

Slide 43 text

Control Plane - DataStore ● データオブジェクトを永続化 ● 各オブジェクトについてはあとで

Slide 44

Slide 44 text

Control Plane - FileStore ● ファイル形式のデータを保存する ● ログ ● コマンドの出力結果 ● 各種指標のデータ

Slide 45

Slide 45 text

コントロールプレーン構成 ー GKE ● GKE上にHelmでデプロイ ● Data storeはFirestore ● File storeはGCS(Google Cloud Storage) ● 管理画面、監視（Grafana）へはIAPを通して アクセス ● GithubでOAuthログイン ● Github Teamsを使ってRBAC ● Slackチャンネルへアラートを通知

Slide 46

Slide 46 text

コントロールプレーン構成 ー ECS Fargate ● GKE上にHelmでデプロイ ● Data storeはRDS for MySQL ● File storeはS3 ● CacheはElastiCache for Redis ● GithubでOAuthログイン ● Github Teamsを使ってRBAC ● Slackチャンネルへアラートを通知

Slide 47

Slide 47 text

Piped Agent ● 各クラスタ内にデプロイされる ● 必ずしもクラスタ内でなくてよい ● ステートレス ● 実際にアプリケーションをデプロイする ● Gitから構成ファイルを取得する ● デプロイに必要なクレデンシャルを持つ

Slide 48

Slide 48 text

48 質問あれば🙋

Slide 49

Slide 49 text

49 PipeCDの用語集 📗

Slide 50

Slide 50 text

用語集 - 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に進む機能

Slide 51

Slide 51 text

用語集 - 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を鎖のように繋げて実行する機能

Slide 52

Slide 52 text

52 Data Objects

Slide 53

Slide 53 text

Data Object ● Piped - Piped Agentの情報 ● Project - Projectの情報。Projectはデータの論理グループ。 ● Application - Applicationの情報 ● Deployment - Deploymentの情報 ● API key - 外部からの通信に使用 ● Deployment chain - Deployment chainの関係 ● Event - EventWatcherで使用される。今日は省きます ● Command - 後述 ※ Userという概念はPipeCDにはない

Slide 54

Slide 54 text

54 Command

Slide 55

Slide 55 text

Command ● PipeCDの各コンポーネント（UI、CLI, pipedなど）から非同期的にアクションが起こる。 ○ ボタンクリック ○ pipectl実行 ○ Githubのプッシュ ○ etc. ● それらをすぐには実行せず、Commandという形でDBに保存する。 ● ワーカーが定期的にCommandを取り出し、適切にスケジューリングして実行していく ● @kentakozukaはシンプルなイベントドリブン・アーキテクチャーと思っている

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

58 Deployment

Slide 59

Slide 59 text

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か判断する

Slide 60

Slide 60 text

Deployment Pipeline ユーザーが自由に設定できるDeploymentの手順 Stage - Pipelineの中の１つの段階、ステップのこと。例）Wait, Canary Rollout, Analysis Quick Sync StrategyはQuick Syncという１つのステージのみを持つ

Slide 61

Slide 61 text

Deployment Status Deploymentの各ステータス PENDING - トリガーするとまずこのステータスになる PLANNED - 実行することが決定して、待っている状態 RUNNING - 実行中 ROLLING_BACK - ロールバック中 SUCCESS - 問題なく完了した状態 FAILURE - 実行中にエラーが発生して終了した状態 CANCELLED - なにかによってキャンセルされた デプロイメントはPENDINGから始まり、 SUCCESS/FAILURE/CANCELLEDのどれかで終わる

Slide 62

Slide 62 text

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の各ステージの情報

Slide 63

Slide 63 text

63 ソースコードの くわしい解説 👀

Slide 64

Slide 64 text

リポジトリ https://github.com/pipe-cd/pipecd

Slide 65

Slide 65 text

リポジトリのディレクトリ構成 cmd - 各コンポーネントのエントリーポイント docs - ドキュメント examples - 各フィーチャーを試すための簡単な構成ファイル hacks - いろんなスクリプト manifests - helm charts pkg - 実際のGoのコード quickstart - Quickstartで必要なコンフィグ test - インテグレーションテストのコード tool - 開発に使うGoのアプリコード web - WebUI CONTRIBUTING.md - コントリビュートについてのあれこれ Makefile - 開発中に使う便利コマンド集

Slide 66

Slide 66 text

cmd/ ● 各コンポーネントのエントリーポイント ○ launcher ○ pipecd ○ pipectl ○ piped cobraを使ってます

Slide 67

Slide 67 text

launcher ● pipedをUIから更新するリモートアップグレードを行う 詳しくはドキュメント参照

Slide 68

Slide 68 text

pipectl Command Line Interface ● Control Planeと通信してPipeCDの設定を表示・変更可能 ● シェルスクリプトと組み合わせて、PipeCDの設定をプログラム可能

Slide 69

Slide 69 text

69 Deployment Deep Dive

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

pipedの重要人物たち 本当はもっとあります https://github.com/pipe-cd/pipecd/tree/master/pkg/app/piped

Slide 72

Slide 72 text

Application Live State Store ● ApplicationのLive State（現在の状態）を取得してキャッシュとして保持する ● 実装はPlatform Providerによって分かれている https://github.com/pipe-cd/pipecd/blob/master/pkg/app/piped/livestatestore/livestat estore.go

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

Deployment Trigger デプロイメントをトリガーする 定期実行とオンデマンドの２つの処理がある https://github.com/pipe-cd/pipecd/tree/master/pkg/app/piped/trigger

Slide 76

Slide 76 text

Deployment Trigger 定期実行 - Control PlaneからApplicationを取得して必要であればDeploymentをトリガーする オンデマンド - Control PlaneからCommandを取得してDeploymentをトリガーする

Slide 77

Slide 77 text

Deployment Controller Control PlaneからDeploymentを取得し、適切にスケジューリングしつつApplicationをデプロ イする賢いやつ。例えるなら監督みたい？ https://github.com/pipe-cd/pipecd/tree/master/pkg/app/piped/controller

Slide 78

Slide 78 text

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

Slide 79

Slide 79 text

Deployment Controllerが定期的に実行するもの - syncPlanners() - syncSchedulers() - checkCommands() https://github.com/pipe-cd/pipecd/blob/8ea515a42e7c129bf2bfd32396db5960b0283a 06/pkg/app/piped/controller/controller.go#L231-L236

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

syncSchedulers() - Statusが PLANNED と RUNNING のDeploymentを取得 - Deployment１つにつき、１つのSchedulerを作成 - schedule毎に作業ディレクトリを作って、goroutineでscheduler.Run() FAQ - Q: なぜRUNNINGも取得している？ A: Pipedがdeploymentの実行中に再起動になった可能性もある

Slide 83

Slide 83 text

scheduler.Run() - 必要であればDeploymentステータスを RUNNING に変更 - 全ての完了していないStageをひとつずつ実行していく(code) - executeState() - 実行詳細は Platform Provider によって異なる - 最終的にステータスを SUCCESS, FAILURE, CANCELLED のどれかに変更して終了

Slide 84

Slide 84 text

checkCommands() code 実行されていないCommandを取得 必要ならばPlannerやSchedulerにGo channelを通してDeploymentをキャンセルする。

Slide 85

Slide 85 text

85 Let’s take a 5min break

Slide 86

Slide 86 text

86 How to Start Contributing

Slide 87

Slide 87 text

How to Start Contributing to PipeCD Contributing to PipeCDを読んでみよう！

Slide 88

Slide 88 text

88 Good First Issues

Slide 89

Slide 89 text

PipeCD’s Good First Issues 最初にやるのにちょうどよいIssueにつけるラベル ● Let’s browse PipeCD’s good first issues!

Slide 90

Slide 90 text

90 Let’s Create a PR!

Slide 91

Slide 91 text

pipe-cd/pipe @pipecd_dev https://pipecd.dev/ We always welcome your contributions!