The intention of this post is to create Azure Container Apps deployment and to explain how it differentiates to Azure Container Instances for this specific context
In this post, I’d like to show, how to create a deployment of an Azure Container App – using a customized Container Image, which is managed by an Azure Container Registry. To figure out the most obvious differences within the scope of a first deployment in contrast to Azure Container Instances, I’m going to create a deployment of an Azure Container Instance in addition – using the very same Container Image.
This post is also about to risk a (not complete) comparison between the Azure Container Apps and the Azure Container Instances. Both are Azure Services, both are about Container Services – to run your Container in the Cloud without taking care about the infrastructure behind – that’s managed for you. But what about the differences? When should you use the Container App, when should you use the Container Instance? That’s what I’d like to answer in this post with regard to my humble opinion.
It starts with a chapter about the deployment of an Azure Container App using a Linux Container Image, the next chapter is about using the same Container Image for deploying an Azure Container Instance. After that, the differences between those two Azure Services are explained and finally the post ends with a conclusion.
2. Container Apps Deployment
The Azure Container Apps service allows you to run your Container in the Cloud – without the need of provisioning an infrastructure like e.g.: a Kubernetes Service (from the user perspective ;)). This means you can start immediately to deploy and host your Container to the Cloud – including a lot of additonal functionalities. Let’s see how this lightweight approach works.
Before that, I’d like to refer to the customized Container Image, I’d like to use.
2.1 The customized Container Image managed by the Container Registry
I’ve created a simple Linux Container, which just prints “Hi, I’m your Linux Container!” at runtime. The corresponding Container Image is pushed to my Container Registry named “blogdemoregistry” – which can be seen in the picture below:
I’m going to use this Container Image for the Azure Container App deployment and for the Azure Container Instance deployment.
If you don’t have a proper customized Container Image available, then you can use the Quick-Start Images for a first try of course.
2.2 Deployment of a Container App with a customized Image
Now it’s about creating and using the Azure Container Apps service. In my Azure Portal, I’m just searching for “container app” and I’m going to select the following icon:
After that, I continue with the creation of a deployment with clicking at the “Create” button:
The following dialogue is about providing the basic information for your deployment:
- Subscription: if you’ve several Azure subscriptions – from which subscription should the Container App be part of?
- Resource group: which resource group would you like to assign the Container App? You can create a new one, if you don’t already created one.
- Container app name: The name of your Container App – in my case “patrickscontainerapp”
- Container Apps Environment: a Container App Environment can contain multiple Container Apps. Assign those Container Apps to one specific Environment, if you’d like to enable e.g.: communication between the Container
I don’t have created a proper Container App Environment so far, therefore I select “Create new” at “Container Apps Environment”:
I’d like to name my Container App Environment “patrickscontainerappenv” – as region I choose “West Europe” as I’m located in Austria (Azure datacenter region in Austria is planned ;))
Finally, the basic information is entered.
Now the basics are done, so I switch to “App settings”. As I’d like to use my own Container Image, I’ve to uncheck “Use quickstart image”.
The following three dropdown menu items, are about to select:
- the Azure Container Registry, which contains the specific Container Image: in my case it’s “blogdemoregistry.azurecr.io
- the Image – “myrepo”
- the Tag – “mylinuxcontainer”
For my first deployment of the Container Apps, I’ll just discover the main functionality, I’ll skip the last two columns and trigger the creation of that deployment.
Finally, the deployment is done:
The Azure Container Apps deployment named “patrickscontainerapp” is finally done:
But what’s now? I’d like to try the probably most interesting functionality – the scaling of the Container App: therfore I click at “Scale”…
…and I choose three replica instances as minimum…
…and I’m going to create the deployment of the new revision:
After completing the deployment of the revision, I’d like to verify that really three instances of my Container are running. Therefore, at first I’d like to observe the Logs and I select “Log stream”:
At this menu item, all replicas can be chosen, which are deployed due to the scaling rule and the logs of the Container should be revealed. In my case, I expect the output “Hi, I’m your Linux Container”….and the Container App logs don’t disappoint me:
So, I proved that three replicas are running and I could verify the logs. Despite from that, I’d like to attach to one of those replica. For that, I’ll click at “Console” and I pick an instance by choosing it from the dropdown menu…
…after attaching to the Container, I’ll enter the file system and call the script, which is defined as Entry Point of the Container, which again provides the expected log:
2.3 Conclusion of the Container Apps Usage
Azure Container Apps is a great Azure service, if you would like
- to deploy your Container in the Cloud in a quickly and easy manner and
- if it is your goal to scale them and
- if you’d like to use multiple Container, which should be able to communicate with each other and
- without the provisioning an infrastructure like a Kubernetes Service.
So, this service manages the deployment in the background for you – just provide the necessary information about the (among others) Container Image, which you’d like to choose and you are almost done. After that, you can apply scale rules, in addition observing the logs and metrics.
In my example, two resources are created:
Currently, there is no Windows Container Support, so you can deploy Linux Container only with Azure Container Apps, but there exists a Feature Request:
I’ve also tried to share some details, why we would prefer to have Windows Container support for the Azure Container Apps:
3. Container Instances Deployment
In contrast to the Azure Container Apps, let’s create an Azure Container Instances deployment to find some major differences between those two services.
3.1 Deployment of a Container Instance with a customized Image
Again, I’m searching for the service – in that case the Azure Container Instances – in the Azure Portal:
I’m selecting “Container instances” and again I get a dialogue for inserting the basic information:
- which subscription/resource group I would like to use
- the name of the Container – I’m going to name it “patrickscontainerinstance”
- the region
- the source of the Container Image – it is again the same Azure Container Registry, which I’ve used for the deployment of the Azure Container Apps. In addition of course I’m using the same Image and Tag.
Consider, that the OS type is stated as Linux. At this point, I’d like to refer to the first major difference with regard to the Azure Container Apps: Azure Container Instances are also capable of deploying Windows Container.
After that, I’m going to trigger the deployment of the Azure Container Instance:
After a few minutes, the Azure Container Instance, named “patrickscontainerinstance” is ready:
For Linux Container, the deployment should be done within a few minutes, be aware that Windows Container would take a few minutes longer, as they Image file size is bigger. To get the Container in a running state, the corresponding Container Image has to be downloaded – as mentioned this takes longer for Windows Container Images.
Finally, the Linux Container is running:
Similar to the Azure Container App, I can observe the logs:
In addition it os also possible to attach to the Container, to get to it’s file system and running the “start.sh” script manually:
In contrast to the Azure Container Apps and to refer to a next major difference, it is not possible to scale the Container. There exists no dedicated functionality with regard to apply scaling rules.
3.2 Conclusion of the Container Instances Usage
From my point of view, Azure Container Instances should be used if you’d like to test whether your Container can be deployed and hosted in the Cloud – a rather simple and clear requirement.
Imagine you are starting almost from scratch with regard to your knowledge about Kubernetes and the proper Workload deployment rules and your goal is to deploy your Container at a specific Kubernetes cluster: there are that many pain points, which you could face. If you are not that experienced yet and you just would like to ensure that you Container is ready to be hosted in Azure without the need of scaling it: risk a first try with Azure Container Instances.
Azure Container Instances manages the infrastructure behind – same as for the Azure Container Apps – just pick your desired Container Image and the service manages almost everything for you. So you can ensure that the Container runs in the Cloud, providing the arguments in a proper way (see “Command override”).
So, this service serves well as first lightweigth starting point to migrate your Workloads to the Cloud.
4. Container Apps vs. Container Instances in this context
In this section, I’d like to refer to the differences between those similar Azure Services for this specific context – to create a deployment of a customized Container Image in a fast and simple way as a very first try.
Both services suit well, if you would like to deploy/host your Container in the Cloud and if you’d like to avoid to provision a more complex infrastructure as e.g.: a Kubernetes Service. As a prerequiste: make your Container Image be accessible at a Container Registry, this could be a private or a public registry. I’d recommend to push the Container Image to an Azure Container Registry – as the Image can be easily selected from the dropdown menu without entering the mandatory credentials when using e.g.: a private registry.
Despite from that, use a Container App in contrast to a Contaiener Instance if:
- you would like to scale your Container
- you would like to deploy multiple Container from different Container Images, which should be able to communicate with each other (see “Container App Environment”)
Use a Container Instance in contrast to a Contaiener App if:
- you would like to to run a single Container in the cloud only
- you would like to use Windows Container Images, as Azure Container Instances are capable of deploying Windows Container – that is currently restricted for the Azure Container Apps.
That’s of course not a complete list of differences. The intention of this post is to refer to the most obvious differences with regard to a very first deployment.
Please consider the features of both services to get more details:
Azure Container Apps are now GA and further features are already requested as:
the support of Windows Container:
the support for a new Terraform resource:
Looking forward to both of them.
This blog featured as part of Azure Week. Find more great Azure content here.
About the Author:
Hi, my name is Patrick Koch, I’m a “Senior Integration Engineer Software”, working in the Automotive Industry. I love to practice DevOps and would like to share my experiences, which include especially implementations and best practice approaches related to:
- Cloud (Azure, AWS, GCP)
- Infrastructure as Code (Terraform)
- Kubernetes (Azure Kubernetes Service, Rancher)
- Containerization (Docker)
- CI/CD (Azure DevOps Server)
Koch, P. (2022). Azure Container Apps – Deployment with a customized Container Image and a Comparison to Azure Container Instances. Available at: https://www.patrickkoch.dev/posts/post_18/ [Accessed: 23rd June 2022].