Merge pull request #4035 from milosgajdos/small-docs-cleanup
This commit is contained in:
commit
a2e65220ae
3 changed files with 0 additions and 54 deletions
|
@ -1,28 +0,0 @@
|
|||
---
|
||||
published: false
|
||||
---
|
||||
|
||||
# Migrating a 1.0 registry to 2.0
|
||||
|
||||
TODO: This needs to be revised in light of Olivier's work
|
||||
|
||||
A few thoughts here:
|
||||
|
||||
There was no "1.0". There was an implementation of the Registry API V1 but only a version 0.9 of the service was released.
|
||||
The image formats are not compatible in any way. One must convert v1 images to v2 images using a docker client or other tool.
|
||||
One can migrate images from one version to the other by pulling images from the old registry and pushing them to the v2 registry.
|
||||
|
||||
-----
|
||||
|
||||
The Docker Registry 2.0 is backward compatible with images created by the earlier specification. If you are migrating a private registry to version 2.0, you should use the following process:
|
||||
|
||||
1. Configure and test a 2.0 registry image in a sandbox environment.
|
||||
|
||||
2. Back up up your production image storage.
|
||||
|
||||
Your production image storage should reside on a volume or storage backend.
|
||||
Make sure you have a backup of its contents.
|
||||
|
||||
3. Stop your existing registry service.
|
||||
|
||||
4. Restart your registry with your tested 2.0 image.
|
|
@ -52,19 +52,6 @@ specification, details of the protocol will be left to a future specification.
|
|||
Relevant header definitions and error codes are present to provide an
|
||||
indication of what a client may encounter.
|
||||
|
||||
#### Future
|
||||
|
||||
There are features that have been discussed during the process of cutting this
|
||||
specification. The following is an incomplete list:
|
||||
|
||||
- Immutable image references
|
||||
- Multiple architecture support
|
||||
- Migration from v2compatibility representation
|
||||
|
||||
These may represent features that are either out of the scope of this
|
||||
specification, the purview of another specification or have been deferred to a
|
||||
future version.
|
||||
|
||||
### Use Cases
|
||||
|
||||
For the most part, the use cases of the former registry API apply to the new
|
||||
|
|
|
@ -52,19 +52,6 @@ specification, details of the protocol will be left to a future specification.
|
|||
Relevant header definitions and error codes are present to provide an
|
||||
indication of what a client may encounter.
|
||||
|
||||
#### Future
|
||||
|
||||
There are features that have been discussed during the process of cutting this
|
||||
specification. The following is an incomplete list:
|
||||
|
||||
- Immutable image references
|
||||
- Multiple architecture support
|
||||
- Migration from v2compatibility representation
|
||||
|
||||
These may represent features that are either out of the scope of this
|
||||
specification, the purview of another specification or have been deferred to a
|
||||
future version.
|
||||
|
||||
### Use Cases
|
||||
|
||||
For the most part, the use cases of the former registry API apply to the new
|
||||
|
|
Loading…
Reference in a new issue