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.