Save 37% off PRO during our Black Friday Sale! »

CloudNative Days を支える CI/CD ワークフローの変遷

Cb17938137021ead2656d0fe58b7c7b1?s=47 kanata
October 18, 2021

CloudNative Days を支える CI/CD ワークフローの変遷

CloudNative Days Tokyo 2021 プレイベント (https://cloudnativedays.connpass.com/event/226567/) の発表資料です
---
pdf 化して少し崩れたので、Google Slides のリンクも貼っておきます
https://docs.google.com/presentation/d/1JxLIAROmiQh_1QZicTs7bMsnl4vnOvFBtmkp6Mvs5rA/edit?usp=sharing

Cb17938137021ead2656d0fe58b7c7b1?s=128

kanata

October 18, 2021
Tweet

Transcript

  1. CloudNative Days を支える CI/CD ワークフローの変遷 かなた / @kanatakita
 1

  2. $ whoami 北澤 祥太 / かなた
 @kanatakita
 ShotaKitazawa
 本業:
 パブリッククラウドサービス開発のための共通基盤の構築・運用


    SRE の導入・推進
 趣味:
 ラーメン、スノボ、自宅鯖構築 最近できてない、イベント裏方
 最近:
 ISUCON11 予選作問担当、reviewapp-operator 開発
 2 よく使う アイコン
  3. 本日のお話 3

  4. CloudNative Days の運営体制 4 Operation Promotion Contents Dreamkast Broadcast SNS等への


    プロモーション
 配信周りの
 エンジニアリング
 配信基盤の開発・運用 
 イベント当日オペレーション担当 
 イベントコンテンツの 
 考案・準備

  5. Dreamkast チームの取り組み > 配信プラットフォームの開発
 • Ruby on Rails (dreamkast) /

    
 React (dreamkast-ui) にて開発
 • オンラインカンファレンスに
 必要な機能を Web サービスとして提供
 (ストリーム配信/チャット/QA機能/...)
 
 > アプリケーション動作基盤の構築・運用
 • AWS / EKS を利用
 • アプリケーションに対する
 CI/CD やモニタリングも実施
 5
  6. 本日のお話 6 Dreamkast の


  7. TL;DR この発表を3行でまとめると
 • 従来の Dreamkast のリリースフローをいい感じに作ったけど
 • 運用してくうちに痒いところが何個か出てきたから
 • kubernetes

    operator を自作してもっといい感じにしたよ
 7
  8. 従来の話 ~ CloudNative Days Spring 2021 Online (Mar 11-12, 2021)

    8
  9. Dreamkast v2 Infra Architcture 9 more information... Kubernetesなんて知りたくなかった。ただ楽してアプリを作りたかっただけなんだ。 
 @jacopen

    ー CloudNative Days Spring 2021 Online 
 dreamkast
 dreamkast-ui
 cert-manager
 redis
 Argo CD
 Prometheus
 Grafana
 Loki
 2 環境
 dev/prod
 リソース管理
 ドメイン管理
 external-
 secrets

  10. アプリケーションリポジトリ (app-repo) とマニフェストリポジトリ (infra-repo) を分割
 infra-repo app-repo Dreamkast v2 のリポジトリ構成

    10 dreamkast
 dreamkast-ui
 dreamkast-infra
 Argo CD polling
  11. Dreamkast v2 のリリースフロー要件 Dreamkast v1 (on Heroku) の開発体験を損なわないために、以下は必須要件
 • ステージング環境

    (stg) と本番環境 (prd) があり、
 本番環境は必ずステージング環境から promote される必要がある
 • app-repo に PR を出す毎に検証用環境 (dev) が立ち上がる (Review Apps)
 11 dev
 stg
 prd
 merge
 promote

  12. Dreamkast のリリースフローの実現 • 「dev = PullRequest」「stg = main ブランチ」「prd =

    Latest tag」
 • GitHub Actions を利用して infra-repo を操作
 • タグ打ちオペレーションを ChatOps で実施
 12
  13. Dreamkast のリリースフローの実現 • 「PullRequest = dev」「main ブランチ = stg」「Latest tag

    = prd」
 • GitHub Actions を利用して infra-repo を操作
 • タグ打ちオペレーションを ChatOps で実施
 13
  14. Dreamkast のリリースフローの実現 14 manifest/app ├── argocd-apps │ ├── development │

    │ └── (dev-cluster 用 ArgoCD Application manifest) │ └── production │ └── (prod-cluster 用 ArgoCD Application manifest) └── dreamkast ├── base │ └── (base manifests) └── overlays ├── development │ ├── dk-${PR_NUM} │ │ ├── kustomization.yaml │ │ └── other manifests │ └── … ├── staging │ └── main │ ├── kustomization.yaml │ └── other manifests └── production └── main dreamkast-infra 
 一部抜粋
 dev/prod cluster で Argo CD Application 
 マニフェストを配置するディレクトリを分け、 
 そこから dreamkast 用マニフェストを watch 

  15. Dreamkast のリリースフローの実現 15 manifest/app ├── argocd-apps │ ├── development │

    │ └── (dev-cluster 用 ArgoCD Application manifest) │ └── production │ └── (prod-cluster 用 ArgoCD Application manifest) └── dreamkast ├── base │ └── (base manifests) └── overlays ├── development │ ├── dk-${PR_NUM} │ │ ├── kustomization.yaml │ │ └── other manifests │ └── … ├── staging │ └── main │ ├── kustomization.yaml │ └── other manifests └── production └── main dreamkast-infra 
 一部抜粋
 staging/production
 更新時
 GitHub Actions にてマニフェストの imageTag を更新
 app-repo の main HEAD が更新されると 
 (production の場合は Latest tag) 
 左記の imageTag も更新される 
 

  16. Dreamkast のリリースフローの実現 16 manifest/app ├── argocd-apps │ ├── development │

    │ └── (dev-cluster 用 ArgoCD Application manifest) │ └── production │ └── (prod-cluster 用 ArgoCD Application manifest) └── dreamkast ├── base │ └── (base manifests) └── overlays ├── development │ ├── dk-${PR_NUM} │ │ ├── kustomization.yaml │ │ └── other manifests │ └── … ├── staging │ └── main │ ├── kustomization.yaml │ └── other manifests └── production └── main dreamkast-infra 
 一部抜粋
 Argo CD Application 用 
 マニフェストも push
 manifest/app/argocd-apps/development 以下を dev-cluster の Argo CD が watch 
 することで Review Apps を実現 
 development
 更新時
 ディレクトリごとテンプレートから新規作 成

  17. Dreamkast のリリースフローの実現 17 New!
 Other Manifests Argo CD Application

  18. Dreamkast のリリースフローの実現 • 「PullRequest = dev」「main ブランチ = stg」「Latest tag

    = prd」
 • GitHub Actions を利用して infra-repo を操作
 • タグ打ちオペレーションを ChatOps で実施
 18
  19. Dreamkast のリリースフローの実現 • 「PullRequest = dev」「main ブランチ = stg」「Latest tag

    = prd」
 • GitHub Actions を利用して infra-repo を操作
 • タグ打ちオペレーションを ChatOps で実施
 ◦ actions-ecosystem の各種アクションを利用
 ▪ PR の label (patch/minor/major) を元に semver なタグの自動インクリメント 
 ◦ dreamkast-releasebot の実装
 ▪ main に対して更新差分が empty commits のみである PR を 
 作成するだけの Slack Bot
 19
  20. いい感じに dreamkast の CI/CD が整備できた! 20

  21. CloudNative Days Spring 2021 Online (Mar 11-12, 2021) ~ Now

    21
  22. 新メンバー加入! → リリースフロー周りを説明...
 ☞ 説明してても結構複雑...
 
 
 22 ある日の会話①

  23. 「たまに動かない時があるんですが」
  「それは原因が分かってるんですが解決が面倒なので運用でカバーしてます」
 
 
 23 ある日の会話②

  24. ある日の会話③ 「app の新コンポーネント実装しました!」
 「infra-repo のマニフェストを更新したいんですけど、何やれば Review Apps で反映され ます??」
  「これとこれのマニフェストは今更新が必要で、マージ後にはこっちのファイルを更新す

    る必要があって...」
 24
  25. リリースフローの課題感 • app と infra の境界線が曖昧
 ◦ infra のドメイン知識を加味した gitops-xxx.yaml

    を app リポジトリに配置する必要がある 
 ◦ infra 管理者が manifest-repo だけを見て「どの app-repo からマニフェストの更新が来る か」といった全容を把握できない 
 • (特に Review Apps の仕組みが) まれによくバグる
 ◦ 例. PR を Open してすぐ Close したとき、GC action が gitops-dev action 
 より早く manifest-repo を更新しようとすると不整合が発生 
 • Review Apps として展開されるマニフェストのテンプレートを更新したいときの操作 が煩雑
 ◦ gitops-dev action により自動生成されるマニフェストを手動更新する必要性 
 ◦ テンプレートの更新タイミングが難しい 
 25
  26. リリースフローの課題感 • app と infra の境界線が曖昧
 ◦ infra のドメイン知識を加味した gitops-xxx.yaml

    を app リポジトリに配置する必要がある 
 ◦ infra 管理者が manifest-repo だけを見て「どの app-repo からマニフェストの更新が来る か」といった全容を把握できない 
 • (特に Review Apps の仕組みが) まれによくバグる
 ◦ 例. PR を Open してすぐ Close したとき、GC action が gitops-dev action 
 より早く manifest-repo を更新しようとすると不整合が発生 
 • Review Apps として展開されるマニフェストのテンプレートを更新したいときの操作 が煩雑
 ◦ gitops-dev action により自動生成されるマニフェストを手動更新する必要性 
 ◦ テンプレートの更新タイミングが難しい 
 26 
 GitOps をしてるはずなのに CIOps になってる...?

  27. GitOps? CIOps? CIOps
 • CI 内で CD もやってしまう構成 
 •

    世の中の CI ツールはだいたい push 型 
 pros
 • CI に全てのフローが集中するので、 単純
 cons
 • ビルドとデプロイが不可分 
 ◦ app-repo 管理者がデプロイ先の知識を
 持つ必要がある
 GitOps
 • Git をベースに CI と CD を分離した構成 
 • SSoT を実現するために基本的に pull 型 
 pros
 • SSoT の実現
 • 責任分界点の明確化 
 ◦ CI: app team / CD: infra team
 cons
 • CI/CD が分離するのでその分複雑 
 27 push hook deploy push pull CI & CD config CI config CD config ref
  28. Dreamkast のリリースフロー 「app-repo で GitHub Actions を用いた CI と infra-repo

    で Argo CD を
 用いた CD とで分離してるし infra-repo は SSoT にもなってるから GitOps だね」
 28 infra-repo
 管理者

  29. ちょっとまって? 「gitops GitHub Action に複雑なロジックがあり、
 しかもそれがバグると app-repo 管理者が調査する必要があり辛い」
 ◦ 「infra-repo

    をデプロイ先とみなした場合の CIOps 」とも言える
 29 app-repo
 管理者

  30. リリースフローの課題感 • app と infra の境界線が曖昧
 ◦ infra のドメイン知識を加味した gitops-xxx.yaml

    を app リポジトリに配置する必要がある 
 ◦ infra 管理者が manifest-repo だけを見て「どの app-repo からマニフェストの更新が来る か」といった全容を把握できない 
 • (特に Review Apps の仕組みが) まれによくバグる
 ◦ 例. PR を Open してすぐ Close したとき、GC action が gitops-dev action 
 より早く manifest-repo を更新しようとすると不整合が発生 
 • Review Apps として展開されるマニフェストのテンプレートを更新したいときの操作 が煩雑
 ◦ gitops-dev action により自動生成されるマニフェストを手動更新する必要性 
 ◦ テンプレートの更新タイミングが難しい 
 30 バグった際に app-repo を触る開発者が これを調査しなければならず辛い
 (CIOps の欠点)

  31. リリースフローの課題感 • app と infra の境界線が曖昧
 ◦ infra のドメイン知識を加味した gitops-xxx.yaml

    を app リポジトリに配置する必要がある 
 ◦ infra 管理者が manifest-repo だけを見て「どの app-repo からマニフェストの更新が来る か」といった全容を把握できない 
 • (特に Review Apps の仕組みが) まれによくバグる
 ◦ 例. PR を Open してすぐ Close したとき、GC action が gitops-dev action 
 より早く manifest-repo を更新しようとすると不整合が発生 
 • Review Apps として展開されるマニフェストのテンプレートを更新したいときの操作 が煩雑
 ◦ gitops-dev action により自動生成されるマニフェストを手動更新する必要性 
 ◦ テンプレートの更新タイミングが難しい 
 31 イベントをトリガーに infra-repo の更新処 理が手続き的に実行される
 ⇒ 宣言的に管理したい

  32. リリースフローの課題感 • app と infra の境界線が曖昧
 ◦ infra のドメイン知識を加味した gitops-xxx.yaml

    を app リポジトリに配置する必要がある 
 ◦ infra 管理者が manifest-repo だけを見て「どの app-repo からマニフェストの更新が来る か」といった全容を把握できない 
 • (特に Review Apps の仕組みが) まれによくバグる
 ◦ 例. PR を Open してすぐ Close したとき、GC action が gitops-dev action 
 より早く manifest-repo を更新しようとすると不整合が発生 
 • Review Apps として展開されるマニフェストのテンプレートを更新したいときの操作 が煩雑
 ◦ gitops-dev action により自動生成されるマニフェストを手動更新する必要性 
 ◦ テンプレートの更新タイミングが難しい 
 32 自前実装 gitops Action に
 このあたりの機能が足りてない
 ⇒ 要実装

  33. やりたいこと • Review Apps の知識を app-repo に置きたくなくて • 宣言的に Review

    Apps 環境の管理をしたくて • 運用に困ったら機能拡張していきたい
 33
  34. 既存の OSS にないか? Argo CD Image Updater
 • Argo CD

    Application オブジェクトを読んで以下を実施
 ◦ コンテナレジストリのイメージタグをポーリング監視 
 ◦ 更新を検知すると infra-repo のマニフェストを自動更新 
 • infra-repo のマニフェストをクラスタに適用するのは Argo CD が実施
 ➢ app-repo に infra-repo の知識を一切置く必要がない
 34 参考: 類似ソフトウェア
 • Flux - Automate image updates to Git
 • PipeCD - Event watcher

  35. 既存の OSS にないか? Argo CD Image Updater
 • Argo CD

    Application オブジェクトを読んで以下を実施
 ◦ コンテナレジストリのイメージタグをポーリング監視 
 ◦ 更新を検知すると infra-repo のマニフェストを自動更新 
 • infra-repo のマニフェストをクラスタに適用するのは Argo CD が実施
 ➢ app-repo に infra-repo の知識を一切置く必要がない
 35 参考: 類似ソフトウェア
 • Flux - Automate image updates to Git
 • PipeCD - Event watcher
 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: example namespace: argocd annotations: argocd-image-updater.argoproj.io/image-list: > example01=docker.io/kanatakita/example01, example02=docker.io/kanatakita/example02 argocd-image-updater.argoproj.io/example01.update-strategy: latest argocd-image-updater.argoproj.io/example01.allow-tags: regexp:^main-.*$ argocd-image-updater.argoproj.io/example02.update-strategy: latest argocd-image-updater.argoproj.io/example02.allow-tags: regexp:^main-.*$ argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/git-creds argocd-image-updater.argoproj.io/git-branch: main spec: ...
  36. 既存の OSS にないか? Argo CD Image Updater
 • Argo CD

    Application オブジェクトを読んで以下を実施
 ◦ コンテナレジストリのイメージタグをポーリング監視 
 ◦ 更新を検知すると infra-repo のマニフェストを自動更新 
 • infra-repo のマニフェストをクラスタに適用するのは Argo CD が実施
 ➢ app-repo に infra-repo の知識を一切置く必要がない
 36 参考: 類似ソフトウェア
 • Flux - Automate image updates to Git
 • PipeCD - Event watcher
 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: example namespace: argocd annotations: argocd-image-updater.argoproj.io/image-list: > example01=docker.io/kanatakita/example01, example02=docker.io/kanatakita/example02 argocd-image-updater.argoproj.io/example01.update-strategy: latest argocd-image-updater.argoproj.io/example01.allow-tags: regexp:^main-.*$ argocd-image-updater.argoproj.io/example02.update-strategy: latest argocd-image-updater.argoproj.io/example02.allow-tags: regexp:^main-.*$ argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/git-creds argocd-image-updater.argoproj.io/git-branch: main spec: ... コンテナレジストリを監視対象に設定 
 infra-repo へ
 アクセスするための設 定
 この条件を満たすタグが push さ れた際、 infra-repo 内のマニフェ スト内のタグを更新する

  37. 既存の OSS にないか? Argo CD Image Updater
 • Argo CD

    Application オブジェクトを読んで以下を実施
 ◦ コンテナレジストリのイメージタグをポーリング監視 
 ◦ 更新を検知すると infra-repo のマニフェストを自動更新 
 • infra-repo のマニフェストをクラスタに適用するのは Argo CD が実施
 ➢ app-repo に infra-repo の知識を一切置く必要がない
 37 参考: 類似ソフトウェア
 • Flux - Automate image updates to Git
 • PipeCD - Event watcher
 apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: example namespace: argocd annotations: argocd-image-updater.argoproj.io/image-list: > example01=docker.io/kanatakita/example01, example02=docker.io/kanatakita/example02 argocd-image-updater.argoproj.io/example01.update-strategy: latest argocd-image-updater.argoproj.io/example01.allow-tags: regexp:^main-.*$ argocd-image-updater.argoproj.io/example02.update-strategy: latest argocd-image-updater.argoproj.io/example02.allow-tags: regexp:^main-.*$ argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/git-creds argocd-image-updater.argoproj.io/git-branch: main spec: ... ➢ Review Apps を実現することが不可能 この条件を満たすタグが push さ れた際、 infra-repo 内のマニフェ スト内のタグを更新する
 infra-repo へ
 アクセスするための設 定
 コンテナレジストリを監視対象に設定 

  38. やりたいこと (再掲) • Review Apps の知識を app-repo に置きたくなくて • 宣言的に

    Review Apps 環境の管理をしたくて • 運用に困ったら機能拡張していきたい
 38
  39. 💡 39

  40. Kubernetes Operator pattern !!! 40 ⇒ https://kubernetes.io/docs/concepts/extend-kubernetes/operator/

  41. リリースフローにおける課題の解決 従来の gitops GitHub Actions の代わりに以下を実装・導入
 • stg, prd: Argo

    CD Imager Updater の導入 (※未実施)
 • dev: reviewapp-operator の新規実装と導入
 41
  42. reviewapp-operator • Argo CD と協調し Review Apps 環境を構築
 42

  43. reviewapp-operator • Argo CD と協調し Review Apps 環境を構築
 43 app-repo

    の open な PR を List し、新規 作成 / closed された PR を検知 

  44. reviewapp-operator • Argo CD と協調し Review Apps 環境を構築
 44 infra-repo

    に対し、検知した PR に 
 対応するマニフェストの作成 / 削除 
 Argo CD がマニフェストの
 更新を検知し K8s cluster に適用
 (※reviewapp-operator 責務外)

  45. reviewapp-operator • Argo CD と協調し Review Apps 環境を構築
 45 app-repo

    の該当 PR にコメント 
 Argo CD Application 
 オブジェクトの更新を検知 

  46. reviewapp-operator • Argo CD と協調し Review Apps 環境を構築
 46 app-repo

    の該当 PR 
 Argo CD Application Object の 
 更新を検知

  47. reviewapp-operator: Custom Resources (v0.0.3) 4つの Custom Resources
 • ReviewApp
 ◦

    app-repo の PR 1 つに対し ReviewApp オブジェクト 1 つが対応 
 ◦ ReviewAppManager リソースの子リソースとして作成される 
 ◦ 外部に及ぼす処理は ReviewApp Reconciler が担当 
 • ReviewAppManager
 ◦ app-repo, infra-repo へのアクセス用設定や、infra-repo の path の指定等を行う 
 ◦ ReviewAppManager Reconciler から PR 毎に ReviewApp リソースが作成される 
 • ManifestsTemplate
 ◦ Review Apps 環境を構築するためのマニフェストを定義 
 • ApplicationTemplate
 ◦ 上記マニフェストをデプロイするための Argo CD Application マニフェストを定義 
 ※ 利用者が適用するリソースは下3つ
 47
  48. reviewapp-operator: Custom Resources (v0.0.3) 48

  49. reviewapp-operator: Custom Resources (v0.0.3) 49 ReviewAppManager リソースから、 
 app-repo の

    PR 毎に ReviewApp リソースが 
 子リソースとして生成される 

  50. reviewapp-operator: Custom Resources (v0.0.3) 50 app-repo の PR を検知し、 


    ApplicationTemplate, ManifestsTemplate リソースを 
 参照して infra-repo にマニフェストを push 

  51. reviewapp-operator のその他の機能 51 • ApplicationTemplate / ManifestsTemplate のバージョン管理
 ◦ app-repo

    の PR に特定のラベルを付与すると template リソースの spec.candidate 以下のマニフェ ストを参照
 labels: candidate-template watch
 👍 app 開発に合わせてマニフェストファイルを更新したい場合に対応
 reviewapp-o perator
 infra-repo
 ReviewApp
 Manifests
 Template
 Application
 Template
 push manifests

  52. reviewapp-operator のその他の機能 52 • ApplicationTemplate / ManifestsTemplate のバージョン管理
 ◦ app-repo

    の PR に特定のラベルを付与すると template リソースの spec.candidate 以下のマニフェ ストを参照
 labels: candidate-template watch
 👍 app 開発に合わせてマニフェストファイルを更新したい場合に対応
 reviewapp-o perator
 infra-repo
 ReviewApp
 Application
 Template
 Manifests
 Template
 push manifests
 apiVersion: dreamkast.cloudnativedays.jp/v1alpha1 kind: ApplicationTemplate metadata: name: applicationtemplate-sample spec: stable: | apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: app-”{{.AppRepo.PrNumber}}” spec: ... candidate: | apiVersion: rgoproj.io/v1alpha1 kind: Application metadata: name: app-”{{.AppRepo.PrNumber}}” spec: ...
  53. reviewapp-operator のその他の機能 53 • ApplicationTemplate / ManifestsTemplate のバージョン管理
 ◦ app-repo

    の PR に特定のラベルを付与すると template リソースの spec.candidate 以下のマニフェ ストを参照
 labels: candidate-template watch
 👍 app 開発に合わせてマニフェストファイルを更新したい場合に対応
 reviewapp-o perator
 infra-repo
 ReviewApp
 Application
 Template
 Manifests
 Template
 push manifests
 apiVersion: dreamkast.cloudnativedays.jp/v1alpha1 kind: ApplicationTemplate metadata: name: applicationtemplate-sample spec: stable: &application | apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: app-{{.AppRepo.PrNumber}}" spec: ... candidate: *application 余談: 同じものを登録したい場合は yaml のアンカーを利用すれば良い 

  54. リリースフローの課題感 (再掲) • app と infra の境界線が曖昧
 ◦ infra のドメイン知識を加味した

    gitops-xxx.yaml を app リポジトリに配置する必要がある 
 ◦ infra 管理者が manifest-repo だけを見て「どの app-repo からマニフェストの更新が来る か」といった全容を把握できない 
 • (特に Review Apps の仕組みが) まれによくバグる
 ◦ 例. PR を Open してすぐ Close したとき、GC action が gitops-dev action 
 より早く manifest-repo を更新しようとすると不整合が発生 
 • Review Apps として展開されるマニフェストのテンプレートを更新したいときの操作 が煩雑
 ◦ gitops-dev action により自動生成されるマニフェストを手動更新する必要性 
 ◦ テンプレートの更新タイミングが難しい 
 54 reviewapp-operator 用マニフェストを用い、 
 全て infra-repo で設定を管理 
 operator pattern による宣言的な動作の実現 
 テンプレートを2世代定義可能なインタフェースとした 

  55. やりたいこと (再掲) • Review Apps の知識を app-repo に置きたくなくて • 宣言的に

    Review Apps 環境の管理をしたくて • 運用に困ったら機能拡張していきたい
 55 ✅
 ✅
 ✅

  56. 振り返り • ここ半年の dreamkast の CI/CD フローを話した
 ◦ GitHub Actions

    (test / build / update infra-repo in dev,stg,prd) + Argo CD 
 → GitHub Actions (test / build) + reviewapp-operator (Review Apps) + 
 Argo CD Image Updater (update infra-repo in stg,prd) + Argo CD 
 • reviewapp-operator で app-repo と infra-repo の責任分界点が明確化
 ◦ CI 側で実現していた Review Apps の仕組みを CD 側に寄せられた 
 ◦ ReviewApp 周りの作り込みがしたくなった際も Go + kubebuilder で開発可能 
 • 正直 reviewapp-operator の導入で CI/CD システム自体の複雑度は上がった
 ◦ どうなるかはこれから次第 (ドキュメンテーション / BugFix / operator 開発文化の醸成 / ...) 
 56
  57. Dreamkast チーム 今後のタスク • 実装
 ◦ dreamkast の機能拡充・front/backend 分離 


    ◦ dreamkast-ui で利用するストリーミングサービスの変更 (Vimeo → Amazon IVS) 
 ◦ dreamkast-archive (by AWS Amplify) 実装 
 • CI/CD 
 ◦ Argo CD Image Updater の導入 
 ◦ reviewapp-operator 機能拡張・BugFix 
 • ...
 
 57
  58. 他の取り組み • Observability チームの発足? (dreamkast チームからの分離?)
 ◦ プロファイラ・分散トレーサの導入 
 ▪

    メトリクスの充実
 ◦ イベント中の dreamkast のメトリクスを一般公開 
 ▪ Grafana Dashboard の Dreamkast 埋め込み or Dashboard の新規実装 
 ◦ SRE 的な取り組み
 ▪ Twitter の FB 等を元にしたイベント時の SLO の策定と SLI の取得 
 ▪ 上記 SLI/SLO を元にした開発タスクの優先度決め 
 ◦ ...
 58
  59. 他の取り組み • Observability チームの発足? (dreamkast チームからの分離?)
 ◦ 分散トレーシングの導入 
 ▪

    API を通した っfdreamkast のが進むことが予想されるため 
 ◦ イベント中の dreamkast のメトリクスを公開したい! 
 ▪ Grafana Dashboard の Dreamkast 埋め込み or Dashboard の新規実装 
 ◦ SRE 的な取り組み (just idea) 
 ▪ Twitter の FB 等を元にしたイベント時の SLO の策定と SLI の取得 
 ▪ 上記 SLI/SLO を元にした開発タスクの優先度決め 
 59 興味があれば
 お声掛けください!

  60. 参考: リポジトリのリンク • アプリケーションリポジトリ (app-repo)
 ◦ https://github.com/cloudnativedaysjp/dreamkast 
 ◦ https://github.com/cloudnativedaysjp/dreamkast-ui

    
 • マニフェストリポジトリ (infra-repo)
 ◦ https://github.com/cloudnativedaysjp/dreamkast-infra 
 • [旧方式] GitOps 用 GitHub Action
 ◦ https://github.com/cloudnativedaysjp/action-dreamkast-gitops 
 • ChatOps による app-repo タグインクリメントの実現
 ◦ https://github.com/cloudnativedaysjp/dreamkast-releasebot 
 ◦ https://github.com/actions-ecosystem 
 • reviewapp-operator
 ◦ https://github.com/cloudnativedaysjp/reviewapp-operator 
 • アーカイブサイト (AWS Amplify)
 ◦ https://github.com/cloudnativedaysjp/website 
 60