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

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

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

Transcript

1. SDPF ベアメタルサーバー / ハイパーバイザー開発における

   GitHub Actions を活用した CI 事例の紹介

   NTT コミュニケーションズ

   プラットフォームサービス本部 クラウド & ネットワークサービス部

   開発オペレーション部門

   山中 克志

   

   View Slide

2. 名前：山中克志（@yamy）（入社6年目）

   所属：NTT コム PS 本部 C&N 部 開発オペレーション部門 7G 5T

   業務：SDPF ベアメタルサーバー / ハイパーバイザー開発

   メインの開発の傍ら業務効率を上げる何かをするのが好き

   アジャイル / スクラムのあれこれ導入・便利ツールや改善の生成 など

   趣味でこんなの作ってました：

   自己紹介

   Android 向けリズムゲーム

   Google Play 公開中

   スマホブラウザ向け

   オンライン UNO

   研究室のホームページ

   2
   分かりやすく見せれるものを

   作りたいタイプ

   

   View Slide

3. 話したいこと（目次）

   1. BM / DH 開発の CI について

   

   2. CI への GitHub Actions の導入

   a. 環境構成、実際に流している workflow 例 など

   3. 導入・活用してみた所感

   3
   BM = BareMetal server = SDPF ベアメタルサーバー

   DH = Dedicated Hypervisor = SDPF ハイパーバイザー

   

   View Slide

4. 4
   1. BM / DH 開発の CI について

   2. CI への GitHub Actions の導入

   3. 導入・活用してみた所感

   

   View Slide

5. SDPF ベアメタルサーバー / ハイパーバイザー

   5
   https://sdpf.ntt.com/
   

   View Slide

6. SDPF ベアメタルサーバー / ハイパーバイザー

   

   6
   https://sdpf.ntt.com/
   

   View Slide

7. サービス全体で数千台規模の物理サーバを現在提供中

   SDPF ベアメタルサーバー / ハイパーバイザー

   

   7
   https://sdpf.ntt.com/services/server-instance/ https://sdpf.ntt.com/services/vsphere/
   

   View Slide

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
   

   View Slide

9. PR の内容に応じて以下の片方 or 両方を行いテストが通れば PR をマージ
   

   単体テスト

   ● 単一リポジトリを対象としたテスト

   ● 主に lint と RSpec（Ruby のテストフレームワーク）を流す

   ● 対象リポジトリは 20 個以上

   結合テスト

   ● 複数リポジトリのコードを連携させたテスト

   ● ユーザ目線で API を叩いて実際にサーバインスタンスの作成・削除などを行う
   

   ● 環境を用意するための下準備も多く 4-5 時間ほどかかる 🥱

   BM / DH で行っている CI

   

   9
   

   View Slide

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

    結
    合
    テス
    ト実
    行
    

    （手
    動
    ）

    

    View Slide

11. 11
    1. BM / DH 開発の CI について

    2. GitHub Actions を導入した CI

    3. 導入・活用してみた所感

    

    View Slide

12. リポジトリやイシューに対する操作や様々なイベントをトリガーとして、

    事前に定義した workflow を GitHub から実行できるツール

    ● workflow：トリガーとなるイベントと job とその実行順序などの定義

    ● job：実行する step のリストと runner などの定義

    ● step：shell の記述や外部 action の呼び出しなど具体的に実行する処理の定義

    ● runner：一連の step の実行場所の定義

    

    

    GitHub Actions

    12
    状況に応じてどちらかを選択する

    ● GitHub-hosted runners

    ● self-hosted runners

    

    View Slide

13. GitHub が提供する実行環境、よく使われるのはこちら

    ● job ごとに clean な環境（マシン）が自動で払い出される 👍

    ● 環境の構成（インストール済みパッケージなど）は固定 ※

    ● カジュアルに使えるが従量課金（無料枠あり）💸 

    

    GitHub-hosted runners

    13
    ※ スペック選択オプションについては 2022-09-01 に public beta となった
    

    View Slide

