Slide 1

Slide 1 text

       © Chatwork ArgoCDとGitHub Self Hosted Runnerを使って リリース時間を1/4にした話 2022年11月21日 SRE部 坂本 諒 Chatwork株式会社

Slide 2

Slide 2 text

{自己・会社}紹介 デプロイフローの改善 テスト環境のデプロイフローの改善 まとめなど 1 2 3 4 AGENDA アジェンダ

Slide 3

Slide 3 text

{自己・会社}紹介 デプロイフローの改善 テスト環境のデプロイフローの改善 まとめなど 1 2 3 4 AGENDA アジェンダ

Slide 4

Slide 4 text

自己紹介 4 ● 坂本 諒 ● SRE部所属 ○ Kubernetesの管理やCIフローの整備など ● 趣味 ランニング ○ 月200kmぐらい ○ 昨日(11/20)ハーフマラソン走ってきました ■ 90分6秒 ○ 来月(12月)湘南国際マラソン参加予定

Slide 5

Slide 5 text

会社概要 5 会社名 Chatwork株式会社 代表取締役CEO 山本 正喜 従業員数 304名(2022年9月末日時点) 所在地 東京、大阪、ベトナム、台湾 設立 2004年11月11日

Slide 6

Slide 6 text

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株式会社にて選定。

Slide 7

Slide 7 text

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株式会社にて選定。

Slide 8

Slide 8 text

{自己・会社}紹介 デプロイフローの改善 テスト環境のデプロイフローの改善 まとめなど 1 2 3 4 AGENDA アジェンダ

Slide 9

Slide 9 text

ChatworkのKubernetes利用 2.1

Slide 10

Slide 10 text

ChatworkのアプリケーションのKubernetes利用 10 ● Kubernetesの本番利用は2016年末から ○ まずは新規アプリケーションでの採用 ○ Kubernetesは現在ではEKSを利用 ● 2020年にメイン(モノリス)のアプリケーションをKubernetesに移行 ○ PHPのレジェンドシステムをEC2からKubernetesに移行する話 そ の5 〜PHPアプリケーションをコンテナ化しよう〜 - Chatwork Creator's Note ○ 詳細はブログに記載 ● 2021年にほとんどのアプリケーションをKubernetesに移行

Slide 11

Slide 11 text

Chatworkの構成(ざっくり) 11

Slide 12

Slide 12 text

Chatworkの構成(ざっくり) 12

Slide 13

Slide 13 text

Chatworkの構成(ざっくり) 13 Node数: 45 〜 160 (90% spot instance) Pod数: 600 〜 2,500

Slide 14

Slide 14 text

EKSクラスタの運用の話 14 ● 夏のAWS Kubernetes 祭り!〜Kubernetesの運用最前線を紹介〜 ○ https://aws.amazon.com/jp/blogs/news/20220804-container s-event/ ■ クラスタをBlue/Greenで無停止で切り替えている話など

Slide 15

Slide 15 text

各種ツール 2.2

Slide 16

Slide 16 text

Chatworkがリリースで使用しているツール 16 ● Helm ○ Kubernetesパッケージマネージャ ○ 汎用性の高い記述にしてchartsも公開 ■ https://github.com/chatwork/charts ● Helmfile ○ https://github.com/helmfile/helmfile ○ prod/stgなど環境差異を吸収する ● CircleCI/Github Actions ● Jenkins/ArgoCD

Slide 17

Slide 17 text

HelmとHelmfile 17 ● Helmfile ○ Helmをさらに宣言的/環境別に管理するためのOSS ■ helmコマンドをyamlファイルで管理できる → GitOpsとの相性が良い ■ 環境という概念があり、環境ごとの値が定義可能 Helmfileの場合 Helmの場合 helmコマンドをyaml化して GitOps! helm installコマンド のポチポチが必要

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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 }}

Slide 20

Slide 20 text

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 }} 環境ごとの値の設定

Slide 21

Slide 21 text

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に渡すパラメータ

Slide 22

Slide 22 text

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でリリースする内容

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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}}

