Various copyedits to reduce future tense, wordiness, and use of 'please' (#5788)
* Reword lots of instances of 'will' * Reword lots of instances of won't * Reword lots of instances of we'll * Eradicate you'll * Eradicate 'be able to' type of phrases * Eradicate 'unable to' type of phrases * Eradicate 'has / have to' type of phrases * Eradicate 'note that' type of phrases * Eradicate 'in order to' type of phrases * Redirect to official Chef and Puppet docs * Eradicate gratuitous 'please' * Reduce use of e.g. * Reduce use of i.e. * Reduce use of N.B. * Get rid of 'sexagesimal' and correct some errors
This commit is contained in:
Misty Stanley-Jones
GitHub
parent
b5bbca9ed4
commit
f1fb06838a
14 changed files with 114 additions and 122 deletions
|
|
@ -26,7 +26,7 @@ We also implement push restriction (to a limited user group) for the sake of the
|
|||
|
||||
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.
|
||||
Furthermore, introducing an extra http layer in your communication pipeline adds complexity when deploying, maintaining, and debugging.
|
||||
|
||||
## Setting things up
|
||||
|
||||
|
|
@ -40,7 +40,7 @@ Run the following script:
|
|||
mkdir -p auth
|
||||
mkdir -p data
|
||||
|
||||
# This is the main apache configuration you will use
|
||||
# This is the main apache configuration
|
||||
cat <<EOF > auth/httpd.conf
|
||||
LoadModule headers_module modules/mod_headers.so
|
||||
|
||||
|
|
|
|||
|
|
@ -4,15 +4,12 @@ keywords: registry, on-prem, images, tags, repository, distribution, recipes, ad
|
|||
title: Recipes overview
|
||||
---
|
||||
|
||||
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.
|
||||
This list of "recipes" provides end-to-end scenarios for exotic or otherwise advanced use-cases.
|
||||
These recipes are not useful for most standard set-ups.
|
||||
|
||||
## Requirements
|
||||
|
||||
You should have followed entirely the basic [deployment guide](../deploying.md).
|
||||
|
||||
If you have not, please take the time to do so.
|
||||
Before following these steps, work through the [deployment guide](../deploying.md).
|
||||
|
||||
At this point, it's assumed that:
|
||||
|
||||
|
|
|
|||
|
|
@ -8,12 +8,11 @@ redirect_from:
|
|||
|
||||
## 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, such as
|
||||
multiple physical or virtual machines all running Docker, each daemon goes out
|
||||
to the internet and fetches an image it doesn't have locally, from the Docker
|
||||
repository. You can run a local registry mirror and point all your daemons
|
||||
there, to avoid this extra internet traffic.
|
||||
|
||||
### Alternatives
|
||||
|
||||
|
|
@ -30,7 +29,7 @@ Hub can be mirrored.
|
|||
|
||||
### Solution
|
||||
|
||||
The Registry can be configured as a pull through cache. In this mode a Registry
|
||||
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?
|
||||
|
|
@ -42,15 +41,15 @@ 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 checks the remote to
|
||||
ensure if it has the latest version of the requested content. Otherwise, it
|
||||
fetches and caches the latest content.
|
||||
|
||||
### 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
|
||||
When running as a pull through cache the Registry periodically removes old
|
||||
content to save disk space. Subsequent requests for removed content causes a
|
||||
remote fetch and local re-caching.
|
||||
|
||||
To ensure best performance and guarantee correctness the Registry cache should
|
||||
|
|
@ -61,16 +60,16 @@ be configured to use the `filesystem` driver for storage.
|
|||
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 ensures that concurrent requests do not pull duplicate data,
|
||||
but this property does not hold true for a registry cache cluster.
|
||||
|
||||
### Configure 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.
|
||||
|
||||
In order to access private images on the Docker Hub, a username and password can
|
||||
To access private images on the Docker Hub, a username and password can
|
||||
be supplied.
|
||||
|
||||
```yaml
|
||||
|
|
@ -81,11 +80,11 @@ proxy:
|
|||
```
|
||||
|
||||
> **Warning**: If you specify a username and password, it's very important to
|
||||
> understand that private resources that this user has access to Docker Hub will
|
||||
> be made available on your mirror. **You must secure your mirror** by
|
||||
> understand that private resources that this user has access to Docker Hub is
|
||||
> made available on your mirror. **You must secure your mirror** by
|
||||
> implementing authentication if you expect these resources to stay private!
|
||||
|
||||
> **Warning**: In order for the scheduler to clean up old entries, `delete` must
|
||||
> **Warning**: For the scheduler to clean up old entries, `delete` must
|
||||
> be enabled in the registry configuration. See
|
||||
> [Registry Configuration](/registry/configuration.md) for more details.
|
||||
|
||||
|
|
@ -114,7 +113,7 @@ Save the file and reload Docker for the change to take effect.
|
|||
> ```
|
||||
>
|
||||
> It's telling you that the file doesn't exist yet in the local cache and is
|
||||
> being pulled from upstream.
|
||||
> being pulled from upstream.
|
||||
|
||||
|
||||
## Use case: the China registry mirror
|
||||
|
|
@ -130,7 +129,7 @@ $ docker pull registry.docker-cn.com/library/ubuntu
|
|||
|
||||
You can add `"https://registry.docker-cn.com"` to the `registry-mirrors` array
|
||||
in [`/etc/docker/daemon.json`](/engine/reference/commandline/dockerd.md#daemon-configuration-file)
|
||||
to pull from the China registry mirror by default.
|
||||
to pull from the China registry mirror by default.
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
|||
|
|
@ -38,9 +38,9 @@ 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
|
||||
makes it more complex to deploy, maintain, and debug. Make sure the extra
|
||||
complexity is required.
|
||||
|
||||
For instance, Amazon's Elastic Load Balancer (ELB) in HTTPS mode already sets
|
||||
the following client header:
|
||||
|
|
@ -61,7 +61,7 @@ proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
|||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
```
|
||||
|
||||
Otherwise Nginx will reset the ELB's values, and the requests will not be routed
|
||||
Otherwise Nginx resets the ELB's values, and the requests are not routed
|
||||
properly. For more information, see
|
||||
[#970](https://github.com/docker/distribution/issues/970).
|
||||
|
||||
|
|
@ -75,7 +75,7 @@ Review the [requirements](/registry/recipes/index.md#requirements), then follow
|
|||
mkdir -p auth data
|
||||
```
|
||||
|
||||
2. Create the main nginx configuration you will use. Paste this code block into a new file called `auth/nginx.conf`:
|
||||
2. Create the main nginx configuration. Paste this code block into a new file called `auth/nginx.conf`:
|
||||
|
||||
```conf
|
||||
events {
|
||||
|
|
@ -91,7 +91,7 @@ Review the [requirements](/registry/recipes/index.md#requirements), then follow
|
|||
## Set a variable to help us decide if we need to add the
|
||||
## 'Docker-Distribution-Api-Version' header.
|
||||
## The registry always sets this header.
|
||||
## In the case of nginx performing auth, the header will be unset
|
||||
## In the case of nginx performing auth, the header is unset
|
||||
## since nginx is auth-ing before proxying.
|
||||
map $upstream_http_docker_distribution_api_version $docker_distribution_api_version {
|
||||
'' 'registry/2.0';
|
||||
|
|
@ -128,7 +128,7 @@ Review the [requirements](/registry/recipes/index.md#requirements), then follow
|
|||
auth_basic "Registry realm";
|
||||
auth_basic_user_file /etc/nginx/conf.d/nginx.htpasswd;
|
||||
|
||||
## If $docker_distribution_api_version is empty, the header will not be added.
|
||||
## If $docker_distribution_api_version is empty, the header is not added.
|
||||
## See the map directive above where this variable is defined.
|
||||
add_header 'Docker-Distribution-Api-Version' $docker_distribution_api_version always;
|
||||
|
||||
|
|
@ -148,7 +148,7 @@ Review the [requirements](/registry/recipes/index.md#requirements), then follow
|
|||
```bash
|
||||
$ docker run --rm --entrypoint htpasswd registry:2 -Bbn testuser testpassword > auth/nginx.htpasswd
|
||||
```
|
||||
|
||||
|
||||
> **Note**: If you do not want to use `bcrypt`, you can omit the `-B` parameter.
|
||||
|
||||
4. Copy your certificate files to the `auth/` directory.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue