github.com/walkingsparrow/docker@v1.4.2-0.20151218153551-b708a2249bfa/docs/userguide/storagedriver/aufs-driver.md (about)

     1  <!--[metadata]>
     2  +++
     3  title = "AUFS storage driver in practice"
     4  description = "Learn how to optimize your use of AUFS driver."
     5  keywords = ["container, storage, driver, AUFS "]
     6  [menu.main]
     7  parent = "mn_storage_docker"
     8  +++
     9  <![end-metadata]-->
    10  
    11  # Docker and AUFS in practice
    12  
    13  AUFS was the first storage driver in use with Docker. As a result, it has a long and close history with Docker, is very stable, has a lot of real-world deployments, and has strong community support.  AUFS has several features that make it a good choice for Docker. These features enable:
    14  
    15  - Fast container startup times.
    16  - Efficient use of storage.
    17  - Efficient use of memory.
    18  
    19  Despite its capabilities and long history with Docker, some Linux distributions do not support AUFS. This is usually because AUFS is not included in the mainline (upstream) Linux kernel.
    20  
    21  The following sections examine some AUFS features and how they relate to Docker.
    22  
    23  ## Image layering and sharing with AUFS
    24  
    25  AUFS is a *unification filesystem*. This means that it takes multiple directories on a single Linux host, stacks them on top of each other, and provides a single unified view. To achieve this, AUFS uses *union mount*.
    26  
    27  AUFS stacks multiple directories and exposes them as a unified view through a single mount point. All of the directories in the stack, as well as the union mount point, must all exist on the same Linux host. AUFS refers to each directory that it stacks as a *branch*.
    28  
    29  Within Docker, AUFS union mounts enable image layering. The AUFS storage driver implements Docker image layers using this union mount system. AUFS branches correspond to Docker image layers. The diagram below shows a Docker container based on the `ubuntu:latest` image.
    30  
    31  ![](images/aufs_layers.jpg)
    32  
    33  This diagram shows the relationship between the Docker image layers and the AUFS branches (directories) in `/var/lib/docker/aufs`. Each image layer  and the container layer correspond to an AUFS branch (directory) in the Docker host's local storage area. The union mount point gives the unified view of all layers.
    34  
    35  AUFS also supports the copy-on-write technology (CoW). Not all storage drivers do.
    36  
    37  ## Container reads and writes with AUFS
    38  
    39  Docker leverages AUFS CoW technology to enable image sharing and minimize the use of disk space. AUFS works at the file level. This means that all AUFS CoW operations copy entire files - even if only a small part of the file is being modified. This behavior can have a noticeable impact on container performance, especially if the files being copied are large, below a lot of image layers, or the CoW operation must search a deep directory tree.
    40  
    41  Consider, for example, an application running in a container needs to add a single new value to a large key-value store (file). If this is the first time the file is modified it does not yet exist in the container's top writable layer. So, the CoW must *copy up* the file from the underlying image. The AUFS storage driver searches each image layer for the file. The search order is from top to bottom. When it is found, the entire file is *copied up* to the container's top writable layer. From there, it can be opened and modified.
    42  
    43  Larger files obviously take longer to *copy up* than smaller files, and files that exist in lower image layers take longer to locate than those in higher layers. However, a *copy up* operation only occurs once per file on any given container. Subsequent reads and writes happen against the file's copy already *copied-up* to the container's top layer.
    44  
    45  
    46  ## Deleting files with the AUFS storage driver
    47  
    48  The AUFS storage driver deletes a file from a container by placing a *whiteout
    49  file* in the container's top layer. The whiteout file effectively obscures the
    50  existence of the file in image's lower, read-only layers.  The simplified
    51  diagram below shows a container based on an image with three image layers.
    52  
    53  ![](images/aufs_delete.jpg)
    54  
    55  The `file3` was deleted from the container. So, the AUFS storage driver  placed
    56  a whiteout file in the container's top layer. This whiteout file effectively
    57  "deletes"  `file3` from the container by obscuring any of the original file's
    58  existence in the image's read-only base layer. Of course, the image could have
    59  been in any of the other layers instead or in addition depending on how the
    60  layers are built.
    61  
    62  ## Configure Docker with AUFS
    63  
    64  You can only use the AUFS storage driver on Linux systems with AUFS installed. Use the following command to determine if your system supports AUFS.
    65  
    66  ```bash
    67  $ grep aufs /proc/filesystems
    68  nodev   aufs
    69  ```
    70  
    71  This output indicates the system supports AUFS.  Once you've verified your
    72  system supports AUFS, you can must instruct the Docker daemon to use it. You do
    73  this from the command line with the `docker daemon` command:
    74  
    75  ```bash
    76  $ sudo docker daemon --storage-driver=aufs &
    77  ```
    78  
    79  Alternatively, you can edit the Docker config file and add the
    80  `--storage-driver=aufs` option to the `DOCKER_OPTS` line.
    81  
    82  ```bash
    83  # Use DOCKER_OPTS to modify the daemon startup options.
    84  DOCKER_OPTS="--storage-driver=aufs"
    85  ```
    86  
    87  Once your daemon is running, verify the storage driver with the `docker info` command.
    88  
    89  ```bash
    90  $ sudo docker info
    91  Containers: 1
    92  Images: 4
    93  Storage Driver: aufs
    94   Root Dir: /var/lib/docker/aufs
    95   Backing Filesystem: extfs
    96   Dirs: 6
    97   Dirperm1 Supported: false
    98  Execution Driver: native-0.2
    99  ...output truncated...
   100  ```
   101  
   102  The output above shows that the Docker daemon is running the AUFS storage driver on top of an existing ext4 backing filesystem.
   103  
   104  ## Local storage and AUFS
   105  
   106  As the `docker daemon` runs with the AUFS driver, the driver stores images and containers on within the Docker host's local storage area in the `/var/lib/docker/aufs` directory.
   107  
   108  ### Images
   109  
   110  Image layers and their contents are stored under
   111  `/var/lib/docker/aufs/mnt/diff/<image-id>` directory. The contents of an image
   112  layer in this location includes all the files and directories belonging in that
   113  image layer.
   114  
   115  The `/var/lib/docker/aufs/layers/` directory contains metadata about how image
   116  layers are stacked. This directory contains one file for every image or
   117  container layer on the Docker host. Inside each file are the image layers names
   118  that exist below it. The diagram below shows an image with 4 layers.
   119  
   120  ![](images/aufs_metadata.jpg)
   121  
   122  Inspecting the contents of the file relating to the top layer of the image
   123  shows the three image layers below it. They are listed in the order they are
   124  stacked.
   125  
   126  ```bash
   127  $ cat /var/lib/docker/aufs/layers/91e54dfb11794fad694460162bf0cb0a4fa710cfa3f60979c177d920813e267c
   128  
   129  d74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82
   130  
   131  c22013c8472965aa5b62559f2b540cd440716ef149756e7b958a1b2aba421e87
   132  
   133  d3a1f33e8a5a513092f01bb7eb1c2abf4d711e5105390a3fe1ae2248cfde1391
   134  ```
   135  
   136  The base layer in an image has no image layers below it, so its file is empty.
   137  
   138  ### Containers
   139  
   140  Running containers are mounted at locations in the
   141  `/var/lib/docker/aufs/mnt/<container-id>` directory. This is the AUFS union
   142  mount point that exposes the container and all underlying image layers as a
   143  single unified view. If a container is not running, its directory still exists
   144  but is empty. This is because containers are only mounted when they are running.
   145  
   146  Container metadata and various config files that are placed into the running
   147  container are stored in `/var/lib/containers/<container-id>`. Files in this
   148  directory exist for all containers on the system, including ones that are
   149  stopped. However, when a container is running the container's log files are also
   150  in this directory.
   151  
   152  A container's thin writable layer is stored under
   153  `/var/lib/docker/aufs/diff/<container-id>`. This directory is stacked by AUFS as
   154  the containers top writable layer and is where all changes to the container are
   155  stored. The directory exists even if the container is stopped. This means that
   156  restarting a container will not lose changes made to it. Once a container is
   157  deleted this directory is deleted.
   158  
   159  Information about which image layers are stacked below a container's top
   160  writable layer is stored in the following file
   161  `/var/lib/docker/aufs/layers/<container-id>`. The command below shows that the
   162  container with ID `b41a6e5a508d` has 4 image layers below it:
   163  
   164  ```bash
   165  $ cat /var/lib/docker/aufs/layers/b41a6e5a508dfa02607199dfe51ed9345a675c977f2cafe8ef3e4b0b5773404e-init
   166  91e54dfb11794fad694460162bf0cb0a4fa710cfa3f60979c177d920813e267c
   167  d74508fb6632491cea586a1fd7d748dfc5274cd6fdfedee309ecdcbc2bf5cb82
   168  c22013c8472965aa5b62559f2b540cd440716ef149756e7b958a1b2aba421e87
   169  d3a1f33e8a5a513092f01bb7eb1c2abf4d711e5105390a3fe1ae2248cfde1391
   170  ```
   171  
   172  The image layers are shown in order. In the output above, the layer starting
   173  with image ID "d3a1..." is the image's base  layer. The image layer starting
   174  with "91e5..." is the image's topmost layer.
   175  
   176  
   177  ## AUFS and Docker performance
   178  
   179  To summarize some of the performance related aspects already mentioned:
   180  
   181  - The AUFS storage driver is a good choice for PaaS and other similar use-cases where container density is important. This is because AUFS efficiently shares images between multiple running containers, enabling fast container start times and minimal use of disk space.
   182  
   183  - The underlying mechanics of how AUFS shares files between image layers and containers uses the systems page cache very efficiently.
   184  
   185  - The AUFS storage driver can introduce significant latencies into container write performance. This is because the first time a container writes to any file, the file has be located and copied into the containers top writable layer. These latencies increase and are compounded when these files exist below many image layers and the files themselves are large.
   186  
   187  One final point. Data volumes provide the best and most predictable performance.
   188  This is because they bypass the storage driver and do not incur any of the
   189  potential overheads introduced by thin provisioning and copy-on-write. For this
   190  reason, you may want to place heavy write workloads on data volumes.
   191  
   192  ## Related information
   193  
   194  * [Understand images, containers, and storage drivers](imagesandcontainers.md)
   195  * [Select a storage driver](selectadriver.md)
   196  * [Btrfs storage driver in practice](btrfs-driver.md)
   197  * [Device Mapper storage driver in practice](device-mapper-driver.md)