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

819 publish cherrypicks
Update volumes userguide
2026-08-19 12:16:30 +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
84 changed files with 2771 additions and 3160 deletions
@@ -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
@@ -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.
@@ -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.
@@ -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:
@@ -72,38 +72,38 @@ installer.
 and choosing "Open" from the pop-up menu.

    The installer launches the "Install Docker Toolbox" dialog.
-
+    
    ![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.


@@ -134,9 +134,9 @@ There are two ways to use the installed tools, from the Docker Quickstart Termin
    * points the terminal environment to this VM

    Once the launch completes, the Docker Quickstart Terminal reports:
-
+    
     ![All finished](/installation/images/mac-success.png)
-
+     
    Now, you can run `docker` commands. 

 3. Verify your setup succeeded by running the `hello-world` container.
@@ -186,20 +186,20 @@ different shell such as C Shell but the commands are the same.
        To see how to connect Docker to this machine, run: docker-machine env default

    This creates a new `default` in VirtualBox.
-
+    
    ![default](/installation/images/default.png)

    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.

        $ 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
@@ -214,7 +214,7 @@ different shell such as C Shell but the commands are the same.
        export DOCKER_MACHINE_NAME="default"
        # Run this command to configure your shell: 
        # eval "$(docker-machine env default)"
-
+    
 4. Connect your shell to the `default` machine.

        $ eval "$(docker-machine env default)"
@@ -246,9 +246,9 @@ this older VM, you can migrate it.
 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:
@@ -280,9 +280,9 @@ To verify this, run the following commands:

    $ docker-machine ls
    NAME                ACTIVE   DRIVER       STATE     URL                         SWARM
-    dev                 *        virtualbox   Running   tcp://192.168.99.100:2376   
+    default             *        virtualbox   Running   tcp://192.168.99.100:2376   

-The `ACTIVE` machine, in this case `dev`, is the one your environment is pointing to.
+The `ACTIVE` machine, in this case `default`, is the one your environment is pointing to.

 ### Access container ports

@@ -319,9 +319,9 @@ The `ACTIVE` machine, in this case `dev`, is the one your environment is pointin
    not the localhost address (0.0.0.0) but is instead the address of the
    your Docker VM.

-5. Get the address of the `dev` VM.
+5. Get the address of the `default` VM.

-        $ docker-machine ip dev
+        $ docker-machine ip default
        192.168.59.103

 6. Enter the `http://192.168.59.103:49157` address in your browser:
@@ -408,7 +408,7 @@ To uninstall, do the following:

        $ docker-machine rm dev
        Successfully removed dev
-
+    
     Removing a machine deletes its VM from VirtualBox and from the
     `~/.docker/machine/machines` directory.

@@ -417,7 +417,7 @@ To uninstall, do the following:
 4. Remove the `docker`, `docker-compose`, and `docker-machine` commands from the `/usr/local/bin` folder.

        $ rm /usr/local/bin/docker
-
+      
 5. Delete the `~/.docker` folder from your system.


@@ -429,4 +429,4 @@ documentation](https://docs.docker.com/machine/).

 You can continue with the [Docker User Guide](/userguide). If you are
 interested in using the Kitematic GUI, see the [Kitermatic user
-guide](/kitematic/userguide/).
+guide](/kitematic/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)
@@ -36,7 +36,7 @@ Your machine must be running Windows 7.1, 8/8.1 or newer to run Docker. Windows
 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.

@@ -44,19 +44,19 @@ Your machine must be running Windows 7.1, 8/8.1 or newer to run Docker. Windows

    #### For Windows 8 or 8.1

-    Choose **Start > Task Manager** and navigate to the **Performance** tab.          
-    Under **CPU** you should see the following:
+	  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.
+    
+    ### 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
@@ -101,14 +101,14 @@ installer.
 3. Install Docker Toolbox by double-clicking the installer.

    The installer launches the "Setup - Docker Toolbox" dialog.
-
+    
    ![Install Docker Toolbox](/installation/images/win-welcome.png)

 4. Press "Next" to install the toolbox.

    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
@@ -120,16 +120,16 @@ installer.
 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
