SDPF ベアメタルサーバー / ハイパーバイザー開発における GitHub Actions を活用した CI 事例の紹介

社内の技術イベントでの発表に用いたスライドです。

自分のチームで行っている GitHub Actions の self-hosted runners を活用した CI 事例についての紹介スライドです。

Transcript

1. SDPF ベアメタルサーバー / ハイパーバイザー開発における
 GitHub Actions を活用した CI 事例の紹介
 NTT コミュニケーションズ
 プラットフォームサービス本部 クラウド & ネットワークサービス部
 開発オペレーション部門
 山中 克志

2. 名前：山中克志（@yamy）（入社6年目）
 所属：NTT コム PS 本部 C&N 部 開発オペレーション部門 7G 5T
 業務：SDPF ベアメタルサーバー / ハイパーバイザー開発
 メインの開発の傍ら業務効率を上げる何かをするのが好き
 アジャイル / スクラムのあれこれ導入・便利ツールや改善の生成 など
 趣味でこんなの作ってました：
 自己紹介
 Android 向けリズムゲーム
 Google Play 公開中
 スマホブラウザ向け
 オンライン UNO
 研究室のホームページ
 2 分かりやすく見せれるものを
 作りたいタイプ

3. 話したいこと（目次）
 1. BM / DH 開発の CI について
 
 2. CI への GitHub Actions の導入
 a. 環境構成、実際に流している workflow 例 など
 3. 導入・活用してみた所感
 3 BM = BareMetal server = SDPF ベアメタルサーバー
 DH = Dedicated Hypervisor = SDPF ハイパーバイザー

4. 4 1. BM / DH 開発の CI について
 2. CI への GitHub Actions の導入
 3. 導入・活用してみた所感

5. SDPF ベアメタルサーバー / ハイパーバイザー
 5 https://sdpf.ntt.com/
6. SDPF ベアメタルサーバー / ハイパーバイザー
 
 6 https://sdpf.ntt.com/
7. サービス全体で数千台規模の物理サーバを現在提供中
 SDPF ベアメタルサーバー / ハイパーバイザー
 
 7 https://sdpf.ntt.com/services/server-instance/ https://sdpf.ntt.com/services/vsphere/
8. 主な開発内容
 • 物理サーバに対する OS インストールや電源操作等の自動化（API 開発）
 • 物理サーバの在庫管理や監視（故障検知）
 • サーバインスタンス / OS 等ライセンス利用状況の管理（課金処理）
 開発体制・規模
 • 5人以下の少数のメンバーでスクラムで開発
 • 管理 VM 数：1000 以上（ステージング + 商用環境） 
 • ソースコード行数：50万行以上
 もう少し詳しい中の仕組みを知りたい方はこちら 
 ベアメタルのつくりかた： https://speakerdeck.com/hiconyan/beametarufalsetukurikata 
 クラウドサービスのウラオモテ： https://speakerdeck.com/hanasuke/outside-and-inside-of-cloud-services 
 BM / DH の開発
 8
9. PR の内容に応じて以下の片方 or 両方を行いテストが通れば PR をマージ 
 単体テスト
 • 単一リポジトリを対象としたテスト
 • 主に lint と RSpec（Ruby のテストフレームワーク）を流す
 • 対象リポジトリは 20 個以上
 結合テスト
 • 複数リポジトリのコードを連携させたテスト
 • ユーザ目線で API を叩いて実際にサーバインスタンスの作成・削除などを行う 
 • 環境を用意するための下準備も多く 4-5 時間ほどかかる 🥱
 BM / DH で行っている CI
 
 9
10. オンプレ上に構築した vSphere 環境上の VM で単体・結合テストを実施
 
 
 
 
 
 
 商用環境（KVM 上で VM を運用）を単純化したテスト環境（VM 群）を複数保持
 BM / DH の CI 実行環境
 10 ESXi
 ESXi
 ESXi
 物理サーバ
 物理サーバ
 物理サーバ
 ESXi
 物理サーバ
 検証環境1
 検証環境2
 検証環境 N
 
 
 
 
 
 
 VM
 VM
 VM
 VM
 VM
 VM
 物理サーバ
 物理サーバ
 snapshot 復元,
 Ansible 適用,
 
 各種テスト実行
 OS 自動インストール,
 ディスク削除, etc ...
 単体テスト実行
 （webhook）
 PR
 結 合 テス ト実 行 
 （手 動 ）

11. 11 1. BM / DH 開発の CI について
 2. GitHub Actions を導入した CI
 3. 導入・活用してみた所感

