$30 off During Our Annual Pro Sale. View Details »

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

Ryo Sakamoto
November 24, 2022
1.5k

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

CNDT 2022登壇資料

Ryo Sakamoto

November 24, 2022
Tweet

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