Merge pull request #603 from londoncalling/vnext-compose-1.9.0-merge
Vnext compose 1.9.0 merge
This commit is contained in:
Victoria Bialas
GitHub
commit
0060344386
@ -1,16 +1,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
|
||||
keywords: registry, manifest, images, tags, repository, distribution, digest
|
||||
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
|
||||
@ -81,4 +74,4 @@ constraints of CAS.*
|
||||
For this reason 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 will cause the Engine to receive a manifest it cannot use and the
|
||||
pull will fail.
|
||||
pull will fail.
|
||||
@ -1,16 +1,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
|
||||
keywords: registry, on-prem, images, tags, repository, distribution, configuration
|
||||
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
|
||||
@ -1863,4 +1856,4 @@ The following example illustrates these values:
|
||||
|
||||
>**Note**: Cloudfront keys exist separately to other AWS keys. See
|
||||
>[the documentation on AWS credentials](http://docs.aws.amazon.com/general/latest/gr/aws-security-credentials.html)
|
||||
>for more information.
|
||||
>for more information.
|
||||
@ -1,16 +1,9 @@
|
||||
---
|
||||
description: Explains how to deploy a registry
|
||||
keywords:
|
||||
- registry, on-prem, images, tags, repository, distribution, deployment
|
||||
menu:
|
||||
main:
|
||||
parent: smn_registry
|
||||
weight: 3
|
||||
keywords: registry, on-prem, images, tags, repository, distribution, deployment
|
||||
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
|
||||
@ -234,4 +227,4 @@ You will find more specific and advanced informations in the following sections:
|
||||
- [Advanced "recipes"](recipes/index.md)
|
||||
- [Registry API](spec/api.md)
|
||||
- [Storage driver model](storage-drivers/index.md)
|
||||
- [Token authentication](spec/auth/token.md)
|
||||
- [Token authentication](spec/auth/token.md)
|
||||
@ -1,16 +1,9 @@
|
||||
---
|
||||
description: describes deprecated functionality
|
||||
keywords:
|
||||
- registry, manifest, images, signatures, repository, distribution, digest
|
||||
menu:
|
||||
main:
|
||||
parent: smn_registry_ref
|
||||
weight: 8
|
||||
title: Deprecated Features
|
||||
keywords: registry, manifest, images, signatures, repository, distribution, digest
|
||||
title: Docker Registry deprecation
|
||||
---
|
||||
|
||||
# Docker Registry Deprecation
|
||||
|
||||
This document details functionality or components which are deprecated within
|
||||
the registry.
|
||||
|
||||
@ -24,4 +17,4 @@ not stored in the registry. This does not alter the functional behavior of
|
||||
the registry.
|
||||
|
||||
Old signatures blobs can be removed from the registry storage by running the
|
||||
garbage-collect subcommand.
|
||||
garbage-collect subcommand.
|
||||
@ -1,16 +1,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
|
||||
keywords: registry, garbage, images, tags, repository, distribution
|
||||
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.
|
||||
|
||||
@ -133,5 +126,4 @@ blob eligible for deletion: sha256:7e15ce58ccb2181a8fced7709e9893206f0937cc9543b
|
||||
blob eligible for deletion: sha256:87192bdbe00f8f2a62527f36bb4c7c7f4eaf9307e4b87e8334fb6abec1765bcb
|
||||
blob eligible for deletion: sha256:b549a9959a664038fc35c155a95742cf12297672ca0ae35735ec027d55bf4e97
|
||||
blob eligible for deletion: sha256:f251d679a7c61455f06d793e43c06786d7766c88b8c24edf242b2c08e3c3f599
|
||||
```
|
||||
|
||||
```
|
||||
13
docs/help.md
13
docs/help.md
@ -1,16 +1,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
|
||||
keywords: registry, on-prem, images, tags, repository, distribution, help, 101, TL;DR
|
||||
title: Get help
|
||||
---
|
||||
|
||||
# Getting help
|
||||
|
||||
If you need help, or just want to chat, you can reach us:
|
||||
|
||||
- on irc: `#docker-distribution` on freenode
|
||||
@ -21,4 +14,4 @@ If you want to report a bug:
|
||||
- be sure to first read about [how to contribute](https://github.com/docker/distribution/blob/master/CONTRIBUTING.md)
|
||||
- you can then do so on the [GitHub project bugtracker](https://github.com/docker/distribution/issues)
|
||||
|
||||
You can also find out more about the Docker's project [Getting Help resources](/opensource/get-help.md).
|
||||
You can also find out more about the Docker's project [Getting Help resources](/opensource/get-help.md).
|
||||
@ -1,22 +1,16 @@
|
||||
---
|
||||
aliases:
|
||||
- /registry/overview/
|
||||
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
|
||||
keywords: registry, on-prem, images, tags, repository, distribution
|
||||
redirect_from:
|
||||
- /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 +22,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 +64,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).
|
||||
@ -1,16 +1,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
|
||||
keywords: registry, on-prem, images, tags, repository, distribution, insecure
|
||||
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.
|
||||
@ -111,4 +104,4 @@ update-ca-trust
|
||||
$ update-ca-trust enable
|
||||
```
|
||||
|
||||
Now restart docker (`service docker stop && service docker start`, or any other way you use to restart docker).
|
||||
Now restart docker (`service docker stop && service docker start`, or any other way you use to restart docker).
|
||||
@ -1,17 +1,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
|
||||
keywords: registry, on-prem, images, tags, repository, distribution, use cases, requirements
|
||||
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 +13,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,22 +39,37 @@ 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
|
||||
|
||||
Dive into [deploying your registry](deploying.md)
|
||||
Dive into [deploying your registry](deploying.md)
|
||||
@ -1,16 +1,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
|
||||
keywords: registry, on-prem, images, tags, repository, distribution, notifications, advanced
|
||||
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
|
||||
@ -347,4 +340,4 @@ provide acceptable guarantees, adding a transactional `Sink` to the registry
|
||||
is a possibility, although it may have an effect on request service time.
|
||||
Please see the
|
||||
[godoc](http://godoc.org/github.com/docker/distribution/notifications#Sink)
|
||||
for more information.
|
||||
for more information.
|
||||
@ -1,16 +1,9 @@
|
||||
---
|
||||
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
|
||||
keywords: 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.
|
||||
@ -19,7 +12,7 @@ Usually, that includes enterprise setups using LDAP/AD on the backend and a SSO
|
||||
|
||||
### 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
|
||||
|
||||
@ -27,7 +20,7 @@ With the method presented here, you implement basic authentication for docker en
|
||||
|
||||
While we use a simple htpasswd file as an example, any other apache 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
|
||||
|
||||
@ -200,7 +193,7 @@ Now, start your stack:
|
||||
|
||||
docker-compose up -d
|
||||
|
||||
Login with a "push" authorized user (using `testuserpush` and `testpasswordpush`), then tag and push your first image:
|
||||
Login with a "push" authorized user (using `testuserpush` and `testpasswordpush`), then tag and push your first image:
|
||||
|
||||
docker login myregistrydomain.com:5043
|
||||
docker tag ubuntu myregistrydomain.com:5043/test
|
||||
@ -213,4 +206,4 @@ Now, login with a "pull-only" user (using `testuser` and `testpassword`), then p
|
||||
|
||||
Verify that the "pull-only" can NOT push:
|
||||
|
||||
docker push myregistrydomain.com:5043/test
|
||||
docker push myregistrydomain.com:5043/test
|
||||
@ -1,16 +1,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
|
||||
keywords: registry, on-prem, images, tags, repository, distribution, recipes, advanced
|
||||
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.
|
||||
@ -34,4 +27,4 @@ At this point, it's assumed that:
|
||||
* [using Apache as an authenticating proxy](apache.md)
|
||||
* [using Nginx as an authenticating proxy](nginx.md)
|
||||
* [running a Registry on macOS](osx-setup-guide.md)
|
||||
* [mirror the Docker Hub](mirror.md)
|
||||
* [mirror the Docker Hub](mirror.md)
|
||||
@ -1,59 +1,75 @@
|
||||
---
|
||||
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
|
||||
keywords: 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 doesn’t have it will go out to the internet and fetch it from the public Docker registry. By running a local registry mirror, you can keep most of the 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 doesn’t have it will go out to the
|
||||
internet and fetch it from the public Docker registry. By running a local
|
||||
registry mirror, you can keep most of the 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 +82,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 +91,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`.
|
||||
@ -1,42 +1,49 @@
|
||||
---
|
||||
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
|
||||
keywords: 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 +51,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 +60,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,9 +193,10 @@ 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
|
||||
docker push myregistrydomain.com:5043/test
|
||||
docker pull myregistrydomain.com:5043/test
|
||||
docker pull myregistrydomain.com:5043/test
|
||||
@ -1,15 +1,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
|
||||
keywords: registry, on-prem, images, tags, repository, distribution, macOS, recipe, advanced
|
||||
title: macOS Setup Guide
|
||||
---
|
||||
|
||||
# macOS Setup Guide
|
||||
|
||||
## Use-case
|
||||
|
||||
This is useful if you intend to run a registry server natively on macOS.
|
||||
@ -78,4 +72,4 @@ Start the Docker registry:
|
||||
|
||||
### Unloading the docker registry service
|
||||
|
||||
launchctl unload ~/Library/LaunchAgents/com.docker.registry.plist
|
||||
launchctl unload ~/Library/LaunchAgents/com.docker.registry.plist
|
||||
@ -1,15 +1,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
|
||||
keywords: registry, on-prem, images, tags, repository, distribution, api, advanced
|
||||
title: Docker Registry HTTP API V2
|
||||
---
|
||||
|
||||
# Docker Registry HTTP API V2
|
||||
|
||||
## Introduction
|
||||
|
||||
The _Docker Registry HTTP API_ is the protocol to facilitate distribution of
|
||||
@ -5481,4 +5475,4 @@ The following headers will be returned with the response:
|
||||
|Name|Description|
|
||||
|----|-----------|
|
||||
|`Content-Length`|Length of the JSON response body.|
|
||||
|`Link`|RFC5988 compliant rel='next' with URL to next result set, if available|
|
||||
|`Link`|RFC5988 compliant rel='next' with URL to next result set, if available|
|
||||
@ -1,17 +1,10 @@
|
||||
---
|
||||
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
|
||||
keywords: registry, on-prem, images, tags, repository, distribution, authentication, advanced
|
||||
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),
|
||||
[OAuth2 Token Authentication](oauth.md) for more information.
|
||||
[OAuth2 Token Authentication](oauth.md) for more information.
|
||||
@ -1,17 +1,9 @@
|
||||
---
|
||||
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
|
||||
description: Describe the reference implementation of the Docker Registry v2 authentication schema
|
||||
keywords: registry, on-prem, images, tags, repository, distribution, JWT authentication, advanced
|
||||
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
|
||||
@ -332,4 +324,4 @@ authorization then the registry will return the appropriate error.
|
||||
|
||||
At no point in this process should the registry need to call back to the
|
||||
authorization server. The registry only needs to be supplied with the trusted
|
||||
public keys to verify the token signatures.
|
||||
public keys to verify the token signatures.
|
||||
@ -1,16 +1,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
|
||||
keywords: registry, on-prem, images, tags, repository, distribution, oauth2, advanced
|
||||
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.
|
||||
@ -187,5 +180,4 @@ HTTP/1.1 200 OK
|
||||
Content-Type: application/json
|
||||
|
||||
{"refresh_token":"kas9Da81Dfa8","access_token":"eyJhbGciOiJFUzI1NiIsInR5":"expires_in":900,"scope":"repository:samalba/my-app:pull,repository:samalba/my-app:push"}
|
||||
```
|
||||
|
||||
```
|
||||
@ -1,17 +1,9 @@
|
||||
---
|
||||
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
|
||||
description: Describes the scope and access fields used for registry authorization tokens
|
||||
keywords: registry, on-prem, images, tags, repository, distribution, advanced, access, scope
|
||||
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
|
||||
@ -140,5 +132,4 @@ restricting scope to specific type, name, and actions combinations should be
|
||||
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.
|
||||
|
||||
with the authorization server, and never with a resource provider.
|
||||
@ -1,17 +1,9 @@
|
||||
---
|
||||
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
|
||||
keywords: 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:
|
||||
|
||||
|
||||
@ -26,7 +18,7 @@ This document outlines the v2 Docker registry authentication scheme:
|
||||
5. The client retries the original request with the Bearer token embedded in
|
||||
the request's Authorization header.
|
||||
6. The Registry authorizes the client by validating the Bearer token and the
|
||||
claim set embedded within it and begins the push/pull session as usual.
|
||||
claim set embedded within it and begins the push/pull session as usual.
|
||||
|
||||
## Requirements
|
||||
|
||||
@ -82,7 +74,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
|
||||
@ -162,7 +155,7 @@ Defines getting a bearer and refresh token using the token endpoint.
|
||||
<code>expires_in</code>
|
||||
</dt>
|
||||
<dd>
|
||||
(Optional) The duration in seconds since the token was issued that it
|
||||
(Optional) The duration in seconds since the token was issued that it
|
||||
will remain valid. When omitted, this defaults to 60 seconds. For
|
||||
compatibility with older clients, a token should never be returned with
|
||||
less than 60 seconds to live.
|
||||
@ -253,4 +246,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)
|
||||
@ -1,17 +1,10 @@
|
||||
---
|
||||
description: Explains registry JSON objects
|
||||
keywords:
|
||||
- registry, service, images, repository, json
|
||||
menu:
|
||||
main:
|
||||
parent: smn_registry_ref
|
||||
weight: -1
|
||||
title: Reference Overview
|
||||
keywords: registry, service, images, repository, json
|
||||
title: Docker Registry Reference
|
||||
---
|
||||
|
||||
# Docker Registry Reference
|
||||
|
||||
* [HTTP API V2](api.md)
|
||||
* [Storage Driver](../storage-drivers/index.md)
|
||||
* [Token Authentication Specification](auth/token.md)
|
||||
* [Token Authentication Implementation](auth/jwt.md)
|
||||
* [Token Authentication Implementation](auth/jwt.md)
|
||||
@ -1,16 +1,10 @@
|
||||
---
|
||||
description: Explains registry JSON objects
|
||||
keywords: registry, service, images, repository, json
|
||||
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.
|
||||
@ -89,4 +83,4 @@ var canonical bytes.Buffer
|
||||
if err := json.Indent(&canonical, incoming, "", ""); err != nil {
|
||||
// ... handle error
|
||||
}
|
||||
```
|
||||
```
|
||||
@ -1,15 +1,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 '
|
||||
keywords: registry, on-prem, images, tags, repository, distribution, api, advanced, manifest
|
||||
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).
|
||||
@ -164,4 +158,4 @@ by *libtrust*. A signature consists of the following fields:
|
||||
]
|
||||
}
|
||||
|
||||
```
|
||||
```
|
||||
@ -1,15 +1,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 '
|
||||
keywords: registry, on-prem, images, tags, repository, distribution, api, advanced, manifest
|
||||
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
|
||||
@ -295,4 +289,4 @@ their own, but only serve to fill in the parent chain in a compatible way.
|
||||
The IDs in these synthetic configurations will be derived from hashes of their
|
||||
respective blobs. The registry will create these configurations and their IDs
|
||||
using the same scheme as Docker 1.10 when it creates a legacy manifest to push
|
||||
to a registry which doesn't support the new format.
|
||||
to a registry which doesn't support the new format.
|
||||
@ -1,15 +1,9 @@
|
||||
---
|
||||
description: Explains how to use the Azure storage drivers
|
||||
keywords:
|
||||
- registry, service, driver, images, storage, azure
|
||||
menu:
|
||||
main:
|
||||
parent: smn_storagedrivers
|
||||
keywords: registry, service, driver, images, storage, azure
|
||||
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
|
||||
@ -74,4 +68,4 @@ An implementation of the `storagedriver.StorageDriver` interface which uses [Mic
|
||||
* To get information about
|
||||
[azure-blob-storage](http://azure.microsoft.com/en-us/services/storage/) visit
|
||||
the Microsoft website.
|
||||
* You can use Microsoft's [Blob Service REST API](https://msdn.microsoft.com/en-us/library/azure/dd135733.aspx) to [create a container] (https://msdn.microsoft.com/en-us/library/azure/dd179468.aspx).
|
||||
* You can use Microsoft's [Blob Service REST API](https://msdn.microsoft.com/en-us/library/azure/dd135733.aspx) to [create a container] (https://msdn.microsoft.com/en-us/library/azure/dd179468.aspx).
|
||||
@ -1,15 +1,9 @@
|
||||
---
|
||||
description: Explains how to use the filesystem storage drivers
|
||||
keywords:
|
||||
- registry, service, driver, images, storage, filesystem
|
||||
menu:
|
||||
main:
|
||||
parent: smn_storagedrivers
|
||||
keywords: registry, service, driver, images, storage, filesystem
|
||||
title: Filesystem storage driver
|
||||
---
|
||||
|
||||
# Filesystem storage driver
|
||||
|
||||
An implementation of the `storagedriver.StorageDriver` interface which uses the local filesystem.
|
||||
|
||||
## Parameters
|
||||
@ -20,4 +14,4 @@ there is adequate space available. Defaults to `/var/lib/registry`.
|
||||
`maxthreads`: (optional) The maximum number of simultaneous blocking filesystem
|
||||
operations permitted within the registry. Each operation spawns a new thread and
|
||||
may cause thread exhaustion issues if many are done in parallel. Defaults to
|
||||
`100`, and can be no lower than `25`.
|
||||
`100`, and can be no lower than `25`.
|
||||
@ -1,15 +1,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
|
||||
keywords: registry, service, driver, images, storage, gcs, google, cloud
|
||||
title: Google Cloud Storage driver
|
||||
---
|
||||
|
||||
# Google Cloud Storage driver
|
||||
|
||||
An implementation of the `storagedriver.StorageDriver` interface which uses Google Cloud for object storage.
|
||||
|
||||
## Parameters
|
||||
@ -74,4 +68,4 @@ An implementation of the `storagedriver.StorageDriver` interface which uses Goog
|
||||
|
||||
**Note** Instead of a key file you can use [Google Application Default Credentials](https://developers.google.com/identity/protocols/application-default-credentials).
|
||||
|
||||
`rootdirectory`: (optional) The root directory tree in which all registry files will be stored. Defaults to the empty string (bucket root).
|
||||
`rootdirectory`: (optional) The root directory tree in which all registry files will be stored. Defaults to the empty string (bucket root).
|
||||
@ -1,19 +1,11 @@
|
||||
---
|
||||
aliases:
|
||||
- /registry/storagedrivers/
|
||||
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
|
||||
keywords: registry, on-prem, images, tags, repository, distribution, storage drivers, advanced
|
||||
redirect_from:
|
||||
- /registry/storagedrivers/
|
||||
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
|
||||
@ -63,4 +55,4 @@ Storage drivers should call `factory.Register` with their driver name in an `ini
|
||||
Storage driver test suites are provided in
|
||||
`storagedriver/testsuites/testsuites.go` and may be used for any storage
|
||||
driver written in Go. Tests can be registered using the `RegisterSuite`
|
||||
function, which run the same set of tests for any registered drivers.
|
||||
function, which run the same set of tests for any registered drivers.
|
||||
@ -1,15 +1,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
|
||||
keywords: registry, service, driver, images, storage, in-memory
|
||||
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
|
||||
@ -19,4 +13,4 @@ volatile memory, use the [`filesystem` driver](filesystem.md) on a ramdisk.
|
||||
|
||||
## Parameters
|
||||
|
||||
None
|
||||
None
|
||||
@ -1,16 +1,11 @@
|
||||
---
|
||||
description: Explains how to use the Aliyun OSS storage driver
|
||||
keywords:
|
||||
- registry, service, driver, images, storage, OSS, aliyun
|
||||
menu:
|
||||
main:
|
||||
parent: smn_storagedrivers
|
||||
keywords: registry, service, driver, images, storage, OSS, aliyun
|
||||
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
|
||||
|
||||
@ -123,4 +118,4 @@ no
|
||||
<td> The root directory tree in which to store all registry files. Defaults to an empty string (bucket root).
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
</table>
|
||||
@ -1,16 +1,11 @@
|
||||
---
|
||||
description: Explains how to use the S3 storage drivers
|
||||
keywords:
|
||||
- registry, service, driver, images, storage, S3
|
||||
menu:
|
||||
main:
|
||||
parent: smn_storagedrivers
|
||||
keywords: registry, service, driver, images, storage, S3
|
||||
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 +216,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 +246,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 +270,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).
|
||||
@ -1,16 +1,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
|
||||
keywords: registry, service, driver, images, storage, swift
|
||||
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 +206,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>
|
||||
@ -242,4 +239,4 @@ disabled that feature, the configuration file can specify the following optional
|
||||
</p>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
</table>
|
||||
Loading…
Reference in New Issue
Block a user