Merge pull request #15701 from moxiegirl/819-publish-cherrypicks

819 publish cherrypicks
Update volumes userguide
2026-08-19 20:26:54 +00:00 · 2015-08-19 13:41:37 -07:00 · 2015-08-19 10:07:50 -07:00 · 2015-08-19 10:07:39 -07:00 · 2015-08-19 10:06:47 -07:00 · 2015-08-19 10:06:38 -07:00
107 changed files with 4227 additions and 5244 deletions
@@ -1,5 +1,96 @@
 # Changelog
 ## 1.8.0 (2015-08-11)
 ### Distribution
 + Trusted pull, push and build, disabled by default
 * Make tar layers deterministic between registries
 * Don't allow deleting the image of running containers
 * Check if a tag name to load is a valid digest
 * Allow one character repository names
 * Add a more accurate error description for invalid tag name
 * Make build cache ignore mtime
 ### Cli
 + Add support for DOCKER_CONFIG/--config to specify config file dir
 + Add --type flag  for docker inspect command
 + Add formatting options to `docker ps` with `--format`
 + Replace `docker -d` with new subcommand `docker daemon`
 * Zsh completion updates and improvements
 * Add some missing events to bash completion
 * Support daemon urls with base paths in `docker -H`
 * Validate status= filter to docker ps
 * Display when a container is in --net=host in docker ps
 * Extend docker inspect to export image metadata related to graph driver
 * Restore --default-gateway{,-v6} daemon options
 * Add missing unpublished ports in docker ps
 * Allow duration strings in `docker events` as --since/--until
 * Expose more mounts information in `docker inspect`
 ### Runtime
 + Add new Fluentd logging driver
 + Allow `docker import` to load from local files
 + Add logging driver for GELF via UDP
 + Allow to copy files from host to containers with `docker cp`
 + Promote volume drivers from experimental to master
 + Add rollover log driver, and --log-driver-opts flag
 + Add memory swappiness tuning options
 * Remove cgroup read-only flag when privileged
 * Make /proc, /sys, & /dev readonly for readonly containers
 * Add cgroup bind mount by default
 * Overlay: Export metadata for container and image in `docker inspect`
 * Devicemapper: external device activation
 * Devicemapper: Compare uuid of base device on startup
 * Remove RC4 from the list of registry cipher suites
 * Add syslog-facility option
 * LXC execdriver compatibility with recent LXC versions
 * Mark LXC execriver as deprecated (to be removed with the migration to runc)
 ### Plugins
 * Separate plugin sockets and specs locations
 * Allow TLS connections to plugins
 ### Bug fixes
 - Add missing 'Names' field to /containers/json API output
 - Make `docker rmi --dangling` safe when pulling
 - Devicemapper: Change default basesize to 100G
 - Go Scheduler issue with sync.Mutex and gcc
 - Fix issue where Search API endpoint would panic due to empty AuthConfig
 - Set image canonical names correctly
 - Check dockerinit only if lxc driver is used
 - Fix ulimit usage of nproc
 - Always attach STDIN if -i,--interactive is specified
 - Show error messages when saving container state fails
 - Fixed incorrect assumption on --bridge=none treated as disable network
 - Check for invalid port specifications in host configuration
 - Fix endpoint leave failure for --net=host mode
 - Fix goroutine leak in the stats API if the container is not running
 - Check for apparmor file before reading it
 - Fix DOCKER_TLS_VERIFY being ignored
 - Set umask to the default on startup
 - Correct the message of pause and unpause a non-running container
 - Adjust disallowed CpuShares in container creation
 - ZFS: correctly apply selinux context
 - Display empty string instead of <nil> when IP opt is nil
 - `docker kill` returns error when container is not running
 - Fix COPY/ADD quoted/json form
 - Fix goroutine leak on logs -f with no output
 - Remove panic in nat package on invalid hostport
 - Fix container linking in Fedora 22
 - Fix error caused using default gateways outside of the allocated range
 - Format times in inspect command with a template as RFC3339Nano
 - Make registry client to accept 2xx and 3xx http status responses as successful
 - Fix race issue that caused the daemon to crash with certain layer downloads failed in a specific order.
 - Fix error when the docker ps format was not valid.
 - Remove redundant ip forward check.
 - Fix issue trying to push images to repository mirrors.
 - Fix error cleaning up network entrypoints when there is an initialization issue.
 ## 1.7.1 (2015-07-14)
 #### Runtime
@@ -1 +1 @@
-1.8.0-dev
+1.8.0
@@ -6,8 +6,24 @@ COPY . /src
 COPY . /docs/content/
-WORKDIR /docs/content
+RUN svn checkout https://github.com/docker/compose/trunk/docs /docs/content/compose
 RUN svn checkout https://github.com/docker/swarm/trunk/docs /docs/content/swarm
 RUN svn checkout https://github.com/docker/machine/trunk/docs /docs/content/machine
 RUN svn checkout https://github.com/docker/distribution/trunk/docs /docs/content/registry
 RUN svn checkout https://github.com/kitematic/kitematic/trunk/docs /docs/content/kitematic
 RUN svn checkout https://github.com/docker/tutorials/trunk/docs /docs/content/
 RUN svn checkout https://github.com/docker/opensource/trunk/docs /docs/content/opensource
 RUN /docs/content/touch-up.sh
-WORKDIR /docs
+
 # Sed to process GitHub Markdown
 # 1-2 Remove comment code from metadata block
 # 3 Change ](/word to ](/project/ in links
 # 4 Change ](word.md) to ](/project/word)
 # 5 Remove .md extension from link text
 # 6 Change ](../ to ](/project/word) 
 # 7 Change ](../../ to ](/project/ --> not implemented
 # 
 # 
 RUN /src/pre-process.sh /docs
