Introduction to Azure Container Instances

Azure, Containers

Microsoft today released a public preview of a new service, Azure Container Instances. This may seem confusing initially, Azure already has a container service called Azure Container Services (ACS), but this is a somewhat different offering. ACS is a full container hosting solution, including orchestrators, deployed on top of multiple IaaS based Azure Virtual machines. Azure Container Instances (ACI) is not an orchestrator, it is a platform for deploying containers quickly and  simply. The exciting difference with ACI is that containers are now a first class object in Azure, using ACI you can just deploy a container object, there is no need to deploy and manage VMs to host your containers, you simply specify the size of the container your require without having to care about the underlying VMs or storage.

This simple container as service offering should be useful to those looking to quickly spin up a container without having to worry about infrastructure behind it, but what is even more exiting is the potential to provide a platform as a service offering to be used by orchestrators for providing containers (see later in this article).

In this article we’ll take a look at some of the basics of this service, how it can be used and it’s limitations.

Limitations

ACI is in preview, so there are some limitations on what you can do with the service

ACI went GA in April 2018.

Isolation

Containers are run on the host machine using HyperV isolation, so that container instances are as isolated as virtual machines in Azure. This should mean containers offer the same level of security and performance isolation from other users sharing the same host,

Creating a container

Creating a container is a single line command in  cloud shell, with various option. At a minimum you need to specify the name to use for the container, the image you want to use (can come from Dockerhub or a private registry), the resource group to store this in, and if you want a public IP the ip-address option. Note that your container name needs to be lower case, otherwise you’ll see an error.

az container create –name helloworld –image microsoft/aci-helloworld –resource-group containertesting –ip-address public

This creates a new container with the default size of 1 CPU and 1.5GB memory. It adds a public IP and exposes port 80.

As mentioned, there’s no interface in the portal for containers, so if you look in your resource group you will see the object you created, but there is very little you can do with it in the GUI.

Once your done with container you can delete it with the container delete command

az container delete –name helloworldcontainer –resource-group containertest

As mentioned containers can also be deployed using ARM templates, you can find some examples here.

Container Sizes

Unlike virtual machines, containers aren’t restricted to pre-set sizes, you can choose at deployment time the amount of CPU cores and Memory. To specify these ammend your command to include the cpu and memory commands:

az container create --name helloworld --image microsoft/aci-helloworld --resource-group containertest --cpu 2 --memory 4 --ip-address (public

I have seen some errors when deploying larger size containers in certain regions (mainly West Europe), so I suspect there are some limits in place for the preview. Larger sizes in East US seemed to work fine. I’ve not yet been able to find documentation of how big your containers can get.

Data and Persistence

As mentioned, it’s not currently possible to connect an container to an Azure virtual network so using local network resources for persisting data is not possible. Container instances do offer the ability to mount Azure file shares for persistent data, with plans to add Azure disks in the future.

I’ve not yet been able to get hold of the documentation for how to attach file shares, I will update this article when I have that.

Alternatively, if your data can be stored in a database you can  make use of public services like Azure SQL, Cosmos DB or Table storage.

Container Groups

ACI has the concept of container groups, these are multiple containers which  are deployed to the same host and share the same network and any mounted volumes, the concept is similar to Kubernetes pods. Container groups need to be deployed using an ARM template rather than through the cloud shell, you can see an example of this here.

Orchestration

As already mention, ACI is not an orchestator, it’s a tool for providing easy deployment of indvidual VM’s. However, ACI is intended to be used with orchestrators, theorchestrator can utilise ACI as the method of provisioning VMs and not have to care about managing hosts. ACI comes ready with an example (experimental) connector for Kubernetes and I am sure further down the line we will see these for other orchestrators.

Pricing

Container pricing is a bit more complex than VM’s, your charged on 3 metrics

  • Create request – a one of fee for each creation of a container, currently $0.0025 in the East US region
  • Memory Usage – The amount of memory used by each container per second. Billed at 0.0000125 per GB per second
  • CPU Usage – The amount of CPU cores used by each container per second. Billed at $0.000013 per core per second

so a container created once with 2 cores and 2GB memory, running for an hour would cost

0.0025 +((0.0000125 * 3600)*2) + ((0.000013 * 3600)*2)=$0.1861