12. リポジトリやイシューに対する操作や様々なイベントをトリガーとして、
 事前に定義した workflow を GitHub から実行できるツール
 • workflow：トリガーとなるイベントと job とその実行順序などの定義
 • job：実行する step のリストと runner などの定義
 • step：shell の記述や外部 action の呼び出しなど具体的に実行する処理の定義
 • runner：一連の step の実行場所の定義
 
 
 GitHub Actions
 12 状況に応じてどちらかを選択する
 • GitHub-hosted runners
 • self-hosted runners

13. GitHub が提供する実行環境、よく使われるのはこちら
 • job ごとに clean な環境（マシン）が自動で払い出される 👍
 • 環境の構成（インストール済みパッケージなど）は固定 ※
 • カジュアルに使えるが従量課金（無料枠あり）💸 
 
 GitHub-hosted runners
 13 ※ スペック選択オプションについては 2022-09-01 に public beta となった
14. GitHub が提供する実行環境、よく使われるのはこちら
 • job ごとに clean な環境（マシン）が自動で払い出される 👍
 • 環境の構成（インストール済みパッケージなど）は固定 ※
 • カジュアルに使えるが従量課金（無料枠あり）💸 
 
 GitHub-hosted runners 利用にあたっての課題
 14 BM / DH では 20000分/月 ほど CI を回している
 4時間ほどかかる結合テストもあるため時間課金は避けたい、、、😔

15. 自前で用意する実行環境、準備がやや手間だが無料
 • 自前の環境（マシン・コンテナ）で runner アプリを起動 & GitHub に登録
 • 登録済みの runner を job が pick、runner アプリの動作環境で job が実行
 
 self-hosted runners
 15
16. 自前で用意する実行環境、準備がやや手間だが無料
 • 自前の環境（マシン・コンテナ）で runner アプリを起動 & GitHub に登録
 • 登録済みの runner を job が pick、runner アプリの動作環境で job が実行
 1つの runner が同じ時間に処理できる job は 1つ ≒ job の同時実行数が縛られる
 基本的には runner は登録されっぱなし ≒ job ごとに環境が使い回される 😩
 
 self-hosted runners のデメリット
 16 前の job のゴミが無い clean な環境で毎回 job を実行したい、、
 GitHub-hosted runners のように job ごとに runner を払い出したい、、

17. GitHub の推奨する方法
 Autoscaling with self-hosted runners - GitHub Enterprise Cloud Docs
 
 job が queue に積まれたことは webhook で受取可能
 webhook を受け取る度に、
 runner アプリが起動するマシンやコンテナを動的に起動して runner を登録し、
 job の終了とともに runner を登録解除してマシンやコンテナを破棄すれば、
 限られたリソースの中で job を毎回 clean な環境で実行可能
 
 
 runner の autoscaling によるデメリットの解消
 17
18. self-hosted runners の autoscaling のための OSS がいくつか存在
 • actions-runner-controller / actions-runner-controller
 ◦ kubernetes に runner コンテナを動的にデプロイ
 • phillips-labs / terraform-aws-github-runner
 ◦ AWS に terraform で runner マシンを動的にデプロイ
 autoscaling の選択肢
 18
19. self-hosted runners の autoscaling のための OSS がいくつか存在
 • actions-runner-controller / actions-runner-controller
 ◦ kubernetes に runner コンテナを動的にデプロイ
 • phillips-labs / terraform-aws-github-runner
 ◦ AWS に terraform で runner マシンを動的にデプロイ
 autoscaling の選択肢
 19 kubernetes 使ってないし気軽に手を出すものじゃないっぽいしなあ…
 強いマシン余ってるしお金払ってまで AWS とか使うのもなあ…
 ➔ 既にある環境で動かせるものを自分で作ってみよう 💡 
 🤔
20. CI 環境 with GitHub Actions
 20 ESXi
 ESXi
 ESXi
 物理サーバ
 物理サーバ
 物理サーバ
 ESXi
 物理サーバ
 検証環境1
 検証環境2
 検証環境 N
 
 
 
 
 
 
 VM
 VM
 VM
 VM
 VM
 VM
 物理サーバ
 物理サーバ
 snapshot 復元,
 Ansible 適用,
 各種テスト実行
 OS 自動インストール,
 ディスク削除, etc ...
 job queued 通知 
 （webhook）
 PR
 自作 runner-controller
 コンテナ起動
 workflow 実行
 runner
 アプリ
 
 
 
 
 
 runner 登録
 runner pick
 処理の終了後 runner 自動登録解除 & コンテナ自動削除

