Documentation: Centralized inbound gateway architecture options for Container Apps

[epomatti]

It would be nice to have a dedicated page in the documentation, perhaps under the Networking concepts section, to describe how ACA can be implemented along with a centralized inbound gateway, such as Application Gateway, API Management (APIM), Front Door, and others, while explaining the limitations and implications of each one of those designs. Or perhaps describe if this is not a recommendation.

There are some requirements and capabilities that could be deal breakers for teams interested in a serverless microservices approach with ACA, either before or after the decision is made. For example:

• WAF capabilities, such as IP restrictions and traffic inspection
• Native integration with Application Gateway
• Centralized endpoint for web services with URL path routing
• Manage a single certificate and custom domain

Here are some of the design options that I could gather by reading some other issues:

Design	Details
Self-managed Application Gateway	In this approach you create your own Application Gateway and you're responsible for creating and managing it's configuration, such as the application routes and ACA targets. ℹ️ gRPC is currently not supported by AGW: https://github.com/Azure/application-gateway-kubernetes-ingress/issues/1015
Fully-managed Application Gateway	Much like AKS AGW ingress controller, an Application Gateway instance that is fully or partially managed by ACA, which includes automatic route registration for applications. ℹ️ This is currently not supported by Container Apps.
API Management	It is possible to publish your ACA applications using APIM. ℹ️ Internal-only apps (recommended) would require APIM with VNET integration, which requires Premium tier and this can be quite expensive for smaller projects, which can then use a special header for control.
Front Door	As per #402, ACA currently does not support private integration with Front Door.
Container App as ingress	This might not be a recommended approach, but it should be possible to make all your apps internal, and have a single external app that handles traffic using Nginx, Apache, etc. Main benefits here would be a single certificate and domain to manage, and a centralized entry point for security controls. Perhaps there is a Dapr component for this that I'm not aware of.

I couldn't find a native solution within ACA to have a single entrypoint for the applications, but perhaps I'm wrong.

I imagine there are more designs possible, would be great if anyone could add more to this thread.

If it doesn't make much sense to publish a page about this I hope this issue helps anyone looking for more information about pros/cons of such designs with ACA.

These are some of the issues that I found that are related:

• 327

• 8

• 243

• 402

• 97

[tomkerkhove]

Self-Hosted gateway of Azure API Management would be another good addition to this effort where it runs on Azure Container Apps as sole ingress which exposes internal services similar to https://github.com/tomkerkhove/azure-apim-on-container-apps

[onionhammer]

I'm grappling with these same questions right now. More, well documented, options would be very welcome.

[kendallroden]

working on more advanced networking docs and will consider the above requests

[ramrgit]

We are also exploring the same questions right now. @epomatti, thank you for compiling the list above. I wonder if we can implement an Ocelot style gateway as a container app and use DAPR to communicate to the other (downstream) services while only exposing the gateway container app. Any thoughts on the viability of this approach would be greatly appreciated.

[epomatti]

@ramrgit this should be possible with an internal-only environment, where you provide your own subnets. Container Apps instances will then be deployed to a subnet that you control, which should be private. You can then have a public subnet with your Ocelot deployed in it and set the Ocelot routes accordingly. Check this DNS part in the network page, I wonder if would be recommended to use a custom DNS server in this approach (VNET-scope ingress with non-custom domain) and avoid traversing out (?). Open the private subnet firewall ACLs (NSG) to allow traffic between the public and the private subnets.

You'll have to manage the Ocelot routes manually while the Event Grid integration is in the roadmap (check https://github.com/microsoft/azure-container-apps/issues/342)

[chriswangelin]

I would like to advocate for including this issue in the ACA roadmap if it isn't already covered under another issue there. I noticed that @SophCarp has recently added many items to the roadmap, so this seemed like an opportune time to speak up. Having more specific architectural guidance around integrating ACA with the services mentioned in OP would be hugely helpful!

[SophCarp]

Hi @chriswangelin thanks for bringing this to my attention! I'll check in with the team to see what we can do.

[MirzaMerdovic]

I have been struggling with the same questions as raised here by the author and others. Right now we went with running Traefik in an ACA inside a closed environment. The scenario works and we have to manage our own image of Traefik that contains route configurations, which is a bit of a downside. Alas I think it would be super useful for community if this is nicely documented and explained so that users are aware of pros and cons when setting up their environments.

[chriswangelin]

Just discovered a new FastTrack for Azure blog post on integrating Azure Front Door WAF with Azure Container Apps (published 2/1/23). Could be a helpful resource for those of us following this issue.