aws-cli 创建 AWS App Mesh 虚拟服务create-virtual-service 命令实操与参数剖析【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli本文以 aws-cli 仓库中 aws appmesh create-virtual-service 官方示例 为主体完整讲解如何通过命令行创建虚拟服务包括基于 virtual node 与 virtual router 两种 provider 的 JSON 输入文件、命令执行方式与典型输出结构。结合仓库内嵌的 App Mesh 服务模型与--cli-input-json参数的底层实现文章进一步剖析了每个字段的取值约束、参数合并优先级和幂等性机制帮助读者将示例真正落地到生产操作。虚拟服务与 create-virtual-service 命令概览在 AWS App Mesh 中虚拟服务virtual service是对真实服务的一层抽象它由一个 virtual node 直接提供或者经由一个 virtual router 间接提供。依赖方服务只需按virtualServiceName发起调用请求就会路由到该虚拟服务指定的 provider 上。这正是示例文档开头给出的定义。从仓库中内嵌的 App Mesh 服务模型 service-2.json 可以确认CreateVirtualService操作的协议细节协议为rest-jsonHTTP 方法为PUT请求 URI 为/v20190125/meshes/{meshName}/virtualServices该操作在模型中被标记为idempotent: true即重复提交相同请求不会产生副作用这与下文clientToken幂等令牌参数相呼应模型声明了 8 种可能的错误类型NotFoundException、BadRequestException、ConflictException、TooManyRequestsException、ForbiddenException、ServiceUnavailableException、InternalServerErrorException和LimitExceededException。其中ConflictException通常对应“同名虚拟服务已存在”NotFoundException通常对应 mesh 或 provider 资源不存在。由于虚拟服务的spec结构嵌套较深aws-cli 提供了--cli-input-json参数允许用一份 JSON 文件或 JSON 字符串作为整个命令的输入。下面的两个示例正是官方文档中给出的标准用法。示例一以 virtual node 作为 provider 创建虚拟服务这是示例文档中的 Example 1。先将输入写入create-virtual-service-virtual-node.json然后执行命令aws appmesh create-virtual-service \ --cli-input-json file://create-virtual-service-virtual-node.json输入文件create-virtual-service-virtual-node.json内容如下{ meshName: app1, spec: { provider: { virtualNode: { virtualNodeName: vnServiceA } } }, virtualServiceName: serviceA.svc.cluster.local }三个顶层字段与模型中的必填项一一对应CreateVirtualServiceInput的required列表恰好是meshName、spec、virtualServiceName即virtualServiceName与meshName、spec同为必填参数缺一不可。spec.provider.virtualNode.virtualNodeName对应的VirtualNodeServiceProvider结构体中virtualNodeName也是必填成员其底层类型为ResourceName长度约束为 1255 字符。命令执行后的典型输出为{ virtualService: { meshName: app1, metadata: { arn: arn:aws:appmesh:us-east-1:123456789012:mesh/app1/virtualService/serviceA.svc.cluster.local, createdAt: 1563810859.474, lastUpdatedAt: 1563810967.179, uid: a1b2c3d4-5678-90ab-cdef-11111EXAMPLE, version: 2 }, spec: { provider: { virtualNode: { virtualNodeName: vnServiceA } } }, status: { status: ACTIVE }, virtualServiceName: serviceA.svc.cluster.local } }结合 service-2.json 中VirtualServiceData与ResourceMetadata的定义可以解读输出中的关键字段arn资源的完整 ARN格式为arn:aws:appmesh:region:account:mesh/meshName/virtualService/virtualServiceName后续用其他命令引用该资源时可直接使用createdAt/lastUpdatedAtUnix 秒级时间戳表示资源的创建与最近更新时间uid资源唯一标识符version资源版本号。模型文档明确说明“资源创建时版本为 1每次更新后版本号递增”。注意上面这个输出中version为 2 且createdAt与lastUpdatedAt不相等——从该字段语义看这说明该虚拟服务在示例中被更新过一次是模型约束的直接体现status.status取值枚举为ACTIVE、INACTIVE、DELETED三种。另外需要注意2019-01-25 版本模型的ResourceMetadata必填成员还包括meshOwner与resourceOwner用于 mesh 共享cross-account sharing场景示例文档中的输出为精简展示实际返回中会包含这两个账户 ID 字段。示例二以 virtual router 作为 provider 创建虚拟服务示例文档的 Example 2 演示了另一种 provider 类型virtual router。命令形式相同只是 JSON 文件不同aws appmesh create-virtual-service \ --cli-input-json file://create-virtual-service-virtual-router.jsoncreate-virtual-service-virtual-router.json内容如下{ meshName: app1, spec: { provider: { virtualRouter: { virtualRouterName: vrServiceB } } }, virtualServiceName: serviceB.svc.cluster.local }输出结构上与示例一完全同构仅provider换成了virtualRouter分支{ virtualService: { meshName: app1, metadata: { arn: arn:aws:appmesh:us-east-1:123456789012:mesh/app1/virtualService/serviceB.svc.cluster.local, createdAt: 1563908363.999, lastUpdatedAt: 1563908363.999, uid: a1b2c3d4-5678-90ab-cdef-11111EXAMPLE, version: 1 }, spec: { provider: { virtualRouter: { virtualRouterName: vrServiceB } } }, status: { status: ACTIVE }, virtualServiceName: serviceB.svc.cluster.local } }这里version为 1 且createdAt等于lastUpdatedAt说明这是刚创建、尚未更新过的资源。对比示例一version 为 2恰好可以印证前面关于metadata.version的解读。选择 virtual node 还是 virtual router 作为 provider取决于服务拓扑如果虚拟服务直接指向一组后端端点用 virtual node如果需要在虚拟服务后面再做一层路由分发例如灰度、按头部分流则指向 virtual router。示例文档在结尾提示读者参考 AWS App Mesh 用户指南中关于 Virtual Services 与 Virtual Nodes 的章节做进一步学习。输入参数全表必填项与可选项将两个示例合并来看--cli-input-json的 JSON 完整覆盖了CreateVirtualServiceInput结构体的所有成员。按模型定义整理如下字段必填说明meshName是虚拟服务所属的 mesh 名称底层类型为ResourceName长度 1255 字符请求中它会被放入 URI 路径locationName: meshNamevirtualServiceName是虚拟服务名称。示例使用serviceA.svc.cluster.local这种类 Kubernetes DNS 风格命名调用方即以该名字寻址spec是虚拟服务规格其内部provider为 union 类型virtualNode与virtualRouter二选一只能指定一个clientToken否幂等令牌。模型文档说明其为“你提供的唯一、大小写敏感的标识符用于保证请求的幂等性最多 36 个字母、数字、连字符和下划线”且被标记为idempotencyToken。重试失败请求时携带相同clientToken可避免重复创建meshOwner否mesh 拥有者的账户 ID。若要在他人的 mesh 中创建资源该账户必须先将 mesh 共享给你的账户否则请求会被拒绝tags否标签列表用于分类和组织资源。模型约束为最多 50 个标签标签键最长 128 字符标签值最长 256 字符关于spec.provider的 union 语义值得强调在 service-2.json 中VirtualServiceProvider被显式声明为union: true即virtualNode和virtualRouter两个分支互斥。如果在同一份 JSON 中同时给出两者属于非法输入实际使用中应选择其中一个。--cli-input-json与file://前缀的底层实现示例中--cli-input-json file://create-virtual-service-virtual-node.json的写法在 aws-cli 源码中有清晰的实现链路理解它有助于排查“为什么 JSON 没生效”这类问题。第一步参数注册。cliinputjson.py 中的register_cli_input_json在building-argument-table事件上把cli-input-json参数加入几乎所有服务操作带outfile流式输出的操作除外。该参数自带 help 文案说明了核心语义JSON 格式应与--generate-cli-skeleton生成的骨架一致如果命令行上同时提供了其他参数CLI 参数会覆盖 JSON 中对应的值且 JSON 中的值按字面量处理不能用于传二进制数据。第二步取值与文件读取。在add_to_call_parameters方法中CLI 通过 paramfile.py 的get_paramfile(input_json, LOCAL_PREFIX_MAP)解析取值前缀匹配表LOCAL_PREFIX_MAP只认file://和fileb://两种本地前缀分别为文本与二进制读取。file://后的路径会先经过os.path.expandvars和os.path.expanduser展开支持环境变量与~写法。若值不带识别前缀则被直接当作 JSON 字符串处理因此--cli-input-json {meshName: app1, ...}的内联写法同样可行。若 JSON 解析失败ValueError会抛出ParamError错误信息同时包含解析错误和收到的原始 JSON 串方便定位。第三步参数合并。_update_call_parameters的逻辑是遍历 JSON 的顶层键只有当该键尚未出现在call_parameters中时才写入——这就是“命令行参数优先于 JSON”的实现方式命令行已解析出的参数先就位JSON 只补全缺失的键。因此在实践中可以放心混用两种写法例如aws appmesh create-virtual-service \ --mesh-name app1 \ --cli-input-json file://create-virtual-service-virtual-node.json此时meshName以命令行值为准spec与virtualServiceName从 JSON 文件补齐。该机制有完整的测试覆盖参见 test_cliinputjson.py 中对参数覆盖、非法 JSON、文件前缀等场景的用例参数文件加载逻辑本身的测试见 test_paramfile.py。输出结构与后续操作CreateVirtualServiceOutput的必填成员只有一个virtualService其结构即上文解读过的VirtualServiceDatameshName、metadata、spec、status、virtualServiceName均必填。也就是说创建成功后拿到的就是虚拟服务的完整描述后续可以用同一份结构直接作为update-virtual-service的输入基础。围绕虚拟服务的生命周期仓库示例目录下还提供了配套命令的示例可与本文示例串联使用create-virtual-node.rst创建作为 provider 的 virtual nodecreate-virtual-router.rst创建作为 provider 的 virtual routerdescribe-virtual-service.rst查询刚创建的虚拟服务核对status是否达到ACTIVEupdate-virtual-service.rst修改 provider 指向执行后metadata.version会递增list-virtual-services.rst列出 mesh 内全部虚拟服务delete-virtual-service.rst删除虚拟服务create-mesh.rst / describe-mesh.rst前置的 mesh 准备与确认。从源码结构看一个可复现的最小操作序列是先确保名为app1的 mesh 已存在aws appmesh describe-mesh --mesh-name app1再准备本文示例一的 JSON 文件并执行create-virtual-service最后用describe-virtual-service校验status.status ACTIVE。若命令返回NotFoundException或ConflictException优先检查 mesh 名称、provider 资源名是否真实存在、以及虚拟服务名是否已被占用。小结create-virtual-service的输入围绕三个必填项展开meshName、virtualServiceName、spec其中spec.provider是 unionvirtualNode与virtualRouter二选一官方示例给出的两个 JSON 输入文件分别覆盖了两种 provider 场景输出中的metadataarn、uid、version与statusACTIVE/INACTIVE/DELETED是后续运维操作的关键依据--cli-input-json支持file://本地文件与内联 JSON 两种形态命令行参数优先于 JSON 值clientToken可保障重试幂等以上结论均有仓库内依据API 约束来自 App Mesh 2019-01-25 服务模型--cli-input-json行为来自 cliinputjson.py 与 paramfile.py 的实现示例正文来自 create-virtual-service.rst。【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
aws-cli 创建 AWS App Mesh 虚拟服务create-virtual-service 命令实操与参数剖析【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli本文以 aws-cli 仓库中 aws appmesh create-virtual-service 官方示例 为主体完整讲解如何通过命令行创建虚拟服务包括基于 virtual node 与 virtual router 两种 provider 的 JSON 输入文件、命令执行方式与典型输出结构。结合仓库内嵌的 App Mesh 服务模型与--cli-input-json参数的底层实现文章进一步剖析了每个字段的取值约束、参数合并优先级和幂等性机制帮助读者将示例真正落地到生产操作。虚拟服务与 create-virtual-service 命令概览在 AWS App Mesh 中虚拟服务virtual service是对真实服务的一层抽象它由一个 virtual node 直接提供或者经由一个 virtual router 间接提供。依赖方服务只需按virtualServiceName发起调用请求就会路由到该虚拟服务指定的 provider 上。这正是示例文档开头给出的定义。从仓库中内嵌的 App Mesh 服务模型 service-2.json 可以确认CreateVirtualService操作的协议细节协议为rest-jsonHTTP 方法为PUT请求 URI 为/v20190125/meshes/{meshName}/virtualServices该操作在模型中被标记为idempotent: true即重复提交相同请求不会产生副作用这与下文clientToken幂等令牌参数相呼应模型声明了 8 种可能的错误类型NotFoundException、BadRequestException、ConflictException、TooManyRequestsException、ForbiddenException、ServiceUnavailableException、InternalServerErrorException和LimitExceededException。其中ConflictException通常对应“同名虚拟服务已存在”NotFoundException通常对应 mesh 或 provider 资源不存在。由于虚拟服务的spec结构嵌套较深aws-cli 提供了--cli-input-json参数允许用一份 JSON 文件或 JSON 字符串作为整个命令的输入。下面的两个示例正是官方文档中给出的标准用法。示例一以 virtual node 作为 provider 创建虚拟服务这是示例文档中的 Example 1。先将输入写入create-virtual-service-virtual-node.json然后执行命令aws appmesh create-virtual-service \ --cli-input-json file://create-virtual-service-virtual-node.json输入文件create-virtual-service-virtual-node.json内容如下{ meshName: app1, spec: { provider: { virtualNode: { virtualNodeName: vnServiceA } } }, virtualServiceName: serviceA.svc.cluster.local }三个顶层字段与模型中的必填项一一对应CreateVirtualServiceInput的required列表恰好是meshName、spec、virtualServiceName即virtualServiceName与meshName、spec同为必填参数缺一不可。spec.provider.virtualNode.virtualNodeName对应的VirtualNodeServiceProvider结构体中virtualNodeName也是必填成员其底层类型为ResourceName长度约束为 1255 字符。命令执行后的典型输出为{ virtualService: { meshName: app1, metadata: { arn: arn:aws:appmesh:us-east-1:123456789012:mesh/app1/virtualService/serviceA.svc.cluster.local, createdAt: 1563810859.474, lastUpdatedAt: 1563810967.179, uid: a1b2c3d4-5678-90ab-cdef-11111EXAMPLE, version: 2 }, spec: { provider: { virtualNode: { virtualNodeName: vnServiceA } } }, status: { status: ACTIVE }, virtualServiceName: serviceA.svc.cluster.local } }结合 service-2.json 中VirtualServiceData与ResourceMetadata的定义可以解读输出中的关键字段arn资源的完整 ARN格式为arn:aws:appmesh:region:account:mesh/meshName/virtualService/virtualServiceName后续用其他命令引用该资源时可直接使用createdAt/lastUpdatedAtUnix 秒级时间戳表示资源的创建与最近更新时间uid资源唯一标识符version资源版本号。模型文档明确说明“资源创建时版本为 1每次更新后版本号递增”。注意上面这个输出中version为 2 且createdAt与lastUpdatedAt不相等——从该字段语义看这说明该虚拟服务在示例中被更新过一次是模型约束的直接体现status.status取值枚举为ACTIVE、INACTIVE、DELETED三种。另外需要注意2019-01-25 版本模型的ResourceMetadata必填成员还包括meshOwner与resourceOwner用于 mesh 共享cross-account sharing场景示例文档中的输出为精简展示实际返回中会包含这两个账户 ID 字段。示例二以 virtual router 作为 provider 创建虚拟服务示例文档的 Example 2 演示了另一种 provider 类型virtual router。命令形式相同只是 JSON 文件不同aws appmesh create-virtual-service \ --cli-input-json file://create-virtual-service-virtual-router.jsoncreate-virtual-service-virtual-router.json内容如下{ meshName: app1, spec: { provider: { virtualRouter: { virtualRouterName: vrServiceB } } }, virtualServiceName: serviceB.svc.cluster.local }输出结构上与示例一完全同构仅provider换成了virtualRouter分支{ virtualService: { meshName: app1, metadata: { arn: arn:aws:appmesh:us-east-1:123456789012:mesh/app1/virtualService/serviceB.svc.cluster.local, createdAt: 1563908363.999, lastUpdatedAt: 1563908363.999, uid: a1b2c3d4-5678-90ab-cdef-11111EXAMPLE, version: 1 }, spec: { provider: { virtualRouter: { virtualRouterName: vrServiceB } } }, status: { status: ACTIVE }, virtualServiceName: serviceB.svc.cluster.local } }这里version为 1 且createdAt等于lastUpdatedAt说明这是刚创建、尚未更新过的资源。对比示例一version 为 2恰好可以印证前面关于metadata.version的解读。选择 virtual node 还是 virtual router 作为 provider取决于服务拓扑如果虚拟服务直接指向一组后端端点用 virtual node如果需要在虚拟服务后面再做一层路由分发例如灰度、按头部分流则指向 virtual router。示例文档在结尾提示读者参考 AWS App Mesh 用户指南中关于 Virtual Services 与 Virtual Nodes 的章节做进一步学习。输入参数全表必填项与可选项将两个示例合并来看--cli-input-json的 JSON 完整覆盖了CreateVirtualServiceInput结构体的所有成员。按模型定义整理如下字段必填说明meshName是虚拟服务所属的 mesh 名称底层类型为ResourceName长度 1255 字符请求中它会被放入 URI 路径locationName: meshNamevirtualServiceName是虚拟服务名称。示例使用serviceA.svc.cluster.local这种类 Kubernetes DNS 风格命名调用方即以该名字寻址spec是虚拟服务规格其内部provider为 union 类型virtualNode与virtualRouter二选一只能指定一个clientToken否幂等令牌。模型文档说明其为“你提供的唯一、大小写敏感的标识符用于保证请求的幂等性最多 36 个字母、数字、连字符和下划线”且被标记为idempotencyToken。重试失败请求时携带相同clientToken可避免重复创建meshOwner否mesh 拥有者的账户 ID。若要在他人的 mesh 中创建资源该账户必须先将 mesh 共享给你的账户否则请求会被拒绝tags否标签列表用于分类和组织资源。模型约束为最多 50 个标签标签键最长 128 字符标签值最长 256 字符关于spec.provider的 union 语义值得强调在 service-2.json 中VirtualServiceProvider被显式声明为union: true即virtualNode和virtualRouter两个分支互斥。如果在同一份 JSON 中同时给出两者属于非法输入实际使用中应选择其中一个。--cli-input-json与file://前缀的底层实现示例中--cli-input-json file://create-virtual-service-virtual-node.json的写法在 aws-cli 源码中有清晰的实现链路理解它有助于排查“为什么 JSON 没生效”这类问题。第一步参数注册。cliinputjson.py 中的register_cli_input_json在building-argument-table事件上把cli-input-json参数加入几乎所有服务操作带outfile流式输出的操作除外。该参数自带 help 文案说明了核心语义JSON 格式应与--generate-cli-skeleton生成的骨架一致如果命令行上同时提供了其他参数CLI 参数会覆盖 JSON 中对应的值且 JSON 中的值按字面量处理不能用于传二进制数据。第二步取值与文件读取。在add_to_call_parameters方法中CLI 通过 paramfile.py 的get_paramfile(input_json, LOCAL_PREFIX_MAP)解析取值前缀匹配表LOCAL_PREFIX_MAP只认file://和fileb://两种本地前缀分别为文本与二进制读取。file://后的路径会先经过os.path.expandvars和os.path.expanduser展开支持环境变量与~写法。若值不带识别前缀则被直接当作 JSON 字符串处理因此--cli-input-json {meshName: app1, ...}的内联写法同样可行。若 JSON 解析失败ValueError会抛出ParamError错误信息同时包含解析错误和收到的原始 JSON 串方便定位。第三步参数合并。_update_call_parameters的逻辑是遍历 JSON 的顶层键只有当该键尚未出现在call_parameters中时才写入——这就是“命令行参数优先于 JSON”的实现方式命令行已解析出的参数先就位JSON 只补全缺失的键。因此在实践中可以放心混用两种写法例如aws appmesh create-virtual-service \ --mesh-name app1 \ --cli-input-json file://create-virtual-service-virtual-node.json此时meshName以命令行值为准spec与virtualServiceName从 JSON 文件补齐。该机制有完整的测试覆盖参见 test_cliinputjson.py 中对参数覆盖、非法 JSON、文件前缀等场景的用例参数文件加载逻辑本身的测试见 test_paramfile.py。输出结构与后续操作CreateVirtualServiceOutput的必填成员只有一个virtualService其结构即上文解读过的VirtualServiceDatameshName、metadata、spec、status、virtualServiceName均必填。也就是说创建成功后拿到的就是虚拟服务的完整描述后续可以用同一份结构直接作为update-virtual-service的输入基础。围绕虚拟服务的生命周期仓库示例目录下还提供了配套命令的示例可与本文示例串联使用create-virtual-node.rst创建作为 provider 的 virtual nodecreate-virtual-router.rst创建作为 provider 的 virtual routerdescribe-virtual-service.rst查询刚创建的虚拟服务核对status是否达到ACTIVEupdate-virtual-service.rst修改 provider 指向执行后metadata.version会递增list-virtual-services.rst列出 mesh 内全部虚拟服务delete-virtual-service.rst删除虚拟服务create-mesh.rst / describe-mesh.rst前置的 mesh 准备与确认。从源码结构看一个可复现的最小操作序列是先确保名为app1的 mesh 已存在aws appmesh describe-mesh --mesh-name app1再准备本文示例一的 JSON 文件并执行create-virtual-service最后用describe-virtual-service校验status.status ACTIVE。若命令返回NotFoundException或ConflictException优先检查 mesh 名称、provider 资源名是否真实存在、以及虚拟服务名是否已被占用。小结create-virtual-service的输入围绕三个必填项展开meshName、virtualServiceName、spec其中spec.provider是 unionvirtualNode与virtualRouter二选一官方示例给出的两个 JSON 输入文件分别覆盖了两种 provider 场景输出中的metadataarn、uid、version与statusACTIVE/INACTIVE/DELETED是后续运维操作的关键依据--cli-input-json支持file://本地文件与内联 JSON 两种形态命令行参数优先于 JSON 值clientToken可保障重试幂等以上结论均有仓库内依据API 约束来自 App Mesh 2019-01-25 服务模型--cli-input-json行为来自 cliinputjson.py 与 paramfile.py 的实现示例正文来自 create-virtual-service.rst。【免费下载链接】aws-cliUniversal Command Line Interface for Amazon Web Services项目地址: https://gitcode.com/GitHub_Trending/aw/aws-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