@@ -11,7 +11,7 @@ parent = "smn_images"
 # Create a base image
 So you want to create your own [*Base Image*](
-/terms/image/#base-image)? Great!
+/reference/glossary/#base-image)? Great!
 The specific process will depend heavily on the Linux distribution you
 want to package. We have some examples below, and you are encouraged to
@@ -11,111 +11,7 @@ weight = 7
 # Using certificates for repository client verification
-In [Running Docker with HTTPS](/articles/https), you learned that, by default,
+The orginal content was deprecated. For information about configuring
-Docker runs via a non-networked Unix socket and TLS must be enabled in order
+cerficates, see  [deploying a registry
-to have the Docker client and the daemon communicate securely over HTTPS.
+server](http://docs.docker.com/registry/deploying/). To reach an older version
-
+of this content, refer to an older version of the documentation. 
 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.
@@ -57,7 +57,7 @@ These options :
 - Set `tls` to true with the server certificate and key specified using `--tlscert` and `--tlskey` respectively
 - Listen for connections on `tcp://192.168.59.3:2376`
-The command line reference has the [complete list of daemon flags](/reference/commandline/cli/#daemon)
+The command line reference has the [complete list of daemon flags](/reference/commandline/daemon)
 with explanations.
 ## Ubuntu
@@ -114,7 +114,7 @@ These options :
 - Set `tls` to true with the server certificate and key specified using `--tlscert` and `--tlskey` respectively
 - Listen for connections on `tcp://192.168.59.3:2376`
-The command line reference has the [complete list of daemon flags](/reference/commandline/cli/#daemon)
+The command line reference has the [complete list of daemon flags](/reference/commandline/daemon)
 with explanations.
@@ -207,7 +207,7 @@ These options :
 - Set `tls` to true with the server certificate and key specified using `--tlscert` and `--tlskey` respectively
 - Listen for connections on `tcp://192.168.59.3:2376`
-The command line reference has the [complete list of daemon flags](/reference/commandline/cli/#daemon)
+The command line reference has the [complete list of daemon flags](/reference/commandline/daemon)
 with explanations.
 5. Save and close the file.
@@ -11,81 +11,8 @@ weight = 8
 # Run a local registry mirror
-## Why?
+The orginal content was deprecated. [An archived
-
+version](https://docs.docker.com/v1.6/articles/registry_mirror) is available in
-If you have multiple instances of Docker running in your environment
+the 1.7 documentation. For information about configuring mirrors with the latest
-(e.g., multiple physical or virtual machines, all running the Docker
+Docker Registry version, please file a support request with [the Distribution
-daemon), each time one of them requires an image that it doesn't have
+project](https://github.com/docker/distribution/issues). 
 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.
@@ -1,86 +0,0 @@
 <!--[metadata]>
 +++
 title = "Accounts on Docker Hub"
 description = "Docker Hub accounts"
 keywords = ["Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, docs,  documentation"]
 [menu.main]
 parent = "smn_pubhub"
 weight = 1
 +++
 <![end-metadata]-->
 # Accounts on Docker Hub
 ## Docker Hub accounts
 You can `search` for Docker images and `pull` them from [Docker
 Hub](https://hub.docker.com) without signing in or even having an
 account. However, in order to `push` images, leave comments or to *star*
 a repository, you are going to need a [Docker
 Hub](https://hub.docker.com) account.
 ### Registration for a Docker Hub account
 You can get a [Docker Hub](https://hub.docker.com) account by
 [signing up for one here](https://hub.docker.com/account/signup/). A valid
 email address is required to register, which you will need to verify for
 account activation.
 ### Email activation process
 You need to have at least one verified email address to be able to use your
 [Docker Hub](https://hub.docker.com) account. If you can't find the validation email,
 you can request another by visiting the [Resend Email Confirmation](
 https://hub.docker.com/account/resend-email-confirmation/) page.
 ### Password reset process
 If you can't access your account for some reason, you can reset your password
 from the [*Password Reset*](https://hub.docker.com/account/forgot-password/)
 page.
 ## Organizations and groups
 A Docker Hub organization contains public and private repositories just like
 a user account. Access to push, pull or create these organisation owned repositories
 is allocated by defining groups of users and then assigning group rights to
 specific repositories. This allows you to distribute limited access
 Docker images, and to select which Docker Hub users can publish new images.
 ### Creating and viewing organizations
 You can see what organizations [you belong to and add new organizations](
 https://hub.docker.com/account/organizations/) from the Account Settings
 tab. They are also listed below your user name on your repositories page
 and in your account profile.
 ![organizations](/docker-hub/hub-images/orgs.png)
 ### Organization groups
 Users in the `Owners` group of an organization can create and modify the
 membership of groups.
 Unless they are the organization's `Owner`, users can only see groups of which they
 are members.
 ![groups](/docker-hub/hub-images/groups.png)
 ### Repository group permissions
 Use organization groups to manage the users that can interact with your repositories.
 You must be in an organization's `Owners` group to create a new group, Hub
 repository, or automated build. As an `Owner`, you then delegate the following
 repository access rights to groups:
 | Access Right | Description                                                                                                                                                                                                                                                                |
 |--------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | `Read`       | Users with this right can view, search, and pull a private repository.                                                                                                                                                                                                     |
 | `Write`      | Users with this right can push to non-automated repositories on the Docker Hub.                                                                                                                                                                                            |
 | `Admin`      | Users with this right can modify a repository's "Description", "Collaborators" rights. They can also mark a repository as unlisted, change its  "Public/Private" status and "Delete" the repository. Finally, `Admin` rights are required to read the build log on a repo. |
 |              |                                                                                                                                                                                                                                                                            |
 Regardless of their actual access rights, users with unverified email addresses
 have `Read` access to the repository. Once they have verified their address,
 they have their full access rights as granted on the organization.
@@ -1,465 +0,0 @@
 <!--[metadata]>
 +++
 title = "Automated Builds on Docker Hub"
 description = "Docker Hub Automated Builds"
 keywords = ["Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, docs, documentation, trusted, builds, trusted builds,  automated builds"]
 [menu.main]
 parent = "smn_pubhub"
 weight = 3
 +++
 <![end-metadata]-->
 # Automated Builds on Docker Hub
 ## About Automated Builds
 *Automated Builds* are a special feature of Docker Hub which allow you to
 use [Docker Hub's](https://hub.docker.com) build clusters to automatically
 create images from a GitHub or Bitbucket repository containing a `Dockerfile`
 The system will clone your repository and build the image described by the
 `Dockerfile` using the directory the `Dockerfile` is in (and subdirectories)
 as the build context. The resulting automated image will then be uploaded
 to the Docker Hub registry and marked as an *Automated Build*.
 Automated Builds have several advantages:
 * Users of *your* Automated Build can trust that the resulting
 image was built exactly as specified.
 * The `Dockerfile` will be available to anyone with access to
 your repository on the Docker Hub registry.
 * Because the process is automated, Automated Builds help to
 make sure that your repository is always up to date.
 * Not having to push local Docker images to Docker Hub saves 
 you both network bandwidth and time.
 Automated Builds are supported for both public and private repositories
 on both [GitHub](http://github.com) and [Bitbucket](https://bitbucket.org/).
 To use Automated Builds, you must have an [account on Docker Hub](
 https://docs.docker.com/userguide/dockerhub/#creating-a-docker-hub-account)
 and on GitHub and/or Bitbucket. In either case, the account needs
 to be properly validated and activated before you can link to it.
 The first time you to set up an Automated Build, your
 [Docker Hub](https://hub.docker.com) account will need to be linked to
 a GitHub or Bitbucket account.
 This will allow the registry to see your repositories.
 If you have previously linked your Docker Hub account, and want to view or modify
 that link, click on the "Manage - Settings" link in the sidebar, and then
 "Linked Accounts" in your Settings sidebar.
 ## Automated Builds from GitHub
 If you've previously linked your Docker Hub account to your GitHub account,
 you'll be able to skip to the [Creating an Automated Build](#creating-an-automated-build).
 ### Linking your Docker Hub account to a GitHub account
 > *Note:*
 > Automated Builds currently require *read* and *write* access since
 > [Docker Hub](https://hub.docker.com) needs to setup a GitHub service
 > hook. We have no choice here, this is how GitHub manages permissions, sorry!
 > We do guarantee nothing else will be touched in your account.
 To get started, log into your Docker Hub account and click the
 "+ Add Repository" button at the upper right of the screen. Then select
 [Automated Build](https://registry.hub.docker.com/builds/add/).
 Select the [GitHub service](https://registry.hub.docker.com/associate/github/).
 When linking to GitHub, you'll need to select either "Public and Private",
 or "Limited" linking.
 The "Public and Private" option is the easiest to use,
 as it grants the Docker Hub full access to all of your repositories. GitHub
 also allows you to grant access to repositories belonging to your GitHub
 organizations.
 By choosing the "Limited" linking, your Docker Hub account only gets permission
 to access your public data and public repositories.
 Follow the onscreen instructions to authorize and link your
 GitHub account to Docker Hub. Once it is linked, you'll be able to
 choose a source repository from which to create the Automatic Build.
 You will be able to review and revoke Docker Hub's access by visiting the
 [GitHub User's Applications settings](https://github.com/settings/applications).
 > **Note**: If you delete the GitHub account linkage that is used for one of your
 > automated build repositories, the previously built images will still be available.
 > If you re-link to that GitHub account later, the automated build can be started
 > using the "Start Build" button on the Hub, or if the webhook on the GitHub repository
 > still exists, will be triggered by any subsequent commits.
 ### Auto builds and limited linked GitHub accounts.
 If you selected to link your GitHub account with only a "Limited" link, then
 after creating your automated build, you will need to either manually trigger a
 Docker Hub build using the "Start a Build" button, or add the GitHub webhook
 manually, as described in [GitHub Service Hooks](#github-service-hooks).
 ### Changing the GitHub user link
 If you want to remove, or change the level of linking between your GitHub account
 and the Docker Hub, you need to do this in two places.
 First, remove the "Linked Account" from your Docker Hub "Settings".
 Then go to your GitHub account's Personal settings, and in the "Applications"
 section, "Revoke access".
 You can now re-link your account at any time.
 ### GitHub organizations
 GitHub organizations and private repositories forked from organizations will be
 made available to auto build using the "Docker Hub Registry" application, which
 needs to be added to the organization - and then will apply to all users.
 To check, or request access, go to your GitHub user's "Setting" page, select the
 "Applications" section from the left side bar, then click the "View" button for
 "Docker Hub Registry".
 ![Check User access to GitHub](/docker-hub/hub-images/gh-check-user-org-dh-app-access.png)
 The organization's administrators may need to go to the Organization's "Third
 party access" screen in "Settings" to Grant or Deny access to the Docker Hub
 Registry application. This change will apply to all organization members.
 ![Check Docker Hub application access to Organization](/docker-hub/hub-images/gh-check-admin-org-dh-app-access.png)
 More detailed access controls to specific users and GitHub repositories would be
 managed using the GitHub People and Teams interfaces.
 ### Creating an Automated Build
 You can [create an Automated Build](
 https://registry.hub.docker.com/builds/github/select/) from any of your
 public or private GitHub repositories that have a `Dockerfile`.
 Once you've selected the source repository, you can then configure:
 - The Hub user/org the repository is built to - either your Hub account name,
 or the name of any Hub organizations your account is in
 - The Docker repository name the image is built to
 - If the Docker repository should be "Public" or "Private"
  You can change the accessibility options after the repository has been created.
  If you add a Private repository to a Hub user, then you can only add other users
  as collaborators, and those users will be able to view and pull all images in that 
  repository. To configure more granular access permissions, such as using groups of 
  users or allow different users access to different image tags, then you need
  to add the Private repository to a Hub organization that your user has Administrator
  privilege on.
 - If you want the GitHub to notify the Docker Hub when a commit is made, and thus trigger
  a rebuild of all the images in this automated build.
 You can also select one or more
 - The git branch/tag, which repository sub-directory to use as the context
 - The Docker image tag name
 You can set a description for the repository by clicking "Description" link in the righthand side bar after the automated build - note that the "Full Description" will be over-written next build from the README.md file.
 has been created.
 ### GitHub private submodules
 If your GitHub repository contains links to private submodules, you'll get an
 error message in your build.
 Normally, the Docker Hub sets up a deploy key in your GitHub repository.
 Unfortunately, GitHub only allows a repository deploy key to access a single repository.
 To work around this, you need to create a dedicated user account in GitHub and attach
 the automated build's deploy key that account. This dedicated build account
 can be limited to read-only access to just the repositories required to build.
 <table class="table table-bordered">
  <thead>
    <tr>
      <th>Step</th>
      <th>Screenshot</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1.</td>
      <td><img src="/docker-hub/hub-images/gh_org_members.png"></td>
      <td>First, create the new account in GitHub. It should be given read-only
      access to the main repository and all submodules that are needed.</td>
    </tr>
    <tr>
      <td>2.</td>
      <td><img src="/docker-hub/hub-images/gh_team_members.png"></td>
      <td>This can be accomplished by adding the account to a read-only team in
      the organization(s) where the main GitHub repository and all submodule
      repositories are kept.</td>
    </tr>
    <tr>
      <td>3.</td>
      <td><img src="/docker-hub/hub-images/gh_repo_deploy_key.png"></td>
      <td>Next, remove the deploy key from the main GitHub repository. This can be done in the GitHub repository's "Deploy keys" Settings section.</td>
    </tr>
    <tr>
      <td>4.</td>
      <td><img src="/docker-hub/hub-images/deploy_key.png"></td>
      <td>Your automated build's deploy key is in the "Build Details" menu
      under "Deploy keys".</td>
    </tr>
    <tr>
      <td>5.</td>
      <td><img src="/docker-hub/hub-images/gh_add_ssh_user_key.png"></td>
      <td>In your dedicated GitHub User account, add the deploy key from your
      Docker Hub Automated Build.</td>
    </tr>
  </tbody>
 </table>
 ### GitHub service hooks
 The GitHub Service hook allows GitHub to notify the Docker Hub when something has
 been committed to that git repository. You will need to add the Service Hook manually
 if your GitHub account is "Limited" linked to the Docker Hub.
 Follow the steps below to configure the GitHub Service hooks for your Automated Build:
 <table class="table table-bordered">
  <thead>
    <tr>
      <th>Step</th>
      <th>Screenshot</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1.</td>
      <td><img src="/docker-hub/hub-images/gh_settings.png"></td>
      <td>Log in to GitHub.com, and go to your Repository page. Click on "Settings" on
      the right side of the page. You must have admin privileges to the repository in order to do this.</td>
    </tr>
    <tr>
      <td>2.</td>
      <td><img src="/docker-hub/hub-images/gh_menu.png" alt="Webhooks & Services"></td>
      <td>Click on "Webhooks & Services" on the left side of the page.</td></tr>
      <tr><td>3.</td>
      <td><img src="/docker-hub/hub-images/gh_service_hook.png" alt="Find the service labeled Docker"></td>
      <td>Find the service labeled "Docker" (or click on "Add service") and click on it.</td></tr>
      <tr><td>4.</td>
      <td><img src="/docker-hub/hub-images/gh_docker-service.png" alt="Activate Service Hooks"></td>
      <td>Make sure the "Active" checkbox is selected and click the "Update service" button to save your changes.</td>
    </tr>
  </tbody>
 </table>
 ## Automated Builds with Bitbucket
 In order to setup an Automated Build, you need to first link your
 [Docker Hub](https://hub.docker.com) account with a Bitbucket account.
 This will allow the registry to see your repositories.
 To get started, log into your Docker Hub account and click the
 "+ Add Repository" button at the upper right of the screen. Then
 select [Automated Build](https://registry.hub.docker.com/builds/add/).
 Select the [Bitbucket source](
 https://registry.hub.docker.com/associate/bitbucket/).
 Then follow the onscreen instructions to authorize and link your
 Bitbucket account to Docker Hub. Once it is linked, you'll be able
 to choose a repository from which to create the Automatic Build.
 ### Creating an Automated Build
 You can [create an Automated Build](
 https://registry.hub.docker.com/builds/bitbucket/select/) from any of your
 public or private Bitbucket repositories with a `Dockerfile`.
 ### Adding a Hook
 When you link your Docker Hub account, a `POST` hook should get automatically
 added to your Bitbucket repository. Follow the steps below to confirm or modify the
 Bitbucket hooks for your Automated Build:
 <table class="table table-bordered">
  <thead>
    <tr>
      <th>Step</th>
      <th>Screenshot</th>
      <th>Description</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1.</td>
      <td><img src="/docker-hub/hub-images/bb_menu.png" alt="Settings" width="180"></td>
      <td>Log in to Bitbucket.org and go to your Repository page. Click on "Settings" on
      the far left side of the page, under "Navigation". You must have admin privileges
      to the repository in order to do this.</td>
    </tr>
    <tr>
      <td>2.</td>
      <td><img src="/docker-hub/hub-images/bb_hooks.png" alt="Hooks" width="180"></td>
      <td>Click on "Hooks" on the near left side of the page, under "Settings".</td></tr>
    <tr>
      <td>3.</td>
      <td><img src="/docker-hub/hub-images/bb_post-hook.png" alt="Docker Post Hook"></td><td>You should now see a list of hooks associated with the repo, including a <code>POST</code> hook that points at
      registry.hub.docker.com/hooks/bitbucket.</td>
    </tr>
  </tbody>
 </table>
 ## The Dockerfile and Automated Builds
 During the build process, Docker will copy the contents of your `Dockerfile`.
 It will also add it to the [Docker Hub](https://hub.docker.com) for the Docker
 community (for public repositories) or approved team members/orgs (for private
 repositories) to see on the repository page.
 ### README.md
 If you have a `README.md` file in your repository, it will be used as the
 repository's full description.The build process will look for a
 `README.md` in the same directory as your `Dockerfile`.
 > **Warning:**
 > If you change the full description after a build, it will be
 > rewritten the next time the Automated Build has been built. To make changes,
 > modify the `README.md` from the Git repository.
 ## Remote Build triggers
 If you need a way to trigger Automated Builds outside of GitHub or Bitbucket,
 you can set up a build trigger. When you turn on the build trigger for an
 Automated Build, it will give you a URL to which you can send POST requests.
 This will trigger the Automated Build, much as with a GitHub webhook.
 Build triggers are available under the Settings menu of each Automated Build
 repository on the Docker Hub.
 ![Build trigger screen](/docker-hub/hub-images/build-trigger.png)
 You can use `curl` to trigger a build:
 ```
 $ curl --data "build=true" -X POST https://registry.hub.docker.com/u/svendowideit/testhook/trigger/be579c
 82-7c0e-11e4-81c4-0242ac110020/
 OK
 ```
 > **Note:**
 > You can only trigger one build at a time and no more than one
 > every five minutes. If you already have a build pending, or if you
 > recently submitted a build request, those requests *will be ignored*.
 > To verify everything is working correctly, check the logs of last
 > ten triggers on the settings page .
 ## Webhooks
 Automated Builds also include a Webhooks feature. Webhooks can be called
 after a successful repository push is made. This includes when a new tag is added
 to an existing image.
 The webhook call will generate a HTTP POST with the following JSON
 payload:
 ```
 {
  "callback_url": "https://registry.hub.docker.com/u/svendowideit/testhook/hook/2141b5bi5i5b02bec211i4eeih0242eg11000a/",
  "push_data": {
    "images": [
        "27d47432a69bca5f2700e4dff7de0388ed65f9d3fb1ec645e2bc24c223dc1cc3",
        "51a9c7c1f8bb2fa19bcd09789a34e63f35abb80044bc10196e304f6634cc582c",
        ...
    ],
    "pushed_at": 1.417566161e+09,
    "pusher": "trustedbuilder"
  },
  "repository": {
    "comment_count": 0,
    "date_created": 1.417494799e+09,
    "description": "",
    "dockerfile": "#\n# BUILD\u0009\u0009docker build -t svendowideit/apt-cacher .\n# RUN\u0009\u0009docker run -d -p 3142:3142 -name apt-cacher-run apt-cacher\n#\n# and then you can run containers with:\n# \u0009\u0009docker run -t -i -rm -e http_proxy http://192.168.1.2:3142/ debian bash\n#\nFROM\u0009\u0009ubuntu\nMAINTAINER\u0009SvenDowideit@home.org.au\n\n\nVOLUME\u0009\u0009[\"/var/cache/apt-cacher-ng\"]\nRUN\u0009\u0009apt-get update ; apt-get install -yq apt-cacher-ng\n\nEXPOSE \u0009\u00093142\nCMD\u0009\u0009chmod 777 /var/cache/apt-cacher-ng ; /etc/init.d/apt-cacher-ng start ; tail -f /var/log/apt-cacher-ng/*\n",
    "full_description": "Docker Hub based automated build from a GitHub repo",
    "is_official": false,
    "is_private": true,
    "is_trusted": true,
    "name": "testhook",
    "namespace": "svendowideit",
    "owner": "svendowideit",
    "repo_name": "svendowideit/testhook",
    "repo_url": "https://registry.hub.docker.com/u/svendowideit/testhook/",
    "star_count": 0,
    "status": "Active"
  }
 }
 ```
 Webhooks are available under the Settings menu of each Repository.  
 Use a tool like [requestb.in](http://requestb.in/) to test your webhook.
 > **Note**: The Docker Hub servers use an elastic IP range, so you can't
 > filter requests by IP.
 ### Webhook chains
 Webhook chains allow you to chain calls to multiple services. For example,
 you can use this to trigger a deployment of your container only after
 it has been successfully tested, then update a separate Changelog once the
 deployment is complete.
 After clicking the "Add webhook" button, simply add as many URLs as necessary
 in your chain.
 The first webhook in a chain will be called after a successful push. Subsequent
 URLs will be contacted after the callback has been validated.
 ### Validating a callback
 In order to validate a callback in a webhook chain, you need to
 1. Retrieve the `callback_url` value in the request's JSON payload.
 1. Send a POST request to this URL containing a valid JSON body.
 > **Note**: A chain request will only be considered complete once the last
 > callback has been validated.
 To help you debug or simply view the results of your webhook(s),
 view the "History" of the webhook available on its settings page.
 ### Callback JSON data
 The following parameters are recognized in callback data:
 * `state` (required): Accepted values are `success`, `failure` and `error`.
  If the state isn't `success`, the webhook chain will be interrupted.
 * `description`: A string containing miscellaneous information that will be
  available on the Docker Hub. Maximum 255 characters.
 * `context`: A string containing the context of the operation. Can be retrieved
  from the Docker Hub. Maximum 100 characters.
 * `target_url`: The URL where the results of the operation can be found. Can be
  retrieved on the Docker Hub.
 *Example callback payload:*
    {
      "state": "success",
      "description": "387 tests PASSED",
      "context": "Continuous integration by Acme CI",
      "target_url": "http://ci.acme.com/results/afd339c1c3d27"
    }
 ## Repository links
 Repository links are a way to associate one Automated Build with
 another. If one gets updated, the linking system triggers a rebuild
 for the other Automated Build. This makes it easy to keep all your
 Automated Builds up to date.
 To add a link, go to the repository for the Automated Build you want to
 link to and click on *Repository Links* under the Settings menu at
 right. Then, enter the name of the repository that you want have linked.
 > **Warning:**
 > You can add more than one repository link, however, you should
 > do so very carefully. Creating a two way relationship between Automated Builds will
 > cause an endless build loop.
@@ -1,20 +0,0 @@
 <!--[metadata]>
 +++
 draft = true
 title = "The Docker Hub Registry help"
 description = "The Docker Registry help documentation home"
 keywords = ["Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, docs,  documentation"]
 [menu.main]
 parent = "smn_pubhub"
 +++
 <![end-metadata]-->
 # The Docker Hub Registry help
 ## Introduction
 For your questions about the [Docker Hub](https://hub.docker.com) registry you
 can use [this documentation](docs.md).
 If you can not find something you are looking for, please feel free to
 [contact us](https://docker.com/resources/support/).
@@ -1,38 +0,0 @@
 <!--[metadata]>
 +++
 title = "The Docker Hub"
 description = "The Docker Help documentation home"
 keywords = ["Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, docs, documentation, accounts, organizations, repositories,  groups"]
 [menu.main]
 parent = "smn_pubhub"
 +++
 <![end-metadata]-->
 # Docker Hub
 The [Docker Hub](https://hub.docker.com) provides a cloud-based platform service
 for distributed applications, including container image distribution and change
 management, user and team collaboration, and lifecycle workflow automation.
 ![DockerHub](/docker-hub/hub-images/hub.png)
 ## [Finding and pulling images](./userguide.md)
 Find out how to [use the Docker Hub](./userguide.md) to find and pull Docker
 images to run or build upon.
 ## [Accounts](./accounts.md)
 [Learn how to create](./accounts.md) a Docker Hub
 account and manage your organizations and groups.
 ## [Your Repositories](./repos.md)
 Find out how to share your Docker images in [Docker Hub
 repositories](./repos.md) and how to store and manage private images.
 ## [Automated builds](./builds.md)
 Learn how to automate your build and deploy pipeline with [Automated
 Builds](./builds.md)
@@ -1,113 +0,0 @@
 <!--[metadata]>
 +++
 title = "Official Repositories on Docker Hub"
 description = "Guidelines for Official Repositories on Docker Hub"
 keywords = ["Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, docs, official, image,  documentation"]
 [menu.main]
 parent = "smn_pubhub"
 weight = 4
 +++
 <![end-metadata]-->
 # Official Repositories on Docker Hub
 The Docker [Official Repositories](http://registry.hub.docker.com/official) are
 a curated set of Docker repositories that are promoted on Docker Hub. They are
 designed to:
 * Provide essential base OS repositories (for example,
  [`ubuntu`](https://registry.hub.docker.com/_/ubuntu/),
  [`centos`](https://registry.hub.docker.com/_/centos/)) that serve as the
  starting point for the majority of users.
 * Provide drop-in solutions for popular programming language runtimes, data
  stores, and other services, similar to what a Platform-as-a-Service (PAAS)
  would offer.
 * Exemplify [`Dockerfile` best practices](/articles/dockerfile_best-practices)
  and provide clear documentation to serve as a reference for other `Dockerfile`
  authors.
 * Ensure that security updates are applied in a timely manner. This is
  particularly important as many Official Repositories are some of the most
  popular on Docker Hub.
 * Provide a channel for software vendors to redistribute up-to-date and
  supported versions of their products. Organization accounts on Docker Hub can
  also serve this purpose, without the careful review or restrictions on what
  can be published.
 Docker, Inc. sponsors a dedicated team that is responsible for reviewing and
 publishing all Official Repositories content. This team works in collaboration
 with upstream software maintainers, security experts, and the broader Docker
 community.
 While it is preferable to have upstream software authors maintaining their
 corresponding Official Repositories, this is not a strict requirement. Creating
 and maintaining images for Official Repositories is a public process. It takes
 place openly on GitHub where participation is encouraged. Anyone can provide
 feedback, contribute code, suggest process changes, or even propose a new
 Official Repository.
 ## Should I use Official Repositories?
 New Docker users are encouraged to use the Official Repositories in their
 projects. These repositories have clear documentation, promote best practices,
 and are designed for the most common use cases. Advanced users are encouraged to
 review the Official Repositories as part of their `Dockerfile` learning process.
 A common rationale for diverging from Official Repositories is to optimize for
 image size. For instance, many of the programming language stack images contain
 a complete build toolchain to support installation of modules that depend on
 optimized code. An advanced user could build a custom image with just the
 necessary pre-compiled libraries to save space.
 A number of language stacks such as
 [`python`](https://registry.hub.docker.com/_/python/) and
 [`ruby`](https://registry.hub.docker.com/_/ruby/) have `-slim` tag variants
 designed to fill the need for optimization.  Even when these "slim" variants are
 insufficient, it is still recommended to inherit from an Official Repository
 base OS image to leverage the ongoing maintenance work, rather than duplicating
 these efforts.
 ## How can I get involved?
 All Official Repositories contain a **User Feedback** section in their
 documentation which covers the details for that specific repository. In most
 cases, the GitHub repository which contains the Dockerfiles for an Official
 Repository also has an active issue tracker. General feedback and support
 questions should be directed to `#docker-library` on Freenode IRC.
 ## How do I create a new Official Repository?
 From a high level, an Official Repository starts out as a proposal in the form
 of a set of GitHub pull requests.  You'll find detailed and objective proposal
 requirements in the following GitHub repositories:
 * [docker-library/official-images](https://github.com/docker-library/official-images)
 * [docker-library/docs](https://github.com/docker-library/docs)
 The Official Repositories team, with help from community contributors, formally
 review each proposal and provide feedback to the author. This initial review
 process may require a bit of back and forth before the proposal is accepted.
 There are also subjective considerations during the review process. These
 subjective concerns boil down to the basic question: "is this image generally
 useful?"  For example, the [`python`](https://registry.hub.docker.com/_/python/)
 Official Repository is "generally useful" to the large Python developer
 community, whereas an obscure text adventure game written in Python last week is
 not.
 When a new proposal is accepted, the author becomes responsible for keeping
 their images up-to-date and responding to user feedback.  The Official
 Repositories team becomes responsible for publishing the images and
 documentation on Docker Hub.  Updates to the Official Repository follow the same
 pull request process, though with less review. The Official Repositories team
 ultimately acts as a gatekeeper for all changes, which helps mitigate the risk
 of quality and security issues from being introduced.
 > **Note**: If you are interested in proposing an Official Repository, but would
 > like to discuss it with Docker, Inc. privately first, please send your
 > inquiries to partners@docker.com.  There is no fast-track or pay-for-status
 > option.
@@ -1,193 +0,0 @@
 <!--[metadata]>
 +++
 title = "Your Repositories on Docker Hub"
 description = "Your Repositories on Docker Hub"
 keywords = ["Docker, docker, registry, accounts, plans, Dockerfile, Docker Hub, webhooks, docs,  documentation"]
 [menu.main]
 parent = "smn_pubhub"
 weight = 2
 +++
 <![end-metadata]-->
 # Your Hub repositories
 Docker Hub repositories make it possible for you to share images with co-workers,
 customers or the Docker community at large. If you're building your images internally,
 either on your own Docker daemon, or using your own Continuous integration services,
 you can push them to a Docker Hub repository that you add to your Docker Hub user or
 organization account.
 Alternatively, if the source code for your Docker image is on GitHub or Bitbucket,
 you can use an "Automated build" repository, which is built by the Docker Hub
 services. See the [automated builds documentation](./builds.md) to read about
 the extra functionality provided by those services.
 ![repositories](/docker-hub/hub-images/repos.png)
 Your Docker Hub repositories have a number of useful features.
 ## Stars
 Your repositories can be starred and you can star repositories in
 return. Stars are a way to show that you like a repository. They are
 also an easy way of bookmarking your favorites.
 ## Comments
 You can interact with other members of the Docker community and maintainers by
 leaving comments on repositories. If you find any comments that are not
 appropriate, you can flag them for review.
 ## Collaborators and their role
 A collaborator is someone you want to give access to a private
 repository. Once designated, they can `push` and `pull` to your
 repositories. They will not be allowed to perform any administrative
 tasks such as deleting the repository or changing its status from
 private to public.
 > **Note:**
 > A collaborator cannot add other collaborators. Only the owner of
 > the repository has administrative access.
 You can also assign more granular collaborator rights ("Read", "Write", or "Admin")
 on Docker Hub by using organizations and groups. For more information
 see the [accounts documentation](accounts/).
 ## Private repositories
 Private repositories allow you to have repositories that contain images
 that you want to keep private, either to your own account or within an
 organization or group.
 To work with a private repository on [Docker
 Hub](https://hub.docker.com), you will need to add one via the [Add
 Repository](https://registry.hub.docker.com/account/repositories/add/)
 link. You get one private repository for free with your Docker Hub
 account. If you need more accounts you can upgrade your [Docker
 Hub](https://registry.hub.docker.com/plans/) plan.
 Once the private repository is created, you can `push` and `pull` images
 to and from it using Docker.
 > *Note:* You need to be signed in and have access to work with a
 > private repository.
 Private repositories are just like public ones. However, it isn't
 possible to browse them or search their content on the public registry.
 They do not get cached the same way as a public repository either.
 It is possible to give access to a private repository to those whom you
 designate (i.e., collaborators) from its Settings page. From there, you
 can also switch repository status (*public* to *private*, or
 vice-versa). You will need to have an available private repository slot
 open before you can do such a switch. If you don't have any available,
 you can always upgrade your [Docker
 Hub](https://registry.hub.docker.com/plans/) plan.
 ## Webhooks
 A webhook is an HTTP call-back triggered by a specific event.
 You can use a Hub repository webhook to notify people, services, and other
 applications after a new image is pushed to your repository (this also happens
 for Automated builds). For example, you can trigger an automated test or
 deployment to happen as soon as the image is available.
 To get started adding webhooks, go to the desired repository in the Hub,
 and click "Webhooks" under the "Settings" box.
 A webhook is called only after a successful `push` is
 made. The webhook calls are HTTP POST requests with a JSON payload
 similar to the example shown below.
 *Example webhook JSON payload:*
 ```
 {
  "callback_url": "https://registry.hub.docker.com/u/svendowideit/busybox/hook/2141bc0cdec4hebec411i4c1g40242eg110020/",
  "push_data": {
    "images": [
        "27d47432a69bca5f2700e4dff7de0388ed65f9d3fb1ec645e2bc24c223dc1cc3",
        "51a9c7c1f8bb2fa19bcd09789a34e63f35abb80044bc10196e304f6634cc582c",
        ...
    ],
    "pushed_at": 1.417566822e+09,
    "pusher": "svendowideit"
  },
  "repository": {
    "comment_count": 0,
    "date_created": 1.417566665e+09,
    "description": "",
    "full_description": "webhook triggered from a 'docker push'",
    "is_official": false,
    "is_private": false,
    "is_trusted": false,
    "name": "busybox",
    "namespace": "svendowideit",
    "owner": "svendowideit",
    "repo_name": "svendowideit/busybox",
    "repo_url": "https://registry.hub.docker.com/u/svendowideit/busybox/",
    "star_count": 0,
    "status": "Active"
 }
 ```
 <TODO: does it tell you what tag was updated?>
 For testing, you can try an HTTP request tool like [requestb.in](http://requestb.in/).
 > **Note**: The Docker Hub servers use an elastic IP range, so you can't
 > filter requests by IP.
 ### Webhook chains
 Webhook chains allow you to chain calls to multiple services. For example,
 you can use this to trigger a deployment of your container only after
 it has been successfully tested, then update a separate Changelog once the
 deployment is complete.
 After clicking the "Add webhook" button, simply add as many URLs as necessary
 in your chain.
 The first webhook in a chain will be called after a successful push. Subsequent
 URLs will be contacted after the callback has been validated.
 ### Validating a callback
 In order to validate a callback in a webhook chain, you need to
 1. Retrieve the `callback_url` value in the request's JSON payload.
 1. Send a POST request to this URL containing a valid JSON body.
 > **Note**: A chain request will only be considered complete once the last
 > callback has been validated.
 To help you debug or simply view the results of your webhook(s),
 view the "History" of the webhook available on its settings page.
 #### Callback JSON data
 The following parameters are recognized in callback data:
 * `state` (required): Accepted values are `success`, `failure` and `error`.
  If the state isn't `success`, the webhook chain will be interrupted.
 * `description`: A string containing miscellaneous information that will be
  available on the Docker Hub. Maximum 255 characters.
 * `context`: A string containing the context of the operation. Can be retrieved
  from the Docker Hub. Maximum 100 characters.
 * `target_url`: The URL where the results of the operation can be found. Can be
  retrieved on the Docker Hub.
 *Example callback payload:*
    {
      "state": "success",
      "description": "387 tests PASSED",
      "context": "Continuous integration by Acme CI",
      "target_url": "http://ci.acme.com/results/afd339c1c3d27"
    }
 ## Mark as unlisted
 By marking a repository as unlisted, you can create a publicly pullable repository
 which will not be in the Hub or commandline search. This allows you to have a limited
 release, but does not restrict access to anyone that is told, or guesses the repository
 name.
@@ -1,63 +0,0 @@
 <!--[metadata]>
 +++
 title = "Docker Hub user guide"
 description = "Docker Hub user guide"
 keywords = ["Docker, docker, registry, Docker Hub, docs,  documentation"]
 [menu.main]
 parent = "smn_pubhub"
 +++
 <![end-metadata]-->
 # Using the Docker Hub
 Docker Hub is used to find and pull Docker images to run or build upon, and to
 distribute and build images for other users to use.
 ![your profile](/docker-hub/hub-images/dashboard.png)
 ## Finding repositories and images
 There are two ways you can search for public repositories and images available
 on the Docker Hub. You can use the "Search" tool on the Docker Hub website, or
 you can `search` for all the repositories and images using the Docker commandline
 tool:
    $ docker search ubuntu
 Both will show you a list of the currently available public repositories on the
 Docker Hub which match the provided keyword.
 If a repository is private or marked as unlisted, it won't be in the repository
 search results. To see all the repositories you have access to and their statuses,
 you can look at your profile page on [Docker Hub](https://hub.docker.com).
 ## Pulling, running and building images
 You can find more information on [working with Docker images](../userguide/dockerimages.md).
 ## Official Repositories
 The Docker Hub contains a number of [Official
 Repositories](http://registry.hub.docker.com/official). These are
 certified repositories from vendors and contributors to Docker. They
 contain Docker images from vendors like Canonical, Oracle, and Red Hat
 that you can use to build applications and services.
 If you use Official Repositories you know you're using an optimized and
 up-to-date image to power your applications.
 > **Note:**
 > If you would like to contribute an Official Repository for your
 > organization, see [Official Repositories on Docker
 > Hub](/docker-hub/official_repos) for more information.
 ## Building and shipping your own repositories and images
 The Docker Hub provides you and your team with a place to build and ship Docker images.
 Collections of Docker images are managed using repositories - 
 You can configure two types of repositories to manage on the Docker Hub:
 [Repositories](./repos.md), which allow you to push images to the Hub from your local Docker daemon,
 and [Automated Builds](./builds.md), which allow you to configure GitHub or Bitbucket to
 trigger the Hub to rebuild repositories when changes are made to the repository.
@@ -96,7 +96,7 @@ which is officially supported by Docker.
 >command fails for the Docker repo during installation. To work around this,
 >add the key directly using the following:
 >
->       $ wget -qO- https://get.docker.com/gpg | sudo apt-key add -
+>       $ curl -sSL https://get.docker.com/gpg | sudo apt-key add -
 ### Uninstallation
@@ -21,7 +21,7 @@ installation mechanisms. Using these packages ensures you get the latest release
 of Docker. If you wish to install using Fedora-managed packages, consult your
 Fedora release documentation for information on Fedora's Docker support.
-##Prerequisites
+## Prerequisites
 Docker requires a 64-bit installation regardless of your Fedora version. Also, your kernel must be 3.10 at minimum. To check your current kernel
 version, open a terminal and use `uname -r` to display your kernel version:
@@ -206,6 +206,24 @@ If you need to add an HTTP Proxy, set a different directory or partition for the
 Docker runtime files, or make other customizations, read our Systemd article to
 learn how to [customize your Systemd Docker daemon options](/articles/systemd/).
 ## Running Docker with a manually-defined network
 If you manually configure your network using `systemd-network` with `systemd` version 219 or higher, containers you start with Docker may be unable to access your network.
 Beginning with version 220, the forwarding setting for a given network (`net.ipv4.conf.<interface>.forwarding`) defaults to *off*. This setting prevents IP forwarding. It also conflicts with Docker which enables the `net.ipv4.conf.all.forwarding` setting within a container.
 To work around this, edit the `<interface>.network` file in
 `/usr/lib/systemd/network/` on your Docker host  (ex: `/usr/lib/systemd/network/80-container-host0.network`) add the following block:
 ```
 [Network]
 ...
 IPForward=kernel
 # OR
 IPForward=true
 ...
 ```
 This configuration allows IP forwarding from the container as expected.
 ## Uninstall
@@ -10,37 +10,34 @@ parent = "smn_engine"
 # Mac OS X
-You can install Docker using Boot2Docker to run `docker` commands at your command-line.
+> **Note**: This release of Docker deprecates the Boot2Docker command line in
-Choose this installation if you are familiar with the command-line or plan to
+> favor of Docker Machine.  Use the Docker Toolbox to install Docker Machine as
-contribute to the Docker project on GitHub.
+> well as the other Docker tools.
-[<img src="/installation/images/kitematic.png" alt="Download Kitematic"
+You install Docker using Docker Toolbox. Docker Toolbox includes the following Docker tools:
 style="float:right;">](https://kitematic.com/download)
-Alternatively, you may want to try <a id="inlinelink" href="https://kitematic.com/"
+* Docker Machine for running the `docker-machine` binary
-target="_blank">Kitematic</a>, an application that lets you set up Docker and
+* Docker Engine for running the `docker` binary
-run containers using a graphical user interface (GUI).
+* Docker Compose for running the `docker-compose` binary
-
+* Kitematic, the Docker GUI
-## Command-line Docker with Boot2Docker
+* a shell preconfigured for a Docker command-line environment
 * Oracle VM VirtualBox 
 Because the Docker daemon uses Linux-specific kernel features, you can't run
-Docker natively in OS X. Instead, you must install the Boot2Docker application.
+Docker natively in OS X. Instead, you must use `docker-machine` to create and
-The application includes a VirtualBox Virtual Machine (VM), Docker itself, and the
+attach to a virtual machine (VM). This machine is a Linux VM that hosts Docker
-Boot2Docker management tool.
+for you on your Mac.
 The Boot2Docker management tool is a lightweight Linux virtual machine made
 specifically to run the Docker daemon on Mac OS X. The VirtualBox VM runs
 completely from RAM, is a small ~24MB download, and boots in approximately 5s.
 **Requirements**
-Your Mac must be running OS X 10.6 "Snow Leopard" or newer to run Boot2Docker.
+Your Mac must be running OS X 10.8 "Mountain Lion" or newer to install the
 Docker Toolbox.
 ### Learn the key concepts before installing
-In a Docker installation on Linux, your machine is both the localhost and the
+In a Docker installation on Linux, your physical machine is both the localhost
-Docker host. In networking, localhost means your computer. The Docker host is
+and the Docker host. In networking, localhost means your computer. The Docker
-the machine on which the containers run.
+host is the computer on which the containers run.
 On a typical Linux installation, the Docker client, the Docker daemon, and any
 containers run directly on your localhost. This means you can address ports on a
@@ -49,135 +46,243 @@ Docker container using standard localhost addressing such as `localhost:8000` or
 ![Linux Architecture Diagram](/installation/images/linux_docker_host.svg)
-In an OS X installation, the `docker` daemon is running inside a Linux virtual
+In an OS X installation, the `docker` daemon is running inside a Linux VM called
-machine provided by Boot2Docker.
+`default`. The `default` is a lightweight Linux VM made specifically to run
 the Docker daemon on Mac OS X. The VM runs completely from RAM, is a small ~24MB
 download, and boots in approximately 5s.
 ![OSX Architecture Diagram](/installation/images/mac_docker_host.svg)
-In OS X, the Docker host address is the address of the Linux VM.
+In OS X, the Docker host address is the address of the Linux VM. When you start
-When you start the `boot2docker` process, the VM is assigned an IP address. Under
+the VM with `docker-machine` it is assigned an IP address. When you start a
-`boot2docker` ports on a container map to ports on the VM. To see this in
+container, the ports on a container map to ports on the VM. To see this in
 practice, work through the exercises on this page.
 ### Installation
-1. Go to the [boot2docker/osx-installer ](
+If you have VirtualBox running, you must shut it down before running the
-   https://github.com/boot2docker/osx-installer/releases/latest) release page.
+installer. 
-4. Download Boot2Docker by clicking `Boot2Docker-x.x.x.pkg` in the "Downloads"
+1. Go to the [Docker Toolbox](https://www.docker.com/toolbox) page.
   section.
-3. Install Boot2Docker by double-clicking the package.
+2. Click the installer link to download.
-    The installer places Boot2Docker and VirtualBox in your "Applications" folder.
+3. Install Docker Toolbox by double-clicking the package or by right-clicking
 and choosing "Open" from the pop-up menu.
-The installation places the `docker` and `boot2docker` binaries in your
+    The installer launches the "Install Docker Toolbox" dialog.
-`/usr/local/bin` directory.
+    
    ![Install Docker Toolbox](/installation/images/mac-welcome-page.png)
 4. Press "Continue" to install the toolbox.
    The installer presents you with options to customize the standard
    installation. 
    ![Standard install](/installation/images/mac-page-two.png)
    By default, the standard Docker Toolbox installation:
    * installs binaries for the Docker tools in `/usr/local/bin` 
    * makes these binaries available to all users 
    * updates any existing VirtualBox installation 
    Change these defaults by pressing "Customize" or "Change
    Install Location."  
 5. Press "Install" to perform the standard installation.
     The system prompts you for your password.
     ![Password prompt](/installation/images/mac-password-prompt.png)
 6. Provide your password to continue with the installation.
     When it completes, the installer provides you with some information you can
     use to complete some common tasks.
     ![All finished](/installation/images/mac-page-finished.png)
 7. Press "Close" to exit.
-## Start the Boot2Docker Application
+## Running a Docker Container
-To run a Docker container, you first start the `boot2docker` VM and then issue
+To run a Docker container, you:
 `docker` commands to create, load, and manage containers. You can launch
 `boot2docker` from your Applications folder or from the command line.
-> **NOTE**: Boot2Docker is designed as a development tool. You should not use
+* create a new (or start an existing) Docker virtual machine 
->  it in production environments.
+* switch your environment to your new VM
 * use the `docker` client to create, load, and manage containers
-### From the Applications folder
+Once you create a machine, you can reuse it as often as you like. Like any
 VirtualBox VM, it maintains its configuration between uses.
-When you launch the "Boot2Docker" application from your "Applications" folder, the
+There are two ways to use the installed tools, from the Docker Quickstart Terminal or
-application:
+[from your shell](#from-your-shell).
-* opens a terminal window
+### From the Docker Quickstart Terminal
-* creates a $HOME/.boot2docker directory
+1. Open the "Applications" folder or the "Launchpad".
-* creates a VirtualBox ISO and certs
+2. Find the Docker Quickstart Terminal  and double-click to launch it.
-* starts a VirtualBox VM running the `docker` daemon
+    The application:
-Once the launch completes, you can run `docker` commands. A good way to verify
+    * opens a terminal window
-your setup succeeded is to run the `hello-world` container.
+    * creates a VM called `default` if it doesn't exists, starts the VM if it does
    * points the terminal environment to this VM
-    $ docker run hello-world
+    Once the launch completes, the Docker Quickstart Terminal reports:
-    Unable to find image 'hello-world:latest' locally
+    
-    511136ea3c5a: Pull complete
+     ![All finished](/installation/images/mac-success.png)
-    31cbccb51277: Pull complete
+     
-    e45a5af57b00: Pull complete
+    Now, you can run `docker` commands. 
    hello-world:latest: The image you are pulling has been verified.
    Important: image verification is a tech preview feature and should not be
    relied on to provide security.
    Status: Downloaded newer image for hello-world:latest
    Hello from Docker.
    This message shows that your installation appears to be working correctly.
-    To generate this message, Docker took the following steps:
+3. Verify your setup succeeded by running the `hello-world` container.
    1. The Docker client contacted the Docker daemon.
    2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
       (Assuming it was not already locally available.)
    3. The Docker daemon created a new container from that image which runs the
       executable that produces the output you are currently reading.
    4. The Docker daemon streamed that output to the Docker client, which sent it
       to your terminal.
-    To try something more ambitious, you can run an Ubuntu container with:
+        $ docker run hello-world
-    $ docker run -it ubuntu bash
+        Unable to find image 'hello-world:latest' locally
        511136ea3c5a: Pull complete
        31cbccb51277: Pull complete
        e45a5af57b00: Pull complete
        hello-world:latest: The image you are pulling has been verified.
        Important: image verification is a tech preview feature and should not be
        relied on to provide security.
        Status: Downloaded newer image for hello-world:latest
        Hello from Docker.
        This message shows that your installation appears to be working correctly.
-    For more examples and ideas, visit:
+        To generate this message, Docker took the following steps:
-    http://docs.docker.com/userguide/
+        1. The Docker client contacted the Docker daemon.
        2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
           (Assuming it was not already locally available.)
        3. The Docker daemon created a new container from that image which runs the
           executable that produces the output you are currently reading.
        4. The Docker daemon streamed that output to the Docker client, which sent it
           to your terminal.
        To try something more ambitious, you can run an Ubuntu container with:
        $ docker run -it ubuntu bash
        For more examples and ideas, visit:
        http://docs.docker.com/userguide/
-A more typical way to start and stop `boot2docker` is using the command line.
+A more typical way to interact with the Docker tools is from your regular shell command line.
-### From your command line
+### From your shell
-Initialize and run `boot2docker` from the command line, do the following:
+This section assumes you are running a Bash shell. You may be running a
 different shell such as C Shell but the commands are the same.
-1. Create a new Boot2Docker VM.
+1. Create a new Docker VM.
-        $ boot2docker init
+        $ docker-machine create --driver virtualbox default
        Creating VirtualBox VM...
        Creating SSH key...
        Starting VirtualBox VM...
        Starting VM...
        To see how to connect Docker to this machine, run: docker-machine env default
-    This creates a new virtual machine. You only need to run this command once.
+    This creates a new `default` in VirtualBox.
    ![default](/installation/images/default.png)
-2. Start the `boot2docker` VM.
+    The command also creates a machine configuration in the
    `~/.docker/machine/machines/default` directory. You only need to run the
    `create` command once. Then, you can use `docker-machine` to start, stop,
    query, and otherwise manage the VM from the command line.
 2. List your available machines.
-        $ boot2docker start
+        $ docker-machine ls
        NAME                ACTIVE   DRIVER       STATE     URL                         SWARM
        default             *        virtualbox   Running   tcp://192.168.99.101:2376  
    If you have previously installed the deprecated Boot2Docker application or
    run the Docker Quickstart Terminal, you may have a `dev` VM as well.  When you
    created `default`, the `docker-machine` command provided instructions
    for learning how to connect the VM.
-3. Display the environment variables for the Docker client.
+3. Get the environment commands for your new VM.
-        $ boot2docker shellinit
+        $ docker-machine env default
-        Writing /Users/mary/.boot2docker/certs/boot2docker-vm/ca.pem
+        export DOCKER_TLS_VERIFY="1"
-        Writing /Users/mary/.boot2docker/certs/boot2docker-vm/cert.pem
+        export DOCKER_HOST="tcp://192.168.99.101:2376"
-        Writing /Users/mary/.boot2docker/certs/boot2docker-vm/key.pem
+        export DOCKER_CERT_PATH="/Users/mary/.docker/machine/machines/default"
-            export DOCKER_HOST=tcp://192.168.59.103:2376
+        export DOCKER_MACHINE_NAME="default"
-            export DOCKER_CERT_PATH=/Users/mary/.boot2docker/certs/boot2docker-vm
+        # Run this command to configure your shell: 
-            export DOCKER_TLS_VERIFY=1
+        # eval "$(docker-machine env default)"
 4. Connect your shell to the `default` machine.
-    The specific paths and address on your machine will be different.
+        $ eval "$(docker-machine env default)"
 4. To set the environment variables in your shell do the following:
        $ eval "$(boot2docker shellinit)"
    You can also set them manually by using the `export` commands `boot2docker`
    returns.
 5. Run the `hello-world` container to verify your setup.
        $ docker run hello-world
-## Basic Boot2Docker exercises
+## Learn about your Toolbox installation
-At this point, you should have `boot2docker` running and the `docker` client
+Toolbox installs the Docker Engine binary, the Docker binary on your system. When you
-environment initialized. To verify this, run the following commands:
+use the Docker Quickstart Terminal or create a `default` manually, Docker
 Machine updates the `~/.docker/machine/machines/default` folder to your
 system. This folder contains the configuration for the VM.
-    $ boot2docker status
+You can create multiple VMs on your system with Docker Machine. So, you may have
-    $ docker version
+more than one VM folder if you have more than one VM. To remove a VM, use the
 `docker-machine rm <machine-name>` command.
-Work through this section to try some practical container tasks using `boot2docker` VM.
+## Migrate from Boot2Docker
 If you were using Boot2Docker previously, you have a pre-existing Docker
 `boot2docker-vm` VM on your local system.  To allow Docker Machine to manage
 this older VM, you can migrate it.
 1. Open a terminal or the Docker CLI on your system.
 2. Type the following command.
        $ docker-machine create -d virtualbox --virtualbox-import-boot2docker-vm boot2docker-vm docker-vm
 3. Use the `docker-machine` command to interact with the migrated VM.  
 The `docker-machine` subcommands are slightly different than the `boot2docker`
 subcommands. The table below lists the equivalent `docker-machine` subcommand
 and what it does:
 |  `boot2docker` | `docker-machine` | `docker-machine` description                             |
 |----------------|------------------|----------------------------------------------------------|
 | init           | create           | Creates a new docker host.                               |
 | up             | start            | Starts a stopped machine.                                |
 | ssh            | ssh              | Runs a command or interactive ssh session on the machine.|
 | save           | -                | Not applicable.                                          |
 | down           | stop             | Stops a running machine.                                 |
 | poweroff       | stop             | Stops a running machine.                                 |
 | reset          | restart          | Restarts a running machine.                              |
 | config         | inspect          | Prints machine configuration details.                    |
 | status         | ls               | Lists all machines and their status.                     |
 | info           | inspect          | Displays a machine's details.                            |
 | ip             | ip               | Displays the machine's ip address.                       |
 | shellinit      | env              | Displays shell commands needed to configure your shell to interact with a machine |
 | delete         | rm               | Removes a machine.                                       |
 | download       | -                | Not applicable.                                          |
 | upgrade        | upgrade          | Upgrades a machine's Docker client to the latest stable release. |
 ## Example of Docker on Mac OS X
 Work through this section to try some practical container tasks on a VM. At this
 point, you should have a VM running and be connected to it through your shell.
 To verify this, run the following commands:
    $ docker-machine ls
    NAME                ACTIVE   DRIVER       STATE     URL                         SWARM
    default             *        virtualbox   Running   tcp://192.168.99.100:2376   
 The `ACTIVE` machine, in this case `default`, is the one your environment is pointing to.
 ### Access container ports
@@ -212,11 +317,11 @@ Work through this section to try some practical container tasks using `boot2dock
    This didn't work. The reason it doesn't work is your `DOCKER_HOST` address is
    not the localhost address (0.0.0.0) but is instead the address of the
-    `boot2docker` VM.
+    your Docker VM.
-5. Get the address of the `boot2docker` VM.
+5. Get the address of the `default` VM.
-        $ boot2docker ip
+        $ docker-machine ip default
        192.168.59.103
 6. Enter the `http://192.168.59.103:49157` address in your browser:
@@ -232,7 +337,7 @@ Work through this section to try some practical container tasks using `boot2dock
 ### Mount a volume on the container
-When you start `boot2docker`, it automatically shares your `/Users` directory
+When you start a container it automatically shares your `/Users/username` directory
 with the VM. You can use this share point to mount directories onto your container.
 The next exercise demonstrates how to do this.
@@ -254,7 +359,8 @@ The next exercise demonstrates how to do this.
 5. Start a new `nginx` container and replace the `html` folder with your `site` directory.
-        $ docker run -d -P -v $HOME/site:/usr/share/nginx/html --name mysite nginx
+        $ docker run -d -P -v $HOME/site:/usr/share/nginx/html \
          --name mysite nginx
 6. Get the `mysite` container's port.
@@ -274,85 +380,53 @@ The next exercise demonstrates how to do this.
    ![Cool page](/installation/images/cool_view.png)
-9. Stop and then remove your running `mysite` container.
+10. Stop and then remove your running `mysite` container.
        $ docker stop mysite
        $ docker rm mysite
 ## Upgrade Boot2Docker
-If you running Boot2Docker 1.4.1 or greater, you can upgrade Boot2Docker from
+## Upgrade Docker Toolbox
 the command line. If you are running an older version, you should use the
 package provided by the `boot2docker` repository.
-### From the command line
+To upgrade Docker Toolbox, download an re-run [the Docker Toolbox
-
+installer](https://docker.com/toolbox/).
 To upgrade from 1.4.1 or greater, you can do this:
 1. Open a terminal on your local machine.
 2. Stop the `boot2docker` application.
        $ boot2docker stop
 3. Run the upgrade command.
        $ boot2docker upgrade
-### Use the installer
+## Uninstall Docker Toolbox 
-To upgrade any version of Boot2Docker, do this:
+To uninstall, do the following:
-1. Open a terminal on your local machine.
+1. List your machines.
-2. Stop the `boot2docker` application.
+        $ docker-machine ls
        NAME                ACTIVE   DRIVER       STATE     URL                         SWARM
        dev                 *        virtualbox   Running   tcp://192.168.99.100:2376   
        my-docker-machine            virtualbox   Stopped                               
        default                      virtualbox   Stopped  
-        $ boot2docker stop
+2. Remove each machine.
-3. Go to the [boot2docker/osx-installer ](
+        $ docker-machine rm dev
-   https://github.com/boot2docker/osx-installer/releases/latest) release page.
+        Successfully removed dev
     Removing a machine deletes its VM from VirtualBox and from the
     `~/.docker/machine/machines` directory.
-4. Download Boot2Docker by clicking `Boot2Docker-x.x.x.pkg` in the "Downloads"
+3. Remove the Docker Quickstart Terminal and Kitematic from your "Applications" folder.
   section.
-2. Install Boot2Docker by double-clicking the package.
+4. Remove the `docker`, `docker-compose`, and `docker-machine` commands from the `/usr/local/bin` folder.
-    The installer places Boot2Docker in your "Applications" folder.
+        $ rm /usr/local/bin/docker
 5. Delete the `~/.docker` folder from your system.
-## Uninstallation 
+## Learning more 
-1. Go to the [boot2docker/osx-installer ](
+Use `docker-machine help` to list the full command line reference for Docker Machine. For more
-   https://github.com/boot2docker/osx-installer/releases/latest) release page. 
+information about using SSH or SCP to access a VM, see [the Docker Machine
 documentation](https://docs.docker.com/machine/).
-2. Download the source code by clicking `Source code (zip)` or
+You can continue with the [Docker User Guide](/userguide). If you are
-   `Source code (tar.gz)` in the "Downloads" section.
+interested in using the Kitematic GUI, see the [Kitermatic user
-
+guide](/kitematic/userguide/).
 3. Extract the source code.
 4. Open a terminal on your local machine.
 5. Change to the directory where you extracted the source code:
        $ cd <path to extracted source code>
 6. Make sure the uninstall.sh script is executable:
        $ chmod +x uninstall.sh
 7. Run the uninstall.sh script:
        $ ./uninstall.sh
 ## Learning more and acknowledgement
 Use `boot2docker help` to list the full command line reference. For more
 information about using SSH or SCP to access the Boot2Docker VM, see the README
 at  [Boot2Docker repository](https://github.com/boot2docker/boot2docker).
 Thanks to Chris Jones whose [blog](http://viget.com/extend/how-to-use-docker-on-os-x-the-missing-guide)  
 inspired me to redo this page.
 Continue with the [Docker User Guide](/userguide).
@@ -96,7 +96,7 @@ To upgrade your kernel and install the additional packages, do the following:
        $ sudo reboot
-5. After your system reboots, go ahead and [install Docker](#installing-docker-on-ubuntu).
+5. After your system reboots, go ahead and [install Docker](#installation).
 ### For Saucy 13.10 (64 bit)
@@ -111,18 +111,18 @@ install Docker using the following:
 1. Log into your Ubuntu installation as a user with `sudo` privileges.
-2. Verify that you have `wget` installed.
+2. Verify that you have `curl` installed.
-        $ which wget
+        $ which curl
-    If `wget` isn't installed, install it after updating your manager:
+    If `curl` isn't installed, install it after updating your manager:
        $ sudo apt-get update
-        $ sudo apt-get install wget
+        $ sudo apt-get install curl
 3. Get the latest Docker package.
-        $ wget -qO- https://get.docker.com/ | sh
+        $ curl -sSL https://get.docker.com/ | sh
    The system prompts you for your `sudo` password. Then, it downloads and
    installs Docker and its dependencies.
@@ -132,7 +132,7 @@ install Docker using the following:
 >command fails for the Docker repo during installation. To work around this,
 >add the key directly using the following:
 >
->       $ wget -qO- https://get.docker.com/gpg | sudo apt-key add -
+>       $ curl -sSL https://get.docker.com/gpg | sudo apt-key add -
 4. Verify `docker` is installed correctly.
@@ -197,9 +197,14 @@ When users run Docker, they may see these messages when working with an image:
    WARNING: Your kernel does not support cgroup swap limit. WARNING: Your
    kernel does not support swap limit capabilities. Limitation discarded.
-To prevent these messages, enable memory and swap accounting on your system. To
+To prevent these messages, enable memory and swap accounting on your
-enable these on system using GNU GRUB (GNU GRand Unified Bootloader), do the
+system.  Enabling memory and swap accounting does induce both a memory
-following.
+overhead and a performance degradation even when Docker is not in
 use. The memory overhead is about 1% of the total available
 memory. The performance degradation is roughly 10%.
 To enable memory and swap on system using GNU GRUB (GNU GRand Unified
 Bootloader), do the following:
 1. Log into Ubuntu as a user with `sudo` privileges.
@@ -339,9 +344,9 @@ to start the docker daemon on boot
 ## Upgrade Docker
-To install the latest version of Docker with `wget`:
+To install the latest version of Docker with `curl`:
-    $ wget -qO- https://get.docker.com/ | sh
+    $ curl -sSL https://get.docker.com/ | sh
 ## Uninstallation
@@ -9,118 +9,315 @@ parent = "smn_engine"
 <![end-metadata]-->
 # Windows
 > **Note:**
 > Docker has been tested on Windows 7 and 8.1; it may also run on older versions.
 > Your processor needs to support hardware virtualization.
-The Docker Engine uses Linux-specific kernel features, so to run it on Windows
+> **Note**: This release of Docker deprecates the Boot2Docker command line in
-we need to use a lightweight virtual machine (VM).  You use the **Windows Docker
+> favor of Docker Machine.  Use the Docker Toolbox to install Docker Machine as
-Client** to control the virtualized Docker Engine to build, run, and manage
+> well as the other Docker tools.
 Docker containers.
-To make this process easier, we've designed a helper application called
+You install Docker using Docker Toolbox. Docker Toolbox includes the following Docker tools:
 [Boot2Docker](https://github.com/boot2docker/boot2docker) which creates a Linux virtual
 machine on Windows to run Docker on a Linux operating system.
-Although you will be using Windows Docker client, the docker engine hosting the
+* Docker Machine for running the `docker-machine` binary
-containers will still be running on Linux. Until the Docker engine for Windows
+* Docker Engine for running the `docker` binary
-is developed, you can launch only Linux containers from your Windows machine.
+* Kitematic, the Docker GUI
 * a shell preconfigured for a Docker command-line environment
 * Oracle VM VirtualBox 
 Because the Docker daemon uses Linux-specific kernel features, you can't run
 Docker natively in Windows. Instead, you must use `docker-machine` to create and attach to a Docker VM on your machine. This VM hosts Docker for you on your Windows system.
 The Docker VM is lightweight Linux virtual machine made specifically to run the
 Docker daemon on Windows. The VirtualBox VM runs completely from RAM, is a
 small ~24MB download, and boots in approximately 5s.
 ## Requirements
 Your machine must be running Windows 7.1, 8/8.1 or newer to run Docker. Windows 10 is not currently supported. To find out what version of Windows you have:
 1. Right click the Windows message and choose **System**. 
    ![Which version](/installation/images/win_ver.png)
    If you aren't using a supported version, you could consider upgrading your
    operating system.
 2. Make sure your Windows system supports Hardware Virtualization Technology and that virtualization is enabled.
    #### For Windows 8 or 8.1
 	  Choose **Start > Task Manager** and navigate to the **Performance** tab.          
 	  Under **CPU** you should see the following:
      ![Release page](/installation/images/virtualization.png)
    If virtualization is not enabled on your system, follow the manufacturer's instructions for enabling it.
    ### For Windows 7 
 	  Run the <a
 	  href="http://www.microsoft.com/en-us/download/details.aspx?id=592"
 	  target="_blank"> Microsoft® Hardware-Assisted Virtualization Detection
 	  Tool</a> and follow the on-screen instructions.
 > **Note**: If you have Docker hosts running and you don't wish to do a Docker Toolbox
 installation, you can install the `docker.exe` using the *unofficial* Windows package
 manager Chocolately. For information on how to do this, see [Docker package on
 Chocolatey](http://chocolatey.org/packages/docker).
 ### Learn the key concepts before installing
 In a Docker installation on Linux, your machine is both the localhost and the
 Docker host. In networking, localhost means your computer. The Docker host is
 the machine on which the containers run.
 On a typical Linux installation, the Docker client, the Docker daemon, and any
 containers run directly on your localhost. This means you can address ports on a
 Docker container using standard localhost addressing such as `localhost:8000` or
 `0.0.0.0:8376`.
 ![Linux Architecture Diagram](/installation/images/linux_docker_host.svg)
 In an Windows installation, the `docker` daemon is running inside a Linux virtual
 machine. You use the Windows Docker client to talk to the Docker host VM. Your
 Docker containers run inside this host. 
 ![Windows Architecture Diagram](/installation/images/win_docker_host.svg)
-## Demonstration
+In Windows, the Docker host address is the address of the Linux VM. When you
 start the VM with `docker-machine` it is assigned an IP address. When you start
 a container, the ports on a container map to ports on the VM. To see this in
 practice, work through the exercises on this page.
 <iframe width="640" height="480" src="//www.youtube.com/embed/TjMU3bDX4vo?rel=0" frameborder="0" allowfullscreen></iframe>
-## Installation
+### Installation
-1. Download the latest release of the
+If you have VirtualBox running, you must shut it down before running the
-   [Docker for Windows Installer](https://github.com/boot2docker/windows-installer/releases/latest).
+installer. 
 2. Run the installer, which will install Docker Client for Windows, VirtualBox,
   Git for Windows (MSYS-git), the boot2docker Linux ISO, and the Boot2Docker
   management tool.
   ![](/installation/images/windows-installer.png)
 3. Run the **Boot2Docker Start** shortcut from your Desktop or “Program Files →
   Boot2Docker for Windows”.
   The Start script will ask you to enter an ssh key passphrase - the simplest
   (but least secure) is to just hit [Enter].
-4. The **Boot2Docker Start** will start a unix shell already configured to manage
+1. Go to the [Docker Toolbox](https://www.docker.com/toolbox) page.
   Docker running inside the virtual machine. Run `docker version` to see
   if it is working correctly:
-![](/installation/images/windows-boot2docker-start.png)
+2. Click the installer link to download.
-## Running Docker
+3. Install Docker Toolbox by double-clicking the installer.
-> **Note:** if you are using a remote Docker daemon, such as Boot2Docker, 
+    The installer launches the "Setup - Docker Toolbox" dialog.
-> then _do not_ type the `sudo` before the `docker` commands shown in the
+    
-> documentation's examples.
+    ![Install Docker Toolbox](/installation/images/win-welcome.png)
-**Boot2Docker Start** will automatically start a shell with environment variables
+4. Press "Next" to install the toolbox.
 correctly set so you can start using Docker right away:
-Let's try the `hello-world` example image. Run
+    The installer presents you with options to customize the standard
    installation. By default, the standard Docker Toolbox installation:
    * installs executables for the Docker tools in `C:\Program Files\Docker Toolbox` 
    * updates any existing VirtualBox installation 
    * adds a Docker Inc. folder to your program shortcuts
    * updates your `PATH` environment variable
    * adds desktop icons for the Docker Quickstart Terminal and Kitematic
-    $ docker run hello-world
+    This installation assumes the defaults are acceptable.
 5. Press "Next" until you reach the "Ready to Install" page.
     The system prompts you for your password.
     ![Install](/installation/images/win-page-6.png)
 6. Press "Install"  to continue with the installation.
     When it completes, the installer provides you with some information you can
     use to complete some common tasks.
     ![All finished](/installation/images/windows-finish.png)
 7. Press "Close" to exit.
 ## Running a Docker Container
 To run a Docker container, you:
 * create a new (or start an existing) Docker virtual machine 
 * switch your environment to your new VM
 * use the `docker` client to create, load, and manage containers
 Once you create a machine, you can reuse it as often as you like. Like any
 VirtualBox VM, it maintains its configuration between uses.
 There are several ways to use the installed tools, from the Docker Quickstart Terminal or
 [from your shell](#from-your-shell).
 ### From the Docker Quickstart Terminal
 1. Find the Docker Quickstart Terminal icon on your Desktop and double-click to launch it.
    The application:
    * opens a terminal window
    * creates a `default` if it doesn't exist, starts the VM if it does
    * points the terminal environment to this VM
    Once the launch completes, you can run `docker` commands. 
 3. Verify your setup succeeded by running the `hello-world` container.
        $ docker run hello-world
        Unable to find image 'hello-world:latest' locally
        511136ea3c5a: Pull complete
        31cbccb51277: Pull complete
        e45a5af57b00: Pull complete
        hello-world:latest: The image you are pulling has been verified.
        Important: image verification is a tech preview feature and should not be
        relied on to provide security.
        Status: Downloaded newer image for hello-world:latest
        Hello from Docker.
        This message shows that your installation appears to be working correctly.
        To generate this message, Docker took the following steps:
        1. The Docker client contacted the Docker daemon.
        2. The Docker daemon pulled the "hello-world" image from the Docker Hub.
           (Assuming it was not already locally available.)
        3. The Docker daemon created a new container from that image which runs the
           executable that produces the output you are currently reading.
        4. The Docker daemon streamed that output to the Docker client, which sent it
           to your terminal.
        To try something more ambitious, you can run an Ubuntu container with:
        $ docker run -it ubuntu bash
        For more examples and ideas, visit:
        http://docs.docker.com/userguide/
 This should download the very small `hello-world` image and print a
 `Hello from Docker.` message.
 ## Using Docker from Windows Command Line Prompt (cmd.exe)
-Launch a Windows Command Line Prompt (cmd.exe).
+1. Launch a Windows Command Line Prompt (cmd.exe).
-Boot2Docker command requires `ssh.exe` to be in the PATH, therefore we need to
+    The `docker-machine` command requires `ssh.exe` in your `PATH` environment
-include `bin` folder of the Git installation (which has ssh.exe) to the `%PATH%`
+    variable. This `.exe` is in the MsysGit `bin` folder. 
 environment variable by running:
-    set PATH=%PATH%;"c:\Program Files (x86)\Git\bin"
+2. Add this to the `%PATH%` environment variable by running:
-and then we can run the `boot2docker start` command to start the Boot2Docker VM.
+        set PATH=%PATH%;"c:\Program Files (x86)\Git\bin"
-(Run `boot2docker init` command if you get an error saying machine does not
+        
-exist.) Then copy the instructions for cmd.exe to set the environment variables
+3. Create a new Docker VM.
 to your console window and you are ready to run docker commands such as
 `docker ps`:
-![](/installation/images/windows-boot2docker-cmd.png)
+        docker-machine create --driver virtualbox my-default
        Creating VirtualBox VM...
        Creating SSH key...
        Starting VirtualBox VM...
        Starting VM...
        To see how to connect Docker to this machine, run: docker-machine env my-default
    The command also creates a machine configuration in the
    `C:\USERS\USERNAME\.docker\machine\machines` directory. You only need to run the `create`
    command once. Then, you can use `docker-machine` to start, stop, query, and
    otherwise manage the VM from the command line.
 4. List your available machines.
        C:\Users\mary> docker-machine ls
        NAME                ACTIVE   DRIVER       STATE     URL                         SWARM
        my-default        *        virtualbox   Running   tcp://192.168.99.101:2376  
    If you have previously installed the deprecated Boot2Docker application or
    run the Docker Quickstart Terminal, you may have a `dev` VM as well.  
 5. Get the environment commands for your new VM.
        C:\Users\mary> docker-machine env --shell cmd my-default
 6. Connect your shell to the `my-default` machine.
        C:\Users\mary> eval "$(docker-machine env my-default)"
 7. Run the `hello-world` container to verify your setup.
        C:\Users\mary> docker run hello-world
 ## Using Docker from PowerShell
-Launch a PowerShell window, then add `ssh.exe` to your PATH:
+1. Launch a Windows PowerShell window.
-    $Env:Path = "${Env:Path};c:\Program Files (x86)\Git\bin"
+2. Add `ssh.exe` to your PATH:
-and after running the `boot2docker start` command it will print PowerShell
+        PS C:\Users\mary> $Env:Path = "${Env:Path};c:\Program Files (x86)\Git\bin"
-commands to set the environment variables to connect to the Docker daemon
+        
-running inside the VM. Run these commands and you are ready to run docker
+3. Create a new Docker VM.
 commands such as `docker ps`:
-![](/installation/images/windows-boot2docker-powershell.png)
+        PS C:\Users\mary> docker-machine create --driver virtualbox my-default
 4. List your available machines.
-> NOTE: You can alternatively run `boot2docker shellinit | Invoke-Expression`
+        C:\Users\mary> docker-machine ls
-> command to set the environment variables instead of copying and pasting on
+        NAME                ACTIVE   DRIVER       STATE     URL                         SWARM
-> PowerShell.
+        my-default        *        virtualbox   Running   tcp://192.168.99.101:2376  
 5. Get the environment commands for your new VM.
-# Further Details
+        C:\Users\mary> docker-machine env --shell powershell my-default
 6. Connect your shell to the `my-default` machine.
-The Boot2Docker management tool provides several commands:
+        C:\Users\mary> eval "$(docker-machine env my-default)"
-    $ boot2docker
+7. Run the `hello-world` container to verify your setup.
    Usage: boot2docker.exe [<options>] {help|init|up|ssh|save|down|poweroff|reset|restart|config|status|info|ip|shellinit|delete|download|upgrade|version} [<args>]
-## Upgrading
+        C:\Users\mary> docker run hello-world
 1. Download the latest release of the [Docker for Windows Installer](
   https://github.com/boot2docker/windows-installer/releases/latest)
-2. Run the installer, which will update the Boot2Docker management tool.
+## Learn about your Toolbox installation
-3. To upgrade your existing virtual machine, open a terminal and run:
+Toolbox installs the Docker Engine binary in the `C:\Program Files\Docker
 Toolbox` directory. When you use the Docker Quickstart Terminal or create a
 `default` manually, Docker Machine updates the
 `C:\USERS\USERNAME\.docker\machine\machines\default` folder to your
 system. This folder contains the configuration for the VM.
-        boot2docker stop
+You can create multiple VMs on your system with Docker Machine. So, you may have
-        boot2docker download
+more than one VM folder if you have more than one VM. To remove a VM, use the
-        boot2docker start
+`docker-machine rm <machine-name>` command.
 ## Migrate from Boot2Docker
 If you were using Boot2Docker previously, you have a pre-existing Docker
 `boot2docker-vm` VM on your local system.  To allow Docker Machine to manage
 this older VM, you can migrate it.
 1. Open a terminal or the Docker CLI on your system.
 2. Type the following command.
        $ docker-machine create -d virtualbox --virtualbox-import-boot2docker-vm boot2docker-vm docker-vm
 3. Use the `docker-machine` command to interact with the migrated VM.  
 The `docker-machine` subcommands are slightly different than the `boot2docker`
 subcommands. The table below lists the equivalent `docker-machine` subcommand
 and what it does:
 |  `boot2docker` | `docker-machine` | `docker-machine` description                             |
 |----------------|------------------|----------------------------------------------------------|
 | init           | create           | Creates a new docker host.                               |
 | up             | start            | Starts a stopped machine.                                |
 | ssh            | ssh              | Runs a command or interactive ssh session on the machine.|
 | save           | -                | Not applicable.                                          |
 | down           | stop             | Stops a running machine.                                 |
 | poweroff       | stop             | Stops a running machine.                                 |
 | reset          | restart          | Restarts a running machine.                              |
 | config         | inspect          | Prints machine configuration details.                    |
 | status         | ls               | Lists all machines and their status.                     |
 | info           | inspect          | Displays a machine's details.                            |
 | ip             | ip               | Displays the machine's ip address.                       |
 | shellinit      | env              | Displays shell commands needed to configure your shell to interact with a machine |
 | delete         | rm               | Removes a machine.                                       |
 | download       | -                | Not applicable.                                          |
 | upgrade        | upgrade          | Upgrades a machine's Docker client to the latest stable release. |
 ## Upgrade Docker Toolbox
 To upgrade Docker Toolbox, download an re-run [the Docker Toolbox
 installer](https://www.docker.com/toolbox).
 ## Container port redirection
@@ -157,13 +354,12 @@ uses. You can do this with
 ## Uninstallation
-You can uninstall Boot2Docker using Window's standard process for removing programs.
+You can uninstall Docker Toolbox using Window's standard process for removing
-This process does not remove the `docker-install.exe` file. You must delete that file
+programs. This process does not remove the `docker-install.exe` file. You must
-yourself.
+delete that file yourself.
-## References
+## Learn more
-If you have Docker hosts running and if you don't wish to do a 
+You can continue with the [Docker User Guide](/userguide). If you are
-Boot2Docker installation, you can install the docker.exe using
+interested in using the Kitematic GUI, see the [Kitermatic user
-unofficial Windows package manager Chocolately. For information
+guide](/kitematic/userguide/).
 on how to do this, see [Docker package on Chocolatey](http://chocolatey.org/packages/docker).
@@ -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
+Docker registries hold images. These are public or private stores from which you
-or download images. The public Docker registry is called
+upload or download images. The public Docker registry is provided with the
-[Docker Hub](http://hub.docker.com). It provides a huge collection of existing
+[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
+images for your use. These can be images you create yourself or you can use
-can use images that others have previously created. Docker registries are the 
+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 
+image you can *push* it to a public registry such as the one provided by [Docker
-your own registry running behind your firewall.
+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.
@@ -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://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, Postgres to IRC bouncers to Rails app servers to Hadoop to base images
 for various Linux distros. The
@@ -0,0 +1,107 @@
 #!/bin/bash -ex
 # Populate an array with just docker dirs and one with content dirs
 content_dir=(`ls -d /docs/content/*`)
 # Loop content not of docker/
 #
 # Sed to process GitHub Markdown
 # 1-2 Remove comment code from metadata block
 # 3 Remove .md extension from link text
 # 4 Change ](/ to ](/project/ in links
 # 5 Change ](word) to ](/project/word)
 # 6 Change ](../../ to ](/project/
 # 7 Change ](../ to ](/project/word)
 # 
 for i in "${content_dir[@]}"
 do
   :
   case $i in
      "/docs/content/docker-trusted-registry")
      ;;
      "/docs/content/docker-hub")
      ;;
      "/docs/content/windows")
      ;;
      "/docs/content/mac")
      ;;
      "/docs/content/linux")
      ;;
      "/docs/content/registry")
      y=${i##*/}
      find $i -type f -name "*.md" -not -name "*.compare.md" -exec sed -i.old \
        -e '/^<!\(--\)\{0,1\}\[\(end-\)\{0,1\}metadata\]\(--\)\{0,1\}>/g' \
        -e 's/\(\][(]\)\(\.*\/\)*/\1/g' \
        -e 's/\(\][(]\)\([A-Za-z0-9_/-]\{1,\}\)\(\.md\)\{0,1\}\(#\{0,1\}\(#[A-Za-z0-9_-]*\)\{0,1\}\)[)]/\1\/'$y'\/\2\4)/g' \
        {} \;
      ;;
      "/docs/content/compose")
         y=${i##*/}
        find $i -type f -name "*.md" -exec sed -i.old \
        -e '/^<!.*metadata]>/g' \
        -e '/^<!.*end-metadata.*>/g' \
        -e 's/\(\]\)\([(]\)\(\/\)/\1\2\/'$y'\//g' \
        -e 's/\(\][(]\)\([A-z].*\)\(\.md\)/\1\/'$y'\/\2/g' \
        -e 's/\([(]\)\(.*\)\(\.md\)/\1\2/g'  \
        -e 's/\(\][(]\)\(\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\.\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\)/\1\/'$y'\//g' {} \;      
      ;;
      "/docs/content/swarm")
         y=${i##*/}
         find $i -type f -name "*.md" -exec sed -i.old \
        -e '/^<!.*metadata]>/g' \
        -e '/^<!.*end-metadata.*>/g' \
        -e 's/\(\]\)\([(]\)\(\/\)/\1\2\/'$y'\//g' \
        -e 's/\(\][(]\)\([A-z].*\)\(\.md\)/\1\/'$y'\/\2/g' \
        -e 's/\([(]\)\(.*\)\(\.md\)/\1\2/g'  \
        -e 's/\(\][(]\)\(\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\.\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\)/\1\/'$y'\//g' {} \;     
      ;;
      "/docs/content/machine")
         y=${i##*/}
        find $i -type f -name "*.md" -exec sed -i.old \
        -e '/^<!.*metadata]>/g' \
        -e '/^<!.*end-metadata.*>/g' \
        -e 's/\(\]\)\([(]\)\(\/\)/\1\2\/'$y'\//g' \
        -e 's/\(\][(]\)\([A-z].*\)\(\.md\)/\1\/'$y'\/\2/g' \
        -e 's/\([(]\)\(.*\)\(\.md\)/\1\2/g'  \
        -e 's/\(\][(]\)\(\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\.\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\)/\1\/'$y'\//g' {} \;         
      ;;
      "/docs/content/kitematic")
         y=${i##*/}
        find $i -type f -name "*.md" -exec sed -i.old \
        -e '/^<!.*metadata]>/g' \
        -e '/^<!.*end-metadata.*>/g' \
        -e 's/\(\]\)\([(]\)\(\/\)/\1\2\/'$y'\//g' \
        -e 's/\(\][(]\)\([A-z].*\)\(\.md\)/\1\/'$y'\/\2/g' \
        -e 's/\([(]\)\(.*\)\(\.md\)/\1\2/g'  \
        -e 's/\(\][(]\)\(\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\.\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\)/\1\/'$y'\//g' {} \;         
      ;;
      "/docs/content/opensource")
         y=${i##*/}
        find $i -type f -name "*.md" -exec sed -i.old \
        -e '/^<!.*metadata]>/g' \
        -e '/^<!.*end-metadata.*>/g' \
        -e 's/\(\]\)\([(]\)\(\/\)/\1\2\/'$y'\//g' \
        -e 's/\(\][(]\)\([A-z].*\)\(\.md\)/\1\/'$y'\/\2/g' \
        -e 's/\([(]\)\(.*\)\(\.md\)/\1\2/g'  \
        -e 's/\(\][(]\)\(\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\.\.\/\)/\1\/'$y'\//g' \
        -e 's/\(\][(]\)\(\.\.\/\)/\1\/'$y'\//g' {} \;         
      ;;
      *)
         y=${i##*/}
        find $i -type f -name "*.md" -exec sed -i.old \
        -e '/^<!.*metadata]>/g' \
        -e '/^<!.*end-metadata.*>/g' {} \;        
      ;;
      esac
 done
@@ -96,9 +96,9 @@ environment.
 1. Open a terminal.
-    Mac users, use `boot2docker status` to make sure Boot2Docker is running. You
+    Mac users, use `docker-machine status your_vm_name` to make sure your VM is
-    may need to run `eval "$(boot2docker shellinit)"` to initialize your shell
+    running. You may need to run `eval "$(docker-machine env your_vm_name)"` to
-    environment.
+    initialize your shell environment.
 3. Change into the root of your forked repository.
@@ -193,7 +193,7 @@ environment.
    Keeping the ancestor images improves the build performance. When you rebuild
    the child image, the build process uses the local ancestors rather than
    retrieving them from the Hub. The build process gets new ancestors only if
-    DockerHub has updated versions.
+    Docker Hub has updated versions.
 ## Start a container and run a test
@@ -10,502 +10,5 @@ parent = "smn_remoteapi"
 # Docker Hub API
- This is the REST API for [Docker Hub](https://hub.docker.com).
+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. 
 - Authorization is done with basic auth over SSL
 - Not all commands require authentication, only those noted as such.
 # 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
@@ -298,429 +298,4 @@ The `fromImage` and `repo` parameters now supports the `repo:tag` format.
 Consequently,  the `tag` parameter is now obsolete. Using the new format and
 the `tag` parameter at the same time will return an error.
 ## v1.13
 ### Full documentation
 [*Docker Remote API v1.13*](/reference/api/docker_remote_api_v1.13/)
 ### What's new
 `GET /containers/(name)/json`
 **New!**
 The `HostConfig.Links` field is now filled correctly
 **New!**
 `Sockets` parameter added to the `/info` endpoint listing all the sockets the 
 daemon is configured to listen on.
 `POST /containers/(name)/start`
 `POST /containers/(name)/stop`
 **New!**
 `start` and `stop` will now return 304 if the container's status is not modified
 `POST /commit`
 **New!**
 Added a `pause` parameter (default `true`) to pause the container during commit
 ## v1.12
 ### Full documentation
 [*Docker Remote API v1.12*](/reference/api/docker_remote_api_v1.12/)
 ### What's new
 `POST /build`
 **New!**
 Build now has support for the `forcerm` parameter to always remove containers
 `GET /containers/(name)/json`
 `GET /images/(name)/json`
 **New!**
 All the JSON keys are now in CamelCase
 **New!**
 Trusted builds are now Automated Builds - `is_trusted` is now `is_automated`.
 **Removed Insert Endpoint**
 The `insert` endpoint has been removed.
 ## v1.11
 ### Full documentation
 [*Docker Remote API v1.11*](/reference/api/docker_remote_api_v1.11/)
 ### What's new
 `GET /_ping`
 **New!**
 You can now ping the server via the `_ping` endpoint.
 `GET /events`
 **New!**
 You can now use the `-until` parameter to close connection
 after timestamp.
 `GET /containers/(id)/logs`
 This url is preferred method for getting container logs now.
 ## v1.10
 ### Full documentation
 [*Docker Remote API v1.10*](/reference/api/docker_remote_api_v1.10/)
 ### What's new
 `DELETE /images/(name)`
 **New!**
 You can now use the force parameter to force delete of an
    image, even if it's tagged in multiple repositories. **New!**
    You
    can now use the noprune parameter to prevent the deletion of parent
    images
 `DELETE /containers/(id)`
 **New!**
 You can now use the force parameter to force delete a
    container, even if it is currently running
 ## v1.9
 ### Full documentation
 [*Docker Remote API v1.9*](/reference/api/docker_remote_api_v1.9/)
 ### What's new
 `POST /build`
 **New!**
 This endpoint now takes a serialized ConfigFile which it
 uses to resolve the proper registry auth credentials for pulling the
 base image. Clients which previously implemented the version
 accepting an AuthConfig object must be updated.
 ## v1.8
 ### Full documentation
 [*Docker Remote API v1.8*](/reference/api/docker_remote_api_v1.8/)
 ### What's new
 `POST /build`
 **New!**
 This endpoint now returns build status as json stream. In
 case of a build error, it returns the exit status of the failed
 command.
 `GET /containers/(id)/json`
 **New!**
 This endpoint now returns the host config for the
 container.
 `POST /images/create`
 `POST /images/(name)/insert`
 `POST /images/(name)/push`
 **New!**
 progressDetail object was added in the JSON. It's now
 possible to get the current value and the total of the progress
 without having to parse the string.
 ## v1.7
 ### Full documentation
 [*Docker Remote API v1.7*](/reference/api/docker_remote_api_v1.7/)
 ### What's new
 `GET /images/json`
 The format of the json returned from this uri changed. Instead of an
 entry for each repo/tag on an image, each image is only represented
 once, with a nested attribute indicating the repo/tags that apply to
 that image.
 Instead of:
    HTTP/1.1 200 OK
    Content-Type: application/json
    [
      {
        "VirtualSize": 131506275,
        "Size": 131506275,
        "Created": 1365714795,
        "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
        "Tag": "12.04",
        "Repository": "ubuntu"
      },
      {
        "VirtualSize": 131506275,
        "Size": 131506275,
        "Created": 1365714795,
        "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
        "Tag": "latest",
        "Repository": "ubuntu"
      },
      {
        "VirtualSize": 131506275,
        "Size": 131506275,
        "Created": 1365714795,
        "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
        "Tag": "precise",
        "Repository": "ubuntu"
      },
      {
        "VirtualSize": 180116135,
        "Size": 24653,
        "Created": 1364102658,
        "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
        "Tag": "12.10",
        "Repository": "ubuntu"
      },
      {
        "VirtualSize": 180116135,
        "Size": 24653,
        "Created": 1364102658,
        "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
        "Tag": "quantal",
        "Repository": "ubuntu"
      }
    ]
 The returned json looks like this:
    HTTP/1.1 200 OK
    Content-Type: application/json
    [
      {
         "RepoTags": [
           "ubuntu:12.04",
           "ubuntu:precise",
           "ubuntu:latest"
         ],
         "Id": "8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c",
         "Created": 1365714795,
         "Size": 131506275,
         "VirtualSize": 131506275
      },
      {
         "RepoTags": [
           "ubuntu:12.10",
           "ubuntu:quantal"
         ],
         "ParentId": "27cf784147099545",
         "Id": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
         "Created": 1364102658,
         "Size": 24653,
         "VirtualSize": 180116135
      }
    ]
 `GET /images/viz`
 This URI no longer exists. The `images --viz`
 output is now generated in the client, using the
 `/images/json` data.
 ## v1.6
 ### Full documentation
 [*Docker Remote API v1.6*](/reference/api/docker_remote_api_v1.6/)
 ### What's new
 `POST /containers/(id)/attach`
 **New!**
 You can now split stderr from stdout. This is done by
 prefixing a header to each transmission. See
 [`POST /containers/(id)/attach`](
 /reference/api/docker_remote_api_v1.9/#attach-to-a-container "POST /containers/(id)/attach").
 The WebSocket attach is unchanged. Note that attach calls on the
 previous API version didn't change. Stdout and stderr are merged.
 ## v1.5
 ### Full documentation
 [*Docker Remote API v1.5*](/reference/api/docker_remote_api_v1.5/)
 ### What's new
 `POST /images/create`
 **New!**
 You can now pass registry credentials (via an AuthConfig
    object) through the X-Registry-Auth header
 `POST /images/(name)/push`
 **New!**
 The AuthConfig object now needs to be passed through the
    X-Registry-Auth header
 `GET /containers/json`
 **New!**
 The format of the Ports entry has been changed to a list of
 dicts each containing PublicPort, PrivatePort and Type describing a
 port mapping.
 ## v1.4
 ### Full documentation
 [*Docker Remote API v1.4*](/reference/api/docker_remote_api_v1.4/)
 ### What's new
 `POST /images/create`
 **New!**
 When pulling a repo, all images are now downloaded in parallel.
 `GET /containers/(id)/top`
 **New!**
 You can now use ps args with docker top, like docker top
    <container_id> aux
 `GET /events`
 **New!**
 Image's name added in the events
 ## v1.3
 docker v0.5.0
 [51f6c4a](https://github.com/docker/docker/commit/51f6c4a7372450d164c61e0054daf0223ddbd909)
 ### Full documentation
 [*Docker Remote API v1.3*](/reference/api/docker_remote_api_v1.3/)
 ### What's new
 `GET /containers/(id)/top`
 List the processes running inside a container.
 `GET /events`
 **New!**
 Monitor docker's events via streaming or via polling
 Builder (/build):
 - Simplify the upload of the build context
 - Simply stream a tarball instead of multipart upload with 4
   intermediary buffers
 - Simpler, less memory usage, less disk usage and faster
 > **Warning**: 
 > The /build improvements are not reverse-compatible. Pre 1.3 clients will
 > break on /build.
 List containers (/containers/json):
 - You can use size=1 to get the size of the containers
 Start containers (/containers/<id>/start):
 - You can now pass host-specific configuration (e.g., bind mounts) in
   the POST body for start calls
 ## v1.2
 docker v0.4.2
 [2e7649b](https://github.com/docker/docker/commit/2e7649beda7c820793bd46766cbc2cfeace7b168)
 ### Full documentation
 [*Docker Remote API v1.2*](/reference/api/docker_remote_api_v1.2/)
 ### What's new
 The auth configuration is now handled by the client.
 The client should send it's authConfig as POST on each call of
 `/images/(name)/push`
 `GET /auth`
 **Deprecated.**
 `POST /auth`
 Only checks the configuration but doesn't store it on the server
    Deleting an image is now improved, will only untag the image if it
    has children and remove all the untagged parents if has any.
 `POST /images/<name>/delete`
 Now returns a JSON structure with the list of images
 deleted/untagged.
 ## v1.1
 docker v0.4.0
 [a8ae398](https://github.com/docker/docker/commit/a8ae398bf52e97148ee7bd0d5868de2e15bd297f)
 ### Full documentation
 [*Docker Remote API v1.1*](/reference/api/docker_remote_api_v1.1/)
 ### What's new
 `POST /images/create`
 `POST /images/(name)/insert`
 `POST /images/(name)/push`
 Uses json stream instead of HTML hijack, it looks like this:
        HTTP/1.1 200 OK
        Content-Type: application/json
        {"status":"Pushing..."}
        {"status":"Pushing", "progress":"1/? (n/a)"}
        {"error":"Invalid..."}
        ...
 ## v1.0
 docker v0.3.4
 [8d73740](https://github.com/docker/docker/commit/8d73740343778651c09160cde9661f5f387b36f4)
 ### Full documentation
 [*Docker Remote API v1.0*](/reference/api/docker_remote_api_v1.0/)
 ### What's new
 Initial version
@@ -10,752 +10,8 @@ parent="smn_hub_ref"
 # The Docker Hub and the Registry v1
-## The three roles
+This API is deprecated as of 1.7. To view the old version, see the [go
-
+here](http://docs.docker.com/v1.7/reference/api/hub_registry_spec/) in
-There are three major components playing a role in the Docker ecosystem.
+the 1.7 documentation. If you want an overview of the current features in
-
+Docker Hub or other image management features see the [image management
-### Docker Hub
+overview](/userguide/image_management/) in the current documentation set.
 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.
@@ -10,48 +10,50 @@ parent = "mn_reference"
 # Dockerfile reference
-**Docker can build images automatically** by reading the instructions
+Docker can build images automatically by reading the instructions from a
-from a `Dockerfile`. A `Dockerfile` is a text document that contains all
+`Dockerfile`. A `Dockerfile` is a text document that contains all the commands a
-the commands you would normally execute manually in order to build a
+user could call on the command line to assemble an image. Using `docker build`
-Docker image. By calling `docker build` from your terminal, you can have
+users can create an automated build that executes several command-line
-Docker build your image step by step, executing the instructions
+instructions in succession.
 successively.
-This page discusses the specifics of all the instructions you can use in your
+This page describes the commands you can use in a `Dockerfile`. When you are
-`Dockerfile`. To further help you write a clear, readable, maintainable
+done reading this page, refer to the [`Dockerfile` Best
-`Dockerfile`, we've also written a [`Dockerfile` Best Practices
+Practices](/articles/dockerfile_best-practices) for a tip-oriented guide.
 guide](/articles/dockerfile_best-practices). Lastly, you can test your
 Dockerfile knowledge with the [Dockerfile tutorial](/userguide/level1).
 ## Usage
-To [*build*](/reference/commandline/cli/#build) an image from a source repository,
+The [`docker build`](/reference/commandline/build/) command builds an image from
-create a description file called `Dockerfile` at the root of your repository.
+a `Dockerfile` and a *context*. The build's context is the files at a specified
-This file will describe the steps to assemble the image.
+location `PATH` or `URL`. The `PATH` is a directory on your local filesystem.
 The `URL` is a the location of a Git repository.
-Then call `docker build` with the path of your source repository as the argument
+A context is processed recursively. So, a `PATH` includes any subdirectories and
-(for example, `.`):
+the `URL` includes the repository and its submodules. A simple build command
 that uses the current directory as context:
    $ docker build .
    Sending build context to Docker daemon  6.51 MB
    ...
-The path to the source repository defines where to find the *context* of
+The build is run by the Docker daemon, not by the CLI. The first thing a build
-the build. The build is run by the Docker daemon, not by the CLI, so the
+process does is send the entire context (recursively) to the daemon.  In most
-whole context must be transferred to the daemon. The Docker CLI reports
+cases, it's best to start with an empty directory as context and keep your
-"Sending build context to Docker daemon" when the context is sent to the daemon.
+Dockerfile in that directory. Add only the files needed for building the
 Dockerfile.
-> **Warning**
+>**Warning**: Do not use your root directory, `/`, as the `PATH` as it causes
-> Avoid using your root directory, `/`, as the root of the source repository. The 
+>the build to transfer the entire contents of your hard drive to the Docker
-> `docker build` command will use whatever directory contains the Dockerfile as the build
+>daemon. 
 > context (including all of its subdirectories). The build context will be sent to the
 > Docker daemon before building the image, which means if you use `/` as the source
 > repository, the entire contents of your hard drive will get sent to the daemon (and
 > thus to the machine running the daemon). You probably don't want that.
-In most cases, it's best to put each Dockerfile in an empty directory. Then,
+To use a file in the build context, the `Dockerfile` refers to the file with
-only add the files needed for building the Dockerfile to the directory. To
+an instruction, for example,  a `COPY` instruction. To increase the build's
-increase the build's performance, you can exclude files and directories by
+performance, exclude files and directories by adding a `.dockerignore` file to
-adding a `.dockerignore` file to the directory.  For information about how to
+the context directory.  For information about how to [create a `.dockerignore`
-[create a `.dockerignore` file](#dockerignore-file) on this page.
+file](#dockerignore-file) see the documentation on this page.
 Traditionally, the `Dockerfile` is called `Dockerfile` and located in the root
 of the context. You use the `-f` flag with `docker build` to point to a Dockerfile
 anywhere in your file system.
 You can specify a repository and tag at which to save the new image if
 the build succeeds:
@@ -100,7 +102,7 @@ be UPPERCASE in order to distinguish them from arguments more easily.
 Docker runs the instructions in a `Dockerfile` in order. **The
 first instruction must be \`FROM\`** in order to specify the [*Base
-Image*](/terms/image/#base-image) from which you are building.
+Image*](/reference/glossary/#base-image) from which you are building.
 Docker will treat lines that *begin* with `#` as a
 comment. A `#` marker anywhere else in the line will
@@ -114,12 +116,6 @@ images.
 ### Environment replacement
 > **Note**: prior to 1.3, `Dockerfile` environment variables were handled
 > similarly, in that they would be replaced as described below. However, there
 > was no formal definition on as to which instructions handled environment
 > replacement at the time. After 1.3 this behavior will be preserved and
 > canonical.
 Environment variables (declared with [the `ENV` statement](#env)) can also be
 used in certain instructions as variables to be interpreted by the
 `Dockerfile`. Escapes are also handled for including variable-like syntax
@@ -166,13 +162,13 @@ The instructions that handle environment variables in the `Dockerfile` are:
 the instructions above.
 Environment variable substitution will use the same value for each variable
-throughout the entire command.  In other words, in this example:
+throughout the entire command. In other words, in this example:
    ENV abc=hello
    ENV abc=bye def=$abc
    ENV ghi=$abc
-will result in `def` having a value of `hello`, not `bye`.  However, 
+will result in `def` having a value of `hello`, not `bye`. However, 
 `ghi` will have a value of `bye` because it is not part of the same command
 that set `abc` to `bye`.
@@ -191,7 +187,7 @@ expansion) is done using Go's
 You can specify exceptions to exclusion rules. To do this, simply prefix a
 pattern with an `!` (exclamation mark) in the same way you would in a
-`.gitignore` file.  Currently there is no support for regular expressions.
+`.gitignore` file. Currently there is no support for regular expressions.
 Formats like `[^temp*]` are ignored. 
 The following is an example `.dockerignore` file:
@@ -251,7 +247,7 @@ Or
    FROM <image>@<digest>
-The `FROM` instruction sets the [*Base Image*](/terms/image/#base-image)
+The `FROM` instruction sets the [*Base Image*](/reference/glossary/#base-image)
 for subsequent instructions. As such, a valid `Dockerfile` must have `FROM` as
 its first instruction. The image can be any valid image – it is especially easy
 to start by **pulling an image** from the [*Public Repositories*](
@@ -310,7 +306,7 @@ commands using a base image that does not contain `/bin/sh`.
 The cache for `RUN` instructions isn't invalidated automatically during
 the next build. The cache for an instruction like 
-`RUN apt-get dist-upgrade -y` will be reused during the next build.  The 
+`RUN apt-get dist-upgrade -y` will be reused during the next build. The 
 cache for `RUN` instructions can be invalidated by using the `--no-cache` 
 flag, for example `docker build --no-cache`.
@@ -888,9 +884,9 @@ The `VOLUME` instruction creates a mount point with the specified name
 and marks it as holding externally mounted volumes from native host or other
 containers. The value can be a JSON array, `VOLUME ["/var/log/"]`, or a plain
 string with multiple arguments, such as `VOLUME /var/log` or `VOLUME /var/log
-/var/db`.  For more information/examples and mounting instructions via the
+/var/db`. For more information/examples and mounting instructions via the
 Docker client, refer to 
-[*Share Directories via Volumes*](/userguide/dockervolumes/#volume)
+[*Share Directories via Volumes*](/userguide/dockervolumes/#mount-a-host-directory-as-a-data-volume)
 documentation.
 The `docker run` command initializes the newly created volume with any data 
@@ -906,6 +902,10 @@ This Dockerfile results in an image that causes `docker run`, to
 create a new mount point at `/myvol` and copy the  `greeting` file 
 into the newly created volume.
 > **Note**:
 > If any build steps change the data within the volume after it has been
 > declared, those changes will be discarded.
 > **Note**:
 > The list is parsed as a JSON array, which means that
 > you must use double-quotes (") around words not single-quotes (').
@@ -19,6 +19,10 @@ aufs (advanced multi layered unification filesystem) is a Linux [filesystem](#fi
 Docker supports as a storage backend. It implements the
 [union mount](http://en.wikipedia.org/wiki/Union_mount) for Linux file systems.
 ## Base image
 An image that has no parent is a **base image**.
 ## boot2docker
 [boot2docker](http://boot2docker.io/) is a lightweight Linux distribution made
@@ -25,8 +25,16 @@ driver sends the following metadata in the structured log message:
 | `container_name` | The container name at the time it was started. If you use `docker rename` to rename a container, the new name is not reflected in the journal entries.                                         |
 | `source`         | `stdout` or `stderr`                |
 The `docker logs` command is not available for this logging driver.
 ## Usage
 Some options are supported by specifying `--log-opt` as many times as needed:
 - `fluentd-address`: specify `host:port` to connect `localhost:24224`
 - `fluentd-tag`: specify tag for fluentd message, which interpret some markup, ex `{{.ID}}`, `{{.FullID}}` or `{{.Name}}` `docker.{{.ID}}`
 Configure the default logging driver by passing the
 `--log-driver` option to the Docker daemon:
@@ -1,129 +1,18 @@
 <!--[metadata]>
 +++
-title = "Configure logging drivers"
+title = "Logging Drivers"
-description = "Configure logging driver."
+description = "Logging Drivers"
-keywords = ["Fluentd, docker, logging, driver"]
+keywords = [" docker, logging, driver"]
 [menu.main]
-parent = "smn_logging"
+parent = "smn_administrate"
 identifier = "smn_logging"
 weight=8
 +++
 <![end-metadata]-->
-# Configure logging drivers
+# Logging Drivers
-The container can have a different logging driver than the Docker daemon. Use
+* [Configuring logging drivers](overview)
-the `--log-driver=VALUE` with the `docker run` command to configure the
+* [Fluentd logging driver](fluentd)
-container's logging driver. The following options are supported:
+* [Journald logging driver](journald)
 | `none`      | Disables any logging for the container. `docker logs` won't be available with this driver.                                    |
 |-------------|-------------------------------------------------------------------------------------------------------------------------------|
 | `json-file` | Default logging driver for Docker. Writes JSON messages to file.                                                              |
 | `syslog`    | Syslog logging driver for Docker. Writes log messages to syslog.                                                              |
 | `journald`  | Journald logging driver for Docker. Writes log messages to `journald`.                                                        |
 | `gelf`      | Graylog Extended Log Format (GELF) logging driver for Docker. Writes log messages to a GELF endpoint likeGraylog or Logstash. |
 | `fluentd`   | Fluentd logging driver for Docker. Writes log messages to `fluentd` (forward input).                                          |
 The `docker logs`command is available only for the `json-file` logging driver.  
 ### The json-file options
 The following logging options are supported for the `json-file` logging driver:
    --log-opt max-size=[0-9+][k|m|g]
    --log-opt max-file=[0-9+]
 Logs that reach `max-size` are rolled over. You can set the size in kilobytes(k), megabytes(m), or gigabytes(g). eg `--log-opt max-size=50m`. If `max-size` is not set, then logs are not rolled over.
 `max-file` specifies the maximum number of files that a log is rolled over before being discarded. eg `--log-opt max-file=100`. If `max-size` is not set, then `max-file` is not honored.
 If `max-size` and `max-file` are set, `docker logs` only returns the log lines from the newest log file. 
 ### The syslog options
 The following logging options are supported for the `syslog` logging driver:
    --log-opt syslog-address=[tcp|udp]://host:port
    --log-opt syslog-address=unix://path
    --log-opt syslog-facility=daemon
    --log-opt syslog-tag="mailer"
 `syslog-address` specifies the remote syslog server address where the driver connects to.
 If not specified it defaults to the local unix socket of the running system.
 If transport is either `tcp` or `udp` and `port` is not specified it defaults to `514`
 The following example shows how to have the `syslog` driver connect to a `syslog`
 remote server at `192.168.0.42` on port `123`
    $ docker run --log-driver=syslog --log-opt syslog-address=tcp://192.168.0.42:123
 The `syslog-facility` option configures the syslog facility. By default, the system uses the
 `daemon` value. To override this behavior, you can provide an integer of 0 to 23 or any of
 the following named facilities:
 * `kern`
 * `user`
 * `mail`
 * `daemon`
 * `auth`
 * `syslog`
 * `lpr`
 * `news`
 * `uucp`
 * `cron`
 * `authpriv`
 * `ftp`
 * `local0`
 * `local1`
 * `local2`
 * `local3`
 * `local4`
 * `local5`
 * `local6`
 * `local7`
 The `syslog-tag` specifies a tag that identifies the container's syslog messages. By default,
 the system uses the first 12 characters of the container id. To override this behavior, specify
 a `syslog-tag` option
 ## Specify journald options
 The `journald` logging driver stores the container id in the journal's `CONTAINER_ID` field. For detailed information on
 working with this logging driver, see [the journald logging driver](/reference/logging/journald/)
 reference documentation.
 ## Specify gelf options
 The GELF logging driver supports the following options:
    --log-opt gelf-address=udp://host:port
    --log-opt gelf-tag="database"
 The `gelf-address` option specifies the remote GELF server address that the
 driver connects to. Currently, only `udp` is supported as the transport and you must
 specify a `port` value. The following example shows how to connect the `gelf`
 driver to a GELF remote server at `192.168.0.42` on port `12201`
    $ docker run --log-driver=gelf --log-opt gelf-address=udp://192.168.0.42:12201
 The `gelf-tag` option specifies a tag for easy container identification.
 ## Specify fluentd options
 You can use the `--log-opt NAME=VALUE` flag to specify these additional Fluentd logging driver options.
 - `fluentd-address`: specify `host:port` to connect [localhost:24224]
 - `fluentd-tag`: specify tag for `fluentd` message, 
 When specifying a `fluentd-tag` value, you can use the following markup tags:
 - `{{.ID}}`: short container id (12 characters)
 - `{{.FullID}}`: full container id
 - `{{.Name}}`: container name
 For example, to specify both additional options:
 `docker run --log-driver=fluentd --log-opt fluentd-address=localhost:24224 --log-opt fluentd-tag=docker.{{.Name}}`
 If container cannot connect to the Fluentd daemon on the specified address,
 the container stops immediately. For detailed information on working with this
 logging driver, see [the fluentd logging driver](/reference/logging/fluentd/)
@@ -0,0 +1,130 @@
 <!--[metadata]>
 +++
 title = "Configuring Logging Drivers"
 description = "Configure logging driver."
 keywords = ["Fluentd, docker, logging, driver"]
 [menu.main]
 parent = "smn_logging"
 weight=-1
 +++
 <![end-metadata]-->
 # Configure logging drivers
 The container can have a different logging driver than the Docker daemon. Use
 the `--log-driver=VALUE` with the `docker run` command to configure the
 container's logging driver. The following options are supported:
 | `none`      | Disables any logging for the container. `docker logs` won't be available with this driver.                                    |
 |-------------|-------------------------------------------------------------------------------------------------------------------------------|
 | `json-file` | Default logging driver for Docker. Writes JSON messages to file.                                                              |
 | `syslog`    | Syslog logging driver for Docker. Writes log messages to syslog.                                                              |
 | `journald`  | Journald logging driver for Docker. Writes log messages to `journald`.                                                        |
 | `gelf`      | Graylog Extended Log Format (GELF) logging driver for Docker. Writes log messages to a GELF endpoint likeGraylog or Logstash. |
 | `fluentd`   | Fluentd logging driver for Docker. Writes log messages to `fluentd` (forward input).                                          |
 The `docker logs`command is available only for the `json-file` logging driver.  
 ### The json-file options
 The following logging options are supported for the `json-file` logging driver:
    --log-opt max-size=[0-9+][k|m|g]
    --log-opt max-file=[0-9+]
 Logs that reach `max-size` are rolled over. You can set the size in kilobytes(k), megabytes(m), or gigabytes(g). eg `--log-opt max-size=50m`. If `max-size` is not set, then logs are not rolled over.
 `max-file` specifies the maximum number of files that a log is rolled over before being discarded. eg `--log-opt max-file=100`. If `max-size` is not set, then `max-file` is not honored.
 If `max-size` and `max-file` are set, `docker logs` only returns the log lines from the newest log file. 
 ### The syslog options
 The following logging options are supported for the `syslog` logging driver:
    --log-opt syslog-address=[tcp|udp]://host:port
    --log-opt syslog-address=unix://path
    --log-opt syslog-facility=daemon
    --log-opt syslog-tag="mailer"
 `syslog-address` specifies the remote syslog server address where the driver connects to.
 If not specified it defaults to the local unix socket of the running system.
 If transport is either `tcp` or `udp` and `port` is not specified it defaults to `514`
 The following example shows how to have the `syslog` driver connect to a `syslog`
 remote server at `192.168.0.42` on port `123`
    $ docker run --log-driver=syslog --log-opt syslog-address=tcp://192.168.0.42:123
 The `syslog-facility` option configures the syslog facility. By default, the system uses the
 `daemon` value. To override this behavior, you can provide an integer of 0 to 23 or any of
 the following named facilities:
 * `kern`
 * `user`
 * `mail`
 * `daemon`
 * `auth`
 * `syslog`
 * `lpr`
 * `news`
 * `uucp`
 * `cron`
 * `authpriv`
 * `ftp`
 * `local0`
 * `local1`
 * `local2`
 * `local3`
 * `local4`
 * `local5`
 * `local6`
 * `local7`
 The `syslog-tag` specifies a tag that identifies the container's syslog messages. By default,
 the system uses the first 12 characters of the container id. To override this behavior, specify
 a `syslog-tag` option
 ## Specify journald options
 The `journald` logging driver stores the container id in the journal's `CONTAINER_ID` field. For detailed information on
 working with this logging driver, see [the journald logging driver](/reference/logging/journald/)
 reference documentation.
 ## Specify gelf options
 The GELF logging driver supports the following options:
    --log-opt gelf-address=udp://host:port
    --log-opt gelf-tag="database"
 The `gelf-address` option specifies the remote GELF server address that the
 driver connects to. Currently, only `udp` is supported as the transport and you must
 specify a `port` value. The following example shows how to connect the `gelf`
 driver to a GELF remote server at `192.168.0.42` on port `12201`
    $ docker run --log-driver=gelf --log-opt gelf-address=udp://192.168.0.42:12201
 The `gelf-tag` option specifies a tag for easy container identification.
 ## Specify fluentd options
 You can use the `--log-opt NAME=VALUE` flag to specify these additional Fluentd logging driver options.
 - `fluentd-address`: specify `host:port` to connect [localhost:24224]
 - `fluentd-tag`: specify tag for `fluentd` message, 
 When specifying a `fluentd-tag` value, you can use the following markup tags:
 - `{{.ID}}`: short container id (12 characters)
 - `{{.FullID}}`: full container id
 - `{{.Name}}`: container name
 For example, to specify both additional options:
 `docker run --log-driver=fluentd --log-opt fluentd-address=localhost:24224 --log-opt fluentd-tag=docker.{{.Name}}`
 If container cannot connect to the Fluentd daemon on the specified address,
 the container stops immediately. For detailed information on working with this
 logging driver, see [the fluentd logging driver](/reference/logging/fluentd/)
@@ -19,11 +19,11 @@ parent = "mn_reference"
 **Docker runs processes in isolated containers**. When an operator
 executes `docker run`, she starts a process with its own file system,
 its own networking, and its own isolated process tree.  The
-[*Image*](/terms/image/#image) which starts the process may define
+[*Image*](/reference/glossary/#image) which starts the process may define
 defaults related to the binary to run, the networking to expose, and
 more, but `docker run` gives final control to the operator who starts
 the container from the image. That's the main reason
-[*run*](/reference/commandline/cli/#run) has more options than any
+[*run*](/reference/commandline/run) has more options than any
 other `docker` command.
 ## General form
@@ -87,7 +87,7 @@ In detached mode (`-d=true` or just `-d`), all I/O should be done
 through network connections or shared volumes because the container is
 no longer listening to the command line where you executed `docker run`.
 You can reattach to a detached container with `docker`
-[*attach*](/reference/commandline/cli/#attach). If you choose to run a
+[*attach*](/reference/commandline/attach). If you choose to run a
 container in the detached mode, then you cannot use the `--rm` option.
 ### Foreground
@@ -360,8 +360,8 @@ Using the `--restart` flag on Docker run you can specify a restart policy for
 how a container should or should not be restarted on exit.
 When a restart policy is active on a container, it will be shown as either `Up`
-or `Restarting` in [`docker ps`](/reference/commandline/cli/#ps). It can also be
+or `Restarting` in [`docker ps`](/reference/commandline/ps). It can also be
-useful to use [`docker events`](/reference/commandline/cli/#events) to see the
+useful to use [`docker events`](/reference/commandline/events) to see the
 restart policy in effect.
 Docker supports the following restart policies:
@@ -417,7 +417,7 @@ You can specify the maximum amount of times Docker will try to restart the
 container when using the **on-failure** policy.  The default is that Docker
 will try forever to restart the container. The number of (attempted) restarts
 for a container can be obtained via [`docker inspect`](
-/reference/commandline/cli/#inspect). For example, to get the number of restarts
+/reference/commandline/inspect). For example, to get the number of restarts
 for container "my-container";
    $ docker inspect -f "{{ .RestartCount }}" my-container
@@ -491,9 +491,7 @@ command:
    $ docker run --security-opt label:type:svirt_apache_t -i -t centos bash
-Note:
+> **Note**: You would have to write policy defining a `svirt_apache_t` type.
 You would have to write policy defining a `svirt_apache_t` type.
 ## Specifying custom cgroups
@@ -507,16 +505,18 @@ parent group.
 The operator can also adjust the performance parameters of the
 container:
-    -m, --memory="": Memory limit (format: <number><optional unit>, where unit = b, k, m or g)
+| Option                     |  Description                                                                                |
-    --memory-swap="": Total memory limit (memory + swap, format: <number><optional unit>, where unit = b, k, m or g)
+|----------------------------|---------------------------------------------------------------------------------------------|
-    -c, --cpu-shares=0: CPU shares (relative weight)
+| `-m`, `--memory="" `       | Memory limit (format: `<number>[<unit>]`, where unit = b, k, m or g)                        |
-    --cpu-period=0: Limit the CPU CFS (Completely Fair Scheduler) period
+| `--memory-swap=""`         | Total memory limit (memory + swap, format: `<number>[<unit>]`, where unit = b, k, m or g)   |
-    --cpuset-cpus="": CPUs in which to allow execution (0-3, 0,1)
+| `-c`, `--cpu-shares=0`     | CPU shares (relative weight)                                                                |
-    --cpuset-mems="": Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems.
+| `--cpu-period=0`           | Limit the CPU CFS (Completely Fair Scheduler) period                                        |
-    --cpu-quota=0: Limit the CPU CFS (Completely Fair Scheduler) quota
+| `--cpuset-cpus="" `        | CPUs in which to allow execution (0-3, 0,1)                                                 |
-    --blkio-weight=0: Block IO weight (relative weight) accepts a weight value between 10 and 1000.
+| `--cpuset-mems=""`         | Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems. |
-    --oom-kill-disable=true|false: Whether to disable OOM Killer for the container or not.
+| `--cpu-quota=0`            | Limit the CPU CFS (Completely Fair Scheduler) quota                                         |
-    --memory-swappiness="": Tune a container's memory swappiness behavior. Accepts an integer between 0 and 100.
+| `--blkio-weight=0`         | Block IO weight (relative weight) accepts a weight value between 10 and 1000.               |
 | `--oom-kill-disable=false` | Whether to disable OOM Killer for the container or not.                                     |
 | `--memory-swappiness=""  ` | Tune a container's memory swappiness behavior. Accepts an integer between 0 and 100.        |
 ### Memory constraints
@@ -568,7 +568,7 @@ We have four ways to set memory usage:
  </tbody>
 </table>
-Examples:
+### Examples
    $ docker run -ti ubuntu:14.04 /bin/bash
@@ -600,8 +600,6 @@ Only disable the OOM killer on containers where you have also set the
 running out of memory and require killing the host's system processes to free
 memory.
 Examples:
 The following example limits the memory to 100M and disables the OOM killer for
 this container:
@@ -894,7 +892,7 @@ familiar with using LXC directly.
 > you can use `--lxc-conf` to set a container's IP address, but this will not be
 > reflected in the `/etc/hosts` file.
-# Logging drivers (--log-driver)
+## Logging drivers (--log-driver)
 The container can have a different logging driver than the Docker daemon. Use
 the `--log-driver=VALUE` with the `docker run` command to configure the
@@ -910,17 +908,8 @@ container's logging driver. The following options are supported:
 	The `docker logs`command is available only for the `json-file` logging
 driver.  For detailed information on working with logging drivers, see
-[Configure a logging driver](reference/logging/).
+[Configure a logging driver](/reference/logging/overview/).
 #### Logging driver: fluentd
 Fluentd logging driver for Docker. Writes log messages to fluentd (forward input). `docker logs`
 command is not available for this logging driver.
 Some options are supported by specifying `--log-opt` as many as needed, like `--log-opt fluentd-address=localhost:24224 --log-opt fluentd-tag=docker.{{.Name}}`.
 - `fluentd-address`: specify `host:port` to connect [localhost:24224]
 - `fluentd-tag`: specify tag for fluentd message, which interpret some markup, ex `{{.ID}}`, `{{.FullID}}` or `{{.Name}}` [docker.{{.ID}}]
 ## Overriding Dockerfile image defaults
@@ -942,7 +931,7 @@ Dockerfile instruction and how the operator can override that setting.
 - [USER](#user)
 - [WORKDIR](#workdir)
-## CMD (default command or options)
+### CMD (default command or options)
 Recall the optional `COMMAND` in the Docker
 commandline:
@@ -958,7 +947,7 @@ image), you can override that `CMD` instruction just by specifying a new
 If the image also specifies an `ENTRYPOINT` then the `CMD` or `COMMAND`
 get appended as arguments to the `ENTRYPOINT`.
-## ENTRYPOINT (default command to execute at runtime)
+### ENTRYPOINT (default command to execute at runtime)
    --entrypoint="": Overwrite the default entrypoint set by the image
@@ -981,7 +970,7 @@ or two examples of how to pass more parameters to that ENTRYPOINT:
    $ docker run -i -t --entrypoint /bin/bash example/redis -c ls -l
    $ docker run -i -t --entrypoint /usr/bin/redis-cli example/redis --help
-## EXPOSE (incoming ports)
+### EXPOSE (incoming ports)
 The Dockerfile doesn't give much control over networking, only providing
 the `EXPOSE` instruction to give a hint to the operator about what
@@ -1023,7 +1012,7 @@ then the client container can access the exposed port via a private
 networking interface.  Docker will set some environment variables in the
 client container to help indicate which interface and port to use.
-## ENV (environment variables)
+### ENV (environment variables)
 When a new container is created, Docker will set the following environment
 variables automatically:
@@ -1059,7 +1048,7 @@ variables automatically:
 The container may also include environment variables defined
 as a result of the container being linked with another container. See
-the [*Container Links*](/userguide/dockerlinks/#container-linking)
+the [*Container Links*](/userguide/dockerlinks/#connect-with-the-linking-system)
 section for more details.
 Additionally, the operator can **set any environment variable** in the
@@ -1136,7 +1125,7 @@ container's `/etc/hosts` entry will be automatically updated.
 > restarted. We recommend using the host entries in `/etc/hosts` to resolve the
 > IP address of linked containers.
-## VOLUME (shared filesystems)
+### VOLUME (shared filesystems)
    -v=[]: Create a bind mount with: [host-dir:]container-dir[:rw|ro].
           If 'host-dir' is missing, then docker creates a new volume.
@@ -1151,18 +1140,21 @@ one or more `VOLUME`'s associated with an image, but only the operator
 can give access from one container to another (or from a container to a
 volume mounted on the host).
-## USER
+### USER
-The default user within a container is `root` (id = 0), but if the
+`root` (id = 0) is the default user within a container. The image developer can
-developer created additional users, those are accessible too. The
+create additional users. Those users are accessible by name.  When passing a numeric
-developer can set a default user to run the first process with the
+ID, the user does not have to exist in the container.
-Dockerfile `USER` instruction, but the operator can override it:
+
 The developer can set a default user to run the first process with the
 Dockerfile `USER` instruction. When starting a container, the operator can override
 the `USER` instruction by passing the `-u` option.
    -u="": Username or UID
-> **Note:** if you pass numeric uid, it must be in range 0-2147483647.
+> **Note:** if you pass a numeric uid, it must be in the range of 0-2147483647.
-## WORKDIR
+### WORKDIR
 The default working directory for running binaries within a container is the
 root directory (`/`), but the developer can set a different default with the
@@ -0,0 +1,291 @@
 <!--[metadata]>
 +++
 title = "Content trust in Docker"
 description = "Enabling content trust in Docker"
 keywords = ["content, trust, security, docker,  documentation"]
 [menu.main]
 parent= "smn_content_trust"
 weight=-1
 +++
 <![end-metadata]-->
 # Content trust in Docker
 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 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 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.
 ## Understand trust in Docker 
 Content trust allows operations with a remote Docker registry to enforce
 client-side signing and verification of image tags. Content trust provides the
 ability to use digital signatures for data sent to and received from remote
 Docker registries. These signatures allow client-side verification of the
 integrity and publisher of specific image tags. 
 Currently, content trust is disabled by default. You must enabled it by setting
 the `DOCKER_CONTENT_TRUST` environment variable.
 Once content trust is enabled, image publishers can sign their images. Image consumers can
 ensure that the images they use are signed. publishers and consumers can be
 individuals alone or in organizations. Docker's content trust supports users and
 automated processes such as builds. 
 ### Image tags and content trust
 An individual image record has the following identifier:
 ```
 [REGISTRY_HOST[:REGISTRY_PORT]/]REPOSITORY[:TAG]
 ```
 A particular image `REPOSITORY` can have multiple tags. For example, `latest` and
 `3.1.2` are both tags on the `mongo` image. An image publisher can build an image
 and tag combination many times changing the image with each build. 
 Content trust is associated with the `TAG` portion of an image. Each image
 repository has a set of keys that image publishers use to sign an image tag.
 Image publishers have discretion on which tags they sign.
 An image repository can contain an image with one tag that is signed and another
 tag that is not. For example, consider [the Mongo image
 repository](https://hub.docker.com/r/library/mongo/tags/). The `latest`
 tag could be unsigned while the `3.1.6` tag could be signed. It is the
 responsibility of the image publisher to decide if an image tag is signed or
 not. In this representation, some image tags are signed, others are not:
 ![Signed tags](../images/tag_signing.png)
 Publishers can choose to sign a specific tag or not. As a result, the content of
 an unsigned tag and that of a signed tag with the same name may not match. For
 example, a publisher can push a tagged image `someimage:latest` and sign it.
 Later, the same publisher can push an unsigned `someimage:latest` image. This second
 push replaces the last unsigned tag `latest` but does not affect the signed `latest` version. 
 The ability to choose which tags they can sign, allows publishers to iterate over
 the unsigned version of an image before officially signing it.
 Image consumers can enable content trust to ensure that images they use were
 signed. If a consumer enables content trust, they can only pull, run, or build
 with trusted images. Enabling content trust is like wearing a pair of
 rose-colored glasses. Consumers "see" only signed images tags and the less
 desirable, unsigned image tags are "invisible" to them.
 ![Trust view](../images/trust_view.png)
 To the consumer who does not enabled content trust, nothing about how they
 work with Docker images changes. Every image is visible regardless of whether it
 is signed or not.
 ### Content trust operations and keys
 When content trust is enabled, `docker` CLI commands that operate on tagged images must
 either have content signatures or explicit content hashes. The commands that
 operate with content trust are:
 * `push`
 * `build`
 * `create` 
 * `pull`
 * `run` 
 For example, with content trust enabled a `docker pull someimage:latest` only
 succeeds if `someimage:latest` is signed. However, an operation with an explicit
 content hash always succeeds as long as the hash exists:
 ```bash
 $ docker pull someimage@sha256:d149ab53f8718e987c3a3024bb8aa0e2caadf6c0328f1d9d850b2a2a67f2819a
 ```
 Trust for an image tag is managed through the use of signing keys. Docker's content
 trust makes use four different keys: 
 | Key                 | Description                                                                                                                                                                                                                                                                                                                                                                         |
 |---------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | offline key         | Root of content trust for a image tag. When content trust is enabled, you create the offline key once. |
 | target and snapshot | These two keys are known together as the "tagging" key. When content trust is enabled, you create this key when you add a new image repository. If you have the offline key, you can export the tagging key and allow other publishers to sign the image tags.    |
 | timestamp           | This key applies to a repository. It allows Docker repositories to have freshness security guarantees without requiring periodic content refreshes on the client's side.                                                                                                              |
 With the exception of the timestamp, all the keys are generated and stored locally
 client-side. The timestamp is safely generated and stored in a signing server that
 is deployed alongside the Docker registry. All keys are generated in a backend
 service that isn't directly exposed to the internet and are encrypted at rest.
 The following image depicts the various signing keys and their relationships:
 ![Content trust components](../images/trust_components.png)
 >**WARNING**: Loss of the offline key is **very difficult** to recover from.
 >Correcting this loss requires intervention from [Docker
 >Support](https://support.docker.com) to reset the repository state. This loss
 >also requires **manual intervention** from every consumer that used a signed
 >tag from this repository prior to the loss. 
 You should backup the offline key somewhere safe. Given that it is only required
 to create new repositories, it is a good idea to store it offline. Make sure you
 read [Manage keys for content trust](/security/trust/trust_key_mng) information
 for details on creating, securing, and backing up your keys. 
 ## Survey of typical content trust operations
 This section surveys the typical trusted operations users perform with Docker
 images.
 ### Enable content trust
 Enable content trust by setting the `DOCKER_CONTENT_TRUST` environment variable.
 Enabling per-shell is useful because you can have one shell configured for
 trusted operations and another terminal shell for untrusted operations. You can
 also add this declaration to your shell profile to have it turned on always by
 default.
 To enable content trust in a `bash` shell enter the following command:
 ```bash
 export DOCKER_CONTENT_TRUST=1
 ```
 Once set, each of the "tag" operations require key for trusted tag. All of these
 commands also support the `--disable-content-trust` flag. This flag allows
 publishers to run individual operations on tagged images without content trust on an
 as-needed basis. 
 ### Push trusted content
 To create signed content for a specific image tag, simply enable content trust and push
 a tagged image. If this is the first time you have pushed an image using content trust
 on your system, the session looks like this:
 ```bash
 $ docker push docker/trusttest:latest
 The push refers to a repository [docker.io/docker/trusttest] (len: 1)
 9a61b6b1315e: Image already exists 
 902b87aaaec9: Image already exists 
 latest: digest: sha256:d02adacee0ac7a5be140adb94fa1dae64f4e71a68696e7f8e7cbf9db8dd49418 size: 3220
 Signing and pushing trust metadata
 You are about to create a new offline signing key passphrase. This passphrase
 will be used to protect the most sensitive key in your signing system. Please
 choose a long, complex passphrase and be careful to keep the password and the
 key file itself secure and backed up. It is highly recommended that you use a
 password manager to generate the passphrase and keep it safe. There will be no
 way to recover this key. You can find the key in your config directory.
 Enter passphrase for new offline key with id a1d96fb: 
 Repeat passphrase for new offline key with id a1d96fb: 
 Enter passphrase for new tagging key with id docker.io/docker/trusttest (3a932f1): 
 Repeat passphrase for new tagging key with id docker.io/docker/trusttest (3a932f1): 
 Finished initializing "docker.io/docker/trusttest"
 ```
 When you push your first tagged image with content trust enabled, the  `docker` client
 recognizes this is your first push and:
 - alerts you that it will create a new offline key
 - requests a passphrase for the key
 - generates an offline key in the `~/.docker/trust` directory
 - generates a tagging key for in the `~/.docker/trust` directory
 The passphrase you chose for both the offline key and your content key-pair should
 be randomly generated and stored in a *password manager*. 
 It is important to note, if you had left off the `latest` tag, content trust is skipped.
 This is true even if content trust is enabled and even if this is your first push. 
 ```bash
 $ docker push docker/trusttest
 The push refers to a repository [docker.io/docker/trusttest] (len: 1)
 9a61b6b1315e: Image successfully pushed 
 902b87aaaec9: Image successfully pushed 
 latest: digest: sha256:a9a9c4402604b703bed1c847f6d85faac97686e48c579bd9c3b0fa6694a398fc size: 3220
 No tag specified, skipping trust metadata push
 ```
 It is skipped because as the message states, you did not supply an image `TAG`
 value. In Docker content trust, signatures are associated with tags.
 Once you have an offline key on your system, subsequent images repositories
 you create can use that same offline key:
 ```bash
 $ docker push docker.io/docker/seaside:latest
 The push refers to a repository [docker.io/docker/seaside] (len: 1)
 a9539b34a6ab: Image successfully pushed 
 b3dbab3810fc: Image successfully pushed 
 latest: digest: sha256:d2ba1e603661a59940bfad7072eba698b79a8b20ccbb4e3bfb6f9e367ea43939 size: 3346
 Signing and pushing trust metadata
 Enter key passphrase for offline key with id a1d96fb: 
 Enter passphrase for new tagging key with id docker.io/docker/seaside (bb045e3): 
 Repeat passphrase for new tagging key with id docker.io/docker/seaside (bb045e3): 
 Finished initializing "docker.io/docker/seaside"
 ```
 The new image has its own tagging key and timestamp key. The `latest` tag is signed with both of
 these.
 ### Pull image content
 A common way to consume an image is to `pull` it. With content trust enabled, the Docker
 client only allows `docker pull` to retrieve signed images. 
 ```
 $  docker pull docker/seaside
 Using default tag: latest
 Pull (1 of 1): docker/trusttest:latest@sha256:d149ab53f871
 ...
 Tagging docker/trusttest@sha256:d149ab53f871 as docker/trusttest:latest
 ```
 The `seaside:latest` image is signed. In the following example, the command does not specify a tag, so the system uses
 the `latest` tag by default again and the `docker/cliffs:latest` tag is not signed.
 ```bash
 $ docker pull docker/cliffs
 Using default tag: latest
 no trust data available
 ```
 Because the tag `docker/cliffs:latest` is not trusted, the `pull` fails.
 ### Disable content trust for specific operations
 A user that wants to disable content trust for a particular operation can use the
 `--disable-content-trust` flag. **Warning: this flag disables content trust for
 this operation**. With this flag, Docker will ignore content-trust and allow all
 operations to be done without verifying any signatures. If we wanted the
 previous untrusted build to succeed we could do:
 ```
 $  cat Dockerfile
 FROM docker/trusttest:notrust
 RUN echo
 $  docker build --disable-content-trust -t docker/trusttest:testing .
 Sending build context to Docker daemon 42.84 MB
 ...
 Successfully built f21b872447dc
 ```
 The same is true for all the other commands, such as `pull` and `push`:
 ```
 $  docker pull --disable-content-trust docker/trusttest:untrusted
 ...
 $  docker push --disable-content-trust docker/trusttest:untrusted
 ...
 ```
 ## Related information
 * [Manage keys for content trust](/security/trust/trust_key_mng)
 * [Automation with content trust](/security/trust/trust_automation)
 * [Play in a content trust sandbox](/security/trust/trust_sandbox)
@@ -0,0 +1,21 @@
 <!--[metadata]>
 +++
 title = "Use trusted images"
 description = "Use trusted images"
 keywords = ["trust, security, docker,  index"]
 [menu.main]
 identifier="smn_content_trust"
 parent= "mn_docker_hub"
 weight=4
 +++
 <![end-metadata]-->
 # Use trusted images
 The following topics are available:
 * [Content trust in Docker](/security/trust/content_trust) 
 * [Manage keys for content trust](/security/trust/trust_key_mng)
 * [Automation with content trust](/security/trust/trust_automation)
 * [Play in a content trust sandbox](/security/trust/trust_sandbox)
@@ -0,0 +1,79 @@
 <!--[metadata]>
 +++
 title = "Automation with content trust"
 description = "Automating content push pulls with trust"
 keywords = ["trust, security, docker,  documentation, automation"]
 [menu.main]
 parent= "smn_content_trust"
 +++
 <![end-metadata]-->
 # Automation with content trust
 Your automation systems that pull or build images can also work with trust. Any automation environment must set `DOCKER_TRUST_ENABLED` either manually or in in a scripted fashion before processing images.
 ## Bypass requests for passphrases
 To allow tools to wrap docker and push trusted content, there are two
 environment variables that allow you to provide the passphrases without an
 expect script, or typing them in:
 - `DOCKER_CONTENT_TRUST_OFFLINE_PASSPHRASE`
 - `DOCKER_CONTENT_TRUST_TAGGING_PASSPHRASE`
 Docker attempts to use the contents of these environment variables as passphrase
 for the keys. For example, an image publisher can export the repository `target`
 and `snapshot` passphrases:
 ```bash
 $  export DOCKER_CONTENT_TRUST_OFFLINE_PASSPHRASE="u7pEQcGoebUHm6LHe6"
 $  export DOCKER_CONTENT_TRUST_TAGGING_PASSPHRASE="l7pEQcTKJjUHm6Lpe4"
 ```
 Then, when pushing a new tag the Docker client does not request these values but signs automatically:
 ```bash
 $  docker push docker/trusttest:latest
 The push refers to a repository [docker.io/docker/trusttest] (len: 1)
 a9539b34a6ab: Image already exists
 b3dbab3810fc: Image already exists
 latest: digest: sha256:d149ab53f871 size: 3355
 Signing and pushing trust metadata
 ```
 ## Building with content trust
 You can also build with content trust. Before running the `docker build` command, you should set the environment variable `DOCKER_CONTENT_TRUST` either manually or in in a scripted fashion. Consider the simple Dockerfile below. 
 ```Dockerfile
 FROM docker/trusttest:latest
 RUN echo
 ```
 The `FROM` tag is pulling a signed image. You cannot build an image that has a
 `FROM` that is not either present locally or signed. Given that content trust
 data exists for the tag `latest`, the following build should succeed:
 ```bash
 $  docker build -t docker/trusttest:testing .
 Using default tag: latest
 latest: Pulling from docker/trusttest
 b3dbab3810fc: Pull complete
 a9539b34a6ab: Pull complete
 Digest: sha256:d149ab53f871
 ```
 If content trust is enabled, building from a Dockerfile that relies on tag without trust data, causes the build command to fail:
 ```bash
 $  docker build -t docker/trusttest:testing .
 unable to process Dockerfile: No trust data for notrust
 ```
 ## Related information
 * [Content trust in Docker](/security/trust/content_trust) 
 * [Manage keys for content trust](/security/trust/trust_key_mng)
 * [Play in a content trust sandbox](/security/trust/trust_sandbox)
@@ -0,0 +1,73 @@
 <!--[metadata]>
 +++
 title = "Manage keys for content trust"
 description = "Manage keys for content trust"
 keywords = ["trust, security, root,  keys, repository"]
 [menu.main]
 parent= "smn_content_trust"
 +++
 <![end-metadata]-->
 # Manage keys for content trust
 Trust for an image tag is managed through the use of keys. Docker's content
 trust makes use four different keys: 
 | Key                 | Description                                                                                                                                                                                                                                                                                                                                                                         |
 |---------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 | offline key         | Root of content trust for a image tag. When content trust is enabled, you create the offline key once. |
 | target and snapshot | These two keys are known together as the "tagging" key. When content trust is enabled, you create this key when you add a new image repository. If you have the offline key, you can export the tagging key and allow other publishers to sign the image tags.    |
 | timestamp           | This key applies to a repository. It allows Docker repositories to have freshness security guarantees without requiring periodic content refreshes on the client's side.                                                                                                              |
 With the exception of the timestamp, all the keys are generated and stored locally
 client-side. The timestamp is safely generated and stored in a signing server that
 is deployed alongside the Docker registry. All keys are generated in a backend
 service that isn't directly exposed to the internet and are encrypted at rest.
 ## Choosing a passphrase
 The passphrases you chose for both the offline key and your tagging key should
 be randomly generated and stored in a password manager.  Having the tagging key
 allow users to sign image tags on a repository. Passphrases are used to encrypt
 your keys at rest and ensures that a lost laptop or an unintended backup doesn't
 put the private key material at risk. 
 ## Back up your keys
 All the Docker trust keys are stored encrypted using the passphrase you provide
 on creation. Even so, you should still take care of the location where you back them up.
 Good practice is to create two encrypted USB keys.
 It is very important that you backup your keys to a safe, secure location. Loss
 of the tagging key is recoverable; loss of the offline key is not. 
 The Docker client stores the keys in the `~/.docker/trust/private` directory.
 Before backing them up, you should `tar` them into an archive:
 ```bash
 $ umask 077; tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private; umask 022
 ```
 ## Lost keys
 If a publisher loses keys it means losing the ability to sign trusted content for
 your repositories.  If you lose a key, contact [Docker
 Support](https://support.docker.com) (support@docker.com) to reset the repository
 state. 
 This loss also requires **manual intervention** from every consumer that pulled
 the tagged image prior to the loss. Image consumers would get an error for
 content that they already downloaded:
 ```
 could not validate the path to a trusted root: failed to validate data with current trusted certificates
 ```
 To correct this, they need to download a new image tag with that is signed with
 the new key. 
 ## Related information
 * [Content trust in Docker](/security/trust/content_trust) 
 * [Automation with content trust](/security/trust/trust_automation)
 * [Play in a content trust sandbox](/security/trust/trust_sandbox)
@@ -0,0 +1,331 @@
 <!--[metadata]>
 +++
 title = "Play in a content trust sandbox"
 description = "Play in a trust sandbox"
 keywords = ["trust, security, root,  keys, repository, sandbox"]
 [menu.main]
 parent= "smn_content_trust"
 +++
 <![end-metadata]-->
 # Play in a content trust sandbox
 This page explains how to set up and use a sandbox for experimenting with trust.
 The sandbox allows you to configure and try trust operations locally without
 impacting your production images. 
 Before working through this sandbox, you should have read through the [trust
 overview](/security/trust/content_trust).
 ### Prerequisites
 These instructions assume you are running in Linux or Mac OS X. You can run
 this sandbox on a local machine or on a virtual machine. You will need to
 have `sudo` privileges on your local machine or in the VM.
 This sandbox requires you to install two Docker tools: Docker Engine and Docker
 Compose. To install the Docker Engine, choose from the [list of supported
 platforms](/installation). To install Docker Compose, see the
 [detailed instructions here](/compose/install).
 Finally, you'll need to have `git` installed on your local system or VM.
 ## What is in the sandbox?
 If you are just using trust out-of-the-box you only need your Docker Engine
 client and access to Docker's own public hub. The sandbox mimics a
 production trust environment, and requires these additional components:
 | Container       | Description                                                                                                                                 |
 |-----------------|---------------------------------------------------------------------------------------------------------------------------------------------|
 | nostarysandbox  | A container with the latest version of Docker Engine and with some preconfigured certifications. This is your sandbox where you can use the `docker` client to test trust operations. |
 | Registry server | A local registry service.                                                                                                                 |
 | Notary server   | The service that does all the heavy-lifting of managing trust                                                                               |
 | Notary signer   | A service that ensures that your keys are secure.                                                                                           |
 | MySQL           | The database where all of the trust information will be stored                                                                              |
 The sandbox uses the Docker daemon on your local system. Within the `nostarysandbox`
 you interact with a local registry rather than the public Docker Hub. This means
 your everyday image repositories are not used. They are protected while you play.
 When you play in the sandbox, you'll also create root and tagging keys. The
 sandbox is configured to store all the keys and files inside the `notarysandbox`
 container. Since the keys you create in the sandbox are for play only,
 destroying the container destroys them as well.
 ## Build the sandbox
 In this section, you build the Docker components for your trust sandbox. If you
 work exclusively with the Docker Hub, you would not need with these components.
 They are built into the Docker Hub for you. For the sandbox, however, you must
 build your own entire, mock production environment and registry.
 ### Configure /etc/hosts
 The sandbox' `notaryserver` and `sandboxregistry` run on your local server. The
 client inside the `notarysandbox` container connects to them over your network.
 So, you'll need an entry for both the servers in your local `/etc/hosts` file.
 1. Add an entry for the `notaryserver` to `/etc/hosts`.
        $ sudo sh -c 'echo "127.0.0.1 notaryserver" >> /etc/hosts'
 2. Add an entry for the `sandboxregistry` to `/etc/hosts`.
        $ sudo sh -c 'echo "127.0.0.1 sandboxregistry" >> /etc/hosts'
 ### Build the notarytest image
 1. Create a `notarytest` directory on your system.
        $ mkdir notarysandbox
 2. Change into your `notarysandbox` directory.
        $ cd notarysandbox
 3. Create a `notarytest` directory then change into that.
        $ mkdir notarytest
        $ cd nostarytest
 4. Create a filed called `Dockerfile` with your favorite editor.
 5. Add the following to the new file.
        FROM debian:jessie
        ADD https://master.dockerproject.org/linux/amd64/docker /usr/bin/docker
        RUN chmod +x /usr/bin/docker \
          && apt-get update \
          && apt-get install -y \
          tree \
          vim \
          git \
          ca-certificates \
          --no-install-recommends
        WORKDIR /root
        RUN git clone -b trust-sandbox https://github.com/docker/notary.git
        RUN cp /root/notary/fixtures/root-ca.crt /usr/local/share/ca-certificates/root-ca.crt
        RUN update-ca-certificates
        ENTRYPOINT ["bash"]
 6. Save and close the file.
 7. Build the testing container.
        $ docker build -t nostarysandbox .
        Sending build context to Docker daemon 2.048 kB
        Step 0 : FROM debian:jessie
         ...
         Successfully built 5683f17e9d72
 ### Build and start up the trust servers
 In this step, you get the source code for your notary and registry services.
 Then, you'll use Docker Compose to build and start them on your local system.
 1. Change to back to the root of your  `notarysandbox` directory.
        $ cd notarysandbox
 2. Clone the `notary` project.
          $ git clone -b trust-sandbox https://github.com/docker/notary.git
 3. Clone the `distribution` project.
        $ git clone https://github.com/docker/distribution.git
 4. Change to the `notary` project directory.
        $ cd notary
   The directory contains a `docker-compose` file that you'll use to run a
   notary server together with a notary signer and the corresponding MySQL
   databases. The databases store the trust information for an image.
 5. Build the server images.
        $  docker-compose build 
    The first time you run this, the build takes some time.
 6. Run the server containers on your local system.
        $ docker-compose up -d
    Once the trust services are up, you'll setup a local version of the Docker
    Registry v2. 
 7. Change to the `nostarysandbox/distribution` directory.
 8. Build the `sandboxregistry` server.
        $ docker build -t sandboxregistry .
 9. Start the `sandboxregistry` server running. 
        $ docker run -p 5000:5000 --name sandboxregistry sandboxregistry &
 ## Playing in the sandbox
 Now that everything is setup, you can go into your `nostarysandbox` container and
 start testing Docker content trust. 
 ### Start the notarysandbox container
 In this procedure, you start the `notarysandbox` and link it to the running
 `notary_notaryserver_1` and `sandboxregistry` containers. The links allow
 communication among the containers.
 ```
 $ docker run -it -v /var/run/docker.sock:/var/run/docker.sock --link notary_notaryserver_1:notaryserver --link sandboxregistry:sandboxregistry nostarysandbox
 root@0710762bb59a:/# 
 ```
 Mounting the `docker.sock` gives the `nostarysandbox` access to the `docker`
 deamon on your host, while storing all the keys and files inside the sandbox
 container.  When you destroy the container, you destroy the "play" keys.
 ### Test some trust operations
 Now, you'll pull some images. 
 1. Download a `docker` image to test with.
        # docker pull docker/trusttest 
        docker pull docker/trusttest
        Using default tag: latest
        latest: Pulling from docker/trusttest
        b3dbab3810fc: Pull complete 
        a9539b34a6ab: Pull complete 
        Digest: sha256:d149ab53f8718e987c3a3024bb8aa0e2caadf6c0328f1d9d850b2a2a67f2819a
        Status: Downloaded newer image for docker/trusttest:latest
 2. Tag it to be pushed to our sandbox registry: 
        # docker tag docker/trusttest sandboxregistry:5000/test/trusttest:latest
 3. Enable content trust.
        # export DOCKER_CONTENT_TRUST=1
 4. Identify the trust server.
        # export DOCKER_CONTENT_TRUST_SERVER=https://notaryserver:4443
    This step is only necessary because the sandbox is using its own server.
    Normally, if you are using the Docker Public Hub this step isn't necessary.
 5. Pull the test image.
        # docker pull sandboxregistry:5000/test/trusttest
        Using default tag: latest
        no trust data available
      You see an error, because this content doesn't exist on the `sandboxregistry` yet.
 6. Push the trusted image.
        # docker push sandboxregistry:5000/test/trusttest:latest
        The push refers to a repository [sandboxregistry:5000/test/trusttest] (len: 1)
        a9539b34a6ab: Image successfully pushed 
        b3dbab3810fc: Image successfully pushed 
        latest: digest: sha256:1d871dcb16805f0604f10d31260e79c22070b35abc71a3d1e7ee54f1042c8c7c size: 3348
        Signing and pushing trust metadata
        You are about to create a new root signing key passphrase. This passphrase
        will be used to protect the most sensitive key in your signing system. Please
        choose a long, complex passphrase and be careful to keep the password and the
        key file itself secure and backed up. It is highly recommended that you use a
        password manager to generate the passphrase and keep it safe. There will be no
        way to recover this key. You can find the key in your config directory.
        Enter passphrase for new offline key with id 8c69e04: 
        Repeat passphrase for new offline key with id 8c69e04: 
        Enter passphrase for new tagging key with id sandboxregistry:5000/test/trusttest (93c362a): 
        Repeat passphrase for new tagging key with id sandboxregistry:5000/test/trusttest (93c362a): 
        Finished initializing "sandboxregistry:5000/test/trusttest"
        latest: digest: sha256:d149ab53f8718e987c3a3024bb8aa0e2caadf6c0328f1d9d850b2a2a67f2819a size: 3355
        Signing and pushing trust metadata
 7. Try pulling the image you just pushed:
        # docker pull sandboxregistry:5000/test/trusttest  
        Using default tag: latest
        Pull (1 of 1): sandboxregistry:5000/test/trusttest:latest@sha256:1d871dcb16805f0604f10d31260e79c22070b35abc71a3d1e7ee54f1042c8c7c
        sha256:1d871dcb16805f0604f10d31260e79c22070b35abc71a3d1e7ee54f1042c8c7c: Pulling from test/trusttest
        b3dbab3810fc: Already exists 
        a9539b34a6ab: Already exists 
        Digest: sha256:1d871dcb16805f0604f10d31260e79c22070b35abc71a3d1e7ee54f1042c8c7c
        Status: Downloaded newer image for sandboxregistry:5000/test/trusttest@sha256:1d871dcb16805f0604f10d31260e79c22070b35abc71a3d1e7ee54f1042c8c7c
        Tagging sandboxregistry:5000/test/trusttest@sha256:1d871dcb16805f0604f10d31260e79c22070b35abc71a3d1e7ee54f1042c8c7c as sandboxregistry:5000/test/trusttest:latest
 ### Test with malicious images
 What happens when data is corrupted and you try to pull it when trust is
 enabled? In this section, you go into the `sandboxregistry` and tamper with some
 data. Then, you try and pull it.
 1. Leave the sandbox container running.
 2. Open a new bash terminal from your host into the `sandboxregistry`.
        $ docker exec -it sandboxregistry bash
        296db6068327#
 3. Change into the registry storage. 
    You'll need to provide the `sha` you received when you pushed the image.
        # cd /var/lib/registry/docker/registry/v2/blobs/sha256/aa/aac0c133338db2b18ff054943cee3267fe50c75cdee969aed88b1992539ed042
 4. Add malicious data to one of the trusttest layers:
        # echo "Malicious data" > data
 5. Got back to your sandbox terminal.
 6. List the trusttest image.
        # docker images | grep trusttest
        docker/trusttest                 latest              a9539b34a6ab        7 weeks ago         5.025 MB
        sandboxregistry:5000/test/trusttest   latest              a9539b34a6ab        7 weeks ago         5.025 MB
        sandboxregistry:5000/test/trusttest   <none>              a9539b34a6ab        7 weeks ago         5.025 MB
 7. Remove the `trusttest:latest` image.
        # docker rmi -f a9539b34a6ab
        Untagged: docker/trusttest:latest
        Untagged: sandboxregistry:5000/test/trusttest:latest
        Untagged: sandboxregistry:5000/test/trusttest@sha256:1d871dcb16805f0604f10d31260e79c22070b35abc71a3d1e7ee54f1042c8c7c
        Deleted: a9539b34a6aba01d3942605dfe09ab821cd66abf3cf07755b0681f25ad81f675
        Deleted: b3dbab3810fc299c21f0894d39a7952b363f14520c2f3d13443c669b63b6aa20
 8. Pull the image again.
        # docker pull sandboxregistry:5000/test/trusttest
        Using default tag: latest
        ...
        b3dbab3810fc: Verifying Checksum 
        a9539b34a6ab: Pulling fs layer 
        filesystem layer verification failed for digest sha256:aac0c133338db2b18ff054943cee3267fe50c75cdee969aed88b1992539ed042
      You'll see the the pull did not complete because the trust system was
      unable to verify the image.
 ## More play in the sandbox
 Now, that you have a full Docker content trust sandbox on your local system,
 feel free to play with it and see how it behaves. If you find any security
 issues with Docker, feel free to send us an email at <security@docker.com>.
 &nbsp;
@@ -1,51 +0,0 @@
 <!--[metadata]>
 +++
 draft = true
 title = "Container"
 description = "Definitions of a container"
 keywords = ["containers, lxc, concepts, explanation, image,  container"]
 [menu.main]
 parent = "mn_reference"
 +++
 <![end-metadata]-->
 # Container
 ## Introduction
 ![](/terms/images/docker-filesystems-busyboxrw.png)
 Once you start a process in Docker from an [*Image*](/terms/image), Docker
 fetches the image and its [*Parent Image*](/terms/image), and repeats the
 process until it reaches the [*Base Image*](/terms/image/#base-image-def). Then
 the [*Union File System*](/terms/layer) adds a read-write layer on top. That
 read-write layer, plus the information about its [*Parent
 Image*](/terms/image)
 and some additional information like its unique id, networking
 configuration, and resource limits is called a **container**.
 ## Container state
 Containers can change, and so they have state. A container may be
 **running** or **exited**.
 When a container is running, the idea of a "container" also includes a
 tree of processes running on the CPU, isolated from the other processes
 running on the host.
 When the container is exited, the state of the file system and its exit
 value is preserved. You can start, stop, and restart a container. The
 processes restart from scratch (their memory state is **not** preserved
 in a container), but the file system is just as it was when the
 container was stopped.
 You can promote a container to an [*Image*](/terms/image) with `docker commit`.
 Once a container is an image, you can use it as a parent for new containers.
 ## Container IDs
 All containers are identified by a 64 hexadecimal digit string
 (internally a 256bit value). To simplify their use, a short ID of the
 first 12 characters can be used on the command line. There is a small
 possibility of short id collisions, so the docker server will always
 return the long ID.
@@ -1,42 +0,0 @@
 <!--[metadata]>
 +++
 draft = true
 title = "File system"
 description = "How Linux organizes its persistent storage"
 keywords = ["containers, files,  linux"]
 [menu.main]
 parent = "mn_reference"
 +++
 <![end-metadata]-->
 # File system
 ## Introduction
 ![](/terms/images/docker-filesystems-generic.png)
 In order for a Linux system to run, it typically needs two [file
 systems](http://en.wikipedia.org/wiki/Filesystem):
 1. boot file system (bootfs)
 2. root file system (rootfs)
 The **boot file system** contains the bootloader and the kernel. The
 user never makes any changes to the boot file system. In fact, soon
 after the boot process is complete, the entire kernel is in memory, and
 the boot file system is unmounted to free up the RAM associated with the
 initrd disk image.
 The **root file system** includes the typical directory structure we
 associate with Unix-like operating systems:
 `/dev, /proc, /bin, /etc, /lib, /usr,` and `/tmp` plus all the configuration
 files, binaries and libraries required to run user applications (like bash,
 ls, and so forth).
 While there can be important kernel differences between different Linux
 distributions, the contents and organization of the root file system are
 usually what make your software packages dependent on one distribution
 versus another. Docker can help solve this problem by running multiple
 distributions at the same time.
 ![](/terms/images/docker-filesystems-multiroot.png)
@@ -1,47 +0,0 @@
 <!--[metadata]>
 +++
 draft = true 
 title = "Image"
 description = "Definition of an image"
 keywords = ["containers, lxc, concepts, explanation, image,  container"]
 [menu.main]
 parent = "mn_reference"
 +++
 <![end-metadata]-->
 # Image
 ## Introduction
 ![](/terms/images/docker-filesystems-debian.png)
 In Docker terminology, a read-only [*Layer*](/terms/layer/#layer) is
 called an **image**. An image never changes.
 Since Docker uses a [*Union File System*](/terms/layer/#union-file-system), the
 processes think the whole file system is mounted read-write. But all the
 changes go to the top-most writeable layer, and underneath, the original
 file in the read-only image is unchanged. Since images don't change,
 images do not have state.
 ![](/terms/images/docker-filesystems-debianrw.png)
 ## Parent image
 ![](/terms/images/docker-filesystems-multilayer.png)
 Each image may depend on one more image which forms the layer beneath
 it. We sometimes say that the lower image is the **parent** of the upper
 image.
 ## Base image
 An image that has no parent is a **base image**.
 ## Image IDs
 All images are identified by a 64 hexadecimal digit string (internally a
 256bit value). To simplify their use, a short ID of the first 12
 characters can be used on the command line. There is a small possibility
 of short id collisions, so the docker server will always return the long
 ID.
@@ -1,42 +0,0 @@
 <!--[metadata]>
 +++
 draft = true
 title = "Layers"
 description = "Organizing the Docker Root File System"
 keywords = ["containers, lxc, concepts, explanation, image,  container"]
 [menu.main]
 parent = "mn_use_docker"
 +++
 <![end-metadata]-->
 # Layers
 ## Introduction
 In a traditional Linux boot, the kernel first mounts the root [*File
 System*](/terms/filesystem) as read-only, checks its
 integrity, and then switches the whole rootfs volume to read-write mode.
 ## Layer
 When Docker mounts the rootfs, it starts read-only, as in a traditional
 Linux boot, but then, instead of changing the file system to read-write
 mode, it takes advantage of a [union
 mount](http://en.wikipedia.org/wiki/Union_mount) to add a read-write
 file system *over* the read-only file system. In fact there may be
 multiple read-only file systems stacked on top of each other. We think
 of each one of these file systems as a **layer**.
 ![](/terms/images/docker-filesystems-multilayer.png)
 At first, the top read-write layer has nothing in it, but any time a
 process creates a file, this happens in the top layer. And if something
 needs to update an existing file in a lower layer, then the file gets
 copied to the upper layer and changes go into the copy. The version of
 the file on the lower layer cannot be seen by the applications anymore,
 but it is there, unchanged.
 ## Union File System
 We call the union of the read-write layer and all the read-only layers a
 **union file system**.
@@ -1,27 +0,0 @@
 <!--[metadata]>
 +++
 draft = true
 title = "Registry"
 description = "Definition of an Registry"
 keywords = ["containers, concepts, explanation, image, repository,  container"]
 [menu.main]
 parent = "mn_reference"
 +++
 <![end-metadata]-->
 # Registry
 ## Introduction
 A Registry is a hosted service containing
 [*repositories*](/terms/repository/#repository-def) of
 [*images*](/terms/image/#image-def) which responds to the Registry API.
 The default registry can be accessed using a browser at
 [Docker Hub](https://hub.docker.com) or using the
 `docker search` command.
 ## Further reading
 For more information see [*Working with
 Repositories*](/userguide/dockerrepos/#working-with-the-repository)
@@ -1,42 +0,0 @@
 <!--[metadata]>
 +++
 draft = true
 title = "Repository"
 description = "Definition of an Repository"
 keywords = ["containers, concepts, explanation, image, repository,  container"]
 [menu.main]
 parent = "identifier"
 +++
 <![end-metadata]-->
 # Repository
 ## Introduction
 A repository is a set of images either on your local Docker server, or
 shared, by pushing it to a [*Registry*](/terms/registry/#registry-def)
 server.
 Images can be associated with a repository (or multiple) by giving them
 an image name using one of three different commands:
 1. At build time (e.g., `docker build -t IMAGENAME`),
 2. When committing a container (e.g.,
   `docker commit CONTAINERID IMAGENAME`) or
 3. When tagging an image id with an image name (e.g.,
   `docker tag IMAGEID IMAGENAME`).
 A Fully Qualified Image Name (FQIN) can be made up of 3 parts:
 `[registry_hostname[:port]/][user_name/](repository_name:version_tag)`
 `username` and `registry_hostname` default to an empty string. When
 `registry_hostname` is an empty string, then `docker push` will push to
 `index.docker.io:80`.
 If you create a new repository which you want to share, you will need to
 set at least the `user_name`, as the `default` blank `user_name` prefix is
 reserved for [Official Repositories](/docker-hub/official_repos).
 For more information see [*Working with
 Repositories*](/userguide/dockerrepos/#working-with-the-repository)
@@ -1,78 +0,0 @@
 <!--[metadata]>
 +++
 title = "Getting started with Docker Hub"
 description = "Introductory guide to getting an account on Docker Hub"
 keywords = ["documentation, docs, the docker guide, docker guide, docker, docker platform, virtualization framework, docker.io, central service, services, how to, container, containers, automation, collaboration, collaborators, registry, repo, repository, technology, github webhooks,  trusted builds"]
 [menu.main]
 parent = "smn_pubhub"
 weight = 1
 +++
 <![end-metadata]-->
 # Getting started with Docker Hub
 This section provides a quick introduction to the [Docker Hub](https://hub.docker.com),
 including how to create an account.
 The [Docker Hub](https://hub.docker.com) is a centralized resource for working with
 Docker and its components. Docker Hub helps you collaborate with colleagues and get the
 most out of Docker. To do this, it provides services such as:
 * Docker image hosting.
 * User authentication.
 * Automated image builds and work-flow tools such as build triggers and web
  hooks.
 * Integration with GitHub and Bitbucket.
 In order to use Docker Hub, you will first need to register and create an account. Don't
 worry, creating an account is simple and free.
 ## Creating a Docker Hub account
 There are two ways for you to register and create an account:
 1. Via the web, or
 2. Via the command line.
 ### Register via the web
 Fill in the [sign-up form](https://hub.docker.com/account/signup/) by
 choosing your user name and password and entering a valid email address. You can also
 sign up for the Docker Weekly mailing list, which has lots of information about what's
 going on in the world of Docker.
 ![Register using the sign-up page](/userguide/register-web.png)
 ### Register via the command line
 You can also create a Docker Hub account via the command line with the
 `docker login` command.
    $ docker login
 ### Confirm your email
 Once you've filled in the form, check your email for a welcome message asking for
 confirmation so we can activate your account.
 ### Login
 After you complete the confirmation process, you can login using the web console:
 ![Login using the web console](/userguide/login-web.png)
 Or via the command line with the `docker login` command:
    $ docker login
 Your Docker Hub account is now active and ready to use.
 ##  Next steps
 Next, let's start learning how to Dockerize applications with our "Hello world"
 exercise.
 Go to [Dockerizing Applications](/userguide/dockerizing).
@@ -133,8 +133,8 @@ This really long string is called a *container ID*. It uniquely
 identifies a container so we can work with it.
 > **Note:** 
-> The container ID is a bit long and unwieldy and a bit later
+> The container ID is a bit long and unwieldy. A bit later,
-> on we'll see a shorter ID and some ways to name our containers to make
+> we'll see a shorter ID and ways to name our containers to make
 > working with them easier.
 We can use this container ID to see what's happening with our `hello world` daemon.
@@ -157,8 +157,8 @@ is running, its status and an automatically assigned name,
 `insane_babbage`. 
 > **Note:** 
-> Docker automatically names any containers you start, a
+> Docker automatically generates names for any containers started.
-> little later on we'll see how you can specify your own names.
+> We'll see how to specify your own names a bit later.
 Okay, so we now know it's running. But is it doing what we asked it to do? To see this
 we're going to look inside the container using the `docker logs`
@@ -227,11 +227,11 @@ The components in this prefix are:
 Docker uses this prefix format to define three distinct environment variables:
 * The `prefix_ADDR` variable contains the IP Address from the URL, for
-example `WEBDB_PORT_8080_TCP_ADDR=172.17.0.82`.
+example `WEBDB_PORT_5432_TCP_ADDR=172.17.0.82`.
 * The `prefix_PORT` variable contains just the port number from the URL for
-example `WEBDB_PORT_8080_TCP_PORT=8080`.
+example `WEBDB_PORT_5432_TCP_PORT=5432`.
 * The `prefix_PROTO` variable contains just the protocol from the URL for
-example `WEBDB_PORT_8080_TCP_PROTO=tcp`.
+example `WEBDB_PORT_5432_TCP_PROTO=tcp`.
 If the container exposes multiple ports, an environment variable set is
 defined for each one. This means, for example, if a container exposes 4 ports
@@ -240,7 +240,7 @@ that Docker creates 12 environment variables, 3 for each port.
 Additionally, Docker creates an environment variable called `<alias>_PORT`.
 This variable contains the URL of the source container's first exposed port.
 The  'first' port is defined as the exposed port with the lowest number.
-For example, consider the `WEBDB_PORT=tcp://172.17.0.82:8080` variable.  If
+For example, consider the `WEBDB_PORT=tcp://172.17.0.82:5432` variable.  If
 that port is used for both tcp and udp, then the tcp one is specified.
 Finally, Docker also exposes each Docker originated environment variable
@@ -82,8 +82,7 @@ You now have an image from which you can run containers.
 Anyone can pull public images from the [Docker Hub](https://hub.docker.com)
 registry, but if you would like to share your own images, then you must
-register first, as we saw in the [first section of the Docker User
+[register first](/docker-hub/accounts).
 Guide](/userguide/dockerhub/).
 ## Pushing a repository to Docker Hub
@@ -28,7 +28,7 @@ Docker.
 A *data volume* is a specially-designated directory within one or more
 containers that bypasses the [*Union File
-System*](/terms/layer/#union-file-system). Data volumes provide several 
+System*](/reference/glossary#union-file-system). Data volumes provide several 
 useful features for persistent or shared data:
 - Volumes are initialized when a container is created. If the container's
@@ -74,16 +74,21 @@ The output will provide details on the container configurations including the
 volumes. The output should look something similar to the following:
    ...
-    "Volumes": {
+    Mounts": [
-        "/webapp": "/var/lib/docker/volumes/fac362...80535"
+        {
-    },
+            "Name": "fac362...80535",
-    "VolumesRW": {
+            "Source": "/var/lib/docker/volumes/fac362...80535/_data",
-        "/webapp": true
+            "Destination": "/webapp",
-    }
+            "Driver": "local",
            "Mode": "",
            "RW": true
        }
    ]
    ...
-You will notice in the above 'Volumes' is specifying the location on the host and 
+You will notice in the above 'Source' is specifying the location on the host and 
-'VolumesRW' is specifying that the volume is read/write.
+'Destination' is specifying the volume location inside the container. `RW` shows
 if the volume is read/write.
 ### Mount a host directory as a data volume
@@ -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.
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
moxiegirl	942363d3ca	Merge pull request #15701 from moxiegirl/819-publish-cherrypicks 819 publish cherrypicks	2015-08-19 13:41:37 -07:00
Tonis Tiigi	44f2104028	Update volumes userguide Fixes #15644 Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com> (cherry picked from commit `cc2aab7816`)	2015-08-19 10:07:50 -07:00
Philipp Wahala	6117b05e87	Small fix in dev env docs Signed-off-by: Philipp Wahala <philipp.wahala@gmail.com> (cherry picked from commit `fbc0ea32e8`) Conflicts: docs/project/set-up-dev-env.md	2015-08-19 10:07:39 -07:00
Qiang Huang	7d7ef1188b	Add format description in run doc And only set false to --oom-kill-disable, we just need the default value to show. Signed-off-by: Qiang Huang <h.huangqiang@huawei.com> (cherry picked from commit `2a468ed7e4`)	2015-08-19 10:06:47 -07:00
Morgan Bauer	c6d31c934b	remove references to 'source repository' - rewrite intro to Dockerfile reference usage section to remove references to 'source repository' - Closes #14714 - Fixes: #8648 - Updating with Seb's comments Signed-off-by: Mary Anthony <mary@docker.com> (cherry picked from commit `b143c05d64`)	2015-08-19 10:06:38 -07:00
Sebastiaan van Stijn	8df037b7ca	docs: fix anchor link on Ubuntu installation page Signed-off-by: Sebastiaan van Stijn <github@gone.nl> (cherry picked from commit `5dd28c1f9d`)	2015-08-19 10:06:33 -07:00
Mary Anthony	72b8e7e3ac	Updating hashcode links to commands Signed-off-by: Mary Anthony <mary@docker.com> (cherry picked from commit `85c2c77188`)	2015-08-19 10:06:27 -07:00
Kai Blin	f9f2dbcb15	reference/run: Clarify the use of numeric UIDs it is possible to pass an UID that has not been created inside the container, clarify this in the docs. This should fix issue #14795 Signed-off-by: Kai Blin <kai@samba.org> (cherry picked from commit `a7cfb098d4`) Conflicts: docs/reference/run.md	2015-08-19 10:06:09 -07:00
Kai Blin	3d18cd851b	reference/run: Add a paragraph break Signed-off-by: Kai Blin <kai@samba.org> (cherry picked from commit `4d89910820`) Conflicts: docs/reference/run.md	2015-08-19 10:04:24 -07:00
Kai Blin	7324d8dd8c	reference/run: Add some articles Signed-off-by: Kai Blin <kai@samba.org> (cherry picked from commit `8a61e2b151`) Conflicts: docs/reference/run.md	2015-08-19 10:02:17 -07:00
Kai Blin	a3ae93dc2e	reference/run: Some editorial changes Based on the suggestions from @moxiegirl, some changes to make the wording more clear. Signed-off-by: Kai Blin <kai@samba.org> (cherry picked from commit `ba29d31c9c`) Conflicts: docs/reference/run.md	2015-08-19 10:00:26 -07:00
Patrick Hemmer	385676735b	add documentation clarifying behavior of VOLUME instruction Signed-off-by: Patrick Hemmer <patrick.hemmer@gmail.com> (cherry picked from commit `08a867b82f`)	2015-08-19 09:58:36 -07:00
Dharmit Shah	3e2e0397f3	Fixing docs to remove references to links under terms/ Removed terms/ directory Signed-off-by: Dharmit Shah <shahdharmit@gmail.com> (cherry picked from commit `0a925d07a8`)	2015-08-19 09:58:16 -07:00
Michael Grauer	512f486e0c	Update dev machine name to default in mac installation docs Signed-off-by: Michael Grauer <michael.grauer@kitware.com> (cherry picked from commit `f26045a534`)	2015-08-19 09:58:10 -07:00
Charles Chan	745722293d	Cleanup "Working with containers" page. * Cleanup introduction * Update output of `docker version` * Cleanup explaination of `docker inspect` * Change 'deleting' to 'removing' for consistency Signed-off-by: Charles Chan <charleswhchan@users.noreply.github.com> (cherry picked from commit `2fcae333e8`)	2015-08-19 09:58:00 -07:00
Charles Chan	87f58529b2	Reformat /containers/(id)/resize to make it consistent with "Exec Resize" section. Signed-off-by: Charles Chan <charleswhchan@users.noreply.github.com> (cherry picked from commit `6cd2d89469`) Conflicts: docs/reference/api/docker_remote_api_v1.21.md	2015-08-19 09:57:39 -07:00
Charles Chan	8f7cdbb060	Improve/fix "Dockerizing Applications" page. * Try to update the wording for the notes. Signed-off-by: Charles Chan <charleswhchan@users.noreply.github.com> (cherry picked from commit `316eb2979e`)	2015-08-19 09:53:09 -07:00
Morgan Bauer	172c412ae8	fix link Signed-off-by: Morgan Bauer <mbauer@us.ibm.com> (cherry picked from commit `c50e78e799`)	2015-08-19 09:53:04 -07:00
Diogo Monica	67baebe9e7	Fixing race condition on private key backup how-to Signed-off-by: Diogo Monica <diogo@docker.com> (cherry picked from commit `fbb268c12a`)	2015-08-19 09:52:59 -07:00
moxiegirl	e1eee1290d	Fixing bad formatting reported by David via email Fixed and tested Signed-off-by: Mary Anthony <mary@docker.com> (cherry picked from commit `ef453f7118`)	2015-08-19 09:52:40 -07:00
bin liu	d3fe81f9ba	fix broken link to glossary page. Signed-off-by: bin liu <liubin0329@gmail.com> (cherry picked from commit `f6753cd963`)	2015-08-19 09:52:23 -07:00
Sebastiaan van Stijn	551c4559ad	docs: fix fedora prerequisites heading Fixes the prerequisites heading not being rendered properly, because of a missing space. Signed-off-by: Sebastiaan van Stijn <github@gone.nl> (cherry picked from commit `2c18e1cd05`)	2015-08-19 09:52:16 -07:00
bin liu	2eaa994b24	change port number through example context Signed-off-by: bin liu <liubin0329@gmail.com> (cherry picked from commit `b0a65f93a5`)	2015-08-19 09:52:06 -07:00
moxiegirl	e9183b35a3	Merge pull request #15514 from moxiegirl/fix-installation-images Docker Toolbox Updates fixes #14561	2015-08-11 23:39:41 -07:00
Mary Anthony	19c08cd7f4	Docker Toolbox Updates fixes #14561 - Tested Mac/iterated with Jeff on fixes - Waiting on formal uninstall;manual now - 4 hour work - Fixe #14562 converting Windows to Mac - Found errors in installer need fixes/another iteration - Updated as far as possible with limited installation - 3 Hours work - Entering comments from PR review - New screen captures and migration material - Entering Sven's comment - Testing with powershell, Seb's comments - Fix link in upgrade - Minor tweaks to http and typos - Adding deprecation note Signed-off-by: Mary Anthony <mary@docker.com> (cherry picked from commit `6ca22add18`) Conflicts: docs/installation/mac.md docs/installation/windows.md	2015-08-11 23:31:06 -07:00
moxiegirl	e6d84bddc4	Merge pull request #15513 from moxiegirl/pull-link-fixes Fixes after release	2015-08-11 23:18:56 -07:00
Mary Anthony	f5ab4142be	Fixes after release Adding in a link about the deprecated material Fixing bad link to staging Signed-off-by: Mary Anthony <mary@docker.com> (cherry picked from commit `8b09f8a302`)	2015-08-11 23:16:16 -07:00
moxiegirl	7d71532829	Merge pull request #15499 from moxiegirl/fix-hub-cp Removal of docker-hub	2015-08-11 15:23:51 -07:00
Sven Dowideit	da5014009c	Removing Hub v1 documentation, Hub v2 documentation will come from that repository Signed-off-by: Sven Dowideit <SvenDowideit@home.org.au> (cherry picked from commit `70092b3ee0`)	2015-08-11 15:21:37 -07:00
Sven Dowideit	3a2e6b3871	remove unused images Signed-off-by: Sven Dowideit <SvenDowideit@home.org.au> (cherry picked from commit `9f530aba7f`)	2015-08-11 15:21:25 -07:00
moxiegirl	e041a26365	Merge pull request #15490 from moxiegirl/cp-logging-change Several fixes in formatting	2015-08-11 11:58:58 -07:00
Mary Anthony	b7960c1e45	Several fixes in formatting - fixing headings in run.md - creating a table for readability - adding index for logging - moving logging overview into logging - Updating with Seb's comments Signed-off-by: Mary Anthony <mary@docker.com> (cherry picked from commit `70aa63b92a`)	2015-08-11 11:57:54 -07:00
David Calavera	0d03096b65	Bump version to 1.8.0 Signed-off-by: David Calavera <david.calavera@gmail.com>	2015-08-11 11:35:27 -05:00
Jessica Frazelle	55e9551aaa	minor cosmetic change to client output on pull Signed-off-by: Jessica Frazelle <acidburn@docker.com> (cherry picked from commit `8bd6322760`)	2015-08-11 11:35:27 -05:00
Mary Anthony	c65afe6ba8	Updating new vm and with migrate Signed-off-by: Mary Anthony <mary@docker.com> (cherry picked from commit `e5c160e1d6`)	2015-08-11 11:35:27 -05:00
Mary Anthony	5745aaed22	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> (cherry picked from commit `d550d729e1`)	2015-08-11 11:35:27 -05:00
Diogo Monica	b6f0f93c94	Docker content trust documentation - started from Diogo's work - updated after discussions with team - Updating with new key names - fixing weight - adding in sandbox - adding in gliffy for images - backing out to old names for now - Copy edit pass - Entering comments from the content trust team - Update name of branch and image name - Removing the last diogo reference - Updating with Seb's comments Signed-off-by: Mary Anthony <mary@docker.com> (cherry picked from commit `753bf40f15`)	2015-08-11 11:35:26 -05:00
Youcef YEKHLEF	33b16fef43	Add fedora 22 install docs warning about systemd-network With systemd in version 219 IP forwarding should be forced in the interface configuration file. Signed-off-by: yyekhlef <yyekhlef@gmail.com> (cherry picked from commit `35aebdc803`)	2015-08-10 12:11:42 -05:00
Youcef YEKHLEF	9705c349c5	Add fedora 22 install docs warning about systemd-network Following @cles commit #6bd15a68c for Arch Signed-off-by: yyekhlef <yyekhlef@gmail.com> (cherry picked from commit `f224a9f3d6`)	2015-08-10 12:11:42 -05:00
Ankush Agarwal	3de34af5d1	Remove note from docker version 1.3 on Env variables Fixes #14734 Signed-off-by: Ankush Agarwal <ankushagarwal11@gmail.com> (cherry picked from commit `89ec5399af`)	2015-08-10 12:11:42 -05:00
Ankush Agarwal	b3f3abfc94	Make official install instructions use curl instead of wget YOU GO CURL Fixes #14650 Signed-off-by: Ankush Agarwal <ankushagarwal11@gmail.com> (cherry picked from commit `c76fef1791`)	2015-08-10 12:10:42 -05:00
Mary Anthony	783baec49c	Fixes #15349 too many apis Signed-off-by: Mary Anthony <mary@docker.com> (cherry picked from commit `1d5f479e01`)	2015-08-10 12:10:42 -05:00
Vincent Bernat	c1d9e7c6fb	doc: add a notice about memory accounting overhead The documentation for Debian and Ubuntu explains how to enable memory and swap accounting but doesn't explain why it is disabled in the first place. The problem with those subsystems is that they incurs a performance hit even when not used at all. Add this explanation. The provided figure are quite vague. The memory overhead is easily verifiable. It is for example cited in [RedHat documentation][]. For the performance hit, maybe the performance is better now, but a few years ago, it was said to be [between 6 and 15%][]. The goal is that people don't just enable memory accounting if they don't have a use for it. [RedHat documentation]: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Resource_Management_Guide/sec-memory.html [between 6 and 15%]: https://lwn.net/Articles/517562/ Signed-off-by: Vincent Bernat <vincent@bernat.im> (cherry picked from commit `56b33e9f27`)	2015-08-10 12:10:42 -05:00