测试云原生质量保障【免费下载链接】originConformance test suite for OpenShift项目地址https://gitcode.com/gh_mirrors/or/origin点击查看免费下载ImageStream镜像流是 OpenShift 在 Kubernetes 与 Docker 之上提供的关键抽象它把注册表里的镜像提升为集群内可跟踪、可触发、可控制的逻辑实体。本文以本仓库 examples/image-streams/README.md 为主线结合其产物 image-streams-centos7.json 及配套的拉取脚本、测试用例完整讲解 ImageStream 的核心概念、预置镜像流清单、JSON 结构细节、标签命名约定以及如何用它们驱动部署与更新。读完本文你将掌握 ImageStream 的定义格式、部署方法以及这套预置示例的自动生成与校验链路。ImageStream注册表镜像之上的抽象层examples/image-streams/README.md 开篇即点明了 ImageStream 的设计动机Imagestreams provide an abstraction for images located in a registry. By referencing an imagestream (or a tag within an imagestream) instead of referencing a image registry/repository:tag directly, your resources can be triggered when the underlying image changes, as well as control when image updates are rolled out.翻译并展开来说ImageStream 带来两个核心能力抽象与解耦应用资源不再直接写死registry.example.com/team/app:v1这样的 registry/repository:tag而是引用imagestream或imagestream 内的某个 tag如postgresql:10-el8。镜像的来源registry 地址、仓库路径、tag发生迁移时只需更新 ImageStream 定义而无需改动所有引用它的工作负载。变更触发与滚动控制当底层镜像发生变化时例如上游镜像仓库出现了新的 digest引用该 ImageStream 的资源可以被自动触发如触发 Build、触发 DeploymentConfig 的 ImageChange 部署同时管理员可以精确控制何时、以何种策略把新镜像滚动出去而不是让集群无差别地拉取最新镜像。这一抽象正是 OpenShift 构建、部署、模板三大能力链images、builds、deployments、templates的基石examples/README.md 在介绍示例集时也把解释 Kubernetes 与 Docker 之上新增的概念作为目录的定位。预置镜像流清单13 个开箱即用的 ImageStreamexamples/image-streams目录中README 提供了一份可下载的定义清单每个语言/中间件都提供CentOS7与RHEL7两个系列的镜像流定义其中 CentOS 系列最终落盘为 image-streams-centos7.jsonRHEL 系列在脚本中被注释保留。完整清单如下ImageStream角色说明.NET (dotnet)S2I 构建器构建并运行 .NET 应用含 6.0、9.0、3.1 等版本 tagHTTPD (httpd)Web 服务器 / 构建器Apache HTTP Server构建与托管静态内容Jenkins (jenkins)CI 服务提供 Jenkins 2.x 服务器含升级重部署专用 tagMariaDB (mariadb)数据库10.5、10.3 版本MySQL (mysql)数据库8.0 版本Nginx (nginx)Web 服务器 / 反向代理1.20、1.18 系列Node.js (nodejs)S2I 构建器16、14 版本含 minimal 变体Perl (perl)S2I 构建器5.32、5.30、5.26PHP (php)S2I 构建器8.0、7.4、7.3Python (python)S2I 构建器3.9、3.8、3.6、2.7PostgreSQL (postgresql)数据库13、12、10Redis (redis)数据库5Ruby (ruby)S2I 构建器3.0、2.7、2.5WildFly (wildfly)S2I 构建器Java/Jakarta EE 应用17.0 至 26.1每个条目在 README 中均以名称的固定行格式出现。这些定义由外部镜像目录openshift/library维护本仓库通过脚本自动拉取详见下文自动化维护小节因此该目录下的 JSON 文件属于生成产物不应手动修改——README 末尾明确声明Note: This file is processed byhack/update-external-examples.sh. New examples must follow the exact syntax of the existing entries. Files in this directory are automatically pulled down, do not modify/add files to this directory.深入解析 image-streams-centos7.json 的结构image-streams-centos7.json 是一个 2155 行的ImageStreamList顶层将 13 个 ImageStream 打包为一份清单{ kind: ImageStreamList, apiVersion: image.openshift.io/v1, items: [ ... ] }每个items元素都是一个完整的ImageStream其字段结构与含义如下以dotnet为例见 image-streams-centos7.json{ kind: ImageStream, apiVersion: image.openshift.io/v1, metadata: { name: dotnet, creationTimestamp: null, annotations: { openshift.io/display-name: .NET } }, spec: { lookupPolicy: { local: false }, tags: [ ... ] }, status: { dockerImageRepository: } }metadata名称与展示信息metadata.nameImageStream 的集群内名称如dotnet、postgresql是其他资源引用它的句柄。metadata.annotations[openshift.io/display-name]在 Web 控制台 / 开发者目录中展示的友好名称如.NET、PostgreSQL与机器可读的 name 解耦。spec.lookupPolicy.local本地镜像解析开关lookupPolicy.local是 OpenShift 的一项特殊能力当设为true时集群会把 ImageStream 内 tag 指向的镜像自动解析为本地镜像引用使 Pod 等资源可以直接通过 ImageStream 名称拉取镜像而无需显式写全 registry 地址。本仓库预置的 13 个定义中该字段均为false表示不启用本地查找解析镜像引用仍走显式地址。spec.tags标签数组——ImageStream 的核心每个 tag 定义了一组名字 → 镜像来源的映射。以dotnet的latesttag 为例{ name: latest, annotations: { description: Build and run .NET applications. ... WARNING: By selecting this tag, your application will automatically update to use the latest version of .NET available on OpenShift, including major versions updates., iconClass: icon-dotnet, openshift.io/display-name: .NET (Latest), sampleContextDir: app, sampleRef: dotnet-9.0, sampleRepo: https://github.com/redhat-developer/s2i-dotnetcore-ex, supports: dotnet, tags: builder,.net,dotnet,dotnetcore,hidden }, from: { kind: ImageStreamTag, name: 9.0-ubi8 }, generation: null, importPolicy: {}, referencePolicy: { type: Local } }各字段的作用可归纳如下字段含义name标签名如latest、10-el7、16-ubi8供其他资源以stream:tag形式引用annotations.description镜像功能说明latest标签均附有 WARNING选择该标签将自动跟随 OpenShift 上可用版本含大版本升级annotations.iconClass控制台中的图标类名annotations[openshift.io/display-name]该标签的展示名称annotations[openshift.io/provider-display-name]镜像提供方预置定义中为 Red Hat, Inc.annotations.sampleRepo/sampleContextDir/sampleRef供oc new-app等工具使用的示例仓库与上下文信息annotations.supports支持的框架标识如dotnet、php:8.0,php用于从代码自动匹配构建器annotations.tags检索分类标签带hidden的 tag 会在控制台目录中隐藏annotations.version版本号如6.0、8.0from.kind镜像来源类型DockerImage直接指向外部 registry 的具体镜像或ImageStreamTag指向本流内/其他流的另一个 tagfrom.name来源地址DockerImage时为完整镜像名如registry.access.redhat.com/ubi8/dotnet-60:6.0ImageStreamTag时为 tag 名如9.0-ubi8importPolicy导入策略可含scheduled: true定时检查上游并导入新 digestreferencePolicy.type引用策略预置定义统一为Local工作负载引用本集群内部镜像仓库的 digest 地址status.dockerImageRepository状态字段由控制器回填该流对应的内部镜像仓库地址定义文件中为空标签间引用的链式结构预置定义大量使用 tag 指向 tag 的写法形成浮动标签 → 具体版本标签的链。典型模式{ name: latest, from: { kind: ImageStreamTag, name: 9.0-ubi8 } }即latest只是一个逻辑别名指向9.0-ubi8这个具体版本标签而9.0-ubi8又通过DockerImage指向registry.access.redhat.com/ubi8/dotnet-90:9.0。这样的好处是应用可以稳定引用dotnet:latest获得持续更新也可以钉死dotnet:6.0-ubi8保持版本不变而镜像仓库地址一旦迁移只需调整底层那一个DockerImage来源。特殊 tagjenkins 的升级重部署三件套Jenkins 流还演示了 ImageStream 与升级流程的深度集成见 image-streams-centos7.json提供了三个专用 tagocp-upgrade-redeployOCP 升级时若 Jenkins 镜像引用发生变化会自动重部署 DeploymentConfiguser-maintained-upgrade-redeploy需用户手动执行oc import-image jenkins:user-maintained-upgrade-redeploy -n openshift控制器拉取最新 digest 后触发重部署scheduled-upgrade-redeploy通过importPolicy.scheduled: true定时检查上游自动导入新 digest 并触发重部署。三者共用quay.io/openshift/origin-jenkins:4.11作为镜像来源区别仅在于谁触发导入。这组定义是从源码注释中可直接验证的镜像流驱动滚动更新的实战案例。标签命名约定与版本选择从预置定义中可以总结出清晰的命名规范便于直接套用命名模式含义示例latest浮动标签跟随最新可用版本含大版本dotnet:latestversion-el7基于 CentOS 7 / RHEL 7mariadb:10.5-el7、postgresql:12-el7version-ubi8基于 UBI 8python:3.9-ubi8、nodejs:16-ubi8version-ubi9基于 UBI 9php:8.0-ubi9、perl:5.32-ubi9version-ubi8-minimalUBI 8 Minimal更小体积nodejs:16-ubi8-minimalversion-ubi7基于 UBI 7较旧的兼容路径ruby:3.0-ubi7选择建议依据定义本身的行为追求持续自动更新 → 引用latest但需接受 WARNING 中描述的大版本也可能自动跳变的行为追求稳定可复现 → 引用带版本前缀的具体标签如postgresql:13-el7数据库类流MariaDB/MySQL/PostgreSQL/Redis只定义数据库镜像语言类流.NET/Node.js/PHP/Python/Ruby/Perl/WildFly定义为 S2I 构建器镜像并带有supports标注可被oc new-app自动识别。把 ImageStream 用到真实工作负载中1. 导入预置镜像流将清单文件直接应用到目标项目通常为openshift项目供全集群共享oc apply -f examples/image-streams/image-streams-centos7.json -n openshift2. 在模板/DeploymentConfig 中引用数据库模板 examples/db-templates/postgresql-persistent-template.json 是模板消费 ImageStream的标准示例其 DeploymentConfig 的triggers中声明了一个ImageChange触发器from指向postgresql:${POSTGRESQL_VERSION}且namespace参数默认值为openshifttriggers: [ { imageChangeParams: { automatic: true, containerNames: [postgresql], from: { kind: ImageStreamTag, name: postgresql:${POSTGRESQL_VERSION}, namespace: ${NAMESPACE} }, lastTriggeredImage: }, type: ImageChange }, { type: ConfigChange } ]模板参数POSTGRESQL_VERSION的描述为 Version of PostgreSQL image to be used (10-el7, 10-el8, or latest)默认值10-el8——这意味着用户实例化模板时只需改参数值就能在 ImageStream 的多个 tag 之间切换数据库版本而 DeploymentConfig 的定义完全无需变动。automatic: true保证当该 tag 的 digest 更新时OpenShift 会自动触发新一轮滚动部署。同样地examples/jenkins/jenkins-ephemeral-template.json 也以 Jenkins ImageStreamTag 参数形式引用jenkins流并把jenkins-agent-base:latest、java:latest、nodejs:latest等 ImageStreamTag 用于 Kubernetes 插件的 PodTemplate 默认镜像。3. 用 new-app / import-image 驱动oc new-app imagestream:tag直接基于镜像流创建应用supports标注可帮助自动匹配构建器oc import-image stream:tag -n project手动触发控制器从上游导入最新镜像 digestjenkins 的user-maintained-upgrade-redeploytag 描述中即明确给出了该命令的用法定时导入在 tag 上设置importPolicy.scheduled: true控制器将周期性检查上游更新。自动化维护update-external-examples.sh 的拉取与合并examples/image-streams/README.md 与 hack/update-external-examples.sh 构成了一套README 即清单、脚本即生成器的维护机制脚本进入examples/image-streams目录先清理所有*.json/yaml/yml旧文件用grep -E \(https://raw.githubusercontent.com.*centos.*\) README.md匹配 README 中包含镜像定义 URL 的行再用sed提取括号内的 URL交给curl -O逐个下载注释掉的 RHEL 分支同理但当前处于禁用状态用jq将下载到的多个 JSON 合并为ImageStreamListjq . -s *.json | jq . | {kind: List,apiVersion: v1, items: .} images-centos.tmp mv images-centos.tmp image-streams-centos7.json最终产物即 image-streams-centos7.json。这解释了 README 的两条硬性约束新条目必须精确遵循既有语法脚本依赖[名称](https://raw.githubusercontent.com/.../xxx.json)这一行格式来提取 URL任何偏离都会导致拉取失败不要手动修改/新增该目录文件文件由脚本自动覆盖生成手工改动会在下次执行脚本时被清除。质量保障examples_test.go 的 schema 校验预置示例并非只靠脚本拉取还配有单元测试守护。在 examples/examples_test.go 中TestExampleObjectSchemas为../examples/image-streams目录注册了期望类型imagev1.ImageStreamList然后递归遍历目录下所有 JSON/YAML用 OpenShift API schemeimagev1.Install等执行runtime.DecodeInto反序列化校验walkJSONFiles还会检查每个文件都被测试用例覆盖防止出现有文件无测试的漏网之鱼。这意味着拉取下来的定义必须能被image.openshift.io/v1的 scheme 正确解码否则 CI 直接报错kind、apiVersion、字段结构等一旦与 OpenShift API 类型不匹配测试即可在合并前拦截。结语与维护要点总结本文要点概念层面ImageStream 是注册表镜像的集群内抽象让资源引用与镜像仓库解耦并赋予镜像变更 → 自动触发/受控滚动的能力资产层面examples/image-streams 提供 .NET、HTTPD、Jenkins、MariaDB、MySQL、Nginx、Node.js、Perl、PHP、Python、PostgreSQL、Redis、Ruby、WildFly 共 13 个镜像流的 CentOS7/RHEL7 双系列定义产物为 image-streams-centos7.json结构层面ImageStream 由metadata、spec.lookupPolicy、spec.tags、status组成tags支持DockerImage/ImageStreamTag两种来源、importPolicy.scheduled定时导入、referencePolicy引用策略以及latest浮动标签 版本标签的链式设计工程层面hack/update-external-examples.sh 从 README 自动拉取并合并定义examples/examples_test.go 保证定义始终可被 OpenShift API scheme 解码落地层面配合 db-templates 与 jenkins 中的模板通过ImageChange触发器即可实现改参数换版本、digest 更新自动重部署的完整闭环。如果你需要在集群中批量启用这些镜像流直接应用image-streams-centos7.json到openshift项目即可若想新增镜像流务必遵循 README 的固定行语法并在外部镜像目录中维护定义而不是直接修改本目录的生成文件。赞分享测试云原生质量保障【免费下载链接】originConformance test suite for OpenShift项目地址https://gitcode.com/gh_mirrors/or/origin点击查看免费下载相关推荐NixOS 构建自定义安装 ISO 镜像从预置配置到 mkImageMediaOverride 覆盖机制NixOS 构建自定义安装 ISO 镜像从预置配置到 mkImageMediaOverride 覆盖机制 导读 本文以 NixOS 手册中“Building包管理器操作系统ESP-IDF IDF Docker 镜像指南自动化构建、串口烧写与自定义镜像定制ESP IDF IDF Docker 镜像指南自动化构建、串口烧写与自定义镜像定制 本文以 ESP IDF 官方文档 IDF Docker 镜像 https:物联网嵌入式3个关键策略提升OpenAEV平台安全测试效能的完整指南3个关键策略提升OpenAEV平台安全测试效能的完整指南 OpenAEV作为开源对抗性暴露验证平台为企业安全团队提供了全面的网络攻击模拟能力。通过精心设计的上一篇不懂代码也能建模5步让AI接管Blender免费开源的BlenderMCP完整上手指南下一篇Midscene Chrome扩展AI浏览器自动化3分钟跑通第一条指令创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考