docker 仓库 —— 获取 docker repository 中的 image 信息

http://192.168.33.21:5000/v2/_catalog

 http://192.168.33.21:5000/v2/_catalog?n=2000

n=2000 ,为显示 2000条 仓库name（默认显示）

 

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": [
    <name>,
    ...
  ]
}

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 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=<integer>

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: <<url>?n=<n from the request>&last=<last repository in response>>; rel="next"

{
  "repositories": [
    <name>,
    ...
  ]
}

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 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 <http://example.com/v2/_catalog?n=20&last=b>; rel="next". Please see 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=<n from the request>&last=<last repository value from previous response>

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: <<url>?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.

http://192.168.33.21:5000/v2/westwin/cbop/cbop_ut_pg13.5/tags/list

http://192.168.33.21:5000/v2/westwin.io/customer_containers/dotnet-pg13/tags/list

 

 

> [internal] load metadata for 192.168.33.21:5000/********12:v3.1.10:
failed to solve with frontend dockerfile.v0: failed to create LLB definition: failed to do request: Head "https://192.168.33.21:5000/v2/**********/manifests/v3.1.10": http: server gave HTTP response to HTTPS client

 docker pull 指定image地址（不添加 http or https）

 

docker 配置，修复 http 自动改为 https请求。 仓库地址前 添加【https://】

{
  "registry-mirrors": [],
  "insecure-registries": [
    "http://192.168.33.21:5000"
  ],
  "debug": false,
  "experimental": false,
  "features": {
    "buildkit": true
  },
  "builder": {
    "gc": {
      "enabled": true,
      "defaultKeepStorage": "20GB"
    }
  }
}

　　

参考文档：

https://newbedev.com/how-to-get-a-list-of-images-on-docker-registry-v2

How to get a list of images on docker registry v2

For the latest (as of 2015-07-31) version of Registry V2, you can get this image from DockerHub:

docker pull distribution/registry:master

List all repositories (effectively images):

curl -X GET https://myregistry:5000/v2/_catalog
> {"repositories":["redis","ubuntu"]}

List all tags for a repository:

curl -X GET https://myregistry:5000/v2/ubuntu/tags/list
> {"name":"ubuntu","tags":["14.04"]}

If the registry needs authentication you have to specify username and password in the curl command

curl -X GET -u <user>:<pass> https://myregistry:5000/v2/_catalog
curl -X GET -u <user>:<pass> https://myregistry:5000/v2/ubuntu/tags/list

you can search on

http://<ip/hostname>:<port>/v2/_catalog

Get catalogs

Default, registry api return 100 entries of catalog, there is the code:

When you curl the registry api:

curl --cacert domain.crt https://your.registry:5000/v2/_catalog

it equivalents with：

curl --cacert domain.crt https://your.registry:5000/v2/_catalog?n=100

This is a pagination methond.

When the sum of entries beyond 100, you can do in two ways:

First: give a bigger number

curl --cacert domain.crt https://your.registry:5000/v2/_catalog?n=2000

Sencond: parse the next linker url

curl --cacert domain.crt https://your.registry:5000/v2/_catalog

A link element contained in response header:

curl --cacert domain.crt https://your.registry:5000/v2/_catalog

response header:

Link: </v2/_catalog?last=pro-octopus-ws&n=100>; rel="next"

The link element have the last entry of this request, then you can request the next 'page':

curl --cacert domain.crt https://your.registry:5000/v2/_catalog?last=pro-octopus-ws

If the response header contains link element, you can do it in a loop.

Get Images

When you get the result of catalog, it like follows:

{ "repositories": [ "busybox", "ceph/mds" ] }

you can get the images in every catalog:

curl --cacert domain.crt https://your.registry:5000/v2/busybox/tags/list

returns:

{"name":"busybox","tags":["latest"]}

The latest version of Docker Registry available from https://github.com/docker/distribution supports Catalog API. (v2/_catalog). This allows for capability to search repositories

