尧图网络科技YAOTU DIGITAL 获取报价
获取报价
首页 / 资讯中心 / 文章详情

rkt fetch 命令完全指南:通过 HTTPS、Meta Discovery 与 Docker Registry 拉取 ACI 镜像

发布时间:2026/9/25 2:27:44

资讯中心
01
ARTICLE

rkt fetch 命令完全指南:通过 HTTPS、Meta Discovery 与 Docker Registry 拉取 ACI 镜像

rkt fetch 命令完全指南:通过 HTTPS、Meta Discovery 与 Docker Registry 拉取 ACI 镜像
容器运行时云原生网络【免费下载链接】rkt[Project ended] rkt is a pod-native container engine for Linux. It is composable, secure, and built on standards.项目地址https://gitcode.com/gh_mirrors/rk/rkt点击查看免费下载rkt 是 CoreOS 团队推出的 Pod 原生 Linux 容器引擎其镜像以 ACIApp Container Image格式分发。rkt fetch是 rkt 家族中最基础的命令之一负责从远端定位、下载并校验 ACI 镜像及其签名并将结果存入本地镜像存储imagestore。本指南以 Documentation/subcommands/fetch.md 为骨架深入 rkt 源码剖析四种镜像参数形态镜像名、file://、http(s)://、docker://的完整拉取链路、--pull-policy缓存策略、HTTPS 鉴权配置与签名验证机制读完你将对 rkt 的镜像获取体系有从命令行到存储层级的全景认知。命令概览rkt fetch 到底做了什么从源码看cmdFetch的完整定义为Use: fetch IMAGE_URL... Short: Fetch image(s) and store them in the local store Long: Locates and downloads remote ACIs and their attached signatures. If the ACI is available in the local store, the image will not be fetched again.其定义位于 rkt/fetch.go。命令的核心逻辑runFetch依次执行解析参数 → 打开本地镜像存储imagestore与树存储treestore→ 组装image.Fetcher→ 逐个拉取并打印镜像哈希rkt/fetch.go。默认情况下rkt fetch会连同镜像依赖WithDeps: true一并拉取。拉取完成后rkt 向标准输出打印一个短哈希默认 12 位加--full则打印完整哈希。如果 ACI 已存在于本地存储rkt 不会重复下载Long描述中明确声明。关键实现事实rkt/image/fetcher.goFetchImage根据输入字符串判断镜像“分布”类型ACI 归档、Appc 镜像名、Docker 镜像fetchSingleImage按分布类型分发到不同的拉取器rkt/image/fetcher.go若WithDeps为真递归拉取 ACI manifest 中声明的依赖rkt/image/fetcher.go若系统支持 OverlayFS 且当前为 root还会将镜像渲染进 treestore为后续run/prepare做准备rkt/image/fetcher.go。通过 Meta Discovery 拉取镜像名最省事的用法是直接给镜像名镜像名的 ACI 发现机制在 App Container 规范中有详细定义# rkt fetch coreos.com/etcd:v2.0.0 rkt: searching for app image coreos.com/etcd:v2.0.0 rkt: fetching image from https://github.com/coreos/etcd/releases/download/v2.0.0/etcd-v2.0.0-linux-amd64.aci Downloading aci: [ ] 3.25 MB/3.7 MB Downloading signature from https://github.com/coreos/etcd/releases/download/v2.0.0/etcd-v2.0.0-linux-amd64.sig rkt: signature verified: CoreOS ACI Builder releasecoreos.com sha512-fa1cb92dc276b0f9bedf87981e61ecde流程拆解源码依据 rkt/image/namefetcher.go发现DiscoverydiscoverApp向镜像名的域名发起ac-discovery元标签探测从 HTMLmeta标签中解析出 ACI 与签名ASC文件的真实下载地址rkt/image/namefetcher.go密钥获取maybeFetchPubKeys检查本地是否已信任该镜像名前缀对应的公钥若没有且启用了--trust-keys-from-https会通过 HTTPS或受信任连接自动获取并信任签名公钥rkt/image/namefetcher.go下载与验证下载 ACI 与 ASC 后通过 keystore 校验签名实体校验通过则输出signature verified及签名者身份rkt/image/namefetcher.go。未信任镜像创建者时的行为若尚未信任镜像创建者未提前执行rkt trust --prefix coreos.com/etcdrkt 仍会完成下载但不会验证签名输出中不再出现signature verified行# rkt fetch coreos.com/etcd:v2.0.0 rkt: searching for app image coreos.com/etcd:v2.0.0 rkt: fetching image from https://github.com/coreos/etcd/releases/download/v2.0.0/etcd-v2.0.0-linux-amd64.aci Downloading aci: [ ] 3.25 MB/3.7 MB Downloading signature from https://github.com/coreos/etcd/releases/download/v2.0.0/etcd-v2.0.0-linux-amd64.sig rkt: fetching image from https://github.com/coreos/etcd/releases/download/v2.0.0/etcd-v2.0.0-linux-amd64.aci sha512-fa1cb92dc276b0f9bedf87981e61ecde这与签名信任模型一致rkt 只在“信任镜像创建者”的前提下强制签名验证。签名验证在 rkt/image/validator.go 的ValidateWithSignature与 keystore 的CheckSignature中完成未信任的密钥前缀不会通过校验。从指定位置直接拉取如果你已知镜像的确切存储位置可以直接传 URLHTTP/HTTPS 均支持# rkt fetch https://github.com/coreos/etcd/releases/download/v2.0.0/etcd-v2.0.0-linux-amd64.aci rkt: fetching image from https://github.com/coreos/etcd/releases/download/v2.0.0/etcd-v2.0.0-linux-amd64.aci Downloading aci: [ ] 3.25 MB/3.7 MB Downloading signature from https://github.com/coreos/etcd/releases/download/v2.0.0/etcd-v2.0.0-linux-amd64.sig rkt: fetching image from https://github.com/coreos/etcd/releases/download/v2.0.0/etcd-v2.0.0-linux-amd64.aci sha512-fa1cb92dc276b0f9bedf87981e61ecde在源码层面URL 形态的 ACI 归档由fetchACIArchive处理其仅支持三种 schemehttp、https与file其他 scheme如ftp会明确报错rkt/image/fetcher.go。签名文件的 URL 由镜像 URL 推断把.aci后缀替换为.aci.asc见ascURLFromImgURL/ascPathFromImgPathrkt/image/common.go。用户也可以用--signature参数提供本地签名文件替代远端签名。本地文件file:// 与相对路径除了 URL你还可以直接指定本地 ACI 文件例如rkt fetch file:///home/me/foo.aci或rkt fetch foo.aci。当输入既不像 URL 也不像带版本号的镜像名时rkt 会按“本地路径”启发式处理guessAppcOrPathrkt/image/common.go。file://路径走fetchSingleImageByPath直接使用fileFetcher读取文件并导入存储rkt/image/fetcher.go。从 Docker Registry 拉取镜像rkt 可以直接拉取现有 Docker 镜像并在本地将其转换为 ACI# rkt --insecure-optionsimage fetch docker://busybox rkt: fetching image from docker://busybox rkt: warning: image signature verification has been disabled Downloading layer: 4986bf8c15363d1c5d15512d5266f8777bfba4974ac56e3270e7760f6f0a8125 Downloading layer: ea13149945cb6b1e746bf28032f02e9b5a793523481a0a18645fc77ad53c4ea2 Downloading layer: df7546f9f060a2268024c8a230d8639878585defcc1bc6f79d2728a13957871b Downloading layer: 511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158 sha512-c4010045aec65aefa74770ef2bb648d9关键约束Docker 镜像不支持签名验证。因此必须携带--insecure-optionsimage跳过镜像签名校验才能拉取否则会直接报错“signature verification for docker images is not supported (try --insecure-optionsimage)”——这是dockerFetcher中的硬性检查rkt/image/dockerfetcher.go。底层实现rkt/image/dockerfetcher.go解析docker://URL语法要求为docker://[REGISTRY_HOST[:REGISTRY_PORT]/]IMAGE_NAME[:TAG]调用docker2aci库的ConvertRemoteRepo拉取各层并Squash合成为一个 ACI 文件Compression: NoCompression将合成后的 ACI 写入本地 imagestore若 URL 未指定:TAG或 TAG 为latest该镜像在存储中被标记为Latest后续rkt fetch docker://busybox会识别这种“最新标记”。此外docker://URL 也支持直接跟 Docker Hub 默认仓库的省略写法如docker:///redis详见下文鉴权小节。镜像拉取行为与缓存策略--pull-policyrkt 会尽量避免不必要的网络传输若镜像已存在于本地存储rkt 会利用 HTTP 的ETag 与 Cache-Control判断是否仍需重新下载——除非远端镜像已更新否则不再传输。这一行为可通过--pull-policy标志调整完整语义定义在 Documentation/image-fetching-behavior.md。三种策略语义选项含义newrun 与 prepare 的默认行为先查本地存储缺失则从远端拉取updatefetch 的默认行为尝试从远端拉取但若远端镜像与本地存储一致则不拉取never仅查本地存储绝不访问远端按镜像参数类型的详细行为矩阵拉取来源镜像参数详细行为store本地file://直接使用指定文件store本地http(s)://在本地存储中查找该 URL命中则使用对应镜像store本地docker://在本地存储中查找该 URL命中则使用对应镜像store本地镜像名查本地存储命中即用。若当前目录存在与镜像名同名的文件则优先使用该文件remote远端file://使用指定文件remote远端http(s)://先查存储中该 URL 的记录若存在且保存的Cache-Control的max-age 0判断镜像是否过期未过期直接用否则重新下载若可用则携带已保存的 ETag 发起条件请求。若服务端返回304 Not Modified仍使用本地存储中已有的镜像remote远端docker://使用 docker2aci 拉取remote远端镜像名执行 ACI Discovery 逻辑发现成功则按上述 http(s):// 的远端规则下载。若当前目录存在与镜像名同名的文件则优先使用该文件源码级实现细节拉取策略与 ETag/Cache 逻辑的核心落在两处Fetcher 分发maybeCheckRemoteFromStore在PullPolicy ! update时直接返回本地存储中的 BlobKeyrkt/image/fetcher.gomaybeFetchHTTPURLFromRemote在PullPolicy ! never时走 httpFetcherrkt/image/fetcher.go。对于镜像名maybeCheckStoreForApprkt/image/fetcher.go与maybeFetchImageFromRemoterkt/image/fetcher.go做同样的策略判断。缓存判定httpFetcher.Hash先通过useCached(rem.DownloadTime, rem.CacheMaxAge)判断本地缓存是否仍在有效期rkt/image/httpfetcher.go过期则携带旧 ETag 发起下载rkt/image/httpops.go 中的If-None-Match请求头resumableSession.HandleStatus解析 HTTP 响应304 Not Modified时置UseCached true并直接复用本地 BlobKeyrkt/image/resumablesession.goCache-Control的max-age、no-store、no-cache由getMaxAge解析rkt/image/resumablesession.go。另外值得一提的细节resumableSession还支持断点续传——若本地已有部分下载的临时文件且服务器支持 Range 请求会通过Range: bytes已下载字节数-请求续传并通过 Last-Modified/ETag 判断资源是否已变化rkt/image/resumablesession.go。兼容旧标志历史上 fetch 还有两个标志现已弃用并映射到 pull-policyrkt/fetch.go--store-only已弃用→ 等价于--pull-policynever--no-store已弃用→ 等价于--pull-policyupdate私有仓库鉴权配置从私有仓库下载镜像时通常需要凭证。rkt 目前支持https:// 与 docker:// 两种协议的拉取鉴权凭证通过 JSON 配置文件提供。注意https 与 docker 对应的配置 kind 完全不同格式详见 Documentation/configuration.md。配置目录分层系统目录/usr/lib/rktvendor 提供、只读、本地目录/etc/rkt管理员维护、可选用户目录保存私有凭证。三者可用--system-config、--local-config、--user-config标志覆盖覆盖语义为“后层覆盖前层同名字段”。https 鉴权rktKind auth配置文件放置于auth.d子目录默认/etc/rkt/auth.d。每种配置必须包含非空的rktKind与rktVersion当前版本v1支持三种鉴权类型1. Basic HTTP 认证type: basic——credentials含user、password两键/etc/rkt/auth.d/coreos-basic.json:{ rktKind: auth, rktVersion: v1, domains: [coreos.com, tectonic.com], type: basic, credentials: { user: foo, password: bar } }2. OAuth Bearer Tokentype: oauth——credentials只含token一键/etc/rkt/auth.d/coreos-oauth.json:{ rktKind: auth, rktVersion: v1, domains: [coreos.com, tectonic.com], type: oauth, credentials: { token: sometoken } }3. AWS v4 签名type: aws——credentials中accessKeyID与secretAccessKey必填awsRegion可选留空则从 URL/域名自动推断/etc/rkt/auth.d/coreos-aws.json:{ rktKind: auth, rktVersion: v1, domains: [my-s3-bucket.s3.amazonaws.com], type: aws, credentials: { accessKeyID: foo, secretAccessKey: bar, awsRegion: us-east-1 } }覆盖语义按域名逐条覆盖。例如系统目录已有对所有域名生效的 OAuth 公共 token/usr/lib/rkt/auth.d/coreos.jsondomains 含coreos.com、tectonic.com、kubernetes.io本地目录再用两个文件分别覆盖coreos.com改为 Basic与tectonic.com换成专属 token/etc/rkt/auth.d/specific-coreos.json:{ rktKind: auth, rktVersion: v1, domains: [coreos.com], type: basic, credentials: { user: foo, password: bar } }/etc/rkt/auth.d/specific-tectonic.json:{ rktKind: auth, rktVersion: v1, domains: [tectonic.com], type: oauth, credentials: { token: tectonic-token } }最终效果请求kubernetes.io仍发Authorization: Bearer common-token请求coreos.com发Authorization: Basic Zm9vOmJhcg即foo:bar的 Base64请求tectonic.com发Authorization: Bearer tectonic-token。注意在同一个配置目录内同一域名出现在多个文件中属于语法错误。Docker Registry 鉴权rktKind dockerAuth配置同样放在auth.d子目录但字段不同registries字符串数组必填与credentials目前仅支持 Basic 认证含user、password两键。常用 Docker Registry 列表registry-1.docker.io命令行未指定 registry 时的默认例如docker:///redisquay.iogcr.ioaws_account_id.dkr.ecr.region.amazonaws.comAWS ECR示例/etc/rkt/auth.d/docker.json:{ rktKind: dockerAuth, rktVersion: v1, registries: [registry-1.docker.io, quay.io], credentials: { user: foo, password: bar } }覆盖语义按 registry 逐条生效例如系统配置覆盖registry-1.docker.io、gcr.io、quay.io本地可用/etc/rkt/auth.d/specific-quay.jsonquay.io用baz/quux与/etc/rkt/auth.d/specific-gcr.jsongcr.io用goo/gle局部覆盖未被覆盖的registry-1.docker.io仍沿用系统配置的用户名密码。同一配置目录内同一 registry 定义在多个文件中同样是语法错误。使用 AWS ECR 时凭证会过期需定期刷新如aws ecr get-login获取新凭证。在源码中dockerFetcher.getCreds依据 registry 的 index name 从DockerAuth映射来自dockerAuth配置 kind中取出用户名密码传给docker2aci.RemoteConfigrkt/image/dockerfetcher.gohttps 的鉴权头则由resumableSession.httpRequest在请求 URL 为 https 时按 host 匹配Headerers即auth配置调用SignRequest注入rkt/image/resumablesession.go且重定向到不同 host 时会剥离Authorization头防止凭证泄露rkt/image/resumablesession.go。命令选项速查rkt fetch支持的专属选项rkt/fetch.goFlag默认值取值说明--fullfalsetrue/false拉取后打印完整镜像哈希默认打印短哈希--signature空文件路径用于校验前一个镜像的本地签名文件--pull-policynewfetch 命令内部默认updatenever、new、update设置何时拉取镜像详见 Documentation/image-fetching-behavior.md需要说明的是--pull-policy标志默认值在 flag 定义层面是new但 fetch 子命令通过flagPullPolicyDefaultUpdate在运行时将默认值改为updaterkt/fetch.go与 Documentation/image-fetching-behavior.md 中“fetch 默认 update”的表述一致。全局选项fetch 同样适用Flag默认值取值说明--insecure-optionsnonenone、http、image、tls、pubkey、capabilities、paths、seccomp、all-fetch、all-run、all逗号分隔的安全功能禁用列表详见 Documentation/commands.md--system-config/usr/lib/rkt目录路径系统配置目录--local-config/etc/rkt目录路径本地配置目录--user-config空目录路径用户配置目录--trust-keys-from-httpsfalsetrue/false自动信任从 HTTPS 获取的 GPG 密钥若同时指定 insecure 的pubkey选项HTTP 也可--insecure-options中与拉取镜像最相关的是image跳过镜像签名验证、tls跳过 TLS 证书校验与pubkey允许通过不安全连接获取公钥。其中image在拉取 Docker 镜像时是强制项tls对应源码中SkipTLSCheck会打印 “TLS verification has been disabled” 警告pubkey对应ConsiderInsecurePubKeys会显著降低安全性——攻击者可伪造远端服务器与假密钥进而提供被篡改的容器镜像Documentation/commands.md。常见用法与排错建议只想获取镜像但不想运行用rkt fetch而非rkt run——fetch 只下载并入库run 会进一步启动容器。拉取 Docker 镜像忘记--insecure-optionsimage会得到 “signature verification for docker images is not supported” 错误补上该标志即可。希望强制使用本地缓存离线拉取rkt fetch --pull-policynever 镜像仅查 imagestore不访问远端。希望强制刷新远端内容rkt fetch --pull-policyupdate 镜像是 fetch 默认行为若远端资源未变化服务端返回304后仍复用本地镜像不产生冗余流量。私有 S3 桶拉取失败确认/etc/rkt/auth.d/下已配置type: aws的auth配置且domains与桶域名精确匹配。镜像签名验证失败若已信任创建者但报签名错误通常意味着远端签名变更可尝试rkt trust --prefix 前缀重新信任源码在 rkt/image/namefetcher.go 中对此有提示。扩展阅读镜像拉取策略的完整行为矩阵Documentation/image-fetching-behavior.md所有配置 kindauth / dockerAuth / paths / stage1的字段与覆盖语义Documentation/configuration.md签名信任与公钥管理Documentation/signing-and-verification-guide.mdfetch 拉取到的镜像如何被 run / prepare 使用Documentation/subcommands/run.md 与 Documentation/subcommands/prepare.md全局选项完整列表Documentation/commands.md核心实现源码rkt/image/fetcher.go、rkt/image/namefetcher.go、rkt/image/httpfetcher.go、rkt/image/dockerfetcher.go、rkt/image/resumablesession.go、rkt/fetch.go赞分享容器运行时云原生网络【免费下载链接】rkt[Project ended] rkt is a pod-native container engine for Linux. It is composable, secure, and built on standards.项目地址https://gitcode.com/gh_mirrors/rk/rkt点击查看免费下载相关推荐rkt ACI 托管指南利用 Meta Discovery 搭建镜像分发服务rkt ACI 托管指南利用 Meta Discovery 搭建镜像分发服务 rkt 以 App Container ImagesACI作为应用容器的原生容器运行时云原生网络rkt trust为 ACI 镜像验证建立信任链的命令行指南rkt trust为 ACI 镜像验证建立信任链的命令行指南 rkt 在运行任何从远程获取的 ACIApp Container Image之前都会依据镜容器运行时云原生网络小米米家设备通信协议演进从mihome-binary-protocol看智能家居安全发展小米米家设备通信协议演进从mihome binary protocol看智能家居安全发展 小米米家MiHome设备通过专有的二进制通信协议实现智能控制该物联网智能家居网络通信逆向工程上一篇MLX-VLM DOTS-MOCR终极指南如何在Mac上实现高效多语言OCR识别下一篇10倍速数据处理cuDF GPU加速实战指南让你的Python代码飞起来创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
02
RELATED NEWS

相关资讯

更多网站建设与数字化升级内容

03
WHY YAOTU

想打造同款高转化官网?

懂行业、懂生意,从建站到增长一站式陪跑

◈

场景化定制

不做模板站,围绕你的业务场景量身设计,小众不撞款。

◐

营销型架构

以转化目标组织内容与路径,让官网真正带来询盘。

▲

全周期服务

设计、开发、运营、运维一体,上线只是开始。

免费获取你的建站方案

留下需求,专属顾问 24 小时内为你输出方案建议。