14. GitHub が提供する実行環境、よく使われるのはこちら

    ● job ごとに clean な環境（マシン）が自動で払い出される 👍

    ● 環境の構成（インストール済みパッケージなど）は固定 ※

    ● カジュアルに使えるが従量課金（無料枠あり）💸 

    

    GitHub-hosted runners 利用にあたっての課題

    14
    BM / DH では 20000分/月 ほど CI を回している

    4時間ほどかかる結合テストもあるため時間課金は避けたい、、、😔

    

    View Slide

15. 自前で用意する実行環境、準備がやや手間だが無料

    ● 自前の環境（マシン・コンテナ）で runner アプリを起動 & GitHub に登録

    ● 登録済みの runner を job が pick、runner アプリの動作環境で job が実行

    

    self-hosted runners

    15
    

    View Slide

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 を払い出したい、、

    

    View Slide

17. GitHub の推奨する方法

    Autoscaling with self-hosted runners - GitHub Enterprise Cloud Docs

    

    job が queue に積まれたことは webhook で受取可能

    webhook を受け取る度に、

    runner アプリが起動するマシンやコンテナを動的に起動して runner を登録し、

    job の終了とともに runner を登録解除してマシンやコンテナを破棄すれば、

    限られたリソースの中で job を毎回 clean な環境で実行可能

    

    

    runner の autoscaling によるデメリットの解消

    17
    

    View Slide

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
    

    View Slide

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 とか使うのもなあ…

    ➔ 既にある環境で動かせるものを自分で作ってみよう 💡 

    🤔
    

    View Slide

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 自動登録解除 & コンテナ自動削除

    

    View Slide

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 をマウント

    

    View Slide

22. 単体テストの workflow 例

    22
    事前処理

    （PR 情報の表示など） 

    事後処理

    （テスト結果の slack 通知など） 

    linter
 RSpec

    テスト環境準備

    （snapshot 復元など） 

    

    View Slide

23. 結合テストの workflow 例

    23
    全体の時間が長いため 

    適宜 job を並列実行させて時間短縮 

    テスト環境準備（snapshot 復元、ansible 適用） 

    サーバインスタンス作成 API 実行 

    作成したインスタンスの検証 

    

    View Slide

24. 24
    1. BM / DH 開発の CI について

    2. GitHub Actions を導入した CI

    3. 導入・活用してみた所感

    

    View Slide

25. ● GitHub Actions のような扱いやすい workflow 実行ツールを導入すれば、

    CI / CD 含め日々の作業の自動化のモチベーションが湧きやすい

    

    ● 実行ごとに処理内容（workflow / 自作 action）をブランチで指定できる

    ○ 既存 CI を回しつつ CI 自体の改修も同時進行しやすい

    

    ● GitHub Actions 職人が生まれないように気をつける必要はある

    ○ Jenkins 職人ほど隔絶されはしないと思うが

    

    ● 手動実行時に与えるパラメータの柔軟性は今の所 Jenkins の方が優れている

    ○ GitHub Actions は入力パラメータ数の制限もあるため今後に期待

    Jenkins から移行してみて

    25
    

    View Slide

26. runner の autoscaling について

    ● autoscaling はやっぱり便利

    ○ workflow / job を並列数や課金を気にせずガシガシ実行できて気持ち良い

    ○ 開発自体もスケールしやすくなる

    ○ シンプルな構成で作ったがちゃんと動いてくれてる

    ■ 開発規模が大きくなってきたら、docker ホストの分割や

    runner-controller の複数運用・監視・ロギングなども検討候補となる

    

    ● autoscaling なしで始めるのも全然アリ

    ○ 前回の job のゴミ掃除を job や workflow の最初に自前で仕込めば良い

    ○ BM/DH も最初は 1リポジトリに 1 runner を専属で起動させっぱなしだった

    26
    

    View Slide

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 

    

    View Slide

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

    

    View Slide

29. 大規模サービスの CI を GitHub Actions で実現

    ● Jenkins からの移行

    ● 既存のオンプレ資産を活用し、無料 CI 実行環境を構築

    ● 自作 runner-controller と Docker により runner の autoscaling を実現

    ● シンプルな構成で様々な workflow を実行

    まとめ

    29
    self-hosted runners の導入はそこまで難しくない

    みんな GitHub Actions を使ってみよう！

    

    View Slide