作者:ソリューショングループ 岡村
Azure Container Apps & Dapr
今回は、Azure Container Apps (ACA) で Dapr コンポーネントを使用してみた感想を紹介します。ACAでDaprを使う際の参考になる公式ドキュメントはこちら。Dapr にはさまざまなComponentがあり、それらを組み合わせて利用することで、柔軟な構成が可能となっています。
良かった点
- Azure Storage Queues binding
- Queue bindingを利用することで、ACAでQueueトリガーを使用できるようになりました。さらに、このバインディングがenqueue/dequeueの処理を担ってくれるため、アプリケーションにAzure Blob Storage SDKなどをインストールする必要がなく、enqueue/dequeue の処理を自分で書かなくて済みました。
- また、上記bindingがenqueue/dequeueを担ってくれるため、アプリケーションにAzure Blob Storage SDK等をinstallする必要がなくなり、enqueue/dequeue の処理を自分で書かなくて済んだ。
- Azure Key Vault secret store
- ACA自体にSecret管理機能はあるが、それを使わずに Dapr Secret Component を使った。
- Dapr Secret Component で Azure KeyVaultを選択すると、kv上のsecretを名称を指定して、Dapr経由で参照できるようになる。
- ACAのUser Identityに Key Vault Secrets User を与えることで、ACA上のアプリがDapr経由でkv secretにアクセスできるようになる。
- そのため、secretをKey Vaultで集中管理することができる。
- なお、
Key Vault Secrets User
を使うことになるため、Key VaultでRBACが使えるようにしてあげる必要がある
- terraformの場合はenable_rbac_authorization: true
を指定する。
- azurerm_key_vault
物足りなかったこと
- Azure Blob Storage binding
- Daprでblobの操作をするComponentはあるのだが、単純なCRUDしかできず、Azure Blob Storage SDKで使えるような細かい要求を満たすということができないケースがある。
- 例えば、blobをstreamで取得したい時など - 今回のアプリでは使用を見送った。
- Daprでblobの操作をするComponentはあるのだが、単純なCRUDしかできず、Azure Blob Storage SDKで使えるような細かい要求を満たすということができないケースがある。
ハマった点
- queue binding でenqueue(input)/dequeue(output)の両方を実施しようとした場合、ACAのIdentityに Storage Queue Data Contributor を与える必要がある。
- 最初は Storage Queue Data Message ProcessorとStorage Queue Data Message Senderを与えていたのだが、ACAでenqueue/dequeue時に403エラーが発生したため
Contributor
に変更した。
- 最初は Storage Queue Data Message ProcessorとStorage Queue Data Message Senderを与えていたのだが、ACAでenqueue/dequeue時に403エラーが発生したため