From 812fa0710bc149c350f7981545da2c352b97c636 Mon Sep 17 00:00:00 2001 From: Sebastiaan van Stijn Date: Sat, 20 Jan 2024 00:15:39 +0100 Subject: [PATCH] engine: remove docker 1.10 migration guide These docs described how to migrate the image store when upgrading to the content-addressable image store in docker 1.10. As these docs were added 9 Years ago, and were not included in the TOC, it's likely that users will have migrated by now :D - https://blog.docker.com/2016/01/docker-1-10-rc/ - https://github.com/moby/moby/commit/a315a5acec43b10cd503dc552ee23ea706443f6c Signed-off-by: Sebastiaan van Stijn --- content/engine/_index.md | 1 + content/engine/migration.md | 77 ------------------------------------- 2 files changed, 1 insertion(+), 77 deletions(-) delete mode 100644 content/engine/migration.md diff --git a/content/engine/_index.md b/content/engine/_index.md index 5ae43b5737..ca5f1c4434 100644 --- a/content/engine/_index.md +++ b/content/engine/_index.md @@ -42,6 +42,7 @@ grid: aliases: - /edge/ - /engine/ce-ee-node-activate/ +- /engine/migration/ - /engine/misc/ - /linux/ --- diff --git a/content/engine/migration.md b/content/engine/migration.md deleted file mode 100644 index c94aead216..0000000000 --- a/content/engine/migration.md +++ /dev/null @@ -1,77 +0,0 @@ ---- -description: Migrate to Engine 1.10 -keywords: docker, documentation, engine, upgrade, migration -title: Migrate to Engine 1.10 ---- - -Starting from version 1.10 of Docker Engine, we completely change the way image -data is addressed on disk. Previously, every image and layer used a randomly -assigned UUID. In 1.10 we implemented a content addressable method using an ID, -based on a secure hash of the image and layer data. - -The new method gives users more security, provides a built-in way to avoid ID -collisions and guarantee data integrity after pull, push, load, or save. It also -brings better sharing of layers by allowing many images to freely share their -layers even if they didn’t come from the same build. - -Addressing images by their content also lets us more easily detect if something -has already been downloaded. Because we have separated images and layers, you -don’t need to pull the configurations for every image that was part of the -original build chain. We also don’t need to create layers for the build -instructions that didn’t modify the filesystem. - -Content addressability is the foundation for the new distribution features. The -image pull and push code has been reworked to use a download/upload manager -concept that makes pushing and pulling images much more stable and mitigates any -parallel request issues. The download manager also brings retries on failed -downloads and better prioritization for concurrent downloads. - -We are also introducing a new manifest format that is built on top of the -content addressable base. It directly references the content addressable image -configuration and layer checksums. The new manifest format also makes it -possible for a manifest list to be used for targeting multiple -architectures/platforms. Moving to the new manifest format is completely -transparent. - -## Prepare for upgrade - -To make your current images accessible to the new model we need to migrate them -to content addressable storage. This means calculating the secure checksums for -your current data. - -All your current images, tags, and containers are automatically migrated to the -new foundation the first time you start Docker Engine 1.10. Before loading your -container, the daemon calculates all needed checksums for your current data, -and after it has completed, all your images and tags have brand new secure -IDs. - -**While this is simple operation, calculating SHA256 checksums for your files -can take time if you have lots of image data.** On average you should assume -that migrator can process data at a speed of 100MB/s. During this time your -Docker daemon won’t be ready to respond to requests. - -## Minimize migration time - -If you can accept this one time hit, then upgrading Docker Engine and restarting -the daemon transparently migrates your images. However, if you want to -minimize the daemon’s downtime, a migration utility can be run while your old -daemon is still running. - -This tool finds all your current images and calculate the checksums for -them. After you upgrade and restart the daemon, the checksum data of the -migrated images already exist, freeing the daemon from that computation -work. If new images appeared between the migration and the upgrade, those are -processed at time of upgrade to 1.10. - -[You can download the migration tool -here.](https://github.com/docker/v1.10-migrator/releases) - -The migration tool can also be run as a Docker image. While running the migrator -image you need to expose your Docker data directory to the container. If you use -the default path then you would run: - - $ docker run --rm -v /var/lib/docker:/var/lib/docker docker/v1.10-migrator - -If you use the -devicemapper storage driver, you also need to pass the flag `--privileged` to -give the tool access to your storage devices. \ No newline at end of file