From 677eaaa3cc21da3a3d1054217f6e99acc109f2ce Mon Sep 17 00:00:00 2001 From: Misty Stanley-Jones Date: Mon, 10 Oct 2016 16:19:47 -0700 Subject: [PATCH 01/11] Change 'draft: true' to 'published: false' for Jekyll --- docs/architecture.md | 2 +- docs/glossary.md | 2 +- docs/migration.md | 2 +- docs/spec/implementations.md | 2 +- docs/spec/json.md | 2 +- 5 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/architecture.md b/docs/architecture.md index 91b704f8..c2aaa9f2 100644 --- a/docs/architecture.md +++ b/docs/architecture.md @@ -1,5 +1,5 @@ --- -draft: true +published: false --- # Architecture diff --git a/docs/glossary.md b/docs/glossary.md index 61c8d1dc..2eb1626a 100644 --- a/docs/glossary.md +++ b/docs/glossary.md @@ -1,5 +1,5 @@ --- -draft: true +published: false --- # Glossary diff --git a/docs/migration.md b/docs/migration.md index 167c5a68..e46441cb 100644 --- a/docs/migration.md +++ b/docs/migration.md @@ -1,5 +1,5 @@ --- -draft: true +published: false --- # Migrating a 1.0 registry to 2.0 diff --git a/docs/spec/implementations.md b/docs/spec/implementations.md index a365db6c..34746535 100644 --- a/docs/spec/implementations.md +++ b/docs/spec/implementations.md @@ -1,5 +1,5 @@ --- -draft: true +published: false --- # Distribution API Implementations diff --git a/docs/spec/json.md b/docs/spec/json.md index 8e149a34..e5d0d304 100644 --- a/docs/spec/json.md +++ b/docs/spec/json.md @@ -1,6 +1,6 @@ --- description: Explains registry JSON objects -draft: true +published: false keywords: - registry, service, images, repository, json menu: From 50bd0cce0748ca0503617fa1f9ec82f67ef8db85 Mon Sep 17 00:00:00 2001 From: John Mulhausen Date: Tue, 11 Oct 2016 12:00:08 -0700 Subject: [PATCH 02/11] Delete api.md.tmpl Deleting per comments in https://github.com/docker/distribution/pull/1985 --- docs/spec/api.md.tmpl | 1219 ----------------------------------------- 1 file changed, 1219 deletions(-) delete mode 100644 docs/spec/api.md.tmpl diff --git a/docs/spec/api.md.tmpl b/docs/spec/api.md.tmpl deleted file mode 100644 index c44418f4..00000000 --- a/docs/spec/api.md.tmpl +++ /dev/null @@ -1,1219 +0,0 @@ ---- -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 ---- - -# Docker Registry HTTP API V2 - -## Introduction - -The _Docker Registry HTTP API_ is the protocol to facilitate distribution of -images to the docker engine. It interacts with instances of the docker -registry, which is a service to manage information about docker images and -enable their distribution. The specification covers the operation of version 2 -of this API, known as _Docker Registry HTTP API V2_. - -While the V1 registry protocol is usable, there are several problems with the -architecture that have led to this new version. The main driver of this -specification is a set of changes to the docker the image format, covered in -[docker/docker#8093](https://github.com/docker/docker/issues/8093). -The new, self-contained image manifest simplifies image definition and improves -security. This specification will build on that work, leveraging new properties -of the manifest format to improve performance, reduce bandwidth usage and -decrease the likelihood of backend corruption. - -For relevant details and history leading up to this specification, please see -the following issues: - -- [docker/docker#8093](https://github.com/docker/docker/issues/8093) -- [docker/docker#9015](https://github.com/docker/docker/issues/9015) -- [docker/docker-registry#612](https://github.com/docker/docker-registry/issues/612) - -### Scope - -This specification covers the URL layout and protocols of the interaction -between docker registry and docker core. This will affect the docker core -registry API and the rewrite of docker-registry. Docker registry -implementations may implement other API endpoints, but they are not covered by -this specification. - -This includes the following features: - -- Namespace-oriented URI Layout -- PUSH/PULL registry server for V2 image manifest format -- Resumable layer PUSH support -- V2 Client library implementation - -While authentication and authorization support will influence this -specification, details of the protocol will be left to a future specification. -Relevant header definitions and error codes are present to provide an -indication of what a client may encounter. - -#### Future - -There are features that have been discussed during the process of cutting this -specification. The following is an incomplete list: - -- Immutable image references -- Multiple architecture support -- Migration from v2compatibility representation - -These may represent features that are either out of the scope of this -specification, the purview of another specification or have been deferred to a -future version. - -### Use Cases - -For the most part, the use cases of the former registry API apply to the new -version. Differentiating use cases are covered below. - -#### Image Verification - -A docker engine instance would like to run verified image named -"library/ubuntu", with the tag "latest". The engine contacts the registry, -requesting the manifest for "library/ubuntu:latest". An untrusted registry -returns a manifest. Before proceeding to download the individual layers, the -engine verifies the manifest's signature, ensuring that the content was -produced from a trusted source and no tampering has occurred. After each layer -is downloaded, the engine verifies the digest of the layer, ensuring that the -content matches that specified by the manifest. - -#### Resumable Push - -Company X's build servers lose connectivity to docker registry before -completing an image layer transfer. After connectivity returns, the build -server attempts to re-upload the image. The registry notifies the build server -that the upload has already been partially attempted. The build server -responds by only sending the remaining data to complete the image file. - -#### Resumable Pull - -Company X is having more connectivity problems but this time in their -deployment datacenter. When downloading an image, the connection is -interrupted before completion. The client keeps the partial data and uses http -`Range` requests to avoid downloading repeated data. - -#### Layer Upload De-duplication - -Company Y's build system creates two identical docker layers from build -processes A and B. Build process A completes uploading the layer before B. -When process B attempts to upload the layer, the registry indicates that its -not necessary because the layer is already known. - -If process A and B upload the same layer at the same time, both operations -will proceed and the first to complete will be stored in the registry (Note: -we may modify this to prevent dogpile with some locking mechanism). - -### Changes - -The V2 specification has been written to work as a living document, specifying -only what is certain and leaving what is not specified open or to future -changes. Only non-conflicting additions should be made to the API and accepted -changes should avoid preventing future changes from happening. - -This section should be updated when changes are made to the specification, -indicating what is different. Optionally, we may start marking parts of the -specification to correspond with the versions enumerated here. - -Each set of changes is given a letter corresponding to a set of modifications -that were applied to the baseline specification. These are merely for -reference and shouldn't be used outside the specification other than to -identify a set of modifications. - -
-
l
-
-
    -
  • Document TOOMANYREQUESTS error code.
    • -
-
- -
k
-
-
    -
  • Document use of Accept and Content-Type headers in manifests endpoint.
    • -
-
- -
j
-
-
    -
  • Add ability to mount blobs across repositories.
    • -
-
- -
i
-
-
    -
  • Clarified expected behavior response to manifest HEAD request.
    • -
-
- -
h
-
-
    -
  • All mention of tarsum removed.
    • -
-
- -
g
-
-
    -
  • Clarify behavior of pagination behavior with unspecified parameters.
    • -
-
- -
f
-
-
    -
  • Specify the delete API for layers and manifests.
    • -
-
- -
e
-
-
    -
  • Added support for listing registry contents.
    • -
  • Added pagination to tags API.
    • -
  • Added common approach to support pagination.
    • -
-
- -
d
-
-
    -
  • Allow repository name components to be one character.
    • -
  • Clarified that single component names are allowed.
    • -
-
- -
c
-
-
    -
  • Added section covering digest format.
    • -
  • Added more clarification that manifest cannot be deleted by tag.
    • -
-
- -
b
-
-
    -
  • Added capability of doing streaming upload to PATCH blob upload.
    • -
  • Updated PUT blob upload to no longer take final chunk, now requires entire data or no data.
    • -
  • Removed `416 Requested Range Not Satisfiable` response status from PUT blob upload.
    • -
-
- -
a
-
-
    -
  • Added support for immutable manifest references in manifest endpoints.
    • -
  • Deleting a manifest by tag has been deprecated.
    • -
  • Specified `Docker-Content-Digest` header for appropriate entities.
    • -
  • Added error code for unsupported operations.
    • -
