Thursday, November 30, 2017

Azure Container Instance (1): Introducing ACI EmptyDir Volumes

A new type of volume named emptyDir was supported in Azure Container Instance since version 2017-10-01-preview.

What is emtyDir volume?

As the name hints, an emptyDir volume is initially empty. Containers in a container group can all read and write the same files in the emptyDir volume, though that volume can be mounted at the same or different paths in each container. When a container group is deleted for any reason, the data in the emptyDir is deleted forever.

When to use emptyDir volume?

The emptyDir is very useful when we are going to save service states or share data among containers in a container group. The following are some example scenarios to employ emptyDir volumes:
(1) scratch space, such as for a disk-based merge sort;
(2) checkpointing a long computation for recovery from crashes;
(3) holding files that a content-manager container fetches while a webserver container serves the data;

How to use emptyDir volume?

First an emptyDir object without any properties is added into the volumes array of the container group, and then a volume mount is added into the volumeMounts of a container. The name of volume mount should match the name of the volume.

The following is an example container group definition in JSON:

{
  "properties": {
    "containers": [
      {
        "name": "demo1",
        "properties": {
          "command": [],
          "image": "nginx",
          "ports": [
            {
              "port": 80
            }
          ],
          "resources": {
            "requests": {
              "cpu": 1,
              "memoryInGb": 1.4
            }
          },
          "volumeMounts": [
            {
              "name": "sharedvolume",
              "mountPath": "/var/log/nginx",
              "readOnly": false
            }
          ]
        }
      },
      {
        "name": "demo2",
        "properties": {
          "command": [
            "bin/bash",
            "-c",
            "while sleep 5; do cat /mnt/input/access.log > /mnt/azurefile/test.txt; done"
          ],
          "image": "centos:7",
          "resources": {
            "requests": {
              "cpu": 1,
              "memoryInGb": 1.4
            }
          },
          "volumeMounts": [
            {
              "name": "sharedvolume",
              "mountPath": "/mnt/input",
              "readOnly": true
            },
            {
              "name": "azurefile",
              "mountPath": "/mnt/azurefile",
              "readOnly": false
            }
          ]
        }
      }
    ],
    "osType": "Linux",
    "ipAddress": {
      "ports": [
        {
          "protocol": "TCP",
          "port": 80
        }
      ],
      "type": "Public"
    },
    "volumes": [
      {
        "name": "sharedvolume",
        "emptyDir": {}
      },
      {
        "name": "azurefile",
        "azureFile": {
          "shareName": "<YourAzureFileShare>",
          "storageAccountName": "<YourStorageAccountName>",
          "storageAccountKey": "<YourStorageAccountKey>"
        }
      }
    ]
  },
  "location": "westus"
}

In the JSON definition above, the emptyDir named sharedVolume is mounted into both container demo1 and demo2 where the mounted paths are different. In container demo1, the mounted path is /var/log/nginx. Since the official nginx image creates a symbolic link from /dev/stdout to /var/log/nginx/access.log, the nginx log file is included in the mounted emptyDir volume. When the emptyDir is mounted into container demo2, the nginx log file is also accessible in demo2.

The container demo2 also write the nginx logs into an Azure file. Therefore, when you try to access the nginx web service via browsers, a few lines of logs will be inserted in the container demo1, and container demo2 will read the log and write it into the Azure file. You can check the logs in the Azure file on the Azure portal web site.

AKS (1) - Five seconds latency when resolving DNS

We intermittently meet 5s latencies in an AKS clusters with CNI when it’s resolving DNS. This article is to summarize what we have learned...