【Github Actions】Self-hosted runnersの振り返り
はじめに
今回、みすてむず いず みすきーしすてむず (4) Advent Calendar 2023の12/15の枠として投稿させていただいてます。
せっかくいただいた機会ですので、2023年、特にお世話になったGitHub ActionsのSelf-hosted runnersを私の観点踏まえ振り返ろうと思います。
きっかけ
Self-hosted runnersを利用しようと思ったきっかけはセキュリティ要件でした。
私はAWSのEC2サーバー上で運用しているプライベートのサービスに対して、CI/CD目的でGitHub Actionsからのアプローチを模索してましたが、このとき解決が見込めたのがSelf-hosted runnersでした。
ネットワークのセキュリティ向上
きっかけで書いてある以下のケースをどのように解決されるのかを振り返ります。
AWSのEC2サーバー上で運用しているプライベートのサービスに対して、CI/CD目的でGitHub Actionsからのアプローチ
GitHubで提供されているランナーは、GitHub-hosted runnersと呼ばれます。
GitHub-hosted runnersで運用する場合
最初のアプローチとして考えたのは、IPアドレスとポートの制限制限を設ける方法です。
設定できる箇所として、以下の2箇所があります
- VPCのネットワークACL
- EC2のセキュリティグループ
GitHub-hosted runnersの課題
GitHubが公開するIPがかなりの数あり、上記2箇所はルールの数が決まってましたのでIPアドレスの設定が行えませんでした。
インバウンドルールに0.0.0.0/0の22ポートを許可するルールの追加もできますが、サーバー内へのアクセスは防げてもアクセスをネットワークレベルで制限してるわけではないので、DoS攻撃が来た場合にサーバーが落ちる可能性があります。
Self-hosted runnersで解決
Self-hosted runnersは、自前のサーバーをGitHub Actionsのランナーとして利用することができます。
Self-hosted runnersを設定すると、自前のサーバーからGitHub Actionsに50secのロングポーリングが行われます。
つまり、自前サーバーのインバウンド許可設定は不要です。
Self-hosted runnersのサーバーはElasticIPによってパブリックIPを固定化することができるので、運用してるEC2側のセキュリティグループにはそのIPアドレスと22ポートを許可するルールを追加すればセキュリティが高くなります。
さらに、アウトバウンドにGitHubのドメインをルール追加することによって更なるセキュリティの向上が見込めます。
Self-hosted runnersの課題
自前のサーバーを用意するわけなので、その分料金を気にする必要があります。
特に自前のサーバーをEC2で立てる場合は、頻度の多い処理を扱う場合は常に稼働状態にさせないと行けません。
EC2であればEvent Bridge Schedulerによる稼働時間の調整や、何かしらの自動起動&停止の仕組みを検討してください。
Self-hosted runnersの注意点
Self-hosted runnersを利用するジョブ上でのオープンソースのアクションの利用に注意してください。
オープンソースのアクションに悪意のあるコミットが紛れてしまった場合、マシン内部から情報が漏れるリスクがあります。
もし利用する場合はブランチ名ではなくタグ名を指定してください。
その他セキュリティに関して、以下の公式ドキュメントを参照してください
その他、Self-hosted runnersの振り返り
個人的に運用してみて、思ったこと
ランナーのラベルは付与しておいた方がいい
Self-hosted runnersのラベルは目的別に付与すること、
また、なるべくランナーを登録するタイミングで、ラベルを作成&付与することを勧めます。
理由としては、ランナーが増えてきた際に付与することが手間が発生するからです。
特にworkflow_dispatchイベントを利用してるワークフローでは、ymlの変更が浸透されるのを待つケースが発生しますので、可能なら早めにラベルを付与しておいた方がいいです。
Self-hosted runnersのプロセスをサービス化させる
サービス化させることによって、マシンの起動と同時にランナーがIdle状態になります。
起動させる手間が省けて、運用が楽になります。
1台に複数のランナーを設定する
ランナーはジョブが発生した際にActive状態になり、Idel状態になるまで他のジョブを受け付けません。
後続は待ちが発生してしまうので、その待ちを緩和させるために複数のランナーを用意します。
1台あたり1ランナーを用意する方法だと、増やす場合にサーバーを用意したり等の手間が発生してしまいますので、1台に複数ランナー用意したほうがセットアップの手間も減るのでお勧めです。
Windows上でSelf-hosted runnersの設定
こちらは注意点です。
Windowsマシン上でSelf-hosted runnersのサービス化を行う場合は、初期設定時にのみ行えます。あとからサービス化はできないので注意してください。
最後に
ここで書かせていただいた内容は、一端の情報ですので、
もっと深い内容や基本的なこと、設定方法等、公式ドキュメントに記載があります。
利用する前にぜひ一読お願いします。
Discussion