モンスターストライク と Jenkins 2022/11/2 モンスト事業本部 モンストサーバチーム 松原 信忠

モンストサーバチーム 2

サーバーチームはモンストのバックエンドの「開発」と「運用」の両方を行う 開発環境や開発を支援するツールも開発・運用している（Jenkinsもその一つ） モンストの開発に関わるチーム 3

リポジトリに応じてジョブが何種類かある（以下に一部抜粋） 1. モンストのバックエンド本体のリポジトリ テストの実行（Ruby） ソースコードのデプロイ（開発環境のみ） マスターデータのインポート 2. 本体以外の周辺ツールをまとめたモノレポジトリ テストの実行（主にGo） Goの依存パッケージのVendoring 独自 apt パッケージのビルドとリリース 3. Google Cloud DNS や AWS Security Group などを IaC しているリポジトリ 設定の適用 サーバチームでの Jenkins 用途 4

リポジトリに応じてジョブが何種類かある（以下に一部抜粋） 1. モンストのバックエンド本体のリポジトリ テストの実行（Ruby） ソースコードのデプロイ（開発環境のみ） マスターデータのインポート 2. 本体以外の周辺ツールをまとめたモノレポジトリ テストの実行（主にGo） Goの依存パッケージのVendoring 独自 apt パッケージのビルドとリリース 3. Google Cloud DNS や AWS Security Group などを IaC しているリポジトリ 設定の適用 サーバチームでの Jenkins 用途 5

リポジトリに応じてジョブが何種類かある（以下に一部抜粋） 1. モンストのバックエンド本体のリポジトリ テストの実行（Ruby） ソースコードのデプロイ（開発環境のみ） マスターデータのインポート 2. 本体以外の周辺ツールをまとめたモノレポジトリ テストの実行（主にGo） Goの依存パッケージのVendoring 独自 apt パッケージのビルドとリリース 3. Google Cloud DNS や AWS Security Group などを IaC しているリポジトリ 設定の適用 サーバチームでの Jenkins 用途 6

リポジトリに応じてジョブが何種類かある（以下に一部抜粋） 1. モンストのバックエンド本体のリポジトリ テストの実行（Ruby） ソースコードのデプロイ（開発環境のみ） マスターデータのインポート 2. 本体以外の周辺ツールをまとめたモノレポジトリ テストの実行（主にGo） Goの依存パッケージのVendoring 独自 apt パッケージのビルドとリリース 3. Google Cloud DNS や AWS Security Group などを IaC しているリポジトリ 設定の適用 サーバチームでの Jenkins 用途 7

サーバチームでの Jenkins 構成 8

Jenkins コントローラーは GKE 上で動かしている Jenkins 公式の Helm Chart を利用している サーバチームでの Jenkins 構成 https://github.com/jenkinsci/helm-charts 9

Jenkins へのアクセスは Webhook も含めて自作ゼロトラストプロキシを介す jwt-auth-plugin を使ってゼロトラストプロキシを介してきたかを確認 サーバチームでの Jenkins 構成 https://github.com/jenkinsci/jwt-auth-plugin 10

Jenkins エージェントは GCE で動かしている Packer でベースイメージを作り、Ansible でプロビジョニングする サーバチームでの Jenkins 構成 11

生じた課題と解決方法 12

モンストの機能開発では「QA期間」というのがある そのため、QA期間まで（締め日）に機能をある程度完成させる必要がある 締め日にコミットが集中して、テスト用のジョブが大量に発生して滞留する エージェントを一時的に足せば良いが、その都度行うのは大変 課題：ジョブが滞留する時期がある 13

Go製・GKE上で動作させている 当時、内定者アルバイトで来てた方にフルスクラッチしてもらった 解決：エージェントのオートスケーラーの開発 14

(1) 現在の Jenkins エージェントの状態を API から取得 エージェントのラベル毎にオートスケールのための設定を分けている 解決：エージェントのオートスケーラーの開発 15

