Windows containers Adventure: container storage



The core technology of container technology is tiered storage. Under Linux, the relevant files are stored in / var / lib / docker by default, while after installing docker for windows under Windows 10, the default storage files are placed in C: \ programdata \ docker. You can modify the default storage location by setting docker root in the configuration file. Then, even if you know the actual storage location of the files, you are not recommended to modify the files manually. These files are under the refined management of docker.

Technical details

Default C disk space size

By default, the size of the mirrored disk C of Microsoft / windowsservercore: 1803 is 20g. We can enter the container through the following command, and then confirm with PowerShell command.

docker run --rm -it microsoft/windowsservercore:1803 powershell
Get-CimInstance -Class Win32_Volume | select DriveLetter, @{Name="CapacityInGB"; Expression={$PSItem.Capacity / 1GB}}, @{Name"FreeSpaceInGB";  Expression={$PSItem.FreeSpace / 1GB}}

The output of the command is as follows:

DriveLetter     CapacityInGB    FreeSpaceInGB
-----------     ------------    -------------
C:          19.8740043640137 19.7209014892578

If the default size cannot meet the remaining space check conditions of some software, you can use — storage opt “size = 50GB” to modify it when docker runs, and then run the previous PowerShell command again for confirmation.

DriveLetter     CapacityInGB    FreeSpaceInGB
-----------     ------------    -------------
C:          49.8740005493164 49.7309150695801

Persistent storage volume

In windows, there are several ways of persistent storage of containers, such as bind mounts and named volumes, and SMB shared folders are also supported in bind mounts.

Bind Mounts

When using bind mounts, we need to pay attention to permissions. When the container is running in Hyper-V isolation mode, the container accesses the host folder through the localsystem account, and provides simple read-only and read-write access models. If you find that you do not have permission to access the host folder, you only need to increase the access permission of localsystem on the host folder.

When the container is running in the process isolation mode, use the process related account in the container for operation. By default, Microsoft / windowsservercore uses containeradmin, while Microsoft / nanoserver uses containeruser to access host folders. However, containeradmin and containeruser only exist in the container environment, so authenticated users need to be used when configuring permissions on the host. It should also be noted that if the host folder contains symbolic links, the symbolic links on these hosts are resolved in the container, so they cannot be accessed in the container.

The following is an example of bind mounts. After the container is started, the hostname is written to the mounted storage volume through the hostname.

docker run --rm -it -v c:/apps/dockerdata:c:/data microsoft/nanoserver:1803 cmd
hostname > c:\data\hostname.txr

SMB Mounts

At present, SMB mounts supports traditional file servers and services on the public cloud. The traditional servers here also include servers that support iSCSI protocol. This means that you can create a new file server using iSCSI target and then establish a link through the iSCSI initiator. Then set the drive letter. The iSCSI target of daemon tools, an old tool manufacturer, is used in the local test. After mounting and specifying the drive letter, you can start using the mounted storage volume in the container.

Windows containers Adventure: container storage

Named Volume

Both of the above methods use the – V parameter to specify the local folder to be mounted or mapped to the local remote storage when docker runs. You can also create a named volume through docker volume create, and then mount it using the specified name instead of the local folder path.

For example, you can use the following command to create named volume

docker volume create app1_mysql_data

Then use docker inspect to check the actual storage location of the data

$ docker volume inspect app1_mysql_data
        "CreatedAt": "2018-06-10T13:41:39+08:00",
        "Driver": "local",
        "Labels": {},
        "Mountpoint": "C:\\ProgramData\\Docker\\volumes\\app1_mysql_data\\_data",
        "Name": "app1_mysql_data",
        "Options": {},
        "Scope": "local"


Today, we discussed the details and knowledge points related to windows container storage. Because the data in the container is lost after the container is destroyed, reasonable configuration of storage volume will help us realize data persistence.