10,000. A container with a cpu-share of 1,000 would get twice the CPU resources of a
container with a cpu-share of 500. To use this, I would add the --cpu-shares
as part of the docker run command. For the full list of possible constraints that will
likely be implemented in Windows containers over time, see
https://docs.docker.com/engine/reference/run/#/runtime-constraints-on-resources.
Understanding Storage for Containers
Container instances should be considered stateless, with any data within an instance
considered transient and not stored in a persistent manner. Every time a container is
deleted and re-created, any data that is not part of the image will be lost as each
instance gets a new, clean scratch space.
Often we talk about storage as pets or cattle. We say that traditional servers are like
pets that we name, care for, and heal if they are sick. Storage in the new cloud service
model is like cattle; if cattle are sick, they are shot and new cattle are stood up in their
place—something for which Nano Server is specifically designed. Well, in that analogy
a container is a chicken, and you don’t even bother to brand it—the chickens just run
around, and you don’t give them any thought at all. Therefore, the container is not a
good fit for persistent storage unless a container instance is committed to create a new
image, which is uncommon. What if persistent storage is required?
Volume mappings allow a volume on the host to be connected to a container instance
when it starts in either a read-only or read-write mode. Multiple container instances
can connect to the same container host volume.
This use of volume mappings is achieved by using the -v parameter and specifying the
folder location to which it will be mapped in the container instance and the target
location on the contain host filesystem. For example, the following line maps a folder
in the container instance named c:\data to the contents in the d:\ContainerData
folder on the host. Inside the container instance, it would be able to interact with
c:\data as if it was local content. Any data written is written directly to the folder on
the container host filesystem and is therefore persisted.
docker run -v d:\ContainerData:c:\data
By default, the volume mapping is read-write. However, if read-only mode is required,
append :ro to the end; for example:
docker run -v d:\ContainerData:c:\data:ro
A full example using the earlier demosite container image and enabling interaction
would be the following. Once inside the container, I would be able to navigate to
c:\data, which would show the data storage in the c:\containerdata folder on my
actual container host.
docker run --name demo1 -it -v C:\containerdata:c:\data demosite cmd.exe
Another option is to use traditional network-based storage, such as an SMB share that