@@ -198,7 +198,7 @@ There are several ways to use the installed tools, from the Docker Quickstart Te
 2. Add this to the `%PATH%` environment variable by running:

        set PATH=%PATH%;"c:\Program Files (x86)\Git\bin"
-
+        
 3. Create a new Docker VM.

        docker-machine create --driver virtualbox my-default
@@ -212,20 +212,20 @@ There are several ways to use the installed tools, from the Docker Quickstart Te
    `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)"
@@ -241,21 +241,21 @@ There are several ways to use the installed tools, from the Docker Quickstart Te
 2. Add `ssh.exe` to your PATH:

        PS C:\Users\mary> $Env:Path = "${Env:Path};c:\Program Files (x86)\Git\bin"
-
+        
 3. Create a new Docker VM.

        PS C:\Users\mary> docker-machine create --driver virtualbox my-default
-
+    
 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  
-
+      
 5. Get the environment commands for your new VM.

        C:\Users\mary> docker-machine env --shell powershell my-default
-
+    
 6. Connect your shell to the `my-default` machine.

        C:\Users\mary> eval "$(docker-machine env my-default)"
@@ -288,9 +288,9 @@ this older VM, you can migrate it.
 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:
@@ -362,4 +362,4 @@ delete that file yourself.

 You can continue with the [Docker User Guide](/userguide). If you are
 interested in using the Kitematic GUI, see the [Kitermatic user
-guide](/kitematic/userguide/).
+guide](/kitematic/userguide/).
@@ -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
-    may need to run `eval "$(boot2docker shellinit)"` to initialize your shell
-    environment.
+    Mac users, use `docker-machine status your_vm_name` to make sure your VM is
+    running. You may need to run `eval "$(docker-machine env your_vm_name)"` to
+    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

@@ -0,0 +1,17 @@
+<!--[metadata]>
+++
+title = "The Docker Hub and the Registry v1"
+description = "Documentation for docker Registry and Registry API"
+keywords = ["docker, registry, api,  hub"]
+[menu.main]
+parent="smn_hub_ref"
+++
+<![end-metadata]-->
+
+# The Docker Hub and the Registry v1
+
+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
+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
+overview](/userguide/image_management/) in the current documentation set.
@@ -10,48 +10,50 @@ parent = "mn_reference"

 # Dockerfile reference

-**Docker can build images automatically** by reading the instructions
-from a `Dockerfile`. A `Dockerfile` is a text document that contains all
-the commands you would normally execute manually in order to build a
-Docker image. By calling `docker build` from your terminal, you can have
-Docker build your image step by step, executing the instructions
-successively.
+Docker can build images automatically by reading the instructions from a
+`Dockerfile`. A `Dockerfile` is a text document that contains all the commands a
+user could call on the command line to assemble an image. Using `docker build`
+users can create an automated build that executes several command-line
+instructions in succession.

-This page discusses the specifics of all the instructions you can use in your
-`Dockerfile`. To further help you write a clear, readable, maintainable
-`Dockerfile`, we've also written a [`Dockerfile` Best Practices
-guide](/articles/dockerfile_best-practices). Lastly, you can test your
-Dockerfile knowledge with the [Dockerfile tutorial](/userguide/level1).
+This page describes the commands you can use in a `Dockerfile`. When you are
+done reading this page, refer to the [`Dockerfile` Best
+Practices](/articles/dockerfile_best-practices) for a tip-oriented guide.

 ## Usage

-To [*build*](/reference/commandline/cli/#build) an image from a source repository,
-create a description file called `Dockerfile` at the root of your repository.
-This file will describe the steps to assemble the image.
+The [`docker build`](/reference/commandline/build/) command builds an image from
+a `Dockerfile` and a *context*. The build's context is the files at a specified
+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
-(for example, `.`):
+A context is processed recursively. So, a `PATH` includes any subdirectories and
+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. The build is run by the Docker daemon, not by the CLI, so the
-whole context must be transferred to the daemon. The Docker CLI reports
-"Sending build context to Docker daemon" when the context is sent to the daemon.
+The build is run by the Docker daemon, not by the CLI. The first thing a build
+process does is send the entire context (recursively) to the daemon.  In most
+cases, it's best to start with an empty directory as context and keep your
+Dockerfile in that directory. Add only the files needed for building the
+Dockerfile.

-> **Warning**
-> Avoid using your root directory, `/`, as the root of the source repository. The 
-> `docker build` command will use whatever directory contains the Dockerfile as the build
-> 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.
+>**Warning**: Do not use your root directory, `/`, as the `PATH` as it causes
+>the build to transfer the entire contents of your hard drive to the Docker
+>daemon. 

-In most cases, it's best to put each Dockerfile in an empty directory. Then,
-only add the files needed for building the Dockerfile to the directory. To
-increase the build's performance, you can exclude files and directories by
-adding a `.dockerignore` file to the directory.  For information about how to
-[create a `.dockerignore` file](#dockerignore-file) on this page.
+To use a file in the build context, the `Dockerfile` refers to the file with
+an instruction, for example,  a `COPY` instruction. To increase the build's
+performance, exclude files and directories by adding a `.dockerignore` file to
+the context directory.  For information about how to [create a `.dockerignore`
+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
@@ -160,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`.