-
-
- -## Overview - -This section covers client flows and details of the API endpoints. The URI -layout of the new API is structured to support a rich authentication and -authorization model by leveraging namespaces. All endpoints will be prefixed -by the API version and the repository name: - - /v2// - -For example, an API endpoint that will work with the `library/ubuntu` -repository, the URI prefix will be: - - /v2/library/ubuntu/ - -This scheme provides rich access control over various operations and methods -using the URI prefix and http methods that can be controlled in variety of -ways. - -Classically, repository names have always been two path components where each -path component is less than 30 characters. The V2 registry API does not -enforce this. The rules for a repository name are as follows: - -1. A repository name is broken up into _path components_. A component of a - repository name must be at least one lowercase, alpha-numeric characters, - optionally separated by periods, dashes or underscores. More strictly, it - must match the regular expression `[a-z0-9]+(?:[._-][a-z0-9]+)*`. -2. If a repository name has two or more path components, they must be - separated by a forward slash ("/"). -3. The total length of a repository name, including slashes, must be less the - 256 characters. - -These name requirements _only_ apply to the registry API and should accept a -superset of what is supported by other docker ecosystem components. - -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) -section. - -### Errors - -Actionable failure conditions, covered in detail in their relevant sections, -are reported as part of 4xx responses, in a json response body. One or more -errors will be returned in the following format: - - { - "errors:" [{ - "code": , - "message": , - "detail": - }, - ... - ] - } - -The `code` field will be a unique identifier, all caps with underscores by -convention. The `message` field will be a human readable string. The optional -`detail` field may contain arbitrary json data providing information the -client can use to resolve the issue. - -While the client can take action on certain error codes, the registry may add -new error codes over time. All client implementations should treat unknown -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) -section. - -### API Version Check - -A minimal endpoint, mounted at `/v2/` will provide version support information -based on its response statuses. The request format is as follows: - - GET /v2/ - -If a `200 OK` response is returned, the registry implements the V2(.1) -registry API and the client may proceed safely with other V2 operations. -Optionally, the response may contain information about the supported paths in -the response body. The client should be prepared to ignore this data. - -If a `401 Unauthorized` response is returned, the client should take action -based on the contents of the "WWW-Authenticate" header and try the endpoint -again. Depending on access control setup, the client may still have to -authenticate against different resources, even if this check succeeds. - -If `404 Not Found` response status, or other unexpected status, is returned, -the client should proceed with the assumption that the registry does not -implement V2 of the API. - -When a `200 OK` or `401 Unauthorized` response is returned, the -"Docker-Distribution-API-Version" header should be set to "registry/2.0". -Clients may require this header value to determine if the endpoint serves this -API. When this header is omitted, clients may fallback to an older API version. - -### Content Digests - -This API design is driven heavily by [content addressability](http://en.wikipedia.org/wiki/Content-addressable_storage). -The core of this design is the concept of a content addressable identifier. It -uniquely identifies content by taking a collision-resistant hash of the bytes. -Such an identifier can be independently calculated and verified by selection -of a common _algorithm_. If such an identifier can be communicated in a secure -manner, one can retrieve the content from an insecure source, calculate it -independently and be certain that the correct content was obtained. Put simply, -the identifier is a property of the content. - -To disambiguate from other concepts, we call this identifier a _digest_. A -_digest_ is a serialized hash result, consisting of a _algorithm_ and _hex_ -portion. The _algorithm_ identifies the methodology used to calculate the -digest. The _hex_ portion is the hex-encoded result of the hash. - -We define a _digest_ string to match the following grammar: -``` -digest := algorithm ":" hex -algorithm := /[A-Fa-f0-9_+.-]+/ -hex := /[A-Fa-f0-9]+/ -``` - -Some examples of _digests_ include the following: - -digest | description | -----------------------------------------------------------------------------------|------------------------------------------------ -sha256:6c3c624b58dbbcd3c0dd82b4c53f04194d1247c6eebdaab7c610cf7d66709b3b | Common sha256 based digest | - -While the _algorithm_ does allow one to implement a wide variety of -algorithms, compliant implementations should use sha256. Heavy processing of -input before calculating a hash is discouraged to avoid degrading the -uniqueness of the _digest_ but some canonicalization may be performed to -ensure consistent identifiers. - -Let's use a simple example in pseudo-code to demonstrate a digest calculation: -``` -let C = 'a small string' -let B = sha256(C) -let D = 'sha256:' + EncodeHex(B) -let ID(C) = D -``` - -Above, we have bytestring `C` passed into a function, `SHA256`, that returns a -bytestring `B`, which is the hash of `C`. `D` gets the algorithm concatenated -with the hex encoding of `B`. We then define the identifier of `C` to `ID(C)` -as equal to `D`. A digest can be verified by independently calculating `D` and -comparing it with identifier `ID(C)`. - -#### Digest Header - -To provide verification of http content, any response may include a -`Docker-Content-Digest` header. This will include the digest of the target -entity returned in the response. For blobs, this is the entire blob content. For -manifests, this is the manifest body without the signature content, also known -as the JWS payload. Note that the commonly used canonicalization for digest -calculation may be dependent on the mediatype of the content, such as with -manifests. - -The client may choose to ignore the header or may verify it to ensure content -integrity and transport security. This is most important when fetching by a -digest. To ensure security, the content should be verified against the digest -used to fetch the content. At times, the returned digest may differ from that -used to initiate a request. Such digests are considered to be from different -_domains_, meaning they have different values for _algorithm_. In such a case, -the client may choose to verify the digests in both domains or ignore the -server's digest. To maintain security, the client _must_ always verify the -content against the _digest_ used to fetch the content. - -> __IMPORTANT:__ If a _digest_ is used to fetch content, the client should use -> the same digest used to fetch the content to verify it. The header -> `Docker-Content-Digest` should not be trusted over the "local" digest. - -### Pulling An Image - -An "image" is a combination of a JSON manifest and individual layer files. The -process of pulling an image centers around retrieving these two components. - -The first step in pulling an image is to retrieve the manifest. For reference, -the relevant manifest fields for the registry are the following: - - field | description | -----------|------------------------------------------------| -name | The name of the image. | -tag | The tag for this version of the image. | -fsLayers | A list of layer descriptors (including digest) | -signature | A JWS used to verify the manifest content | - -For more information about the manifest format, please see -[docker/docker#8093](https://github.com/docker/docker/issues/8093). - -When the manifest is in hand, the client must verify the signature to ensure -the names and layers are valid. Once confirmed, the client will then use the -digests to download the individual layers. Layers are stored in as blobs in -the V2 registry API, keyed by their digest. - -#### Pulling an Image Manifest - -The image manifest can be fetched with the following url: - -``` -GET /v2//manifests/ -``` - -The `name` and `reference` parameter identify the image and are required. The -reference may include a tag or digest. - -The client should include an Accept header indicating which manifest content -types it supports. For more details on the manifest formats and their content -types, see [manifest-v2-1.md](manifest-v2-1.md) and -[manifest-v2-2.md](manifest-v2-2.md). In a successful response, the Content-Type -header will indicate which manifest type is being returned. - -A `404 Not Found` response will be returned if the image is unknown to the -registry. If the image exists and the response is successful, the image -manifest will be returned, with the following format (see -[docker/docker#8093](https://github.com/docker/docker/issues/8093) for details): - - { - "name": , - "tag": , - "fsLayers": [ - { - "blobSum": - }, - ... - ] - ], - "history": , - "signature": - } - -The client should verify the returned manifest signature for authenticity -before fetching layers. - -##### Existing Manifests - -The image manifest can be checked for existence with the following url: - -``` -HEAD /v2//manifests/ -``` - -The `name` and `reference` parameter identify the image and are required. The -reference may include a tag or digest. - -A `404 Not Found` response will be returned if the image is unknown to the -registry. If the image exists and the response is successful the response will -be as follows: - -``` -200 OK -Content-Length: -Docker-Content-Digest: -``` - - -#### Pulling a Layer - -Layers are stored in the blob portion of the registry, keyed by digest. -Pulling a layer is carried out by a standard http request. The URL is as -follows: - - GET /v2//blobs/ - -Access to a layer will be gated by the `name` of the repository but is -identified uniquely in the registry by `digest`. - -This endpoint may issue a 307 (302 for /blobs/uploads/ -``` - -The parameters of this request are the image namespace under which the layer -will be linked. Responses to this request are covered below. - -##### Existing Layers - -The existence of a layer can be checked via a `HEAD` request to the blob store -API. The request should be formatted as follows: - -``` -HEAD /v2//blobs/ -``` - -If the layer with the digest specified in `digest` is available, a 200 OK -response will be received, with no actual body content (this is according to -http specification). The response will look as follows: - -``` -200 OK -Content-Length: -Docker-Content-Digest: -``` - -When this response is received, the client can assume that the layer is -already available in the registry under the given name and should take no -further action to upload the layer. Note that the binary digests may differ -for the existing registry layer, but the digests will be guaranteed to match. - -##### Uploading the Layer - -If the POST request is successful, a `202 Accepted` response will be returned -with the upload URL in the `Location` header: - -``` -202 Accepted -Location: /v2//blobs/uploads/ -Range: bytes=0- -Content-Length: 0 -Docker-Upload-UUID: -``` - -The rest of the upload process can be carried out with the returned url, -called the "Upload URL" from the `Location` header. All responses to the -upload url, whether sending data or getting status, will be in this format. -Though the URI format (`/v2//blobs/uploads/`) for the `Location` -header is specified, clients should treat it as an opaque url and should never -try to assemble it. While the `uuid` parameter may be an actual UUID, this -proposal imposes no constraints on the format and clients should never impose -any. - -If clients need to correlate local upload state with remote upload state, the -contents of the `Docker-Upload-UUID` header should be used. Such an id can be -used to key the last used location header when implementing resumable uploads. - -##### Upload Progress - -The progress and chunk coordination of the upload process will be coordinated -through the `Range` header. While this is a non-standard use of the `Range` -header, there are examples of [similar approaches](https://developers.google.com/youtube/v3/guides/using_resumable_upload_protocol) in APIs with heavy use. -For an upload that just started, for an example with a 1000 byte layer file, -the `Range` header would be as follows: - -``` -Range: bytes=0-0 -``` - -To get the status of an upload, issue a GET request to the upload URL: - -``` -GET /v2//blobs/uploads/ -Host: -``` - -The response will be similar to the above, except will return 204 status: - -``` -204 No Content -Location: /v2//blobs/uploads/ -Range: bytes=0- -Docker-Upload-UUID: -``` - -Note that the HTTP `Range` header byte ranges are inclusive and that will be -honored, even in non-standard use cases. - -##### Monolithic Upload - -A monolithic upload is simply a chunked upload with a single chunk and may be -favored by clients that would like to avoided the complexity of chunking. To -carry out a "monolithic" upload, one can simply put the entire content blob to -the provided URL: - -``` -PUT /v2//blobs/uploads/?digest= -Content-Length: -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 -and expected responses. - -##### Chunked Upload - -To carry out an upload of a chunk, the client can specify a range header and -only include that part of the layer file: - -``` -PATCH /v2//blobs/uploads/ -Content-Length: -Content-Range: - -Content-Type: application/octet-stream - - -``` - -There is no enforcement on layer chunk splits other than that the server must -receive them in order. The server may enforce a minimum chunk size. If the -server cannot accept the chunk, a `416 Requested Range Not Satisfiable` -response will be returned and will include a `Range` header indicating the -current status: - -``` -416 Requested Range Not Satisfiable -Location: /v2//blobs/uploads/ -Range: 0- -Content-Length: 0 -Docker-Upload-UUID: -``` - -If this response is received, the client should resume from the "last valid -range" and upload the subsequent chunk. A 416 will be returned under the -following conditions: - -- Invalid Content-Range header format -- Out of order chunk: the range of the next chunk must start immediately after - the "last valid range" from the previous response. - -When a chunk is accepted as part of the upload, a `202 Accepted` response will -be returned, including a `Range` header with the current upload status: - -``` -202 Accepted -Location: /v2//blobs/uploads/ -Range: bytes=0- -Content-Length: 0 -Docker-Upload-UUID: -``` - -##### Completed Upload - -For an upload to be considered complete, the client must submit a `PUT` -request on the upload endpoint with a digest parameter. If it is not provided, -the upload will not be considered complete. The format for the final chunk -will be as follows: - -``` -PUT /v2//blob/uploads/?digest= -Content-Length: -Content-Range: - -Content-Type: application/octet-stream - - -``` - -Optionally, if all chunks have already been uploaded, a `PUT` request with a -`digest` parameter and zero-length body may be sent to complete and validated -the upload. Multiple "digest" parameters may be provided with different -digests. The server may verify none or all of them but _must_ notify the -client if the content is rejected. - -When the last chunk is received and the layer has been validated, the client -will receive a `201 Created` response: - -``` -201 Created -Location: /v2//blobs/ -Content-Length: 0 -Docker-Content-Digest: -``` - -The `Location` header will contain the registry URL to access the accepted -layer file. The `Docker-Content-Digest` header returns the canonical digest of -the uploaded blob which may differ from the provided digest. Most clients may -ignore the value but if it is used, the client should verify the value against -the uploaded blob data. - -###### Digest Parameter - -The "digest" parameter is designed as an opaque parameter to support -verification of a successful transfer. For example, an HTTP URI parameter -might be as follows: - -``` -sha256:6c3c624b58dbbcd3c0dd82b4c53f04194d1247c6eebdaab7c610cf7d66709b3b -``` - -Given this parameter, the registry will verify that the provided content does -match this digest. - -##### Canceling an Upload - -An upload can be cancelled by issuing a DELETE request to the upload endpoint. -The format will be as follows: - -``` -DELETE /v2//blobs/uploads/ -``` - -After this request is issued, the upload uuid will no longer be valid and the -registry server will dump all intermediate data. While uploads will time out -if not completed, clients should issue this request if they encounter a fatal -error but still have the ability to issue an http request. - -##### Cross Repository Blob Mount - -A blob may be mounted from another repository that the client has read access -to, removing the need to upload a blob already known to the registry. To issue -a blob mount instead of an upload, a POST request should be issued in the -following format: - -``` -POST /v2//blobs/uploads/?mount=&from= -Content-Length: 0 -``` - -If the blob is successfully mounted, the client will receive a `201 Created` -response: - -``` -201 Created -Location: /v2//blobs/ -Content-Length: 0 -Docker-Content-Digest: -``` - -The `Location` header will contain the registry URL to access the accepted -layer file. The `Docker-Content-Digest` header returns the canonical digest of -the uploaded blob which may differ from the provided digest. Most clients may -ignore the value but if it is used, the client should verify the value against -the uploaded blob data. - -If a mount fails due to invalid repository or digest arguments, the registry -will fall back to the standard upload behavior and return a `202 Accepted` with -the upload URL in the `Location` header: - -``` -202 Accepted -Location: /v2//blobs/uploads/ -Range: bytes=0- -Content-Length: 0 -Docker-Upload-UUID: -``` - -This behavior is consistent with older versions of the registry, which do not -recognize the repository mount query parameters. - -Note: a client may issue a HEAD request to check existence of a blob in a source -repository to distinguish between the registry not supporting blob mounts and -the blob not existing in the expected repository. - -##### Errors - -If an 502, 503 or 504 error is received, the client should assume that the -download can proceed due to a temporary condition, honoring the appropriate -retry mechanism. Other 5xx errors should be treated as terminal. - -If there is a problem with the upload, a 4xx error will be returned indicating -the problem. After receiving a 4xx response (except 416, as called out above), -the upload will be considered failed and the client should take appropriate -action. - -Note that the upload url will not be available forever. If the upload uuid is -unknown to the registry, a `404 Not Found` response will be returned and the -client must restart the upload process. - -### Deleting a Layer - -A layer may be deleted from the registry via its `name` and `digest`. A -delete may be issued with the following request format: - - DELETE /v2//blobs/ - -If the blob exists and has been successfully deleted, the following response -will be issued: - - 202 Accepted - Content-Length: None - -If the blob had already been deleted or did not exist, a `404 Not Found` -response will be issued instead. - -If a layer is deleted which is referenced by a manifest in the registry, -then the complete images will not be resolvable. - -#### Pushing an Image Manifest - -Once all of the layers for an image are uploaded, the client can upload the -image manifest. An image can be pushed using the following request format: - - PUT /v2//manifests/ - Content-Type: - - { - "name": , - "tag": , - "fsLayers": [ - { - "blobSum": - }, - ... - ] - ], - "history": , - "signature": , - ... - } - -The `name` and `reference` fields of the response body must match those -specified in the URL. The `reference` field may be a "tag" or a "digest". The -content type should match the type of the manifest being uploaded, as specified -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 -may be returned. - -If one or more layers are unknown to the registry, `BLOB_UNKNOWN` errors are -returned. The `detail` field of the error response will have a `digest` field -identifying the missing blob. An error is returned for each unknown blob. The -response format is as follows: - - { - "errors:" [{ - "code": "BLOB_UNKNOWN", - "message": "blob unknown to registry", - "detail": { - "digest": - } - }, - ... - ] - } - -### Listing Repositories - -Images are stored in collections, known as a _repository_, which is keyed by a -`name`, as seen throughout the API specification. A registry instance may -contain several repositories. The list of available repositories is made -available through the _catalog_. - -The catalog for a given registry can be retrieved with the following request: - -``` -GET /v2/_catalog -``` - -The response will be in the following format: - -``` -200 OK -Content-Type: application/json - -{ - "repositories": [ - , - ... - ] -} -``` - -Note that the contents of the response are specific to the registry -implementation. Some registries may opt to provide a full catalog output, -limit it based on the user's access level or omit upstream results, if -providing mirroring functionality. Subsequently, the presence of a repository -in the catalog listing only means that the registry *may* provide access to -the repository at the time of the request. Conversely, a missing entry does -*not* mean that the registry does not have the repository. More succinctly, -the presence of a repository only guarantees that it is there but not that it -is _not_ there. - -For registries with a large number of repositories, this response may be quite -large. If such a response is expected, one should use pagination. A registry -may also limit the amount of responses returned even if pagination was not -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) -section. - -#### Pagination - -Paginated catalog results can be retrieved by adding an `n` parameter to the -request URL, declaring that the response should be limited to `n` results. -Starting a paginated flow begins as follows: - -``` -GET /v2/_catalog?n= -``` - -The above specifies that a catalog response should be returned, from the start of -the result set, ordered lexically, limiting the number of results to `n`. The -response to such a request would look as follows: - -``` -200 OK -Content-Type: application/json -Link: <?n=&last=>; rel="next" - -{ - "repositories": [ - , - ... - ] -} -``` - -The above includes the _first_ `n` entries from the result set. To get the -_next_ `n` entries, one can create a URL where the argument `last` has the -value from `repositories[len(repositories)-1]`. If there are indeed more -results, the URL for the next block is encoded in an -[RFC5988](https://tools.ietf.org/html/rfc5988) `Link` header, as a "next" -relation. The presence of the `Link` header communicates to the client that -the entire result set has not been returned and another request must be -issued. If the header is not present, the client can assume that all results -have been received. - -> __NOTE:__ In the request template above, note that the brackets -> are required. For example, if the url is -> `http://example.com/v2/_catalog?n=20&last=b`, the value of the header would -> be `; rel="next"`. Please see -> [RFC5988](https://tools.ietf.org/html/rfc5988) for details. - -Compliant client implementations should always use the `Link` header -value when proceeding through results linearly. The client may construct URLs -to skip forward in the catalog. - -To get the next result set, a client would issue the request as follows, using -the URL encoded in the described `Link` header: - -``` -GET /v2/_catalog?n=&last= -``` - -The above process should then be repeated until the `Link` header is no longer -set. - -The catalog result set is represented abstractly as a lexically sorted list, -where the position in that list can be specified by the query term `last`. The -entries in the response start _after_ the term specified by `last`, up to `n` -entries. - -The behavior of `last` is quite simple when demonstrated with an example. Let -us say the registry has the following repositories: - -``` -a -b -c -d -``` - -If the value of `n` is 2, _a_ and _b_ will be returned on the first response. -The `Link` header returned on the response will have `n` set to 2 and last set -to _b_: - -``` -Link: <?n=2&last=b>; rel="next" -``` - -The client can then issue the request with the above value from the `Link` -header, receiving the values _c_ and _d_. Note that `n` may change on the second -to last response or be fully omitted, depending on the server implementation. - -### Listing Image Tags - -It may be necessary to list all of the tags under a given repository. The tags -for an image repository can be retrieved with the following request: - - GET /v2//tags/list - -The response will be in the following format: - - 200 OK - Content-Type: application/json - - { - "name": , - "tags": [ - , - ... - ] - } - -For repositories with a large number of tags, this response may be quite -large. If such a response is expected, one should use the pagination. - -#### Pagination - -Paginated tag results can be retrieved by adding the appropriate parameters to -the request URL described above. The behavior of tag pagination is identical -to that specified for catalog pagination. We cover a simple flow to highlight -any differences. - -Starting a paginated flow may begin as follows: - -``` -GET /v2//tags/list?n= -``` - -The above specifies that a tags response should be returned, from the start of -the result set, ordered lexically, limiting the number of results to `n`. The -response to such a request would look as follows: - -``` -200 OK -Content-Type: application/json -Link: <?n=&last=>; rel="next" - -{ - "name": , - "tags": [ - , - ... - ] -} -``` - -To get the next result set, a client would issue the request as follows, using -the value encoded in the [RFC5988](https://tools.ietf.org/html/rfc5988) `Link` -header: - -``` -GET /v2//tags/list?n=&last= -``` - -The above process should then be repeated until the `Link` header is no longer -set in the response. The behavior of the `last` parameter, the provided -response result, lexical ordering and encoding of the `Link` header are -identical to that of catalog pagination. - -### Deleting an Image - -An image may be deleted from the registry via its `name` and `reference`. A -delete may be issued with the following request format: - - DELETE /v2//manifests/ - -For deletes, `reference` *must* be a digest or the delete will fail. If the -image exists and has been successfully deleted, the following response will be -issued: - - 202 Accepted - Content-Length: None - -If the image had already been deleted or did not exist, a `404 Not Found` -response will be issued instead. - -> **Note** When deleting a manifest from a registry version 2.3 or later, the -> following header must be used when `HEAD` or `GET`-ing the manifest to obtain -> the correct digest to delete: - - Accept: application/vnd.docker.distribution.manifest.v2+json - -> for more details, see: [compatibility.md](../compatibility.md#content-addressable-storage-cas) - -## Detail - -> **Note**: This section is still under construction. For the purposes of -> implementation, if any details below differ from the described request flows -> above, the section below should be corrected. When they match, this note -> should be removed. - -The behavior of the endpoints are covered in detail in this section, organized -by route and entity. All aspects of the request and responses are covered, -including headers, parameters and body formats. Examples of requests and their -corresponding responses, with success and failure, are enumerated. - -> **Note**: The sections on endpoint detail are arranged with an example -> request, a description of the request, followed by information about that -> request. - -A list of methods and URIs are covered in the table below: - -|Method|Path|Entity|Description| -|------|----|------|-----------| -{{range $route := .RouteDescriptors}}{{range $method := .Methods}}| {{$method.Method}} | `{{$route.Path|prettygorilla}}` | {{$route.Entity}} | {{$method.Description}} | -{{end}}{{end}} - -The detail for each endpoint is covered in the following sections. - -### Errors - -The error codes encountered via the API are enumerated in the following table: - -|Code|Message|Description| -|----|-------|-----------| -{{range $err := .ErrorDescriptors}} `{{$err.Value}}` | {{$err.Message}} | {{$err.Description|removenewlines}} -{{end}} - -{{range $route := .RouteDescriptors}} -### {{.Entity}} - -{{.Description}} - -{{range $method := $route.Methods}} - -#### {{.Method}} {{$route.Entity}} - -{{.Description}} - -{{if .Requests}}{{range .Requests}}{{if .Name}} -##### {{.Name}}{{end}} - -``` -{{$method.Method}} {{$route.Path|prettygorilla}}{{range $i, $param := .QueryParameters}}{{if eq $i 0}}?{{else}}&{{end}}{{$param.Name}}={{$param.Format}}{{end}}{{range .Headers}} -{{.Name}}: {{.Format}}{{end}}{{if .Body.ContentType}} -Content-Type: {{.Body.ContentType}}{{end}}{{if .Body.Format}} - -{{.Body.Format}}{{end}} -``` - -{{.Description}} - -{{if or .Headers .PathParameters .QueryParameters}} -The following parameters should be specified on the request: - -|Name|Kind|Description| -|----|----|-----------| -{{range .Headers}}|`{{.Name}}`|header|{{.Description}}| -{{end}}{{range .PathParameters}}|`{{.Name}}`|path|{{.Description}}| -{{end}}{{range .QueryParameters}}|`{{.Name}}`|query|{{.Description}}| -{{end}}{{end}} - -{{if .Successes}} -{{range .Successes}} -###### On Success: {{if .Name}}{{.Name}}{{else}}{{.StatusCode | statustext}}{{end}} - -``` -{{.StatusCode}} {{.StatusCode | statustext}}{{range .Headers}} -{{.Name}}: {{.Format}}{{end}}{{if .Body.ContentType}} -Content-Type: {{.Body.ContentType}}{{end}}{{if .Body.Format}} - -{{.Body.Format}}{{end}} -``` - -{{.Description}} -{{if .Fields}}The following fields may be returned in the response body: - -|Name|Description| -|----|-----------| -{{range .Fields}}|`{{.Name}}`|{{.Description}}| -{{end}}{{end}}{{if .Headers}} -The following headers will be returned with the response: - -|Name|Description| -|----|-----------| -{{range .Headers}}|`{{.Name}}`|{{.Description}}| -{{end}}{{end}}{{end}}{{end}} - -{{if .Failures}} -{{range .Failures}} -###### On Failure: {{if .Name}}{{.Name}}{{else}}{{.StatusCode | statustext}}{{end}} - -``` -{{.StatusCode}} {{.StatusCode | statustext}}{{range .Headers}} -{{.Name}}: {{.Format}}{{end}}{{if .Body.ContentType}} -Content-Type: {{.Body.ContentType}}{{end}}{{if .Body.Format}} - -{{.Body.Format}}{{end}} -``` - -{{.Description}} -{{if .Headers}} -The following headers will be returned on the response: - -|Name|Description| -|----|-----------| -{{range .Headers}}|`{{.Name}}`|{{.Description}}| -{{end}}{{end}} - -{{if .ErrorCodes}} -The error codes that may be included in the response body are enumerated below: - -|Code|Message|Description| -|----|-------|-----------| -{{range $err := .ErrorCodes}}| `{{$err.Descriptor.Value}}` | {{$err.Descriptor.Message}} | {{$err.Descriptor.Description|removenewlines}} | -{{end}} - -{{end}}{{end}}{{end}}{{end}}{{end}}{{end}} - -{{end}} From b206e8b2a45938a42f4a6d74ea38f93908e94d92 Mon Sep 17 00:00:00 2001 From: Richard Scothern Date: Fri, 14 Oct 2016 14:24:14 -0700 Subject: [PATCH 03/11] Add note about configuring a registry cache with delete enabled Signed-off-by: Richard Scothern --- docs/recipes/mirror.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/docs/recipes/mirror.md b/docs/recipes/mirror.md index 75ea964f..a7f80a49 100644 --- a/docs/recipes/mirror.md +++ b/docs/recipes/mirror.md @@ -62,6 +62,8 @@ In order to access private images on the Docker Hub, a username and password can > :warn: if you specify a username and password, it's very important to understand that private resources that this user has access to on the Hub will be made available on your mirror. It's thus paramount that you secure your mirror by implementing authentication if you expect these resources to stay private! +> :warn: in order for the scheduler to clean up old entries, delete must be enabled in the registry configuration. See the [Registry Configuration Reference](configuration.md) for more details. + ### Configuring the Docker daemon You will need to pass the `--registry-mirror` option to your Docker daemon on startup: From 70c7657c69e38dce3fd73913e3df2cfd33f180d1 Mon Sep 17 00:00:00 2001 From: Misty Stanley-Jones Date: Mon, 17 Oct 2016 15:00:00 -0700 Subject: [PATCH 04/11] Update branding for macOS Apple has changed their branding guidelines from 'OS X' to 'macOS' so we should update ours to be within trademark / branding guidelines. See http://www.apple.com/macos/sierra/ Signed-off-by: Misty Stanley-Jones --- docs/recipes/index.md | 2 +- docs/recipes/menu.md | 2 +- docs/recipes/osx-setup-guide.md | 16 ++++++++-------- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/recipes/index.md b/docs/recipes/index.md index 49537079..482a4894 100644 --- a/docs/recipes/index.md +++ b/docs/recipes/index.md @@ -33,5 +33,5 @@ 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 OS X](osx-setup-guide.md) + * [running a Registry on macOS](osx-setup-guide.md) * [mirror the Docker Hub](mirror.md) diff --git a/docs/recipes/menu.md b/docs/recipes/menu.md index 1755009e..15398f75 100644 --- a/docs/recipes/menu.md +++ b/docs/recipes/menu.md @@ -17,5 +17,5 @@ type: menu * [using Apache as an authenticating proxy](apache.md) * [using Nginx as an authenticating proxy](nginx.md) - * [running a Registry on OS X](osx-setup-guide.md) + * [running a Registry on macOS](osx-setup-guide.md) * [mirror the Docker Hub](mirror.md) diff --git a/docs/recipes/osx-setup-guide.md b/docs/recipes/osx-setup-guide.md index 0d0c443d..f926f8c9 100644 --- a/docs/recipes/osx-setup-guide.md +++ b/docs/recipes/osx-setup-guide.md @@ -1,32 +1,32 @@ --- -description: Explains how to run a registry on OS X +description: Explains how to run a registry on macOS keywords: -- registry, on-prem, images, tags, repository, distribution, OS X, recipe, advanced +- registry, on-prem, images, tags, repository, distribution, macOS, recipe, advanced menu: main: parent: smn_recipes -title: Running on OS X +title: Running on macOS --- -# OS X Setup Guide +# macOS Setup Guide ## Use-case -This is useful if you intend to run a registry server natively on OS X. +This is useful if you intend to run a registry server natively on macOS. ### Alternatives -You can start a VM on OS X, and deploy your registry normally as a container using Docker inside that VM. +You can start a VM on macOS, and deploy your registry normally as a container using Docker inside that VM. The simplest road to get there is traditionally to use the [docker Toolbox](https://www.docker.com/toolbox), or [docker-machine](/machine/index.md), which usually relies on the [boot2docker](http://boot2docker.io/) iso inside a VirtualBox VM. ### Solution -Using the method described here, you install and compile your own from the git repository and run it as an OS X agent. +Using the method described here, you install and compile your own from the git repository and run it as an macOS agent. ### Gotchas -Production services operation on OS X is out of scope of this document. Be sure you understand well these aspects before considering going to production with this. +Production services operation on macOS is out of scope of this document. Be sure you understand well these aspects before considering going to production with this. ## Setup golang on your machine From bd9f8c7f6ef970c346244c6eec4cd72bdf6745ea Mon Sep 17 00:00:00 2001 From: John Mulhausen Date: Tue, 18 Oct 2016 14:58:14 -0700 Subject: [PATCH 05/11] Update mirror.md --- docs/recipes/mirror.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/recipes/mirror.md b/docs/recipes/mirror.md index a7f80a49..6e66f73a 100644 --- a/docs/recipes/mirror.md +++ b/docs/recipes/mirror.md @@ -62,7 +62,7 @@ In order to access private images on the Docker Hub, a username and password can > :warn: if you specify a username and password, it's very important to understand that private resources that this user has access to on the Hub will be made available on your mirror. It's thus paramount that you secure your mirror by implementing authentication if you expect these resources to stay private! -> :warn: in order for the scheduler to clean up old entries, delete must be enabled in the registry configuration. See the [Registry Configuration Reference](configuration.md) for more details. +> :warn: in order for the scheduler to clean up old entries, delete must be enabled in the registry configuration. See the [Registry Configuration Reference](../configuration.md) for more details. ### Configuring the Docker daemon From 8e8290bd814e6108a5e470d1348b1ed2cd844e5a Mon Sep 17 00:00:00 2001 From: John Mulhausen Date: Tue, 25 Oct 2016 12:15:25 -0700 Subject: [PATCH 06/11] Formatting fix --- docs/configuration.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/configuration.md b/docs/configuration.md index fa4d625a..da957c15 100644 --- a/docs/configuration.md +++ b/docs/configuration.md @@ -748,7 +748,8 @@ interpretation of the options. no - Specify a `duration` by providing an integer and a unit. Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, `h`. For example, `3000s` is a valid duration; there should be no space between the integer and unit. If you do not specify a `duration` or specify an integer without a time unit, this defaults to 20 minutes. + {% capture text %}Specify a `duration` by providing an integer and a unit. Valid time units are `ns`, `us` (or `µs`), `ms`, `s`, `m`, `h`. For example, `3000s` is a valid duration; there should be no space between the integer and unit. If you do not specify a `duration` or specify an integer without a time unit, this defaults to 20 minutes.{% endcapture %} + {{ text | markdownify }} From e63f5950da8738e3409d44863ef7d544ec1a4bdd Mon Sep 17 00:00:00 2001 From: John Mulhausen Date: Tue, 25 Oct 2016 12:18:22 -0700 Subject: [PATCH 07/11] Formatting fixes --- docs/configuration.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/configuration.md b/docs/configuration.md index da957c15..72c95972 100644 --- a/docs/configuration.md +++ b/docs/configuration.md @@ -1832,7 +1832,7 @@ conjunction with the S3 storage driver. The storage middleware name. Currently cloudfront is an accepted value. - disabled + disabled Set to false to easily disable the middleware. @@ -1861,7 +1861,6 @@ The following example illustrates these values: keypairid: asecret duration: 60 - >**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. From 81b038a875b2ff483fcd0201de20bc820a0bed89 Mon Sep 17 00:00:00 2001 From: Adrien Duermael Date: Mon, 31 Oct 2016 13:38:31 -0700 Subject: [PATCH 08/11] removed menu.md files Signed-off-by: Adrien Duermael --- docs/menu.md | 23 ----------------------- docs/recipes/menu.md | 21 --------------------- docs/spec/menu.md | 15 --------------- docs/storage-drivers/menu.md | 15 --------------- 4 files changed, 74 deletions(-) delete mode 100644 docs/menu.md delete mode 100644 docs/recipes/menu.md delete mode 100644 docs/spec/menu.md delete mode 100644 docs/storage-drivers/menu.md diff --git a/docs/menu.md b/docs/menu.md deleted file mode 100644 index def2cd5c..00000000 --- a/docs/menu.md +++ /dev/null @@ -1,23 +0,0 @@ ---- -description: High-level overview of the Registry -keywords: -- registry, on-prem, images, tags, repository, distribution -menu: - main: - identifier: smn_registry - parent: mn_components -title: Docker Registry -type: menu ---- - -# Overview of Docker Registry Documentation - -The Docker Registry documentation includes the following topics: - -* [Docker Registry Introduction](index.md) -* [Understanding the Registry](introduction.md) -* [Deploying a registry server](deploying.md) -* [Registry Configuration Reference](configuration.md) -* [Notifications](notifications.md) -* [Recipes](recipes/index.md) -* [Getting help](help.md) diff --git a/docs/recipes/menu.md b/docs/recipes/menu.md deleted file mode 100644 index 15398f75..00000000 --- a/docs/recipes/menu.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -description: Registry Recipes -keywords: -- registry, on-prem, images, tags, repository, distribution -menu: - main: - identifier: smn_recipes - parent: smn_registry - weight: 6 -title: Recipes -type: menu ---- - -# Recipes - -## The List - - * [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) diff --git a/docs/spec/menu.md b/docs/spec/menu.md deleted file mode 100644 index 0e39f6b7..00000000 --- a/docs/spec/menu.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -description: Explains registry JSON objects -keywords: -- registry, service, images, repository, json -menu: - main: - identifier: smn_registry_ref - parent: smn_registry - weight: 7 -title: Reference -type: menu ---- - - - diff --git a/docs/storage-drivers/menu.md b/docs/storage-drivers/menu.md deleted file mode 100644 index c58f57de..00000000 --- a/docs/storage-drivers/menu.md +++ /dev/null @@ -1,15 +0,0 @@ ---- -description: Storage Drivers -keywords: -- registry, on-prem, images, tags, repository, distribution -menu: - main: - identifier: smn_storagedrivers - parent: smn_registry - weight: 7 -title: Storage Drivers -type: menu ---- - - - From 2ecf05a74ecae70ae5cde9f0940b4d5655c9bb0d Mon Sep 17 00:00:00 2001 From: Adrien Duermael Date: Tue, 1 Nov 2016 17:00:55 -0700 Subject: [PATCH 09/11] absolute links to docs.docker.com are now relative links Signed-off-by: Adrien Duermael --- docs/index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/index.md b/docs/index.md index 3e7bde8e..0a57a2d3 100644 --- a/docs/index.md +++ b/docs/index.md @@ -30,7 +30,7 @@ You should use the Registry if you want to: 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](https://docs.docker.com/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 From 3d14741648eca978ea99528159e1390d911bd22c Mon Sep 17 00:00:00 2001 From: Gaetan Date: Fri, 4 Nov 2016 10:48:38 -0700 Subject: [PATCH 10/11] fix more frontmatter keywords values (#439) * fix format of frontmatter keyword entry in some .md files Signed-off-by: Gaetan de Villele --- docs/compatibility.md | 5 ++--- docs/deploying.md | 5 ++--- docs/deprecated.md | 5 ++--- docs/garbage-collection.md | 6 ++---- docs/help.md | 5 ++--- docs/index.md | 5 ++--- docs/insecure.md | 5 ++--- docs/introduction.md | 5 ++--- docs/notifications.md | 6 +++--- docs/recipes/apache.md | 7 +++---- docs/recipes/index.md | 5 ++--- docs/recipes/mirror.md | 7 +++---- docs/recipes/nginx.md | 7 +++---- docs/recipes/osx-setup-guide.md | 6 +++--- docs/storage-drivers/azure.md | 5 ++--- docs/storage-drivers/filesystem.md | 5 ++--- docs/storage-drivers/gcs.md | 5 ++--- docs/storage-drivers/index.md | 6 +++--- docs/storage-drivers/inmemory.md | 5 ++--- docs/storage-drivers/oss.md | 5 ++--- docs/storage-drivers/s3.md | 5 ++--- docs/storage-drivers/swift.md | 5 ++--- 22 files changed, 50 insertions(+), 70 deletions(-) diff --git a/docs/compatibility.md b/docs/compatibility.md index 6d18ffc3..71ee230d 100644 --- a/docs/compatibility.md +++ b/docs/compatibility.md @@ -1,7 +1,6 @@ --- description: describes get by digest pitfall -keywords: -- registry, manifest, images, tags, repository, distribution, digest +keywords: registry, manifest, images, tags, repository, distribution, digest menu: main: parent: smn_registry_ref @@ -81,4 +80,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. \ No newline at end of file diff --git a/docs/deploying.md b/docs/deploying.md index 1aa42aa0..de347055 100644 --- a/docs/deploying.md +++ b/docs/deploying.md @@ -1,7 +1,6 @@ --- description: Explains how to deploy a registry -keywords: -- registry, on-prem, images, tags, repository, distribution, deployment +keywords: registry, on-prem, images, tags, repository, distribution, deployment menu: main: parent: smn_registry @@ -234,4 +233,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) \ No newline at end of file diff --git a/docs/deprecated.md b/docs/deprecated.md index d30ff425..dd4f9762 100644 --- a/docs/deprecated.md +++ b/docs/deprecated.md @@ -1,7 +1,6 @@ --- description: describes deprecated functionality -keywords: -- registry, manifest, images, signatures, repository, distribution, digest +keywords: registry, manifest, images, signatures, repository, distribution, digest menu: main: parent: smn_registry_ref @@ -24,4 +23,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. \ No newline at end of file diff --git a/docs/garbage-collection.md b/docs/garbage-collection.md index d24bb77c..1352b527 100644 --- a/docs/garbage-collection.md +++ b/docs/garbage-collection.md @@ -1,7 +1,6 @@ --- description: High level discussion of garbage collection -keywords: -- registry, garbage, images, tags, repository, distribution +keywords: registry, garbage, images, tags, repository, distribution menu: main: parent: smn_registry_ref @@ -133,5 +132,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 -``` - +``` \ No newline at end of file diff --git a/docs/help.md b/docs/help.md index 8728924c..40615b27 100644 --- a/docs/help.md +++ b/docs/help.md @@ -1,7 +1,6 @@ --- description: Getting help with the Registry -keywords: -- registry, on-prem, images, tags, repository, distribution, help, 101, TL;DR +keywords: registry, on-prem, images, tags, repository, distribution, help, 101, TL;DR menu: main: parent: smn_registry @@ -21,4 +20,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). \ No newline at end of file diff --git a/docs/index.md b/docs/index.md index 0a57a2d3..269ab74f 100644 --- a/docs/index.md +++ b/docs/index.md @@ -2,8 +2,7 @@ aliases: - /registry/overview/ description: High-level overview of the Registry -keywords: -- registry, on-prem, images, tags, repository, distribution +keywords: registry, on-prem, images, tags, repository, distribution menu: main: parent: smn_registry @@ -65,4 +64,4 @@ 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). \ No newline at end of file diff --git a/docs/insecure.md b/docs/insecure.md index 0bb21458..01385ef6 100644 --- a/docs/insecure.md +++ b/docs/insecure.md @@ -1,7 +1,6 @@ --- description: Deploying a Registry in an insecure fashion -keywords: -- registry, on-prem, images, tags, repository, distribution, insecure +keywords: registry, on-prem, images, tags, repository, distribution, insecure menu: main: parent: smn_registry_ref @@ -111,4 +110,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). \ No newline at end of file diff --git a/docs/introduction.md b/docs/introduction.md index f95be819..d1a572b9 100644 --- a/docs/introduction.md +++ b/docs/introduction.md @@ -1,7 +1,6 @@ --- description: Explains what the Registry is, basic use cases and requirements -keywords: -- registry, on-prem, images, tags, repository, distribution, use cases, requirements +keywords: registry, on-prem, images, tags, repository, distribution, use cases, requirements menu: main: parent: smn_registry @@ -52,4 +51,4 @@ Also, while just starting a registry is fairly easy, operating it in a productio ## Next -Dive into [deploying your registry](deploying.md) +Dive into [deploying your registry](deploying.md) \ No newline at end of file diff --git a/docs/notifications.md b/docs/notifications.md index dd01a5b8..a4a5f51b 100644 --- a/docs/notifications.md +++ b/docs/notifications.md @@ -1,7 +1,7 @@ --- description: Explains how to work with registry notifications -keywords: -- registry, on-prem, images, tags, repository, distribution, notifications, advanced +keywords: registry, on-prem, images, tags, repository, distribution, notifications, + advanced menu: main: parent: smn_registry @@ -347,4 +347,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. \ No newline at end of file diff --git a/docs/recipes/apache.md b/docs/recipes/apache.md index 1b503584..318470d7 100644 --- a/docs/recipes/apache.md +++ b/docs/recipes/apache.md @@ -1,8 +1,7 @@ --- 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 +keywords: registry, on-prem, images, tags, repository, distribution, authentication, + proxy, apache, httpd, TLS, recipe, advanced menu: main: parent: smn_recipes @@ -213,4 +212,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 \ No newline at end of file diff --git a/docs/recipes/index.md b/docs/recipes/index.md index 482a4894..948f1bb4 100644 --- a/docs/recipes/index.md +++ b/docs/recipes/index.md @@ -1,7 +1,6 @@ --- description: Fun stuff to do with your registry -keywords: -- registry, on-prem, images, tags, repository, distribution, recipes, advanced +keywords: registry, on-prem, images, tags, repository, distribution, recipes, advanced menu: main: parent: smn_recipes @@ -34,4 +33,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) \ No newline at end of file diff --git a/docs/recipes/mirror.md b/docs/recipes/mirror.md index 6e66f73a..8d94c2f3 100644 --- a/docs/recipes/mirror.md +++ b/docs/recipes/mirror.md @@ -1,8 +1,7 @@ --- description: Setting-up a local mirror for Docker Hub images -keywords: -- registry, on-prem, images, tags, repository, distribution, mirror, Hub, recipe, - advanced +keywords: registry, on-prem, images, tags, repository, distribution, mirror, Hub, + recipe, advanced menu: main: parent: smn_recipes @@ -74,4 +73,4 @@ 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`. \ No newline at end of file diff --git a/docs/recipes/nginx.md b/docs/recipes/nginx.md index 94fca625..d0e97f4f 100644 --- a/docs/recipes/nginx.md +++ b/docs/recipes/nginx.md @@ -1,8 +1,7 @@ --- description: Restricting access to your registry using a nginx proxy -keywords: -- registry, on-prem, images, tags, repository, distribution, nginx, proxy, authentication, - TLS, recipe, advanced +keywords: registry, on-prem, images, tags, repository, distribution, nginx, proxy, + authentication, TLS, recipe, advanced menu: main: parent: smn_recipes @@ -188,4 +187,4 @@ Login with a "push" authorized user (using `testuser` and `testpassword`), then 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 \ No newline at end of file diff --git a/docs/recipes/osx-setup-guide.md b/docs/recipes/osx-setup-guide.md index f926f8c9..03a5fa3a 100644 --- a/docs/recipes/osx-setup-guide.md +++ b/docs/recipes/osx-setup-guide.md @@ -1,7 +1,7 @@ --- description: Explains how to run a registry on macOS -keywords: -- registry, on-prem, images, tags, repository, distribution, macOS, recipe, advanced +keywords: registry, on-prem, images, tags, repository, distribution, macOS, recipe, + advanced menu: main: parent: smn_recipes @@ -78,4 +78,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 \ No newline at end of file diff --git a/docs/storage-drivers/azure.md b/docs/storage-drivers/azure.md index 64e476e4..08d5b00e 100644 --- a/docs/storage-drivers/azure.md +++ b/docs/storage-drivers/azure.md @@ -1,7 +1,6 @@ --- description: Explains how to use the Azure storage drivers -keywords: -- registry, service, driver, images, storage, azure +keywords: registry, service, driver, images, storage, azure menu: main: parent: smn_storagedrivers @@ -74,4 +73,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). \ No newline at end of file diff --git a/docs/storage-drivers/filesystem.md b/docs/storage-drivers/filesystem.md index 2c7f6628..5c7e0e60 100644 --- a/docs/storage-drivers/filesystem.md +++ b/docs/storage-drivers/filesystem.md @@ -1,7 +1,6 @@ --- description: Explains how to use the filesystem storage drivers -keywords: -- registry, service, driver, images, storage, filesystem +keywords: registry, service, driver, images, storage, filesystem menu: main: parent: smn_storagedrivers @@ -20,4 +19,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`. \ No newline at end of file diff --git a/docs/storage-drivers/gcs.md b/docs/storage-drivers/gcs.md index 4c8a7c88..8787b620 100644 --- a/docs/storage-drivers/gcs.md +++ b/docs/storage-drivers/gcs.md @@ -1,7 +1,6 @@ --- description: Explains how to use the Google Cloud Storage drivers -keywords: -- registry, service, driver, images, storage, gcs, google, cloud +keywords: registry, service, driver, images, storage, gcs, google, cloud menu: main: parent: smn_storagedrivers @@ -74,4 +73,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). \ No newline at end of file diff --git a/docs/storage-drivers/index.md b/docs/storage-drivers/index.md index 1c9fbe9d..d42d7b08 100644 --- a/docs/storage-drivers/index.md +++ b/docs/storage-drivers/index.md @@ -2,8 +2,8 @@ aliases: - /registry/storagedrivers/ description: Explains how to use storage drivers -keywords: -- registry, on-prem, images, tags, repository, distribution, storage drivers, advanced +keywords: registry, on-prem, images, tags, repository, distribution, storage drivers, + advanced menu: main: identifier: storage_index @@ -63,4 +63,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. \ No newline at end of file diff --git a/docs/storage-drivers/inmemory.md b/docs/storage-drivers/inmemory.md index 6fbed6aa..d658bcd5 100644 --- a/docs/storage-drivers/inmemory.md +++ b/docs/storage-drivers/inmemory.md @@ -1,7 +1,6 @@ --- description: Explains how to use the in-memory storage drivers -keywords: -- registry, service, driver, images, storage, in-memory +keywords: registry, service, driver, images, storage, in-memory menu: main: parent: smn_storagedrivers @@ -19,4 +18,4 @@ volatile memory, use the [`filesystem` driver](filesystem.md) on a ramdisk. ## Parameters -None +None \ No newline at end of file diff --git a/docs/storage-drivers/oss.md b/docs/storage-drivers/oss.md index 44109003..f291af79 100644 --- a/docs/storage-drivers/oss.md +++ b/docs/storage-drivers/oss.md @@ -1,7 +1,6 @@ --- description: Explains how to use the Aliyun OSS storage driver -keywords: -- registry, service, driver, images, storage, OSS, aliyun +keywords: registry, service, driver, images, storage, OSS, aliyun menu: main: parent: smn_storagedrivers @@ -123,4 +122,4 @@ no The root directory tree in which to store all registry files. Defaults to an empty string (bucket root). - + \ No newline at end of file diff --git a/docs/storage-drivers/s3.md b/docs/storage-drivers/s3.md index cf729490..30941cf9 100644 --- a/docs/storage-drivers/s3.md +++ b/docs/storage-drivers/s3.md @@ -1,7 +1,6 @@ --- description: Explains how to use the S3 storage drivers -keywords: -- registry, service, driver, images, storage, S3 +keywords: registry, service, driver, images, storage, S3 menu: main: parent: smn_storagedrivers @@ -265,4 +264,4 @@ 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). \ No newline at end of file diff --git a/docs/storage-drivers/swift.md b/docs/storage-drivers/swift.md index eaa80511..454f2acb 100644 --- a/docs/storage-drivers/swift.md +++ b/docs/storage-drivers/swift.md @@ -1,7 +1,6 @@ --- description: Explains how to use the OpenStack swift storage driver -keywords: -- registry, service, driver, images, storage, swift +keywords: registry, service, driver, images, storage, swift menu: main: parent: smn_storagedrivers @@ -242,4 +241,4 @@ disabled that feature, the configuration file can specify the following optional

