Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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 コミュニケーションズ

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

    開発オペレーション部門

    山中 克志


    View full-size slide

  2. 名前:山中克志(@yamy)(入社6年目)

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

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

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

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

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

    自己紹介

    Android 向けリズムゲーム

    Google Play 公開中

    スマホブラウザ向け

    オンライン UNO

    研究室のホームページ

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

    作りたいタイプ


    View full-size slide

  3. 話したいこと(目次)

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


    2. CI への GitHub Actions の導入

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

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

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

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


    View full-size slide

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

    2. CI への GitHub Actions の導入

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


    View full-size slide

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

    5
    https://sdpf.ntt.com/

    View full-size slide

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


    6
    https://sdpf.ntt.com/

    View full-size slide

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

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


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

    View full-size 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 full-size slide

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

    単体テスト

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

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

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

    結合テスト

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

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

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

    BM / DH で行っている CI


    9

    View full-size 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 full-size slide

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

    2. GitHub Actions を導入した CI

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


    View full-size slide

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

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

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

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

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

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



    GitHub Actions

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

    ● GitHub-hosted runners

    ● self-hosted runners


    View full-size slide

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

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

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

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


    GitHub-hosted runners

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

    View full-size slide

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

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

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

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


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

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

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


    View full-size slide

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

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

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


    self-hosted runners

    15

    View full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size 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 full-size slide

  22. 単体テストの workflow 例

    22
    事前処理

    (PR 情報の表示など) 

    事後処理

    (テスト結果の slack 通知など) 

    linter
 RSpec

    テスト環境準備

    (snapshot 復元など) 


    View full-size slide

  23. 結合テストの workflow 例

    23
    全体の時間が長いため 

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

    テスト環境準備(snapshot 復元、ansible 適用) 

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

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


    View full-size slide

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

    2. GitHub Actions を導入した CI

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


    View full-size slide

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

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


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

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


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

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


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

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

    Jenkins から移行してみて

    25

    View full-size slide

  26. runner の autoscaling について

    ● autoscaling はやっぱり便利

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

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

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

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

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


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

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

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

    26

    View full-size 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 full-size 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 full-size slide

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

    ● Jenkins からの移行

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

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

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

    まとめ

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

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


    View full-size slide