【GitHub Actions】self-hosted runners を Azure で構築する

どうも、ちゃんかわです。
最近は、Azure や GitHub Actions を使った CI/CD 環境の構築に勤しむ日々を送っています。

ついこの前、社内の活動で GitHub Actions の実行環境に self-hosted runners を利用する機会がありました。そこでの知見を共有すべく、今回は、self-hosted runners を Azure で構築する手順を紹介したいと思います。

runner と virtual-environments の使い方も紹介します、興味のある方は、ぜひご覧ください。

※注意
self-hosted runners を追加するリポジトリは private であることが推奨されています。以下の手順を行う際は、リポジトリのアクセス権限に注意してください。

GitHub Actions のおさらい

GitHub Actions は、CI/CD を含む様々なタスクをリポジトリに紐づく形で実行できるサービスです。

リポジトリへの push はもちろん、issue の発行や Pull Request の作成など、様々なリポジトリに関連するイベントをトリガーにジョブと呼ばれる単位でスクリプトを実行することができます。

self-hosted runners って何?

GitHub Actions を実行する環境として、以下の 2 つを選択することができます。

  • GitHub-hosted runners
  • self-hosted runners

GitHub-hosted runners は、名前の通り GitHub 側で管理された仮想環境で実行される runners を指します。基本的にはこの GitHub-hosted runners でジョブが実行されます、

自前でのサーバの用意やメンテナンスといった手間がかからず、即座に GitHub Actions のジョブを実行することができる一方で、仮想環境のスペックや使用されるイメージは定められており、カスタマイズできる範囲が限られています。

(ちなみに、Azure の Virutal Machine 上で Standard_DS2_v2 の VM サイズで実行されているようです。)

参考: Cloud hosts for GitHub-hosted runners

self-hosted runners では、自前で用意した仮想環境を用いて GitHub Actions を実行することができます。

サーバの用意や管理の手間はかかりますが、サーバをホスティングするクラウドサービスやマシンスペックなどを自身で決めることができるため、環境の構築次第でより高速にかつ柔軟に GitHub Actions を実行することができます。

virtual-environments の利用

virtual-environments は、GitHub-hosted runners で使用されるマシンイメージです。

actions/virtual-environments で公開されており、このイメージを self-hosted runners でも使用することができます。

virtual-environments を使用しなくても、公式がサポートしている OS であれば self-hosted runners を構築することは可能です。

参考: Supported architectures and operating systems for self-hosted runners

ただし、GitHub Marketplace で公開されている Actions は virtual-environments が前提で作られているものもあり、必要に応じて、依存関係にあるソフトウェアのインストールや環境変数等の設定を行わなけなければなりません。

たとえば、setup-python をワークフローで使用する場合は、各種 Python のパッケージのインストールやディレクトリの作成が必要となります。

今回の記事では、virtual-environments を使用して環境を構築します。

イメージのビルド方法は、Prepare environment and image deployment に記載されています。
(イメージのビルドには結構時間がかかります。私の環境では 4,5時間程度かかりました。)

上記のリンクに記載の GenerateResourcesAndImage.ps1 が完了すると、スクリプト実行時に指定した Azure の Storage Account 上に マシンイメージとなる VHD ファイル が作成されます。また、その VHD ファイルを参照する Virtual Machine(VM) の ARM テンプレートも合わせて作成されます。

Azure インフラの構築

virtual-environments のイメージを使用する VM を構築します。VM 構築にあたって、Virtual Network や Subnet、NIC、Public IP 等の Azure リソースを作成します。

Generated VM Deployment のやり方に従って CreateAzureVMFromPackerTemplate.ps1 を実行することで、以下ような環境が作成されます。

全体図

デフォルトでは、Standard_DS2_v2 の VM サイズが指定されており、個人利用ではそこそこお金がかかってしまいます。検証目的の場合は、Standard_B1s 等の VM サイズに変更するのが良いかと思います。

CreateAzureVMFromPackerTemplate.ps1 実行時には、VM に SSH でアクセスするためのユーザ名、パスワードを指定します。後の作業で使用するため、控えておいてください。

runner の導入と実行

これまでの作業では、virtual-environments を実行する Azure のインフラ環境を作成しましたが、GitHub Actions を実行するためには runner を導入する必要があります。

runner は、GitHub Actions のワークフローやジョブを実行するためのアプリケーションです。このアプリケーションを、これまでに作成した VM にインストールしていきます。

VM でのインストール作業にあたって、アクセストークンが必要になります。個人アクセストークン(PAT)は、以下の手順に従って発行できます。

参考: 個人アクセストークンを使用する

runner のインストールと実行手順は、self-hosted runners を追加したいリポジトリから確認することが可能です。

リポジトリにアクセス後、[settings] ⇒ [Actions] ⇒ [Runners] にアクセスし、[New self-hosted runner]を押下します。
環境に応じた OS (今回は、Linux) を選択する事で、以下のようなコマンドが表示されます。

コマンド画面例

これらのコマンドを、VM 上で実行することで runner のインストールと実行が可能となります。VM 上で実行する際には、先ほど控えていたユーザ名とパスワードを指定して、SSH でアクセスしてください。

以上の手順で runner を実行することはできますが、サービスとして実行されていないため、 VM が再起動すると runner が停止してしまいます。
マシン起動時に runner を実行するようにするためには、サービスとして設定する必要があります。

参考: セルフホストランナーアプリケーションをサービスとして設定する

上で紹介した runner のインストールとサービスとしての実行のやり方以外にも、公式でシェルスクリプトが用意されています。

実行するコマンドは、以下の二つです。

このシェルスクリプトを使用することで、より簡単に runner を導入することができるため、個人的にはこのやり方をお勧めします。

runner の実行に成功すると、下の画像のように登録した self-hosted runners が設定画面上に表示されます。
self-hosted runners のリスト

今回の手順では、self-hosted runners の名前はご自身が立てた VM の名前と同じなります。

self-hosted runners の利用

self-hosted runners を利用するには、GitHub Actions の workflow で self-hosted runners を指定する必要があります。今回は、Azure 上に環境を構築していますので、Azure の GitHub Actions の例を示します。

runs-on: self-hosted を指定することで、登録した self-hosted runners 上でジョブが実行されるようになります。

ここで注意点があります。

今回のワークフローの例で使用している Azure/login@v1.4.3Azure/cli@v1 ですが、これらは Azure CLI と Docker に依存しています。virtual-environments のイメージを使用された方は、既に組み込まれているためインストールの作業は不要ですが、virtual-environments を使用されていない方は、別途インストールが必要となります。

また、Azure/cli@v1 のジョブを実行する際に、以下のエラーが発生する場合があります。

dial unix /var/run/docker.sock: connect: permission denied

その場合は、以下の手順に従い Docker コマンドの Permission の設定を行ってください。

参考: Container 使用時の注意点

参考: Manage Docker as a non-root user

まとめ

self-hosted runners の Azure における構築手順と、virtual-environments、runners の導入手順について紹介しました。

今回構築した Azure のインフラ環境自体は、かなりシンプルな構成となっており、可用性やセキュリティの面でまだまだ改善の余地があります。ご自身の環境に合わせていろいろカスタマイズしていくことで、より高速で安全かつセキュアな GitHub Actions の実行環境を目指していただければと思います。

カスタマイズのやり方については、私の方でも今度また記事にしたいなと思っています。

以上、ご覧いただきありがとうございました。

  • このエントリーをはてなブックマークに追加