If interested, you can try docker image registry CLI I built to make it easy for using the search features in the new Docker Registry distribution (https://github.com/vivekjuneja/docker_registry_cli)

We wrote a CLI tool for this purpose: docker-ls It allows you to browse a docker registry and supports authentication via token or basic auth.

https://docs.docker.com/registry/spec/api/#/listing-image-tags

GET Base

Check that the endpoint implements Docker Registry API V2.

GET /v2/
Host: <registry host>
Authorization: <scheme> <token>

The following parameters should be specified on the request:

Name	Kind	Description
Host	header	Standard HTTP Host Header. Should be set to the registry host.
Authorization	header	An RFC7235 compliant authorization header.

 

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": [
    <name>,
    ...
  ]
}

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 section.

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/<name>/tags/list

The response will be in the following format:

200 OK
Content-Type: application/json

{
    "name": <name>,
    "tags": [
        <tag>,
        ...
    ]
}

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.

Tags

Retrieve information about tags.

GET Tags

Fetch the tags under the repository identified by name.

Tags

GET /v2/<name>/tags/list
Host: <registry host>
Authorization: <scheme> <token>

Return all tags for the repository

The following parameters should be specified on the request:

Name	Kind	Description
Host	header	Standard HTTP Host Header. Should be set to the registry host.
Authorization	header	An RFC7235 compliant authorization header.
name	path	Name of the target repository.

Manifest

Create, update, delete and retrieve manifests.

GET Manifest

Fetch the manifest identified by name and reference where reference can be a tag or digest. A HEAD request can also be issued to this endpoint to obtain resource information without receiving all data.

GET /v2/<name>/manifests/<reference>
Host: <registry host>
Authorization: <scheme> <token>

The following parameters should be specified on the request:

Name	Kind	Description
Host	header	Standard HTTP Host Header. Should be set to the registry host.
Authorization	header	An RFC7235 compliant authorization header.
name	path	Name of the target repository.
reference	path	Tag or digest of the target manifest.

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.

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
GET	/v2/	Base	Check that the endpoint implements Docker Registry API V2.
GET	/v2/<name>/tags/list	Tags	Fetch the tags under the repository identified by name.
GET	/v2/<name>/manifests/<reference>	Manifest	Fetch the manifest identified by name and reference where reference can be a tag or digest. A HEAD request can also be issued to this endpoint to obtain resource information without receiving all data.
PUT	/v2/<name>/manifests/<reference>	Manifest	Put the manifest identified by name and reference where reference can be a tag or digest.
DELETE	/v2/<name>/manifests/<reference>	Manifest	Delete the manifest identified by name and reference. Note that a manifest can only be deleted by digest.
GET	/v2/<name>/blobs/<digest>	Blob	Retrieve the blob from the registry identified by digest. A HEAD request can also be issued to this endpoint to obtain resource information without receiving all data.
DELETE	/v2/<name>/blobs/<digest>	Blob	Delete the blob identified by name and digest
POST	/v2/<name>/blobs/uploads/	Initiate Blob Upload	Initiate a resumable blob upload. If successful, an upload location will be provided to complete the upload. Optionally, if the digest parameter is present, the request body will be used to complete the upload in a single request.
GET	/v2/<name>/blobs/uploads/<uuid>	Blob Upload	Retrieve status of upload identified by uuid. The primary purpose of this endpoint is to resolve the current status of a resumable upload.
PATCH	/v2/<name>/blobs/uploads/<uuid>	Blob Upload	Upload a chunk of data for the specified upload.
PUT	/v2/<name>/blobs/uploads/<uuid>	Blob Upload	Complete the upload specified by uuid, optionally appending the body as the final chunk.
DELETE	/v2/<name>/blobs/uploads/<uuid>	Blob Upload	Cancel outstanding upload processes, releasing associated resources. If this is not called, the unfinished uploads will eventually timeout.
GET	/v2/_catalog	Catalog	Retrieve a sorted, json list of repositories available in the registry.

The detail for each endpoint is covered in the following sections.