(2) 閾値以上のエージェントがジョブを実行している場合はエージェントを追加 エージェントは GCE のインスタンステンプレートから生成 解決：エージェントのオートスケーラーの開発 16

(3) 追加したエージェントがジョブを実行していない場合はエージェントを削除 これらを数分おきに繰り返す 解決：エージェントのオートスケーラーの開発 17

Jenkins はサーバーチームのメンバー以外も使っている マスターデータのインポート（実行は Slack Bot から） マスターデータの静的解析（GitHub Webhook から） マスターデータの翻訳（海外版） しかし Web UIからできる設定を、サーバーメンバー以外にはやってほしくない 課題：Jenkins の細かいアクセス制御をしたい 18

モンスト開発では自作のゼロトラストプロキシを運用していたので、これを利用する Go製・GKE上で動作させている 会社の Google アカウントで認証・ユーザーの識別を行う ユーザー毎にロールを与えて、ロール毎にアクセスできる Webサービスを制限 解決：自作ゼロトラストプロキシによる制御 19

Webサービスのパスや Read Only かどうかの制御も可能 GitHub や Slack からのアクセスを許可するかどうかも制御可能 社員以外はクライアント証明書を渡してアクセス制限をかけることも可能 サーバーチームのロールでは「Read/Write」にし、それ以外では Read Only にした 解決：自作ゼロトラストプロキシによる制御 20

Jenkins では独自 apt パッケージのビルドとリリースをしており、これらのジョブは 別々になっている ビルド：PRがマージされた時点で差分に応じて自動実行 リリース：サーバーにプロビジョニングをかけてるときには避けたいので手動実行 しかし、欲を出すと ビルドの終わった時点で「リリースして良いか」を Slack に投稿して手動 実行を促してほしい （いわゆる「Manual Approval」みたいなことがしたい） 課題：ジョブの後に別のジョブを手動実行したい 21

Go製・GKE上で動作する自作 Slack Bot に機能を追加した Slack Bot は GitHub Webhook も受け取れるようになっている 解決：Slack Bot でジョブの終了を待つ 22

1. 独自 apt パッケージのPRがマージされるのを Slack Bot が検知 2. ビルドのジョブが終わるのを Jenkins の Web API を定期的に呼んで待つ 3. ビルドが終わったら Slack に通知し Add Reaction を待つ 4. Add Reaction されたらリリースのジョブを Jenkins の Web API から実行 解決：Slack Bot でジョブの終了を待つ 23

Jenkins でクラウドサービスの設定の適用しているため、秘匿情報の管理をしている Google Cloud のアクセスキー AWS のアクセスキー（用途やリージョン毎に分けている） しかし、Jenkins の秘匿情報管理で設定できるスコープが「グローバル」と「システ ム」しか基本的にはなく、リポジトリ毎に設定することができない また、大量の秘匿情報を何個も登録するのが大変 課題：秘匿情報をリポジトリ毎に管理したい 24

Amber という OSS を利用する リポジトリには Amber で生成した公開鍵と暗号化した秘匿情報を保存 Jenkins には Amber で生成した秘密鍵だけを保存 リポジトリと秘密鍵が揃う場合（ジョブ）でだけ、元の秘匿情報を利用できる 解決：Amber の導入 https://github.com/fpco/amber 25

モンストサーバーチームでは Jenkins を自前運用して利用している テストの実行やデータインポート、IaC の適用などで利用している コントローラーは GKE 上で動作させて、Helm を使って構成管理 エージェントは GCE 上で動作させて、Packer と Ansible を使って構成管理 生じた課題は主に、自作ツールやOSSを利用して Jenkins の外から解決している ジョブが時期によって滞留するので、エージェントのオートスケーラーを自作 細かいアクセス制御をするために自作ゼロトラストプロキシを利用 Slack から Manual Approval をするために Slack Bot を自作 リポジトリ毎に秘匿情報を管理するために Amber という OSS を導入 まとめ 26

No content