技術ブログ株式会社エーピーコミュニケーションズの技術ブログです。エーピーコミュニケーションズの技術ブログです。>こんにちは!ACS事業部の谷合です。Controller(以降ARC)の紹介をシリーズでお送りしております。前回前々回は以下の記事を書いておりました。技術ブログ今回はARCのコードを解説していきたいと思います。解説は長くなるので今回を前編とします。Podの作成さいごにACS事業部のご紹介はじめに私は全コードリーディング完了しておりますが、すべて解説するのは困難なため、以下の流れをコードから追ってみます。コードはGo言語で書かれています。GitHub突然ですが、以下の画像は何だと思いますか?コード内の関数の呼び出し元呼び出し先、関数の要約をMiroボードで可視化したものになります。このコード内から上記流れを抜粋していきます。この記事のことARCのコード解説します。以下のルールの基、解説していきます。Actions時にMessageを受信し、EphemeralRunnerSetの.Spec.Replicasを増減させるController処理概要ARCはControllerとして実装されています。Loopという機能を用い、CustomResource(今回はAutoscalingRunnerSet、AutoscalingListener、EphemeralRunnerSetなどのリソースを指します)定義を、管理対象リソースに強制させ、冪等性を保証しています。ARCの冪等性は各CRの定義を、CRの子リソースに継承したり、各子リソースが適切なタイミングで作成、更新、削除されることを指します。そのため、CustomResource(以降CR)デプロイを、契機に処理を開始します。こちらについては以下の記事で詳しく解説しておりますので参照ください。Loopという機能で冪等性を保っています。Loopを呼ぶといった動作をしています。監視における対象は以下の通りです。子リソースとは、CRをOwnerReferenceに設定しているリソースを指します。詳細な実装は、拙著の以下の記事も参照ください。zenn.devそれでは、各Controllerが何を監視しているかを見てみましょう。Controllerは自分自身と、子リソースであるEphemeralRunnerSetリソース、子リソースでないもののAutoScalingListenerリソースを監視しています。AutoScalingListenerリソースは親リソースがない唯一のCRです。このような仕様となっているかはどこにも書いてないですが、AutoScalingListenerリソースの役割であるGitHubとのロングポーリングを途絶えさせたくないなどの理由があるのかもしれません。Controllerは自分自身と、子リソースであるEphemeralRunnerを監視しています。Controllerは自分自身と、子リソースであるPodを監視しています。Controllerは自分自身と、子リソースであるPodとServiceAccount、子リソースでないロールを監視しています。リソースのデプロイ契機で、EphemeralRunnerSetとAutoScalingListenerリソースをデプロイ、EphemeralRunnerSetの.Spec.Replicas変更契機でEphemeralRunnerリソースとPodが作成できるわけです。Podが作成され、GitHubとのロングポーリングが開始されます。CustomResourceが作成される。以下の動作を見ていきましょう。resource.前述した通り、各コントローラでは自分自身または子リソース、それ以外を監視しています。Setが作成されます。Setの作成と、AutoScalingRunnerSetリソースの更新がされます。r.createRunnerScaleSet関数を見てみましょう。actionsClientFor関数を呼び出して、GitHubとやり取りをするためのclientを生成します。Setを登録するURL(リポジトリ、Oraganization、Enterprise)を使い、clientを生成します。これらは、AutoScalingRunnerSetリソースをhelmでデプロイする際に渡す必須の情報です。