Great video! Thanks for the in-depth review. One question, how does the Dapr client running in the front end container identify the backend app using the AppId? Does Dapr function as a service mesh across for example the Vnet that you deploy it in, with sidecars keeping a record of all other app.ids within the vnet? If you wanted to use Dapr to reference and app.id outside the Vnet how would that work?
Dapr needs only the Dapr ID (which is indeed specified as the AppId). The way it finds the backend depends on how name resolution is configured. With Container Apps (which uses Kubernetes) the name resolution is done with Kubernetes itself. When you deploy Daprized container apps, Kubernetes services are created for you that use the AppId as the service name. Standard Kubernetes name resolution is then used, which also means you cannot simply connect to apps outside the cluster. Dapr supports Hashicorp Consul for name resolution as well, but that is currently in Alpha state. Modifying the name resolution component in Container Apps is currently not supported because it requires a Dapr configuration spec. See docs.dapr.io/reference/components-reference/supported-name-resolution/setup-nr-consul/.
Have not tried that yet as we use Atlas or MongoDB API for Cosmos DB but it should be possible. Do not that ACA does not support privileged containers and run as root. So you will need to ensure your Mongo DB container can run in that way...
Thanks Geert for this excellent video! Keep them coming 😊
Well explained. Thanks.
Thanks! Glad you liked it...
Excellent video, thank you. What do you use for the lovely black diagrams? They look great
Thank you! I use Excalidram for the diagrams.
Great video! Thanks for the in-depth review. One question, how does the Dapr client running in the front end container identify the backend app using the AppId? Does Dapr function as a service mesh across for example the Vnet that you deploy it in, with sidecars keeping a record of all other app.ids within the vnet? If you wanted to use Dapr to reference and app.id outside the Vnet how would that work?
Dapr needs only the Dapr ID (which is indeed specified as the AppId). The way it finds the backend depends on how name resolution is configured. With Container Apps (which uses Kubernetes) the name resolution is done with Kubernetes itself. When you deploy Daprized container apps, Kubernetes services are created for you that use the AppId as the service name. Standard Kubernetes name resolution is then used, which also means you cannot simply connect to apps outside the cluster. Dapr supports Hashicorp Consul for name resolution as well, but that is currently in Alpha state. Modifying the name resolution component in Container Apps is currently not supported because it requires a Dapr configuration spec. See docs.dapr.io/reference/components-reference/supported-name-resolution/setup-nr-consul/.
Can i run a MongoDB Container on Container Apps?
Have not tried that yet as we use Atlas or MongoDB API for Cosmos DB but it should be possible. Do not that ACA does not support privileged containers and run as root. So you will need to ensure your Mongo DB container can run in that way...