操作系统云原生安全【免费下载链接】bottlerocketAn operating system designed for hosting containers项目地址https://gitcode.com/gh_mirrors/bo/bottlerocket点击查看免费下载本指南以 Bottlerocket 仓库根目录下的 TESTING.md 为骨架系统讲解如何在本地运行 Bottlerocket 单元测试以及如何使用 TestSys 测试系统在真实云环境中执行端到端集成测试EKS、ECS、VMware 变体、版本迁移测试、工作负载测试与自定义测试类型。读完本文你将掌握cargo make测试任务体系、testsys 集群的搭建方法、Test.toml配置的层级覆盖规则以及各个变体的完整测试命令流程。测试体系概览两层测试策略Bottlerocket 的测试分为两个层次单元测试Unit Tests针对 Rust 源码级别的快速验证在本地即可执行用于检查具体函数与模块的正确性。集成测试Integration Tests将 Bottlerocket 作为完整操作系统运行起来在真实或近似真实的基础设施上验证系统行为由 testsys 命令行工具和测试系统协调完成。两者的关系正如 TESTING.md 所述单元测试只能带我们走这么远最终我们需要知道 Bottlerocket 作为一个完整系统是否能正确运行。单元测试cargo make unit-tests在仓库根目录执行以下命令即可运行全部单元测试cargo make unit-tests变体条件编译注意事项Bottlerocket 中部分代码会根据 variant变体进行条件编译因此某些测试不会被默认执行。除非你恰好想测试默认变体否则建议显式传入目标变体与架构cargo make \ -e BUILDSYS_VARIANTaws-ecs-2 \ -e BUILDSYS_ARCHx86_64 \ unit-tests其中BUILDSYS_VARIANT指定目标变体如aws-ecs-2、aws-k8s-1.32、vmware-k8s-1.31等BUILDSYS_ARCH指定架构x86_64或aarch64。从 Makefile.toml 可以看到unit-tests任务与仓库中几乎所有构建、测试任务一样通过run-twoliter转发给 Twoliter 工具执行确保本地使用的是与构建环境一致的测试入口。集成测试架构TestSys 与 testsys 集群TestSys 使用Kubernetes operator来测试 Bottlerocket。其核心架构要点如下operator 运行在一个与控制平面隔离的集群中该集群被称为testsys 集群control cluster当你启动一次 Bottlerocket 集成测试时testsys 集群中会启动若干 Pod 来执行下述流程testsys 测试系统负责协调整个生命周期依次完成创建集群或复用已有集群创建 Bottlerocket 实例运行针对集群与实例的测试终止 Bottlerocket 实例终止 Kubernetes 集群如需要。注意testsys 工具本体位于独立的 bottlerocket-test-system 仓库本仓库中的 Makefile.toml 提供了cargo make testsys任务作为统一入口。搭建测试环境EKS 方案规划中理论上 testsys 集群可以运行在任何具备必要授权与网络连通性的地方。官方计划提供在 EKS 中搭建 testsys 集群的完整指引与角色权限但角色相关工作仍在进行中请留意后续文档更新。使用临时 kind 集群推荐开发者工作流对开发者而言最快的方式是使用 [kind] 搭建一个临时的 testsys 集群。重要警告kind 只能用于你自己使用的临时 testsys 集群不要用它搭建长期存活的集群也不要搭建与他人共享的集群。Step 1创建 kind 集群kind create cluster --name testsys集群名称可以随意指定。Step 2导出 kubeconfig所有 testsys 相关的cargo make任务都会读取环境变量TESTSYS_KUBECONFIG。建议把 kubeconfig 写入一个尚不存在的路径export TESTSYS_KUBECONFIG${HOME}/testsys-kubeconfig.yaml kind get kubeconfig --name testsys $TESTSYS_KUBECONFIGStep 3安装 testsys 集群组件cargo make setup-testStep 4注入 AWS 凭证testsys 容器需要 AWS 凭证才能操作 AWS 资源。以下命令把当前默认配置的凭证作为 secret 加入集群仅适用于个人开发工作流切勿与共享集群混用cargo make testsys add secret map \ --name creds \ access-key-id$(aws configure get aws_access_key_id) \ secret-access-key$(aws configure get aws_secret_access_key)如果你使用命名 profile可以这样指定PROFILEYour desired profile name cargo make testsys add secret map \ --name creds \ access-key-id$(aws configure get aws_access_key_id --profile ${PROFILE}) \ secret-access-key$(aws configure get aws_secret_access_key --profile ${PROFILE})Step 5通过环境变量传递 secret 名称添加 secret 之后需要通过环境变量把 secret 名称告诉 testsysexport TESTSYS_AWS_SECRET_NAMEawsCredentialsName of your secret便捷入口cargo make testsys所有 testsys 命令都可以通过cargo make testsys arguments调用这样做可以避免本地安装了多个不同版本的 testsys 造成混乱——testsys 要求 controller 镜像与 agent 镜像版本一致。Bottlerocket 相关组件都位于testsys这个 Kubernetes namespace 中。运行集成测试Test.toml 配置cargo make支持通过环境变量配置大量参数但更推荐使用配置文件。配置文件名默认为Test.toml其查找与冲突检测逻辑见 Makefile.toml根目录与tests目录只能存在一份配置文件。例如可以根据变体需求指定实例类型[aws-k8s] # Set the default instance type for all aws-k8s variants instance-type m5.xlarge [aws-k8s-nvidia] # Override the instance type for nvidia aws-k8s variants instance-type g5g.2xlarge由于aws-k8s-nvidia属于FAMILY-FLAVOR级别配置它会优先于FAMILY级别的aws-k8s配置。还可以为自定义测试类型创建独立配置表。假设自定义测试类型名为foo上面的配置可以扩展为[aws-k8s] # Set the default instance type for all aws-k8s variants instance-type m5.xlarge [aws-k8s.configuration.foo] # Set the default instance type for all aws-k8s variants when TESTSYS_TESTfoo is set instance-type m5.8xlarge [aws-k8s-nvidia] # Override the instance type for nvidia aws-k8s variants instance-type g5g.2xlarge [aws-k8s-nvidia.configuration.foo] # Override the instance type for nvidia aws-k8s variants when TESTSYS_TESTfoo is set instance-type g5g.8xlarge测试类型与配置选择测试类型通过TESTSYS_TEST环境变量指定默认为quick。根据 Makefile.toml 中的定义quick快速测试通常只验证实例是否可达conformance官方认证一致性测试可能耗时长达 3 小时migration升级/降级测试详见下文迁移测试章节workload以编排容器形式运行的工作负载测试自定义测试名通过Test.toml的[family.configuration.name]表提供专属配置。变体差异不同 Bottlerocket 变体需要不同的测试实现Kubernetes 变体使用 [Sonobuoy] 运行 K8s E2E 一致性测试套件ECS 变体则通过在 Bottlerocket 上运行 ECS task 来验证功能aws-k8s变体使用 EC2 与 EKSvmware-k8s变体使用 vSphere以此类推。cargo make test命令已为这些行为设置了合理的默认值。aws-k8s 变体在运行测试之前需要先 构建 Bottlerocket 并创建 AMI。下面命令中的变体与 AWS region 请按需替换警告测试会为你创建一个 EKS 集群。由于 EKS 集群创建耗时较长testsys 的默认行为是将其保留以便复用测试结束后你需要手动删除该 EKS 集群EC2 实例会自动终止但建议二次确认。cargo make \ -e BUILDSYS_VARIANTaws-k8s-1.32 \ -e BUILDSYS_ARCHx86_64 \ build cargo make \ -e BUILDSYS_VARIANTaws-k8s-1.32 \ -e BUILDSYS_ARCHx86_64 \ -e PUBLISH_REGIONSus-west-2 \ ami cargo make \ -e BUILDSYS_VARIANTaws-k8s-1.32 \ -e BUILDSYS_ARCHx86_64 \ test通过以下命令持续观察测试状态cargo make watch-test使用 Karpenter 供给节点在Test.toml中指定resource-agent-type karpenter即可用 Karpenter 供给节点。按照通用映射关系可使用如下配置[aws-k8s.configuration.karpenter] test-type quick resource-agent-type karpenter block-device-mapping [ {name /dev/xvda, volumeType gp3, volumeSize 4, deleteOnTermination true}, {name /dev/xvdb, volumeType gp3, volumeSize 20, deleteOnTermination true}, ]该配置为所有aws-k8s变体创建了一个名为karpenter的新测试类型对应表头中.configuration之后的字符串。启动节点前需要先把 Karpenter 角色加入集群的aws-authConfigMap# Change to your clusters name CLUSTER_NAMEmy-cluster ACCOUNT_IDyour-account-id REGIONus-west-2 eksctl create iamidentity mapping \ -r ${REGION} \ --cluster ${CLUSTER_NAME} \ --arn arn:aws:iam::${ACCOUNT_ID}:role/KarpenterInstanceNodeRole \ --username system:node:{{EC2PrivateDNSName}} \ --group system:bootstrappers \ --group system:nodes然后运行cargo make -e TESTSYS_TESTkarpenter testaws-ecs 变体同样需要先 构建 并创建 AMI。默认实例类型为m5.largex86_64与m6g.largeaarch64可通过环境变量TESTSYS_INSTANCE_TYPE覆盖——这对 NVIDIA 变体尤其有用因为 NVIDIA 变体需要带有 NVIDIA GPU 的实例类型。cargo make \ -e BUILDSYS_VARIANTaws-ecs-2 \ -e BUILDSYS_ARCHx86_64 \ build cargo make \ -e BUILDSYS_VARIANTaws-ecs-2 \ -e BUILDSYS_ARCHx86_64 \ -e PUBLISH_REGIONSus-west-2 \ ami cargo make \ -e BUILDSYS_VARIANTaws-ecs-2 \ -e BUILDSYS_ARCHx86_64 \ testcargo make watch-testAMI 发布的更多细节参见 PUBLISHING.md。vmware-k8s 变体首先需要使用EKS Anywhere创建一个初始管理集群management cluster然后将管理集群的 kubeconfig 路径设置为TESTSYS_MGMT_CLUSTER_KUBECONFIG。测试 VMware 变体还需要 构建 Bottlerocket 以及一个可通过公网访问的 TUF 仓库。基础设施信息可以配置在Infra.toml中也可以通过环境变量配置若使用环境变量请确保设置以下变量GOVC_URLGOVC_USERNAMEGOVC_PASSWORDGOVC_DATACENTERGOVC_DATASTOREGOVC_NETWORKGOVC_RESOURCE_POOLGOVC_FOLDERtestsys 会优先使用Test.toml中指定的数据中心若Test.toml未指定则使用Infra.toml中列出的第一个数据中心。另外VMware 测试要求必须在Test.toml中为 vSphere K8s 集群创建设置control-plane-endpoint。Step 1构建目标变体cargo make \ -e BUILDSYS_VARIANTvmware-k8s-1.31 \ -e BUILDSYS_ARCHx86_64 \ buildStep 2构建包含 OVA 模板的 TUF 仓库cargo make \ -e BUILDSYS_VARIANTvmware-k8s-1.31 \ -e BUILDSYS_ARCHx86_64 \ repoStep 3同步 TUF 仓库同步包含 VMware 变体 metadata 与 targets 的 TUF 仓库确保这些仓库可通过未认证的 HTTP 或 HTTPS 访问且与Infra.toml中的 URL 一致。Step 4运行测试cargo make \ -e BUILDSYS_VARIANTvmware-k8s-1.31 \ -e BUILDSYS_ARCHx86_64 \ test \ --mgmt-cluster-kubeconfig ${TESTSYS_MGMT_CLUSTER_KUBECONFIG}监控测试状态cargo make watch-test迁移测试Migration Testing迁移测试用于验证 Bottlerocket 能否从一个版本升级到新版本、再降级回原版本涉及启动实例、升级与降级的完整流程以某个起始 Bottlerocket 版本或用户提供的初始 AMI启动实例然后将其迁移到目标版本。要完成迁移测试需要准备以下工件一个可公开访问的 TUF 仓库一个由可用密钥签名的旧版 Bottlerocket 发布物旧版发布物的 AMI ID当前改动对应的镜像工件及其本地 TUF 仓库。准备 Infra.tomlBottlerocket 实例需要通过可访问的 TUF 仓库 URL 获取更新 metadata 与 targets。请按照 发布指南 搭建 TUF 仓库。testsys 通过Infra.toml定位 TUF 仓库因此需要根据刚创建的仓库设置metadata_base_url与targets_base_url。下面的示例假设使用Infra.toml中的默认仓库你也可以通过设置PUBLISH_REPO环境变量使用任意仓库。构建起始版本镜像本示例以v1.9.0作为起始版本Bottlerocket 任意 tag 均可。以下脚本会从 git 检出对应分支并构建测试所需的镜像与 TUF 仓库git checkout v1.9.0 cargo make cargo make ami cargo make repo构建完成后记得同步 TUF 仓库的 metadata 与 targets。构建目标版本镜像接下来构建要被升级到的目标工件。切回需要构建的工作分支WORKING_BRANCHdevelop git checkout ${WORKING_BRANCH}然后构建镜像与仓库并同步 TUF 仓库架构与变体可通过BUILDSYS_ARCH与BUILDSYS_VARIANT配置cargo make cargo make ami cargo make repo同样记得同步 TUF 仓库的 metadata 与 targets。至此准备工作完成。运行迁移测试确保所有环境变量仍然有效不足则重新设置然后设置TESTSYS_TESTmigration并调用cargo make testcargo make -e TESTSYS_TESTmigration testtestsys 会自动确定应使用的 AMI它会找出 Bottlerocket 最近发布的版本并在用户的 AMI 中匹配对应的起始 AMI ID。从 Makefile.toml 的注释可以看到migration测试的实际执行序列为先做一次quick测试从TESTSYS_STARTING_VERSION迁移到BUILDSYS_FULL_VERSION对迁移后的实例再做quick测试从BUILDSYS_FULL_VERSION降级回TESTSYS_STARTING_VERSION最后对降级后的实例做一次quick测试。起始版本默认通过git tag --list --sortversion:refname v*自动取最近发布的 tag也可用TESTSYS_STARTING_IMAGE_ID显式提供起始镜像。使用以下命令观察测试状态cargo make watch-test工作负载测试Workload Testing工作负载测试是设计为以编排容器形式运行的测试。在Test.toml中通过名为workloads的 map 定义[aws-nvidia] workloads { WORKLOAD-NAME WORKLOAD-IMAGE-URI }然后设置TESTSYS_TESTworkload运行cargo make -e TESTSYS_TESTworkload test观察状态cargo make watch-test自定义测试类型自定义测试通过以下命令运行cargo make -e TESTSYS_TESTCUSTOM-TEST-NAME test -f PATH-TO-TEMPLATED-YAMLStep 1构建测试 agent。test-agent-cli提供了创建基于 bash 的测试 agent 的接口可参考其 runbook 完成 agent 构建。Step 2创建 YAML 模板。Test.toml中的值可以注入到 YAML manifest 中这样同一个 manifest 可以复用于同一家族family内的所有变体apiVersion: {{api-version}} kind: Test metadata: # The name of the crd created is dependent on the arch and variant for # the test being run. name: {{kube-arch}}-{{kube-variant}}-custom namespace: {{namespace}} spec: retries: 5 agent: name: custom-test-agent image: example-test-agent-cli:latest keepRunning: false configuration: clusterName: {{cluster-name}} instanceType: {{instance-type}} resources: [] dependsOn: [] # The secrets will automatically be populated from the config file, # no template is needed. secrets: {}Step 3运行测试。agent 构建完成、YAML 文件创建好后执行cargo make -e TESTSYS_TESTCUSTOM-TEST-NAME test -f PATH-TO-YAML-FILE测试生命周期辅助任务除setup-test、test、watch-test、testsys之外Makefile.toml 还提供了一批测试生命周期管理任务全部经由 Twoliter 统一调度cargo make clean-test从 testsys 集群中清理测试支持--passed/--failed/--running过滤cargo make reset-test清理所有测试及其资源cargo make reset-single-test清理指定测试及其资源cargo make uninstall-test/cargo make purge-test卸载/清理 testsys 集群组件cargo make watch-test-all观察所有测试与资源的状态支持--running过滤cargo make log-test获取测试日志可加--follow持续跟随输出。关于 kubeconfig 的解析顺序Makefile.toml 中的逻辑是优先使用TESTSYS_KUBECONFIG环境变量指定的路径其次使用tests/testsys.kubeconfig再其次使用仓库根目录下的testsys.kubeconfig若均不存在则回退到用户默认 kubeconfig。若前两个候选同时存在且未显式指定任务会直接报错避免歧义。赞分享操作系统云原生安全【免费下载链接】bottlerocketAn operating system designed for hosting containers项目地址https://gitcode.com/gh_mirrors/bo/bottlerocket点击查看免费下载相关推荐如何为details-dialog-element编写自定义样式CSS定制完全教程如何为details dialog element编写自定义样式CSS定制完全教程 想要为你的details dialog element创建独特美观的对话框LocalAI完整测试指南从单元测试到集成测试的终极实践LocalAI完整测试指南从单元测试到集成测试的终极实践 LocalAI 是一个开源项目旨在本地运行机器学习模型减少对云服务的依赖提高隐私保护。本指南将人工智能大模型模型推理服务本地部署LLM 网关多模态AI AgentRAGMCP 服务SeaORM完整测试指南从单元测试到集成测试的终极实践SeaORM完整测试指南从单元测试到集成测试的终极实践 SeaORM作为Rust生态中备受青睐的异步ORM框架其强大的测试策略确保了代码的稳定性和可靠性。本后端数据库ORM上一篇掌握自动化英雄联盟工具配置提升游戏效率的专业指南下一篇Apache Flink Java Lambda 表达式完全指南类型推断、泛型擦除与显式类型声明创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
