github.com/portworx/docker@v1.12.1/docs/migration.md (about)

     1  <!--[metadata]>
     2  +++
     3  title = "Migrate to Engine 1.10"
     4  description = "Migrate to Engine 1.10"
     5  keywords = ["docker, documentation, engine, upgrade, migration"]
     6  [menu.main]
     7  parent = "engine_use"
     8  weight=79
     9  +++
    10  <![end-metadata]-->
    11  
    12  # Migrate to Engine 1.10
    13  
    14  Starting from version 1.10 of Docker Engine, we completely change the way image
    15  data is addressed on disk. Previously, every image and layer used a randomly
    16  assigned UUID. In 1.10 we implemented a content addressable method using an ID,
    17  based on a secure hash of the image and layer data.
    18  
    19  The new method gives users more security, provides a built-in way to avoid ID
    20  collisions and guarantee data integrity after pull, push, load, or save. It also
    21  brings better sharing of layers by allowing many images to freely share their
    22  layers even if they didn’t come from the same build.
    23  
    24  Addressing images by their content also lets us more easily detect if something
    25  has already been downloaded. Because we have separated images and layers, you
    26  don’t have to pull the configurations for every image that was part of the
    27  original build chain. We also don’t need to create layers for the build
    28  instructions that didn’t modify the filesystem.
    29  
    30  Content addressability is the foundation for the new distribution features. The
    31  image pull and push code has been reworked to use a download/upload manager
    32  concept that makes pushing and pulling images much more stable and mitigates any
    33  parallel request issues. The download manager also brings retries on failed
    34  downloads and better prioritization for concurrent downloads.
    35  
    36  We are also introducing a new manifest format that is built on top of the
    37  content addressable base. It directly references the content addressable image
    38  configuration and layer checksums. The new manifest format also makes it
    39  possible for a manifest list to be used for targeting multiple
    40  architectures/platforms. Moving to the new manifest format will be completely
    41  transparent.
    42  
    43  ## Preparing for upgrade
    44  
    45  To make your current images accessible to the new model we have to migrate them
    46  to content addressable storage. This means calculating the secure checksums for
    47  your current data.
    48  
    49  All your current images, tags and containers are automatically migrated to the
    50  new foundation the first time you start Docker Engine 1.10. Before loading your
    51  container, the daemon will calculate all needed checksums for your current data,
    52  and after it has completed, all your images and tags will have brand new secure
    53  IDs.
    54  
    55  **While this is simple operation, calculating SHA256 checksums for your files
    56  can take time if you have lots of image data.** On average you should assume
    57  that migrator can process data at a speed of 100MB/s. During this time your
    58  Docker daemon won’t be ready to respond to requests.
    59  
    60  ## Minimizing migration time
    61  
    62  If you can accept this one time hit, then upgrading Docker Engine and restarting
    63  the daemon will transparently migrate your images. However, if you want to
    64  minimize the daemon’s downtime, a migration utility can be run while your old
    65  daemon is still running.
    66  
    67  This tool will find all your current images and calculate the checksums for
    68  them. After you upgrade and restart the daemon, the checksum data of the
    69  migrated images will already exist, freeing the daemon from that computation
    70  work. If new images appeared between the migration and the upgrade, those will
    71  be processed at time of upgrade to 1.10.
    72  
    73  [You can download the migration tool
    74  here.](https://github.com/docker/v1.10-migrator/releases)
    75  
    76  The migration tool can also be run as a Docker image. While running the migrator
    77  image you need to expose your Docker data directory to the container. If you use
    78  the default path then you would run:
    79  
    80      $ docker run --rm -v /var/lib/docker:/var/lib/docker docker/v1.10-migrator
    81  
    82  If you use the
    83  devicemapper storage driver, you also need to pass the flag `--privileged` to
    84  give the tool access to your storage devices.