Initial work

Removing references to regsitry 1.0, pointing to distribution
Updating links and title
Adding in comments

Signed-off-by: Mary Anthony <mary@docker.com>

docs/articles/certificates.md

@@ -11,111 +11,7 @@ weight = 7
 
 # Using certificates for repository client verification
 
-In [Running Docker with HTTPS](/articles/https), you learned that, by default,
-Docker runs via a non-networked Unix socket and TLS must be enabled in order
-to have the Docker client and the daemon communicate securely over HTTPS.
-
-Now, you will see how to allow the Docker registry (i.e., *a server*) to
-verify that the Docker daemon (i.e., *a client*) has the right to access the
-images being hosted with *certificate-based client-server authentication*.
-
-We will show you how to install a Certificate Authority (CA) root certificate
-for the registry and how to set the client TLS certificate for verification.
-
-## Understanding the configuration
-
-A custom certificate is configured by creating a directory under
-`/etc/docker/certs.d` using the same name as the registry's hostname (e.g.,
-`localhost`). All `*.crt` files are added to this directory as CA roots.
-
-> **Note:**
-> In the absence of any root certificate authorities, Docker
-> will use the system default (i.e., host's root CA set).
-
-The presence of one or more `<filename>.key/cert` pairs indicates to Docker
-that there are custom certificates required for access to the desired
-repository.
-
-> **Note:**
-> If there are multiple certificates, each will be tried in alphabetical
-> order. If there is an authentication error (e.g., 403, 404, 5xx, etc.), Docker
-> will continue to try with the next certificate.
-
-Our example is set up like this:
-
-    /etc/docker/certs.d/        <-- Certificate directory
-    └── localhost               <-- Hostname
-       ├── client.cert          <-- Client certificate
-       ├── client.key           <-- Client key
-       └── localhost.crt        <-- Registry certificate
-
-## Creating the client certificates
-
-You will use OpenSSL's `genrsa` and `req` commands to first generate an RSA
-key and then use the key to create the certificate.   
-
-    $ openssl genrsa -out client.key 4096
-    $ openssl req -new -x509 -text -key client.key -out client.cert
-
-> **Warning:**: 
-> Using TLS and managing a CA is an advanced topic.
-> You should be familiar with OpenSSL, x509, and TLS before
-> attempting to use them in production. 
-
-> **Warning:**
-> These TLS commands will only generate a working set of certificates on Linux.
-> The version of OpenSSL in Mac OS X is incompatible with the type of
-> certificate Docker requires.
-
-## Testing the verification setup
-
-You can test this setup by using Apache to host a Docker registry.
-For this purpose, you can copy a registry tree (containing images) inside
-the Apache root.
-
-> **Note:**
-> You can find such an example [here](
-> http://people.gnome.org/~alexl/v1.tar.gz) - which contains the busybox image.
-
-Once you set up the registry, you can use the following Apache configuration
-to implement certificate-based protection.
-
-    # This must be in the root context, otherwise it causes a re-negotiation
-    # which is not supported by the TLS implementation in go
-    SSLVerifyClient optional_no_ca
-
-    <Location /v1>
-    Action cert-protected /cgi-bin/cert.cgi
-    SetHandler cert-protected
-
-    Header set x-docker-registry-version "0.6.2"
-    SetEnvIf Host (.*) custom_host=$1
-    Header set X-Docker-Endpoints "%{custom_host}e"
-    </Location>
-
-Save the above content as `/etc/httpd/conf.d/registry.conf`, and
-continue with creating a `cert.cgi` file under `/var/www/cgi-bin/`.
-
-    #!/bin/bash
-    if [ "$HTTPS" != "on" ]; then
-        echo "Status: 403 Not using SSL"
-        echo "x-docker-registry-version: 0.6.2"
-        echo
-        exit 0
-    fi
-    if [ "$SSL_CLIENT_VERIFY" == "NONE" ]; then
-        echo "Status: 403 Client certificate invalid"
-        echo "x-docker-registry-version: 0.6.2"
-        echo
-        exit 0
-    fi
-    echo "Content-length: $(stat --printf='%s' $PATH_TRANSLATED)"
-    echo "x-docker-registry-version: 0.6.2"
-    echo "X-Docker-Endpoints: $SERVER_NAME"
-    echo "X-Docker-Size: 0"
-    echo
-
-    cat $PATH_TRANSLATED
-
-This CGI script will ensure that all requests to `/v1` *without* a valid
-certificate will be returned with a `403` (i.e., HTTP forbidden) error.
+The orginal content was deprecated. For information about configuring
+cerficates, see  [deploying a registry
+server](http://docs.docker.com/registry/deploying/). To reach an older version
+of this content, refer to an older version of the documentation. 

docs/articles/registry_mirror.md

@@ -11,81 +11,8 @@ weight = 8
 
 # Run a local registry mirror
 
-## Why?
-
-If you have multiple instances of Docker running in your environment
-(e.g., multiple physical or virtual machines, all running the Docker
-daemon), each time one of them requires an image that it doesn't have
-it will go out to the internet and fetch it from the public Docker
-registry. By running a local registry mirror, you can keep most of the
-image fetch traffic on your local network.
-
-## How does it work?
-
-The first time you request an image from your local registry mirror,
-it pulls the image from the public Docker registry and stores it locally
-before handing it back to you. On subsequent requests, the local registry
-mirror is able to serve the image from its own storage.
-
-## How do I set up a local registry mirror?
-
-There are two steps to set up and use a local registry mirror.
-
-### Step 1: Configure your Docker daemons to use the local registry mirror
-
-You will need to pass the `--registry-mirror` option to your Docker daemon on
-startup:
-
-    docker daemon --registry-mirror=http://<my-docker-mirror-host>
-
-For example, if your mirror is serving on `http://10.0.0.2:5000`, you would run:
-
-    docker daemon --registry-mirror=http://10.0.0.2:5000
-
-**NOTE:**
-Depending on your local host setup, you may be able to add the
-`--registry-mirror` options to the `DOCKER_OPTS` variable in
-`/etc/default/docker`.
-
-### Step 2: Run the local registry mirror
-
-You will need to start a local registry mirror service. The
-[`registry` image](https://registry.hub.docker.com/_/registry/) provides this
-functionality. For example, to run a local registry mirror that serves on
-port `5000` and mirrors the content at `registry-1.docker.io`:
-
-    docker run -p 5000:5000 \
-        -e STANDALONE=false \
-        -e MIRROR_SOURCE=https://registry-1.docker.io \
-        -e MIRROR_SOURCE_INDEX=https://index.docker.io \
-        registry
-
-## Test it out
-
-With your mirror running, pull an image that you haven't pulled before (using
-`time` to time it):
-
-    $ time docker pull node:latest
-    Pulling repository node
-    [...]
-    
-    real   1m14.078s
-    user   0m0.176s
-    sys    0m0.120s
-
-Now, remove the image from your local machine:
-
-    $ docker rmi node:latest
-
-Finally, re-pull the image:
-
-    $ time docker pull node:latest
-    Pulling repository node
-    [...]
-    
-    real   0m51.376s
-    user   0m0.120s
-    sys    0m0.116s
-
-The second time around, the local registry mirror served the image from storage,
-avoiding a trip out to the internet to refetch it.
+The orginal content was deprecated. [An archived
+version](https://docs.docker.com/v1.6/articles/registry_mirror) is available in
+the 1.7 documentation. For information about configuring mirrors with the latest
+Docker Registry version, please file a support request with [the Distribution
+project](https://github.com/docker/distribution/issues). 

docs/introduction/understanding-docker.md

@@ -116,11 +116,11 @@ images, or you can download Docker images that other people have already created
 Docker images are the **build** component of Docker.
 
 #### Docker registries
-Docker registries hold images. These are public or private stores from which you upload
-or download images. The public Docker registry is called
-[Docker Hub](http://hub.docker.com). It provides a huge collection of existing
-images for your use. These can be images you create yourself or you
-can use images that others have previously created. Docker registries are the 
+Docker registries hold images. These are public or private stores from which you
+upload or download images. The public Docker registry is provided with the
+[Docker Hub](http://hub.docker.com). It serves a huge collection of existing
+images for your use. These can be images you create yourself or you can use
+images that others have previously created. Docker registries are the
 **distribution** component of Docker.
 
 #### Docker containers
@@ -179,8 +179,9 @@ returns a final image.
 
 ### How does a Docker registry work?
 The Docker registry is the store for your Docker images. Once you build a Docker
-image you can *push* it to a public registry [Docker Hub](https://hub.docker.com) or to 
-your own registry running behind your firewall.
+image you can *push* it to a public registry such as the one provided by [Docker
+Hub](https://hub.docker.com) or to your own registry running behind your
+firewall.
 
 Using the Docker client, you can search for already published images and then
 pull them down to your Docker host to build containers from them.

docs/misc/faq.md

@@ -97,7 +97,7 @@ with several powerful functionalities:
  applications. Your ideal PostgreSQL setup can be re-used for all your future
  projects. And so on.
 
- - *Sharing.* Docker has access to a [public registry](https://registry.hub.docker.com/)
+ - *Sharing.* Docker has access to a public registry [on Docker Hub](https://registry.hub.docker.com/)
  where thousands of people have uploaded useful containers: anything from Redis,
  CouchDB, PostgreSQL to IRC bouncers to Rails app servers to Hadoop to base 
  images for various Linux distros. The

docs/reference/api/docker-io_api.md

@@ -10,502 +10,5 @@ parent = "smn_remoteapi"
 
 # Docker Hub API
 
-- This is the REST API for [Docker Hub](https://hub.docker.com).
-- Authorization is done with basic auth over SSL
-- Not all commands require authentication, only those noted as such.
+This API is deprecated as of 1.7. To view the old version, see the [Docker Hub API](https://docs.docker.com/v1.7/reference/api/docker-io_api/) in the 1.7 documentation. 
 
-# Repositories
-
-## User repository
-
-### Create a user repository
-
-`PUT /v1/repositories/(namespace)/(repo_name)/`
-
-Create a user repository with the given `namespace` and `repo_name`.
-
-**Example Request**:
-
-        PUT /v1/repositories/foo/bar/ HTTP/1.1
-        Host: index.docker.io
-        Accept: application/json
-        Content-Type: application/json
-        Authorization: Basic akmklmasadalkm==
-        X-Docker-Token: true
-
-        [{"id": "9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f"}]
-
-Parameters:
-
-- **namespace** – the namespace for the repo
-- **repo_name** – the name for the repo
-
-**Example Response**:
-
-        HTTP/1.1 200
-        Vary: Accept
-        Content-Type: application/json
-        WWW-Authenticate: Token signature=123abc,repository="foo/bar",access=write
-        X-Docker-Token: signature=123abc,repository="foo/bar",access=write
-        X-Docker-Endpoints: registry-1.docker.io [, registry-2.docker.io]
-
-        ""
-
-Status Codes:
-
-- **200** – Created
-- **400** – Errors (invalid json, missing or invalid fields, etc)
-- **401** – Unauthorized
-- **403** – Account is not Active
-
-### Delete a user repository
-
-`DELETE /v1/repositories/(namespace)/(repo_name)/`
-
-Delete a user repository with the given `namespace` and `repo_name`.
-
-**Example Request**:
-
-        DELETE /v1/repositories/foo/bar/ HTTP/1.1
-        Host: index.docker.io
-        Accept: application/json
-        Content-Type: application/json
-        Authorization: Basic akmklmasadalkm==
-        X-Docker-Token: true
-
-        ""
-
-Parameters:
-
-- **namespace** – the namespace for the repo
-- **repo_name** – the name for the repo
-
-**Example Response**:
-
-        HTTP/1.1 202
-        Vary: Accept
-        Content-Type: application/json
-        WWW-Authenticate: Token signature=123abc,repository="foo/bar",access=delete
-        X-Docker-Token: signature=123abc,repository="foo/bar",access=delete
-        X-Docker-Endpoints: registry-1.docker.io [, registry-2.docker.io]
-
-        ""
-
-Status Codes:
-
-- **200** – Deleted
-- **202** – Accepted
-- **400** – Errors (invalid json, missing or invalid fields, etc)
-- **401** – Unauthorized
-- **403** – Account is not Active
-
-## Library repository
-
-### Create a library repository
-
-`PUT /v1/repositories/(repo_name)/`
-
-Create a library repository with the given `repo_name`.
-This is a restricted feature only available to docker admins.
-
-> When namespace is missing, it is assumed to be `library`
-
-
-**Example Request**:
-
-        PUT /v1/repositories/foobar/ HTTP/1.1
-        Host: index.docker.io
-        Accept: application/json
-        Content-Type: application/json
-        Authorization: Basic akmklmasadalkm==
-        X-Docker-Token: true
-
-        [{"id": "9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f"}]
-
-Parameters:
-
-- **repo_name** – the library name for the repo
-
-**Example Response**:
-
-        HTTP/1.1 200
-        Vary: Accept
-        Content-Type: application/json
-        WWW-Authenticate: Token signature=123abc,repository="library/foobar",access=write
-        X-Docker-Token: signature=123abc,repository="foo/bar",access=write
-        X-Docker-Endpoints: registry-1.docker.io [, registry-2.docker.io]
-
-        ""
-
-Status Codes:
-
-- **200** – Created
-- **400** – Errors (invalid json, missing or invalid fields, etc)
-- **401** – Unauthorized
-- **403** – Account is not Active
-
-### Delete a library repository
-
-`DELETE /v1/repositories/(repo_name)/`
-
-Delete a library repository with the given `repo_name`.
-This is a restricted feature only available to docker admins.
-
-> When namespace is missing, it is assumed to be `library`
-
-
-**Example Request**:
-
-        DELETE /v1/repositories/foobar/ HTTP/1.1
-        Host: index.docker.io
-        Accept: application/json
-        Content-Type: application/json
-        Authorization: Basic akmklmasadalkm==
-        X-Docker-Token: true
-
-        ""
-
-Parameters:
-
-- **repo_name** – the library name for the repo
-
-**Example Response**:
-
-        HTTP/1.1 202
-        Vary: Accept
-        Content-Type: application/json
-        WWW-Authenticate: Token signature=123abc,repository="library/foobar",access=delete
-        X-Docker-Token: signature=123abc,repository="foo/bar",access=delete
-        X-Docker-Endpoints: registry-1.docker.io [, registry-2.docker.io]
-
-        ""
-
-Status Codes:
-
-- **200** – Deleted
-- **202** – Accepted
-- **400** – Errors (invalid json, missing or invalid fields, etc)
-- **401** – Unauthorized
-- **403** – Account is not Active
-
-# Repository images
-
-## User repository images
-
-### Update user repository images
-
-`PUT /v1/repositories/(namespace)/(repo_name)/images`
-
-Update the images for a user repo.
-
-**Example Request**:
-
-        PUT /v1/repositories/foo/bar/images HTTP/1.1
-        Host: index.docker.io
-        Accept: application/json
-        Content-Type: application/json
-        Authorization: Basic akmklmasadalkm==
-
-        [{"id": "9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f",
-        "checksum": "b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087"}]
-
-Parameters:
-
-- **namespace** – the namespace for the repo
-- **repo_name** – the name for the repo
-
-**Example Response**:
-
-        HTTP/1.1 204
-        Vary: Accept
-        Content-Type: application/json
-
-        ""
-
-Status Codes:
-
-- **204** – Created
-- **400** – Errors (invalid json, missing or invalid fields, etc)
-- **401** – Unauthorized
-- **403** – Account is not Active or permission denied
-
-### List user repository images
-
-`GET /v1/repositories/(namespace)/(repo_name)/images`
-
-Get the images for a user repo.
-
-**Example Request**:
-
-        GET /v1/repositories/foo/bar/images HTTP/1.1
-        Host: index.docker.io
-        Accept: application/json
-
-Parameters:
-
-- **namespace** – the namespace for the repo
-- **repo_name** – the name for the repo
-
-**Example Response**:
-
-        HTTP/1.1 200
-        Vary: Accept
-        Content-Type: application/json
-
-        [{"id": "9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f",
-        "checksum": "b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087"},
-        {"id": "ertwetewtwe38722009fe6857087b486531f9a779a0c1dfddgfgsdgdsgds",
-        "checksum": "34t23f23fc17e3ed29dae8f12c4f9e89cc6f0bsdfgfsdgdsgdsgerwgew"}]
-
-Status Codes:
-
-- **200** – OK
-- **404** – Not found
-
-## Library repository images
-
-### Update library repository images
-
-`PUT /v1/repositories/(repo_name)/images`
-
-Update the images for a library repo.
-
-**Example Request**:
-
-        PUT /v1/repositories/foobar/images HTTP/1.1
-        Host: index.docker.io
-        Accept: application/json
-        Content-Type: application/json
-        Authorization: Basic akmklmasadalkm==
-
-        [{"id": "9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f",
-        "checksum": "b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087"}]
-
-Parameters:
-
-- **repo_name** – the library name for the repo
-
-**Example Response**:
-
-        HTTP/1.1 204
-        Vary: Accept
-        Content-Type: application/json
-
-        ""
-
-Status Codes:
-
-- **204** – Created
-- **400** – Errors (invalid json, missing or invalid fields, etc)
-- **401** – Unauthorized
-- **403** – Account is not Active or permission denied
-
-### List library repository images
-
-`GET /v1/repositories/(repo_name)/images`
-
-Get the images for a library repo.
-
-**Example Request**:
-
-        GET /v1/repositories/foobar/images HTTP/1.1
-        Host: index.docker.io
-        Accept: application/json
-
-Parameters:
-
-- **repo_name** – the library name for the repo
-
-**Example Response**:
-
-        HTTP/1.1 200
-        Vary: Accept
-        Content-Type: application/json
-
-        [{"id": "9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f",
-        "checksum": "b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087"},
-        {"id": "ertwetewtwe38722009fe6857087b486531f9a779a0c1dfddgfgsdgdsgds",
-        "checksum": "34t23f23fc17e3ed29dae8f12c4f9e89cc6f0bsdfgfsdgdsgdsgerwgew"}]
-
-Status Codes:
-
-- **200** – OK
-- **404** – Not found
-
-# Repository authorization
-
-## Library repository
-
-### Authorize a token for a library
-
-`PUT /v1/repositories/(repo_name)/auth`
-
-Authorize a token for a library repo
-
-**Example Request**:
-
-        PUT /v1/repositories/foobar/auth HTTP/1.1
-        Host: index.docker.io
-        Accept: application/json
-        Authorization: Token signature=123abc,repository="library/foobar",access=write
-
-Parameters:
-
-- **repo_name** – the library name for the repo
-
-**Example Response**:
-
-        HTTP/1.1 200
-        Vary: Accept
-        Content-Type: application/json
-
-        "OK"
-
-Status Codes:
-
-- **200** – OK
-- **403** – Permission denied
-- **404** – Not found
-
-## User repository
-
-### Authorize a token for a user repository
-
-`PUT /v1/repositories/(namespace)/(repo_name)/auth`
-
-Authorize a token for a user repo
-
-**Example Request**:
-
-        PUT /v1/repositories/foo/bar/auth HTTP/1.1
-        Host: index.docker.io
-        Accept: application/json
-        Authorization: Token signature=123abc,repository="foo/bar",access=write
-
-Parameters:
-
-- **namespace** – the namespace for the repo
-- **repo_name** – the name for the repo
-
-**Example Response**:
-
-        HTTP/1.1 200
-        Vary: Accept
-        Content-Type: application/json
-
-        "OK"
-
-Status Codes:
-
-- **200** – OK
-- **403** – Permission denied
-- **404** – Not found
-
-## Users
-
-### User login
-
-`GET /v1/users/`
-
-If you want to check your login, you can try this endpoint
-
-**Example Request**:
-
-        GET /v1/users/ HTTP/1.1
-        Host: index.docker.io
-        Accept: application/json
-        Authorization: Basic akmklmasadalkm==
-
-**Example Response**:
-
-        HTTP/1.1 200 OK
-        Vary: Accept
-        Content-Type: application/json
-
-        OK
-
-Status Codes:
-
-- **200** – no error
-- **401** – Unauthorized
-- **403** – Account is not Active
-
-### User register
-
-`POST /v1/users/`
-
-Registering a new account.
-
-**Example request**:
-
-        POST /v1/users/ HTTP/1.1
-        Host: index.docker.io
-        Accept: application/json
-        Content-Type: application/json
-
-        {"email": "sam@docker.com",
-         "password": "toto42",
-         "username": "foobar"}
-
-Json Parameters:
-
-- **email** – valid email address, that needs to be confirmed
-- **username** – min 4 character, max 30 characters, must match
-        the regular expression [a-z0-9_].
-- **password** – min 5 characters
-
-**Example Response**:
-
-        HTTP/1.1 201 OK
-        Vary: Accept
-        Content-Type: application/json
-
-        "User Created"
-
-Status Codes:
-
-- **201** – User Created
-- **400** – Errors (invalid json, missing or invalid fields, etc)
-
-### Update user
-
-`PUT /v1/users/(username)/`
-
-Change a password or email address for given user. If you pass in an
-email, it will add it to your account, it will not remove the old
-one. Passwords will be updated.
-
-It is up to the client to verify that that password that is sent is
-the one that they want. Common approach is to have them type it
-twice.
-
-**Example Request**:
-
-        PUT /v1/users/fakeuser/ HTTP/1.1
-        Host: index.docker.io
-        Accept: application/json
-        Content-Type: application/json
-        Authorization: Basic akmklmasadalkm==
-
-        {"email": "sam@docker.com",
-         "password": "toto42"}
-
-Parameters:
-
-- **username** – username for the person you want to update
-
-**Example Response**:
-
-        HTTP/1.1 204
-        Vary: Accept
-        Content-Type: application/json
-
-        ""
-
-Status Codes:
-
-- **204** – User Updated
-- **400** – Errors (invalid json, missing or invalid fields, etc)
-- **401** – Unauthorized
-- **403** – Account is not Active
-- **404** – User not found

docs/reference/api/hub_registry_spec.md

@@ -1,761 +0,0 @@
-<!--[metadata]>
-+++
-title = "The Docker Hub and the Registry v1"
-description = "Documentation for docker Registry and Registry API"
-keywords = ["docker, registry, api,  hub"]
-[menu.main]
-parent="smn_hub_ref"
-+++
-<![end-metadata]-->
-
-# The Docker Hub and the Registry v1
-
-## The three roles
-
-There are three major components playing a role in the Docker ecosystem.
-
-### Docker Hub
-
-The Docker Hub is responsible for centralizing information about:
-
- - User accounts
- - Checksums of the images
- - Public namespaces
-
-The Docker Hub has different components:
-
- - Web UI
- - Meta-data store (comments, stars, list public repositories)
- - Authentication service
- - Tokenization
-
-The Docker Hub is authoritative for that information.
-
-There is only one instance of the Docker Hub, run and
-managed by Docker Inc.
-
-### Docker Registry 1.0
-
-The 1.0 registry has the following characteristics:
-
- - It stores the images and the graph for a set of repositories
- - It does not have user accounts data
- - It has no notion of user accounts or authorization
- - It delegates authentication and authorization to the Docker Hub Auth
-   service using tokens
- - It supports different storage backends (S3, cloud files, local FS)
- - It doesn't have a local database
- - [Source Code](https://github.com/docker/docker-registry)
-
-We expect that there will be multiple registries out there. To help you
-grasp the context, here are some examples of registries:
-
- - **sponsor registry**: such a registry is provided by a third-party
-   hosting infrastructure as a convenience for their customers and the
-   Docker community as a whole. Its costs are supported by the third
-   party, but the management and operation of the registry are
-   supported by Docker, Inc. It features read/write access, and delegates
-   authentication and authorization to the Docker Hub.
- - **mirror registry**: such a registry is provided by a third-party
-   hosting infrastructure but is targeted at their customers only. Some
-   mechanism (unspecified to date) ensures that public images are
-   pulled from a sponsor registry to the mirror registry, to make sure
-   that the customers of the third-party provider can `docker pull`
-   those images locally.
- - **vendor registry**: such a registry is provided by a software
-   vendor who wants to distribute docker images. It would be operated
-   and managed by the vendor. Only users authorized by the vendor would
-   be able to get write access. Some images would be public (accessible
-   for anyone), others private (accessible only for authorized users).
-   Authentication and authorization would be delegated to the Docker Hub.
-   The goal of vendor registries is to let someone do `docker pull
-   basho/riak1.3` and automatically push from the vendor registry
-   (instead of a sponsor registry); i.e., vendors get all the convenience of a
-   sponsor registry, while retaining control on the asset distribution.
- - **private registry**: such a registry is located behind a firewall,
-   or protected by an additional security layer (HTTP authorization,
-   SSL client-side certificates, IP address authorization...). The
-   registry is operated by a private entity, outside of Docker's
-   control. It can optionally delegate additional authorization to the
-   Docker Hub, but it is not mandatory.
-
-> **Note:** The latter implies that while HTTP is the protocol
-> of choice for a registry, multiple schemes are possible (and
-> in some cases, trivial):
->
-> - HTTP with GET (and PUT for read-write registries);
-> - local mount point;
-> - remote docker addressed through SSH.
-
-The latter would only require two new commands in Docker, e.g.,
-`registryget` and `registryput`,
-wrapping access to the local filesystem (and optionally doing
-consistency checks). Authentication and authorization are then delegated
-to SSH (e.g., with public keys).
-
-### Docker
-
-On top of being a runtime for LXC, Docker is the Registry client. It
-supports:
-
- - Push / Pull on the registry
- - Client authentication on the Docker Hub
-
-## Workflow
-
-### Pull
-
-![](/static_files/docker_pull_chart.png)
-
-1.  Contact the Docker Hub to know where I should download “samalba/busybox”
-2.  Docker Hub replies: a. `samalba/busybox` is on Registry A b. here are the
-    checksums for `samalba/busybox` (for all layers) c. token
-3.  Contact Registry A to receive the layers for `samalba/busybox` (all of
-    them to the base image). Registry A is authoritative for “samalba/busybox”
-    but keeps a copy of all inherited layers and serve them all from the same
-    location.
-4.  registry contacts Docker Hub to verify if token/user is allowed to download images
-5.  Docker Hub returns true/false lettings registry know if it should proceed or error
-    out
-6.  Get the payload for all layers
-
-It's possible to run:
-
-    $ docker pull https://<registry>/repositories/samalba/busybox
-
-In this case, Docker bypasses the Docker Hub. However the security is not
-guaranteed (in case Registry A is corrupted) because there won't be any
-checksum checks.
-
-Currently registry redirects to s3 urls for downloads, going forward all
-downloads need to be streamed through the registry. The Registry will
-then abstract the calls to S3 by a top-level class which implements
-sub-classes for S3 and local storage.
-
-Token is only returned when the `X-Docker-Token`
-header is sent with request.
-
-Basic Auth is required to pull private repos. Basic auth isn't required
-for pulling public repos, but if one is provided, it needs to be valid
-and for an active account.
-
-**API (pulling repository foo/bar):**
-
-1.  (Docker -> Docker Hub) GET /v1/repositories/foo/bar/images:
-
-**Headers**:
-
-        Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
-        X-Docker-Token: true
-
-**Action**:
-
-        (looking up the foo/bar in db and gets images and checksums
-        for that repo (all if no tag is specified, if tag, only
-        checksums for those tags) see part 4.4.1)
-
-2.  (Docker Hub -> Docker) HTTP 200 OK
-
-**Headers**:
-
-        Authorization: Token
-        signature=123abc,repository=”foo/bar”,access=write
-        X-Docker-Endpoints: registry.docker.io [,registry2.docker.io]
-
-**Body**:
-
-        Jsonified checksums (see part 4.4.1)
-
-3.  (Docker -> Registry) GET /v1/repositories/foo/bar/tags/latest
-
-**Headers**:
-
-        Authorization: Token
-        signature=123abc,repository=”foo/bar”,access=write
-
-4.  (Registry -> Docker Hub) GET /v1/repositories/foo/bar/images
-
-**Headers**:
-
-        Authorization: Token
-        signature=123abc,repository=”foo/bar”,access=read
-
-**Body**:
-
-        <ids and checksums in payload>
-
-**Action**:
-
-        (Lookup token see if they have access to pull.)
-
-        If good:
-        HTTP 200 OK Docker Hub will invalidate the token
-
-        If bad:
-        HTTP 401 Unauthorized
-
-5.  (Docker -> Registry) GET /v1/images/928374982374/ancestry
-
-**Action**:
-
-        (for each image id returned in the registry, fetch /json + /layer)
-
-> **Note**:
-> If someone makes a second request, then we will always give a new token,
-> never reuse tokens.
-
-### Push
-
-![](/static_files/docker_push_chart.png)
-
-1.  Contact the Docker Hub to allocate the repository name “samalba/busybox”
-    (authentication required with user credentials)
-2.  If authentication works and namespace available, “samalba/busybox”
-    is allocated and a temporary token is returned (namespace is marked
-    as initialized in Docker Hub)
-3.  Push the image on the registry (along with the token)
-4.  Registry A contacts the Docker Hub to verify the token (token must
-    corresponds to the repository name)
-5.  Docker Hub validates the token. Registry A starts reading the stream
-    pushed by docker and store the repository (with its images)
-6.  docker contacts the Docker Hub to give checksums for upload images
-
-> **Note:**
-> **It's possible not to use the Docker Hub at all!** In this case, a deployed
-> version of the Registry is deployed to store and serve images. Those
-> images are not authenticated and the security is not guaranteed.
-
-> **Note:**
-> **Docker Hub can be replaced!** For a private Registry deployed, a custom
-> Docker Hub can be used to serve and validate token according to different
-> policies.
-
-Docker computes the checksums and submit them to the Docker Hub at the end of
-the push. When a repository name does not have checksums on the Docker Hub,
-it means that the push is in progress (since checksums are submitted at
-the end).
-
-**API (pushing repos foo/bar):**
-
-1.  (Docker -> Docker Hub) PUT /v1/repositories/foo/bar/
-
-**Headers**:
-
-        Authorization: Basic sdkjfskdjfhsdkjfh== X-Docker-Token:
-        true
-
-**Action**:
-
-- in Docker Hub, we allocated a new repository, and set to
-  initialized
-
-**Body**:
-
-(The body contains the list of images that are going to be
-pushed, with empty checksums. The checksums will be set at
-the end of the push):
-
-        [{“id”: “9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f”}]
-
-2.  (Docker Hub -> Docker) 200 Created
-
-**Headers**:
-
-        WWW-Authenticate: Token
-        signature=123abc,repository=”foo/bar”,access=write
-        X-Docker-Endpoints: registry.docker.io [, registry2.docker.io]
-
-3.  (Docker -> Registry) PUT /v1/images/98765432_parent/json
-
-**Headers**:
-
-        Authorization: Token
-        signature=123abc,repository=”foo/bar”,access=write
-
-4.  (Registry->Docker Hub) GET /v1/repositories/foo/bar/images
-
-**Headers**:
-
-        Authorization: Token
-        signature=123abc,repository=”foo/bar”,access=write
-
-**Action**:
-
-- Docker Hub:
-  will invalidate the token.
-- Registry:
-  grants a session (if token is approved) and fetches
-  the images id
-
-5.  (Docker -> Registry) PUT /v1/images/98765432_parent/json
-
-**Headers**:
-
-        Authorization: Token
-        signature=123abc,repository=”foo/bar”,access=write
-        Cookie: (Cookie provided by the Registry)
-
-6.  (Docker -> Registry) PUT /v1/images/98765432/json
-
-**Headers**:
-
-        Cookie: (Cookie provided by the Registry)
-
-7.  (Docker -> Registry) PUT /v1/images/98765432_parent/layer
-
-**Headers**:
-
-        Cookie: (Cookie provided by the Registry)
-
-8.  (Docker -> Registry) PUT /v1/images/98765432/layer
-
-**Headers**:
-
-        X-Docker-Checksum: sha256:436745873465fdjkhdfjkgh
-
-9.  (Docker -> Registry) PUT /v1/repositories/foo/bar/tags/latest
-
-**Headers**:
-
-        Cookie: (Cookie provided by the Registry)
-
-**Body**:
-
-        “98765432”
-
-10. (Docker -> Docker Hub) PUT /v1/repositories/foo/bar/images
-
-**Headers**:
-
-        Authorization: Basic 123oislifjsldfj== X-Docker-Endpoints:
-        registry1.docker.io (no validation on this right now)
-
-**Body**:
-
-        (The image, id`s, tags and checksums)
-        [{“id”:
-        “9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f”,
-        “checksum”:
-        “b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087”}]
-
-**Return**:
-
-        HTTP 204
-
-> **Note:** If push fails and they need to start again, what happens in the Docker Hub,
-> there will already be a record for the namespace/name, but it will be
-> initialized. Should we allow it, or mark as name already used? One edge
-> case could be if someone pushes the same thing at the same time with two
-> different shells.
-
-If it's a retry on the Registry, Docker has a cookie (provided by the
-registry after token validation). So the Docker Hub won't have to provide a
-new token.
-
-### Delete
-
-If you need to delete something from the Docker Hub or registry, we need a
-nice clean way to do that. Here is the workflow.
-
-1.  Docker contacts the Docker Hub to request a delete of a repository
-    `samalba/busybox` (authentication required with user credentials)
-2.  If authentication works and repository is valid, `samalba/busybox`
-    is marked as deleted and a temporary token is returned
-3.  Send a delete request to the registry for the repository (along with
-    the token)
-4.  Registry A contacts the Docker Hub to verify the token (token must
-    corresponds to the repository name)
-5.  Docker Hub validates the token. Registry A deletes the repository and
-    everything associated to it.
-6.  docker contacts the Docker Hub to let it know it was removed from the
-    registry, the Docker Hub removes all records from the database.
-
-> **Note**:
-> The Docker client should present an "Are you sure?" prompt to confirm
-> the deletion before starting the process. Once it starts it can't be
-> undone.
-
-**API (deleting repository foo/bar):**
-
-1.  (Docker -> Docker Hub) DELETE /v1/repositories/foo/bar/
-
-**Headers**:
-
-        Authorization: Basic sdkjfskdjfhsdkjfh== X-Docker-Token:
-        true
-
-**Action**:
-
-- in Docker Hub, we make sure it is a valid repository, and set
-  to deleted (logically)
-
-**Body**:
-
-        Empty
-
-2.  (Docker Hub -> Docker) 202 Accepted
-
-**Headers**:
-
-        WWW-Authenticate: Token
-        signature=123abc,repository=”foo/bar”,access=delete
-        X-Docker-Endpoints: registry.docker.io [, registry2.docker.io]
-        # list of endpoints where this repo lives.
-
-3.  (Docker -> Registry) DELETE /v1/repositories/foo/bar/
-
-**Headers**:
-
-        Authorization: Token
-        signature=123abc,repository=”foo/bar”,access=delete
-
-4.  (Registry->Docker Hub) PUT /v1/repositories/foo/bar/auth
-
-**Headers**:
-
-        Authorization: Token
-        signature=123abc,repository=”foo/bar”,access=delete
-
-**Action**:
-
-- Docker Hub:
-  will invalidate the token.
-- Registry:
-  deletes the repository (if token is approved)
-
-5.  (Registry -> Docker) 200 OK
-
-        200 If success 403 if forbidden 400 if bad request 404
-        if repository isn't found
-
-6.  (Docker -> Docker Hub) DELETE /v1/repositories/foo/bar/
-
-**Headers**:
-
-        Authorization: Basic 123oislifjsldfj== X-Docker-Endpoints:
-        registry-1.docker.io (no validation on this right now)
-
-**Body**:
-
-        Empty
-
-**Return**:
-
-        HTTP 200
-
-## How to use the Registry in standalone mode
-
-The Docker Hub has two main purposes (along with its fancy social features):
-
- - Resolve short names (to avoid passing absolute URLs all the time):
-
-    username/projectname ->
-    https://registry.docker.io/users/<username>/repositories/<projectname>/
-    team/projectname ->
-    https://registry.docker.io/team/<team>/repositories/<projectname>/
-
- - Authenticate a user as a repos owner (for a central referenced
-    repository)
-
-### Without a Docker Hub
-
-Using the Registry without the Docker Hub can be useful to store the images
-on a private network without having to rely on an external entity
-controlled by Docker Inc.
-
-In this case, the registry will be launched in a special mode
-(-standalone? ne? -no-index?). In this mode, the only thing which changes is
-that Registry will never contact the Docker Hub to verify a token. It will be
-the Registry owner responsibility to authenticate the user who pushes
-(or even pulls) an image using any mechanism (HTTP auth, IP based,
-etc...).
-
-In this scenario, the Registry is responsible for the security in case
-of data corruption since the checksums are not delivered by a trusted
-entity.
-
-As hinted previously, a standalone registry can also be implemented by
-any HTTP server handling GET/PUT requests (or even only GET requests if
-no write access is necessary).
-
-### With a Docker Hub
-
-The Docker Hub data needed by the Registry are simple:
-
- - Serve the checksums
- - Provide and authorize a Token
-
-In the scenario of a Registry running on a private network with the need
-of centralizing and authorizing, it's easy to use a custom Docker Hub.
-
-The only challenge will be to tell Docker to contact (and trust) this
-custom Docker Hub. Docker will be configurable at some point to use a
-specific Docker Hub, it'll be the private entity responsibility (basically
-the organization who uses Docker in a private environment) to maintain
-the Docker Hub and the Docker's configuration among its consumers.
-
-## The API
-
-The first version of the api is available here:
-[https://github.com/jpetazzo/docker/blob/acd51ecea8f5d3c02b00a08176171c59442df8b3/docs/images-repositories-push-pull.md](https://github.com/jpetazzo/docker/blob/acd51ecea8f5d3c02b00a08176171c59442df8b3/docs/images-repositories-push-pull.md)
-
-### Images
-
-The format returned in the images is not defined here (for layer and
-JSON), basically because Registry stores exactly the same kind of
-information as Docker uses to manage them.
-
-The format of ancestry is a line-separated list of image ids, in age
-order, i.e. the image's parent is on the last line, the parent of the
-parent on the next-to-last line, etc.; if the image has no parent, the
-file is empty.
-
-    GET /v1/images/<image_id>/layer
-    PUT /v1/images/<image_id>/layer
-    GET /v1/images/<image_id>/json
-    PUT /v1/images/<image_id>/json
-    GET /v1/images/<image_id>/ancestry
-    PUT /v1/images/<image_id>/ancestry
-
-### Users
-
-### Create a user (Docker Hub)
-
-    POST /v1/users:
-
-**Body**:
-
-    {"email": "[sam@docker.com](mailto:sam%40docker.com)",
-    "password": "toto42", "username": "foobar"`}
-
-**Validation**:
-
-- **username**: min 4 character, max 30 characters, must match the
-  regular expression [a-z0-9_].
-- **password**: min 5 characters
-
-**Valid**:
-
-     return HTTP 201
-
-Errors: HTTP 400 (we should create error codes for possible errors) -
-invalid json - missing field - wrong format (username, password, email,
-etc) - forbidden name - name already exists
-
-> **Note**:
-> A user account will be valid only if the email has been validated (a
-> validation link is sent to the email address).
-
-### Update a user (Docker Hub)
-
-    PUT /v1/users/<username>
-
-**Body**:
-
-    {"password": "toto"}
-
-> **Note**:
-> We can also update email address, if they do, they will need to reverify
-> their new email address.
-
-### Login (Docker Hub)
-
-Does nothing else but asking for a user authentication. Can be used to
-validate credentials. HTTP Basic Auth for now, maybe change in future.
-
-GET /v1/users
-
-**Return**:
-- Valid: HTTP 200
-- Invalid login: HTTP 401
-- Account inactive: HTTP 403 Account is not Active
-
-### Tags (Registry)
-
-The Registry does not know anything about users. Even though
-repositories are under usernames, it's just a namespace for the
-registry. Allowing us to implement organizations or different namespaces
-per user later, without modifying the Registry's API.
-
-The following naming restrictions apply:
-
- - Namespaces must match the same regular expression as usernames (See
-    4.2.1.)
- - Repository names must match the regular expression [a-zA-Z0-9-_.]
-
-### Get all tags:
-
-    GET /v1/repositories/<namespace>/<repository_name>/tags
-
-    **Return**: HTTP 200
-    [
-        {
-            "layer": "9e89cc6f",
-            "name": "latest"
-        },
-        {
-            "layer": "b486531f",
-            "name": "0.1.1",
-        }
-    ]
-
-**4.3.2 Read the content of a tag (resolve the image id):**
-
-    GET /v1/repositories/<namespace>/<repo_name>/tags/<tag>
-
-**Return**:
-
-    "9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f"
-
-**4.3.3 Delete a tag (registry):**
-
-    DELETE /v1/repositories/<namespace>/<repo_name>/tags/<tag>
-
-### 4.4 Images (Docker Hub)
-
-For the Docker Hub to “resolve” the repository name to a Registry location,
-it uses the X-Docker-Endpoints header. In other terms, this requests
-always add a `X-Docker-Endpoints` to indicate the
-location of the registry which hosts this repository.
-
-**4.4.1 Get the images:**
-
-    GET /v1/repositories/<namespace>/<repo_name>/images
-
-    **Return**: HTTP 200
-    [{“id”:
-    “9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f”,
-    “checksum”:
-    “[md5:b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087](md5:b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087)”}]
-
-### Add/update the images:
-
-You always add images, you never remove them.
-
-    PUT /v1/repositories/<namespace>/<repo_name>/images
-
-**Body**:
-
-    [ {“id”:
-    “9e89cc6f0bc3c38722009fe6857087b486531f9a779a0c17e3ed29dae8f12c4f”,
-    “checksum”:
-    “sha256:b486531f9a779a0c17e3ed29dae8f12c4f9e89cc6f0bc3c38722009fe6857087”}
-    ]
-
-**Return**:
-
-    204
-
-### Repositories
-
-### Remove a Repository (Registry)
-
-DELETE /v1/repositories/<namespace>/<repo_name>
-
-Return 200 OK
-
-### Remove a Repository (Docker Hub)
-
-This starts the delete process. see 2.3 for more details.
-
-DELETE /v1/repositories/<namespace>/<repo_name>
-
-Return 202 OK
-
-## Chaining Registries
-
-It's possible to chain Registries server for several reasons:
-
- - Load balancing
- - Delegate the next request to another server
-
-When a Registry is a reference for a repository, it should host the
-entire images chain in order to avoid breaking the chain during the
-download.
-
-The Docker Hub and Registry use this mechanism to redirect on one or the
-other.
-
-Example with an image download:
-
-On every request, a special header can be returned:
-
-    X-Docker-Endpoints: server1,server2
-
-On the next request, the client will always pick a server from this
-list.
-
-## Authentication and authorization
-
-### On the Docker Hub
-
-The Docker Hub supports both “Basic” and “Token” challenges. Usually when
-there is a `401 Unauthorized`, the Docker Hub replies
-this:
-
-    401 Unauthorized
-    WWW-Authenticate: Basic realm="auth required",Token
-
-You have 3 options:
-
-1.  Provide user credentials and ask for a token
-
-**Header**:
-
-        Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
-        X-Docker-Token: true
-
-In this case, along with the 200 response, you'll get a new token
-(if user auth is ok): If authorization isn't correct you get a 401
-response. If account isn't active you will get a 403 response.
-
-**Response**:
-
-        200 OK
-        X-Docker-Token: Token
-        signature=123abc,repository=”foo/bar”,access=read
-
-
-2.  Provide user credentials only
-
-**Header**:
-
-        Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
-
-3.  Provide Token
-
-**Header**:
-
-        Authorization: Token
-        signature=123abc,repository=”foo/bar”,access=read
-
-### 6.2 On the Registry
-
-The Registry only supports the Token challenge:
-
-    401 Unauthorized
-    WWW-Authenticate: Token
-
-The only way is to provide a token on `401 Unauthorized`
-responses:
-
-    Authorization: Token signature=123abc,repository="foo/bar",access=read
-
-Usually, the Registry provides a Cookie when a Token verification
-succeeded. Every time the Registry passes a Cookie, you have to pass it
-back the same cookie.:
-
-    200 OK
-    Set-Cookie: session="wD/J7LqL5ctqw8haL10vgfhrb2Q=?foo=UydiYXInCnAxCi4=&timestamp=RjEzNjYzMTQ5NDcuNDc0NjQzCi4="; Path=/; HttpOnly
-
-Next request:
-
-    GET /(...)
-    Cookie: session="wD/J7LqL5ctqw8haL10vgfhrb2Q=?foo=UydiYXInCnAxCi4=&timestamp=RjEzNjYzMTQ5NDcuNDc0NjQzCi4="
-
-## Document version
-
- - 1.0 : May 6th 2013 : initial release
- - 1.1 : June 1st 2013 : Added Delete Repository and way to handle new
-    source namespace.
-

docs/userguide/image_management.md

@@ -0,0 +1,53 @@
+<!--[metadata]>
++++
+alias = [ "/reference/api/hub_registry_spec/"]
+title = "Image management"
+description = "Documentation for docker Registry and Registry API"
+keywords = ["docker, registry, api,  hub"]
+[menu.main]
+parent="mn_docker_hub"
+weight=-1
++++
+<![end-metadata]-->
+
+# Image management
+
+The Docker Engine provides a client which you can use to create images on the command line or through a build process. You can run these images in a container or publish them for others to use. Storing the images you create, searching for images you might want, or publishing images others might use are all elements of image management.
+
+This section provides an overview of the major features and products Docker provides for image management.
+ 
+
+## Docker Hub
+
+The [Docker Hub](https://docs.docker.com/docker-hub/) is responsible for centralizing information about user accounts, images, and public name spaces. It has different components:
+
+ - Web UI
+ - Meta-data store (comments, stars, list public repositories)
+ - Authentication service
+ - Tokenization
+
+There is only one instance of the Docker Hub, run and managed by Docker Inc. This public Hub is useful for most individuals and smaller companies.
+
+## Docker Registry and the Docker Trusted Registry
+
+The Docker Registry is a component of Docker's ecosystem.  A registry is a
+storage and content delivery system, holding named Docker images, available in
+different tagged versions. For example, the image `distribution/registry`, with
+tags `2.0` and `latest`. Users interact with a registry by using docker push and
+pull commands. For example, `docker pull myregistry.com/stevvooe/batman:voice`.
+
+The Docker Hub has its own registry which, like the Hub itself, is run and managed by Docker. There are other ways to obtain a registry. You can purchase the [Docker Trusted Registry](https://docs.docker.com/dockter-trusted-registry) product to run on your company's network. Alternatively, you can use the Docker Registry component to build a private registry. For information about using a registry, see overview for the [Docker Registry](https://docs.docker.com/registry).
+
+
+## Content Trust
+
+When transferring data among networked systems, *trust* is a central concern. In
+particular, when communicating over an untrusted medium such as the internet, it
+is critical to ensure the integrity and publisher of the all the data a system
+operates on. You use Docker to push and pull images (data) to a registry.
+Content trust gives you the ability to both verify the integrity and the
+publisher of all the data received from a registry over any channel. 
+
+[Content trust](/security/trust) is currently only available for users of the
+public Docker Hub. It is currently not available for the Docker Trusted Registry
+or for private registries.