クラウドネイティブアプリケーション用プラットフォーム「Radius」を触ってみた。 – Cloud Steady

※注意　本ブログ記事は認証で使われるRadius認証やRadiusサーバのブログ記事ではありません。

初めに

こんにちは。NewITソリューション部のエンジニアの下谷です。
今回は2023年10月頃にMicrosoft から発表されたクラウドネイティブアプリケーションを構築するためのOSSプラットフォーム
「Radius」を実際に触ってみたので、その紹介と簡単な手順、触ってみた感想を書いていこうと思います。

Radiusとは？

「Radius」とはざっくり言うと、Kubernetesをベースとしたアプリ基盤を構築できるIaCツールとなります。
特徴的な点としては以下の通りです。

Kubernetesの煩雑なyamlを書かずにアプリケーションのデプロイができる
アプリケーションと環境の設定が完全に分離しているため、切り替えが容易

実際にRadiusを触ってみた

Radiusのチュートリアルページでは、Github Codespaceを使っていてワンクリックで環境がすぐできるようになっていますが、
今回はせっかくなのでローカルで環境を作りたいと思います。

① 事前準備

Radiusを使うにあたって、ローカルではk3dとkindがサポートされているので、k3dを使っていこうと思います。
Overview: Radius on Kubernetes platform | Radius Docs (radapp.io)

以下をインストール。(利用環境がwindowsなので、Docker Desktop以外はchocolatey使ってインストールしました。)
・Docker Desktop
・kubectl
・helm
・k3d
本番環境用とテスト環境用で分けたいので、2つのクラスタを作成。
k3d cluster create test-env
k3d cluster create prod-env
2.で作成した2つのkubernetesにRadiusをインストール。(k3dでクラスタを作成すると、コンテキスト名は「k3d-<クラスタ名>」となる。)
rad install kubernetes --kubecontext k3d-test-env rad install kubernetes --kubecontext k3d-prod-env

② ワークスペースと環境の作成

Radiusでは「ワークスペース」というものがあり、これを用いることで複数の環境を管理することが可能です。

今回は以下のような構成でワークスペースと環境を作成していきたいと思います。

[test-env]ワークスペース→[test-env]環境
[prod-env]ワークスペース→[prod-env]環境

ワークスペースの作成と利用するkubernetesクラスタを指定。
rad workspace create kubernetes test-env --context k3d-prod-env
rad workspace create kubernetes prod-env --context k3d-prod-env
config.yamlファイルに1.の情報が作成されるので、確認。
macOS/Linux: ~/.rad/config.yaml
Windows: %USERPROFILE%\.rad\config.yaml
以下の通りになっていたら、OK。

workspaces:

default: prod-env

items:

prod-env:

connection:

context: k3d-prod-env

kind: kubernetes

test-env:

connection:

context: k3d-test-env

kind: kubernetes
[test-env]環境用、[prod-env]環境用ディレクトリを作成。
mkdir test-env
mkdir prod-env
最初に[test-env]環境を作成する。
[test-env]ワークスペースに切り替えて、[test-env]ディレクトリに移動。
rad workspace switch test-env cd test-env
[test-env]環境を作成。
(–fullオプション使って細かく設定することも可能だが、–fullオプションを使う場合、
現状は自動でlocal-devのレシピ(ローカル環境で実行するためのレシピ)が登録されないので注意。)
rad install
以下の画面が表示されたら、成功。
4.~8.の手順と同様の手順で[prod-env]環境を作成
rad workspace switch prod-env cd ../prod-envrad init
最後、config.yamlが以下のようになっている且つ以下図のようなフォルダ構成になっていたらOK。
workspaces:

default: prod-env

items:

prod-env:

connection:

context: k3d-test-env

kind: kubernetes

environment: /planes/radius/local/resourceGroups/default/providers/Applications.Core/environments/default

scope: /planes/radius/local/resourceGroups/default

test-env:

connection:

context: k3d-test-env

kind: kubernetes

environment: /planes/radius/local/resourceGroups/default/providers/Applications.Core/environments/default

scope: /planes/radius/local/resourceGroups/default
以上で[test-env]環境と[prod-env]環境が作成が完了となります。
後は以下で環境を切り替えつつ、アプリをデプロイしていく形となります。
・テスト環境への切り替え：rad workspace switch test-env
・本番環境への切り替え：rad workspace switch prod-env

Kubernetesについては、このタイミングでテスト用と本番用を用意して、
コンテキストをそれぞれのワークスペース・環境に紐づける必要があるのでご注意ください。

③ アプリのデプロイ