@@ -185,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:
@@ -245,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*](
@@ -304,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`.

@@ -882,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 
@@ -900,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"
-description = "Configure logging driver."
-keywords = ["Fluentd, docker, logging, driver"]
+title = "Logging Drivers"
+description = "Logging Drivers"
+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
-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/)
+* [Configuring logging drivers](overview)
+* [Fluentd logging driver](fluentd)
+* [Journald logging driver](journald)
@@ -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
-useful to use [`docker events`](/reference/commandline/cli/#events) to see the
+or `Restarting` in [`docker ps`](/reference/commandline/ps). It can also be
+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:
-
-You would have to write policy defining a `svirt_apache_t` type.
+> **Note**: 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)
-    --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)
-    --cpu-period=0: Limit the CPU CFS (Completely Fair Scheduler) period
-    --cpuset-cpus="": CPUs in which to allow execution (0-3, 0,1)
-    --cpuset-mems="": Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems.
-    --cpu-quota=0: Limit the CPU CFS (Completely Fair Scheduler) quota
-    --blkio-weight=0: Block IO weight (relative weight) accepts a weight value between 10 and 1000.
-    --oom-kill-disable=true|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.
+| Option                     |  Description                                                                                |
+|----------------------------|---------------------------------------------------------------------------------------------|
+| `-m`, `--memory="" `       | Memory limit (format: `<number>[<unit>]`, where unit = b, k, m or g)                        |
+| `--memory-swap=""`         | Total memory limit (memory + swap, format: `<number>[<unit>]`, where unit = b, k, m or g)   |
+| `-c`, `--cpu-shares=0`     | CPU shares (relative weight)                                                                |
+| `--cpu-period=0`           | Limit the CPU CFS (Completely Fair Scheduler) period                                        |
+| `--cpuset-cpus="" `        | CPUs in which to allow execution (0-3, 0,1)                                                 |
+| `--cpuset-mems=""`         | Memory nodes (MEMs) in which to allow execution (0-3, 0,1). Only effective on NUMA systems. |
+| `--cpu-quota=0`            | Limit the CPU CFS (Completely Fair Scheduler) quota                                         |
+| `--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
-developer created additional users, those are accessible too. The
-developer can set a default user to run the first process with the
-Dockerfile `USER` instruction, but the operator can override it:
+`root` (id = 0) is the default user within a container. The image developer can
+create additional users. Those users are accessible by name.  When passing a numeric
+ID, the user does not have to exist in the container.
+
+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
@@ -32,7 +32,7 @@ $  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
+```bash
 $  docker push docker/trusttest:latest
 The push refers to a repository [docker.io/docker/trusttest] (len: 1)
 a9539b34a6ab: Image already exists
@@ -45,7 +45,7 @@ Signing and pushing trust metadata

 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. 

-```Dockerfilea
+```Dockerfile
 FROM docker/trusttest:latest
 RUN echo
 ```
@@ -45,8 +45,7 @@ The Docker client stores the keys in the `~/.docker/trust/private` directory.
 Before backing them up, you should `tar` them into an archive:

 ```bash
-$ tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private
-$ chmod 600 private_keys_backup.tar.gz
+$ umask 077; tar -zcvf private_keys_backup.tar.gz ~/.docker/trust/private; umask 022
 ```

 ## Lost keys
@@ -15,7 +15,7 @@ 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](content_trust.md).
+overview](/security/trust/content_trust).

 ### Prerequisites