Slide 25

Slide 25 text

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のパス

Slide 26

Slide 26 text

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}} 環境固有の値が入る

Slide 27

Slide 27 text

manifestの生成 helmfile --environment prod template helmfile.yaml prod.yaml values.yaml.gotmpl manifestの生成なのでtemplate

Slide 28

Slide 28 text

ArgoCD移行前のリリース 2.3

Slide 29

Slide 29 text

Chatworkのアプリケーションデプロイ(ArgoCD移行前) 29 ● いくつかのアプリケーションに関してはArgoCDでのデプロイ導入済み ● ChatworkのアプリケーションはEKS移行後もJenkinsを使い続けていた ○ EKS移行の開発者側の心理的な負担を増やさないため ○ モノリス構成で1つのレポジトリに複数のアプリケーションがあ り、各アプリケーションでデプロイツールが異なると負担が大きい と判断 ○ 2021年にほぼすべてのアプリケーションをEKSに移行し、Jenkins を使い続ける理由がない

Slide 30

Slide 30 text

Chatworkのアプリケーションのデプロイ(ArgoCD移行前) 30 k8s Config Prod Stage Test Application Deploy Deploy Deploy Build RUN Pull Pull

Slide 31

Slide 31 text

Jenkinsつらい(Jenkinsそのものが悪いわけではない) 31 ● すぐにリソース不足になったりして、並列でリリースできない ● 1つのアプリケーションで最大で8分程度かかる場合があり、すべての アプリケーションに影響するような修正の場合、並列でリリースできな いために30分ぐらいかかることがあった

Slide 32

Slide 32 text

Jenkinsつらい(Jenkinsそのものが悪いわけではない) 32 Jenkins息してないです!

Slide 33

Slide 33 text

Jenkinsつらい(Jenkinsそのものが悪いわけではない) 33 起きろぉぉ

Slide 34

Slide 34 text

Jenkinsつらい(Jenkinsそのものが悪いわけではない) 34 ● 導入が201X年でゴールデンイメージでの運用 ● 何かをアップデートするとすぐに壊れる ● ジョブの中身はスクリプトでちょっとした修正でバグが入りやすい ○ Helmfile、Jenkinsの設定、デプロイスクリプトが密結合していて manifestの構成に手を入れにくい

Slide 35

Slide 35 text

Chatworkのアプリケーションデプロイ(ArgoCD移行前) 35

Slide 36

Slide 36 text

Chatworkのアプリケーションデプロイ(ArgoCD移行前) 36 黒い画面に文字が 流れるだけで辛い

Slide 37

Slide 37 text

Chatworkのアプリケーションデプロイ(ArgoCD移行前) 37 ときにはJenkinsを 励ましつつも ついに引導を渡すとき

Slide 38

Slide 38 text

ArgoCD移行 2.4

Slide 39

Slide 39 text

ArgoCDへの移行を決定 39 ● ArgoCD自体は導入済みなので、ArgoCDに移行するのが自然 ○ 新規のアプリケーション、SRE管理のアプリケーションはすでに ArgoCDでデプロイ ● CI/CDまわりが複雑になっていたので整理 ○ GitHub Actionsも導入する ■ Self Hosted Runnerを使いたい

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

ArgoCDへの移行をするときに最初にしたこと 41 ● 自分で実際にJenkinsを使ってリリースしてみる ○ 普段はDevチームがデプロイしているが、リリース作業に飛び込ん で、自分でやってみる ● CircleCIとJenkinsのスクリプトの読み込み

Slide 42

Slide 42 text

移行での心がけなど 42 ● 移行時に混乱しないように ○ リリースできない!というのは絶対に避けなければいけない ○ CI/CDフローの大幅な変更は行わない ■ ざっくりいえばJenkinsのところがArgoCDになっただけ、とい う状態にする ● (気持ち面では)Jenkinsのほうがよかった、と思われたら負け ● Jenkinsでもリリース可能な状態に ○ ArgoCDとの並行稼動

Slide 43

