地球から約880光年離れたところに存在する太陽系外惑星「WASP-121b」は、球形ではなくラグビーボールに近い形であったり、「金属の雲が浮かび、ルビーやサファイアの雨が降り注ぐ環境」である可能性が示されたりと、SFチックな惑星として知られています。天文学者たちがWASP-121bの大気構造を分析するために観測をしたところ、惑星における天候の仕組みに関する従来の理解を揺るがすような大気構造をしていることが発見されました。
WASP-121bの大気をさらに分析するために、ヨーロッパ南天天文台の研究者であるジュリア・ビクトリア・ザイデル氏らは、4つの望遠鏡からの合成光でWASP-121bにおける大気の立体構造や循環パターンを観測しました。
結果として、WASP-121bの大気は以下の画像で示されているように3つの層に分かれていることが判明しました。WASP-121bの大気層は上から「水素の風」「ナトリウムのジェット気流」「鉄の空気」となっており、ザイデル氏によるとWASP-121bと同じような大気構造はこれまでどの惑星でも見られなかったものであるとのこと。
⇧ 観測方法が複雑そうですな...
GitHub Actionsのジョブはrunnerに送信するのではなくrunnerが取得しに行ってると思われる話
職場の方に連携いただいて「GitHub Actions」 の「Self-hosted runners」におけるワークフローが処理される流れについて理解ができたので、備忘録として。
「GitHub Actions」は、
⇧「Gitリポジトリ」に「.github/worflows/*.yml」という「YAMLファイル」を「ワークフロー」として、「ワークフロー」を実行することで様々な処理を行う感じで、「ジョブ」が実行されるのは「runner」に指定したマシン上になるのだが、
⇧ ドキュメントにある通り、「runner」としては大きく分けて、
の2種類がありますと。
今回は、「Self-hosted runners」に関する話になります。
まず、公式のドキュメントがイケてないのだが、
セルフホストランナーのラベルについて
ラベルを使うと、セルフホストランナーの共有される特徴に基づき、ワークフローのジョブを特定の種類のセルフホストランナーに送れます。
⇧ この部分だけ見ると、あたかもrunnerに対してジョブを送信しているように読み取れますと。
つまり、この説明だと、
| No | 処理 | 場所 |
|---|---|---|
| 1 | ワークフローのトリガーのイベント送信 | イベントに依る |
| 2 | イベント受信、ワークフローの処理開始 | Gitリポジトリ |
| 3 | ワークフローのジョブ送信 | GitHub Actions |
| 4 | ワークフローのジョブ受信 | Self-hosted runner |
| 5 | ワークフローのジョブを処理 | Self-hosted runner |
というような形になってしまう。
で、職場の方に教えてもらって、正しくは、
| No | 処理 | 場所 |
|---|---|---|
| 1 | ワークフローのトリガーのイベント送信 | イベントに依る |
| 2 | イベント受信、ワークフローの処理開始 | Gitリポジトリ |
| 3 | ワークフローのジョブをキューに送信 | GitHub Actions |
| 4 | キューを監視 ※1 | Self-hosted runner |
| 4 | ワークフローのジョブをキューから取得 | Self-hosted runner |
| 6 | ワークフローのジョブを処理 | Self-hosted runner |
※1 GitHub Actionsのドキュメントで仕組みが説明されていないから分からないが、ポーリングのような仕組みで常時キューを監視しているであろうとのこと。
というような形になっていると聞いて、納得。
公式のドキュメントの内容が正しいとしてしまうと、
GitHubの環境 → Self-hosted runnerの環境
となってしまい、「Self-hosted runners」の外部からリクエストが来るということになってしまう。
正しくは、
Self-hosted runnerの環境 → GitHubの環境
のように、「Self-hosted runners」の方からリクエストされないと駄目であると。
と言うのも、我々の開発環境（「Self-hosted runners」用の仮想マシンが配置されている）が、「GitHub」からのような外部からのリクエストを受け付けないネットワーク設定になっているから。
我々の開発環境（「Self-hosted runners」用の仮想マシンが配置されている）の外に出て行く分には問題ないネットワーク設定になっているので、「Self-hosted runners」の方から「GitHub」に対してリクエストする分には問題ない、という説明を受けて理解できたのだが、公式のドキュメントを見ていただけでは一生経っても理解できなかったので、職場の方に感謝です。
で、改めて公式のドキュメントを読み返してみたが、
セルフホステッド ランナーには self-hosted ラベルが付いている場合があります。 セルフホステッド ランナーを設定すると、既定では self-hosted ラベルが付与されます。 --no-default-labels フラグを渡すことでセルフホステッド ラベルが適用されないように設定できます。 ラベルを使用すると、オペレーティング システムやアーキテクチャなど、特定のランナーを探すオプションを作成できます。self-hosted で始まり (リストの最初にこれを示す必要があります)、必要に応じて追加のラベルを含むラベルの配列を指定することをお勧めします。
ラベルの配列を指定すると、指定したラベルをすべて持つランナーのキューにジョブが入れられます。
デフォルトラベルを使ったジョブの転送
ワークフローのYAMLを使って、これらのラベルの組み合わせに対してジョブを送信できます。
⇧ どちらにしろ、runnerがジョブを監視していることが読み取れない...
ちょっと、「GitHub Actions」のドキュメント酷過ぎる気がするんだが...
「GitHub」を「Microsoft」が管理するようになったからドキュメントが整理されなくなったのか、それ以前から適当な感じだったのかが分からないのだが、辛過ぎる...
ちなみに、別件で公式のドキュメントに対してissueを上げたら、新たにPR（Pull Request）を出して社内で検討してくれると回答ありましたが、他にも直して欲しいところがあり過ぎるんよね...
一次情報を拠り所にできないのは地獄なんよ...
とりあえず、
⇧ 上記のような状態になってしまっているドキュメントを読むことはストレスが尋常じゃないので改善して欲しい気持ちでいっぱいです...
適切な凡例などを掲載したシーケンス図やシステム関連概要図のようなものをドキュメントに載せてくれれば、解釈に悩まなくて済みそうではあるが...
登場人物の関係を絵にして欲しいんよね...
毎度モヤモヤ感が半端ない…
今回はこのへんで。
