For those who haven’t seen it yet, Microsoft this week announced Azure Container Instances which is a new way of delivering Container instances on Azure.
Up until now Microsoft has had the ability to deliver Containers on Azure using Azure Container Service, where we specify which kind of orchestration engine we would like to use and specify the amount of worker nodes (virtual machines) we would like to have. Then we were bound to that amount of virtual machine instances and the containers running on top of those virtual machines.
Azure Container Service is a free service on its own, but we are billed by the amount of virtual machines we are using underneath all the containers runnings per minute. That also means that the virtual machines that are being used by Azure Container Service is part of our responsibility.
So this means that if we have 10 virtual machines in a Kubernetes cluster but we are only using a limited amount of nodes it means that we need to pay for all virtual machines per minute. So not really cloud native right?
Now this is the cool part about Azure container Instances is that we do not actually need to think about the underlying virtual machines, all we need to care about is the container itself. 
The containers are billed per second they are running, instead of per minute which VM’s are which of course will allow for even greater flexibility.
Now unlike Azure Container Services, ACI is not linked to a specific Container orchestration solution so this will require you to use Azure specific commands and not reuse the existing kubernetes commands you are used to right? Well Microsoft has understood that Kubernetes is the right approach and have therefore created a Kubernetes Connector to ACI –> https://github.com/azure/aci-connector-k8s which allows us to use Kubectl against Azure Container Instances.
It does this by
* Registering into the Kubernetes data plane as a Node with unlimited capacity
* Dispatching scheduled Pods to Azure Container Instances instead of a VM-based container engine
So now Microsoft is quite serious about Containers and moving forward, ACI will also support Windows Containers, one might wonder how Microsoft does segmentation of tenant workloads on the virtual machines that run underneath. Microsoft has quite a good range of different services for different workloads now.
Now as mentioned since this is in preview there are some limitations still
- * Only Linux containers are supported at the moment
- * Not possible to attach a container to a virtual network.
- * Use of ACS is currently only through the Azure Cloud Shell or using Azure Resource Manager templates.
- * There are some limitations both on region availability and the size of containers in a region.
Create the Resource Group in Location West Europe and Container
az group create –name myResourceGroup –location westeurope
az container create –name mycontainer –image microsoft/aci-helloworld –resource-group myResourceGroup –ip-address public
Connect to the URL and we come to this page
Delete the container:
az container delete –name mycontainer –resource-group myResourceGroup
Container Groups
Azure Container Instances also support the deployment of multiple containers onto a single host using a container group. This is useful when building an application sidecar for logging, monitoring, for instance. We can do group based container deployment using an ARM template. Here we can also define the CPU and Memory specifics for each container.
az group create –name myResourceGroup –location westus
az group deployment create –name myContainerGroup –resource-group myResourceGroup –template-file azuredeploy.json
{
“$schema”: “https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,
“contentVersion”: “1.0.0.0”,
“parameters”: {
},
“variables”: {
“container1name”: “aci-tutorial-app”,
“container1image”: “nginx”,
“container2name”: “aci-tutorial-sidecar”,
“container2image”: “nginx”
},
“resources”: [
{
“name”: “myContainerGroup”,
“type”: “Microsoft.ContainerInstance/containerGroups”,
“apiVersion”: “2017-08-01-preview”,
“location”: “[resourceGroup().location]”,
“properties”: {
“containers”: [
{
“name”: “[variables(‘container1name’)]”,
“properties”: {
“image”: “[variables(‘container1image’)]”,
“resources”: {
“requests”: {
“cpu”: 1,
“memoryInGb”: 1.5
}
},
“ports”: [
{
“port”: 80
}
]
}
},
{
“name”: “[variables(‘container2name’)]”,
“properties”: {
“image”: “[variables(‘container2image’)]”,
“resources”: {
“requests”: {
“cpu”: 1,
“memoryInGb”: 1.5
}
}
}
}
],
“osType”: “Linux”,
“ipAddress”: {
“type”: “Public”,
“ports”: [
{
“protocol”: “tcp”,
“port”: “80”
}
]
}
}
}
],
“outputs”: {
“containerIPv4Address”: {
“type”: “string”,
“value”: “[reference(resourceId(‘Microsoft.ContainerInstance/containerGroups/’, ‘myContainerGroup’)).ipAddress.ip]”
}
}
}
What about persistent storage options for ACI containers? Microsoft has already made some documentation on how to add persistent storage to ACI containers which can be found here –> https://docs.microsoft.com/en-us/azure/container-instances/container-instances-mounting-azure-files-volume
More info to come.