In today’s rapidly evolving tech landscape, businesses and developers constantly seek more efficient and scalable ways to deploy and manage applications. Azure Container Apps has quickly become a powerful tool in this space, offering a fully managed environment to run microservices and containerized applications on a serverless platform. By simplifying infrastructure management, Azure Container Apps allows you to focus entirely on building your applications.

In the second part of this series, we explored Azure Container Registry—a crucial service for securely storing and managing container images that your Azure Container Apps can use for deployments. Now, in this third part, we will dive into more advanced aspects of Azure Container Apps, focusing on configuring environments, managing ingress, and utilizing managed identities to ensure secure and scalable applications.

Let’s get started!

Key Features and Capabilities of Azure Container Apps

Azure Container Apps provides a wide array of capabilities that help you deploy API endpoints, host background processing jobs, handle event-driven processing, and run microservices. With the ability to dynamically scale based on HTTP traffic, event-driven processing, CPU or memory load, and KEDA-supported scalers, Azure Container Apps ensures that your application can scale seamlessly based on real-time demands.

Benefits of Azure Container Apps:

• Scalability: Dynamically scale based on real-time HTTP traffic or event-driven processing, ensuring resource optimization.
• Flexibility: Deploy public APIs, background jobs, and microservices seamlessly, all in one platform.
• Security: Leverage managed identities to secure your app without dealing with sensitive credentials.
• Ease of Use: Create, configure, and deploy apps without managing the underlying infrastructure, thanks to Azure’s serverless architecture.

Common Use Cases for Azure Container Apps

Azure Container Apps simplifies the deployment of containers by abstracting the complexities of infrastructure management. Here are some common scenarios where you can leverage Azure Container Apps:

• Public API Endpoints: Deploy API endpoints that can be scaled automatically based on HTTP traffic. Traffic splitting across multiple revisions ensures zero downtime while deploying new features.
• Background Processing: Use Azure Container Apps for tasks such as transforming data, processing large jobs, or executing scheduled background jobs.
• Event-Driven Processing: Handle event-driven workloads with ease by deploying apps that respond to messages in queues or topics. Azure Container Apps allows you to scale based on the number of events being processed.
• Microservices: Deploy and manage microservice architectures. With Dapr integration, Azure Container Apps makes it easier to connect and manage microservices, ensuring seamless communication and scaling.

Real-World Example:
Imagine you’re managing an e-commerce platform that handles thousands of transactions per second during peak sales periods. Azure Container Apps can seamlessly scale your API endpoints and backend services based on real-time traffic, ensuring zero downtime and optimal performance. Plus, with Dapr integration, your microservices communicate efficiently, allowing smooth order processing and inventory management.

Setting Up Your Azure Container App Environment

Let’s dive into creating and configuring your Azure Container Apps environment. Azure Container Apps can be found in the Azure Marketplace under the Containers category, or you can simply search for “Container App” in the Azure portal.

1. Creating a Container App:
   • You need an existing container registry resource (such as Azure Container Registry) to specify your container image.
   • Each container app instance resides within a Container App Environment, which provides an isolated network for your apps to communicate with each other.
   • The Container tab on the Create Container App page provides the option to use a quickstart image, or to specify an image in a repository. When specifying an image, you provide information in three sections: Container details, Container resource allocation, and Environment variables.
   • The Bindings tab can be used to connect your container app to other Azure resources. Bindings are optional but can be used to provide additional functionality.
   • The Ingress tab can be used to enable ingress for applications that need an HTTP or TCP endpoint.
   • The Tags tab can be used to specify name/value pairs that enable you to categorize resources and view consolidated billing by applying the same tag to multiple resources and resource groups. If you create tags and then change resource settings on other tabs, your tags will be automatically updated.
   • The Basics tab on the Create Container Apps Environment page is used to name the environment and provides the option to enable zone redundancy.
   • The Workload profiles tab on the Create Container Apps Environment page can be used to add dedicated workload profiles.
   • The Monitoring tab on the Create Container Apps Environment page provides option for specifying monitoring and logging preferences.
   • The Networking tab on the Create Container Apps Environment page provides the option of selecting your own virtual network.

