Kenta Kozuka

こづか けんた(@kentakozuka)

@kentakozuka

@kenta_kozuka

​

Engineer at CyberAgent / Developer Productivity / #PipeCD / #Bucketeer / ✈️🎾🏃⛰️

​

チャンコン カイン(@khanhtc1202)

CyberAgent Developer Productivity室

Friendly neighborhood wizard!!! 👨‍💻📸🎧🌉👾🐈🎶🥤♟

​

今日のスケジュール

​

​

​

​

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

Code of Conduct

​

​

​

PipeCDはCNCFのCode of Conductに従っています。

みんなが楽しくイベントが終われば最高です😆

長いです。気楽にいきましょう

​

​

スライド見てもらえば分かると思いますが、量がかなりあります。

適当に休みながら見てください。

途中で休憩入れると思います。

いつでも質問してください

​

書いていて、説明するのも理解するのも難しいなと思いましたｗ

説明中にぶった切っていいので、質問してください。

Zoomのチャットでも良いです。

​

CNCF Slack の #pipecd, #pipecd-jp チャンネルではいつでも質問募集中です！

Non-code contributions

​

​

​

コードのコントリビューションは数あるコントリビューションの一つです。

ドキュメント、ブログエントリー、Slackチャンネルでの質問・回答、イベントへの参加など、全て平等で重要なコントリビューションです。

是非コミュニティに参加してください！

​

​

すごく良い記事です👇

https://github.com/readme/featured/open-source-non-code-contributions

9

CI, CD周りの

開発手法の紹介

基本的なCI/CDの役割

gitops

11

GitOpsはCDの１つの手法

GitOpsのメリット

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

​

プログレッシブデリバリー

• 機能を段階的に公開していく
• ユーザーへの影響を細かく制御する
• 全てのプロセスを自動化

​

commit

rollout

analyze

release

deploy

rollback

プログレッシブデリバリーのプロセス

• トラフィック制御（カナリアデプロイメント）
• 分析（カナリア分析）
• 自動化されたロールバック

​

16

PipeCDの概要

17

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

様々なプラットフォーム、アプリケーション、テレメトリーに対応

マルチクラスタ・テナンシーでの運用が可能

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

20

GitOps

シンプルなUIと可視性

22

UIはアプリケーションの状態をリアルタイムで可視化し、

どのタイミングで何が発生したかが明示される

Control Plane & Agentモデル

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

セキュリティ

• ビルトインのシークレット管理
• RBAC
• SSO

​

高度な自動化

25

エラーレートに基づく

自動ロールバック

構成変更の自動検知

DevOps指標の可視化

Plan Preview

プログレッシブデリバリー

• 機能を段階的に公開していく
• ユーザーへの影響を細かく制御する
• 全てのプロセスを自動化

​

commit

rollout

analyze

release

deploy

rollback

プログレッシブデリバリーのプロセス

• トラフィック制御（カナリアデプロイメント）
• 分析（カナリア分析）
• 自動化されたロールバック

​

メトリクスの取得

ユーザーのモニタリングシステムからメトリクスを取得

• Prometheus
• Datadog
• CloudWatch
• NewRelic
• Google Cloud Monitoring

分析

Pipedのリモートアップグレード

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

EventWatcher

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

Wait-Approval

34

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

Deployment chain

35

dev

stg

prd

asia

us

europe

通知機能

• PipeCD内の各イベントを通知
• 現在はSlackに対応

​

36

37

実際に見てみよう！

pipecd.dev

38

PipeCDの

アーキテクチャー

PipeCDの全体アーキテクチャー

Control PlaneとAgentの２つ

複数のPipedを管理する

例えば

• プラットフォームチームがControl Planeを運用
• 各チームはpiped agentをクラスタ内に配置するだけ

pipedはシングルバイナリなのでどこでもデプロイ可能

各チームの運用が簡単

大きい組織でスケールする

Control Plane - アーキテクチャー

各種API、UIを提供

​

５つのコンポーネント

• Server - メインコンポーネント
• Ops - サブコンポーネント
• Cache - Redis
• DataStore - DB
• FileStore - S3, GCS, Minio

Control Plane - Server

• APIサーバー
• gRPC (UI, pipectl)
• HTTP
• UIを提供

Control Plane - Ops

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

Control Plane - DataStore

• データオブジェクトを永続化
• 各オブジェクトについてはあとで

Control Plane - FileStore

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

コントロールプレーン構成 ー GKE

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

コントロールプレーン構成 ー ECS Fargate

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

Piped Agent

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

48

質問あれば🙋

49

PipeCDの用語集📗

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

​

用語集 - 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

Data Objects

Data Object

• Piped - Piped Agentの情報
• Project - Projectの情報。Projectはデータの論理グループ。
• Application - Applicationの情報
• Deployment - Deploymentの情報
• API key - 外部からの通信に使用
• Deployment chain - Deployment chainの関係
• Event - EventWatcherで使用される。今日は省きます
• Command - 後述

​

※ Userという概念はPipeCDにはない

54

Command

Command

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

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

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

Deployment

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

​

Deployment Pipeline

​

​

ユーザーが自由に設定できるDeploymentの手順

