20250613_Azure Kubernetes Serviceで構築するAdvanced CICD(ARC-RSS)

GitHub Actionsの課題とその解決策としてのActions Runner Controller (ARC)についての概説です。ARCのアーキテクチャやAzure Kubernetes Service (AKS)との統合の利点を解説し、運用や監視、コスト管理の方法についても詳述しています。さらに、ARCを用いたCI/CD基盤の構築手順やセキュリティ対策についても触れています。

1. Azure Kubernetes Serviceで構築する Advanced CI/CD (Actions Runner Controller Scale Set) 2025.06.13 Yutaka.Osada
2. Agenda • GitHub Actionsについて • GitHub Actionsの課題 • Actions Runner Controllerについて • ARCのアーキテクチャ（超概要） • Azure Kubernetes Serviceとは • AKSでARCを使うメリット • AzureコンポーネントでARCを構成する • 構成イメージ／ネットワーク／セキュリティ • ARC on AKSの運用 • 監視／管理／需要予測／コスト • まとめ DO WHAT MATTERS 2
3. Yutaka Osada （長田 豊） • DevOps Engineer @Avanade Japan • 業務 • Azureコンポーネントを活用したサー ビス構築 • 技術検証、パフォーマンスチューニン グを得意とし、T-SQLが好き。 • 技術スタック • C#, .NET, Azure(PaaS), Azure DevOps, GitHub • Please follow me DO WHAT MATTERS 3 https://github.com/yutaka-art
4. GitHub Actionsについて DO WHAT MATTERS 4 ワークフロー実行指示 • GitHub管理のホストが実行基盤 • 標準ランナーはスペック固定。Teamプラン 以上はlarger runnerを利用可能 • 従量課金形式 ワークフローを実行 GitHub管理サーバー郡 ワークフロー実行指示 ワークフローを実行 ユーザー管理ホスト • ユーザー所有のホストが実行基盤 • スペック、実行環境のカスタマイズはユー ザー管理 • ユーザー所有のホストによる課金 GitHub-hosted-runner Self-hosted-runner
5. GitHub Actionsの課題 DO WHAT MATTERS 5 • CI/CDパイプラインを実行するホストのスペックのカスタマイズ • 外部サービスとの接続問題 • GitHub Actionsの従量課金による料金の削減
6. ランナーの選定ポイント DO WHAT MATTERS 6 ランナー種別 方式 メリット デメリット 難易度 GitHub-hosted 通常 • メンテナンス不要 • 最新環境が常に提供される • 仮想ネットワーク(VNET)内リソー スにアクセス不可 • IP制御不可 ★ GitHub-hosted VNET統合 • GitHub管理 + VNetアクセスが可能 • パブリックネットワーク経由不要 • 利用可能リージョンが限定的 • 初期構成がやや複雑 ★★ Self-hosted オンプレミス • 閉域環境で運用可能 • 社内ポリシーをフル反映可能 • GHECとの接続構成が複雑 • メンテナンスが必要 ★★★ Self-hosted 仮想マシン • Azureおよび、他のパブリッククラウドで構 築可能 • NSGやPrivate Endpointなどと連携可能 • 環境管理の負荷がある • GitHub-hostedより導入が複雑 ★★ Self-hosted Kubernetes / ARC • Ephemeralなスケーラブル環境が構築可能 • IaCによる管理が可能 • 初期セットアップにKubernetes知 識が必要 • 管理が複雑になりがち ★★★ 凡例：赤枠が今回話す 部分
7. Actions Runner Controllerについて DO WHAT MATTERS 7 ARCはSelf-hosted-runnerの調整、スケーリングをおこなうKubernetes Operator ワークフローの数に応じた Self-hosted-runnerを自動 スケーリング・割り当て 一時コンテナによるクリー ンな実行環境によるワーク フロー実施 Helmチャートベースの構 築、管理
8. ARCのアーキテクチャ（超概要） DO WHAT MATTERS 8 ARCにはController-manager、Listener、Runner Scale Setの3つの役割がある 引用元：https://www.google.com/url?q=https%3A%2F%2Fdocs.github.com%2Fja%2Factions%2Fhosting-your-own-runners%2Fmanaging-self-hosted-runners- with-actions-runner-controller%2Fabout-actions-runner-controller
9. Azure Kubernetes Serviceとは DO WHAT MATTERS 10 Azure上でコンテナアプリケーションを実行するマネージドなKubernetesサービス Kubernetesの複雑な 運用・管理の負担を 削減 クラウドの利点を活 かした高可用性、価 格レベルに応じた SLAの保証 需要に応じた自動ス ケーリングやイベン トドリブンの自動ス ケーリング(KEDA)を サポート ノードプールのVMサ イズ、クラスター数 に応じた従量課金
10. AKSでARCを使うメリット DO WHAT MATTERS 11 • すぐに安全に始められる • Entra ID や Key Vault などがそのまま使えるので、 余分な設定なしで ARC を立ち上げ可能。 • 運用の手間とコストを減らせる • コントロールプレーンは Azure が管理。ノードは負 荷に合わせて自動で増減し、使わないときの料金を 抑えられる。 • 企業向けの統制が楽 • Azure Policy と Defender が標準で使え、監査やコ ンプライアンス要件を追加ツールなしで満たせる。 GitHub（Microsoft）＋ Entra ID の同一ベンダー連携で設定が最短 ⇒ Portal で数クリック、 CLI/ARM/Bicep もテンプレ済み コントロールプレーン無料 (Free tier) ― EKS/GKE は $0.10 / h 課金 - Azure Policy に “AKS 用定義” が最初か らカタログ化（GUI で適用） - Defender for Containers が Microsoft 365 Defender と統合し、 GitHub Advanced Security のアラート と一元管理
11. AzureコンポーネントでARCを構成する – 構成イメージ DO WHAT MATTERS 12 System A Actions Runner Controller Management Resource System B Peering Peering GitHub
12. AzureコンポーネントでARCを構成する – ネットワーク DO WHAT MATTERS 13 • ARCは各システム(コンポーネント)と通信できる環境を作る • IPレンジが重複しないように仮想ネットワークのピアリングで相互接 続する • 仮想ネットワーク間のトラフィックが多くなるとピアリングの料金も 高くなるので注意 • Dev/Stg/ProdのRunnerはネットワークを分離させる • 内部の不正な操作、実行防止にもなる • 環境デプロイミスの事故を防ぐ • 環境を分ける分だけ費用が掛かるので、規模に応じて分離する
13. AzureコンポーネントでARCを構成する – セキュリティ DO WHAT MATTERS 14 • プライベートクラスターによる外部公開されないK8s環境を作成可能 • GitHub→ARC→システム、とシステムに直接接続しないためセキュリ ティ向上に繋がる • AKSからGitHubへの通信はNAT Gatewayのような外部通信手段を準 備 • パブリックからプライベート、プライベートからパブリックのような 変更はできない • 仮想ネットワークのピアリングをする場合、必要なところのみNSGで許可 • 大雑把に通信許可すると意図しない通信をする可能性も • 早期フェーズ（Azure環境払い出し時など）にセキュリティを意識。 DevSecOpsを実践すること
14. AzureコンポーネントでARCを構成する – セキュリティ DO WHAT MATTERS 15 • Microsoft Entra統合やAzure RBACによるアクセス制御が可能 • 必要に応じてKubernetes RBACによる詳細な制御も利用する Microsoft Entra Id 管理者 運用担当者 開発者 ARC（Prod環境） ARC（Stg/Dev環境） アクセス、操作可能 アクセス、必要に応じて操作可能 アクセス、操作可能 アクセス不可 権限付与
15. ARC on AKSの運用 – 監視 DO WHAT MATTERS 16 • Azure MonitorとContainer Insightsの連携によるログ、パフォーマンスの取得 • ノードからPodのリソース使用率や正常性と基本的な項目を確認できる • モニタリングする項目を一つひとつ設定する工数も削減できる • Application Insightsとの連携によるログ、メトリクス、分散トレースの取得 • Open Telemetryの有効化によりARCのパフォーマンス周りをまとめられる • 収集したログはLog Analyticsワークスペースへ • ログの分析や他のAzureサービスへの利用ができる • ワークフローの実行が多いとARCのメトリクスが肥大化するので注意する
16. ARC on AKSの運用 – 監視 DO WHAT MATTERS 17 AKSはManaged Prometheus、Managed Grafanaの関連付けにより可視化できる ※ただしManaged Grafanaはユーザ数に応じた月額課金があるため増やしすぎは注意
17. ARC on AKSの運用 – AKSの管理 DO WHAT MATTERS 18 • Runnerイメージをカスタマイズする場合はOS、各種ツールのアップデートを管理 • GitHub-hostedと異なり管理側で対応が必要なため、定期的に • Azure Container Registryのタスク、GitHub Actionsで自動化すると管理工数削 減に • AKSはKubernetesバージョンの自動アップグレード機能がある • 開発者の利用していないときに実施することで工数削減も
18. ARC on AKSの運用 – AKSの需要予測 DO WHAT MATTERS 19 • 大企業だとランナーの実行頻度が多くなるため、定期的に需要を見直す • VMサイズを絞りすぎるとランナー起動までの待ち時間が長くなるので注意 • リスナーがランナーを割り当てるまでの時間を定期的にモニタリングする • エフェメラルランナーを事前に作成する場合、ワークフロー実行中のランナー数 もモニタリングする • Nodeプールのサイズ変更はプールの新規作成が必要 • 予算に余裕があればランナー数を数台増やせるスペックを確保すること • 急な切り替えは開発者のワークフロー実行に影響があるので注意
19. ARC on AKSの運用 – AKSのコスト DO WHAT MATTERS 20 • 利用者の需要に合わせてノードのオートスケーリングを利用 • ユーザノードプールをゼロスケーリングすることも論理的に可能 • GitHub Actionsのスケジュールを使った夜間、休日ジョブがある場合もあるので、 必要な分は残す • 利用しない時間帯がある場合はクラスタ停止も視野に • 需要に応じたノードプールサイズ（VMサイズ）、周辺リソースを見直す • 不必要に大きなサイズを使っている場合はサイズの縮小を検討 • ログ、メトリクスの容量が増えるとちりつもでコストが嵩む • AKSはノードのサイズに応じた予約、Savings Plan、スポットインスタンスが利用 可能 • リソースが安定してきたときに割引プランでコスト削減を検討 • 検証用、優先度の低いジョブ実行用にスポットノードを利用する
20. まとめ DO WHAT MATTERS 21 • ARCはSelf-hosted-runnerのスケーリングに係る課題を解決するKubernetesの Operator • マネージドなAKSと関連するAzureコンポーネントと組み合わせることで、Azure 上でのCI/CD基盤の構築・運用における様々な負担を削減できる • AKS上のARCを運用するにはKubernetesだけでなくCI/CD基盤のモニタリングや 需要予測、運用サポートが必要
21. Appendix DO WHAT MATTERS 22
22. 構築前提とSSH公開鍵の作成 DO WHAT MATTERS 23 ツール URL 備考 Helm 3 https://helm.sh/ja/docs/intro/ins tall/ winget install Helm.Helm Azure CLI https://learn.microsoft.com/ja- jp/cli/azure/install-azure-cli- windows?pivots=msi ssh-keygen -t rsa -b 4096 -C "yutaka.osada@avanade.com" ・~/.ssh/id_rsa（秘密鍵）→ 絶対に流出させない ・~/.ssh/id_rsa.pub（公開鍵）
23. Kubernetes Clusterの構築（Azure Kubernetes Service) （1/3） DO WHAT MATTERS 24 sshPublicKeyへは、[1]で作成した、id_rsa.pubをテキス トで開き内容をコピーしたうえで値を設定すること # azure sign-in az login --tenant <your-tenant-id> # create a resource group az group create --name rg-arc-test --location japaneast # create a AKS cluster az deployment group create --resource-group rg- arc-test --template-file main.bicep -- parameters aksName=aks-arc
24. Kubernetes Clusterの構築（Azure Kubernetes Service) （2/3） DO WHAT MATTERS 25 Mask
25. Kubernetes Clusterの構築（Azure Kubernetes Service) （3/3） DO WHAT MATTERS 26 mask
26. AKSクラスターへ接続 DO WHAT MATTERS 27 az aks get-credentials --resource-group rg-arc-test --name aks-arc kubectl get nodes
27. Actions Runner Controller のインストール DO WHAT MATTERS 28 # install arc helm install arc --namespace "arc-systems" --create-namespace oci://ghcr.io/actions/actions-runner-controller-charts/gha-runner-scale-set-controller helm repo update
28. GitHub Appsの作成とシークレット登録（1/5） DO WHAT MATTERS 29 GitHub Appsを作成する、クライアントシークレットではなく、秘密鍵を利用する https://github.com/settings/apps
29. GitHub Appsの作成とシークレット登録（2/5） DO WHAT MATTERS 30 GitHub App のページで GitHub App を作成した後、"アプリ ID" の値を書き留める。 この値は後で使用 する Repository：Administration: Read and write、メタデータ: 読み取り専用 Organization：セルフホステッド ランナー: 読み取りと書き込み ホームページURL：https://github.com/actions/actions-runner-controller
30. GitHub Appsの作成とシークレット登録（3/5） DO WHAT MATTERS 31 [秘密キー] で、 [秘密キーの生成] をクリックし、.pem ファイルを保存する。 このキーは後で使用する
31. GitHub Appsの作成とシークレット登録（4/5） DO WHAT MATTERS 32 アプリのインストール 上部のURL末尾の数値が インストレーションID
32. GitHub Appsの作成とシークレット登録（5/5） DO WHAT MATTERS 33 github_app_idには、作成したアプリID github_app_installation_idには、当該アプリのインストレーションID github_app_private_keyには、ローカルへ保存した秘密鍵 kubectl create namespace arc-runners kubectl create secret generic github-app-secret --namespace arc-runners --from- literal=github_app_id=999999 --from-literal=github_app_installation_id=99999 --from- file=github_app_private_key=xx.private-key.pem kubectl describe secrets/github-app-secret -n "arc-runners"
33. Runner Scale Set（RSS）のインストール（1/2） DO WHAT MATTERS 34 helm install "arc-runner-set" --namespace "arc-runners" --create-namespace --set githubConfigUrl="https://github.com/yourrepos/actions" --set githubConfigSecret=github-app-secret oci://ghcr.io/actions/actions-runner-controller- charts/gha-runner-scale-set
34. Runner Scale Set（RSS）のインストール（2/2） DO WHAT MATTERS 35 GitHub上のRunner scale setsへ登録される
35. リソース確認 DO WHAT MATTERS 36 helm list -A kubectl -n arc-systems get po kubectl -n arc-systems get autoscalinglisteners.actions.github.com kubectl -n arc-runners get autoscalingrunnersets.actions.github.com kubectl -n arc-runners get ephemeralrunnersets.actions.github.com
36. 動作確認（1/2） DO WHAT MATTERS 37 name: Test workflow on: workflow_dispatch: jobs: test1: runs-on: arc-runner-set-01 steps: - name: Hello world run: echo "Hello" test2: runs-on: arc-runner-set-01 steps: - name: Hello world run: echo "World"
37. 動作確認（2/2） DO WHAT MATTERS 38 kubectl -n arc-runners get ephemeralrunnersets.actions.github.com -w kubectl -n arc-runners get ephemeralrunners.actions.github.com -w
38. まとめ ― 今日持ち帰ってほしい３つのポイント DO WHAT MATTERS 39 • 「まず動く」を体験すれば、ARC＋RSSは怖くない • AKS 作成 → kubectl で接続 → Helm で ARC/RSS インストール → GitHub App とシークレット登録 ―― という最小ステップで “セルフホステッド Runner as-a-Service” が完成します。 • Runner Scale Sets が HRA を置き換え、スケーリングがシンプルに • 従来必要だった Horizontal Runner Autoscaler (HRA) を意識せず、ARC 自身 が Pod 数をジョブ需要に合わせて自動調整。 • “運用に乗せる” ための次ステップ • 可観測性を追加 → metricsServer + Prometheus/Grafana で Runner 利用 率とジョブ滞留を監視。 • セキュアなネットワーク設計 → Private Link・限定 egress・OIDC Workload Identity でゼロトラスト強化。
39. THANK YOU DO WHAT MATTERS Yutaka.Osada union.dml@gmail.com https://github.com/yutaka-art 40