@@ -25,8 +25,8 @@ 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]({{< relref "installation.md" >}}). To install Docker Compose, see the
-[detailed instructions here]({{< relref "compose/install" >}}).
+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.

@@ -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
-> on we'll see a shorter ID and some ways to name our containers to make
+> The container ID is a bit long and unwieldy. A bit later,
+> 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
-> little later on we'll see how you can specify your own names.
+> Docker automatically generates names for any containers started.
+> 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
-Guide](/userguide/dockerhub/).
+[register first](/docker-hub/accounts).

 ## 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": {
-        "/webapp": "/var/lib/docker/volumes/fac362...80535"
-    },
-    "VolumesRW": {
-        "/webapp": true
-    }
+    Mounts": [
+        {
+            "Name": "fac362...80535",
+            "Source": "/var/lib/docker/volumes/fac362...80535/_data",
+            "Destination": "/webapp",
+            "Driver": "local",
+            "Mode": "",
+            "RW": true
+        }
+    ]
    ...

-You will notice in the above 'Volumes' is specifying the location on the host and 
-'VolumesRW' is specifying that the volume is read/write.
+You will notice in the above 'Source' is specifying the location on the host and 
+'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

@@ -33,7 +33,7 @@ Docker Hub is the central hub for Docker. It hosts public Docker images
 and provides services to help you build and manage your Docker
 environment. To learn more:

-Go to [Using Docker Hub](/userguide/dockerhub).
+Go to [Using Docker Hub](/docker-hub).

 ## Dockerizing applications: A "Hello world"

@@ -11,11 +11,11 @@ parent="smn_containers"
 # Working with containers

 In the [last section of the Docker User Guide](/userguide/dockerizing)
-we launched our first containers. We launched two containers using the
-`docker run` command.
+we launched our first containers. We launched containers using the
+`docker run` command:

-* Containers we ran interactively in the foreground.
-* One container we ran daemonized in the background.
+* Interactive container runs in the foreground.
+* Daemonized container runs in the background.

 In the process we learned about several Docker commands:

@@ -43,17 +43,22 @@ version information on the currently installed Docker client and daemon.
 This command will not only provide you the version of Docker client and
 daemon you are using, but also the version of Go (the programming
 language powering Docker).
+  
+    Client:
+      Version:      1.8.1
+      API version:  1.20
+      Go version:   go1.4.2
+      Git commit:   d12ea79
+      Built:        Thu Aug 13 02:35:49 UTC 2015
+      OS/Arch:      linux/amd64

-    Client version: 0.8.0
-    Go version (client): go1.2
-
-    Git commit (client): cc3a8c8
-    Server version: 0.8.0
-
-    Git commit (server): cc3a8c8
-    Go version (server): go1.2
-
-    Last stable version: 0.8.0
+    Server:
+      Version:      1.8.1
+      API version:  1.20
+      Go version:   go1.4.2
+      Git commit:   d12ea79
+      Built:        Thu Aug 13 02:35:49 UTC 2015
+      OS/Arch:      linux/amd64

 ## Get Docker command help

@@ -105,7 +110,7 @@ Lastly, we've specified a command for our container to run: `python app.py`. Thi

 > **Note:** 
 > You can see more detail on the `docker run` command in the [command
-> reference](/reference/commandline/cli/#run) and the [Docker Run
+> reference](/reference/commandline/run) and the [Docker Run
 > Reference](/reference/run/).

 ## Viewing our web application container
@@ -219,8 +224,8 @@ the container.
 ## Inspecting our web application container

 Lastly, we can take a low-level dive into our Docker container using the
-`docker inspect` command. It returns a JSON hash of useful configuration
-and status information about Docker containers.
+`docker inspect` command. It returns a JSON document containing useful
+configuration and status information for the specified container.

    $ docker inspect nostalgic_morse

@@ -297,7 +302,7 @@ this again by stopping the container first.
 And now our container is stopped and deleted.

 > **Note:**
-> Always remember that deleting a container is final!
+> Always remember that removing a container is final!

 # Next steps
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