記事検索

検索ワードを入力してください。
Sky Tech Blog
MLOps環境構築で​使用した​ツールの​紹介 GitHub Actions編

MLOps環境構築で​使用した​ツールの​紹介 GitHub Actions編

MLOps環境構築におけるGitHub ActionsのSelf-hosted runnerの導入について説明します。GitHub Actionsの基本的な使い方から、Self-hosted runnerの構築手順まで詳しく解説します。

はじめに

MLOps環境構築の中で GitHub Actionsの Self-hosted runnerを構築する機会がありましたので、その紹介を行います。
また、GitHub Actionsに馴染みのない方もいらっしゃると思いますので、GitHub Actionsの紹介も行います。

MLOpsとは何かを知りたい方は、下記の記事を参照ください。。

また、今回紹介する手順ではKubernetes環境を前提にします。 Kubernetesについては、下記の記事を参照ください。

GitHub Actionsとは

GitHub Actionsとは、GitHubが提供する CI/CD のサービスです。
これにより、リポジトリ内で自動化されたワークフローを作成し、コードのビルド、テスト、デプロイを行うことができます。

主な​特徴

  • ワークフローの自動化
    GitHub Actions を使用すると、リポジトリ内の特定のイベント(例:プッシュ、プルリクエスト、リリースなど)に基づいて自動的にアクションを実行するワークフローを定義できます。ワークフローはYAMLで定義され、.github/workflowsディレクトリに配置されます。

  • トリガー
    ワークフローは、プッシュやプルリクエスト、スケジュール、手動トリガーなど、さまざまなイベントによって開始できます。

  • シークレット管理
    ワークフロー内で使用するシークレット(APIキーやパスワードなど)を安全に管理できます。シークレットはリポジトリの設定から追加し、ワークフロー内で環境変数として参照できます。

基本的な​ワークフローの​例

以下は、任意のブランチにプッシュされたときにRuffチェックを実行するワークフローの例です。

name: CI

on:
  push:
    branches: '**'

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: clone
      uses: actions/checkout@v4
    - name: set up
      uses: actions/setup-python@v5
      with:
        python-version: '3.10'
    - name: install dependency
      run:
        python -m pip instll --upgrade pip
        pip install ruff
    - name: ruff format
      run: |
        ruff format --check --diff

ここで、runs-on: ubuntu-latestに注目します。
runs-onでこのワークフローをどこで実行するかを指定します。
ワークフローを実行する環境をrunnerと呼び、GitHubが提供するクラウドベースのrunnerをhosted-runner、ユーザが自前で準備したrunnerをself-hosted-runnerと呼びます。
hosted-runnerはいつでも(GitHubが落ちていなければ)利用可能で、多様な環境(Windows、MacOS、Ubuntu)が用意されているのが利点ですが、アカウントの種類ごとに無料枠が設定されており、これを超えてしまうと料金が発生してしまいます。
そこで、無料枠を超えるような利用の仕方だと、runnerを自前でホストするself-hosted-runnerを使用する選択肢が出てきます。

Self-hosted runnerとは

self-hosted runnerは、GitHub Actionsのワークフローを実行するために、ユーザー自身が管理するサーバーや仮想マシン上でランナーをホストするオプションです。
これにより、特定の環境やリソース要件に応じたカスタマイズが可能になります。

主な​特徴

  • カスタマイズ可能 :
    自分で管理するサーバー上でランナーをホストするため、特定のソフトウェアやライブラリを事前にインストールしたり、特定のハードウェアリソースを使用したりすることができます。

  • コスト効率 :
    自社のインフラを利用することで、クラウドベースのホステッドランナーの使用料金を削減できます。

  • ネットワーク制御 :
    セルフホステッドランナーは、企業の内部ネットワーク内で実行できるため、セキュリティやコンプライアンスの要件を満たすことができます。

  • スケーラビリティ :
    必要に応じてセルフホステッドランナーの数を増減させることで、ワークフローの実行に必要なリソースを柔軟に管理できます。

