云原生后端开发工具微服务【免费下载链接】operator-sdkSDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding.项目地址https://gitcode.com/gh_mirrors/op/operator-sdk点击查看免费下载导读本篇文章基于 Operator SDK 仓库中的设计提案 proposals/ansible-operator-testing.mdStatus:implemented已落地实现系统讲解 Ansible Operator 如何接入 Operator SDK 的端到端e2e测试体系。文章以该提案的完整脉络为骨架结合仓库内正式文档 Testing Ansible Operators with Molecule 与相关版本变更记录从设计目标、解决方案、Molecule 场景结构、配置参数到实际编写测试任务完整还原了用 Molecule 测试 Ansible Operator的从设计到实践的闭环。读者读完后既能理解提案背后的设计取舍也能直接上手编写和运行 Ansible Operator 的端到端测试。一、BackgroundAnsible Operator 为何需要统一的测试框架Operator SDK 生态中的各类 OperatorGolang Operator、Helm Operator、Ansible Operator都应融入 SDK 统一的 e2e 测试框架。提案明确指出All operators should fit into the e2e testing framework used by operator-sdk, including Ansible Operator.在 ansible-operator-testing.md 提出之前Ansible Operator 缺少与test {local|cluster}子命令对接的测试能力。而 Ansible 生态本身已有成熟测试工具 —— Molecule其场景scenario机制非常适合承载 operator 的端到端测试需求。二、Goals 与 Non-Goals设计边界Goals目标为 Ansible Operator 增加test {local|cluster}e2e 测试子命令的支持与现有 Ansible 测试框架Molecule集成在 Ansible 生态内提供一致的测试体验保持现有test子命令的对外接口不变。Non-Goals非目标不为 Ansible 专门创建一套新的测试框架不允许 Ansible 用户编写非 Ansible 的测试。这一边界设计非常关键Operator SDK 选择的是借力而非自造轮子通过让 Molecule 承担测试编排职责既复用 Ansible 生态的既有资产又保证了test子命令接口的统一。三、Solution五项落地方案提案给出了五步解决方案构成了整个功能实现的骨架更新脚手架scaffolding可选地初始化 Molecule为 e2e 环境设置一个 Molecule 场景local与cluster场景可能行为不同。为 Molecule 创建 delegated driver委派驱动test local场景下负责在 Kubernetes 集群中创建必要资源namespace、CRDs、roles、rolebindings、operator deploymenttest cluster场景下不做任何资源创建依赖外部已有集群。添加自定义测试入口点entrypoint该入口点会先拉起 operator再运行对应的 Molecule 场景当 Ansible Operator 镜像以--enable-tests选项构建时该入口点会被包含进镜像。更新test local子命令当在 Ansible Operator 项目上下文中运行时触发对应场景的 Molecule 运行。更新test cluster子命令在 Ansible Operator 上下文中创建一个携带自定义测试入口点的 operator 部署在报告/终止行为上尽量与 Golang Operator 的对应实现保持一致。从仓库实现看这一方案已完全落地。在正式测试文档 testing-guide.md 中Ansible Operator 项目的标准目录结构已经包含molecule/目录与config/、Dockerfile、playbooks/、roles/、watches.yaml并列. ├── config ├── Dockerfile ├── Makefile ├── molecule ├── playbooks ├── PROJECT ├── requirements.yml ├── roles └── watches.yaml其中requirements.yml中声明的 Ansible 内容需要通过ansible-galaxy collection install -r requirements.yml安装。四、Molecule 场景结构default / cluster / test-local在 testing-guide.md 中可以看到molecule/目录下包含四个子目录default、test-local、cluster、templates。前三个各自构成一个 Molecule场景scenariotemplates目录则存放被多个场景复用的 Jinja 模板例如 operator 部署模板molecule/templates/operator.yaml.j2。每个场景的基本结构为. ├── molecule.yml ├── prepare.yml ├── converge.yml └── verify.ymlmolecule.ymlMolecule 的配置文件定义使用哪个驱动driver来搭建环境、相关配置、lint 规则及多种其他选项prepare.yml场景初始化阶段运行一次的 Ansible playbook用于一次性配置测试环境例如创建 operator 要监听的集群级CustomResourceDefinitionconverge.yml包含场景核心逻辑的 playbook。常规 Molecule 场景中它负责导入并运行对应 role对 Ansible Operator 而言它主要用于创建将 operator 部署进 Kubernetes 所需的资源verify.yml编写断言任务的 playbook用于验证集群状态是否符合预期。4.1 default 场景角色/playbook 的独立开发default 场景用于在 operator 上下文之外开发 Ansible role 或 playbook通过molecule test或molecule converge运行没有对应的operator-sdk命令。其结构为molecule/default ├── molecule.yml ├── prepare.yml ├── converge.yml └── verify.ymlmolecule.yml使用docker driver拉起一个 Kubernetes-in-Docker 容器默认在宿主机的 9443 端口暴露 API并指定若干prepare.yml与converge.yml使用的 inventory 与环境变量prepare.yml确保存在正确连接到 Kubernetes-in-Docker 集群的 kubeconfig 并映射到正确端口同时等待 Kubernetes API 就绪后才开始测试converge.yml导入并运行你的 role 或 playbookverify.yml放置验证集群状态的 Ansible 任务。default 场景运行时配置参数通过环境变量覆盖环境变量默认值用途KUBE_VERSION1.17要部署的 Kubernetes 版本TEST_CLUSTER_PORT9443宿主机上暴露 Kubernetes API 的端口TEST_OPERATOR_NAMESPACEosdk-testrole 运行的命名空间4.2 cluster 场景对现有集群做端到端测试cluster 场景针对已有的外部集群执行 operator 端到端测试。前提是 operator 镜像需要能被集群拉取可从镜像仓库获取。该场景会把 CRDs、RBAC 和 operator 部署进集群然后创建 CustomResource 实例并运行断言验证 operator 是否正确响应。通过molecule test或molecule converge运行同样没有对应的operator-sdk命令。其结构为molecule/default ├── molecule.yml ├── create.yml ├── prepare.yml ├── converge.yml ├── verify.yml └── destroy.ymlmolecule.yml使用delegated driver不额外拉起任何基础设施create.yml是一个空操作no-op但 delegated driver 必须要求它存在prepare.yml确保 CRD、命名空间和 RBAC 资源已存在于集群中converge.yml基于molecule/templates/operator.yaml.j2模板创建 operator 部署verify.yml默认创建一个 Custom Resource 并等待 reconciliation 成功完成同时内置了一个示例断言destroy.yml在运行结束时删除命名空间、RBAC 资源与 CRD。cluster 场景运行时配置参数环境变量默认值用途OPERATOR_IMAGE无必填部署 operator 到集群时使用的镜像OPERATOR_PULL_POLICYAlways部署 operator 时使用的拉取策略KUBECONFIG~/.kube/config被测集群的 kubeconfig 路径TEST_OPERATOR_NAMESPACEosdk-testrole 运行的命名空间4.3 test-local 场景免集群的完整端到端测试test-local 场景运行完整的端到端测试不需要现有集群或外部镜像仓库可运行在允许特权容器的 CI 环境如 Travis中。它会拉起 Kubernetes-in-Docker 集群、构建 operator、部署进集群然后创建 CR 实例并运行断言。通过molecule test -s local或molecule converge -s test-local运行后者运行结束后会保留环境。其结构为molecule/test-local ├── molecule.yml ├── prepare.yml ├── converge.yml └── verify.ymlmolecule.yml使用 docker driver 拉起 Kubernetes-in-Docker 容器挂载项目根目录并在宿主机 10443 端口暴露 API与 default 场景配置非常相似prepare.yml先运行 default 场景的prepare.yml确保 kubeconfig 存在、API 就绪再运行 cluster 场景的prepare.yml配置 CRDs 与 RBACconverge.yml连接到 Kubernetes-in-Docker 容器利用挂载的项目根目录就地构建 operator从而无需推送外部镜像仓库即可供集群使用随后基于molecule/templates/operator.yaml.j2模板确保集群中存在一份全新部署的 operatorverify.yml直接运行 cluster 场景的verify.yml—— test-local 与 cluster 场景的核心差异仅在于部署方式operator 行为并无不同。test-local 场景运行时配置参数环境变量默认值用途KUBE_VERSION1.17要部署的 Kubernetes 版本TEST_CLUSTER_PORT10443宿主机上暴露 Kubernetes API 的端口TEST_OPERATOR_NAMESPACEosdk-test部署 operator 及相关资源的命名空间4.4 converge 与 test 的区别开发阶段最常用的两个 Molecule 命令是molecule test与molecule convergemolecule test执行完整闭环 —— 拉起集群、准备环境、运行任务、最后拆除环境molecule converge更适合迭代开发两次运行之间保留环境缺点是测试期间可能污染环境运行molecule destroy即可重置。五、编写测试从任务到断言5.1 添加一个 Ansible 任务operator-sdk new生成的默认 operator 不做任何事因此先为它添加一个可验证的 Ansible 任务。以下示例创建一个带单个 key 的 ConfigMap写入roles/example/tasks/main.yml--- # tasks file for exampleapp - name: create Example configmap kubernetes.core.k8s: definition: apiVersion: v1 kind: ConfigMap metadata: name: test-data namespace: {{ ansible_operator_meta.namespace }} data: hello: world注意ansible_operator_meta.namespace是 Ansible Operator 为 role 注入的元数据变量用于获取当前 CR 所在命名空间是编写 operator role 时最常见的元数据用法。5.2 添加对应的测试断言operator 开始干活后在molecule/cluster/verify.yml中添加断言同时加一个 debug 消息查看 ConfigMap 内容--- - name: Verify hosts: localhost connection: local tasks: - debug: varcm vars: cm: {{ lookup(kubernetes.core.k8s, api_versionv1, kindConfigMap, namespacenamespace, resource_nametest-data) }} - assert: that: cm.data.hello world vars: cm: {{ lookup(kubernetes.core.k8s, api_versionv1, kindConfigMap, namespacenamespace, resource_nametest-data) }}这里通过kubernetes.core.k8slookup 插件从集群中按api_version、kind、namespace与resource_name查询资源再用 Ansible 的assert模块校验cm.data.hello world。至此 operator 已有真实行为、测试也有对应断言运行molecule test -s local即可验证一切正常。5.3 断言与失败模块Ansible 的assert与fail模块是编写 Ansible Operator 测试时最常用的断言与失败控制手段assert基于表达式断言that参数断言失败即任务失败进而终止场景fail显式触发失败可用于自定义失败消息或前置条件校验。六、Discussion / Further Investigation提案遗留的讨论点提案在解决方案之外还列出了一些待讨论/进一步调研的问题反映了设计时的真实权衡也帮助读者理解最终形态的取舍测试脚手架是否应该可选还是始终初始化测试从当前仓库的 project-layout.md 看Ansible 项目脚手架已默认包含molecule/目录答案落在了默认初始化一侧。能否轻松从 molecule 测试中访问deploy/资源这影响了 cluster 场景prepare.yml如何获取 CRDs 与 RBAC 清单的路径设计。如何分发自定义 molecule driver最终实现的场景统一采用 Molecule 内置的delegated driver而非自研驱动规避了分发问题。test local与test cluster是否应该是两个不同的 molecule 场景答案是肯定的test-local与cluster作为两个独立场景共存见 testing-guide.md且test-local的verify.yml直接复用 cluster 场景的 verify印证了两者部署方式不同、行为一致的定位。test local需要创建 CRD、role、SA 等所需权限运行 molecule提案提示若权限不足应尽力而为best effort不要因权限问题崩溃整个运行。test cluster以普通 operator 权限运行要求调用前已满足前置条件镜像可达、集群可用。七、实现状态与后续演进该提案在仓库中标记为implemented正式测试文档入口为 Testing Ansible Operators with Molecule。后续版本仍在持续完善该测试体系例如 v1.10.0 升级说明 记录了 Ansible 项目脚手架中 Kustomize 版本升级带来的molecule/default/prepare.yml内Set pull policy命令的适配v1.31.0 变更记录 则说明ansible/v1插件脚手架移除了community.kubernetescollection、将operator_sdk.utilcollection 从v0.4.0升级到v0.5.0并将molecule.yaml文件适配到molecule v5.1.0。这说明 Molecule 测试方案从提出至今始终随 Ansible 生态与 operator-sdk 插件体系同步演进。小结Operator SDK 通过Molecule 场景 delegated driver 自定义测试入口点的组合将 Ansible Operator 无缝接入test {local|cluster}e2e 测试框架default 场景服务角色开发cluster 场景面向真实集群test-local 场景实现免外部集群的完整闭环。对开发者而言只需按 testing-guide.md 在verify.yml中编写断言、以molecule test -s local驱动验证即可获得与 Golang Operator 对等的端到端测试体验。赞分享云原生后端开发工具微服务【免费下载链接】operator-sdkSDK for building Kubernetes applications. Provides high level APIs, useful abstractions, and project scaffolding.项目地址https://gitcode.com/gh_mirrors/op/operator-sdk点击查看免费下载相关推荐PhysicsLayout源码解析深入理解Android物理布局的实现机制PhysicsLayout源码解析深入理解Android物理布局的实现机制 PhysicsLayout是一个基于JBox2D物理引擎的Android布局库它RPCS3 游戏补丁安装完整指南从导入到汉化生效RPCS3 游戏补丁安装完整指南从导入到汉化生效 RPCS3 补丁是这款 PlayStation 3 模拟器的官方扩展机制你用它给游戏换上中文文本、修复运行虚拟化图形学调试器Edyn物理引擎架构设计从单线程到分布式系统的演进之路Edyn物理引擎架构设计从单线程到分布式系统的演进之路 Edyn物理引擎作为一款基于ECS实体 组件系统架构的实时物理引擎其核心设计理念是通过创新的架构云原生后端开发工具微服务上一篇音频分离技术新星Audio Separator 下一篇FreeKill UI设计秘籍使用QML创建精美三国杀界面的完整流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考