为什么无法镜像文件-(为什么无法镜像文件夹)

为什么不能镜像文件？ (为什么不能镜像文件？夹)

简介：本文主要关注镜像结构和 Registry API 总结使用情况。

API1、拉取镜像

镜像是由的 JSON 元数据由独立的层文件组成，镜像检索的重点是找到这两部分。

拉取镜像的第一步是取回元数据(manifest)，注册表(registry)相关字段如下：

字段	描述
name	镜像名称
tag	镜像版本
fsLayers	层描述符列表(包括摘要)电脑
signature	元数据签名

获取元数据清单后，客户必须验证签名，以确保名称和层的有效性。确认后，客户端将使用摘要(digest)下载层文件(layer)。

1.1、拉取 manifests

GET /v2/<name>/manifests/<reference>

name和reference它是定义镜像的必要参数，可以指定唯一的镜像，reference可以是 tag 或 digest

返回数据

{ "schemaVersion": 1, "name": <name>, "tag": <tag>, "architecture": "amd64", "fsLayers":[{ "blobSum": "sha256:a3ed95caeb02ffe68cdd9fd84406680ae93d633cb16422d00e8a7c22955b46d4" }], "history":[<v1 images>], "signatures":[<JWS>]}

在获取层文件之前，客户端应验证返回元数据签名的真实性。

1.1.1.镜像是否存在

HEAD /v2/<name>/manifests/<reference>

name和reference它是定义镜像的必要参数，可以指定唯一的镜像，reference可以是 tag 或 digest电脑

如果返回 404 表示镜像不存在。如果镜像有返回 200

HTTP/1.1 200 OKContent-Length: 9116Content-Type: application/vnd.docker.distribution.manifest.v1 prettyjwsDocker-Content-Digest: sha256:0f09fdacdca588279f0cb332ed0768daa9ed734c491d5d04b89d215982c2bfac1.2.拉取层文件

层存储在注册表中 blob 部分中，由摘要键入。 拉层是通过标准的 http 请求进行的

GET /v2/<name>/blobs/<digest>

对层访问由存储库中的对层访问 name 控制，但注册表中唯一的标识是摘要。

这个 api 可能会响应 307 重定向到另一个服务下载层，客户端应处理重定向。

这个 api 可能会响应 307 重定向到另一个服务下载层，客户端应处理重定向。

2、推送镜像

推镜像和拉镜像的工作顺序相反。组装镜像清单后，客户端必须先将每层推送，当层文件完全推送到注册表，客户端需要上传元数据签名。

2.推送层文件

上传层文件需要两步：

上传并返回注册表服务 url 第二步使用 url 传输实际数据

上传是用 POST 请求开始时，可用于推送数据和检查上传状态 url。

请求头“Location每次请求上传后，将用于定位位置。

2.1.1、开始上传POST /v2/<name>/blobs/uploads

请求的参数是将镜像空间链接到层文件

2.1.2.层是否存在HEAD 电脑 /v2/<name>/blobs/<digest>

若存在指定层文件的摘要，则响应 200，没有 body。200 OKContent-Length: <length of blob>Docker-Content-Digest: <digest>

当收到响应时，客户可以知道层已经存在于注册表中，不需要上传

2.1.三、上传层文件

如果 POST 请求成功，响应 202，然后在响应头中会有Location”指定上传 url202 AcceptedLocation: /v2/<name>/blobs/uploads/<uuid>Range: bytes=0-<offset>Content-Length: 0Docker-Upload-UUID: <uuid>

返回上传过程 url 进行，对上传 url 所有响应，无论是发送数据还是获取状态，都是按照这格式。虽然指定了虽然Location”标头的 URI 但客户端应将其视为黑盒，不得自行组装。虽然指定了虽然Location”标头的 URI 格式，但客户端应视为黑盒，不得自行组装。如果客户端需要将本地上传状态与远程上传状态联系起来，则应使用它Docker-Upload-UUID:在断点重传标头内容时，uuid 可以键入最后使用的位置。

2.1.4、上传进度

通过头上传进度Range虽然不是标志Range仍有许多标准使用方法的例子。

对于刚开始上传，比如一个 1000 字节层文件，“Range标头如下：Range: bytes=0-0

使用 GET 获取上传进度的方法GET /v2/<name>/blobs/uploads/<uuid>Host: <registry host>

响应类似，会返回 204204 No ContentLocation: /v2/<name>/blobs/uploads/<uuid>Range: bytes=0-<offset>Docker-Upload-UUID: <uuid>

2.1.5、单块上传

单块上传是上传单块，为了避免分块的复杂性，只需上传整个单块即可 blob 放到提供的 url 中PUT /v2/<name>/blobs/uploads/<uuid>?digest=<digest>Content-Length: <size of layer>Content-Type: application/octet-stream<Layer Binary Data>

digest必须有参数 PUT 请求中使用

2.1.6、分块上传

上传一块，可指定客户端Range而且只包含层Range部分PATCH /v2/<name>/blobs/uploads/<uuid>Content-Length: <size of chunk>Content-Range: <start of range>-<end of range>Content-Type: application/octet-stream<Layer Chunk Binary Data>

除服务器必须按顺序接受外，拆分没有强制执行块。如果服务器不能接收块，服务器可以强制限制块的最小块。 416。

如果收到 416客户端应从最后一个有效范围恢复上传，并在此情况下返回 416：

无效请求头Content-Range乱序块：下一个块的范围必须在前一个响应的最后一个有效范围后立即开始若块被成功接收，会返回 202

2.1.7、完成上传

为保证上传的完整性，客户端在上传 url 提交一个带有摘要参数的提交 PUT 如果未提供请求，则不认为上传已完成。PUT /v2/<name>/blobs/uploads/<uuid>?digest=<digest>Content-Length: <size of chunk>Content-Range: <start of range>-<end of range>Content-Type: application/octet-stream<Last Layer Chunk Binary Data>

可选的，如果所有块都上传了，可以发送带 digest 参数和 0 长度的 body 的 PUT 请求验证上传完成。

最后一块被接收，层校验完成，接收客户端 201 响应201 CreatedLocation: /v2/<name>/blobs/<digest>Content-Length: 0Docker-Content-Digest: <digest>

Location它将包含可访问层 url，Docker-Content-Digest返回上传的 blob 摘要。

2.1.8、取消上传DELETE /v2/<name>/blobs/uploads/<uuid>

发出此请求后，上传 uuid 它将不再有效，注册服务器将转储所有中间数据。虽然上传未完成会超时，但如果客户端遇到致命错误，仍可发出 http 本请求应发出。虽然上传未完成会超时，但如果客户端遇到致命错误，仍可发出 http 本请求应发出。

2.1.9.跨仓库挂载

另一个可以从客户端读取访问权限的存储库安装 blob，因此，无需上传已知的登记表 blob。 要发出 blob 挂载而不是上传，应以下格式发布 POST 请求POST /v2/<name>/blobs/uploads/?mount=<digest>&from=<repository name>Content-Length: 0

如果 blob 成功挂载，客户端会收到响应 201201 CreatedLocation: /v2/<name>/blobs/<digest>Content-Length: 0Docker-Content-Digest: <digest>

Location用于访问已接收层文件的注册表 URI，Docker-Content-Digest返回上传的 blob 的摘要。

}{

电脑