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

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

yamy
November 02, 2022

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

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

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

yamy

November 02, 2022
Tweet

Other Decks in Programming

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 を使ってみよう!