Slide 43 text

CI/CDの流れ 43 Application k8s Config Charts ECR Kubernetes Cluster CI Pipeline CD Pipeline A

Slide 44

Slide 44 text

CI/CDの流れ 44 Application k8s Config Charts ECR Kubernetes Cluster CI Pipeline CD Pipeline Push A

Slide 45

Slide 45 text

CI/CDの流れ 45 Application k8s Config Charts ECR Kubernetes Cluster CI Pipeline CD Pipeline Push Build A

Slide 46

Slide 46 text

CI/CDの流れ 46 Application k8s Config Charts ECR Kubernetes Cluster CI Pipeline CD Pipeline Push Build Update Push A

Slide 47

Slide 47 text

CI/CDの流れ 47 Application k8s Config Charts ECR Kubernetes Cluster CI Pipeline CD Pipeline Push Build Update Push Manifest Out Of Sync Manifest A

Slide 48

Slide 48 text

CI/CDの流れ 48 Application k8s Config Charts ECR Kubernetes Cluster Sync CI Pipeline CD Pipeline kubectl apply Manifest Push Update Push Build A

Slide 49

Slide 49 text

ArgoCDへの移行の結果 49 ● リソース問題はなくなって、並列でリリースできるようになったので、 かなりの時間短縮 ● どのmanifestが出る・出ているのかGUIで確認可能 ○ 本番は手動sync ● ジョブの結果が見やすい ○ Jenkins自体はスクリプトのエラー内容だけだったので、どこで失 敗したのかわかりにくい ● ツール間の密結合解消 ● ツール自体の再現性

Slide 50

Slide 50 text

ArgoCDへの移行の結果 50

Slide 51

Slide 51 text

移行中の話 51 ● 試験環境では試したりしても、本番だけ微妙に条件が違ったりして、本番 のCI/CDフローでしか確認できないものがあり、ドキドキ ● CircleCIで”なんでこの設定なのか?”の背景がわからず、右往左往 ● ArgoCDの使い方講習会 ○ 今回ArgoCDに移行したアプリケーションはかなり多くの人が関わるの で、毎週講習会&リリース実演会をやり、疑問点などを解消 ■ 関わる人が多いのはまさにモノリスアプリケーションの大変なと ころ? ■ Jenkinsとの並行稼動期間でもArgoCDで一度リリースした人が Jenkinsでリリースすることはなかった

Slide 52

Slide 52 text

{自己・会社}紹介 デプロイフローの改善 テスト環境のデプロイフローの改善 まとめなど 1 2 3 4 AGENDA アジェンダ

Slide 53

Slide 53 text

ArgoCD移行後のテスト環境のリリースの問題 53 ● EKS上のテスト環境はAWSのサービスを使いたいときなどに利用 ○ 諸事情によりテスト環境は全体で1つしかない... ■ アプリケーション毎ではあるけれど ● できるだけ早くテストを回したい ○ imageだけを差し替えて何度も試したい ● 本番用のインテグレーションは、CIの待ちだったり、ArgoCDのsync待 ちだったり、高速に回しにくい ● image tagの設定をArgoCDの環境変数設定機能で入れているが、何回 もやると面倒

Slide 54

Slide 54 text

ArgoCD移行後のテスト環境のリリースの問題 54

Slide 55

Slide 55 text

ArgoCD移行後のテスト環境のリリースの問題改善 55 ● 環境変数を自分で設定していくのは面倒 ● Github Actionsから直接imageの更新をすれば・・

Slide 56

Slide 56 text

CI/CDの流れ 56 Application k8s Config Charts ECR Kubernetes Cluster Sync CI Pipeline CD Pipeline kubectl apply Manifest Push Update Push Build A

Slide 57

Slide 57 text

CI/CDの流れ 57 Application k8s Config Charts ECR Kubernetes Cluster Sync CI Pipeline CD Pipeline kubectl apply Manifest Push Push Build A Update?

Slide 58

Slide 58 text