Stage - Pipelineの中の１つの段階、ステップのこと。例）Wait, Canary Rollout, Analysis

Quick Sync StrategyはQuick Syncという１つのステージのみを持つ

​

Deployment Status

​

​

Deploymentの各ステータス

​

PENDING - トリガーするとまずこのステータスになるPLANNED - 実行することが決定して、待っている状態RUNNING - 実行中

ROLLING_BACK - ロールバック中

SUCCESS - 問題なく完了した状態

FAILURE - 実行中にエラーが発生して終了した状態

CANCELLED - なにかによってキャンセルされた

​

デプロイメントはPENDINGから始まり、SUCCESS/FAILURE/CANCELLEDのどれかで終わる

​

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

ソースコードの

くわしい解説 👀

リポジトリ

​

https://github.com/pipe-cd/pipecd

​

リポジトリのディレクトリ構成

​

​

cmd - 各コンポーネントのエントリーポイント

docs - ドキュメント

examples - 各フィーチャーを試すための簡単な構成ファイル

hacks - いろんなスクリプト

manifests - helm charts

pkg - 実際のGoのコード

quickstart - Quickstartで必要なコンフィグ

test - インテグレーションテストのコード

tool - 開発に使うGoのアプリコード

web - WebUI

CONTRIBUTING.md - コントリビュートについてのあれこれ

Makefile - 開発中に使う便利コマンド集

​

cmd/

• 各コンポーネントのエントリーポイント
• launcher
• pipecd
• pipectl
• piped

​

cobraを使ってます

launcher

• pipedをUIから更新するリモートアップグレードを行う

​

詳しくはドキュメント参照

pipectl

Command Line Interface

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

69

Deployment

Deep Dive

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

pipedの重要人物たち

本当はもっとあります

https://github.com/pipe-cd/pipecd/tree/master/pkg/app/piped

Application Live State Store

​

​

• ApplicationのLive State（現在の状態）を取得してキャッシュとして保持する
• 実装はPlatform Providerによって分かれている

https://github.com/pipe-cd/pipecd/blob/master/pkg/app/piped/livestatestore/livestatestore.go

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

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

Deployment Trigger

​

デプロイメントをトリガーする

定期実行とオンデマンドの２つの処理がある

https://github.com/pipe-cd/pipecd/tree/master/pkg/app/piped/trigger

Deployment Trigger

​

定期実行

• Control PlaneからApplicationを取得して必要であればDeploymentをトリガーする

オンデマンド

• Control PlaneからCommandを取得してDeploymentをトリガーする

Deployment Controller

​

Control PlaneからDeploymentを取得し、適切にスケジューリングしつつApplicationをデプロイする賢いやつ。例えるなら監督みたい？

​

https://github.com/pipe-cd/pipecd/tree/master/pkg/app/piped/controller

Deployment Controllerの内部

Controller

• PlannersとSchedulersを内部に持ち、うまく協調させながらDeploymentを行う

Planner

• Deploymentをどのように実行するか決定する。
• 要はSync Strategyを決定する

Scheduler

• Deploymentを実行する

​

https://github.com/pipe-cd/pipecd/blob/8ea515a42e7c129bf2bfd32396db5960b0283a06/pkg/app/piped/controller/controller.go#L107

Deployment Controllerが定期的に実行するもの

• syncPlanners()
• syncSchedulers()
• checkCommands()

​

https://github.com/pipe-cd/pipecd/blob/8ea515a42e7c129bf2bfd32396db5960b0283a06/pkg/app/piped/controller/controller.go#L231-L236

​

syncPlanners()

1. PENDING ステータスのDeploymentを取得する
2. Deployment１つにつき、１つのPlannerを作成
3. goroutineでplanner.Run()

​

https://github.com/pipe-cd/pipecd/blob/8ea515a42e7c129bf2bfd32396db5960b0283a06/pkg/app/piped/controller/controller.go#L291

planner.Run()

• 各Platform ProviderのPlannerを呼び出す
• Sync Strategyを決定する
• Deployment Statusを PLANNED に変更する

​

https://github.com/pipe-cd/pipecd/blob/8ea515a42e7c129bf2bfd32396db5960b0283a06/pkg/app/piped/controller/controller.go#L499C23-L499C23

​

syncSchedulers()

• Statusが PLANNED と RUNNING のDeploymentを取得
• Deployment１つにつき、１つのSchedulerを作成
• schedule毎に作業ディレクトリを作って、goroutineでscheduler.Run()

​

FAQ

• Q: なぜRUNNINGも取得している？

A: Pipedがdeploymentの実行中に再起動になった可能性もある

​

scheduler.Run()

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

​

checkCommands()

code

実行されていないCommandを取得

必要ならばPlannerやSchedulerにGo channelを通してDeploymentをキャンセルする。

85

Let’s take a 5min break

86

How to Start Contributing

How to Start Contributing to PipeCD

Contributing to PipeCDを読んでみよう！

88

Good First Issues

PipeCD’s Good First Issues

最初にやるのにちょうどよいIssueにつけるラベル

• Let’s browse PipeCD’s good first issues!

90

Let’s Create a PR!

https://pipecd.dev/

We always welcome your contributions!