こちらの記事はDIVXアドベントカレンダー2023の16日目の記事です。

はじめに

こんにちは。DIVXでエンジニアをしております、大久保と申します。

今回の記事はGitHubActionsのGitHubのホステッドランナーを、セルフホステッドランナーに変更した時のことを記事にしてみました。

GithubActionsとは

GitHub Actions は、ビルド、テスト、デプロイのパイプラインを自動化できる継続的インテグレーションと継続的デリバリー (CI/CD) のプラットフォームです。

リポジトリに対してpull request をビルドしてテストしたり、マージされた pull request を環境毎にデプロイしたりするワークフローを作成できます。

GitHubActionsではGitHubで用意されているGitHubホステッドランナーを使用するか、自前でEC2などを用意する、セルフホステッドランナーの2種類があります。

GitHubホステッドランナーとは

・システムの管理とメンテナンスはGitHubによって行われます。

・各ジョブの実行時には、いつでもクリーンなインスタンスが提供されます。

・このサービスはGitHubプランに含まれる無料分を利用し、無料分を超えた場合には分単位の課金が適用されます。

セルフホステッドランナーとは

・既存のクラウドサービスやローカルマシンを使用して、料金を支払うことなくセルフホステッドランナーを設置できます。

・ハードウェア、オペレーティングシステム、ソフトウェア、セキュリティの要件に合わせてシステムをカスタマイズすることが可能です。

・GitHubが用意している仮想サーバーとアプリの互換性がなくなったり、より厳密にカスタムを行う場合などに使用します。

実際にGithubActionsを変更していきます

前提として

・元々GitHubActionsのワークフローを作成が済んでいる

・EC2などのサーバーに必要な環境構築が済んでいる

まずGitHubのリポジトリ/Settings/Actions/Runnersの順に遷移してNew self-hosted runnerをクリックして新規作成します。

1. Runner imageをmacOS、Linux、Windowsの中から選択します。

今回はLinuxを選択しました。

2. Architectureをx64、ARM、ARM64の中から選択します。
今回はx64を選択しました。

ここから実際にEC2のサーバーに接続して、コマンドを入力していきます。

actions-runnerフォルダを作成して、ディレクトリを変更します。

$ mkdir actions-runner && cd actions-runner

curlコマンドを使用して GitHub Actions ランナーの特定バージョン（2.311.0）の tar.gz 圧縮ファイルをダウンロードします。

$ curl -o actions-runner-linux-x64-2.311.0.tar.gz -L <https://github.com/actions/runner/releases/download/v2.311.0/actions-runner-linux-x64-2.311.0.tar.gz>

SHA-256 チェックサムを検証するために使用するコマンドで、ファイルが正しくダウンロードされ、ファイルが変更されていないことを確認しています。

$ echo "**** actions-runner-linux-x64-2.311.0.tar.gz" | shasum -a 256 -c

ファイルが解凍され、その中に含まれるファイルが現在のディレクトリに展開されます。

$ tar xzf ./actions-runner-linux-x64-2.311.0.tar.gz

セルフホステッドランナーの初期設定を行い、リポジトリに登録するための認証トークンが発行されます。

$ ./config.sh --url <https://github.com/> --token ****

これでリポジトリにランナーが作成されました。

ここからは任意で追加していきます。

ランナーのグループを設定するか聞かれますが、今回はDefaultにしておきます。

Enter the name of the runner group to add this runner to: [press Enter for Default]

ランナーの名前は、デフォルトではIPアドレスで登録されるので、任意の名前を設定します。

Enter the name of runner: [press Enter for ip-****]

ラベルを貼り付けておくと、後々ランナーの管理が楽になります。

This runner will have the following labels: 'self-hosted', 'Linux', 'X64'
Enter any additional labels (ex. label-1,label-2): [press Enter to skip]

√ Runner successfully added
√ Runner connection is good

最後にフォルダ名を変更するか聞かれていますが、特に問題ないのでここもデフォルトにしておきます。

Enter name of work folder: [press Enter for _work]

√ Settings Saved.

ランナーを起動します。これで実際に動くようになりました。

$ ./run.sh

√ Connected to GitHub

Current runner version: '2.311.0'
2023-12-11 06:47:39Z: Listening for Jobs

最後に元々作成していたワークフローのruns-on: をGitHubホステッドからセルフホステッドに変更します。先ほどラベルを設定していれば、ここでラベルが付与されたランナーを指定することができます。
修正前

runs-on: ubuntu-latest

修正後

runs-on: [self-hosted, label-name]

セルフホステッドランナーの設定は以上になります。

下記のサンプルコードはmainブランチにプッシュされたことをトリガーに、デプロイをするGitHubActionsのワークフローです。

name: (ECS) Deploy to Staging

