CNDT 2022、ArgoCDとGitHub Actionsの導入でリリース時間を1/4に削減した事例を紹介
![](https://thinkit.co.jp/sites/default/files/styles/main_image_730x/public/main_images/21518_main.jpg?itok=YrWCFHw7)
CNDT 2022から、Chatwork株式会社のSREである坂本諒氏によるEKS上のCI/CD環境においてリリース時間を削減した事例に関するセッションを紹介する。
●動画:ArgoCDとGitHub Actions Self Hosted Runnerを使ってリリース時間を1/4にした話
まずChatworkのKubernetesの利用について概要を説明。2016年末から新規のアプリケーションに限定してKubernetes上の実装が始まり、2020年にはモノリシックなアプリケーションについてもAWSが提供するマネージドKubernetesサービスのEKS上への移行が終わったと語った。2021年にはほとんどのアプリケーションがEKS上に移行されている。規模感は利用しているノード数が約160、Pod数が600から2500くらいというところだ。odの約90%はAWSのSpot Instanceを使ってコスト削減を図っていると説明した。今回の話はこのうち200くらいPodに関連する内容であるという。
ここからChatworkがリリースに使うパッケージマネージャーのHelmとHelmfileについて簡単な説明を行い、具体的にHelmfileで記述する例なども示しながら環境ごとに定義ファイルを生成する仕組みなどについて説明を行った。CIについてはCircleCI、CDについては以前から利用していたという理由でJenkinsを使っていたと解説した。
ただいくつかのアプリケーションについてはすでにArgo CDを使っていたと説明したが、EKSに移行した後もJenkinsについては開発チームの新しいツールに慣れるという負担を減らすという意味で継続して利用していたという。
2021年にはほぼすべてのアプリケーションがEKSに移行しており、この時点でJenkinsを使い続ける理由はなくなったと説明した。
しかしながらJenkinsについてはアップデートを行うと壊れるという事例が発生したこと、スクリプトの修正でバグが発生しがちだったことなどからいわゆる「秘伝のタレ」問題を起こしていたことがうかがえる。
すでにArgo CDを導入していたことなどから、JenkinsからArgo CDへの移行について移行時の混乱を避けること、開発チームに「Jenkinsのほうが良かった」と思わせないこと、JenkinsでもArgo CDでも並列して実行できるようにすることなどを注意点として移行作業が行われたと説明した。
当初のCI/CDの概要を説明したスライドでは、アプリケーションのリポジトリ、Kubernetes構成のリポジトリ、Helmチャートのためのリポジトリなどを用いてGitOpsを目指して構成されていることがわかる。
このフロー自体はごく常識的な構成だが、JenkinsからArgo CDに移行した効果は大きかったようで、メリットとして並列実行できるようになったことでリリース時間が削減されたこと、GUIでCI/CDの結果が確認できることなどを挙げた。それまではJenkinsのターミナルのログを見るしかなく、SREにとっても開発チームにとっても負荷が高かったという。
実際の移行については、講習会やリリースを実演する実演会などを開催して社内啓蒙を行ったと説明。結果的にJenkinsに戻ったアプリケーションはなかったということで、SREチームが思ったように進行したという。
ここからテスト環境においてCDを実行するSelf Hosted Runnerに関する説明に移った。
SaaSで提供されるGitHub ActionsからEKS上のKubernetesに直接アクセスさせたくなかったことが理由であると説明し、任意の場所でGitHub Actionsのジョブを実行可能にするSelf Hosted Runnerを発見したことが大きな転機となったと説明。
またSelf Hosted RunnerをKubernetes上で実行するための仕組みであるActions Runner Controllerについても簡単に解説を行った。
最終的なCI/CDのフローは次のスライドで説明されているが、Kubernetesクラスター上で実行されるSelf Hosted RunnerがArgo CDを起動してCDパイプラインが実行されることなどを解説した。
リリースの改善点として、テスト環境においては手順を省くことでより高速化が行われたこと、ソースコード修正のプルリクエストとコメントの併用によりデプロイまで一気にできるようになったことなどを挙げた。
ここまでで開発チームにとってみれば、大きな改善が行われたとして100%満足していること、具体的には、手間が減った、画面がJenkinsの場合よりも見やすい、リリースが安定した、時間が短縮されデプロイ回数が増えたことなどを挙げて説明した。
最後にまとめとして、最大30分かかっていたリリース作業が8分程度まで短縮したこと、高い安定性、品質の向上、テスト環境のリリース改善などを挙げた。しかしながらGitHub ActionsがKubernetesクラスターにパッチを当てることで環境を変更する方法では、GitOpsとしての設計からは外れてしまうこと、Kubernetesの構成ファイルのリポジトリへの同期はマニュアルで行われていることなどを挙げて改善の余地はまだあると説明し、これからもSREとしての仕事が続くことをコメントしてセッションを終えた。
なおGitHub ActionsのSelf Hosted Runnerについては以下の公式ドキュメントを参考にされたい。
●参考:セルフホステッド ランナーの概要
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- CI/CD ConferenceからサイバーエージェントのCI/CDツール開発のセッションを紹介
- HelmfileでKubernetesマニフェストやKustomization、Helm Chartなどで構成されるアプリケーションを効率的に管理する
- Oracle Cloud Hangout Cafe Season4 #3「CI/CD 最新事情」(2021年6月9日開催)
- CNDT 2022、ChatworkのSREがコンテナセキュリティのための新しいツールを紹介
- CNDT 2022、DMMのアーキテクトが解説するSREと開発の責任境界とリソース管理の実際
- CI/CDから障害の復旧までハイレベルの運用自動化を実現するKeptnとは
- OpenShift Commons Gatheringで語られたOpenShiftに最適なCI/CDとは
- KubeCon+CloudNativeCon NA 2020 IntuitとMayaDataによるカオスエンジニアリングのセッション
- DevOpsのサイクルをコードで管理し、プロセスを自動化する「CI/CDパイプライン」
- 「Cloud Native Trail Map」の10ステップを紐解く(ステップ1~3)