forked from TrueCloudLab/distribution
Content rendering fixes
This commit is contained in:
parent
b3b099f079
commit
856dacadfc
5 changed files with 17 additions and 22 deletions
|
@ -341,7 +341,7 @@ Refer to `loglevel` to configure the level of messages printed.
|
|||
|
||||
## loglevel
|
||||
|
||||
> **DEPRECATED:** Please use [log](#log) instead.
|
||||
> **DEPRECATED:** Please use [log](configuration.md#log) instead.
|
||||
|
||||
loglevel: debug
|
||||
|
||||
|
@ -1251,7 +1251,7 @@ Declare parameters for constructing the redis connections. Registry instances
|
|||
may use the Redis instance for several applications. The current purpose is
|
||||
caching information about immutable blobs. Most of the options below control
|
||||
how the registry connects to redis. You can control the pool's behavior
|
||||
with the [pool](#pool) subsection.
|
||||
with the [pool](configuration.md#pool) subsection.
|
||||
|
||||
It's advisable to configure Redis itself with the **allkeys-lru** eviction policy
|
||||
as the registry does not set an expire value on keys.
|
||||
|
|
|
@ -154,7 +154,7 @@ Except for registries running on secure local networks, registries should always
|
|||
|
||||
The simplest way to achieve access restriction is through basic authentication (this is very similar to other web servers' basic authentication mechanism).
|
||||
|
||||
> **Warning**: You **cannot** use authentication with an insecure registry. You have to [configure TLS first](#running-a-domain-registry) for this to work.
|
||||
> **Warning**: You **cannot** use authentication with an insecure registry. You have to [configure TLS first](deploying.md#running-a-domain-registry) for this to work.
|
||||
|
||||
First create a password file with one entry for the user "testuser", with password "testpassword":
|
||||
|
||||
|
|
|
@ -11,7 +11,7 @@ This page contains definitions for distribution related terms.
|
|||
<dd>
|
||||
<blockquote>A blob is any kind of content that is stored by a Registry under a content-addressable identifier (a "digest").</blockquote>
|
||||
<p>
|
||||
<a href="#layer">Layers</a> are a good example of "blobs".
|
||||
<a href="glossary.md#layer">Layers</a> are a good example of "blobs".
|
||||
</p>
|
||||
</dd>
|
||||
|
||||
|
@ -19,9 +19,9 @@ This page contains definitions for distribution related terms.
|
|||
<dd>
|
||||
<blockquote>An image is a named set of immutable data from which a Docker container can be created.</blockquote>
|
||||
<p>
|
||||
An image is represented by a json file called a <a href="#manifest">manifest</a>, and is conceptually a set of <a hred="#layer">layers</a>.
|
||||
An image is represented by a json file called a <a href="glossary.md#manifest">manifest</a>, and is conceptually a set of <a hred="glossary.md#layer">layers</a>.
|
||||
|
||||
Image names indicate the location where they can be pulled from and pushed to, as they usually start with a <a href="#registry">registry</a> domain name and port.
|
||||
Image names indicate the location where they can be pulled from and pushed to, as they usually start with a <a href="glossary.md#registry">registry</a> domain name and port.
|
||||
|
||||
</p>
|
||||
</dd>
|
||||
|
@ -30,7 +30,7 @@ This page contains definitions for distribution related terms.
|
|||
<dd>
|
||||
<blockquote>A layer is a tar archive bundling partial content from a filesystem.</blockquote>
|
||||
<p>
|
||||
Layers from an <a href="#image">image</a> are usually extracted in order on top of each other to make up a root filesystem from which containers run out.
|
||||
Layers from an <a href="glossary.md#image">image</a> are usually extracted in order on top of each other to make up a root filesystem from which containers run out.
|
||||
</p>
|
||||
</dd>
|
||||
|
||||
|
@ -45,7 +45,7 @@ This page contains definitions for distribution related terms.
|
|||
</dd>
|
||||
|
||||
<dt id="registry"><h4>Registry</h4></dt>
|
||||
<dd><blockquote>A registry is a service that let you store and deliver <a href="#images">images</a>.</blockquote>
|
||||
<dd><blockquote>A registry is a service that let you store and deliver <a href="glossary.md#images">images</a>.</blockquote>
|
||||
</dd>
|
||||
|
||||
<dt id="registry"><h4>Repository</h4></dt>
|
||||
|
@ -57,7 +57,7 @@ This page contains definitions for distribution related terms.
|
|||
<dd><blockquote>A scope is the portion of a namespace onto which a given authorization token is granted.</blockquote></dd>
|
||||
|
||||
<dt id="tag"><h4>Tag</h4></dt>
|
||||
<dd><blockquote>A tag is conceptually a "version" of a <a href="#image">named image</a>.</blockquote>
|
||||
<dd><blockquote>A tag is conceptually a "version" of a <a href="glossary.md#image">named image</a>.</blockquote>
|
||||
<p>
|
||||
Example: `docker pull myimage:latest` instructs docker to pull the image "myimage" in version "latest".
|
||||
</p>
|
||||
|
|
|
@ -15,7 +15,7 @@ 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
|
||||
events. The events are queued into a registry-internal broadcast system which
|
||||
queues and dispatches events to [_Endpoints_](#endpoints).
|
||||
queues and dispatches events to [_Endpoints_](notifications.md#endpoints).
|
||||
|
||||
![](images/notifications.png)
|
||||
|
||||
|
|
|
@ -258,7 +258,7 @@ All endpoints should support aggressive http caching, compression and range
|
|||
headers, where appropriate. The new API attempts to leverage HTTP semantics
|
||||
where possible but may break from standards to implement targeted features.
|
||||
|
||||
For detail on individual endpoints, please see the [_Detail_](#detail)
|
||||
For detail on individual endpoints, please see the [_Detail_](api.md#detail)
|
||||
section.
|
||||
|
||||
### Errors
|
||||
|
@ -288,7 +288,7 @@ error codes as `UNKNOWN`, allowing future error codes to be added without
|
|||
breaking API compatibility. For the purposes of the specification error codes
|
||||
will only be added and never removed.
|
||||
|
||||
For a complete account of all error codes, please see the [_Errors_](#errors-2)
|
||||
For a complete account of all error codes, please see the [_Errors_](api.md#errors-2)
|
||||
section.
|
||||
|
||||
### API Version Check
|
||||
|
@ -622,7 +622,7 @@ Content-Type: application/octet-stream
|
|||
```
|
||||
|
||||
The "digest" parameter must be included with the PUT request. Please see the
|
||||
[_Completed Upload_](#completed-upload) section for details on the parameters
|
||||
[_Completed Upload_](api.md#completed-upload) section for details on the parameters
|
||||
and expected responses.
|
||||
|
||||
##### Chunked Upload
|
||||
|
@ -848,7 +848,7 @@ in [manifest-v2-1.md](manifest-v2-1.md) and [manifest-v2-2.md](manifest-v2-2.md)
|
|||
|
||||
If there is a problem with pushing the manifest, a relevant 4xx response will
|
||||
be returned with a JSON error message. Please see the
|
||||
[_PUT Manifest_](#put-manifest) section for details on possible error codes that
|
||||
[_PUT Manifest_](api.md#put-manifest) section for details on possible error codes that
|
||||
may be returned.
|
||||
|
||||
If one or more layers are unknown to the registry, `BLOB_UNKNOWN` errors are
|
||||
|
@ -912,7 +912,7 @@ explicitly requested. In this case the `Link` header will be returned along
|
|||
with the results, and subsequent results can be obtained by following the link
|
||||
as if pagination had been initially requested.
|
||||
|
||||
For details of the `Link` header, please see the [_Pagination_](#pagination)
|
||||
For details of the `Link` header, please see the [_Pagination_](api.md#pagination)
|
||||
section.
|
||||
|
||||
#### Pagination
|
||||
|
@ -5482,8 +5482,3 @@ The following headers will be returned with the response:
|
|||
|----|-----------|
|
||||
|`Content-Length`|Length of the JSON response body.|
|
||||
|`Link`|RFC5988 compliant rel='next' with URL to next result set, if available|
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
Loading…
Reference in a new issue