![]() ![]() The average uncompressed image is 15 x larger that the amount of image data needed for container startup. We observe that only 20MB of data is read on median, but the median image is 117MB compressed, and 329 MB uncompressed. Figure 5 (below) shows a CDF of these three numbers. What ‘start’ means varies by image type: compiling and running or interpreting a simple ‘hello world’ program in the applicable language executing a simple shell command producing the first ‘up and ready’ message to standard out or first response on an exposed port.įor each image, we take three measurements: its compressed size, uncompressed size, and the number of bytes read from the image when HelloBench executes. HelloBench measures the time taken for these images to start. Over half the bytes are at depth of at least nine. Some data is as deep as the 28th level, but mass is more concentrated to the left. The number of files, directories, and bytes were analyzed by layer for these images. Across these images there are 550 nodes and and 19 roots. Using a HelloBench tool that they wrote, the authors analyse 57 different container images pulled from the Docker Hub. The driver creates a new directory in the underlying file system for each layer it stores. The AUFS driver takes advantage of the AUFS file system’s layering and copy-on-write (COW) capabilities while also accessing the file system underlying AUFS directly. A union mount point provides a view of multiple directories in the underlying file system. As a union file system it does not store data directly on disk, but instead uses another file system (e.g. The AUFS storage driver is a common default. Representation on daemon machines is determined by a pluggable storage driver.Ī Docker storage driver manages container storage and mounting. Layers are represented as gzip-compressed tar files over the network and on the registry machines. Only the layers not already available on the receiving end are transferred. Images may be published with a push from a daemon to a registry, and images may be deployed by executing pulls on a number of daemons in the cluster. Image sharing is accomplished via centralized registries that typically run on machines in the same cluster as the Docker workers. New containers and new images may be created on a specific worker by sending commands to its local daemon. The docker run command will pull images from a repository if they are not already available locally… Based on their analysis of where all that time goes, the authors built ‘Slacker’ – a Docker storage driver that is optimised for fast container startup (and equivalent performance once the container is started).Īmong other findings, our analysis shows that (1) copying package data accounts for 76% of container startup time, (2) only 6.4% of the copied data is actually needed for containers to begin useful work, and (3) simple block de-duplication across images achieves better compression rates than gzip compression of individual images… Slacker speeds up the median container development cycle by 20x and deployment cycle by 5x. Containers are much lighter-weight and faster starting than virtual machines, but in many scenarios where an image must be pulled before the container can be run, startup can still take a surprisingly long time (median about 25s as reported in Large-scale cluster management at Google with Borg). analyse what happens behind the scenes when you docker run a container image, and provide a fascinating look at the makeup of container images along the way. How long did it take before you saw the bash prompt? In this wonderful FAST’16 paper, Harter et al. On you marks, get set, docker run -it ubuntu bash. Slacker: Fast Distribution with Lazy Docker Containers – Harter et al.
0 Comments
Leave a Reply. |