Table of Contents
Regardless of whether you work with Docker and containers daily or you are just familiar with it, that technology is something that will be used more and more in the future. The benefits of Docker and containers, in general, are explained so many times, and we will not spend time to do this again. In one of the previous posts, we told how you could use Docker on Azure Virtual Machines and the basics of Azure Container Registry. Still, this time we will focus on Azure Container Instances, which provides containers as a service, without complex managing container infrastructure.
Azure Container Registry – Your private hub for images
Before we start talking about Azure Container Instances, just a few words to refresh mind about Azure Container Registry. Azure Container Registry (ACR) is the fully managed, private hub for your container images, based on the open-source Docker Registry 2.0, that allows you to build, store, and manage container images for all types of container deployments. Although you can use Docker hub as a private repository for your images, if you have a plan to deploy containers in Azure, Azure Container Registry can be a better solution.
Like almost all other Azure resources, you can deploy Azure Container Registry by using all Azure management tools.
Azure CLI
az acr create --resource-group myResourceGroup --name myAcr --sku Basic --location northeurope --admin-enabled true
Azure PowerShell
New-AzContainerRegistry -ResourceGroupName myResourceGroup -Name myAcr -Sku Basic -Location "northeurope“ -EnableAdminUser
ARM Templates
{
"$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"acrName": {
"type": "string",
"minLength": 5,
"maxLength": 50,
"metadata": {
"description": "Name of your Azure Container Registry"
}
},
"acrAdminUserEnabled": {
"type": "bool",
"defaultValue": false,
"metadata": {
"description": "Enable admin user that have push / pull permission to the registry."
}
},
"location": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"metadata": {
"description": "Location for all resources."
}
},
"acrSku": {
"type": "string",
"metadata": {
"description": "Tier of your Azure Container Registry."
},
"defaultValue": "Basic",
"allowedValues": [
"Basic",
"Standard",
"Premium"
]
}
},
"resources": [
{
"name": "[parameters('acrName')]",
"type": "Microsoft.ContainerRegistry/registries",
"apiVersion": "2019-05-01",
"location": "[parameters('location')]",
"tags": {
"displayName": "Container Registry",
"container.registry": "[parameters('acrName')]"
},
"sku": {
"name": "[parameters('acrSku')]",
"tier": "[parameters('acrSku')]"
},
"properties": {
"adminUserEnabled": "[parameters('acrAdminUserEnabled')]"
}
}
],
"outputs": {}
}
Once you have deployed and configured Azure Container Registry, you are ready to push your images to private repositories and use them later for deploying containers.
Azure Container Instances
Over the years, containers becoming the most desirable option to deploy cloud applications. Azure Container Instances (ACI) gives you the ability to deploy containers quickly and easily without having to manage any virtual machines or complex container infrastructure. ACI is an excellent solution for scenarios where you need to deploy isolated containers quickly and easily. In other situations, where you need full container orchestration, Azure Kubernetes Service (AKS) is a solution that we recommend.
It offers many benefits that can help you to focus on application developing instead of managing container infrastructure:
- Fast startup times – ACI can start containers in Azure in seconds, without the need to provision and manage VMs
- Container access – ACI enables exposing of your container and container groups directly to the internet
- Hypervisor-level security – ACI guarantees your application is as isolated in a container as it would be in a VM
- Custom sizes – ACI provides optimum utilization by allowing exact specifications of CPU cores and memory
- Persistent storage – ACI offers direct mounting of Azure Files shares backed by Azure Storage
- Linux and Windows containers – ACI can schedule both Windows and Linux containers with the same API
- Co-scheduled groups – ACI supports the scheduling of multi-container groups that share a host machine, local network, storage, and lifecycle
- Virtual network deployment – Deploying ACI into the virtual network, enables secure communication with other resources in the virtual network, including those that are on-premises
Container groups in Azure Container Instances
A container group is a top-level resource in ACI. The container group represents a collection of containers that run on the same host machine. All containers in a container group share a lifecycle, resources, local network, and storage volumes, similar to the concept of pods in Kubernetes.
Of course, if you deploy only one container, it is implemented as a single container in a multi-container group. At the moment, the multi-container group is supported only for Linux container workloads. For Windows containers, supported is only single container deployment.
Multi-container group deployment
Deploying a single container instance can be performed using all Azure management tools. But, implementing a multi-container group cannot be done using the Azure portal. The multi-container group deploy is possible in two ways: using the ARM template or the YAML file. For the multi-container group deployment, recommended are ARM templates because you can deploy all additional resources, like Azure Files, as persistent storage. At the same time, a YAML file covers deployment that includes only container instances.
Resource allocation
Each single container instance in a multi-container group has resources specified in its resource request. The maximum resources used by container instances can be different and are configured during deployment. The recommendation is that the resource limit of a container instance should be greater than or equal to the mandatory resource request property. The sum of allocated resources, such as CPU, RAM, or GPU, of all container instances in a multi-container group, define allocated resources of a multi-container group. Also, if you don’t specify a container’s resources limit, the maximum resource usage will be the same as its resource request.
Networking
Azure Container Instances – Container groups can share an external IP address, one or more ports on that IP address, and an FQDN. By exposing container group public IP address and specific port, external clients can reach your application that running on container. Inside the multi-container group, container instances talk to each other by using localhost and a specific port. Two container instances in a multi-container group cannot have exposed the same port. Optionally, a multi-container group can be deployed into an Azure virtual network. That allows containers to communicate securely with other resources in the virtual network.
Storage
In some scenarios, your containers in a multi-container group need additional external storage. As additional storage in a multi-container group, you can specify external volumes to mount within a container group. Supported volumes include:
- Azure file share
- Secret
- Empty directory
- Cloned git repo
Deploying containers in a multi-container group
Deploying multi-container groups are useful in scenarios when you want to separate a web application into more small components (containers). The example used in this post is deploying the WordPress website with a separate MySQL database. As mentioned earlier, a multi-container group can be implemented by using ARM templates or the YAML file. The ARM template is a recommended solution if you want to deploy a multi-container group will all needed resources, such as Azure Files as persistent storage.
ARM Template
Download the ARM Template here.
Once the deployment is completed, you can see a multi-container group with two containers.
One container serves publicly exposed the front-end WordPress website, while the second one hosts the MySQL database for the WordPress site. Folders that store WordPress data, as well as the MySQL data, are stored on external Azure Files.
In the end, the result is a fully functional WordPress website that is deployed into Azure Container Instances as a multi-container group, with Azure Files as persistent external storage.
YAML File
The YAML file supports Azure Container Instances and configures a container group that is deploying. That is an excellent option to have a container configuration for reproducible deployments. The YAML file uses as input parameters for the multi-container group deployment, and deploying can be initiated only using Azure CLI. The limitation of the YAML file is that you cannot use this for deploying additional Azure resources, such as Azure File for external storage or virtual network.
type: Microsoft.ContainerInstance/containerGroups apiVersion: 2018-10-01 location: northeurope name: demo-wordpress properties: containers: name: mysql properties: image: mysql:5.7 resources: requests: cpu: 1 memoryInGb: 1 ports: protocol: tcp port: 3306 environmentVariables: name: MYSQL_ROOT_PASSWORD secureValue: myS3cr3tPa55w.rd name: MYSQL_DATABASE value: wordpress_db name: MYSQL_USER value: wp_admin name: MYSQL_PASSWORD secureValue: myS3cr3tPa55w.rd name: wordpress properties: image: wordpress resources: requests: cpu: 1 memoryInGb: 1 ports: protocol: tcp port: 80 environmentVariables: name: WORDPRESS_DB_HOST value: 127.0.0.1:3306 name: WORDPRESS_DB_NAME value: wordpress_db name: WORDPRESS_DB_USER value: wp_admin name: WORDPRESS_DB_PASSWORD secureValue: myS3cr3tPa55w.rd osType: Linux restartPolicy: OnFailure ipAddress: type: Public dnsNameLabel: demo-wordpress-2020 ports: protocol: tcp port: '80' tags: null
When you have prepared the YAML configuration file, you just need to run to following Azure CLI command, to start multi-container group deployment, based on YAML file:
az create container --resource-group myResourceGroup --file myfile.yaml
Once the YAML configuration file is validated, the deployment starts. As a result, you will have deployed WordPress multi-container group, similar to in previous ARM template deployment demo, with one difference. Because the YAML file doesn’t support deploying additional Azure resources, all storage for container instances is located directly in containers.
Conclusion
Azure Container Instances is a great option for deploying various workloads in Azure. Like as other PaaS services, it is managed by Microsoft, so you can focus on application development, instead of managing complex container infrastructure. By implementing a multi-container group, you can separate the workload to a single and small container while staying in an isolated environment. Many other options are on the table, such as virtual network isolation or persistent external storage, and the possibility with Azure Container Instances are not slight. Of course, once your application becomes more prominent and more complex, you need to consider to use Azure Kubernetes Service, as a next level in application containerization in Azure.
