Tutorialsに「Use Helm to run your first app」が追加されていたので、試してみました。
このTutorialでは初期設定のアプリ定義をGitHubのリポジトリから取得して試すことになっています。また、仕組みとしてはアプリケーションをhelmで定義した状態から始まり、アプリケーションにRadiusを追加し、helmの定義でRadiusのレシピを追加してレシピが参照するRedisなどのサービスをまとめてデプロイできるようになります。また、アプリケーションとRedisの接続もRadiusに任せることができます。
リポジトリから取得すると、最初はhelmのChartが定義されています。アプリケーションコードらしきものも含まれていますが、実際にChartが参照しているのはghcr.io上のコンテナイメージなのでここでは使用しません。このサンプルアプリはRedisを参照しており、接続文字列はkubernetesのsecretに格納し、参照します。というわけで最初のアプリは、kubectlコマンドで名前空間とsecretを作成してからhelmコマンドで展開します。
ここから段階的にRadiusを追加するのがこのTutorialの目的になります。
まずアプリケーションコンテナにRadiusを追加するためには、radapp.io/enabled: 'true'というアノテーションを付与するだけで十分です。アノテーションを追加した後にhelmで更新すると、アプリのバージョンは増えていますが、Pod自体は更新されていません。そして、radコマンドで見ると、確かにRadiusがこのアプリを認識していることがわかります。仕組みとしては、kubernetesのDeploymentを認識し、アプリケーションの一部としてカタログ化することで管理しています。
次に、RedisをRadiusのレシピとして追加します。Radisuのレシピは例えばRedisであれば Applications.Datastores/redisCaches というリソースタイプのオブジェクトとしてkubernetesに追加することができます。また、secretNameフィールドを使って、接続情報を保持する場所を指定することができます。そして、再度helmで更新すると、必要なRedisのコンテナが展開されていることがわかります。
また、Radius上ではwebappとdbがそれぞれ認識されていますが、両方の接続（Connections）は空です。これは、まだRadius上では接続を定義していないためです。
再度にこの接続をRadius上で定義します。定義するためには、アプリ側のkubernetesオブジェクトのアノテーションにradapp.io/connection-redis: 'db'というものを追加します。アノテーションのキーのconnection-という接頭辞の後のredis部分が接続の名前となり、アノテーションの値が接続先のレシピ名となります。この時、RadiusはCONNECTION_{接続の名前}_URLという接続情報を格納する環境変数を自動的に作成します。そのため、もともとhelmチャートで定義していた環境変数名を削除します。逆に言うと、もともとの変数名はRadiusが自動的に作成する環境変数に合わせていたので、アプリ側を変更する必要がないとも言えます。改めてhelmチャートを更新すると、コンテナが再作成され、Radius側で接続されていることがわかります。
あとは実際にアプリに接続してTutorialは完了です。 このTutorialから、helmやkubernetesのリソース定義からでもRadiusを使うことができ、使うことでRadiusの特徴であるどのサービスを参照するかは開発側が定義できるが、参照したサービスが環境ごとにどのようなサービス（コンテナやクラウドサービス）で動き、接続情報をどのように管理するか、というのは運用側がレシピで定義できるようになるということがわかりました。
