問題タブ [github-actions-self-hosted-runners]

いくつかの GitHub セルフホステッド ランナーを作成しましたが、別の仮想ネットワークの背後にあるリソースにアクセスできるようにしたいと考えています。マシンの IP アドレスをホワイトリストに登録するとアクセスできるようになることはわかっていますが、自己ホスト型のランナーになる可能性のある仮想マシンをいくつでも持つことになるため、リソースごとにこれらの IP アドレスのホワイトリストを追加/削除すると、次のようになります。セルフホスト ランナーを作成するときに、多くの手作業や、各リソースの IP アドレスをホワイトリストに登録するための自動化が必要です。

セルフホスト ランナーが接続される仮想ネットワークを、残りのリソースの仮想ネットワークにピアリングしようとしましたが、それらのリソースへのセルフホスト ランナーへのアクセスが許可されると考えていましたが、次の場合に 403 ファイアウォール エラーが発生します。リソースの変更または読み取りを試みます...ここで何か不足していますか? Microsoft のドキュメントを読むと、仮想ネットワークのピアリングがうまくいくように思えます。

両方の Vnet に双方向ピアリングがあり、ピアリング設定で Vnet との間でトラフィックを転送しています。両方の VNet サブネット上の NSG は、インバウンドおよびアウトバウンドの VNet トラフィックを許可する基本的なものにすぎません

https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview

これに行くための推奨される方法はありますか？

独自の GitHub セルフホスト ランナーを持つ 3 つの Ubuntu PC があります。2 つのランナー (PC 1 および PC 2) にはtestというラベルが付けられ、3 番目 (PC 3) にはproductionというラベルが付けられています。さらに、すべてのランナーにはセルフホストのラベルが付けられます

GitHub にはdev、test、productionの 3 つのブランチがあります。目標は、プル リクエストをテスト ブランチまたは本番ブランチにマージすると、対象のラベルを持つすべてのランナーが新しいバージョンをプルし、Docker イメージ/コンテナーをビルドして構成することです。

この手順は PC 1 と PC 3 で機能し、テスト ブランチと運用ブランチでそれぞれマージします。ただし、テスト プル リクエストをマージした直後に PC 1 が「テスト ジョブ」を実行すると、PC 2 のランナーはアイドル状態のままになります。

PC 1 と PC2 のランナーのラベルが同じであることを再確認しました。何が間違っているのか、正しく理解していないのでしょうか? PC ごとにワークフロー ファイルを作成する必要がありますか?

ワークフロー ファイルtest.ymlは次のとおりです。

コードsrc/uploadsと同じ場所に画像をローカルに保存する nodejs プロジェクトがあります。githubaction を使用して cicd パイプラインをトリガーしようとすると、問題が発生します。コードを github からレポ (デジタル オーシャン ドロップレット) にダンプするだけです。デジタル オーシャン ドロップレット リポジトリにはユーザーがアップロードした画像が含まれているため、パイプラインがトリガーされると、github リポジトリにそれらの画像がないため、写真が削除されます。この問題を解決するにはどうすればよいですか

ワークフローの yaml ファイル