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

CNDT 2022登壇資料

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

9. ChatworkのKubernetes利用
   2.1
   

   View Slide

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

    View Slide

11. Chatworkの構成（ざっくり）
    11
    

    View Slide

12. Chatworkの構成（ざっくり）
    12
    

    View Slide

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

    View Slide

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

    View Slide

15. 各種ツール
    2.2
    

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

28. ArgoCD移行前のリリース
    2.3
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

38. ArgoCD移行
    2.4
    

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

50. ArgoCDへの移行の結果
    50
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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クラスタで動かすことで解決
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

72. Dev側の感想
    72
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide