GitHub Actions の正常性の確認
ghe-actions-check
コマンド ライン ユーティリティを使って、your GitHub Enterprise Server instanceの GitHub Actions の正常性を確認できます。 詳細については、「コマンド ライン ユーティリティ」と「管理シェル (SSH) にアクセスする」を参照してく� さい。
GitHub Enterprise Server に自己署名証明書を使用する� �合のセルフホストランナーの設定
信� �された認証局によって署名された証明書でGitHub Enterprise Server上のTLSを設定することを強くおすすめします。 自己署名証明書でも動作はしますが、セルフホストランナーに追� の設定が必要になり、プロダクションの環境では推奨されません。 詳細については、「TLS の構成」を参照してく� さい。
ランナーマシンに証明書をインストールする
セルフホストランナーが自己署名証明書を使用して GitHub Enterprise Server に接続するには、接続がセキュリティで強化されるように、証明書をランナーマシンにインストールする必要があります。
証明書をインストールするステップについては、ランナーのオペレーティングシステ� のドキュメントを参照してく� さい。
証明書を使用するように Node.JS を設定する
ほとんどのアクションは JavaScript で記述されており、オペレーティングシステ� の証明書ストアを使用しない Node.js を使用して実行されます。 セルフホスト ランナー アプリケーションで証明書を使用するには、ランナーのコンピューターで NODE_EXTRA_CA_CERTS
環境変数を設定する必要があります。
環境変数をシステ� 環境変数として設定するか、セルフホスト ランナー アプリケーション ディレクトリで .env という名前のファイルで宣言することができます。
次に例を示します。
NODE_EXTRA_CA_CERTS=/usr/share/ca-certificates/extra/mycertfile.crt
環境変数は、セルフホストランナーアプリケーションの起動時に読み込まれるため、セルフホストランナーアプリケーションを設定または起動する前に、環境変数を設定する必要があります。 証明書の設定が変更された� �合は、セルフホストランナーアプリケーションを再起動する必要があります。
証明書を使用するように Docker コンテナを設定する
ワークフローで Docker コンテナアクションまたはサービスコンテナを使用する� �合は、上記の環境変数の設定に� えて、Docker イメージに証明書をインストールする必要がある� �合もあります。
GitHub Actions の HTTP プロキシ設定
your GitHub Enterprise Server instance に HTTP プロキシ サーバー が構成されている� �合:
-
localhost
と127.0.0.1
を HTTP プロキシ除外 リストに追� する必要があります。 -
ご利用の外部ストレージの� �所がルーティング不可能である� �合は、該当する外部ストレージ URL も、除外リストに追� する必要があります。
プロキシ設定の変更の詳細については、「アウトバウンドの Web プロキシ サーバーの構成」を参照してく� さい。
これらの設定が正しく構成されていない� �合は、GitHub Actions 構成の設定や変更時に Resource unexpectedly moved to https://<IP_ADDRESS>
のようなエラーが発生する可能性があります。
ランナーが新しいホスト名を使用して GitHub Enterprise Server に接続しない
警告: 初期セットアップ後に GitHub Enterprise Server のホスト名を変更しないでく� さい。 ホスト名を変更すると、インスタンスの停止に及ぶ予想外の動作が生じます。
新しいホスト名を使用して環境内に GitHub Enterprise Server を展開し、古いホスト名がインスタンスに解決されなくなった� �合、セルフホスト ランナーは古いホスト名に接続できず、ジョブは実行されません。
your GitHub Enterprise Server instanceに新しいホスト名を使うには、セルフホステッド ランナーの構成を更新する必要があります。 各セルフホストランナーには、次のいずれかの手� �を行う必要があります。
- セルフホスト ランナー アプリケーション ディレクトリで、
.runner
と.credentials
のファイルを編集して、古いホスト名のすべてのメンションを新しいホスト名に置き換えてから、セルフホスト ランナー アプリケーションを再起動します。 - UIを使用して GitHub Enterprise Server からランナーを削除し、再度追� します。 詳細については、「セルフホスト ランナーの削除」および「セルフホスト ランナーの追� 」を参照してく� さい。
スタックジョブと GitHub Actions メモリと CPU の制限
GitHub Actions は、your GitHub Enterprise Server instanceで実行されている複数のサービスで構成されます。 デフォルトでは、これらのサービスは、ほとんどのインスタンスで機能するデフォルトの CPU およびメモリ制限で設定されています。 た� し、GitHub Actions のヘビーユーザは、これらの設定を調整する必要がある� �合があります。
ジョブが開始されていないことに気付いた� �合(アイドル状態のランナーが存在する� �合でも)、または UI でジョブの進行状況が更新または変更されていない� �合は、CPU またはメモリの上限に達している可能性があります。
1. 管理コンソールで全体的な CPU とメモリの使用率を確認する
Management Console にアクセスし、モニターダッシュボードを使用して、[System Health] の下の全体的な CPU とメモリのグラフを調べます。 詳細については、「モニター ダッシュボードへのアクセス」を参照してく� さい。
[システ� 正常性] 全体の CPU 使用率が 100% に近い� �合、または空きメモリが残っていない� �合は、your GitHub Enterprise Server instanceが容量いっぱいで実行されているため、スケールアップする必要があります。 詳細については、「CPU またはメモリ リソースの増� 」を参照してく� さい。
2. 管理コンソールで Nomad Jobs の CPU とメモリの使用率を確認する
全体的な [System Health] の CPU とメモリの使用率に問題がない� �合は、モニターダッシュボードページを下にスクロールして [Nomad Jobs] セクションに移動し、[CPU Percent Value] と [Memory Usage] のグラフを確認します。
これらのグラフの各プロットは、1 つのサービスに対応しています。 GitHub Actions サービスについては、以下を探してく� さい。
mps_frontend
mps_backend
token_frontend
token_backend
actions_frontend
actions_backend
これらのサービスのいずれかが 100% またはそれに近い CPU 使用率であるか、メモリが上限(デフォルトでは 2 GB)に近い� �合、これらのサービスのリソース割り当てを増やす必要がある� �合があります。 上記のサービスのどれが上限に達しているか、上限に近いかを注視してく� さい。
3. 上限に達したサービスへのリソース割り当てを増やす
-
SSH を使用して管理シェルにログインします。 詳細については、「管理シェル (SSH) にアクセスする」を参照してく� さい。
-
次のコマンドを実行して、割り当てに利用可能なリソースを確認します。
nomad node status -self
出力で [Allocated Resources] セクションを見つけます。 これは次の例のようなものです。
Allocated Resources CPU Memory Disk 7740/49600 MHZ 23 GiB/32 GiB 4.4 GiB/7.9 GiB
CPU とメモリの� �合、すべての サービスの 合計 に割り当てられている量 (左側の値) と使用可能な量 (右側の値) が表示されます。 上記の例では、合計 32GiB のうち 23GiB のメモリが割り当てられています。 これは、9GiB のメモリを割り当てることができるということを示しています。
警告: 利用可能なリソースの合計を超える容量を割り当てると、サービスが開始されませんので注意してく� さい。
-
ディレクトリを
/etc/consul-templates/etc/nomad-jobs/actions
に変更します。cd /etc/consul-templates/etc/nomad-jobs/actions
このディレクトリには、上記の GitHub Actions サービスに対応する 3 つのファイルがあります。
mps.hcl.ctmpl
token.hcl.ctmpl
actions.hcl.ctmpl
-
調整が必要なサービスを特定した� �合は、対応するファイルを開き、次のような
resources
グループを見つけます。resources { cpu = 512 memory = 2048 network { port "http" { } } }
値は、CPU リソースの� �合は MHz、メモリリソースの� �合は MB です。
たとえば、上記の例のリソース制限を CPU と 4 GBのメモリの 1GHz に増やすには、次のように変更します。
resources { cpu = 1024 memory = 4096 network { port "http" { } } }
-
ファイルを保存して終了します。
-
ghe-config-apply
を実行して、変更を適用します。ghe-config-apply
の実行中にFailed to run nomad job '/etc/nomad-jobs/<name>.hcl'
のような出力が表示される� �合は、変更によって CPU またはメモリのリソースが過剰に割り当てられている可能性があります。 この� �合は、構成ファイルをもう一度編集し、割り当てられた CPU またはメモリを減らしてから、ghe-config-apply
を再実行します。 -
構成が適用されたら、
ghe-actions-check
を実行して、GitHub Actions サービスが動作していることを確認します。
Dependabot が既存のワークフローをトリガーするときのエラーのトラブルシューティング
your GitHub Enterprise Server instanceに対して Dependabot の更新プログラ� を設定した後、Dependabot イベントによって既存のワークフローがトリガーされるとエラーが発生することがあります。
既定では、push
、pull_request
、pull_request_review
、または pull_request_review_comment
のイベントから Dependabot によってトリガーされる GitHub Actions ワークフローの実行は、リポジトリ フォークから開かれたかのように扱われます。 他のアクターによってトリガーされるワークフローとは異なり、これは読み取り専用の GITHUB_TOKEN
を受け取り、通常使用できるシークレットにはアクセスできないことを意味します。 これにより、Dependabot によってトリガーされたときに、リポジトリへの書き込みを試みるワークフローが失敗します。
この問題を解決するには、次の 3 つの方法があります。
if: github.actor != 'dependabot[bot]'
のような式を使用して、Dependabot によってトリガーされないようにワークフローを更新できます。 詳細については、「式」を参照してく� さい。- ワークフローを変更して、このような制限がない
pull_request_target
を含む 2 段階のプロセスを使用できます。 詳細については、「GitHub Actions による Dependabot の自動化」を参照してく� さい。 - Dependabot のアクセスによってトリガーされるワークフローをシークレットに提供し、
permissions
という用語でGITHUB_TOKEN
の既定のスコープを広げることができます。 詳細については、以下の「シークレットへの Dependabot のアクセスとアクセス許可の増� によってトリガーされるワークフローの提供」を参照してく� さい。
シークレットへの Dependabot のアクセスとアクセス許可の増� によってトリガーされるワークフローの提供
- SSH を使用して管理シェルにログインします。 詳細については、「管理シェル (SSH) にアクセスする」を参照してく� さい。
- your GitHub Enterprise Server instanceの Dependabot によってトリガーされるワークフローの制限を削除するには、次のコマンドを使います。
$ ghe-config app.actions.disable-dependabot-enforcement true
- 構成を適用します。
$ ghe-config-apply
- GitHub Enterprise Serverに戻ります。