CIツールから直接Kubernetes(ArgoCD)に接続したくない 58 ● Github ActionsなどはIPを固定できないので、api serverを外部公開す る必要がある ● 公開しても大丈夫だと思うが、、閉じれるものは閉じたい ● Github ActionsにはSelf Hosted Runnerというすばらしい仕組みが ○ https://github.com/actions-runner-controller/actions-runner -controller ○ これをアプリケーションと同じk8sクラスタで動かすことで解決

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

テスト環境のリリースをどのタイミングでキックするのか 60 ● Pushごとにリリースされても困る ● リリースしたいタイミングは開発者自身が一番理解している ○ 環境変数経由の差し替えでもその想定

Slide 61

Slide 61 text

テスト環境のリリースをどこからキックするのか 61 ● PRのコメントでリリースできると、コミット -> プッシュ -> リリース という流れになって楽 ○ テストする内容のPRはあるはず

Slide 62

Slide 62 text

CI/CDの流れ 62 Application k8s Config Charts ECR Kubernetes Cluster Sync CI Pipeline CD Pipeline kubectl apply Manifest A

Slide 63

Slide 63 text

CI/CDの流れ 63 Application k8s Config Charts ECR Kubernetes Cluster Sync CI Pipeline CD Pipeline kubectl apply Manifest A R

Slide 64

Slide 64 text

CI/CDの流れ 64 Application k8s Config Charts ECR Kubernetes Cluster Sync CI Pipeline CD Pipeline kubectl apply Manifest Push A R

Slide 65

Slide 65 text

CI/CDの流れ 65 Application k8s Config Charts ECR Kubernetes Cluster Sync CI Pipeline CD Pipeline kubectl apply Manifest Push A R PR comment

Slide 66

Slide 66 text

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

Slide 67

Slide 67 text

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

Slide 68

Slide 68 text

ArgoCD移行後のテスト環境のリリース改善 68 ● 本番よりある程度手順をスキップすることでより早く回せるように ● self hosted runnerを利用することでクラスタ内からジョブ実行 ● PRだけで完結するようにPRコメントでデプロイできるように ○ image作成からクラスタへのデプロイまで一気通貫で可能に

Slide 69

Slide 69 text

ArgoCD移行後のテスト環境のリリース 69 ● k8s configでGit管理している状態から上書きしてしまうので、GitOps ではなくなってしまうのが今の悩みどころ

Slide 70

Slide 70 text

テスト環境のリリース改善は続く 70 ● 諸事情により今はテスト環境が1つしかない.... ○ 基本的にはイメージの差し替えのみを行う状態 ● ArgoCD Pull Request Generatorを使ってPR毎のアプリケーションを 出せるようにしたい ○ https://argo-cd.readthedocs.io/en/stable/operator-manual/a pplicationset/Generators-Pull-Request/

Slide 71

Slide 71 text

{自己・会社}紹介 デプロイフローの改善 テスト環境のデプロイフローの改善 まとめなど 1 2 3 4 AGENDA アジェンダ

Slide 72

Slide 72 text

Dev側の感想 72

Slide 73

Slide 73 text

Dev側の感想 73 ● 手間が減った ● 画面が見やすい ○ Jenkinsだと、基本的は待つしかなったが、ArgoCDだとPodの入れ 替えがGUIから確認できるので、進んでいるかどうかがわかる ● リリースが安定するようになった ● 時間が短縮されてデプロイ回数が増えた

Slide 74

Slide 74 text

まとめ 74 ● 長年かわいがっていたJenkinsからArgoCDに移行 ○ 最長で30分かかっていたのが(CI含めて)8分程度に短縮 ○ 安定性の向上 ● Dev側のリリースの心理的な負担が軽減 ○ リリース速度・品質の向上 ● Github Actions self-hosted-runnerを導入して、安全にクラスタ内で CIを実行できるように ○ テスト環境のリリース速度をさらに向上

Slide 75

Slide 75 text

We are Hiring !!! 75 https://hrmos.co/pages/chatwork/jobs/1020019

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

働くをもっと楽しく、創造的に