Converges titles to imperative-form, front-matter based, and sentence-case (#438)

Multiple title fixes, consistency fixes, convergence into metadata-based titles.
This commit is contained in:
John Mulhausen 2016-11-04 15:38:40 -07:00 committed by GitHub
parent f864c74d0d
commit 908a1f14f5
33 changed files with 193 additions and 288 deletions

View file

@ -2,15 +2,9 @@
description: describes get by digest pitfall
keywords:
- registry, manifest, images, tags, repository, distribution, digest
menu:
main:
parent: smn_registry_ref
weight: 9
title: Compatibility
title: Registry compatibility
---
# Registry Compatibility
## Synopsis
*If a manifest is pulled by _digest_ from a registry 2.3 with Docker Engine 1.9
and older, and the manifest was pushed with Docker Engine 1.10, a security check

View file

@ -2,15 +2,9 @@
description: Explains how to configure a registry
keywords:
- registry, on-prem, images, tags, repository, distribution, configuration
menu:
main:
parent: smn_registry
weight: 4
title: Configuring a registry
title: Registry configuration reference
---
# Registry Configuration Reference
The Registry configuration is based on a YAML file, detailed below. While it comes with sane default values out of the box, you are heavily encouraged to review it exhaustively before moving your systems to production.
## Override specific configuration options

View file

@ -2,15 +2,9 @@
description: Explains how to deploy a registry
keywords:
- registry, on-prem, images, tags, repository, distribution, deployment
menu:
main:
parent: smn_registry
weight: 3
title: Deploying a registry server
---
# Deploying a registry server
You need to [install Docker version 1.6.0 or newer](/engine/installation/index.md).
## Running on localhost

View file

@ -2,15 +2,9 @@
description: describes deprecated functionality
keywords:
- registry, manifest, images, signatures, repository, distribution, digest
menu:
main:
parent: smn_registry_ref
weight: 8
title: Deprecated Features
title: Docker Registry deprecation
---
# Docker Registry Deprecation
This document details functionality or components which are deprecated within
the registry.

View file

@ -2,15 +2,9 @@
description: High level discussion of garbage collection
keywords:
- registry, garbage, images, tags, repository, distribution
menu:
main:
parent: smn_registry_ref
weight: 4
title: Garbage Collection
title: Garbage collection
---
# Garbage Collection
As of v2.4.0 a garbage collector command is included within the registry binary.
This document describes what this command does and how and why it should be used.
@ -134,4 +128,3 @@ blob eligible for deletion: sha256:87192bdbe00f8f2a62527f36bb4c7c7f4eaf9307e4b87
blob eligible for deletion: sha256:b549a9959a664038fc35c155a95742cf12297672ca0ae35735ec027d55bf4e97
blob eligible for deletion: sha256:f251d679a7c61455f06d793e43c06786d7766c88b8c24edf242b2c08e3c3f599
```

View file

@ -2,15 +2,9 @@
description: Getting help with the Registry
keywords:
- registry, on-prem, images, tags, repository, distribution, help, 101, TL;DR
menu:
main:
parent: smn_registry
weight: 9
title: Getting help
title: Get help
---
# Getting help
If you need help, or just want to chat, you can reach us:
- on irc: `#docker-distribution` on freenode

View file

@ -4,19 +4,14 @@ aliases:
description: High-level overview of the Registry
keywords:
- registry, on-prem, images, tags, repository, distribution
menu:
main:
parent: smn_registry
weight: 1
title: Registry Overview
title: Docker Registry
---
# Docker Registry
## What it is
The Registry is a stateless, highly scalable server side application that stores and lets you distribute Docker images.
The Registry is open-source, under the permissive [Apache license](http://en.wikipedia.org/wiki/Apache_License).
The Registry is a stateless, highly scalable server side application that stores
and lets you distribute Docker images. The Registry is open-source, under the
permissive [Apache license](http://en.wikipedia.org/wiki/Apache_License).
## Why use it
@ -28,14 +23,19 @@ You should use the Registry if you want to:
## Alternatives
Users looking for a zero maintenance, ready-to-go solution are encouraged to head-over to the [Docker Hub](https://hub.docker.com), which provides a free-to-use, hosted Registry, plus additional features (organization accounts, automated builds, and more).
Users looking for a zero maintenance, ready-to-go solution are encouraged to
head-over to the [Docker Hub](https://hub.docker.com), which provides a
free-to-use, hosted Registry, plus additional features (organization accounts,
automated builds, and more).
Users looking for a commercially supported version of the Registry should look into [Docker Trusted Registry](/docker-trusted-registry/overview/).
Users looking for a commercially supported version of the Registry should look
into [Docker Trusted Registry](/docker-trusted-registry/overview/).
## Requirements
The Registry is compatible with Docker engine **version 1.6.0 or higher**.
If you really need to work with older Docker versions, you should look into the [old python registry](https://github.com/docker/docker-registry).
The Registry is compatible with Docker engine **version 1.6.0 or higher**. If
you really need to work with older Docker versions, you should look into the
[old python registry](https://github.com/docker/docker-registry).
## TL;DR
@ -65,4 +65,6 @@ Now stop your registry and remove all data
## Next
You should now read the [detailed introduction about the registry](introduction.md), or jump directly to [deployment instructions](deploying.md).
You should now read the [detailed introduction about the
registry](introduction.md), or jump directly to [deployment
instructions](deploying.md).

View file

@ -2,15 +2,9 @@
description: Deploying a Registry in an insecure fashion
keywords:
- registry, on-prem, images, tags, repository, distribution, insecure
menu:
main:
parent: smn_registry_ref
weight: 5
title: Testing an insecure registry
title: Test an insecure registry
---
# Insecure Registry
While it's highly recommended to secure your registry using a TLS certificate
issued by a known CA, you may alternatively decide to use self-signed
certificates, or even use your registry over plain http.

View file

@ -2,16 +2,11 @@
description: Explains what the Registry is, basic use cases and requirements
keywords:
- registry, on-prem, images, tags, repository, distribution, use cases, requirements
menu:
main:
parent: smn_registry
weight: 2
title: Understanding the Registry
title: About Registry
---
# Understanding the Registry
A registry is a storage and content delivery system, holding named Docker images, available in different tagged versions.
A registry is a storage and content delivery system, holding named Docker
images, available in different tagged versions.
> Example: the image `distribution/registry`, with tags `2.0` and `2.1`.
@ -19,13 +14,24 @@ Users interact with a registry by using docker push and pull commands.
> Example: `docker pull registry-1.docker.io/distribution/registry:2.1`.
Storage itself is delegated to drivers. The default storage driver is the local posix filesystem, which is suitable for development or small deployments. Additional cloud-based storage drivers like S3, Microsoft Azure, OpenStack Swift and Aliyun OSS are also supported. People looking into using other storage backends may do so by writing their own driver implementing the [Storage API](storage-drivers/index.md).
Storage itself is delegated to drivers. The default storage driver is the local
posix filesystem, which is suitable for development or small deployments.
Additional cloud-based storage drivers like S3, Microsoft Azure, OpenStack Swift
and Aliyun OSS are also supported. People looking into using other storage
backends may do so by writing their own driver implementing the [Storage
API](storage-drivers/index.md).
Since securing access to your hosted images is paramount, the Registry natively supports TLS and basic authentication.
Since securing access to your hosted images is paramount, the Registry natively
supports TLS and basic authentication.
The Registry GitHub repository includes additional information about advanced authentication and authorization methods. Only very large or public deployments are expected to extend the Registry in this way.
The Registry GitHub repository includes additional information about advanced
authentication and authorization methods. Only very large or public deployments
are expected to extend the Registry in this way.
Finally, the Registry ships with a robust [notification system](notifications.md), calling webhooks in response to activity, and both extensive logging and reporting, mostly useful for large installations that want to collect metrics.
Finally, the Registry ships with a robust [notification
system](notifications.md), calling webhooks in response to activity, and both
extensive logging and reporting, mostly useful for large installations that want
to collect metrics.
## Understanding image naming
@ -34,21 +40,36 @@ Image names as used in typical docker commands reflect their origin:
* `docker pull ubuntu` instructs docker to pull an image named `ubuntu` from the official Docker Hub. This is simply a shortcut for the longer `docker pull docker.io/library/ubuntu` command
* `docker pull myregistrydomain:port/foo/bar` instructs docker to contact the registry located at `myregistrydomain:port` to find the image `foo/bar`
You can find out more about the various Docker commands dealing with images in the [official Docker engine documentation](/engine/reference/commandline/cli.md).
You can find out more about the various Docker commands dealing with images in
the [official Docker engine
documentation](/engine/reference/commandline/cli.md).
## Use cases
Running your own Registry is a great solution to integrate with and complement your CI/CD system. In a typical workflow, a commit to your source revision control system would trigger a build on your CI system, which would then push a new image to your Registry if the build is successful. A notification from the Registry would then trigger a deployment on a staging environment, or notify other systems that a new image is available.
Running your own Registry is a great solution to integrate with and complement
your CI/CD system. In a typical workflow, a commit to your source revision
control system would trigger a build on your CI system, which would then push a
new image to your Registry if the build is successful. A notification from the
Registry would then trigger a deployment on a staging environment, or notify
other systems that a new image is available.
It's also an essential component if you want to quickly deploy a new image over a large cluster of machines.
It's also an essential component if you want to quickly deploy a new image over
a large cluster of machines.
Finally, it's the best way to distribute images inside an isolated network.
## Requirements
You absolutely need to be familiar with Docker, specifically with regard to pushing and pulling images. You must understand the difference between the daemon and the cli, and at least grasp basic concepts about networking.
You absolutely need to be familiar with Docker, specifically with regard to
pushing and pulling images. You must understand the difference between the
daemon and the cli, and at least grasp basic concepts about networking.
Also, while just starting a registry is fairly easy, operating it in a production environment requires operational skills, just like any other service. You are expected to be familiar with systems availability and scalability, logging and log processing, systems monitoring, and security 101. Strong understanding of http and overall network communications, plus familiarity with golang are certainly useful as well for advanced operations or hacking.
Also, while just starting a registry is fairly easy, operating it in a
production environment requires operational skills, just like any other service.
You are expected to be familiar with systems availability and scalability,
logging and log processing, systems monitoring, and security 101. Strong
understanding of http and overall network communications, plus familiarity with
golang are certainly useful as well for advanced operations or hacking.
## Next

View file

@ -2,15 +2,9 @@
description: Explains how to work with registry notifications
keywords:
- registry, on-prem, images, tags, repository, distribution, notifications, advanced
menu:
main:
parent: smn_registry
weight: 5
title: Working with notifications
title: Work with notifications
---
# Notifications
The Registry supports sending webhook notifications in response to events
happening within the registry. Notifications are sent in response to manifest
pushes and pulls and layer pushes and pulls. These actions are serialized into

View file

@ -1,16 +1,10 @@
---
description: Restricting access to your registry using an apache proxy
keywords:
- registry, on-prem, images, tags, repository, distribution, authentication, proxy,
apache, httpd, TLS, recipe, advanced
menu:
main:
parent: smn_recipes
title: Authenticating proxy with apache
- registry, on-prem, images, tags, repository, distribution, authentication, proxy, apache, httpd, TLS, recipe, advanced
title: Authenticate proxy with apache
---
# Authenticating proxy with apache
## Use-case
People already relying on an apache proxy to authenticate their users to other services might want to leverage it and have Registry communications tunneled through the same pipeline.

View file

@ -2,15 +2,9 @@
description: Fun stuff to do with your registry
keywords:
- registry, on-prem, images, tags, repository, distribution, recipes, advanced
menu:
main:
parent: smn_recipes
weight: -10
title: Recipes Overview
---
# Recipes
You will find here a list of "recipes", end-to-end scenarios for exotic or otherwise advanced use-cases.
Most users are not expected to have a use for these.

View file

@ -1,59 +1,76 @@
---
description: Setting-up a local mirror for Docker Hub images
keywords:
- registry, on-prem, images, tags, repository, distribution, mirror, Hub, recipe,
advanced
menu:
main:
parent: smn_recipes
title: Mirroring Docker Hub
- registry, on-prem, images, tags, repository, distribution, mirror, Hub, recipe, advanced
title: Registry as a pull through cache
---
# Registry as a pull through cache
## Use-case
If you have multiple instances of Docker running in your environment (e.g., multiple physical or virtual machines, all running the Docker daemon), each time one of them requires an image that it doesnt have it will go out to the internet and fetch it from the public Docker registry. By running a local registry mirror, you can keep most of the redundant image fetch traffic on your local network.
If you have multiple instances of Docker running in your environment (e.g.,
multiple physical or virtual machines, all running the Docker daemon), each time
one of them requires an image that it doesnt have it will go out to the
internet and fetch it from the public Docker registry. By running a local
registry mirror, you can keep most of the redundant image fetch traffic on your
local network.
### Alternatives
Alternatively, if the set of images you are using is well delimited, you can simply pull them manually and push them to a simple, local, private registry.
Alternatively, if the set of images you are using is well delimited, you can
simply pull them manually and push them to a simple, local, private registry.
Furthermore, if your images are all built in-house, not using the Hub at all and relying entirely on your local registry is the simplest scenario.
Furthermore, if your images are all built in-house, not using the Hub at all and
relying entirely on your local registry is the simplest scenario.
### Gotcha
It's currently not possible to mirror another private registry. Only the central Hub can be mirrored.
It's currently not possible to mirror another private registry. Only the central
Hub can be mirrored.
### Solution
The Registry can be configured as a pull through cache. In this mode a Registry responds to all normal docker pull requests but stores all content locally.
The Registry can be configured as a pull through cache. In this mode a Registry
responds to all normal docker pull requests but stores all content locally.
## How does it work?
The first time you request an image from your local registry mirror, it pulls the image from the public Docker registry and stores it locally before handing it back to you. On subsequent requests, the local registry mirror is able to serve the image from its own storage.
The first time you request an image from your local registry mirror, it pulls
the image from the public Docker registry and stores it locally before handing
it back to you. On subsequent requests, the local registry mirror is able to
serve the image from its own storage.
### What if the content changes on the Hub?
When a pull is attempted with a tag, the Registry will check the remote to ensure if it has the latest version of the requested content. If it doesn't it will fetch the latest content and cache it.
When a pull is attempted with a tag, the Registry will check the remote to
ensure if it has the latest version of the requested content. If it doesn't it
will fetch the latest content and cache it.
### What about my disk?
In environments with high churn rates, stale data can build up in the cache. When running as a pull through cache the Registry will periodically remove old content to save disk space. Subsequent requests for removed content will cause a remote fetch and local re-caching.
In environments with high churn rates, stale data can build up in the cache.
When running as a pull through cache the Registry will periodically remove old
content to save disk space. Subsequent requests for removed content will cause a
remote fetch and local re-caching.
To ensure best performance and guarantee correctness the Registry cache should be configured to use the `filesystem` driver for storage.
To ensure best performance and guarantee correctness the Registry cache should
be configured to use the `filesystem` driver for storage.
## Running a Registry as a pull through cache
The easiest way to run a registry as a pull through cache is to run the official Registry image.
The easiest way to run a registry as a pull through cache is to run the official
Registry image.
Multiple registry caches can be deployed over the same back-end. A single registry cache will ensure that concurrent requests do not pull duplicate data, but this property will not hold true for a registry cache cluster.
Multiple registry caches can be deployed over the same back-end. A single
registry cache will ensure that concurrent requests do not pull duplicate data,
but this property will not hold true for a registry cache cluster.
### Configuring the cache
To configure a Registry to run as a pull through cache, the addition of a `proxy` section is required to the config file.
To configure a Registry to run as a pull through cache, the addition of a
`proxy` section is required to the config file.
In order to access private images on the Docker Hub, a username and password can be supplied.
In order to access private images on the Docker Hub, a username and password can
be supplied.
proxy:
remoteurl: https://registry-1.docker.io
@ -66,7 +83,8 @@ In order to access private images on the Docker Hub, a username and password can
### Configuring the Docker daemon
You will need to pass the `--registry-mirror` option to your Docker daemon on startup:
You will need to pass the `--registry-mirror` option to your Docker daemon on
startup:
docker --registry-mirror=https://<my-docker-mirror-host> daemon
@ -74,4 +92,6 @@ For example, if your mirror is serving on `http://10.0.0.2:5000`, you would run:
docker --registry-mirror=https://10.0.0.2:5000 daemon
NOTE: Depending on your local host setup, you may be able to add the `--registry-mirror` option to the `DOCKER_OPTS` variable in `/etc/default/docker`.
> NOTE: Depending on your local host setup, you may be able to add the
`--registry-mirror` option to the `DOCKER_OPTS` variable in
`/etc/default/docker`.

View file

@ -1,42 +1,50 @@
---
description: Restricting access to your registry using a nginx proxy
keywords:
- registry, on-prem, images, tags, repository, distribution, nginx, proxy, authentication,
TLS, recipe, advanced
menu:
main:
parent: smn_recipes
title: Authenticating proxy with nginx
- registry, on-prem, images, tags, repository, distribution, nginx, proxy, authentication, TLS, recipe, advanced
title: Authenticate proxy with nginx
---
# Authenticating proxy with nginx
## Use-case
People already relying on a nginx proxy to authenticate their users to other services might want to leverage it and have Registry communications tunneled through the same pipeline.
People already relying on a nginx proxy to authenticate their users to other
services might want to leverage it and have Registry communications tunneled
through the same pipeline.
Usually, that includes enterprise setups using LDAP/AD on the backend and a SSO mechanism fronting their internal http portal.
Usually, that includes enterprise setups using LDAP/AD on the backend and a SSO
mechanism fronting their internal http portal.
### Alternatives
If you just want authentication for your registry, and are happy maintaining users access separately, you should really consider sticking with the native [basic auth registry feature](../deploying.md#native-basic-auth).
If you just want authentication for your registry, and are happy maintaining
users access separately, you should really consider sticking with the native
[basic auth registry feature](../deploying.md#native-basic-auth).
### Solution
With the method presented here, you implement basic authentication for docker engines in a reverse proxy that sits in front of your registry.
With the method presented here, you implement basic authentication for docker
engines in a reverse proxy that sits in front of your registry.
While we use a simple htpasswd file as an example, any other nginx authentication backend should be fairly easy to implement once you are done with the example.
While we use a simple htpasswd file as an example, any other nginx
authentication backend should be fairly easy to implement once you are done with
the example.
We also implement push restriction (to a limited user group) for the sake of the example. Again, you should modify this to fit your mileage.
We also implement push restriction (to a limited user group) for the sake of the
example. Again, you should modify this to fit your mileage.
### Gotchas
While this model gives you the ability to use whatever authentication backend you want through the secondary authentication mechanism implemented inside your proxy, it also requires that you move TLS termination from the Registry to the proxy itself.
While this model gives you the ability to use whatever authentication backend
you want through the secondary authentication mechanism implemented inside your
proxy, it also requires that you move TLS termination from the Registry to the
proxy itself.
Furthermore, introducing an extra http layer in your communication pipeline will make it more complex to deploy, maintain, and debug, and will possibly create issues. Make sure the extra complexity is required.
Furthermore, introducing an extra http layer in your communication pipeline will
make it more complex to deploy, maintain, and debug, and will possibly create
issues. Make sure the extra complexity is required.
For instance, Amazon's Elastic Load Balancer (ELB) in HTTPS mode already sets the following client header:
For instance, Amazon's Elastic Load Balancer (ELB) in HTTPS mode already sets
the following client header:
```
X-Real-IP
@ -44,7 +52,8 @@ X-Forwarded-For
X-Forwarded-Proto
```
So if you have an nginx sitting behind it, should remove these lines from the example config below:
So if you have an nginx sitting behind it, should remove these lines from the
example config below:
```
X-Real-IP $remote_addr; # pass on real client's IP
@ -52,7 +61,9 @@ X-Forwarded-For $proxy_add_x_forwarded_for;
X-Forwarded-Proto $scheme;
```
Otherwise nginx will reset the ELB's values, and the requests will not be routed properly. For more information, see [#970](https://github.com/docker/distribution/issues/970).
Otherwise nginx will reset the ELB's values, and the requests will not be routed
properly. For more information, see
[#970](https://github.com/docker/distribution/issues/970).
## Setting things up
@ -183,7 +194,8 @@ Now, start your stack:
docker-compose up -d
Login with a "push" authorized user (using `testuser` and `testpassword`), then tag and push your first image:
Login with a "push" authorized user (using `testuser` and `testpassword`), then
tag and push your first image:
docker login -u=testuser -p=testpassword -e=root@example.ch myregistrydomain.com:5043
docker tag ubuntu myregistrydomain.com:5043/test

View file

@ -2,14 +2,9 @@
description: Explains how to run a registry on macOS
keywords:
- registry, on-prem, images, tags, repository, distribution, macOS, recipe, advanced
menu:
main:
parent: smn_recipes
title: Running on macOS
title: macOS Setup Guide
---
# macOS Setup Guide
## Use-case
This is useful if you intend to run a registry server natively on macOS.

View file

@ -2,14 +2,9 @@
description: Specification for the Registry API.
keywords:
- registry, on-prem, images, tags, repository, distribution, api, advanced
menu:
main:
parent: smn_registry_ref
title: HTTP API V2
title: Docker Registry HTTP API V2
---
# Docker Registry HTTP API V2
## Introduction
The _Docker Registry HTTP API_ is the protocol to facilitate distribution of

View file

@ -2,15 +2,9 @@
description: Docker Registry v2 authentication schema
keywords:
- registry, on-prem, images, tags, repository, distribution, authentication, advanced
menu:
main:
parent: smn_registry_ref
weight: 100
title: Docker Registry Token Authentication
title: Docker Registry v2 authentication
---
# Docker Registry v2 authentication
See the [Token Authentication Specification](token.md),
[Token Authentication Implementation](jwt.md),
[Token Scope Documentation](scope.md),

View file

@ -1,17 +1,10 @@
---
description: Describe the reference implementation of the Docker Registry v2 authentication
schema
description: Describe the reference implementation of the Docker Registry v2 authentication schema
keywords:
- registry, on-prem, images, tags, repository, distribution, JWT authentication, advanced
menu:
main:
parent: smn_registry_ref
weight: 101
title: Token Authentication Implementation
title: Docker Registry v2 Bearer token specification
---
# Docker Registry v2 Bearer token specification
This specification covers the `docker/distribution` implementation of the
v2 Registry's authentication schema. Specifically, it describes the JSON
Web Token schema that `docker/distribution` has adopted to implement the

View file

@ -2,15 +2,9 @@
description: Specifies the Docker Registry v2 authentication
keywords:
- registry, on-prem, images, tags, repository, distribution, oauth2, advanced
menu:
main:
parent: smn_registry_ref
weight: 102
title: Oauth2 Token Authentication
title: Docker Registry v2 authentication using OAuth2
---
# Docker Registry v2 authentication using OAuth2
This document describes support for the OAuth2 protocol within the authorization
server. [RFC6749](https://tools.ietf.org/html/rfc6749) should be used as a
reference for the protocol and HTTP endpoints described here.
@ -188,4 +182,3 @@ Content-Type: application/json
{"refresh_token":"kas9Da81Dfa8","access_token":"eyJhbGciOiJFUzI1NiIsInR5":"expires_in":900,"scope":"repository:samalba/my-app:pull,repository:samalba/my-app:push"}
```

View file

@ -1,17 +1,10 @@
---
description: Describes the scope and access fields used for registry authorization
tokens
description: Describes the scope and access fields used for registry authorization tokens
keywords:
- registry, on-prem, images, tags, repository, distribution, advanced, access, scope
menu:
main:
parent: smn_registry_ref
weight: 103
title: Token Scope Documentation
title: Docker Registry token scope and access
---
# Docker Registry Token Scope and Access
Tokens used by the registry are always restricted what resources they may
be used to access, where those resources may be accessed, and what actions
may be done on those resources. Tokens always have the context of a user which
@ -141,4 +134,3 @@ done by fetching an access token using the refresh token. Since the refresh
token is not scoped to specific resources for an audience, extra care should
be taken to only use the refresh token to negotiate new access tokens directly
with the authorization server, and never with a resource provider.

View file

@ -1,17 +1,10 @@
---
description: Specifies the Docker Registry v2 authentication
keywords:
- registry, on-prem, images, tags, repository, distribution, Bearer authentication,
advanced
menu:
main:
parent: smn_registry_ref
weight: 104
title: Token Authentication Specification
- registry, on-prem, images, tags, repository, distribution, Bearer authentication, advanced
title: Docker Registry v2 authentication via central service
---
# Docker Registry v2 authentication via central service
This document outlines the v2 Docker registry authentication scheme:
![v2 registry auth](../../images/v2-registry-auth.png)
@ -82,7 +75,8 @@ Note the HTTP Response Header indicating the auth challenge:
Www-Authenticate: Bearer realm="https://auth.docker.io/token",service="registry.docker.io",scope="repository:samalba/my-app:pull,push"
```
This format is documented in [Section 3 of RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage](https://tools.ietf.org/html/rfc6750#section-3)
This format is documented in [Section 3 of RFC 6750: The OAuth 2.0 Authorization
Framework: Bearer Token Usage](https://tools.ietf.org/html/rfc6750#section-3)
This challenge indicates that the registry requires a token issued by the
specified token server and that the request the client is attempting will
@ -253,4 +247,5 @@ token placed in the HTTP `Authorization` header like so:
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJFUzI1NiIsImtpZCI6IkJWM0Q6MkFWWjpVQjVaOktJQVA6SU5QTDo1RU42Ok40SjQ6Nk1XTzpEUktFOkJWUUs6M0ZKTDpQT1RMIn0.eyJpc3MiOiJhdXRoLmRvY2tlci5jb20iLCJzdWIiOiJCQ0NZOk9VNlo6UUVKNTpXTjJDOjJBVkM6WTdZRDpBM0xZOjQ1VVc6NE9HRDpLQUxMOkNOSjU6NUlVTCIsImF1ZCI6InJlZ2lzdHJ5LmRvY2tlci5jb20iLCJleHAiOjE0MTUzODczMTUsIm5iZiI6MTQxNTM4NzAxNSwiaWF0IjoxNDE1Mzg3MDE1LCJqdGkiOiJ0WUpDTzFjNmNueXk3a0FuMGM3cktQZ2JWMUgxYkZ3cyIsInNjb3BlIjoiamxoYXduOnJlcG9zaXRvcnk6c2FtYWxiYS9teS1hcHA6cHVzaCxwdWxsIGpsaGF3bjpuYW1lc3BhY2U6c2FtYWxiYTpwdWxsIn0.Y3zZSwaZPqy4y9oRBVRImZyv3m_S9XDHF1tWwN7mL52C_IiA73SJkWVNsvNqpJIn5h7A2F8biv_S2ppQ1lgkbw
```
This is also described in [Section 2.1 of RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token Usage](https://tools.ietf.org/html/rfc6750#section-2.1)
This is also described in [Section 2.1 of RFC 6750: The OAuth 2.0 Authorization
Framework: Bearer Token Usage](https://tools.ietf.org/html/rfc6750#section-2.1)

View file

@ -2,15 +2,9 @@
description: Explains registry JSON objects
keywords:
- registry, service, images, repository, json
menu:
main:
parent: smn_registry_ref
weight: -1
title: Reference Overview
title: Docker Registry Reference
---
# Docker Registry Reference
* [HTTP API V2](api.md)
* [Storage Driver](../storage-drivers/index.md)
* [Token Authentication Specification](auth/token.md)

View file

@ -3,14 +3,9 @@ description: Explains registry JSON objects
published: false
keywords:
- registry, service, images, repository, json
menu:
main:
parent: smn_registry_ref
title: Docker Distribution JSON Canonicalization
title: Docker Distribution JSON canonicalization
---
# Docker Distribution JSON Canonicalization
To provide consistent content hashing of JSON objects throughout Docker
Distribution APIs, the specification defines a canonical JSON format. Adopting
such a canonicalization also aids in caching JSON responses.

View file

@ -2,14 +2,9 @@
description: image manifest for the Registry.
keywords:
- registry, on-prem, images, tags, repository, distribution, api, advanced, manifest
menu:
main:
parent: smn_registry_ref
title: 'Image Manifest V 2, Schema 1 '
title: Image manifest V2, schema 1
---
# Image Manifest Version 2, Schema 1
This document outlines the format of of the V2 image manifest. The image
manifest described herein was introduced in the Docker daemon in the [v1.3.0
release](https://github.com/docker/docker/commit/9f482a66ab37ec396ac61ed0c00d59122ac07453).

View file

@ -2,14 +2,9 @@
description: image manifest for the Registry.
keywords:
- registry, on-prem, images, tags, repository, distribution, api, advanced, manifest
menu:
main:
parent: smn_registry_ref
title: 'Image Manifest V 2, Schema 2 '
title: Image manifest V2, schema 2
---
# Image Manifest Version 2, Schema 2
This document outlines the format of of the V2 image manifest, schema version 2.
The original (and provisional) image manifest for V2 (schema 1), was introduced
in the Docker daemon in the [v1.3.0

View file

@ -2,14 +2,9 @@
description: Explains how to use the Azure storage drivers
keywords:
- registry, service, driver, images, storage, azure
menu:
main:
parent: smn_storagedrivers
title: Microsoft Azure storage driver
---
# Microsoft Azure storage driver
An implementation of the `storagedriver.StorageDriver` interface which uses [Microsoft Azure Blob Storage](http://azure.microsoft.com/en-us/services/storage/) for object storage.
## Parameters

View file

@ -2,14 +2,9 @@
description: Explains how to use the filesystem storage drivers
keywords:
- registry, service, driver, images, storage, filesystem
menu:
main:
parent: smn_storagedrivers
title: Filesystem storage driver
---
# Filesystem storage driver
An implementation of the `storagedriver.StorageDriver` interface which uses the local filesystem.
## Parameters

View file

@ -2,14 +2,9 @@
description: Explains how to use the Google Cloud Storage drivers
keywords:
- registry, service, driver, images, storage, gcs, google, cloud
menu:
main:
parent: smn_storagedrivers
title: GCS storage driver
title: Google Cloud Storage driver
---
# Google Cloud Storage driver
An implementation of the `storagedriver.StorageDriver` interface which uses Google Cloud for object storage.
## Parameters

View file

@ -4,16 +4,9 @@ aliases:
description: Explains how to use storage drivers
keywords:
- registry, on-prem, images, tags, repository, distribution, storage drivers, advanced
menu:
main:
identifier: storage_index
parent: smn_storagedrivers
weight: -1
title: Storage Driver overview
title: Docker Registry storage driver
---
# Docker Registry Storage Driver
This document describes the registry storage driver model, implementation, and explains how to contribute new storage drivers.
## Provided Drivers

View file

@ -2,14 +2,9 @@
description: Explains how to use the in-memory storage drivers
keywords:
- registry, service, driver, images, storage, in-memory
menu:
main:
parent: smn_storagedrivers
title: In-memory storage driver
title: In-memory storage driver (testing only)
---
# In-memory storage driver (Testing Only)
For purely tests purposes, you can use the `inmemory` storage driver. This
driver is an implementation of the `storagedriver.StorageDriver` interface which
uses local memory for object storage. If you would like to run a registry from

View file

@ -2,15 +2,11 @@
description: Explains how to use the Aliyun OSS storage driver
keywords:
- registry, service, driver, images, storage, OSS, aliyun
menu:
main:
parent: smn_storagedrivers
title: Aliyun OSS storage driver
---
# Aliyun OSS storage driver
An implementation of the `storagedriver.StorageDriver` interface which uses [Aliyun OSS](http://www.aliyun.com/product/oss) for object storage.
An implementation of the `storagedriver.StorageDriver` interface which uses
[Aliyun OSS](http://www.aliyun.com/product/oss) for object storage.
## Parameters

View file

@ -2,15 +2,11 @@
description: Explains how to use the S3 storage drivers
keywords:
- registry, service, driver, images, storage, S3
menu:
main:
parent: smn_storagedrivers
title: S3 storage driver
---
# S3 storage driver
An implementation of the `storagedriver.StorageDriver` interface which uses Amazon S3 or S3 compatible services for object storage.
An implementation of the `storagedriver.StorageDriver` interface which uses
Amazon S3 or S3 compatible services for object storage.
## Parameters
@ -221,17 +217,25 @@ The following IAM permissions are required by the registry for push and pull. S
## Use Case
Adding CloudFront as a middleware for your S3 backed registry can dramatically improve pull times. Your registry will have the ability to retrieve your images from edge servers, rather than the geographically limited location of your S3 bucket. The farther your registry is from your bucket, the more improvements you will see. See [Amazon CloudFront](https://aws.amazon.com/cloudfront/details/).
Adding CloudFront as a middleware for your S3 backed registry can dramatically
improve pull times. Your registry will have the ability to retrieve your images
from edge servers, rather than the geographically limited location of your S3
bucket. The farther your registry is from your bucket, the more improvements you
will see. See [Amazon CloudFront](https://aws.amazon.com/cloudfront/details/).
## Configuring CloudFront for Distribution
If you are unfamiliar with creating a CloudFront distribution, see [Getting Started with Cloudfront](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.html).
If you are unfamiliar with creating a CloudFront distribution, see [Getting
Started with
Cloudfront](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/GettingStarted.html).
Defaults can be kept in most areas except:
### Origin:
The CloudFront distribution must be created such that the `Origin Path` is set to the directory level of the root "docker" key in S3. If your registry exists on the root of the bucket, this path should be left blank.
The CloudFront distribution must be created such that the `Origin Path` is set
to the directory level of the root "docker" key in S3. If your registry exists
on the root of the bucket, this path should be left blank.
### Behaviors:
@ -243,7 +247,9 @@ The CloudFront distribution must be created such that the `Origin Path` is set t
## Registry configuration
Here the `middleware` option is used. It is still important to keep the `storage` option as CloudFront will only handle `pull` actions; `push` actions are still directly written to S3.
Here the `middleware` option is used. It is still important to keep the
`storage` option as CloudFront will only handle `pull` actions; `push` actions
are still directly written to S3.
The following example shows what you will need at minimum:
@ -265,4 +271,6 @@ middleware:
## CloudFront Key-Pair
A CloudFront key-pair is required for all AWS accounts needing access to your CloudFront distribution. For information, please see [Creating CloudFront Key Pairs](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-trusted-signers.html#private-content-creating-cloudfront-key-pairs).
A CloudFront key-pair is required for all AWS accounts needing access to your
CloudFront distribution. For information, please see [Creating CloudFront Key
Pairs](http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-trusted-signers.html#private-content-creating-cloudfront-key-pairs).

View file

@ -2,15 +2,12 @@
description: Explains how to use the OpenStack swift storage driver
keywords:
- registry, service, driver, images, storage, swift
menu:
main:
parent: smn_storagedrivers
title: Swift storage driver
title: OpenStack Swift storage driver
---
# OpenStack Swift storage driver
An implementation of the `storagedriver.StorageDriver` interface that uses [OpenStack Swift](http://docs.openstack.org/developer/swift/) for object storage.
An implementation of the `storagedriver.StorageDriver` interface that uses
[OpenStack Swift](http://docs.openstack.org/developer/swift/) for object
storage.
## Parameters
@ -210,8 +207,9 @@ An implementation of the `storagedriver.StorageDriver` interface that uses [Open
</tr>
</table>
The features supported by the Swift server are queried by requesting the `/info` URL on the server. In case the administrator
disabled that feature, the configuration file can specify the following optional parameters :
The features supported by the Swift server are queried by requesting the `/info`
URL on the server. In case the administrator disabled that feature, the
configuration file can specify the following optional parameters :
<table>
<tr>