2. Configuring the Environment:
   • Start by naming your environment and setting zone redundancy options.
   • Configure workload profiles to support different app configurations, such as dedicated or consumption-based profiles.
   • Set up monitoring and logging to ensure you are capturing metrics that help with debugging and performance optimization.
   • Choose your virtual network, ensuring that it is in the same region as your environment. This allows seamless communication between your container apps.

2. Networking Options:
   • You can configure networking options, such as using a private virtual network or exposing your app through an external endpoint with ingress enabled.
   • If you prefer tighter security, use internal ingress to restrict access to your container app within the virtual network.
   • The Networking tab provides the following options:
     • Use your own virtual network: Select Yes to use your own virtual network.
     • Virtual network: Select your virtual network from the dropdown. Only networks located in the same region as the container apps environment are listed.
     • Infrastructure subnet: Select the subnet that you’ve prepared for your container app.
     • When using the Consumption only Architecture for Azure Container Apps, you must use a dedicated subnet with a CIDR range of /23 or larger.

Secure Your Apps: Leveraging Managed Identities

Security is a critical aspect of any application deployment, and Azure Container Apps simplifies security by providing Managed Identities. Managed Identities allow your container apps to authenticate with Azure services without the need to manage credentials.

• System-Assigned Managed Identities: These are automatically created with your container app and deleted when the app is deleted. This simplifies access to resources such as Azure Key Vault or Azure Storage.
• User-Assigned Managed Identities: These are created independently and can be shared across multiple resources, making them useful for complex scenarios requiring consistent identity management.

With Managed Identities, your app can securely interact with services such as Azure Container Registry, eliminating the need for hard-coded credentials. Additionally, Managed Identities can be used to authenticate Dapr-enabled applications, further enhancing the security and scalability of microservices.

Mastering Ingress and Scaling for Seamless Operations

Azure Container Apps allows you to expose your container app to the public web, your virtual network (VNET), and other container apps within your environment by enabling ingress.

Ingress is the entry point for traffic to your container app. Azure Container Apps allows you to expose your container apps to the public web or a private virtual network, depending on your security requirements. You can configure external ingress for public access or internal ingress to limit access to within the container app environment.

When you enable ingress, you can choose between two types of ingress:

• External: Accepts traffic from both the public internet and your container app’s internal environment.
• Internal: Allows only internal access from within your container app’s environment.

Each container app within an environment can be configured with different ingress settings. For example, in a scenario with multiple microservice apps, to increase security you could have a single container app that receives public requests and passes the requests to a background service. In this scenario, you would configure the public-facing container app with external ingress and the internal-facing container app with internal ingress.

There are two types of Ingress:

HTTP Ingress: Offers features such as TLS termination, support for HTTP/1.1 and HTTP/2, WebSocket, and gRPC, ensuring secure communication for your apps. With HTTP ingress enabled, your container app has:

• Support for TLS termination
• Support for HTTP/1.1 and HTTP/2
• Support for WebSocket and gRPC
• HTTPS endpoints that always use TLS 1.2, terminated at the ingress point
• Endpoints that expose ports 80 (for HTTP) and 443 (for HTTPS)
• By default, HTTP requests to port 80 are automatically redirected to HTTPS on 443
• A fully qualified domain name (FQDN)
• Request timeout is 240 seconds

TCP Ingress: Suitable for internal communication between apps within your environment, TCP ingress allows direct access to your container apps via port and IP.With TCP ingress enabled, your container app:

• Is accessible to other container apps in the same environment via its name (defined by the name property in the Container Apps resource) and exposed port number.
• Is accessible externally via its fully qualified domain name (FQDN) and exposed port number if the ingress is set to “external”.

Scaling is an essential feature of Azure Container Apps. Based on HTTP traffic, event-driven processing, or CPU/memory load, your apps can scale dynamically, ensuring that resources are utilized efficiently. Azure Container Apps integrates with KEDA scalers, providing automatic scaling options that match your app’s demands.

Conclusion

Azure Container Apps not only makes managing containerized applications easy, but it also provides a flexible and secure foundation to scale your applications as your business grows. By leveraging managed identities, fine-tuning ingress configurations, and capitalizing on dynamic scaling, you can ensure that your applications are ready to handle any demand.

Stay tuned for our next post where we’ll uncover advanced configurations and best practices that will take your containerized applications to the next level. In the meantime, start experimenting with Azure Container Apps today and discover how it can transform your application deployments!