Self-hosted runner構築手順

ここでは、self-hosted runnerの構築手順について説明します。
先ほどのワークフローをself-hosted runnerで実行できるような仕組みを作っていきます。

構築する​システムの​概要

self-hosted runnerを使うにはAction runner podを使用する必要があり、そのpod内で今回動かしたいワークフローを動作させる環境(こちらもコンテナ)を準備する必要があります。
コンテナの中でコンテナを使うのでdocker in dockerという仕組みを使います。
図にまとめると以下のようになります。

まず、runnerを管理するActionRunnerCntrollerを導入し、GitHub上のリポジトリと接続します。
次にrunnerをデプロイし、最後にGitHub Actionsからrunner上でワークフローを実行する、という流れです。

前提

Kubernetes環境は構築済みで、コンテナレジストリには使用するdocker imageがすべてpushされていることを前提とします。

手順

1. secret設定

GitHubでPersonalAccessToken(PAT)を発行し、secretに登録します。
以下のコマンドを実行し、secretを登録します。
このとき、必ず管理者権限のPATを登録してください。

kubectl create ns actions-runner-system
kubectl create secret generic controller-manager \
  -n actions-runner-system \
  --from-literal=github_token=

2.actions-runner-controller(ARC)構築

インストールする前に、設定ファイルを準備します(arc-values.yaml)。
これには、デフォルトのARCの設定で上書きしたい箇所だけを記載します。
例えば、環境変数でプロキシの設定をするなどです。

env:    
  http_proxy: "http://1.2.3.4:1234

helmを使用してARCをインストールします。

helm repo add actions-runner-controller https://actions-runner-controller.github.io/actions-runner-controller
helm upgrade --install --namespace actions-runner-system --create-namespace \
            --wait actions-runner-controller actions-runner-controller/actions-runner-controller -f arc-values.yaml

3. runnerの​デプロイ

デプロイするyamlを準備します。
以下は一例です。

kind: RunnerDeployment
metadata:
  name: example-runnerdeploy
spec:
  replicas: 2
  template:
    spec:
      image: summerwind/actions-runner-dind
      dockerdWithinRunnerController: true
      repository: your/GitHubRepo
      labels: ci-runner

ここで大切なのは、dockerdWithinRunnerControllerをtrueにする(dindできるようにするため)ことと、label(ワークフローをどのrunnerで実行するかの識別に必要)の設定です。
以下のコマンドでデプロイします。

kubectl apply -f <ファイル名>

4. デプロイできているかの​確認

podがRunningになっているかの確認

kubectl get pod -A

GitHubで認識できているかの確認
リポジトリのsettings/Actions/Runnersで、デプロイしたrunnerが表示されてstatusがIdleかを確認する。

5. ワークフローの​実行

hosted-runnerを使用したyamlで、runs-on に先ほどデプロイしたrunnerのlabelを指定します。(runs-on: ci-runner)
あとは適当なブランチにpushすれば、self-hosted-runnerを使用したワークフローが実行されます。

おわりに

GitHub Actionsの概要を紹介し、self-hosted runnerを使用してGitHub Actionsのワークフローを実行する手順を説明しました。
ぜひ、self-hosted runnerを使用してCI/CD環境の構築に挑戦してみてください!

私たちは、データ分析基盤の構築やDeep Learningモデル開発、MLOps構築、生成AIモデル開発等データに関わるプロジェクトを伴走支援しております。MLOps環境の開発経験のある方や、興味のある方は、ぜひご応募ください。あなたのスキルと情熱をお待ちしています。


\シェアをお願いします!/
  • X
  • Facebook
  • LINE
キャリア採用募集中!

入社後にスキルアップを目指す若手の方も、ご自身の経験を幅広いフィールドで生かしたいベテランの方も、お一人おひとりの経験に応じたキャリア採用を行っています。

Sky株式会社のソフトウェア開発や製品、採用に関するお問い合わせについては、下記のリンクをご確認ください。
お問い合わせ
ホーム