②完了後は必要に応じてワークスペースを切り替えて作業すればよいだけなので、
以降はテスト環境に絞って、手順を紹介したいと思います。

[test-env]ワークスペースに切り替えて、[test-env]ディレクトリに移動。
rad workspace switch test-env
cd test-env
[test-env]ディレクトリ配下に[app.bicep]ファイルが配置されているので、開くと以下内容が記載されている。
既にデモ用アプリのイメージが指定されているので、今回はこのデモ用アプリをデプロイしていく。
アプリをデプロイ＆実行。以下図のように表示されたらOK。
rad run app.bicep
実際にhttp://localhost:3000を開いてみると、以下の画面が表示されます。
Radiusではアプリと一緒にダッシュボードもデプロイされています。
http://localhost:7007を開くと、以下のダッシュボードのページを見ることができます。
また、以下のようにバックエンドやMongoDB等を追加することができます。
以下を見ると、18~24行目にconnectionsがありますが、ここでdemoアプリがバックエンドやDB間の接続を定義しています。
特にDBについて、接続するための認証情報をdemoアプリ側で持つ必要がない点はすごく良いなと感じました。
実際に上記内容でアプリをデプロイ＆実行して、http://localhost:3000を開いてみると、
以下図のように[Radius Connections]にバックエンドとDBが追加されています。
ダッシュボードの方でも確認してみると、以下のようにdemoアプリとバックエンド、DB間の依存関係を見ることができます。
追加できるリソースは今のところ以下のみです。
但し、Applications.Coreに含まれるExtendersを使えば、自分で独自のリソース追加することもできるようです。
・Applications.Core: アプリケーション・コンテナ・ゲートウェイ・ルート等のコアリソース。
・Applications.Dapr: Dapr の構成要素と構成の管理をサポートするリソース。
・Applications.Datastores: アプリケーション内で使用可能なデータストアリソース。
・Applications.Messaging: アプリケーション内で使用可能なメッセージングリソース。
・Bicep.Deployments: Bicep デプロイを処理するための機能。
詳細は以下を参照。
Overview: Resource schemas | Radius Docs (radapp.io)

④　検証まとめ

検証結果を以下にまとめます。

Kubernetesを使う場合は比較的長いyamlファイルを書く必要があるが、それを書く必要がなく、簡単にアプリをデプロイできた。
リソースの依存関係を簡単に記載でき、認証情報のハードコーディングが不要
ワークスペースを用いて環境毎に利用するKubernetesクラスターを分けることが可能。

また、今回はローカルでアプリを作成していったので、紹介する機会がありませんでしたが、
「recipe」というものがあり、③で作成したMongoDBのリソース定義の中で「recipe」を指定することで、
Kubernetes以外のAzureやAWSのリソース(Cosmos DBやS3)を利用することも可能です。

Bicep等のIaCツールとの比較

Radiusを触った感触としては、アプリの観点では Bicep,Terraform等の上位の存在になるかと考えています。
Bicep,Terraform側ではAzureリソースの定義を作成して、それを「recipe」に登録、
Radius側ではアプリを定義した上で利用する環境に応じて「recipe」を利用するといった流れになると考えているからです。

反対にコンテナを使わないアプリのリソースやAzure Virtual Desktopやサーバ単体などアプリに関係しないリソースについては、
現状はBicepやTerraformだけ使った方が良さそうなだと感じました。
RadiusはあくまでKubernetesをベースとしたアプリ基盤の作成にフォーカスを充てているので、
上に挙げたリソースの管理は厳しいと考えています。

触ってみた感想

ローカル環境で容易にアプリをデプロイでき、且つアプリの定義をほぼ変えず、
ワークスペースや「recipe」を切り替えるだけで環境を変えることができるのはすごく良いと感じました。

但し、RadiusはKubernetsをベースとしているので、Radiusを使う前にKubernetesの環境を
事前に用意する必要があるので、Kubernetesの知識が多少必要だと感じました。

また、ワークスペースやリソースグループ、環境の構成が若干分かりずらいのと、
ドキュメントがまだ少ないので、エラーに遭遇した際、解決するのが大変だと感じました。
(実際にエラーに遭遇して、解決するのに時間かかりました。)

最後に

今回はアプリ基盤を構築するためのIaCツール「Radius」を紹介いたしました。
まだ去年の10月に出たばかりでこれから機能の追加や改善が行われていくと思うので、これからに期待したいと思います。

また、弊社ではクラウドやAIを中心としたシステムを提供しております。
ご興味をお持ちいただけましたらお気軽にお問い合わせいただけると幸いです。

初めに