on:
  push:
    branches:
      - main  # このブランチにプッシュされた際にデプロイをトリガー

jobs:
  deploy:
    runs-on: self-hosted # セルフホステッドランナーを指定

    steps:
    - name: Checkout code
      uses: actions/checkout@v2　# リポジトリの内容をセキュアにチェックアウト

    - name: Deploy with Capistrano
      uses: miloserdow/capistrano-deploy@master # deployをする
      with:
         deploy_key: ${{ secrets.*** }}
         deploy_env: 'staging'  

セルフホステッドランナーを使用時に考慮するべき点

・EC2をワークフローの開始と同時に起動させる。

・EC2をワークフローの終了と同時に停止させる。

・Dockerを使用しているのでコンテナ、イメージなどをリフレッシュする。

・GitHub Actions Runnerの自動起動。

EC2をワークフローの開始と同時に起動させる

EC2は主にインスタンスが起動している時間に基づいて課金されますので、CI/CDを使用しない場合は停止させています。

停止しているEC2を開始させるワークフローを作成します。

jobs:
  start-instance:
    runs-on: ubuntu-latest
    steps:
     - name: Configure AWS credentials
       uses: aws-actions/configure-aws-credentials@v1
       with:
         aws-access-key-id: ${{ secrets.*** }}
         aws-secret-access-key: ${{ secrets.*** }}
         aws-region: ap-northeast-1

     - name: Start EC2 Instance
       run: |
         aws ec2 start-instances --instance-ids ***

インスタンスを開始するワークフローのランナーはGitHubホステッドのランナーにします。

IAMには開始のみの権限を与えて該当ののインスタンスを開始させます。

EC2をワークフローの終了と同時に停止させる

次にワークフローの終了をトリガーにEC2を停止させます。

同じ要領でワークフローを作成します。デプロイワークフローのキャンセル、失敗、成功のアクションに対してトリガーさせます。

name: Stop EC2 on Staging Deploy Job Cancel or Completion

on:
  workflow_run:
    workflows: ["(ECS) Deploy to Staging"]
    types:
      - "requested"
      - "completed"
jobs:
  stop-instance:
    if: github.event.workflow_run.conclusion == 'cancelled' || github.event.workflow_run.conclusion == 'success' || github.event.workflow_run.conclusion == 'failure'
    runs-on: ubuntu-latest
    steps:

- name: Configure AWS credentials
  uses: aws-actions/configure-aws-credentials@v1
  with:
    aws-access-key-id: ${{ secrets.*** }}
    aws-secret-access-key: ${{ secrets.*** }}
    aws-region: ap-northeast-1

  - name: Stop EC2 Instance
    run: |
       aws ec2 stop-instances --instance-ids ***

Dockerコンテナ、イメージなどをリフレッシュする

ECSを使用している場合は、毎回ECRからイメージをpullして作り直したりするので、ストレージ容量が不足してしまいます。Dockerを使用している場合は、下記をワークフローに追加します。

- name: Docker System Prune
    run: docker system prune -af --volumes

GitHub Actions Runnerの自動起動

ランナーはactions-runnerディレクトリでrun.shコマンドを打つことによって起動されます。毎回コマンドを入力するワークフローを作成してもいいのですが、今回はSystemdを利用したGitHub Actions Runnerの自動起動をさせます。

Systemdとは

Systemdは、Linuxの初期化システムとして広く採用されているツールキットです。システムの起動や停止、サービスの管理、デーモンの実行など、システム全体の管理を行うことができます。Systemdは、サービスやタスクをユニットとして管理し、これによりシステムの動作を柔軟に制御することができます。

Systemdサービスファイルの作成

/etc/systemd/system/ ディレクトリに actions-runner.service という名前でサービスファイルを作成します。

sudo vi /etc/systemd/system/actions-runner.service

以下の内容をファイルに記述します。

[Unit]
Description=GitHub Actions Runner

[Service]
ExecStart=/home/ubuntu/actions-runner/run.sh
WorkingDirectory=/home/ubuntu/actions-runner/
Restart=always
User=ubuntu

[Install]
WantedBy=multi-user.target

Systemdでサービスを管理するためには、サービスファイル（.serviceファイル）を作成する必要があります。このファイルには、サービスの動作や依存関係などの情報を記述します。

サービスが何らかの理由で終了した場合の再起動の動作、サービスが終了した場合に常に再起動します。

まとめ

今回はGitHubActionsのGitHubのホステッドランナーを、セルフホステッドランナーに変更した時のことを記事にしてみました。

考慮する点やどんなサービスを使用するかはそのプロジェクトによって異なると思いますが、少しでも皆様のためになる記事になっていたら幸いです。最後まで御覧いただきありがとうございました。

divxでは一緒に働ける仲間を募集しています。

興味があるかたはぜひ採用ページを御覧ください。