21. runner の autoscaling の実装
 21 自作 runner-controller
 コンテナ起動
 runner
 アプリ
 200行ほどのシンプルなコードベースで runner の autoscaling を実現 ✌ 
 job queued 通知 
 runner 登録
 処理の終了後 runner 自動登録解除 & コンテナ自動削除
 51行の Ruby アプリ by sinatra
 イメージの自動更新の仕組みも、
 この環境上で動作する定期実行 workflow によって実現
 emepheral モードで runner を起動することで実現
 --rm オプションつきで docker run することで実現
 71行の Dockerfile を元に build したイメージから作成 
 build 時に指定したバージョンの runner に加えて、 
 CI で用いる Ruby や Ansible なども予め封入 
 7行の起動スクリプト
 ssh 秘密鍵は docker run 時に
 VM 側の ~/.ssh をマウント

22. 単体テストの workflow 例
 22 事前処理
 （PR 情報の表示など） 
 事後処理
 （テスト結果の slack 通知など） 
 linter
 RSpec
 テスト環境準備
 （snapshot 復元など） 

23. 結合テストの workflow 例
 23 全体の時間が長いため 
 適宜 job を並列実行させて時間短縮 
 テスト環境準備（snapshot 復元、ansible 適用） 
 サーバインスタンス作成 API 実行 
 作成したインスタンスの検証 

24. 24 1. BM / DH 開発の CI について
 2. GitHub Actions を導入した CI
 3. 導入・活用してみた所感

25. • GitHub Actions のような扱いやすい workflow 実行ツールを導入すれば、
 CI / CD 含め日々の作業の自動化のモチベーションが湧きやすい
 
 • 実行ごとに処理内容（workflow / 自作 action）をブランチで指定できる
 ◦ 既存 CI を回しつつ CI 自体の改修も同時進行しやすい
 
 • GitHub Actions 職人が生まれないように気をつける必要はある
 ◦ Jenkins 職人ほど隔絶されはしないと思うが
 
 • 手動実行時に与えるパラメータの柔軟性は今の所 Jenkins の方が優れている
 ◦ GitHub Actions は入力パラメータ数の制限もあるため今後に期待
 Jenkins から移行してみて
 25
26. runner の autoscaling について
 • autoscaling はやっぱり便利
 ◦ workflow / job を並列数や課金を気にせずガシガシ実行できて気持ち良い
 ◦ 開発自体もスケールしやすくなる
 ◦ シンプルな構成で作ったがちゃんと動いてくれてる
 ▪ 開発規模が大きくなってきたら、docker ホストの分割や
 runner-controller の複数運用・監視・ロギングなども検討候補となる
 
 • autoscaling なしで始めるのも全然アリ
 ◦ 前回の job のゴミ掃除を job や workflow の最初に自前で仕込めば良い
 ◦ BM/DH も最初は 1リポジトリに 1 runner を専属で起動させっぱなしだった
 26
27. GitHub Actions の機能について
 27 • 新機能の実装など進化が早い
 ◦ 今回紹介した autoscaling のための機能のほとんども 2021年リリース
 
 • ロードマップを眺めて将来的に実装される機能も見越して CI を作り込むのが吉
 ◦ https://github.com/orgs/github/projects/4247/views/1?filterQuery=action 
 
 • マイナーだが便利な機能の追加が runner のリリースノートからたまに見つかる
 ◦ https://github.com/actions/runner/blob/main/releaseNote.md 

28. GitHub Actions の機能について
 28 • 新機能の実装など進化が早い
 ◦ 今回紹介した autoscaling のための機能のほとんども 2021年リリース
 
 • ロードマップを眺めて将来的に実装される機能も見越して CI を作り込むのが吉
 ◦ https://github.com/orgs/github/projects/4247/views/1?filterQuery=action 
 
 • マイナーだが便利な機能の追加が runner のリリースノートからたまに見つかる
 ◦ https://github.com/actions/runner/blob/main/releaseNote.md 
 https://trends.google.co.jp/trends/explore?date=today%205-y&q=Github%20Actions,CircleCI,TravisCI

29. 大規模サービスの CI を GitHub Actions で実現
 • Jenkins からの移行
 • 既存のオンプレ資産を活用し、無料 CI 実行環境を構築
 • 自作 runner-controller と Docker により runner の autoscaling を実現
 • シンプルな構成で様々な workflow を実行
 まとめ
 29 self-hosted runners の導入はそこまで難しくない
 みんな GitHub Actions を使ってみよう！