尧图网页设计 
AWS CLI 实战使用cloudfront get-invalidation查询 CloudFront 缓存失效任务状态【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli本篇技术指南以 AWS CLI 的aws cloudfront get-invalidation命令为核心系统讲解如何按失效任务 IDInvalidation ID查询 CloudFront 分发Distribution上某次缓存失效操作的详细信息包括任务状态、路径清单、批量请求引用与创建时间。文章同时结合本仓库aws-cli中的命令示例、服务模型service-2.json与等待器waiters-2.json配置为你串起创建失效 → 查询状态 → 等待完成 → 批量列表的完整操作闭环。读完本文你将掌握通过命令行获取任意 CloudFront 失效任务状态的能力并理解失效批次InvalidationBatch与调用方引用CallerReference的底层语义。为什么需要查询缓存失效任务CloudFront 是内容分发网络CDN边缘节点会缓存你的静态资源。当源站上的文件更新后缓存中的旧版本可能仍被客户端命中。此时可以通过**失效Invalidation**机制主动通知 CloudFront 把指定路径的缓存对象作废让后续请求回源拉取最新内容。失效操作是异步的create-invalidation提交后任务会经历InProgress状态直到边缘节点完成清理后才变为Completed。因此你需要一种手段随时确认任务进展——这正是aws cloudfront get-invalidation的用途给定分发 ID 与失效任务 ID返回该任务的最新状态与完整定义。从本仓库的命令行示例 get-invalidation.rst 可以看到它的典型用法aws cloudfront get-invalidation --id I2J0I21PCUYOIK --distribution-id EDFDVBD6EXAMPLE命令用法与参数说明get-invalidation是 AWS CLI 的 CloudFront 命令族中的只读查询命令需要两个必选参数参数类型必选说明--distribution-idString是CloudFront 分发的 ID例如EDFDVBD6EXAMPLE用于定位具体分发--idString是失效任务invalidation的标识符例如I2J0I21PCUYOIK用于定位具体失效任务在底层服务模型中这两个参数分别对应GetInvalidationRequest的DistributionId与Id字段且都会被放入请求 URI 的路径中location: uri详见 service-2.json。也就是说该请求本质上是对以下 REST 端点的调用GET /2020-05-31/distribution/{DistributionId}/invalidation/{Id}典型输出与字段解读命令返回的是一个Invalidation结构体GetInvalidationResult的 payload 直接是该结构见 service-2.json。以下为 get-invalidation.rst 中的完整输出示例{ Invalidation: { Status: Completed, InvalidationBatch: { Paths: { Items: [ /example-path/example-file.jpg, /example-path/example-file-2.jpg ], Quantity: 2 }, CallerReference: cli-example }, Id: I2J0I21PCUYOIK, CreateTime: 2019-12-05T18:40:49.413Z } }对照 service-2.json 中的Invalidation结构定义输出字段含义如下Id失效任务的唯一标识符。由create-invalidation创建时生成也是你后续在--id参数中使用的值。Status任务当前状态。当失效批次执行完毕时为Completed模型中明确说明When the invalidation batch is finished, the status isCompleted执行中则为InProgress。CreateTime失效请求首次提交的时间戳UTCISO 8601 格式例如2019-12-05T18:40:49.413Z。InvalidationBatch本次失效请求的批次定义包含两部分Paths本次要作废的对象路径列表与数量。Items路径字符串数组路径以/开头代表分发根目录下的对象目录失效以/*结尾如/images/*。Quantity路径数量必须与Items实际个数一致模型将其定义为必填字段required: [Quantity]见 service-2.json。CallerReference调用方引用用于唯一标识一次失效请求防止重复提交详见下文。需要注意的是Invalidation结构的Id、Status、CreateTime、InvalidationBatch四个字段在服务模型中均为必填required因此查询成功时输出结构始终完整。从创建到查询完整操作链路get-invalidation通常不会单独使用而是与create-invalidation和list-invalidations配合构成完整的失效任务生命周期管理。以下流程可以同时参考本仓库的 create-invalidation.rst 与 list-invalidations.rst。第一步创建失效任务aws cloudfront create-invalidation \ --distribution-id EDFDVBD6EXAMPLE \ --paths /example-path/example-file.jpg /example-path/example-file2.png注意这里的--paths是 AWS CLI 对 CloudFront 命令的自定义参数。在 cloudfront.py 的实现中PathsArgument接收空格分隔的多个路径并在底层自动组装成InvalidationBatchCallerReference由unique_string()自动生成形如cli-1575570291-670203即cli- 时间戳 随机数见 cloudfront.pyPaths.Quantity自动取路径个数。该参数与--invalidation-batchJSON 文件方式互斥源码通过validate_mutually_exclusive_handler([invalidation_batch], [paths])强制约束见 cloudfront.py。创建响应中的Id例如I1JLWSDAP8FU89与Status通常为InProgress就是你后续查询的输入。如果你想自行控制CallerReference或想通过文件管理大量路径也可以用 JSON 文件方式aws cloudfront create-invalidation \ --distribution-id EDFDVBD6EXAMPLE \ --invalidation-batch file://inv-batch.jsoninv-batch.json内容{ Paths: { Quantity: 2, Items: [ /example-path/example-file.jpg, /example-path/example-file2.png ] }, CallerReference: cli-example }第二步按 ID 查询任务状态拿到任务 ID 后即可执行本文主角命令aws cloudfront get-invalidation --id I2J0I21PCUYOIK --distribution-id EDFDVBD6EXAMPLE返回的Status字段是判断任务是否完成的依据InProgress表示边缘节点仍在处理Completed表示失效已完成。配合后续章节的等待器可以自动化这一判断。第三步列出某分发的全部失效任务如果需要回顾某分发下所有失效任务的 ID例如忘记记录某个任务 ID可用list-invalidationsaws cloudfront list-invalidations --distribution-id EDFDVBD6EXAMPLE返回结构InvalidationList中包含ItemsInvalidationSummary列表每项含Id、Status、CreateTime、Quantity总数、Marker/NextMarker/IsTruncated分页游标与MaxItems本次返回上限等字段见 list-invalidations.rst 与 service-2.json。当IsTruncated为true时可用--marker传入NextMarker继续翻页。借助等待器自动化等待失效完成在脚本化场景中反复手动执行get-invalidation检查Status并不优雅。AWS CLI 为 CloudFront 提供了内置的**等待器waiter**能力aws cloudfront wait invalidation-completed会以固定间隔轮询GetInvalidation直到Invalidation.Status Completed或达到最大尝试次数。这一行为在 waiters-2.json 中有明确定义轮询间隔delay20 秒最大尝试次数maxAttempts30即最长约 10 分钟成功判定Invalidation.Status等于Completed底层操作GetInvalidation即get-invalidation对应的 API。用法示例aws cloudfront wait invalidation-completed \ --id I2J0I21PCUYOIK \ --distribution-id EDFDVBD6EXAMPLE该命令不会输出内容仅在任务完成后返回超时则报错退出。由于等待器基于GetInvalidation实现其成功语义与get-invalidation的Status字段完全一致二者可以无缝衔接——先创建再等待然后放心地让流量回源。深入理解 InvalidationBatch 与 CallerReferenceInvalidationBatch 的结构约束从 service-2.json 可以看到InvalidationBatch结构由Paths与CallerReference两个必填字段构成Paths要失效的对象集合。Quantity必填且需与Items长度一致Items中的每个路径必须以/开头可用通配符*做目录级失效例如/images/*表示失效/images/下所有对象。CallerReference调用方引用是防重放机制的核心。服务模型明确说明每次新建失效请求时都应指定一个新值推荐使用时间戳如果以相同CallerReference提交内容完全一致的请求CloudFront不会创建新任务而是返回先前创建的任务信息如果CallerReference相同但路径内容不同则返回InvalidationBatchAlreadyExists错误。这就是为什么 AWS CLI 默认在--paths模式下用cli-时间戳-随机数自动生成引用保证几乎不可能碰撞重复见 cloudfront.py 的unique_string实现。当你在 JSON 文件方式中自行指定CallerReference时需要自行承担唯一性管理。从查询结果反推任务元信息因为get-invalidation返回的是完整的失效任务定义Invalidation结构而不只是状态所以你可以从一次查询中同时获得该任务影响的确切路径清单Paths.Items与数量Paths.Quantity当时提交的CallerReference可用于审计、去重或与自己的发布流水线记录对齐任务的创建时间CreateTime与当前状态Status。这对于排障和审计非常实用例如发现某个路径的缓存没有及时更新可以直接查询对应失效任务的Status与CreateTime判断任务是否早已完成Completed、还是仍在进行InProgress或是从未提交成功。常见问题与排障建议Invalidation返回InProgress很长时间失效任务从提交到在全部边缘节点生效通常需要数分钟。可结合等待器轮询或对比CreateTime与当前时间判断是否超出合理范围。忘记失效任务 ID先用list-invalidations按分发列出所有任务从Items中定位Id后再调用get-invalidation。路径不生效检查Paths.Items中的路径是否以/开头是否使用了正确的通配符确认该路径确实属于--distribution-id指向的分发。报AccessDenied/NoSuchDistribution/NoSuchInvalidation确认 IAM 权限包含cloudfront:GetInvalidation并核对分发 ID 与任务 ID 拼写无误。小结aws cloudfront get-invalidation是 CloudFront 缓存失效运维中的关键查询命令。通过本文你可以看到一条清晰的链路用create-invalidation创建失效任务--paths快捷模式或--invalidation-batchJSON 文件模式用get-invalidation按 ID 查询单个任务的Status、路径清单、CallerReference与CreateTime用list-invalidations回顾分发下全部任务并获取 ID用aws cloudfront wait invalidation-completed自动化等待任务完成。其中CallerReference的防重放语义、InvalidationBatch的必填约束以及等待器对GetInvalidation的轮询逻辑都有本仓库的源码与模型文件可查证命令示例见 awscli/examples/cloudfront/get-invalidation.rst 与 awscli/examples/cloudfront/create-invalidation.rstCLI 层参数定制见 awscli/customizations/cloudfront.py服务模型与等待器定义见 awscli/botocore/data/cloudfront/2020-05-31/。掌握这套命令组合即可在生产环境中准确、可审计地管理 CloudFront 缓存失效任务。【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AWS CLI 实战：使用 `cloudfront get-invalidation` 查询 CloudFront 缓存失效任务状态
AWS CLI 实战使用cloudfront get-invalidation查询 CloudFront 缓存失效任务状态【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli本篇技术指南以 AWS CLI 的aws cloudfront get-invalidation命令为核心系统讲解如何按失效任务 IDInvalidation ID查询 CloudFront 分发Distribution上某次缓存失效操作的详细信息包括任务状态、路径清单、批量请求引用与创建时间。文章同时结合本仓库aws-cli中的命令示例、服务模型service-2.json与等待器waiters-2.json配置为你串起创建失效 → 查询状态 → 等待完成 → 批量列表的完整操作闭环。读完本文你将掌握通过命令行获取任意 CloudFront 失效任务状态的能力并理解失效批次InvalidationBatch与调用方引用CallerReference的底层语义。为什么需要查询缓存失效任务CloudFront 是内容分发网络CDN边缘节点会缓存你的静态资源。当源站上的文件更新后缓存中的旧版本可能仍被客户端命中。此时可以通过**失效Invalidation**机制主动通知 CloudFront 把指定路径的缓存对象作废让后续请求回源拉取最新内容。失效操作是异步的create-invalidation提交后任务会经历InProgress状态直到边缘节点完成清理后才变为Completed。因此你需要一种手段随时确认任务进展——这正是aws cloudfront get-invalidation的用途给定分发 ID 与失效任务 ID返回该任务的最新状态与完整定义。从本仓库的命令行示例 get-invalidation.rst 可以看到它的典型用法aws cloudfront get-invalidation --id I2J0I21PCUYOIK --distribution-id EDFDVBD6EXAMPLE命令用法与参数说明get-invalidation是 AWS CLI 的 CloudFront 命令族中的只读查询命令需要两个必选参数参数类型必选说明--distribution-idString是CloudFront 分发的 ID例如EDFDVBD6EXAMPLE用于定位具体分发--idString是失效任务invalidation的标识符例如I2J0I21PCUYOIK用于定位具体失效任务在底层服务模型中这两个参数分别对应GetInvalidationRequest的DistributionId与Id字段且都会被放入请求 URI 的路径中location: uri详见 service-2.json。也就是说该请求本质上是对以下 REST 端点的调用GET /2020-05-31/distribution/{DistributionId}/invalidation/{Id}典型输出与字段解读命令返回的是一个Invalidation结构体GetInvalidationResult的 payload 直接是该结构见 service-2.json。以下为 get-invalidation.rst 中的完整输出示例{ Invalidation: { Status: Completed, InvalidationBatch: { Paths: { Items: [ /example-path/example-file.jpg, /example-path/example-file-2.jpg ], Quantity: 2 }, CallerReference: cli-example }, Id: I2J0I21PCUYOIK, CreateTime: 2019-12-05T18:40:49.413Z } }对照 service-2.json 中的Invalidation结构定义输出字段含义如下Id失效任务的唯一标识符。由create-invalidation创建时生成也是你后续在--id参数中使用的值。Status任务当前状态。当失效批次执行完毕时为Completed模型中明确说明When the invalidation batch is finished, the status isCompleted执行中则为InProgress。CreateTime失效请求首次提交的时间戳UTCISO 8601 格式例如2019-12-05T18:40:49.413Z。InvalidationBatch本次失效请求的批次定义包含两部分Paths本次要作废的对象路径列表与数量。Items路径字符串数组路径以/开头代表分发根目录下的对象目录失效以/*结尾如/images/*。Quantity路径数量必须与Items实际个数一致模型将其定义为必填字段required: [Quantity]见 service-2.json。CallerReference调用方引用用于唯一标识一次失效请求防止重复提交详见下文。需要注意的是Invalidation结构的Id、Status、CreateTime、InvalidationBatch四个字段在服务模型中均为必填required因此查询成功时输出结构始终完整。从创建到查询完整操作链路get-invalidation通常不会单独使用而是与create-invalidation和list-invalidations配合构成完整的失效任务生命周期管理。以下流程可以同时参考本仓库的 create-invalidation.rst 与 list-invalidations.rst。第一步创建失效任务aws cloudfront create-invalidation \ --distribution-id EDFDVBD6EXAMPLE \ --paths /example-path/example-file.jpg /example-path/example-file2.png注意这里的--paths是 AWS CLI 对 CloudFront 命令的自定义参数。在 cloudfront.py 的实现中PathsArgument接收空格分隔的多个路径并在底层自动组装成InvalidationBatchCallerReference由unique_string()自动生成形如cli-1575570291-670203即cli- 时间戳 随机数见 cloudfront.pyPaths.Quantity自动取路径个数。该参数与--invalidation-batchJSON 文件方式互斥源码通过validate_mutually_exclusive_handler([invalidation_batch], [paths])强制约束见 cloudfront.py。创建响应中的Id例如I1JLWSDAP8FU89与Status通常为InProgress就是你后续查询的输入。如果你想自行控制CallerReference或想通过文件管理大量路径也可以用 JSON 文件方式aws cloudfront create-invalidation \ --distribution-id EDFDVBD6EXAMPLE \ --invalidation-batch file://inv-batch.jsoninv-batch.json内容{ Paths: { Quantity: 2, Items: [ /example-path/example-file.jpg, /example-path/example-file2.png ] }, CallerReference: cli-example }第二步按 ID 查询任务状态拿到任务 ID 后即可执行本文主角命令aws cloudfront get-invalidation --id I2J0I21PCUYOIK --distribution-id EDFDVBD6EXAMPLE返回的Status字段是判断任务是否完成的依据InProgress表示边缘节点仍在处理Completed表示失效已完成。配合后续章节的等待器可以自动化这一判断。第三步列出某分发的全部失效任务如果需要回顾某分发下所有失效任务的 ID例如忘记记录某个任务 ID可用list-invalidationsaws cloudfront list-invalidations --distribution-id EDFDVBD6EXAMPLE返回结构InvalidationList中包含ItemsInvalidationSummary列表每项含Id、Status、CreateTime、Quantity总数、Marker/NextMarker/IsTruncated分页游标与MaxItems本次返回上限等字段见 list-invalidations.rst 与 service-2.json。当IsTruncated为true时可用--marker传入NextMarker继续翻页。借助等待器自动化等待失效完成在脚本化场景中反复手动执行get-invalidation检查Status并不优雅。AWS CLI 为 CloudFront 提供了内置的**等待器waiter**能力aws cloudfront wait invalidation-completed会以固定间隔轮询GetInvalidation直到Invalidation.Status Completed或达到最大尝试次数。这一行为在 waiters-2.json 中有明确定义轮询间隔delay20 秒最大尝试次数maxAttempts30即最长约 10 分钟成功判定Invalidation.Status等于Completed底层操作GetInvalidation即get-invalidation对应的 API。用法示例aws cloudfront wait invalidation-completed \ --id I2J0I21PCUYOIK \ --distribution-id EDFDVBD6EXAMPLE该命令不会输出内容仅在任务完成后返回超时则报错退出。由于等待器基于GetInvalidation实现其成功语义与get-invalidation的Status字段完全一致二者可以无缝衔接——先创建再等待然后放心地让流量回源。深入理解 InvalidationBatch 与 CallerReferenceInvalidationBatch 的结构约束从 service-2.json 可以看到InvalidationBatch结构由Paths与CallerReference两个必填字段构成Paths要失效的对象集合。Quantity必填且需与Items长度一致Items中的每个路径必须以/开头可用通配符*做目录级失效例如/images/*表示失效/images/下所有对象。CallerReference调用方引用是防重放机制的核心。服务模型明确说明每次新建失效请求时都应指定一个新值推荐使用时间戳如果以相同CallerReference提交内容完全一致的请求CloudFront不会创建新任务而是返回先前创建的任务信息如果CallerReference相同但路径内容不同则返回InvalidationBatchAlreadyExists错误。这就是为什么 AWS CLI 默认在--paths模式下用cli-时间戳-随机数自动生成引用保证几乎不可能碰撞重复见 cloudfront.py 的unique_string实现。当你在 JSON 文件方式中自行指定CallerReference时需要自行承担唯一性管理。从查询结果反推任务元信息因为get-invalidation返回的是完整的失效任务定义Invalidation结构而不只是状态所以你可以从一次查询中同时获得该任务影响的确切路径清单Paths.Items与数量Paths.Quantity当时提交的CallerReference可用于审计、去重或与自己的发布流水线记录对齐任务的创建时间CreateTime与当前状态Status。这对于排障和审计非常实用例如发现某个路径的缓存没有及时更新可以直接查询对应失效任务的Status与CreateTime判断任务是否早已完成Completed、还是仍在进行InProgress或是从未提交成功。常见问题与排障建议Invalidation返回InProgress很长时间失效任务从提交到在全部边缘节点生效通常需要数分钟。可结合等待器轮询或对比CreateTime与当前时间判断是否超出合理范围。忘记失效任务 ID先用list-invalidations按分发列出所有任务从Items中定位Id后再调用get-invalidation。路径不生效检查Paths.Items中的路径是否以/开头是否使用了正确的通配符确认该路径确实属于--distribution-id指向的分发。报AccessDenied/NoSuchDistribution/NoSuchInvalidation确认 IAM 权限包含cloudfront:GetInvalidation并核对分发 ID 与任务 ID 拼写无误。小结aws cloudfront get-invalidation是 CloudFront 缓存失效运维中的关键查询命令。通过本文你可以看到一条清晰的链路用create-invalidation创建失效任务--paths快捷模式或--invalidation-batchJSON 文件模式用get-invalidation按 ID 查询单个任务的Status、路径清单、CallerReference与CreateTime用list-invalidations回顾分发下全部任务并获取 ID用aws cloudfront wait invalidation-completed自动化等待任务完成。其中CallerReference的防重放语义、InvalidationBatch的必填约束以及等待器对GetInvalidation的轮询逻辑都有本仓库的源码与模型文件可查证命令示例见 awscli/examples/cloudfront/get-invalidation.rst 与 awscli/examples/cloudfront/create-invalidation.rstCLI 层参数定制见 awscli/customizations/cloudfront.py服务模型与等待器定义见 awscli/botocore/data/cloudfront/2020-05-31/。掌握这套命令组合即可在生产环境中准确、可审计地管理 CloudFront 缓存失效任务。【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考