So let's see the pricing in there then.

Requests

Container Apps are billed based on total number of requests executed each month. Executions are counted each time an app is executed in response to an HTTP request or an event. The first two million requests are included free each month.

Resource consumption

Container Apps are billed based on resource consumption measured in vCPU seconds and gibibyte seconds (GiB-s). The first 180,000 vCPU-seconds and 360,000 GiB-seconds each month are free. Active usage occurs while your container is starting or while there is at least one request being processed by the application. By default, applications scale to zero. You can also configure Container Apps with a minimum number of instances to be always running in idle mode. Idle usage is charged at a reduced rate when the application isn’t processing any requests.

Doesn't sound so bad, free grants and pricing per seconds, seems fair.

How to create your own?

I will go thru the process with pics. Find container apps from search.

And create your first app.

Choose your subscription and create a resource group or use existing. Then create App environment.

The apps environment will Log analytics so you can again use existing or create a new one.

And then monitoring (Log Analytics)

Then you will have a possibility to create from template (all time favorite "Hello World!")

As you can see it will publish externally with HTTP, so use only for demo purposes, right? Right.

Building it for the real deal

If you want to go full metal jacket at-first glance you can. You have two options choose ACR.

or Docker hub and other registries.

Resource allocations

you have these to choose from in all the configs.

Ingress (incoming traffic)

I don't know who invented Ingress and Egress but haven't ever understood why they cannot be something more common sense, like incoming and outgoing, go figure.

Well to Ingress. You have option to Disable or Enable incoming traffic (Ingress!) and to hide it to your virtual network only or to accept traffic from anywhere.

Or you have multiple vNet's you can use peering between them to allow the traffic from vnet to vnet.

Creating and provisioning will take some time but when it's done, you will displayed the following.

Modifying deployment properties

Inside the deployment you can edit the properties. Like secrets, Continuous development and revisions.

Secrets are key/value pairs than can be used to protect sensitive data like passwords and connection strings. Secrets that you store here will be valid across all your revisions. Note that changing secrets will not create a new revision.

You can setup GitHub Actions to automatically build and deploy your code to your Container App. Note that every deployment will create a new revision.

But also modify the incoming traffic settings.

As I will do a demo, I will change target port to 443

Then to revisions.

Each revision is a variation of your container app that can have different settings for traffic allocations, autoscaling or Dapr. Create a new revision to make changes to your app.

Choose a revision mode.

Choose a suffix for the revisions.

Then you enable or disable Dapr which is Distributed Application Runtime. This runtime helps build resilient, stateless, and stateful microservices.

Azure Container Apps offers a fully managed version of the Dapr APIs when building microservices. When you use Dapr in Azure Container Apps, you can enable sidecars to run next to your microservices that provide a rich set of capabilities. Available Dapr APIs include Service to Service calls, Pub/Sub, Event Bindings, State Stores, and Actors.

Log Analytics

With analytics we can see the traffic and possible problems with the app.

But as the logs will be populated 12 to 24hrs after provisioning I have to take an arrange check with showing these.

But just like what ever Azure service using KQL queries, it will display logs based on filters.

Trying out my new container app

And success! I even have a certificate for my container and it was provisioned only with changing the ingress (incoming port)

Finalizing this post

Azure Container Apps is one excellent feature for your Serverless continuous deployments but not the only one.

Here a Microsoft documentation comparing the solutions, after that one you have hopefully decide which one to choose.

Comparing Container Apps with other Azure container options

Understand when to use Azure Container Apps and how it compares to d container options including Azure Container Instances, Azure App Service, Azure Functions, and Azure Kubernetes Service.

Ps. It probaply still is in preview, altough it doesn't say anything of this in Azure portal.

Share this: