ArgoCDとGitHub Self Hosted Runnerを使って リリース時間を1/4にした話

CNDT 2022登壇資料

Transcript

1. 　　　　　　 © Chatwork ArgoCDとGitHub Self Hosted Runnerを使って リリース時間を1/4にした話 2022年11月21日　SRE部　坂本 諒 Chatwork株式会社
2. {自己・会社}紹介 デプロイフローの改善 テスト環境のデプロイフローの改善 まとめなど 1 2 3 4 AGENDA アジェンダ
3. {自己・会社}紹介 デプロイフローの改善 テスト環境のデプロイフローの改善 まとめなど 1 2 3 4 AGENDA アジェンダ
4. 自己紹介 4 • 坂本 諒 • SRE部所属 ◦ Kubernetesの管理やCIフローの整備など • 趣味 ランニング ◦ 月200kmぐらい ◦ 昨日(11/20)ハーフマラソン走ってきました ▪ 90分6秒 ◦ 来月(12月)湘南国際マラソン参加予定
5. 会社概要 5 会社名 Chatwork株式会社 代表取締役CEO 山本 正喜 従業員数 304名（2022年9月末日時点） 所在地 東京、大阪、ベトナム、台湾 設立 2004年11月11日
6. Chatworkとは 6 効率的に情報共有できる グループチャット 仕事の見える化ができる タスク管理 見落としがなくなる ファイル管理 いつでも会議ができる ビデオ/音声通話 * BOXIL SaaS AWARD 2022「ランキング部門 コラボレーション部門賞」「ベスト評価賞 （初期設定の容易さNo.1、価格の満足度No.1）」を受賞　BOXIL「Chatwork」口コミ評価 * Nielsen NetView 及びNielsen Mobile NetView Customized Report 2022年5月度調べ月次利用者（MAU:Monthly Active User）調査。 * 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む47サービスをChatwork株式会社にて選定。
7. Chatworkは利用者数No.1*のビジネスチャット 7 3月 リリース 10万社 突破！ 20万社 突破！ 導入社数 37万6000社以上！ (2022年9月末日時点) 30万社 突破！ * Nielsen NetView 及びNielsen Mobile NetView Customized Report 2022年5月度調べ月次利用者（MAU:Monthly Active User）調査。 * 調査対象はChatwork、Microsoft Teams、Slack、LINE WORKS、Skypeを含む47サービスをChatwork株式会社にて選定。
8. {自己・会社}紹介 デプロイフローの改善 テスト環境のデプロイフローの改善 まとめなど 1 2 3 4 AGENDA アジェンダ
9. ChatworkのKubernetes利用 2.1
10. ChatworkのアプリケーションのKubernetes利用 10 • Kubernetesの本番利用は2016年末から ◦ まずは新規アプリケーションでの採用 ◦ Kubernetesは現在ではEKSを利用 • 2020年にメイン(モノリス)のアプリケーションをKubernetesに移行 ◦ PHPのレジェンドシステムをEC2からKubernetesに移行する話 そ の5 〜PHPアプリケーションをコンテナ化しよう〜 - Chatwork Creator's Note ◦ 詳細はブログに記載 • 2021年にほとんどのアプリケーションをKubernetesに移行
11. Chatworkの構成（ざっくり） 11
12. Chatworkの構成（ざっくり） 12
13. Chatworkの構成（ざっくり） 13 Node数: 45 〜 160 (90% spot instance) Pod数: 600 〜 2,500
14. EKSクラスタの運用の話 14 • 夏のAWS Kubernetes 祭り！〜Kubernetesの運用最前線を紹介〜 ◦ https://aws.amazon.com/jp/blogs/news/20220804-container s-event/ ▪ クラスタをBlue/Greenで無停止で切り替えている話など
15. 各種ツール 2.2
16. Chatworkがリリースで使用しているツール 16 • Helm ◦ Kubernetesパッケージマネージャ ◦ 汎用性の高い記述にしてchartsも公開 ▪ https://github.com/chatwork/charts • Helmfile ◦ https://github.com/helmfile/helmfile ◦ prod/stgなど環境差異を吸収する • CircleCI/Github Actions • Jenkins/ArgoCD
17. HelmとHelmfile 17 • Helmfile ◦ Helmをさらに宣言的/環境別に管理するためのOSS ▪ helmコマンドをyamlファイルで管理できる → GitOpsとの相性が良い ▪ 環境という概念があり、環境ごとの値が定義可能 Helmfileの場合 Helmの場合 helmコマンドをyaml化して GitOps! helm installコマンド のポチポチが必要
18. Helmfileの機能 • デプロイに便利な機能 ◦ 環境定義 ◦ 複数チャートの依存関係を管理 ◦ AWS ParameterStore連携 helmfile --environment prod apply prod values.yaml / ├── helmfile.yaml └── environments/ ├── values.yaml ├── prod.yaml └── test.yaml Helmfile prod.yaml helmfile --environment test apply values.yaml testyaml test
19. helmfileの例(helmfile.yamlの1/2) environments: prod: values: - ./environments/values.yaml - ./environments/prod.yaml test: values: - ./environments/values.yaml - ./environments/test.yaml kubeVersion: {{ .Values.kubernetes.version }}
20. helmfileの例(helmfile.yamlの1/2) environments: prod: values: - ./environments/values.yaml - ./environments/prod.yaml test: values: - ./environments/values.yaml - ./environments/test.yaml kubeVersion: {{ .Values.kubernetes.version }} 環境ごとの値の設定
21. helmfileの例(helmfile.yamlの1/2) environments: prod: values: - ./environments/values.yaml - ./environments/prod.yaml test: values: - ./environments/values.yaml - ./environments/test.yaml kubeVersion: {{ .Values.kubernetes.version }} helmに渡すパラメータ
22. helmfileの例(helmfile.yamlの2/2) releases: - name: "datadog-agent" namespace: "kube-system" chart: "datadog/datadog" version: "{{ .Values.datadog.version }}" values: - ./values/settings.yaml.gotmpl helmでリリースする内容
23. helmfileの例(helmfile.yamlの2/2) releases: - name: "datadog-agent" namespace: "kube-system" chart: "datadog/datadog" version: "{{ .Values.datadog.version }}" values: - ./values/settings.yaml.gotmpl helmでリリースする内容 helmに渡すvaluesの go template
24. helmfileの例(settings.yaml.gotmpl) datadog: apiKey: ref+awsssm://kubernetes/datadog/apiKey?region=XXX logLevel: {{ .Values.datadog.logLevel }} collectEvents: true clusterChecksRunner: enabled: true replicas: {{ .Values.datadog.clusterChecksRunner.replicas }} resources: {{- toYaml .Values.datadog.clusterChecksRunner.resources | nindent 4}}
25. helmfileの例(settings.yaml.gotmpl) datadog: apiKey: ref+awsssm://kubernetes/datadog/apiKey?region=XXX logLevel: {{ .Values.datadog.logLevel }} collectEvents: true clusterChecksRunner: enabled: true replicas: {{ .Values.datadog.clusterChecksRunner.replicas }} resources: {{- toYaml .Values.datadog.clusterChecksRunner.resources | nindent 4}} parameter storeのパス
26. helmfileの例(settings.yaml.gotmpl) datadog: apiKey: ref+awsssm://kubernetes/datadog/apiKey?region=XXX logLevel: {{ .Values.datadog.logLevel }} collectEvents: true clusterChecksRunner: enabled: true replicas: {{ .Values.datadog.clusterChecksRunner.replicas }} resources: {{- toYaml .Values.datadog.clusterChecksRunner.resources | nindent 4}} 環境固有の値が入る
27. manifestの生成 helmfile --environment prod template helmfile.yaml prod.yaml values.yaml.gotmpl manifestの生成なのでtemplate
28. ArgoCD移行前のリリース 2.3
29. Chatworkのアプリケーションデプロイ(ArgoCD移行前) 29 • いくつかのアプリケーションに関してはArgoCDでのデプロイ導入済み • ChatworkのアプリケーションはEKS移行後もJenkinsを使い続けていた ◦ EKS移行の開発者側の心理的な負担を増やさないため ◦ モノリス構成で1つのレポジトリに複数のアプリケーションがあ り、各アプリケーションでデプロイツールが異なると負担が大きい と判断 ◦ 2021年にほぼすべてのアプリケーションをEKSに移行し、Jenkins を使い続ける理由がない
30. Chatworkのアプリケーションのデプロイ(ArgoCD移行前) 30 k8s Config Prod Stage Test Application Deploy Deploy Deploy Build RUN Pull Pull
31. Jenkinsつらい(Jenkinsそのものが悪いわけではない) 31 • すぐにリソース不足になったりして、並列でリリースできない • 1つのアプリケーションで最大で8分程度かかる場合があり、すべての アプリケーションに影響するような修正の場合、並列でリリースできな いために30分ぐらいかかることがあった
32. Jenkinsつらい(Jenkinsそのものが悪いわけではない) 32 Jenkins息してないです！
33. Jenkinsつらい(Jenkinsそのものが悪いわけではない) 33 起きろぉぉ
34. Jenkinsつらい(Jenkinsそのものが悪いわけではない) 34 • 導入が201X年でゴールデンイメージでの運用 • 何かをアップデートするとすぐに壊れる • ジョブの中身はスクリプトでちょっとした修正でバグが入りやすい ◦ Helmfile、Jenkinsの設定、デプロイスクリプトが密結合していて manifestの構成に手を入れにくい
35. Chatworkのアプリケーションデプロイ(ArgoCD移行前) 35
36. Chatworkのアプリケーションデプロイ(ArgoCD移行前) 36 黒い画面に文字が 流れるだけで辛い
37. Chatworkのアプリケーションデプロイ(ArgoCD移行前) 37 ときにはJenkinsを 励ましつつも ついに引導を渡すとき
38. ArgoCD移行 2.4
39. ArgoCDへの移行を決定 39 • ArgoCD自体は導入済みなので、ArgoCDに移行するのが自然 ◦ 新規のアプリケーション、SRE管理のアプリケーションはすでに ArgoCDでデプロイ • CI/CDまわりが複雑になっていたので整理 ◦ GitHub Actionsも導入する ▪ Self Hosted Runnerを使いたい
40. ArgoCDでhelmfileを使う 40 • helmfileを多用しているので、当然ArgoCDでもhelmfileを使いたい • ArgoCDにはpluginという仕組みがあって、自分で定義することが可能 ◦ helmfile -q --environment XXX template --include-crds --skip-tests ◦ ただしArgoCDのimageにコマンドが入っている必要 • 自分たちでimageを作成して公開 ◦ https://hub.docker.com/r/chatwork/argocd-helmfile
41. ArgoCDへの移行をするときに最初にしたこと 41 • 自分で実際にJenkinsを使ってリリースしてみる ◦ 普段はDevチームがデプロイしているが、リリース作業に飛び込ん で、自分でやってみる • CircleCIとJenkinsのスクリプトの読み込み
42. 移行での心がけなど 42 • 移行時に混乱しないように ◦ リリースできない！というのは絶対に避けなければいけない ◦ CI/CDフローの大幅な変更は行わない ▪ ざっくりいえばJenkinsのところがArgoCDになっただけ、とい う状態にする • (気持ち面では)Jenkinsのほうがよかった、と思われたら負け • Jenkinsでもリリース可能な状態に ◦ ArgoCDとの並行稼動
43. CI/CDの流れ 43 Application k8s Config Charts ECR Kubernetes Cluster CI Pipeline CD Pipeline A
44. CI/CDの流れ 44 Application k8s Config Charts ECR Kubernetes Cluster CI Pipeline CD Pipeline Push A
45. CI/CDの流れ 45 Application k8s Config Charts ECR Kubernetes Cluster CI Pipeline CD Pipeline Push Build A
46. CI/CDの流れ 46 Application k8s Config Charts ECR Kubernetes Cluster CI Pipeline CD Pipeline Push Build Update Push A
47. CI/CDの流れ 47 Application k8s Config Charts ECR Kubernetes Cluster CI Pipeline CD Pipeline Push Build Update Push Manifest Out Of Sync Manifest A
48. CI/CDの流れ 48 Application k8s Config Charts ECR Kubernetes Cluster Sync CI Pipeline CD Pipeline kubectl apply Manifest Push Update Push Build A
49. ArgoCDへの移行の結果 49 • リソース問題はなくなって、並列でリリースできるようになったので、 かなりの時間短縮 • どのmanifestが出る・出ているのかGUIで確認可能 ◦ 本番は手動sync • ジョブの結果が見やすい ◦ Jenkins自体はスクリプトのエラー内容だけだったので、どこで失 敗したのかわかりにくい • ツール間の密結合解消 • ツール自体の再現性
50. ArgoCDへの移行の結果 50
51. 移行中の話 51 • 試験環境では試したりしても、本番だけ微妙に条件が違ったりして、本番 のCI/CDフローでしか確認できないものがあり、ドキドキ • CircleCIで”なんでこの設定なのか？”の背景がわからず、右往左往 • ArgoCDの使い方講習会 ◦ 今回ArgoCDに移行したアプリケーションはかなり多くの人が関わるの で、毎週講習会&リリース実演会をやり、疑問点などを解消 ▪ 関わる人が多いのはまさにモノリスアプリケーションの大変なと ころ？ ▪ Jenkinsとの並行稼動期間でもArgoCDで一度リリースした人が Jenkinsでリリースすることはなかった
52. {自己・会社}紹介 デプロイフローの改善 テスト環境のデプロイフローの改善 まとめなど 1 2 3 4 AGENDA アジェンダ
53. ArgoCD移行後のテスト環境のリリースの問題 53 • EKS上のテスト環境はAWSのサービスを使いたいときなどに利用 ◦ 諸事情によりテスト環境は全体で1つしかない... ▪ アプリケーション毎ではあるけれど • できるだけ早くテストを回したい ◦ imageだけを差し替えて何度も試したい • 本番用のインテグレーションは、CIの待ちだったり、ArgoCDのsync待 ちだったり、高速に回しにくい • image tagの設定をArgoCDの環境変数設定機能で入れているが、何回 もやると面倒
54. ArgoCD移行後のテスト環境のリリースの問題 54
55. ArgoCD移行後のテスト環境のリリースの問題改善 55 • 環境変数を自分で設定していくのは面倒 • Github Actionsから直接imageの更新をすれば・・
56. CI/CDの流れ 56 Application k8s Config Charts ECR Kubernetes Cluster Sync CI Pipeline CD Pipeline kubectl apply Manifest Push Update Push Build A
57. CI/CDの流れ 57 Application k8s Config Charts ECR Kubernetes Cluster Sync CI Pipeline CD Pipeline kubectl apply Manifest Push Push Build A Update?
58. CIツールから直接Kubernetes(ArgoCD)に接続したくない 58 • Github ActionsなどはIPを固定できないので、api serverを外部公開す る必要がある • 公開しても大丈夫だと思うが、、閉じれるものは閉じたい • Github ActionsにはSelf Hosted Runnerというすばらしい仕組みが ◦ https://github.com/actions-runner-controller/actions-runner -controller ◦ これをアプリケーションと同じk8sクラスタで動かすことで解決
59. Actions Runner Controller 59 • Github Actionsにもともとself-hostd runnerという仕組みがある ◦ https://docs.github.com/ja/actions/hosting-your-own-runner s/about-self-hosted-runners • ただ、自分でrunnerを動かすとなると、それなりに大変 ◦ ジョブのキューでスケールさせたい ◦ webhookで即時に反映させたい(そもそもpollingしたり) • このrunnerをk8sで動かすためのコントローラー ◦ “Self-Hosted Runners & Actions Runner Controller (ARC)を運用するこ と”(Track D 2022/11/21 14:20-15:00) ▪ https://event.cloudnativedays.jp/cndt2022/talks/1553
60. テスト環境のリリースをどのタイミングでキックするのか 60 • Pushごとにリリースされても困る • リリースしたいタイミングは開発者自身が一番理解している ◦ 環境変数経由の差し替えでもその想定
61. テスト環境のリリースをどこからキックするのか 61 • PRのコメントでリリースできると、コミット -> プッシュ -> リリース という流れになって楽 ◦ テストする内容のPRはあるはず
62. CI/CDの流れ 62 Application k8s Config Charts ECR Kubernetes Cluster Sync CI Pipeline CD Pipeline kubectl apply Manifest A
63. CI/CDの流れ 63 Application k8s Config Charts ECR Kubernetes Cluster Sync CI Pipeline CD Pipeline kubectl apply Manifest A R
64. CI/CDの流れ 64 Application k8s Config Charts ECR Kubernetes Cluster Sync CI Pipeline CD Pipeline kubectl apply Manifest Push A R
65. CI/CDの流れ 65 Application k8s Config Charts ECR Kubernetes Cluster Sync CI Pipeline CD Pipeline kubectl apply Manifest Push A R PR comment
66. CI/CDの流れ 66 Application k8s Config Charts ECR Kubernetes Cluster Sync CI Pipeline CD Pipeline kubectl apply Manifest Push Push A R PR comment Build
67. CI/CDの流れ 67 Application k8s Config Charts ECR Kubernetes Cluster Sync CI Pipeline CD Pipeline kubectl apply Manifest Push Push Build run_on Patch A R PR comment
68. ArgoCD移行後のテスト環境のリリース改善 68 • 本番よりある程度手順をスキップすることでより早く回せるように • self hosted runnerを利用することでクラスタ内からジョブ実行 • PRだけで完結するようにPRコメントでデプロイできるように ◦ image作成からクラスタへのデプロイまで一気通貫で可能に
69. ArgoCD移行後のテスト環境のリリース 69 • k8s configでGit管理している状態から上書きしてしまうので、GitOps ではなくなってしまうのが今の悩みどころ
70. テスト環境のリリース改善は続く 70 • 諸事情により今はテスト環境が1つしかない.... ◦ 基本的にはイメージの差し替えのみを行う状態 • ArgoCD Pull Request Generatorを使ってPR毎のアプリケーションを 出せるようにしたい ◦ https://argo-cd.readthedocs.io/en/stable/operator-manual/a pplicationset/Generators-Pull-Request/
71. {自己・会社}紹介 デプロイフローの改善 テスト環境のデプロイフローの改善 まとめなど 1 2 3 4 AGENDA アジェンダ
72. Dev側の感想 72
73. Dev側の感想 73 • 手間が減った • 画面が見やすい ◦ Jenkinsだと、基本的は待つしかなったが、ArgoCDだとPodの入れ 替えがGUIから確認できるので、進んでいるかどうかがわかる • リリースが安定するようになった • 時間が短縮されてデプロイ回数が増えた
74. まとめ 74 • 長年かわいがっていたJenkinsからArgoCDに移行 ◦ 最長で30分かかっていたのが(CI含めて)8分程度に短縮 ◦ 安定性の向上 • Dev側のリリースの心理的な負担が軽減 ◦ リリース速度・品質の向上 • Github Actions self-hosted-runnerを導入して、安全にクラスタ内で CIを実行できるように ◦ テスト環境のリリース速度をさらに向上
75. We are Hiring !!! 75 https://hrmos.co/pages/chatwork/jobs/1020019
76. Chatworkその他のセッション 76 • Kubernetesとterraformのセキュリティ/ガバナンス向上委員会 with OPA ◦ Track D 2022/11/21 13:20-14:00 ◦ Keisuke Furuya • SLO策定までの道とChaosEngineeringを使った最適解の見つけ方 ◦ Track A 2022/11/22 13:20-14:00 ◦ Shinya Sasaki
77. 働くをもっと楽しく、創造的に