Microsoft recently announced a new offering for Azure called Azure Container Instances. It is essentially a full-blown Container as a Service.
Whenever I introduce people to the concept of Azure Container Services people get excited, until I tell them that they still have to deploy a virtual machine as the host that the containers will run on. This obviously means that you also have to manage and maintain this virtual machine.
MORE: Free Microsoft Azure Online Training Resources You Need
This was unnecessary overhead when all people wanted was to throw a Dockerfile at a service and it would run it, or have an orchestrator like Kubernetes to orchestrate the deployment of containers for us. In principal, people wanted serverless containers.
Enter Azure Container Instances (ACI). It is now exactly what you would expect, a service that executes a container image. It is billed by the second and it is fast.
ACI supports both Linux and Windows containers, but be aware that they are in public preview until August 12, 2017. So, it cannot yet be deployed via the Azure Portal, but only via the CLI or Azure Cloud Shell. I highly encourage Azure users to become comfortable using both the Azure Cloud Shelland the Azure CLI.
ACI – step by step
Container instances can be deployed via the CLI/Cloud Shell or via ARM templates. For this article, we will use the Azure Cloud Shell, as this will have no requirements on the environment you are from which you are running your code. You can, however, execute the same commands from an authenticated Azure CLI running on your computer.
To get started you need to log in to your Azure Portal and launch the Azure Cloud Shell in the upper right corner.
You will then get access to a Bash, yes, Bash environment on Azure. PowerShell will be released soon, but for now you will be running your commands inside of a Linux shell.
The first thing we need to do is create a new resource group. Currently, ACI is only available in a few Azure regions (https://azure.microsoft.com/en-us/regions/), namely westus, eastus and westeurope.
“az group create –name tomsitpro –location westeurope”
The next command will create a few things that we do not then need to deploy ourselves.
“az container create –name grafana-linux –image grafana/grafana –resource-group tomsitpro –ip-address public –port 3000”
Here we are asking Azure to create a new Container Group for us called “grafana-linux”, use the “grafana/grafana” docker image from http://hub.docker.com, add it to our previously created resource group, assign a public IP address to it and expose the port 3000 TCP to the public.
Think of a container group as a collection of containers all running on the same host, sharing a local network, storage and a public IP. A container group can only expose one port on the public IP, but containers running inside of one container group can access each other on ports they expose. Deploying multiple containers into one container group is achieved via ARM templates or external orchestrators like Kubernetes, which just recently received a plugin for ACI.
Accessing a container
Our last command provisioned a new container group and a single container exposing port 3000 on the public IP. 3000 TCP is the port that Grafana listens on by default.
The container will not be available straight away as ACI first has to pull the image down from its repository and then launch the container, but it should not take longer than a minute for Linux containers and maximum 5 minutes for Windows containers.
As a second container I also deployed a Windows based container image via “az container create –os-type Windows –image davidobrien/nanoserver-grafana –port 3000 –resource-group tomsitpro –ip-address Public –name grafana-nano-windows –memory 3.5 –cpu 2”. Windows container groups need at least 3.5GB memory and 2 virtual CPUs.
Now I can run a query against Azure to check the status of my container group and my container:
“az container show –name grafana-nano-windows –resource-group tomsitpro | jq ‘.ipAddress.ip + ” ” + .state'”
You can omit the pipe to “jq” and see the full output from this command, especially check out the “events” property, which shows you what is currently happening. As soon as the state changes to “running” you can connect to the IP address on port 3000 and enjoy using Grafana.
Logs, where are my logs?
Just because things run inside of containers now does not mean we can forget about logs and metrics. At least logs we can already get out of our containers by using the CLI:
“az container logs –name grafana-nano-windows –resource-group tomsitpro”
Now browse to your container IP on port 3000 and check the logs again. Whatever is written to the container’s console is automatically logged to Azure. Do not forget to delete your container when you are done using it.
“az container delete –name grafana-nano-windows –resource-group tomsitpro –verbose”