- + \ No newline at end of file From 8c922b0c8c90bf551e596b4b411ffaf0406b6a30 Mon Sep 17 00:00:00 2001 From: Misty Stanley-Jones Date: Fri, 4 Nov 2016 13:33:29 -0700 Subject: [PATCH 11/11] Revert "Merge pull request #437 from gdevillele/fix_keywords_format" This reverts commit 13ddc1350ea1edafcb03d4db901823604a5d1ec1, reversing changes made to 7a11f05943cc62d040dcfedc7621fdeafd11c718. --- docs/compatibility.md | 5 +++-- docs/deploying.md | 5 +++-- docs/deprecated.md | 5 +++-- docs/garbage-collection.md | 6 ++++-- docs/help.md | 5 +++-- docs/index.md | 5 +++-- docs/insecure.md | 5 +++-- docs/introduction.md | 5 +++-- docs/notifications.md | 6 +++--- docs/recipes/apache.md | 7 ++++--- docs/recipes/index.md | 5 +++-- docs/recipes/mirror.md | 7 ++++--- docs/recipes/nginx.md | 7 ++++--- docs/recipes/osx-setup-guide.md | 6 +++--- docs/storage-drivers/azure.md | 5 +++-- docs/storage-drivers/filesystem.md | 5 +++-- docs/storage-drivers/gcs.md | 5 +++-- docs/storage-drivers/index.md | 6 +++--- docs/storage-drivers/inmemory.md | 5 +++-- docs/storage-drivers/oss.md | 5 +++-- docs/storage-drivers/s3.md | 5 +++-- docs/storage-drivers/swift.md | 5 +++-- 22 files changed, 70 insertions(+), 50 deletions(-) diff --git a/docs/compatibility.md b/docs/compatibility.md index 71ee230d..6d18ffc3 100644 --- a/docs/compatibility.md +++ b/docs/compatibility.md @@ -1,6 +1,7 @@ --- description: describes get by digest pitfall -keywords: registry, manifest, images, tags, repository, distribution, digest +keywords: +- registry, manifest, images, tags, repository, distribution, digest menu: main: parent: smn_registry_ref @@ -80,4 +81,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. \ No newline at end of file +pull will fail. diff --git a/docs/deploying.md b/docs/deploying.md index de347055..1aa42aa0 100644 --- a/docs/deploying.md +++ b/docs/deploying.md @@ -1,6 +1,7 @@ --- description: Explains how to deploy a registry -keywords: registry, on-prem, images, tags, repository, distribution, deployment +keywords: +- registry, on-prem, images, tags, repository, distribution, deployment menu: main: parent: smn_registry @@ -233,4 +234,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) \ No newline at end of file + - [Token authentication](spec/auth/token.md) diff --git a/docs/deprecated.md b/docs/deprecated.md index dd4f9762..d30ff425 100644 --- a/docs/deprecated.md +++ b/docs/deprecated.md @@ -1,6 +1,7 @@ --- description: describes deprecated functionality -keywords: registry, manifest, images, signatures, repository, distribution, digest +keywords: +- registry, manifest, images, signatures, repository, distribution, digest menu: main: parent: smn_registry_ref @@ -23,4 +24,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. \ No newline at end of file +garbage-collect subcommand. diff --git a/docs/garbage-collection.md b/docs/garbage-collection.md index 1352b527..d24bb77c 100644 --- a/docs/garbage-collection.md +++ b/docs/garbage-collection.md @@ -1,6 +1,7 @@ --- description: High level discussion of garbage collection -keywords: registry, garbage, images, tags, repository, distribution +keywords: +- registry, garbage, images, tags, repository, distribution menu: main: parent: smn_registry_ref @@ -132,4 +133,5 @@ blob eligible for deletion: sha256:7e15ce58ccb2181a8fced7709e9893206f0937cc9543b blob eligible for deletion: sha256:87192bdbe00f8f2a62527f36bb4c7c7f4eaf9307e4b87e8334fb6abec1765bcb blob eligible for deletion: sha256:b549a9959a664038fc35c155a95742cf12297672ca0ae35735ec027d55bf4e97 blob eligible for deletion: sha256:f251d679a7c61455f06d793e43c06786d7766c88b8c24edf242b2c08e3c3f599 -``` \ No newline at end of file +``` + diff --git a/docs/help.md b/docs/help.md index 40615b27..8728924c 100644 --- a/docs/help.md +++ b/docs/help.md @@ -1,6 +1,7 @@ --- description: Getting help with the Registry -keywords: registry, on-prem, images, tags, repository, distribution, help, 101, TL;DR +keywords: +- registry, on-prem, images, tags, repository, distribution, help, 101, TL;DR menu: main: parent: smn_registry @@ -20,4 +21,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). \ No newline at end of file +You can also find out more about the Docker's project [Getting Help resources](/opensource/get-help.md). diff --git a/docs/index.md b/docs/index.md index 269ab74f..0a57a2d3 100644 --- a/docs/index.md +++ b/docs/index.md @@ -2,7 +2,8 @@ aliases: - /registry/overview/ description: High-level overview of the Registry -keywords: registry, on-prem, images, tags, repository, distribution +keywords: +- registry, on-prem, images, tags, repository, distribution menu: main: parent: smn_registry @@ -64,4 +65,4 @@ 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). \ No newline at end of file +You should now read the [detailed introduction about the registry](introduction.md), or jump directly to [deployment instructions](deploying.md). diff --git a/docs/insecure.md b/docs/insecure.md index 01385ef6..0bb21458 100644 --- a/docs/insecure.md +++ b/docs/insecure.md @@ -1,6 +1,7 @@ --- description: Deploying a Registry in an insecure fashion -keywords: registry, on-prem, images, tags, repository, distribution, insecure +keywords: +- registry, on-prem, images, tags, repository, distribution, insecure menu: main: parent: smn_registry_ref @@ -110,4 +111,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). \ No newline at end of file +Now restart docker (`service docker stop && service docker start`, or any other way you use to restart docker). diff --git a/docs/introduction.md b/docs/introduction.md index d1a572b9..f95be819 100644 --- a/docs/introduction.md +++ b/docs/introduction.md @@ -1,6 +1,7 @@ --- description: Explains what the Registry is, basic use cases and requirements -keywords: registry, on-prem, images, tags, repository, distribution, use cases, requirements +keywords: +- registry, on-prem, images, tags, repository, distribution, use cases, requirements menu: main: parent: smn_registry @@ -51,4 +52,4 @@ Also, while just starting a registry is fairly easy, operating it in a productio ## Next -Dive into [deploying your registry](deploying.md) \ No newline at end of file +Dive into [deploying your registry](deploying.md) diff --git a/docs/notifications.md b/docs/notifications.md index a4a5f51b..dd01a5b8 100644 --- a/docs/notifications.md +++ b/docs/notifications.md @@ -1,7 +1,7 @@ --- description: Explains how to work with registry notifications -keywords: registry, on-prem, images, tags, repository, distribution, notifications, - advanced +keywords: +- registry, on-prem, images, tags, repository, distribution, notifications, advanced menu: main: parent: smn_registry @@ -347,4 +347,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. \ No newline at end of file +for more information. diff --git a/docs/recipes/apache.md b/docs/recipes/apache.md index 318470d7..1b503584 100644 --- a/docs/recipes/apache.md +++ b/docs/recipes/apache.md @@ -1,7 +1,8 @@ --- 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 +keywords: +- registry, on-prem, images, tags, repository, distribution, authentication, proxy, + apache, httpd, TLS, recipe, advanced menu: main: parent: smn_recipes @@ -212,4 +213,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 \ No newline at end of file + docker push myregistrydomain.com:5043/test diff --git a/docs/recipes/index.md b/docs/recipes/index.md index 948f1bb4..482a4894 100644 --- a/docs/recipes/index.md +++ b/docs/recipes/index.md @@ -1,6 +1,7 @@ --- description: Fun stuff to do with your registry -keywords: registry, on-prem, images, tags, repository, distribution, recipes, advanced +keywords: +- registry, on-prem, images, tags, repository, distribution, recipes, advanced menu: main: parent: smn_recipes @@ -33,4 +34,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) \ No newline at end of file + * [mirror the Docker Hub](mirror.md) diff --git a/docs/recipes/mirror.md b/docs/recipes/mirror.md index 8d94c2f3..6e66f73a 100644 --- a/docs/recipes/mirror.md +++ b/docs/recipes/mirror.md @@ -1,7 +1,8 @@ --- description: Setting-up a local mirror for Docker Hub images -keywords: registry, on-prem, images, tags, repository, distribution, mirror, Hub, - recipe, advanced +keywords: +- registry, on-prem, images, tags, repository, distribution, mirror, Hub, recipe, + advanced menu: main: parent: smn_recipes @@ -73,4 +74,4 @@ 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`. \ No newline at end of file +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`. diff --git a/docs/recipes/nginx.md b/docs/recipes/nginx.md index d0e97f4f..94fca625 100644 --- a/docs/recipes/nginx.md +++ b/docs/recipes/nginx.md @@ -1,7 +1,8 @@ --- description: Restricting access to your registry using a nginx proxy -keywords: registry, on-prem, images, tags, repository, distribution, nginx, proxy, - authentication, TLS, recipe, advanced +keywords: +- registry, on-prem, images, tags, repository, distribution, nginx, proxy, authentication, + TLS, recipe, advanced menu: main: parent: smn_recipes @@ -187,4 +188,4 @@ Login with a "push" authorized user (using `testuser` and `testpassword`), then 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 \ No newline at end of file + docker pull myregistrydomain.com:5043/test diff --git a/docs/recipes/osx-setup-guide.md b/docs/recipes/osx-setup-guide.md index 03a5fa3a..f926f8c9 100644 --- a/docs/recipes/osx-setup-guide.md +++ b/docs/recipes/osx-setup-guide.md @@ -1,7 +1,7 @@ --- description: Explains how to run a registry on macOS -keywords: registry, on-prem, images, tags, repository, distribution, macOS, recipe, - advanced +keywords: +- registry, on-prem, images, tags, repository, distribution, macOS, recipe, advanced menu: main: parent: smn_recipes @@ -78,4 +78,4 @@ Start the Docker registry: ### Unloading the docker registry service - launchctl unload ~/Library/LaunchAgents/com.docker.registry.plist \ No newline at end of file + launchctl unload ~/Library/LaunchAgents/com.docker.registry.plist diff --git a/docs/storage-drivers/azure.md b/docs/storage-drivers/azure.md index 08d5b00e..64e476e4 100644 --- a/docs/storage-drivers/azure.md +++ b/docs/storage-drivers/azure.md @@ -1,6 +1,7 @@ --- description: Explains how to use the Azure storage drivers -keywords: registry, service, driver, images, storage, azure +keywords: +- registry, service, driver, images, storage, azure menu: main: parent: smn_storagedrivers @@ -73,4 +74,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). \ No newline at end of file +* 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). diff --git a/docs/storage-drivers/filesystem.md b/docs/storage-drivers/filesystem.md index 5c7e0e60..2c7f6628 100644 --- a/docs/storage-drivers/filesystem.md +++ b/docs/storage-drivers/filesystem.md @@ -1,6 +1,7 @@ --- description: Explains how to use the filesystem storage drivers -keywords: registry, service, driver, images, storage, filesystem +keywords: +- registry, service, driver, images, storage, filesystem menu: main: parent: smn_storagedrivers @@ -19,4 +20,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`. \ No newline at end of file +`100`, and can be no lower than `25`. diff --git a/docs/storage-drivers/gcs.md b/docs/storage-drivers/gcs.md index 8787b620..4c8a7c88 100644 --- a/docs/storage-drivers/gcs.md +++ b/docs/storage-drivers/gcs.md @@ -1,6 +1,7 @@ --- description: Explains how to use the Google Cloud Storage drivers -keywords: registry, service, driver, images, storage, gcs, google, cloud +keywords: +- registry, service, driver, images, storage, gcs, google, cloud menu: main: parent: smn_storagedrivers @@ -73,4 +74,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). \ No newline at end of file +`rootdirectory`: (optional) The root directory tree in which all registry files will be stored. Defaults to the empty string (bucket root). diff --git a/docs/storage-drivers/index.md b/docs/storage-drivers/index.md index d42d7b08..1c9fbe9d 100644 --- a/docs/storage-drivers/index.md +++ b/docs/storage-drivers/index.md @@ -2,8 +2,8 @@ aliases: - /registry/storagedrivers/ description: Explains how to use storage drivers -keywords: registry, on-prem, images, tags, repository, distribution, storage drivers, - advanced +keywords: +- registry, on-prem, images, tags, repository, distribution, storage drivers, advanced menu: main: identifier: storage_index @@ -63,4 +63,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. \ No newline at end of file +function, which run the same set of tests for any registered drivers. diff --git a/docs/storage-drivers/inmemory.md b/docs/storage-drivers/inmemory.md index d658bcd5..6fbed6aa 100644 --- a/docs/storage-drivers/inmemory.md +++ b/docs/storage-drivers/inmemory.md @@ -1,6 +1,7 @@ --- description: Explains how to use the in-memory storage drivers -keywords: registry, service, driver, images, storage, in-memory +keywords: +- registry, service, driver, images, storage, in-memory menu: main: parent: smn_storagedrivers @@ -18,4 +19,4 @@ volatile memory, use the [`filesystem` driver](filesystem.md) on a ramdisk. ## Parameters -None \ No newline at end of file +None diff --git a/docs/storage-drivers/oss.md b/docs/storage-drivers/oss.md index f291af79..44109003 100644 --- a/docs/storage-drivers/oss.md +++ b/docs/storage-drivers/oss.md @@ -1,6 +1,7 @@ --- description: Explains how to use the Aliyun OSS storage driver -keywords: registry, service, driver, images, storage, OSS, aliyun +keywords: +- registry, service, driver, images, storage, OSS, aliyun menu: main: parent: smn_storagedrivers @@ -122,4 +123,4 @@ no The root directory tree in which to store all registry files. Defaults to an empty string (bucket root). - \ No newline at end of file + diff --git a/docs/storage-drivers/s3.md b/docs/storage-drivers/s3.md index 30941cf9..cf729490 100644 --- a/docs/storage-drivers/s3.md +++ b/docs/storage-drivers/s3.md @@ -1,6 +1,7 @@ --- description: Explains how to use the S3 storage drivers -keywords: registry, service, driver, images, storage, S3 +keywords: +- registry, service, driver, images, storage, S3 menu: main: parent: smn_storagedrivers @@ -264,4 +265,4 @@ 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). \ No newline at end of file +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). diff --git a/docs/storage-drivers/swift.md b/docs/storage-drivers/swift.md index 454f2acb..eaa80511 100644 --- a/docs/storage-drivers/swift.md +++ b/docs/storage-drivers/swift.md @@ -1,6 +1,7 @@ --- description: Explains how to use the OpenStack swift storage driver -keywords: registry, service, driver, images, storage, swift +keywords: +- registry, service, driver, images, storage, swift menu: main: parent: smn_storagedrivers @@ -241,4 +242,4 @@ disabled that feature, the configuration file can specify the following optional

- \ No newline at end of file +