CI/CD
包含有关 OpenShift Container Platform 构建、管道和 GitOps 的信息
摘要
第 1 章 OpenShift Container Platform CI/CD 概述
OpenShift Container Platform 是面向开发人员的企业就绪 Kubernetes 平台,使组织能够通过 DevOps 实践(如持续集成(CI)和持续交付(CD))自动化应用程序交付流程。为了满足您的机构需求,OpenShift Container Platform 提供以下 CI/CD 解决方案:
- OpenShift 构建
- OpenShift Pipelines
- OpenShift GitOps
1.1. OpenShift 构建
使用 OpenShift 构建时,您可以使用声明性构建过程创建云原生应用程序。您可以在用于创建 BuildConfig 对象的 YAML 文件中定义构建过程。此定义包括构建触发器、输入参数和源代码等属性。部署之后,BuildConfig 对象通常构建可运行的镜像并将其推送到容器镜像 registry。
OpenShift 构建为构建策略提供以下可扩展的支持:
- Docker 构建
- Source-to-image(S2I)构建
- Custom 构建
如需更多信息,请参阅了解镜像构建
1.2. OpenShift Pipelines
OpenShift Pipelines 提供了一个 Kubernetes 原生 CI/CD 框架,用于在其自己的容器中设计和运行 CI/CD 管道的每个步骤。它可以通过可预测的结果独立扩展以满足按需管道。
如需更多信息,请参阅了解 OpenShift Pipelines
1.3. OpenShift GitOps
OpenShift GitOps 是一个使用 Argo CD 作为声明性 GitOps 引擎的 Operator。它启用了多集群 OpenShift 和 Kubernetes 基础架构的 GitOps 工作流。使用 OpenShift GitOps,管理员可以在集群和开发生命周期中一致地配置和部署基于 Kubernetes 的基础架构和应用程序。
如需更多信息,请参阅了解 OpenShift GitOps
1.4. Jenkins
Jenkins 自动化了构建、测试和部署应用和项目的过程。OpenShift 开发者工具提供 Jenkins 镜像,它直接与 OpenShift Container Platform 集成。Jenkins 可通过使用 Samples Operator 模板或认证的 Helm Chart 在 OpenShift 上部署。
第 2 章 构建(build)
2.1. 理解镜像构建
2.1.1. Builds
构建 (build) 是将输入参数转换为结果对象的过程。此过程最常用于将输入参数或源代码转换为可运行的镜像。BuildConfig
对象是整个构建过程的定义。
OpenShift Container Platform 使用 Kubernetes,从构建镜像创建容器并将它们推送到容器镜像 registry。
构建对象具有共同的特征,包括构建的输入,完成构建过程要满足的要求、构建过程日志记录、从成功构建中发布资源,以及发布构建的最终状态。构建会使用资源限制,具体是指定资源限值,如 CPU 使用量、内存使用量,以及构建或 Pod 执行时间。
OpenShift Container Platform 构建系统提供对构建策略的可扩展支持,它们基于构建 API 中指定的可选择类型。可用的构建策略主要有三种:
- Docker 构建
- Source-to-image(S2I)构建
- Custom 构建
默认情况下,支持 docker 构建和 S2I 构建。
构建生成的对象取决于用于创建它的构建器(builder)。对于 docker 和 S2I 构建,生成的对象为可运行的镜像。对于自定义构建,生成的对象是构建器镜像作者指定的任何事物。
此外,也可利用管道构建策略来实现复杂的工作流:
- 持续集成
- 持续部署
2.1.1.1. Docker 构建
OpenShift Container Platform 使用 Buildah 从 Dockerfile 构建容器镜像。有关使用 Dockerfile 构建容器镜像的更多信息,请参阅 Dockerfile 参考文档。
如果使用 buildArgs
数组设置 Docker 构建参数,请参阅 Dockerfile 参考文档中了解 ARG 和 FROM 如何交互。
2.1.1.2. Source-to-image 构建
Source-to-Image (S2I) 是一种用于构建可重复生成的容器镜像的工具。它通过将应用程序源代码注入容器镜像并汇编新镜像来生成可随时运行的镜像。新镜像融合了基础镜像(构建器)和构建的源代码,并可搭配 buildah run
命令使用。S2I 支持递增构建,可重复利用以前下载的依赖项和过去构建的工件等。
2.1.1.3. Custom 构建
采用自定义构建策略时,开发人员可以定义负责整个构建过程的特定构建器镜像。通过利用自己的构建器镜像,可以自定义构建流程。
自定义构建器镜像是嵌入了构建过程逻辑的普通容器镜像,例如用于构建 RPM 或基本镜像的逻辑。
自定义构建以级别很高的特权运行,默认情况下不可供用户使用。只有可赋予集群管理权限的用户才应被授予运行自定义构建的权限。
2.1.1.4. Pipeline 构建
Pipeline 构建策略在 OpenShift Container Platform 4 中弃用。基于 Tekton 的 OpenShift Container Platform Pipelines 中带有等效且改进的功能。
OpenShift Container Platform 上的 Jenkins 镜像被完全支持,用户可以按照 Jenkins 用户文档在作业中定义 jenkinsfile
,或者将其存储在 Source Control Management 系统中。
采用 Pipeline 构建策略时,开发人员可以定义 Jenkins 管道,供 Jenkins 管道插件使用。构建可以由 OpenShift Container Platform 启动、监控和管理,其方式与任何其他构建类型相同。
Pipeline 工作流在 jenkinsfile
中定义,或直接嵌入在构建配置中,或者在 Git 存储库中提供并由构建配置引用。
2.2. 了解构建配置
以下小节定义了构建、构建配置和可用的主要构建策略的概念。
2.2.1. BuildConfig
构建配置描述单个构建定义,以及一组规定何时创建新构建的触发器(trigger)。构建配置通过 BuildConfig
定义,它是一种 REST 对象,可在对 API 服务器的 POST 中使用以创建新实例。
构建配置或 BuildConfig
的特征就是构建策略和一个或多个源。策略决定流程,而源则提供输入。
根据您选择使用 OpenShift Container Platform 创建应用程序的方式,如果使用 Web 控制台或 CLI,通常会自动生成 BuildConfig
,并且可以随时对其进行编辑。如果选择稍后手动更改配置,则了解 BuildConfig
的组成部分及可用选项可能会有所帮助。
以下示例 BuildConfig
在每次容器镜像标签或源代码改变时产生新的构建:
BuildConfig
对象定义
kind: BuildConfig apiVersion: build.openshift.io/v1 metadata: name: "ruby-sample-build" 1 spec: runPolicy: "Serial" 2 triggers: 3 - type: "GitHub" github: secret: "secret101" - type: "Generic" generic: secret: "secret101" - type: "ImageChange" source: 4 git: uri: "https://github.com/openshift/ruby-hello-world" strategy: 5 sourceStrategy: from: kind: "ImageStreamTag" name: "ruby-20-centos7:latest" output: 6 to: kind: "ImageStreamTag" name: "origin-ruby-sample:latest" postCommit: 7 script: "bundle exec rake test"
- 1
- 此规格会创建一个名为
ruby-sample-build
的新BuildConfig
。 - 2
runPolicy
字段控制从此构建配置创建的构建能否同时运行。默认值为Serial
,即新构建将按顺序运行,而不是同时运行。- 3
- 您可以指定导致创建新构建的触发器的列表。
- 4
source
部分定义构建的来源。源类型决定主要的输入源,可以是Git
(指向代码库存储位置)、Dockerfile
(从内联 Dockerfile 构建)或Binary
(接受二进制有效负载)。可以同时拥有多个源。有关每种源类型的更多信息,请参阅"创建构建输入"。- 5
strategy
部分描述用于执行构建的构建策略。您可以在此处指定Source
、Docker
或Custom
策略。本例使用ruby-20-centos7
容器镜像, Source-to-image(S2I)用于应用程序构建。- 6
- 成功构建容器镜像后,它将被推送到
output
部分中描述的存储库。 - 7
postCommit
部分定义一个可选构建 hook。
2.3. 创建构建输入
通过以下小节查看构建输入的概述,并了解如何使用输入提供构建操作的源内容,以及如何使用构建环境和创建 secret。
2.3.1. 构建输入
构建输入提供构建操作的源内容。您可以使用以下构建输入在 OpenShift Container Platform 中提供源,它们按优先顺序列出:
- 内联 Dockerfile 定义
- 从现有镜像中提取内容
- Git 存储库
- 二进制(本地)输入
- 输入 secret
- 外部工件 (artifact)
您可以在单个构建中组合多个输入。但是,由于内联 Dockerfile 具有优先权,它可能会覆盖任何由其他输入提供的名为 Dockerfile 的文件。二进制(本地)和 Git 存储库是互斥的输入。
如果不希望在构建生成的最终应用程序镜像中提供构建期间使用的某些资源或凭证,或者想要消耗在 secret 资源中定义的值,您可以使用输入 secret。外部工件可用于拉取不以其他任一构建输入类型提供的额外文件。
在运行构建时:
- 构造工作目录,并将所有输入内容放进工作目录中。例如,把输入 Git 存储库克隆到工作目录中,并且把由输入镜像指定的文件通过目标目录复制到工作目录中。
-
构建过程将目录更改到
contextDir
(若已指定)。 - 内联 Dockerfile(若有)写入当前目录中。
-
当前目录中的内容提供给构建过程,供 Dockerfile、自定义构建器逻辑或
assemble
脚本引用。这意味着,构建会忽略所有驻留在contextDir
之外的输入内容。
以下源定义示例包括多种输入类型,以及它们如何组合的说明。如需有关如何定义各种输入类型的更多详细信息,请参阅每种输入类型的具体小节。
source: git: uri: https://github.com/openshift/ruby-hello-world.git 1 ref: "master" images: - from: kind: ImageStreamTag name: myinputimage:latest namespace: mynamespace paths: - destinationDir: app/dir/injected/dir 2 sourcePath: /usr/lib/somefile.jar contextDir: "app/dir" 3 dockerfile: "FROM centos:7\nRUN yum install -y httpd" 4
2.3.2. Dockerfile 源
提供 dockerfile
值时,此字段的内容将写到磁盘上,存为名为 Dockerfile
的文件。这是处理完其他输入源之后完成的;因此,如果输入源存储库的根目录中包含 Dockerfile,它会被此内容覆盖。
源定义是 BuildConfig
的 spec
部分的一部分:
source:
dockerfile: "FROM centos:7\nRUN yum install -y httpd" 1
- 1
dockerfile
字段包含要构建的内联 Dockerfile。
其他资源
- 此字段的典型用途是为 Docker 策略构建提供 Dockerfile。
2.3.3. 镜像源
您可以使用镜像向构建过程添加其他文件。输入镜像的引用方式与定义 From
和 To
镜像目标的方式相同。这意味着可以引用容器镜像和镜像流标签。在使用镜像时,必须提供一个或多个路径对,以指示要复制镜像的文件或目录的路径以及构建上下文中要放置它们的目的地。
源路径可以是指定镜像内的任何绝对路径。目的地必须是相对目录路径。构建时会加载镜像,并将指定的文件和目录复制到构建过程上下文目录中。这与源存储库内容要克隆到的目录相同。如果源路径以 /.
结尾,则复制目录的内容,但不在目的地上创建该目录本身。
镜像输入在 BuildConfig
的 source
定义中指定:
source: git: uri: https://github.com/openshift/ruby-hello-world.git ref: "master" images: 1 - from: 2 kind: ImageStreamTag name: myinputimage:latest namespace: mynamespace paths: 3 - destinationDir: injected/dir 4 sourcePath: /usr/lib/somefile.jar 5 - from: kind: ImageStreamTag name: myotherinputimage:latest namespace: myothernamespace pullSecret: mysecret 6 paths: - destinationDir: injected/dir sourcePath: /usr/lib/somefile.jar
另外,如果输入镜像需要 pull secret,您可以将 pull secret 链接到构建所使用的服务帐户。默认情况下,构建使用 builder
服务帐户。如果 secret 包含与托管输入镜像的存储库匹配的凭证,pull secret 会自动添加到构建中。要将 pull secret 连接到构建使用的服务帐户,请运行:
$ oc secrets link builder dockerhub
使用自定义策略的构建不支持此功能。
2.3.4. Git 源
指定之后,从提供的位置获取源代码。
如果您提供内联 Dockerfile,它将覆盖 Git 存储库的 contextDir
中的 Dockerfile。
源定义是 BuildConfig
的 spec
部分的一部分:
source: git: 1 uri: "https://github.com/openshift/ruby-hello-world" ref: "master" contextDir: "app/dir" 2 dockerfile: "FROM openshift/ruby-22-centos7\nUSER example" 3
如果 ref
字段注明拉取请求,则系统将使用 git fetch
操作,然后 checkout FETCH_HEAD
。
如果未提供 ref
值,OpenShift Container Platform 将执行浅克隆 (--depth=1
)。这时,仅下载与默认分支(通常为 master
)上最近提交相关联的文件。这将使存储库下载速度加快,但不会有完整的提交历史记录。要执行指定存储库的默认分支的完整 git clone
,请将 ref
设置为默认分支的名称(如 main
)。
如果 Git 克隆操作要经过执行中间人 (MITM) TLS 劫持或重新加密被代理连接的代理,该操作不起作用。
2.3.4.1. 使用代理
如果 Git 存储库只能使用代理访问,您可以在构建配置的 source
部分中定义要使用的代理。您可以同时配置要使用的 HTTP 和 HTTPS 代理。两个字段都是可选的。也可以在 NoProxy
字段中指定不应执行代理的域。
源 URI 必须使用 HTTP 或 HTTPS 协议才可以正常工作。
source: git: uri: "https://github.com/openshift/ruby-hello-world" ref: "master" httpProxy: http://proxy.example.com httpsProxy: https://proxy.example.com noProxy: somedomain.com, otherdomain.com
对于 Pipeline 策略构建,因为 Jenkins Git 插件当前限制的缘故,通过 Git 插件执行的任何 Git 操作都不会利用 BuildConfig
中定义的 HTTP 或 HTTPS 代理。Git 插件将仅使用 Plugin Manager 面板上 Jenkins UI 中配置的代理。然后,在所有任务中,此代理都会被用于 Jenkins 内部与 git 的所有交互。
其他资源
- 您可以在 JenkinsBehindProxy 上找到有关如何通过 Jenkins UI 配置代理的说明。
2.3.4.2. 源克隆 secret
构建器 pod 需要访问定义为构建源的任何 Git 存储库。源克隆 secret 为构建器 pod 提供了通常无权访问的资源的访问权限,例如私有存储库或具有自签名或不可信 SSL 证书的存储库。
支持以下源克隆 secret 配置:
- .gitconfig 文件
- 基本身份验证
- SSH 密钥身份验证
- 可信证书颁发机构
您还可以组合使用这些配置来满足特定的需求。
2.3.4.2.1. 自动把源克隆 secret 添加到构建配置
创建 BuildConfig
,OpenShift Container Platform 可以自动填充其源克隆 secret 引用。这会使生成的构建自动使用存储在引用的 secret 中的凭证与远程 Git 存储库进行身份验证,而无需进一步配置。
若要使用此功能,包含 Git 存储库凭证的一个 secret 必须存在于稍后创建 BuildConfig
的命名空间中。此 secret 必须包含前缀为 build.openshift.io/source-secret-match-uri-
的一个或多个注解。这些注解中的每一个值都是统一资源标识符(URI)模式,其定义如下。如果 BuildConfig
是在没有源克隆 secret 引用的前提下创建的,并且其 Git 源 URI 与 secret 注解中的 URI 模式匹配,OpenShift Container Platform 将自动在 BuildConfig
插入对该 secret 的引用。
先决条件
URI 模式必须包含:
-
有效的方案包括:
*://
、git://
、http://
、https://
或ssh://
-
一个主机:*,或一个有效的主机名或 IP 地址(可选)在之前使用
*。
-
一个路径:
/*
,或/
(后面包括任意字符并可以包括*
字符)
在上述所有内容中,*
字符被认为是通配符。
URI 模式必须与符合 RFC3986 的 Git 源 URI 匹配。不要在 URI 模式中包含用户名(或密码)组件。
例如,如果使用 ssh://git@bitbucket.atlassian.com:7999/ATLASSIAN jira.git
作为 git 存储库 URL,则源 secret 必须指定为 ssh://bitbucket.atlassian.com:7999/*
(而非 ssh://git@bitbucket.atlassian.com:7999/*
)。
$ oc annotate secret mysecret \ 'build.openshift.io/source-secret-match-uri-1=ssh://bitbucket.atlassian.com:7999/*'
流程
如果多个 secret 与特定 BuildConfig
的 Git URI 匹配,OpenShift Container Platform 会选择匹配最多的 secret。这可以实现下例中所示的基本覆盖。
以下片段显示了两个部分源克隆 secret,第一个匹配通过 HTTPS 访问的 mycorp.com
域中的任意服务器,第二个则覆盖对服务器 mydev1.mycorp.com
和 mydev2.mycorp.com
的访问:
kind: Secret apiVersion: v1 metadata: name: matches-all-corporate-servers-https-only annotations: build.openshift.io/source-secret-match-uri-1: https://*.mycorp.com/* data: ... --- kind: Secret apiVersion: v1 metadata: name: override-for-my-dev-servers-https-only annotations: build.openshift.io/source-secret-match-uri-1: https://mydev1.mycorp.com/* build.openshift.io/source-secret-match-uri-2: https://mydev2.mycorp.com/* data: ...
使用以下命令将
build.openshift.io/source-secret-match-uri-
注解添加到预先存在的 secret:$ oc annotate secret mysecret \ 'build.openshift.io/source-secret-match-uri-1=https://*.mycorp.com/*'
2.3.4.2.2. 手动添加源克隆 secret
通过将 sourceSecret
字段添加到 BuildConfig
中的 source
部分,并将它设置为您创建的 secret 的名称,可以手动将源克隆 secret 添加到构建配置中。在本例中,是 basicsecret
。
apiVersion: "v1" kind: "BuildConfig" metadata: name: "sample-build" spec: output: to: kind: "ImageStreamTag" name: "sample-image:latest" source: git: uri: "https://github.com/user/app.git" sourceSecret: name: "basicsecret" strategy: sourceStrategy: from: kind: "ImageStreamTag" name: "python-33-centos7:latest"
流程
您还可以使用 oc set build-secret
命令在现有构建配置中设置源克隆 secret。
要在现有构建配置上设置源克隆 secret,请输入以下命令:
$ oc set build-secret --source bc/sample-build basicsecret
2.3.4.2.3. 从 .gitconfig 文件创建 secret
如果克隆应用程序要依赖于 .gitconfig
文件,您可以创建包含它的 secret。将它添加到 builder 服务帐户中,再添加到您的 BuildConfig
。
流程
-
从
.gitconfig
文件创建 secret:
$ oc create secret generic <secret_name> --from-file=<path/to/.gitconfig>
如果 .gitconfig
文件的 http
部分设置了 sslVerify=false
,则可以关闭 iVSSL 验证:
[http] sslVerify=false
2.3.4.2.4. 从 .gitconfig 文件为安全 Git 创建 secret
如果 Git 服务器使用双向 SSL 和用户名加密码进行保护,您必须将证书文件添加到源构建中,并在 .gitconfig
文件中添加对证书文件的引用。
先决条件
- 您必须具有 Git 凭证。
流程
将证书文件添加到源构建中,并在 gitconfig
文件中添加对证书文件的引用。
-
将
client.crt
、cacert.crt
和client.key
文件添加到应用程序源代码的/var/run/secrets/openshift.io/source/
目录中。 在服务器的
.gitconfig
文件中,添加下例中所示的[http]
部分:# cat .gitconfig
输出示例
[user] name = <name> email = <email> [http] sslVerify = false sslCert = /var/run/secrets/openshift.io/source/client.crt sslKey = /var/run/secrets/openshift.io/source/client.key sslCaInfo = /var/run/secrets/openshift.io/source/cacert.crt
创建 secret:
$ oc create secret generic <secret_name> \ --from-literal=username=<user_name> \ 1 --from-literal=password=<password> \ 2 --from-file=.gitconfig=.gitconfig \ --from-file=client.crt=/var/run/secrets/openshift.io/source/client.crt \ --from-file=cacert.crt=/var/run/secrets/openshift.io/source/cacert.crt \ --from-file=client.key=/var/run/secrets/openshift.io/source/client.key
为了避免必须再次输入密码,需要在构建中指定 source-to-image(S2I)镜像。但是,如果无法克隆存储库,您仍然必须指定用户名和密码才能推进构建。
其他资源
-
应用程序源代码中的
/var/run/secrets/openshift.io/source/
文件夹。
2.3.4.2.5. 从源代码基本身份验证创建 secret
基本身份验证需要 --username
和 --password
的组合,或者令牌方可与软件配置管理(SCM)服务器进行身份验证。
先决条件
- 用于访问私有存储库的用户名和密码。
流程
在使用
--username
和--password
访问私有存储库前首先创建 secret:$ oc create secret generic <secret_name> \ --from-literal=username=<user_name> \ --from-literal=password=<password> \ --type=kubernetes.io/basic-auth
使用令牌创建基本身份验证 secret:
$ oc create secret generic <secret_name> \ --from-literal=password=<token> \ --type=kubernetes.io/basic-auth
2.3.4.2.6. 从源代码 SSH 密钥身份验证创建 secret
基于 SSH 密钥的身份验证需要 SSH 私钥。
存储库密钥通常位于 $HOME/.ssh/
目录中,但默认名称为 id_dsa.pub
、id_ecdsa.pub
、id_ed25519.pub
或 id_rsa.pub
。
流程
生成 SSH 密钥凭证:
$ ssh-keygen -t ed25519 -C "your_email@example.com"
注意使用带有密语保护的 SSH 密钥会导致 OpenShift Container Platform 无法进行构建。提示输入密语(passphrase)时,请将其留空。
创建两个文件:公钥和对应的私钥(
id_dsa
、id_ecdsa
、id_ed25519
或id_rsa
之一)。这两项就位后,请查阅源代码控制管理 (SCM) 系统的手册来了解如何上传公钥。私钥用于访问您的私有存储库。在使用 SSH 密钥访问私有存储库之前,先创建 secret:
$ oc create secret generic <secret_name> \ --from-file=ssh-privatekey=<path/to/ssh/private/key> \ --from-file=<path/to/known_hosts> \ 1 --type=kubernetes.io/ssh-auth
- 1
- 可选:添加此字段可启用严格的服务器主机密钥检查。
警告在创建 secret 时跳过
known_hosts
文件会使构建容易受到中间人 (MITM) 攻击的影响。注意确保
known_hosts
文件中包含源代码主机条目。
2.3.4.2.7. 从源代码可信证书颁发机构创建 secret
在 Git 克隆操作期间受信任的 TLS 证书颁发机构(CA)集合内置于 OpenShift Container Platform 基础结构镜像中。如果 Git 服务器使用自签名证书或由镜像不信任的颁发机构签名的证书,您可以创建包含证书的 secret 或者禁用 TLS 验证。
如果您为 CA 证书创建 secret,OpenShift Container Platform 会在 Git 克隆操作过程中使用它来访问您的 Git 服务器。使用此方法比禁用 Git 的 SSL 验证要安全得多,后者接受所出示的任何 TLS 证书。
流程
使用 CA 证书文件创建 secret。
如果您的 CA 使用中间证书颁发机构,请合并
ca.crt
文件中所有 CA 的证书。使用以下命令:$ cat intermediateCA.crt intermediateCA.crt rootCA.crt > ca.crt
创建 secret:
$ oc create secret generic mycert --from-file=ca.crt=</path/to/file> 1
- 1
- 您必须使用密钥名称
ca.crt
。
2.3.4.2.8. 源 secret 组合
您可以组合使用不同的源克隆 secret 创建方法来满足特定的需求。
2.3.4.2.8.1. 使用 .gitconfig
文件创建基于 SSH 的身份验证 secret
您可以组合不同的方法开创建源克隆 secret 以满足特定的需求,例如使用 .gitconfig
文件的基于 SSH 的身份验证 secret。
先决条件
- SSH 身份验证
- .gitconfig 文件
流程
使用
.gitconfig
文件创建基于 SSH 的身份验证 secret:$ oc create secret generic <secret_name> \ --from-file=ssh-privatekey=<path/to/ssh/private/key> \ --from-file=<path/to/.gitconfig> \ --type=kubernetes.io/ssh-auth
2.3.4.2.8.2. 创建组合了 .gitconfig 文件和 CA 证书的 secret
您可以组合使用不同的源克隆 secret 创建方法来满足特定的需求,例如组合了 .gitconfig
文件和 CA 证书的 Secret。
先决条件
- .gitconfig 文件
- CA 证书
流程
创建组合了
.gitconfig
文件和 CA 证书的 secret:$ oc create secret generic <secret_name> \ --from-file=ca.crt=<path/to/certificate> \ --from-file=<path/to/.gitconfig>
2.3.4.2.8.3. 使用 CA 证书创建基本身份验证 secret
您可以组合使用不同的源克隆 secret 创建方法来满足特定的需求,例如组合了基本身份验证和 CA 证书的 secret。
先决条件
- 基本身份验证凭证
- CA 证书
流程
使用 CA 证书创建基本身份验证 secret:
$ oc create secret generic <secret_name> \ --from-literal=username=<user_name> \ --from-literal=password=<password> \ --from-file=ca-cert=</path/to/file> \ --type=kubernetes.io/basic-auth
2.3.4.2.8.4. 使用 .gitconfig 文件创建基本身份验证 secret
您可以组合使用不同的源克隆 secret 创建方法来满足特定的需求,例如组合了基本身份验证和 .gitconfig
文件的 secret。
先决条件
- 基本身份验证凭证
-
.gitconfig
文件
流程
使用
.gitconfig
文件创建基本身份验证 secret:$ oc create secret generic <secret_name> \ --from-literal=username=<user_name> \ --from-literal=password=<password> \ --from-file=</path/to/.gitconfig> \ --type=kubernetes.io/basic-auth
2.3.4.2.8.5. 使用 .gitconfig 文件和 CA 证书创建基本身份验证 secret
您可以组合使用不同的源克隆 secret 创建方法来满足特定的需求,例如组合了基本身份验证、.gitconfig
文件和证书颁发机构(CA)证书的 Secret。
先决条件
- 基本身份验证凭证
-
.gitconfig
文件 - CA 证书
流程
使用
.gitconfig
文件和 CA 证书创建基本身份验证 secret:$ oc create secret generic <secret_name> \ --from-literal=username=<user_name> \ --from-literal=password=<password> \ --from-file=</path/to/.gitconfig> \ --from-file=ca-cert=</path/to/file> \ --type=kubernetes.io/basic-auth
2.3.5. 二进制(本地)来源
从本地文件系统流传输内容到构建器称为 Binary
类型构建。对于此类构建,BuildConfig.spec.source.type
的对应值为 Binary
。
这种源类型的独特之处在于,它仅基于您对 oc start-build
的使用而加以利用。
二进制类型构建需要从本地文件系统流传输内容,因此无法自动触发二进制类型构建,如镜像更改触发器。这是因为无法提供二进制文件。同样,您无法从 web 控制台启动二进制类型构建。
要使用二进制构建,请使用以下选项之一调用 oc start-build
:
-
--from-file
:指定的文件内容作为二进制流发送到构建器。您还可以指定文件的 URL。然后,构建器将数据存储在构建上下文顶端的同名文件中。 -
--from-dir
和--from-repo
:内容存档下来,并作为二进制流发送给构建器。然后,构建器在构建上下文目录中提取存档的内容。使用--from-dir
时,您还可以指定提取的存档的 URL。 -
--from-archive
:指定的存档发送到构建器,并在构建器上下文目录中提取。此选项与--from-dir
的行为相同;只要这些选项的参数是目录,就会首先在主机上创建存档。
在上方列出的每种情形中:
-
如果
BuildConfig
已经定义了Binary
源类型,它会有效地被忽略并且替换成客户端发送的内容。 -
如果
BuildConfig
定义了Git
源类型,则会动态禁用它,因为Binary
和Git
是互斥的,并且二进制流中提供给构建器的数据将具有优先权。
您可以将 HTTP 或 HTTPS 方案的 URL 传递给 --from-file
和 --from-archive
,而不传递文件名。将 -from-file
与 URL 结合使用时,构建器镜像中文件的名称由 web 服务器发送的 Content-Disposition
标头决定,如果该标头不存在,则由 URL 路径的最后一个组件决定。不支持任何形式的身份验证,也无法使用自定义 TLS 证书或禁用证书验证。
使用 oc new-build --binary =true
时,该命令可确保强制执行与二进制构建关联的限制。生成的 BuildConfig
具有 Binary
源类型,这意味着为此 BuildConfig
运行构建的唯一有效方法是使用 oc start-build
和其中一个 --from
选项来提供必需的二进制数据。
Dockerfile 和 contextDir
源选项对二进制构建具有特殊含义。
Dockerfile 可以与任何二进制构建源一起使用。如果使用 Dockerfile 且二进制流是存档,则其内容将充当存档中任何 Dockerfile 的替代 Dockerfile。如果将 Dockerfile 与 --from-file
参数搭配 使用,且文件参数命名为 Dockerfile,则 Dockerfile 的值将替换二进制流中的值。
如果是二进制流封装提取的存档内容,contextDir
字段的值将解释为存档中的子目录,并且在有效时,构建器将在执行构建之前更改到该子目录。
2.3.6. 输入 secret 和配置映射
要防止输入 secret 和配置映射的内容出现在构建输出容器镜像中,请使用 Docker 构建和源至镜像构建策略中的构建 卷。
有时候,构建操作需要凭证或其他配置数据才能访问依赖的资源,但又不希望将这些信息放在源代码控制中。您可以定义输入 secret 和输入配置映射。
例如,在使用 Maven 构建 Java 应用程序时,可以设置通过私钥访问的 Maven Central 或 JCenter 的私有镜像。要从该私有镜像下载库,您必须提供以下内容:
-
配置了镜像的 URL 和连接设置的
settings.xml
文件。 -
设置文件中引用的私钥,例如
~/.ssh/id_rsa
。
为安全起见,不应在应用程序镜像中公开您的凭证。
示例中描述的是 Java 应用程序,但您可以使用相同的方法将 SSL 证书添加到 /etc/ssl/certs
目录,以及添加 API 密钥或令牌、许可证文件等。
2.3.6.1. 什么是 secret?
Secret
对象类型提供了一种机制来保存敏感信息,如密码、OpenShift Container Platform 客户端配置文件、dockercfg
文件和私有源存储库凭证等。secret 将敏感内容与 Pod 分离。您可以使用卷插件将 secret 信息挂载到容器中,系统也可以使用 secret 代表 Pod 执行操作。
YAML Secret 对象定义
apiVersion: v1 kind: Secret metadata: name: test-secret namespace: my-namespace type: Opaque 1 data: 2 username: <username> 3 password: <password> stringData: 4 hostname: myapp.mydomain.com 5
2.3.6.1.1. secret 的属性
主要属性包括:
- Secret 数据可以独立于其定义来引用。
- Secret 数据卷由临时文件工具 (tmpfs) 支持,永远不会停留在节点上。
- secret 数据可以在命名空间内共享。
2.3.6.1.2. secret 的类型
type
字段中的值指明 secret 的键名称和值的结构。此类型可用于强制使 secret 对象中存在用户名和密钥。如果您不想进行验证,请使用 opaque
类型,这也是默认类型。
指定以下一种类型来触发最小服务器端验证,确保 secret 数据中存在特定的键名称:
-
kubernetes.io/service-account-token
。使用服务帐户令牌。 -
kubernetes.io/dockercfg
。将.dockercfg
文件用于所需的 Docker 凭证。 -
kubernetes.io/dockerconfigjson
。将.docker/config.json
文件用于所需的 Docker 凭证。 -
kubernetes.io/basic-auth
。与基本身份验证搭配使用。 -
kubernetes.io/ssh-auth
。搭配 SSH 密钥身份验证使用。 -
kubernetes.io/tls
。搭配 TLS 证书颁发机构使用。
如果不想进行验证,设置 type= Opaque
。这意味着,secret 不声明符合键名称或值的任何约定。opaque
secret 允许使用无结构 key:value
对,可以包含任意值。
您可以指定其他任意类型,如 example.com/my-secret-type
。这些类型不在服务器端强制执行,但代表 secret 的创建者意在符合该类型的键/值要求。
2.3.6.1.3. 更新 secret
当修改 secret 的值时,已在被运行的 Pod 使用的 secret 值不会被动态更新。要更改 secret,必须删除原始 pod 并创建一个新 pod,在某些情况下,具有相同的 PodSpec
。
更新 secret 遵循与部署新容器镜像相同的工作流。您可以使用 kubectl rolling-update
命令。
secret 中的 resourceVersion
值不在引用时指定。因此,如果在 pod 启动的同时更新 secret,则将不能定义用于 pod 的 secret 版本。
目前,无法检查 Pod 创建时使用的 secret 对象的资源版本。按照计划 Pod 将报告此信息,以便控制器可以重启使用旧 resourceVersion
的 Pod。在此期间,请勿更新现有 secret 的数据,而应创建具有不同名称的新数据。
2.3.6.2. 创建 secret
您必须先创建 secret,然后创建依赖于此 secret 的 Pod。
在创建 secret 时:
- 使用 secret 数据创建 secret 对象。
- 更新 pod 的服务帐户以允许引用该 secret。
-
创建以环境变量或文件(使用
secret
卷)形式消耗 secret 的 pod。
流程
使用创建命令从 JSON 或 YAML 文件创建 secret 对象:
$ oc create -f <filename>
例如,您可以从本地的
.docker/config.json
文件创建一个 secret:$ oc create secret generic dockerhub \ --from-file=.dockerconfigjson=<path/to/.docker/config.json> \ --type=kubernetes.io/dockerconfigjson
此命令将生成名为
dockerhub
的 secret JSON 规格并创建该对象。YAML Opaque Secret 对象定义
apiVersion: v1 kind: Secret metadata: name: mysecret type: Opaque 1 data: username: <username> password: <password>
- 1
- 指定一个 opaque secret。
Docker 配置 JSON 文件对象定义
apiVersion: v1 kind: Secret metadata: name: aregistrykey namespace: myapps type: kubernetes.io/dockerconfigjson 1 data: .dockerconfigjson:bm5ubm5ubm5ubm5ubm5ubm5ubm5ubmdnZ2dnZ2dnZ2dnZ2dnZ2dnZ2cgYXV0aCBrZXlzCg== 2
2.3.6.3. 使用 secret
创建 secret 后,可以创建一个 Pod 来引用您的 secret,再获取日志,然后删除 Pod。
流程
创建要引用您的 secret 的 Pod:
$ oc create -f <your_yaml_file>.yaml
获取日志:
$ oc logs secret-example-pod
删除 Pod:
$ oc delete pod secret-example-pod
其他资源
带有 secret 数据的 YAML 文件示例:
将创建四个文件的 secret 的 YAML
apiVersion: v1 kind: Secret metadata: name: test-secret data: username: <username> 1 password: <password> 2 stringData: hostname: myapp.mydomain.com 3 secret.properties: |- 4 property1=valueA property2=valueB
pod 的 YAML 使用 secret 数据填充卷中的文件
apiVersion: v1 kind: Pod metadata: name: secret-example-pod spec: containers: - name: secret-test-container image: busybox command: [ "/bin/sh", "-c", "cat /etc/secret-volume/*" ] volumeMounts: # name must match the volume name below - name: secret-volume mountPath: /etc/secret-volume readOnly: true volumes: - name: secret-volume secret: secretName: test-secret restartPolicy: Never
pod 的 YAML 使用 secret 数据填充环境变量
apiVersion: v1 kind: Pod metadata: name: secret-example-pod spec: containers: - name: secret-test-container image: busybox command: [ "/bin/sh", "-c", "export" ] env: - name: TEST_SECRET_USERNAME_ENV_VAR valueFrom: secretKeyRef: name: test-secret key: username restartPolicy: Never
一个 Build Config 的 YAML 定义,在环境变量中使用 secret 数据
apiVersion: build.openshift.io/v1 kind: BuildConfig metadata: name: secret-example-bc spec: strategy: sourceStrategy: env: - name: TEST_SECRET_USERNAME_ENV_VAR valueFrom: secretKeyRef: name: test-secret key: username
2.3.6.4. 添加输入 secret 和配置映射
要向构建提供凭证和其他配置数据,而不将其放在源控制中,您可以定义输入 secret 和输入配置映射。
在某些情况下,构建操作需要凭证或其他配置数据才能访问依赖的资源。要使该信息在不置于源控制中的情况下可用,您可以定义输入 secret 和输入配置映射。
流程
将输入 secret 和配置映射添加到现有的 BuildConfig
对象中:
如果
ConfigMap
对象不存在,则进行创建:$ oc create configmap settings-mvn \ --from-file=settings.xml=<path/to/settings.xml>
这会创建一个名为
settings-mvn
的新配置映射,其中包含settings.xml
文件的纯文本内容。提示您还可以应用以下 YAML 来创建配置映射:
apiVersion: core/v1 kind: ConfigMap metadata: name: settings-mvn data: settings.xml: | <settings> … # Insert maven settings here </settings>
如果
Secret
对象不存在,则进行创建:$ oc create secret generic secret-mvn \ --from-file=ssh-privatekey=<path/to/.ssh/id_rsa> --type=kubernetes.io/ssh-auth
这会创建一个名为
secret-mvn
的新 secret,其包含id_rsa
私钥的 base64 编码内容。提示您还可以应用以下 YAML 来创建输入 secret:
apiVersion: core/v1 kind: Secret metadata: name: secret-mvn type: kubernetes.io/ssh-auth data: ssh-privatekey: | # Insert ssh private key, base64 encoded
将配置映射和 secret 添加到现有
BuildConfig
对象的source
部分中:source: git: uri: https://github.com/wildfly/quickstart.git contextDir: helloworld configMaps: - configMap: name: settings-mvn secrets: - secret: name: secret-mvn
要在新 BuildConfig
对象中包含 secret 和配置映射,请运行以下命令:
$ oc new-build \ openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \ --context-dir helloworld --build-secret “secret-mvn” \ --build-config-map "settings-mvn"
在构建期间,settings.xml
和 id_rsa
文件将复制到源代码所在的目录中。在 OpenShift Container Platform S2I 构建器镜像中,这是镜像的工作目录,使用 Dockerfile
中的 WORKDIR
指令设置。如果要指定其他目录,请在定义中添加 destinationDir
:
source: git: uri: https://github.com/wildfly/quickstart.git contextDir: helloworld configMaps: - configMap: name: settings-mvn destinationDir: ".m2" secrets: - secret: name: secret-mvn destinationDir: ".ssh"
您还可以指定创建新 BuildConfig
对象时的目标目录:
$ oc new-build \ openshift/wildfly-101-centos7~https://github.com/wildfly/quickstart.git \ --context-dir helloworld --build-secret “secret-mvn:.ssh” \ --build-config-map "settings-mvn:.m2"
在这两种情况下,settings.xml
文件都添加到构建环境的 ./.m2
目录中,而 id_rsa
密钥则添加到 ./.ssh
目录中。
2.3.6.5. Source-to-Image 策略
采用 Source
策略时,所有定义的输入 secret 都复制到对应的 destinationDir
中。如果 destinationDir
留空,则 secret 会放置到构建器镜像的工作目录中。
当 destinationDir
是一个相对路径时,使用相同的规则。secret 放置在相对于镜像工作目录的路径中。如果构建器镜像中不存在 destinationDir
路径中的最终目录,则会创建该目录。destinationDir
中的所有上述目录都必须存在,否则会发生错误。
输入 secret 将以全局可写(具有 0666
权限)形式添加,并且在执行 assemble
脚本后其大小会被截断为零。也就是说,生成的镜像中会包括这些 secret 文件,但出于安全原因,它们将为空。
assemble
脚本完成后不会截断输入配置映射。
2.3.6.6. Docker 策略
采用 docker 策略时,您可以使用 Dockerfile 中的 ADD
和 COPY
指令,将所有定义的输入 secret 添加到容器镜像中。
如果没有为 secret 指定 destinationDir
,则文件将复制到 Dockerfile 所在的同一目录中。如果将一个相对路径指定为 destinationDir
,则 secret 复制到相对于 Dockerfile 位置的该目录中。这样,secret 文件可供 Docker 构建操作使用,作为构建期间使用的上下文目录的一部分。
引用 secret 和配置映射数据的 Dockerfile 示例
FROM centos/ruby-22-centos7 USER root COPY ./secret-dir /secrets COPY ./config / # Create a shell script that will output secrets and ConfigMaps when the image is run RUN echo '#!/bin/sh' > /input_report.sh RUN echo '(test -f /secrets/secret1 && echo -n "secret1=" && cat /secrets/secret1)' >> /input_report.sh RUN echo '(test -f /config && echo -n "relative-configMap=" && cat /config)' >> /input_report.sh RUN chmod 755 /input_report.sh CMD ["/bin/sh", "-c", "/input_report.sh"]
用户应该从最终的应用程序镜像中移除输入 secret,以便从该镜像运行的容器中不会存在这些 secret。但是,secret 仍然存在于它们添加到的层中的镜像本身内。这一移除是 Dockerfile 本身的一部分。
为防止输入 secret 和配置映射的内容出现在构建输出容器镜像中并完全避免此移除过程,请在 Docker 构建策略中使用构建卷。
2.3.6.7. Custom 策略
使用 Custom 策略时,所有定义的输入 secret 和配置映射都位于 /var/run/secrets/openshift.io/build
目录中的构建器容器中。自定义构建镜像必须正确使用这些 secret 和配置映射。使用 Custom 策略时,您可以按照 Custom 策略选项中所述定义 secret。
现有策略 secret 与输入 secret 之间没有技术差异。但是,构建器镜像可以区分它们并以不同的方式加以使用,具体取决于您的构建用例。
输入 secret 始终挂载到 /var/run/secrets/openshift.io/build
目录中,或您的构建器可以解析 $BUILD
环境变量(包含完整构建对象)。
如果命名空间和节点上存在 registry 的 pull secret,构建会默认使用命名空间中的 pull secret。
2.3.7. 外部工件 (artifact)
建议不要将二进制文件存储在源存储库中。因此,您必须定义一个构建,在构建过程中拉取其他文件,如 Java .jar
依赖项。具体方法取决于使用的构建策略。
对于 Source 构建策略,必须在 assemble
脚本中放入适当的 shell 命令:
.s2i/bin/assemble
文件
#!/bin/sh APP_VERSION=1.0 wget http://repository.example.com/app/app-$APP_VERSION.jar -O app.jar
.s2i/bin/run
文件
#!/bin/sh exec java -jar app.jar
对于 Docker 构建策略,您必须修改 Dockerfile 并通过 RUN
指令 调用 shell 命令:
Dockerfile 摘录
FROM jboss/base-jdk:8 ENV APP_VERSION 1.0 RUN wget http://repository.example.com/app/app-$APP_VERSION.jar -O app.jar EXPOSE 8080 CMD [ "java", "-jar", "app.jar" ]
在实践中,您可能希望将环境变量用于文件位置,以便要下载的具体文件能够使用 BuildConfig
中定义的环境变量来自定义,而不必更新 Dockerfile 或 assemble
脚本。
您可以选择不同方法来定义环境变量:
-
使用
.s2i/environment
文件(仅适用于 Source 构建策略) -
在
BuildConfig
中设置 -
使用
oc start-build --env
明确提供(仅适用于手动触发的构建)
2.3.8. 将 docker 凭证用于私有容器镜像仓库
您可以为构建提供 .docker/config.json
文件,在文件中包含私有容器 registry 的有效凭证。这样,您可以将输出镜像推送到私有容器镜像 registry 中,或从需要身份验证的私有容器镜像 registry 中拉取构建器镜像。
您可以为同一 registry 中的多个存储库提供凭证,每个软件仓库都有特定于该 registry 路径的凭证。
对于 OpenShift Container Platform 容器镜像 registry,这不是必需的,因为 OpenShift Container Platform 会自动为您生成 secret。
默认情况下,.docker/config.json
文件位于您的主目录中,并具有如下格式:
auths: index.docker.io/v1/: 1 auth: "YWRfbGzhcGU6R2labnRib21ifTE=" 2 email: "user@example.com" 3 docker.io/my-namespace/my-user/my-image: 4 auth: "GzhYWRGU6R2fbclabnRgbkSp="" email: "user@example.com" docker.io/my-namespace: 5 auth: "GzhYWRGU6R2deesfrRgbkSp="" email: "user@example.com"
您可以定义多个容器镜像 registry,或在同一 registry 中定义多个存储库。或者,也可以通过运行 docker login
命令将身份验证条目添加到此文件中。如果文件不存在,则会创建此文件。
Kubernetes 提供Secret
对象,可用于存储配置和密码。
先决条件
-
您必须有一个
.docker/config.json
文件。
流程
从本地
.docker/config.json
文件创建 secret:$ oc create secret generic dockerhub \ --from-file=.dockerconfigjson=<path/to/.docker/config.json> \ --type=kubernetes.io/dockerconfigjson
这将生成名为
dockerhub
的 secret 的 JSON 规格并创建该对象。将
pushSecret
字段添加到BuildConfig
中的output
部分,并将它设为您创建的secret
的名称,上例中为dockerhub
:spec: output: to: kind: "DockerImage" name: "private.registry.com/org/private-image:latest" pushSecret: name: "dockerhub"
您可以使用
oc set build-secret
命令在构建配置上设置推送 secret:$ oc set build-secret --push bc/sample-build dockerhub
您还可以将 push secret 与构建使用的服务帐户链接,而不指定
pushSecret
字段。默认情况下,构建使用builder
服务帐户。如果 secret 包含与托管构建输出镜像的存储库匹配的凭证,则 push secret 会自动添加到构建中。$ oc secrets link builder dockerhub
通过指定
pullSecret
字段(构建策略定义的一部分),从私有容器镜像 registry 拉取构建器容器镜像:strategy: sourceStrategy: from: kind: "DockerImage" name: "docker.io/user/private_repository" pullSecret: name: "dockerhub"
您可以使用
oc set build-secret
命令在构建配置上设置拉取 secret:$ oc set build-secret --pull bc/sample-build dockerhub
注意本例在 Source 构建中使用
pullSecret
,但也适用于 Docker 构建和 Custom 构建。您还可以将 pull secret 链接到构建使用的服务帐户,而不指定
pullSecret
字段。默认情况下,构建使用builder
服务帐户。如果 secret 包含与托管构建的输入镜像的存储库匹配的凭证,pull secret 会自动添加到构建中。将 pull secret 链接到构建使用的服务帐户,而不指定pullSecret
字段:$ oc secrets link builder dockerhub
注意您必须在
BuildConfig
spec 中指定一个from
镜像,才能利用此功能。由oc new-build
或oc new-app
生成的 Docker 策略构建在某些情况下可能无法进行这个操作。
2.3.9. 构建环境
与 Pod 环境变量一样,可以定义构建环境变量,在使用 Downward API 时引用其他源或变量。需要注意一些例外情况。
您也可以使用 oc set env
命令管理 BuildConfig
中定义的环境变量。
不支持在构建环境变量中使用 valueFrom
引用容器资源,因为这种引用在创建容器之前解析。
2.3.9.1. 使用构建字段作为环境变量
您可以注入构建对象的信息,使用 fieldPath
环境变量源指定要获取值的字段的 JsonPath
。
Jenkins Pipeline 策略不支持将 valueFrom
语法用于环境变量。
流程
将
fieldPath
环境变量源设置为您有兴趣获取其值的字段的JsonPath
:env: - name: FIELDREF_ENV valueFrom: fieldRef: fieldPath: metadata.name
2.3.9.2. 使用 secret 作为环境变量
您可以使用 valueFrom
语法,将 secret 的键值作为环境变量提供。
此方法在构建容器集控制台的输出中以纯文本形式显示机密。要避免这种情况,请使用输入 secret 和配置映射。
流程
要将 secret 用作环境变量,请设置
valueFrom
语法:apiVersion: build.openshift.io/v1 kind: BuildConfig metadata: name: secret-example-bc spec: strategy: sourceStrategy: env: - name: MYVAL valueFrom: secretKeyRef: key: myval name: mysecret
其他资源
2.3.10. 服务用(service serving)证书 secret
服务用证书 secret 旨在支持需要开箱即用证书的复杂中间件应用程序。它的设置与管理员工具为节点和 master 生成的服务器证书相同。
流程
要保护与您服务的通信,请让集群生成的签名的服务证书/密钥对保存在您的命令空间的 secret 中。
在服务上设置
service.beta.openshift.io/serving-cert-secret-name
注解,并将值设置为您要用于 secret 的名称。然后,您的
PodSpec
可以挂载该 secret。当它可用时,您的 Pod 会运行。该证书对内部服务 DNS 名称<service.name>.<service.namespace>.svc
有效。证书和密钥采用 PEM 格式,分别存储在
tls.crt
和tls.key
中。证书/密钥对在接近到期时自动替换。在 secret 的service.beta.openshift.io/expiry
注解中查看过期日期,其格式为 RFC3339。
在大多数情形中,服务 DNS 名称 <service.name>.<service.namespace>.svc
不可从外部路由。<service.name>.<service.namespace>.svc
的主要用途是集群内或服务内通信,也用于重新加密路由。
其他 pod 可以信任由集群创建的证书,这些证书只为内部 DNS 名称签名,方法是使用 pod 中自动挂载的 /var/run/secrets/kubernetes.io/serviceaccount/service-ca.crt
文件中的证书颁发机构(CA)捆绑包。
此功能的签名算法是 x509.SHA256WithRSA
。要手动轮转,请删除生成的 secret。这会创建新的证书。
2.3.11. secret 限制
若要使用一个 secret,Pod 需要引用该 secret。可以通过三种方式将 secret 用于 Pod:
- 为容器产生环境变量。
- 作为挂载到一个或多个容器上的卷中的文件。
- 在拉取 Pod 的镜像时通过 kubelet 使用。
卷类型 secret 使用卷机制将数据作为文件写入到容器中。imagePullSecrets
使用服务帐户将 secret 自动注入到命名空间中的所有 Pod。
当模板包含 secret 定义时,模板使用提供的 secret 的唯一方法是确保验证 secret 卷源通过验证,并且指定的对象引用实际指向 Secret
类型的对象。因此,secret 需要在依赖它的任何 Pod 之前创建。确保这一点的最有效方法是通过使用服务帐户自动注入。
Secret API 对象驻留在命名空间中。它们只能由同一命名空间中的 pod 引用。
每个 secret 的大小限制为 1MB。这是为了防止创建可能会耗尽 apiserver 和 kubelet 内存的大型 secret。不过,创建大量较小的 secret 也可能耗尽内存。
2.4. 管理构建输出
以下小节提供了管理构建输出的概览和说明。
2.4.1. 构建输出
使用 docker 或 source-to-image(S2I)策略的构建会导致创建新的容器镜像。镜像而后被推送到由 Build
规格的 output
部分中指定的容器镜像 registry 中。
如果输出类型是 ImageStreamTag
,则镜像将推送到集成的 OpenShift 镜像 registry 并在指定的镜像流中标记。如果输出类型为 DockerImage
,则输出引用的名称将用作 docker push 规格。规格中可以包含 registry;如果没有指定 registry,则默认为 DockerHub。如果 Build 规格的 output 部分为空,则构建结束时不推送镜像。
输出到 ImageStreamTag
spec: output: to: kind: "ImageStreamTag" name: "sample-image:latest"
输出到 docker Push 规格
spec: output: to: kind: "DockerImage" name: "my-registry.mycompany.com:5000/myimages/myimage:tag"
2.4.2. 输出镜像环境变量
Docker 和 source-to-image(S2I)策略构建设置输出镜像的以下环境变量:
变量 | 描述 |
---|---|
| 构建的名称 |
| 构建的命名空间 |
| 构建的源 URL |
| 构建中使用的 Git 引用 |
| 构建中使用的源提交 |
此外,任何用户定义的环境变量(例如,使用 S2I 或 docker 策略选项配置的环境变量)也将是输出镜像环境变量列表的一部分。
2.4.3. 输出镜像标签
docker 和 Source-to-Image (S2I) 构建设置输出镜像的以下标签:
标签 | 描述 |
---|---|
| 构建中使用的源提交的作者 |
| 构建中使用的源提交的日期 |
| 构建中使用的源提交的哈希值 |
| 构建中使用的源提交的消息 |
| 源中指定的分支或引用 |
| 构建的源 URL |
您还可以使用 BuildConfig.spec.output.imageLabels
字段指定将应用到构建配置构建的每个镜像的自定义标签列表。
应用到所构建镜像的自定义标签
spec: output: to: kind: "ImageStreamTag" name: "my-image:latest" imageLabels: - name: "vendor" value: "MyCompany" - name: "authoritative-source-url" value: "registry.mycompany.com"
2.5. 使用构建策略
以下小节定义了受支持的主要构建策略,以及它们的使用方法。
2.5.1. Docker 构建
OpenShift Container Platform 使用 Buildah 从 Dockerfile 构建容器镜像。有关使用 Dockerfile 构建容器镜像的更多信息,请参阅 Dockerfile 参考文档。
如果使用 buildArgs
数组设置 Docker 构建参数,请参阅 Dockerfile 参考文档中了解 ARG 和 FROM 如何交互。
2.5.1.1. 替换 Dockerfile FROM 镜像
您可以将 Dockerfile 中的 FROM
指令替换为 BuildConfig
对象的 from
。如果 Dockerfile 使用多阶段构建,最后一个 FROM
指令中的镜像将被替换。
流程
将 Dockerfile 中的 FROM
指令替换为 BuildConfig
中的 from
。
strategy: dockerStrategy: from: kind: "ImageStreamTag" name: "debian:latest"
2.5.1.2. 使用 Dockerfile 路径
默认情况下,docker 构建使用位于 BuildConfig.spec.source.contextDir
字段中指定的上下文的根目录下的 Dockerfile。
dockerfilePath
字段允许构建使用不同的路径来定位 Dockerfile,该路径相对于 BuildConfig.spec.source.contextDir
字段。它可以是不同于默认 Dockerfile 的其他文件名,如 MyDockerfile
,也可以是子目录中 Dockerfile 的路径,如 dockerfiles/app1/Dockerfile
。
流程
要通过构建的 dockerfilePath
字段使用不同的路径来定位 Dockerfile,请设置:
strategy: dockerStrategy: dockerfilePath: dockerfiles/app1/Dockerfile
2.5.1.3. 使用 Docker 环境变量
要将环境变量提供给 docker 构建过程和生成的镜像使用,您可以在构建配置的 dockerStrategy
定义中添加环境变量。
这里定义的环境变量作为单个 ENV
Dockerfile 指令直接插入到 FROM
指令后,以便稍后可在 Dockerfile 内引用该变量。
流程
变量在构建期间定义并保留在输出镜像中,因此它们也会出现在运行该镜像的任何容器中。
例如,定义要在构建和运行时使用的自定义 HTTP 代理:
dockerStrategy: ... env: - name: "HTTP_PROXY" value: "http://myproxy.net:5187/"
您还可以使用 oc set env
命令管理构建配置中定义的环境变量。
2.5.1.4. 添加 Docker 构建参数
您可以使用 buildArgs
数组来设置 docker build 参数。构建参数将在构建启动时传递给 docker。
请参阅 Dockerfile 参考文档中的 ARG 和 FROM 如何交互。
流程
要设置 docker 构建参数,请在 buildArgs
中添加条目,它位于 BuildConfig
对象的 dockerStrategy
定义中。例如:
dockerStrategy: ... buildArgs: - name: "foo" value: "bar"
只支持 name
和 value
字段。valueFrom
字段上的任何设置都会被忽略。
2.5.1.5. 使用 docker 构建的 Squash 层
通常,Docker 构建会为 Dockerfile 中的每条指令都创建一个层。将 imageOptimizationPolicy
设置为 SkipLayers
,可将所有指令合并到基础镜像顶部的单个层中。
流程
将
imageOptimizationPolicy
设置为SkipLayers
:strategy: dockerStrategy: imageOptimizationPolicy: SkipLayers
2.5.1.6. 使用构建卷
您可以挂载构建卷,为运行的构建授予您不想在输出容器镜像中保留的信息的访问权限。
构建卷提供仅在构建时需要的敏感信息,如存储库凭据。构建卷与构建输入不同,后者的数据可以保留在输出容器镜像中。
构建卷的挂载点(运行中的构建从中读取数据)在功能上与 pod 卷挂载 类似。
流程
在
BuildConfig
对象的dockerStrategy
定义中,将任何构建卷添加到volumes
数组中。例如:spec: dockerStrategy: volumes: - name: secret-mvn 1 mounts: - destinationPath: /opt/app-root/src/.ssh 2 source: type: Secret 3 secret: secretName: my-secret 4 - name: settings-mvn 5 mounts: - destinationPath: /opt/app-root/src/.m2 6 source: type: ConfigMap 7 configMap: name: my-config 8 - name: my-csi-volume 9 mounts: - destinationPath: /opt/app-root/src/some_path 10 source: type: CSI 11 csi: driver: csi.sharedresource.openshift.io 12 readOnly: true 13 volumeAttributes: 14 attribute: value
共享资源 CSI 驱动程序作为技术预览提供。
2.5.2. Source-to-image 构建
Source-to-Image (S2I) 是一种用于构建可重复生成的容器镜像的工具。它通过将应用程序源代码注入容器镜像并汇编新镜像来生成可随时运行的镜像。新镜像融合了基础镜像(构建器)和构建的源代码,并可搭配 buildah run
命令使用。S2I 支持递增构建,可重复利用以前下载的依赖项和过去构建的工件等。
2.5.2.1. 执行 source-to-image 增量构建
Source-to-image (S2I) 可以执行增量构建,也就是能够重复利用过去构建的镜像中的工件。
流程
要创建增量构建,请创建对策略定义进行以下修改:
strategy: sourceStrategy: from: kind: "ImageStreamTag" name: "incremental-image:latest" 1 incremental: true 2
其他资源
- 如需有关如何创建支持增量构建的构建器镜像的信息,请参阅 S2I 要求。
2.5.2.2. 覆盖 source-to-image 构建器镜像脚本
您可以覆盖构建器镜像提供的 assemble
、run
和 save-artifacts
source-to-image(S2I)脚本。
流程
要覆盖构建器镜像提供的 assemble
、run
和 save-artifacts
S2I 脚本,请执行以下任一操作:
-
在应用程序源存储库的
.s2i/bin
目录中提供assemble
、run
或save-artifacts
脚本。 提供包含脚本的目录的 URL,作为策略定义的一部分。例如:
strategy: sourceStrategy: from: kind: "ImageStreamTag" name: "builder-image:latest" scripts: "http://somehost.com/scripts_directory" 1
- 1
- 此路径会将
run
、assemble
和save-artifacts
附加到其中。如果找到任何或所有脚本,将使用它们代替镜像中提供的同名脚本。
位于 scripts
URL 的文件优先于源存储库的 .s2i/bin
中的文件。
2.5.2.3. Source-to-image 环境变量
可以通过两种方式将环境变量提供给源构建过程和生成的镜像。环境文件和 BuildConfig 环境值。提供的变量将存在于构建过程和输出镜像中。
2.5.2.3.1. 使用 Source-to-image 环境文件
利用源代码构建,您可以在应用程序内设置环境值(每行一个),方法是在源存储库中的 .s2i/environment
文件中指定它们。此文件中指定的环境变量存在于构建过程和输出镜像。
如果您在源存储库中提供 .s2i/environment
文件,则 source-to-image(S2I)会在构建期间读取此文件。这允许自定义构建行为,因为 assembe
脚本可能会使用这些变量。
流程
例如,在构建期间禁用 Rails 应用程序的资产编译:
-
在
.s2i/environment
文件中添加DISABLE_ASSET_COMPILATION=true
。
除了构建之外,指定的环境变量也可以在运行的应用程序本身中使用。例如,使 Rails 应用程序在 development
模式而非 production
模式中启动:
-
在
.s2i/environment
文件中添加RAILS_ENV=development
。
使用镜像部分中提供了各个镜像支持的环境变量的完整列表。
2.5.2.3.2. 使用 Source-to-image 构建配置环境
您可以在构建配置的 sourceStrategy
定义中添加环境变量。这里定义的环境变量可在 assemble
脚本执行期间看到,也会在输出镜像中定义,使它们能够供 run
脚本和应用程序代码使用。
流程
例如,禁用 Rails 应用程序的资产编译:
sourceStrategy: ... env: - name: "DISABLE_ASSET_COMPILATION" value: "true"
其他资源
- “构建环境”部分提供了更多高级指导。
-
您还可以使用
oc set env
命令管理构建配置中定义的环境变量。
2.5.2.4. 忽略 source-to-image 源文件
Source-to-Image(S2I) 支持 .s2iignore
文件,该文件包含了需要被忽略的文件列表。构建工作目录中的文件(由各种输入源提供)若与 .s2iignore
文件中指定的文件匹配,将不会提供给 assemble
脚本使用。
2.5.2.5. 使用 Source-to-image 从源代码创建镜像
Source-to-Image (S2I) 是一种框架,它可以轻松地将应用程序源代码作为输入,生成可运行编译的应用程序的新镜像。
使用 S2I 构建可重复生成的容器镜像的主要优点是便于开发人员使用。作为构建器镜像作者,您必须理解两个基本概念,构建过程和 S2I 脚本,才能让您的镜像提供最佳的 S2I 性能。
2.5.2.5.1. 了解 source-to-image 构建过程
构建过程包含以下三个基本元素,这些元素组合成最终的容器镜像:
- 源
- Source-to-image(S2I)脚本
- 构建器镜像
S2I 生成带有构建器镜像的 Dockerfile 作为第一个 FROM
指令。然后,由 S2I 生成的 Dockerfile 会被传递给 Buildah。
2.5.2.5.2. 如何编写 Source-to-image 脚本
您可以使用任何编程语言编写 S2I 脚本,只要脚本可在构建器镜像中执行。S2I 支持多种提供 assemble
/run
/save-artifacts
脚本的选项。每次构建时按以下顺序检查所有这些位置:
- 构建配置中指定的脚本。
-
在应用程序源
.s2i/bin
目录中找到的脚本。 -
在默认镜像 URL 中找到的带有
io.openshift.s2i.scripts-url
标签的脚本。
镜像中指定的 io.openshift.s2i.scripts-url
标签和构建配置中指定的脚本都可以采用以下形式之一:
-
image:///path_to_scripts_dir
:镜像中 S2I 脚本所处目录的绝对路径 -
file:///path_to_scripts_dir
:主机上 S2I 脚本所处目录的相对或绝对路径 -
http(s)://path_to_scripts_dir
:S2I 脚本所处目录的 URL
脚本 | 描述 |
---|---|
|
|
|
|
|
这些依赖项会收集到一个 |
|
借助 |
|
借助
注意
建议将 |
S2I 脚本示例
以下示例 S2I 脚本采用 Bash 编写。每个示例都假定其 tar
内容解包到 /tmp/s2i
目录中。
assemble
脚本:
#!/bin/bash # restore build artifacts if [ "$(ls /tmp/s2i/artifacts/ 2>/dev/null)" ]; then mv /tmp/s2i/artifacts/* $HOME/. fi # move the application source mv /tmp/s2i/src $HOME/src # build application artifacts pushd ${HOME} make all # install the artifacts make install popd
run
脚本:
#!/bin/bash # run the application /opt/application/run.sh
save-artifacts
脚本:
#!/bin/bash pushd ${HOME} if [ -d deps ]; then # all deps contents to tar stream tar cf - deps fi popd
usage
脚本:
#!/bin/bash # inform the user how to use the image cat <<EOF This is a S2I sample builder image, to use it, install https://github.com/openshift/source-to-image EOF
其他资源
2.5.2.6. 使用构建卷
您可以挂载构建卷,为运行的构建授予您不想在输出容器镜像中保留的信息的访问权限。
构建卷提供仅在构建时需要的敏感信息,如存储库凭据。构建卷与构建输入不同,后者的数据可以保留在输出容器镜像中。
构建卷的挂载点(运行中的构建从中读取数据)在功能上与 pod 卷挂载 类似。
流程
在
BuildConfig
对象的sourceStrategy
定义中,将任何构建卷添加到volumes
数组中。例如:spec: sourceStrategy: volumes: - name: secret-mvn 1 mounts: - destinationPath: /opt/app-root/src/.ssh 2 source: type: Secret 3 secret: secretName: my-secret 4 - name: settings-mvn 5 mounts: - destinationPath: /opt/app-root/src/.m2 6 source: type: ConfigMap 7 configMap: name: my-config 8 - name: my-csi-volume 9 mounts: - destinationPath: /opt/app-root/src/some_path 10 source: type: CSI 11 csi: driver: csi.sharedresource.openshift.io 12 readOnly: true 13 volumeAttributes: 14 attribute: value
共享资源 CSI 驱动程序作为技术预览提供。
2.5.3. Custom 构建
采用自定义构建策略时,开发人员可以定义负责整个构建过程的特定构建器镜像。通过利用自己的构建器镜像,可以自定义构建流程。
自定义构建器镜像是嵌入了构建过程逻辑的普通容器镜像,例如用于构建 RPM 或基本镜像的逻辑。
自定义构建以级别很高的特权运行,默认情况下不可供用户使用。只有可赋予集群管理权限的用户才应被授予运行自定义构建的权限。
2.5.3.1. 使用 FROM 镜像进行自定义构建
您可以使用 customStrategy.from
部分来指示要用于自定义构建的镜像。
流程
设置
customStrategy.from
部分:strategy: customStrategy: from: kind: "DockerImage" name: "openshift/sti-image-builder"
2.5.3.2. 在自定义构建中使用 secret
除了可以添加到所有构建类型的源和镜像的 secret 之外,自定义策略还允许向构建器 Pod 添加任意 secret 列表。
2.5.3.3. 使用环境变量进行自定义构建
要将环境变量提供给自定义构建过程使用,您可以在构建配置的 customStrategy
定义中添加环境变量。
这里定义的环境变量将传递给运行自定义构建的 Pod。
流程
定义在构建期间使用的自定义 HTTP 代理:
customStrategy: ... env: - name: "HTTP_PROXY" value: "http://myproxy.net:5187/"
要管理构建配置中定义的环境变量,请输入以下命令:
$ oc set env <enter_variables>
2.5.3.4. 使用自定义构建器镜像
OpenShift Container Platform 的自定义构建策略允许您定义负责整个构建过程的特定构建器镜像。当您需要构建来生成单独的工件,如软件包、JAR、WAR、可安装的 ZIP 或基础镜像时,请使用自定义构建器镜像。
自定义构建器镜像是嵌入构建过程逻辑的普通容器镜像,用于构建工件,如 RPM 或基础容器镜像。
另外,自定义构建器允许实施任何扩展构建过程,如运行单元或集成测试的 CI/CD 流。
2.5.3.4.1. 自定义构建器镜像
在调用时,自定义构建器镜像将接收以下环境变量以及继续进行构建所需要的信息:
变量名称 | 描述 |
---|---|
|
|
| 包含要构建的源代码的 Git 存储库的 URL。 |
|
使用与 |
| 指定要在构建时使用的 Git 存储库的子目录。只有定义后才出现。 |
| 要构建的 Git 引用。 |
| 创建此构建对象的 OpenShift Container Platform master 的版本。 |
| 镜像要推送到的容器镜像 registry。 |
| 所构建镜像的容器镜像标签名称。 |
|
用于运行 |
2.5.3.4.2. 自定义构建器工作流
虽然自定义构建器镜像作者在定义构建过程时具有很大的灵活性,但构建器镜像仍必须遵循如下必要的步骤,才能在 OpenShift Container Platform 内无缝运行构建:
-
Build
对象定义包含有关构建的输入参数的所有必要信息。 - 运行构建过程。
- 如果构建生成了镜像,则将其推送到构建的输出位置(若已定义)。可通过环境变量传递其他输出位置。
2.5.4. Pipeline 构建
Pipeline 构建策略在 OpenShift Container Platform 4 中弃用。基于 Tekton 的 OpenShift Container Platform Pipelines 中带有等效且改进的功能。
OpenShift Container Platform 上的 Jenkins 镜像被完全支持,用户可以按照 Jenkins 用户文档在作业中定义 jenkinsfile
,或者将其存储在 Source Control Management 系统中。
采用 Pipeline 构建策略时,开发人员可以定义 Jenkins 管道,供 Jenkins 管道插件使用。构建可以由 OpenShift Container Platform 启动、监控和管理,其方式与任何其他构建类型相同。
Pipeline 工作流在 jenkinsfile
中定义,或直接嵌入在构建配置中,或者在 Git 存储库中提供并由构建配置引用。
2.5.4.1. 了解 OpenShift Container Platform 管道
Pipeline 构建策略在 OpenShift Container Platform 4 中弃用。基于 Tekton 的 OpenShift Container Platform Pipelines 中带有等效且改进的功能。
OpenShift Container Platform 上的 Jenkins 镜像被完全支持,用户可以按照 Jenkins 用户文档在作业中定义 jenkinsfile
,或者将其存储在 Source Control Management 系统中。
通过管道(pipeline),您可以控制在 OpenShift Container Platform 上构建、部署和推进您的应用程序。通过结合使用 Jenkins Pipeline 构建策略、jenkinsfile
和 Jenkins 客户端插件提供的 OpenShift Container Platform 域特定语言(DSL),您可以为任何场景创建高级构建、测试、部署和推进管道。
OpenShift Container Platform Jenkins 同步插件
OpenShift Container Platform Jenkins 同步插件使构建配置和构建对象与 Jenkins 任务和构建保持同步,并提供以下功能:
- Jenkins 中动态作业并运行创建。
- 从镜像流、镜像流标签或配置映射动态创建代理 Pod 模板。
- 注入环境变量。
- OpenShift Container Platform Web 控制台中的管道视觉化。
- 与 Jenkins Git 插件集成,后者将 OpenShift Container Platform 构建的提交信息传递给 Jenkins Git 插件。
- 将 secret 同步到 Jenkins 凭证条目。
OpenShift Container Platform Jenkins 客户端插件
OpenShift Container Platform Jenkins 客户端插件是一种 Jenkins 插件,旨在提供易读、简洁、全面且流畅的 Jenkins Pipeline 语法,以便与 OpenShift Container Platform API 服务器进行丰富的交互。该插件使用 OpenShift Container Platform 命令行工具 oc
,此工具必须在执行脚本的节点上可用。
Jenkins 客户端插件必须安装到 Jenkins master上,这样才能在您的应用程序的 jenkinsfile
中使用 OpenShift Container Platform DSL。使用 OpenShift Container Platform Jenkins 镜像时,默认安装并启用此插件。
对于项目中的 OpenShift Container Platform 管道,必须使用 Jenkins Pipeline 构建策略。此策略默认使用源存储库根目录下的 jenkinsfile
,但也提供以下配置选项:
-
构建配置中的内联
jenkinsfile
字段。 -
构建配置中的
jenkinsfilePath
字段,该字段引用要使用的jenkinsfile
的位置,该位置相对于源contextDir
。
可选的 jenkinsfilePath
字段指定要使用的文件的名称,其路径相对于源 contextDir
。如果省略了 contextDir
,则默认为存储库的根目录。如果省略了 jenkinsfilePath
,则默认为 jenkinsfile
。
2.5.4.2. 为管道构建提供 Jenkins 文件
Pipeline 构建策略在 OpenShift Container Platform 4 中弃用。基于 Tekton 的 OpenShift Container Platform Pipelines 中带有等效且改进的功能。
OpenShift Container Platform 上的 Jenkins 镜像被完全支持,用户可以按照 Jenkins 用户文档在作业中定义 jenkinsfile
,或者将其存储在 Source Control Management 系统中。
jenkinsfile
使用标准的 Groovy 语言语法,允许对应用程序的配置、构建和部署进行精细控制。
您可以通过以下一种方式提供 jenkinsfile
:
- 位于源代码存储库中的文件。
-
使用
jenkinsfile
字段嵌入为构建配置的一部分。
使用第一个选项时,jenkinsfile
必须包含在以下位置之一的应用程序源代码存储库中:
-
存储库根目录下名为
jenkinsfile
的文件。 -
存储库的源
contextDir
的根目录下名为jenkinsfile
的文件。 -
通过 BuildConfig 的
JenkinsPipelineStrategy
部分的jenkinsfilePath
字段指定的文件名;若提供,则路径相对于源contextDir
,否则默认为存储库的根目录。
jenkinsfile
在 Jenkins 代理 Pod 上运行,如果您打算使用 OpenShift Container Platform DSL,它必须具有 OpenShift Container Platform 客户端二进制文件。
流程
要提供 Jenkins 文件,您可以:
- 在构建配置中嵌入 Jenkins 文件。
- 在构建配置中包含对包含 Jenkins 文件的 Git 存储库的引用。
嵌入式定义
kind: "BuildConfig" apiVersion: "v1" metadata: name: "sample-pipeline" spec: strategy: jenkinsPipelineStrategy: jenkinsfile: |- node('agent') { stage 'build' openshiftBuild(buildConfig: 'ruby-sample-build', showBuildLogs: 'true') stage 'deploy' openshiftDeploy(deploymentConfig: 'frontend') }
引用 Git 存储库
kind: "BuildConfig"
apiVersion: "v1"
metadata:
name: "sample-pipeline"
spec:
source:
git:
uri: "https://github.com/openshift/ruby-hello-world"
strategy:
jenkinsPipelineStrategy:
jenkinsfilePath: some/repo/dir/filename 1
- 1
- 可选的
jenkinsfilePath
字段指定要使用的文件的名称,其路径相对于源contextDir
。如果省略了contextDir
,则默认为存储库的根目录。如果省略了jenkinsfilePath
,则默认为jenkinsfile
。
2.5.4.3. 使用环境变量进行 Pipeline 构建
Pipeline 构建策略在 OpenShift Container Platform 4 中弃用。基于 Tekton 的 OpenShift Container Platform Pipelines 中带有等效且改进的功能。
OpenShift Container Platform 上的 Jenkins 镜像被完全支持,用户可以按照 Jenkins 用户文档在作业中定义 jenkinsfile
,或者将其存储在 Source Control Management 系统中。
要将环境变量提供给 Pipeline 构建过程使用,您可以在构建配置的 jenkinsPipelineStrategy
定义中添加环境变量。
定义后,环境变量将设置为与构建配置关联的任何 Jenkins 任务的参数。
流程
要定义在构建期间使用的环境变量,编辑 YAML 文件:
jenkinsPipelineStrategy: ... env: - name: "FOO" value: "BAR"
您还可以使用 oc set env
命令管理构建配置中定义的环境变量。
2.5.4.3.1. BuildConfig 环境变量和 Jenkins 任务参数之间的映射
根据对 Pipeline 策略构建配置的更改创建或更新 Jenkins 任务时,构建配置中的任何环境变量都会映射到 Jenkins 任务参数定义,其中 Jenkins 任务参数定义的默认值是关联环境变量的当前值。
在 Jenkins 任务初始创建之后,您仍然可以从 Jenkins 控制台向任务添加其他参数。参数名称与构建配置中的环境变量名称不同。为这些 Jenkins 任务启动构建时,将遵循这些参数。
为 Jenkins 任务启动构建的方式决定了如何设置参数。
-
如果使用
oc start-build
启动,则构建配置中的环境变量值是为对应作业实例设置的参数。您在 Jenkins 控制台中对参数默认值所做的更改都将被忽略。构建配置值具有优先权。 如果使用
oc start-build -e
启动,则-e
选项中指定的环境变量值具有优先权。- 如果指定没有列在构建配置中列出的环境变量,它们将添加为 Jenkins 任务参数定义。
-
您在 Jenkins 控制台中对与环境变量对应的参数所做的更改都将被忽略。构建配置以及您通过
oc start-build -e
指定的值具有优先权。
- 如果使用 Jenkins 控制台启动 Jenkins 任务,您可以使用 Jenkins 控制台控制参数的设置,作为启动任务构建的一部分。
建议您在构建配置中指定与作业参数关联的所有可能环境变量。这样做可以减少磁盘 I/O 并提高 Jenkins 处理期间的性能。
2.5.4.4. Pipeline 构建教程
Pipeline 构建策略在 OpenShift Container Platform 4 中弃用。基于 Tekton 的 OpenShift Container Platform Pipelines 中带有等效且改进的功能。
OpenShift Container Platform 上的 Jenkins 镜像被完全支持,用户可以按照 Jenkins 用户文档在作业中定义 jenkinsfile
,或者将其存储在 Source Control Management 系统中。
本例演示如何创建 OpenShift Container Platform Pipeline,以使用 nodejs-mongodb.json
模板构建、部署和验证 Node.js/MongoDB
应用程序。
流程
创建 Jenkins master:
$ oc project <project_name>
选择要使用的项目,或使用
oc new-project <project_name>
创建一个新项目。$ oc new-app jenkins-ephemeral 1
如果要使用持久性存储,请改用
jenkins-persistent
。使用以下内容,创建名为
nodejs-sample-pipeline.yaml
的文件:注意这将创建一个
BuildConfig
对象,它将使用 Jenkins Pipeline 策略来构建、部署和扩展Node.js/MongoDB
示例应用程序。kind: "BuildConfig" apiVersion: "v1" metadata: name: "nodejs-sample-pipeline" spec: strategy: jenkinsPipelineStrategy: jenkinsfile: <pipeline content from below> type: JenkinsPipeline
使用
jenkinsPipelineStrategy
创建BuildConfig
对象后,通过使用内联jenkinsfile
告知管道做什么:注意本例没有为应用程序设置 Git 存储库。
以下
jenkinsfile
内容使用 OpenShift Container Platform DSL 以 Groovy 语言编写。在本例中,请使用 YAML Literal Style 在BuildConfig
中包含内联内容,但首选的方法是使用源存储库中的jenkinsfile
。def templatePath = 'https://raw.githubusercontent.com/openshift/nodejs-ex/master/openshift/templates/nodejs-mongodb.json' 1 def templateName = 'nodejs-mongodb-example' 2 pipeline { agent { node { label 'nodejs' 3 } } options { timeout(time: 20, unit: 'MINUTES') 4 } stages { stage('preamble') { steps { script { openshift.withCluster() { openshift.withProject() { echo "Using project: ${openshift.project()}" } } } } } stage('cleanup') { steps { script { openshift.withCluster() { openshift.withProject() { openshift.selector("all", [ template : templateName ]).delete() 5 if (openshift.selector("secrets", templateName).exists()) { 6 openshift.selector("secrets", templateName).delete() } } } } } } stage('create') { steps { script { openshift.withCluster() { openshift.withProject() { openshift.newApp(templatePath) 7 } } } } } stage('build') { steps { script { openshift.withCluster() { openshift.withProject() { def builds = openshift.selector("bc", templateName).related('builds') timeout(5) { 8 builds.untilEach(1) { return (it.object().status.phase == "Complete") } } } } } } } stage('deploy') { steps { script { openshift.withCluster() { openshift.withProject() { def rm = openshift.selector("dc", templateName).rollout() timeout(5) { 9 openshift.selector("dc", templateName).related('pods').untilEach(1) { return (it.object().status.phase == "Running") } } } } } } } stage('tag') { steps { script { openshift.withCluster() { openshift.withProject() { openshift.tag("${templateName}:latest", "${templateName}-staging:latest") 10 } } } } } } }
- 1
- 要使用的模板的路径。
- 1 2
- 要创建的模板的名称。
- 3
- 启动
node.js
代理 pod 以针对其运行此构建。 - 4
- 为此管道设置 20 分钟超时。
- 5
- 使用此模板标签删除所有内容。
- 6
- 使用此模板标签删除任何 secret。
- 7
- 从
templatePath
创建一个新应用程序。 - 8
- 等待最多五分钟以完成构建。
- 9
- 等待最多五分钟以完成部署。
- 10
- 如果其余部分都成功,则将
$ {templateName}:latest
镜像标记为$ {templateName}-staging:latest
。stage 环境的管道 BuildConfig 可以监控$ {templateName}-staging:latest
镜像更改,并将它部署到 stage 环境中。
注意上例使用 declarative pipeline 风格编写,但较旧的 scripted pipeline 风格也受到支持。
在 OpenShift Container Platform 集群中创建管道
BuildConfig
:$ oc create -f nodejs-sample-pipeline.yaml
如果您不想自行创建文件,可以通过运行以下命令来使用 Origin 存储库中的示例:
$ oc create -f https://raw.githubusercontent.com/openshift/origin/master/examples/jenkins/pipeline/nodejs-sample-pipeline.yaml
启动管道:
$ oc start-build nodejs-sample-pipeline
注意此外,也可以通过 OpenShift Container Platform Web 控制台启动管道,方法是导航到 Builds → Pipeline 部分并点击 Start Pipeline,或者访问 Jenkins 控制台,再导航到您创建的管道并点击 Build Now。
管道启动之后,您应该看到项目中执行了以下操作:
- 在 Jenkins 服务器上创建了作业实例。
- 如果管道需要,启动一个代理 pod。
管道在代理 Pod 上运行,如果不需要代理,则管道在 master 上运行。
-
将删除之前创建的具有
template=nodejs-mongodb-example
标签的所有资源。 -
从
nodejs-mongodb-example
模板创建一个新应用程序及其所有相关资源。 使用
nodejs-mongodb-example
BuildConfig
启动构建。- 管道将等待到构建完成后触发下一阶段。
使用
nodejs-mongodb-example
部署配置启动部署。- 管道将等待到部署完成后触发下一阶段。
-
如果构建和部署都成功,则
nodejs-mongodb-example:latest
镜像将标记为nodejs-mongodb-example:stage
。
-
将删除之前创建的具有
如果管道需要,则代理 pod 会被删除。
注意视觉化管道执行的最佳方法是在 OpenShift Container Platform Web 控制台中查看它。您可以通过登录 Web 控制台并导航到 Builds → Pipelines 来查看管道。
2.5.5. 使用 web 控制台添加 secret
您可以在构建配置中添加 secret,以便它可以访问私有存储库。
流程
将 secret 添加到构建配置中,以便它可以从 OpenShift Container Platform Web 控制台访问私有存储库:
- 创建一个新的 OpenShift Container Platform 项目。
- 创建一个包含用于访问私有源代码存储库的凭证的 secret。
- 创建构建配置。
-
在构建配置编辑器页面上或在 Web 控制台的
create app from builder image
页面中,设置 Source Secret。 - 点击 Save。
2.5.6. 启用拉取 (pull) 和推送 (push)
您可以通过在构建配置中设置 pull secret 来启用拉取到私有 registry,也可以通过设置 push secret 来启用推送。
流程
启用拉取到私有 registry:
- 在构建配置中设置 pull secret。
启用推送:
- 在构建配置中设置 push secret。
2.6. 使用 Buildah 自定义镜像构建
在 OpenShift Container Platform 4.10 中,主机节点上没有 docker socket。这意味着,不能保证自定义构建的 mount docker socket 选项会提供可在自定义构建镜像中使用的可访问 docker socket。
如果您需要此功能来构建和推送镜像,请将 Buildah 工具添加到自定义构建镜像中,并在自定义构建逻辑中使用它来构建并推送镜像。以下是如何使用 Buildah 运行自定义构建的示例。
使用自定义构建策略需要普通用户默认情况下不具备的权限,因为它允许用户在集群上运行的特权容器内执行任意代码。此级别的访问权限可被用来进行可能对集群造成损害的操作,因此应仅授权给信任的用户。
2.6.1. 先决条件
- 查看如何授予自定义构建权限。
2.6.2. 创建自定义构建工件
您必须创建要用作自定义构建镜像的镜像。
流程
从空目录着手,使用以下内容创建名为
Dockerfile
的文件:FROM registry.redhat.io/rhel8/buildah # In this example, `/tmp/build` contains the inputs that build when this # custom builder image is run. Normally the custom builder image fetches # this content from some location at build time, by using git clone as an example. ADD dockerfile.sample /tmp/input/Dockerfile ADD build.sh /usr/bin RUN chmod a+x /usr/bin/build.sh # /usr/bin/build.sh contains the actual custom build logic that will be run when # this custom builder image is run. ENTRYPOINT ["/usr/bin/build.sh"]
在同一目录中,创建名为
dockerfile.sample
的文件。此文件将包含在自定义构建镜像中,并且定义将由自定义构建生成的镜像:FROM registry.access.redhat.com/ubi8/ubi RUN touch /tmp/build
在同一目录中,创建名为
build.sh
的文件。此文件包含自定义生成运行时将要执行的逻辑:#!/bin/sh # Note that in this case the build inputs are part of the custom builder image, but normally this # is retrieved from an external source. cd /tmp/input # OUTPUT_REGISTRY and OUTPUT_IMAGE are env variables provided by the custom # build framework TAG="${OUTPUT_REGISTRY}/${OUTPUT_IMAGE}" # performs the build of the new image defined by dockerfile.sample buildah --storage-driver vfs bud --isolation chroot -t ${TAG} . # buildah requires a slight modification to the push secret provided by the service # account to use it for pushing the image cp /var/run/secrets/openshift.io/push/.dockercfg /tmp (echo "{ \"auths\": " ; cat /var/run/secrets/openshift.io/push/.dockercfg ; echo "}") > /tmp/.dockercfg # push the new image to the target for the build buildah --storage-driver vfs push --tls-verify=false --authfile /tmp/.dockercfg ${TAG}
2.6.3. 构建自定义构建器镜像
您可以使用 OpenShift Container Platform 构建和推送要在 Custom 策略中使用的自定义构建器镜像。
先决条件
- 定义要用于创建新的自定义构建器镜像的所有输入。
流程
定义要用于构建自定义构建器镜像的
BuildConfig
对象:$ oc new-build --binary --strategy=docker --name custom-builder-image
从您在其中创建自定义构建镜像的目录中,运行构建:
$ oc start-build custom-builder-image --from-dir . -F
构建完成后,新自定义构建器镜像将在名为
custom-builder-image:latest
的镜像流标签中的项目内可用。
2.6.4. 使用自定义构建器镜像
您可以定义一个 BuildConfig
对象,它将结合使用 Custom 策略与自定义构建器镜像来执行您的自定义构建逻辑。
先决条件
- 为新自定义构建器镜像定义所有必要的输入。
- 构建您的自定义构建器镜像。
流程
创建名为
buildconfig.yaml
的文件。此文件定义要在项目中创建并执行的BuildConfig
对象:kind: BuildConfig apiVersion: build.openshift.io/v1 metadata: name: sample-custom-build labels: name: sample-custom-build annotations: template.alpha.openshift.io/wait-for-ready: 'true' spec: strategy: type: Custom customStrategy: forcePull: true from: kind: ImageStreamTag name: custom-builder-image:latest namespace: <yourproject> 1 output: to: kind: ImageStreamTag name: sample-custom:latest
- 1
- 指定项目的名称。
创建
BuildConfig
:$ oc create -f buildconfig.yaml
创建名为
imagestream.yaml
的文件。此文件定义构建要将镜像推送到的镜像流:kind: ImageStream apiVersion: image.openshift.io/v1 metadata: name: sample-custom spec: {}
创建镜像流:
$ oc create -f imagestream.yaml
运行自定义构建:
$ oc start-build sample-custom-build -F
构建运行时,它会启动一个 Pod 来运行之前构建的自定义构建器镜像。该 Pod 将运行定义为自定义构建器镜像入口点的
build.sh
逻辑。build.sh
逻辑调用 Buildah 来构建自定义构建器镜像中嵌入的dockerfile.sample
,然后使用 Buildah 将新镜像推送到sample-custom 镜像流
。
2.7. 执行和配置基本构建
以下小节提供了有关基本构建操作的说明,包括启动和取消构建、编辑 BuildConfig
、删除 BuildConfig
、查看构建详情以及访问构建日志。
2.7.1. 启动构建
您可以从当前项目中的现有构建配置手动启动新构建。
流程
要手动启动构建,请输入以下命令:
$ oc start-build <buildconfig_name>
2.7.1.1. 重新运行构建
您可以使用 --from-build
标志,手动重新运行构建。
流程
要手动重新运行构建,请输入以下命令:
$ oc start-build --from-build=<build_name>
2.7.1.2. 流传输构建日志
您可以指定 --follow
标志,在 stdout
中输出构建日志。
流程
要在
stdout
中手动输出构建日志,请输入以下命令:$ oc start-build <buildconfig_name> --follow
2.7.1.3. 在启动构建时设置环境变量
您可以指定 --env
标志,为构建设置任何所需的环境变量。
流程
要指定所需的环境变量,请输入以下命令:
$ oc start-build <buildconfig_name> --env=<key>=<value>
2.7.1.4. 使用源启动构建
您可以通过直接推送源来启动构建,而不依赖于 Git 源拉取或构建的 Dockerfile;源可以是 Git 或 SVN 工作目录的内容、您想要部署的一组预构建二进制工件,或者单个文件。这可以通过为 start-build
命令指定以下选项之一来完成:
选项 | 描述 |
---|---|
| 指定将要存档并用作构建的二进制输入的目录。 |
| 指定将成为构建源中唯一文件的单个文件。该文件放在空目录的根目录中,其文件名与提供的原始文件相同。 |
|
指定用作构建二进制输入的本地存储库的路径。添加 |
将任何这些选项直接传递给构建时,内容将流传输到构建中并覆盖当前的构建源设置。
从二进制输入触发的构建不会在服务器上保留源,因此基础镜像更改触发的重新构建将使用构建配置中指定的源。
流程
使用以下命令从源启动构建,以将本地 Git 存储库的内容作为标签
v2
的存档发送:$ oc start-build hello-world --from-repo=../hello-world --commit=v2
2.7.2. 取消构建
您可以使用 Web 控制台或通过以下 CLI 命令来取消构建。
流程
要手动取消构建,请输入以下命令:
$ oc cancel-build <build_name>
2.7.2.1. 取消多个构建
您可以使用以下 CLI 命令取消多个构建。
流程
要手动取消多个构建,请输入以下命令:
$ oc cancel-build <build1_name> <build2_name> <build3_name>
2.7.2.2. 取消所有构建
您可以使用以下 CLI 命令取消构建配置中的所有构建。
流程
要取消所有构建,请输入以下命令:
$ oc cancel-build bc/<buildconfig_name>
2.7.2.3. 取消给定状态下的所有构建
您可以取消给定状态下的所有构建,如 new
或 pending
状态,同时忽略其他状态下的构建。
流程
要取消给定状态下的所有内容,请输入以下命令:
$ oc cancel-build bc/<buildconfig_name>
2.7.3. 编辑 BuildConfig
要编辑构建配置,您可以使用 Developer 视角的 Builds 视图中的 Edit BuildConfig 选项。
您可以使用以下任一视图编辑 BuildConfig
:
-
Form 视图 允许您使用标准表单字段和复选框编辑
BuildConfig
。 -
YAML 视图 允许您编辑
BuildConfig
,完全控制操作。
您可以在 Form view 和 YAML 视图间切换,而不丢失任何数据。Form 视图中的数据传输到 YAML 视图,反之亦然。
流程
- 在 Developer 视角 的 Builds 视图中,点击菜单 来查看 Edit BuildConfig 选项。
- 点击 Edit BuildConfig 以查看 Form view 选项。
在 Git 部分中,输入您要用来创建应用程序的代码库的 Git 存储库 URL。这个 URL 随后会被验证。
可选:点击 Show Advanced Git Options 来添加详情,例如:
- Git Reference,用于指定包含您要用来构建应用程序的代码的分支、标签或提交。
- Context Dir,用于指定包含您要用来构建应用程序的代码的子目录。
- Source Secret,创建一个具有用来从私有存储库拉取源代码的凭证的 Secret Name。
在 Build from 部分中,选择您要从中构建的选项。您可以使用以下选项:
- 镜像流标签 引用给定镜像流和标签的镜像。输入您要从构建并推送到的位置的项目、镜像流和标签。
- 镜像流镜像 引用给定镜像流和镜像名称的镜像。输入您要从中构建的镜像流镜像。另外,进入要推送到的项目、镜像流和标签。
- Docker 镜像 :通过 Docker 镜像存储库引用 Docker 镜像。您还需要进入项目、镜像流和标签,以引用您要推送到的位置。
- 可选:在 Environment Variables 部分中,使用 Name 和 Value 字段添加与项目关联的环境变量。要添加更多环境变量,请使用 Add Value 或 Add from ConfigMap 和 Secret。
可选: 要进一步自定义应用程序,请使用以下高级选项:
- Trigger
- 构建器镜像更改时触发新镜像构建。点 Add Trigger 并选择 Type 和 Secret 来添加更多触发器。
- Secrets
- 为应用添加 secret。点 Add secret 并选择 Secret 和 Mountpoint 来添加更多 secret。
- 策略
- 单击 Run policy 以选择构建运行策略。所选策略决定从构建配置创建的构建必须运行的顺序。
- Hook
- 选择择 Run build hooks after image is built,以在构建结束时运行命令并验证镜像。添加 Hook 类型、命令 和 参数,以附加到 命令。
-
单击 Save 以保存
BuildConfig
。
2.7.4. 删除 BuildConfig
您可以使用以下命令来删除 BuildConfig
。
流程
要删除
BuildConfig
,请输入以下命令:$ oc delete bc <BuildConfigName>
这也会删除从此
BuildConfig
实例化的所有构建。要删除
BuildConfig
并保留从BuildConfig
中初始化的构建,在输入以下命令时指定--cascade=false
标志:$ oc delete --cascade=false bc <BuildConfigName>
2.7.5. 查看构建详情
您可以使用 Web 控制台或 oc describe
CLI 命令查看构建详情。
这会显示,包括:
- 构建源。
- 构建策略。
- 输出目的地。
- 目标 registry 中的镜像摘要。
- 构建的创建方式。
如果构建采用 Docker
或 Source
策略,则 oc describe
输出还包括用于构建的源修订的相关信息,包括提交 ID、作者、提交者和消息等。
流程
要查看构建详情,请输入以下命令:
$ oc describe build <build_name>
2.7.6. 访问构建日志
您可以使用 Web 控制台或 CLI 访问构建日志。
流程
要直接使用构建来流传输日志,请输入以下命令:
$ oc describe build <build_name>
2.7.6.1. 访问 BuildConfig 日志
您可以使用 Web 控制台或 CLI 访问 BuildConfig
日志。
流程
要输出
BuildConfig
的最新构建的日志,请输入以下命令:$ oc logs -f bc/<buildconfig_name>
2.7.6.2. 访问给定版本构建的 BuildConfig 日志
您可以使用 Web 控制台或 CLI 访问 BuildConfig
的给定版本构建的日志。
流程
要输出
BuildConfig
的给定版本构建的日志,请输入以下命令:$ oc logs --version=<number> bc/<buildconfig_name>
2.7.6.3. 启用日志详细程度
您可以传递 BUILD_LOGLEVEL
环境变量作为 BuildConfig
中 sourceStrategy
或 dockerStrategy
的一部分,来实现更为详细的输出。
管理员可以通过配置 env/BUILD_LOGLEVEL
,为整个 OpenShift Container Platform 实例设置默认的构建详细程度。此默认值可以通过在给定的 BuildConfig
中指定 BUILD_LOGLEVEL
来覆盖。您可以通过将 --build-loglevel
传递给 oc start-build
,在命令行中为非二进制构建指定优先级更高的覆盖。
源构建的可用日志级别如下:
0 级 |
生成运行 |
1 级 | 生成有关已执行进程的基本信息。 |
2 级 | 生成有关已执行进程的非常详细的信息。 |
3 级 | 生成有关已执行进程的非常详细的信息,以及存档内容的列表。 |
4 级 | 目前生成与 3 级相同的信息。 |
5 级 | 生成以上级别中包括的所有内容,另外还提供 Docker 推送消息。 |
流程
要启用更为详细的输出,请传递
BUILD_LOGLEVEL
环境变量作为BuildConfig
中sourceStrategy
或dockerStrategy
的一部分:sourceStrategy: ... env: - name: "BUILD_LOGLEVEL" value: "2" 1
- 1
- 将此值调整为所需的日志级别。
2.8. 触发和修改构建
以下小节概述了如何使用构建 hook 触发构建和修改构建。
2.8.1. 构建触发器
在定义 BuildConfig
时,您可以定义触发器来控制应该运行 BuildConfig
的环境。可用的构建触发器如下:
- Webhook
- 镜像更改
- 配置更改
2.8.1.1. Webhook 触发器
Webhook 触发器通过发送请求到 OpenShift Container Platform API 端点来触发新构建。您可以使用 GitHub、GitLab、Bitbucket 或通用 Webhook 来定义这些触发器。
目前,OpenShift Container Platform Webhook 仅支持各种基于 Git 的源代码管理系统 (SCM) 的推送事件的类同版本。所有其他事件类型都会忽略。
处理推送事件时,OpenShift Container Platform control plane 主机确认事件内的分支引用是否与对应 BuildConfig
中的分支引用匹配。如果匹配,它会检查 OpenShift Container Platform 构建的 Webhook 事件中记录的确切提交引用。如果不匹配,则不触发构建。
oc new-app
和 oc new-build
会自动创建 GitHub 和通用 Webhook 触发器,但其他所需的 Webhook 触发器都必须手动添加。您可以通过设置触发器来手动添加触发器。
对于所有 Webhook,您必须使用名为 WebHookSecretKey
的键定义 secret,并且其值是调用 Webhook 时要提供的值。然后,Webhook 定义必须引用该 secret。secret可确保 URL 的唯一性,防止他人触发构建。键的值将与 Webhook 调用期间提供的 secret 进行比较。
例如,此处的 GitHub Webhook 具有对名为 mysecret
的 secret 的引用:
type: "GitHub" github: secretReference: name: "mysecret"
该 secret 的定义如下。注意 secret 的值采用 base64 编码,如 Secret
对象的 data
字段所要求。
- kind: Secret apiVersion: v1 metadata: name: mysecret creationTimestamp: data: WebHookSecretKey: c2VjcmV0dmFsdWUx
2.8.1.1.1. 使用 GitHub Webhook
当存储库更新时,GitHub Webhook 处理 GitHub 发出的调用。在定义触发器时,您必须指定一个 secret,它将是您在配置 Webhook 时提供给 GitHub 的 URL 的一部分。
GitHub Webhook 定义示例:
type: "GitHub" github: secretReference: name: "mysecret"
Webhook 触发器配置中使用的 secret 与在 GitHub UI 中配置 Webhook 时遇到的 secret
字段不同。前者使 Webhook URL 唯一且难以预测,后者是一个可选的字符串字段,用于创建正文的 HMAC 十六进制摘要,作为 X-Hub-Signature
标头来发送。
oc describe
命令将有效负载 URL 返回为 GitHub Webhook URL(请参阅“显示 Webhook URL”),其结构如下:
输出示例
https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github
先决条件
-
从 GitHub 存储库创建
BuildConfig
。
流程
配置 GitHub Webhook:
从 GitHub 存储库创建
BuildConfig
后,运行以下命令:$ oc describe bc/<name-of-your-BuildConfig>
这会生成一个 Webhook GitHub URL,如下所示:
输出示例
<https://api.starter-us-east-1.openshift.com:443/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github
- 从 GitHub Web 控制台将此 URL 剪切并粘贴到 GitHub 中。
- 在 GitHub 存储库中,从 Settings → Webhooks 中选择 Add Webhook。
- 将 URL 输出粘贴到 Payload URL 字段。
-
将 Content Type 从 GitHub 默认的
application/x-www-form-urlencoded
更改为application/json
。 点击 Add webhook。
您应该看到一条来自 GitHub 的消息,说明您的 Webhook 已配置成功。
现在,每当您将更改推送到 GitHub 存储库时,新构建会自动启动,成功构建后也会启动新部署。
注意Gogs 支持与 GitHub 相同的 Webhook 有效负载格式。因此,如果您使用的是 Gogs 服务器,也可以在
BuildConfig
中定义 GitHub Webhook 触发器,并由 Gogs 服务器触发它。
提供含有有效 JSON 内容的文件后,如
payload.json
,您可以使用curl
手动触发 Webhook:$ curl -H "X-GitHub-Event: push" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/github
只有在 API 服务器没有适当签名的证书时,才需要
-k
参数。
只有 GitHub Webhook 事件的 ref
值与 BuildConfig
资源中的 source.git
字段中指定的 ref
值匹配时,才会触发构建。
其他资源
2.8.1.1.2. 使用 GitLab Webhook
当存储库更新时,GitLab Webhook 处理 GitLab 发出的调用。与 GitHub 触发器一样,您必须指定一个 secret。以下示例是 BuildConfig
中的触发器定义 YAML:
type: "GitLab" gitlab: secretReference: name: "mysecret"
oc describe
命令将有效负载 URL 返回为 GitLab Webhook URL,其结构如下:
输出示例
https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab
流程
配置 GitLab Webhook:
描述
BuildConfig
以获取 Webhook URL:$ oc describe bc <name>
-
复制 Webhook URL,将
<secret>
替换为您的 secret 值。 - 按照 GitLab 设置说明,将 Webhook URL 粘贴到 GitLab 存储库设置中。
提供含有有效 JSON 内容的文件后,如
payload.json
,您可以使用curl
手动触发 Webhook:$ curl -H "X-GitLab-Event: Push Hook" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/gitlab
只有在 API 服务器没有适当签名的证书时,才需要
-k
参数。
2.8.1.1.3. 使用 Bitbucket Webhook
当存储库更新时,Bitbucket Webhook 处理 Bitbucket 发出的调用。与前面的触发器类似,您必须指定一个 secret。以下示例是 BuildConfig
中的触发器定义 YAML:
type: "Bitbucket" bitbucket: secretReference: name: "mysecret"
oc describe
命令将有效负载 URL 返回为 Bitbucket Webhook URL,其结构如下:
输出示例
https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket
流程
配置 Bitbucket Webhook:
描述 BuildConfig 以获取 Webhook URL:
$ oc describe bc <name>
-
复制 Webhook URL,将
<secret>
替换为您的 secret 值。 - 按照 Bitbucket 设置说明,将 Webhook URL 粘贴到 Bitbucket 存储库设置中。
提供含有有效 JSON 内容的文件后,如
payload.json
,您可以使用curl
手动触发 Webhook:$ curl -H "X-Event-Key: repo:push" -H "Content-Type: application/json" -k -X POST --data-binary @payload.json https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/bitbucket
只有在 API 服务器没有适当签名的证书时,才需要
-k
参数。
2.8.1.1.4. 使用通用 Webhook
通用 Webhook 可从能够发出 Web 请求的任何系统调用。与其他 Webhook一样,您必须指定一个 secret,该 secret 将成为调用者必须用于触发构建的 URL 的一部分。secret可确保 URL 的唯一性,防止他人触发构建。如下是 BuildConfig
中的示例触发器定义 YAML:
type: "Generic"
generic:
secretReference:
name: "mysecret"
allowEnv: true 1
- 1
- 设置为
true
,以允许通用 Webhook 传入环境变量。
流程
要设置调用者,请为调用系统提供构建的通用 Webhook 端点的 URL:
输出示例
https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic
调用者必须以
POST
操作形式调用 Webhook。要手动调用 Webhook,您可以使用
curl
:$ curl -X POST -k https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic
HTTP 操作动词必须设置为
POST
。指定了不安全-k
标志以忽略证书验证。如果集群拥有正确签名的证书,则不需要此第二个标志。端点可以接受具有以下格式的可选有效负载:
git: uri: "<url to git repository>" ref: "<optional git reference>" commit: "<commit hash identifying a specific git commit>" author: name: "<author name>" email: "<author e-mail>" committer: name: "<committer name>" email: "<committer e-mail>" message: "<commit message>" env: 1 - name: "<variable name>" value: "<variable value>"
- 1
- 与
BuildConfig
环境变量类似,此处定义的环境变量也可供您的构建使用。如果这些变量与BuildConfig
环境变量发生冲突,则以这些变量为准。默认情况下,Webhook 传递的环境变量将被忽略。在 Webhook 定义上将allowEnv
字段设为true
即可启用此行为。
要使用
curl
传递此有效负载,请在名为payload_file.yaml
的文件中进行定义,再运行以下命令:$ curl -H "Content-Type: application/yaml" --data-binary @payload_file.yaml -X POST -k https://<openshift_api_host:port>/apis/build.openshift.io/v1/namespaces/<namespace>/buildconfigs/<name>/webhooks/<secret>/generic
参数与前一个示例相同,但添加了标头和 payload。
-H
参数将Content-Type
标头设置为application/yaml
或application/json
,具体取决于您的 payload 格式。--data-binary
参数用于通过POST
请求发送带有换行符的二进制 payload。
即使出示了无效的请求 payload(例如,无效的内容类型,或者无法解析或无效的内容等),OpenShift Container Platform 也允许通用 Webhook 触发构建。保留此行为是为了向后兼容。如果出示无效的请求 payload,OpenShift Container Platform 将以 JSON 格式返回警告,作为其 HTTP 200 OK
响应的一部分。
2.8.1.1.5. 显示 Webhook URL
您可以使用以下命令来显示与构建配置关联的 Webhook URL。如果命令不显示任何 Webhook URL,则没有为该构建配置定义任何 Webhook 触发器。
流程
-
显示与
BuildConfig
关联的任何 Webhook URL:
$ oc describe bc <name>
2.8.1.2. 使用镜像更改触发器
作为开发人员,您可以将构建配置为在每次基础镜像更改时自动运行。
当上游镜像有新版本可用时,您可以使用镜像更改触发器自动调用构建。例如,如果构建基于 RHEL 镜像,您可以触发该构建在 RHEL 镜像更改时运行。因此,应用程序镜像始终在最新的 RHEL 基础镜像上运行。
指向 v1 容器 registry 中的容器镜像的镜像流仅在镜像流标签可用时触发一次构建,后续镜像更新时则不会触发。这是因为 v1 容器 registry 中缺少可唯一标识的镜像。
流程
定义指向您要用作触发器的上游镜像的
ImageStream
:kind: "ImageStream" apiVersion: "v1" metadata: name: "ruby-20-centos7"
这将定义绑定到位于
<system-registry>/<namespace>/ruby-20-centos7
的容器镜像存储库的镜像流。<system-registry>
定义为 OpenShift Container Platform 中运行的名为docker-registry
的服务。如果镜像流是构建的基础镜像,请将构建策略中的
from
字段设置为指向ImageStream
:strategy: sourceStrategy: from: kind: "ImageStreamTag" name: "ruby-20-centos7:latest"
在这种情形中,
sourceStrategy
定义将消耗此命名空间中名为ruby-20-centos7
的镜像流的latest
标签。使用指向
ImageStreams
的一个或多个触发器定义构建:type: "ImageChange" 1 imageChange: {} type: "ImageChange" 2 imageChange: from: kind: "ImageStreamTag" name: "custom-image:latest"
将镜像更改触发器用于策略镜像流时,生成的构建会获得一个不可变 docker 标签,指向与该标签对应的最新镜像。在执行构建时,策略会使用此新镜像引用。
对于不引用策略镜像流的其他镜像更改触发器,系统会启动新构建,但不会使用唯一镜像引用来更新构建策略。
由于此示例具有策略的镜像更改触发器,因此生成的构建将是:
strategy: sourceStrategy: from: kind: "DockerImage" name: "172.30.17.3:5001/mynamespace/ruby-20-centos7:<immutableid>"
这将确保触发的构建使用刚才推送到存储库的新镜像,并且可以使用相同的输入随时重新运行构建。
您可以暂停镜像更改触发器,以便在构建开始之前对引用的镜像流进行多次更改。在将 ImageChangeTrigger
添加到 BuildConfig
时,您也可以将 paused
属性设为 true,以避免立即触发构建。
type: "ImageChange" imageChange: from: kind: "ImageStreamTag" name: "custom-image:latest" paused: true
除了设置适用于所有 Strategy
类型的镜像字段外,自定义构建还需要检查 OPENSHIFT_CUSTOM_BUILD_BASE_IMAGE
环境变量。如果不存在,则使用不可变镜像引用来创建它。如果存在,则使用不可变镜像引用进行更新。
如果因为 Webhook 触发器或手动请求而触发构建,则创建的构建将使用从 Strategy
引用的 ImageStream
解析而来的 <immutableid>
。这将确保使用一致的镜像标签来执行构建,以方便再生。
其他资源
2.8.1.3. 识别构建的镜像更改触发器
作为开发人员,如果您有镜像更改触发器,您可以识别启动了上一次构建的镜像更改。这对于调试或故障排除构建非常有用。
BuildConfig
示例
apiVersion: build.openshift.io/v1 kind: BuildConfig metadata: name: bc-ict-example namespace: bc-ict-example-namespace spec: # ... triggers: - imageChange: from: kind: ImageStreamTag name: input:latest namespace: bc-ict-example-namespace - imageChange: from: kind: ImageStreamTag name: input2:latest namespace: bc-ict-example-namespace type: ImageChange status: imageChangeTriggers: - from: name: input:latest namespace: bc-ict-example-namespace lastTriggerTime: "2021-06-30T13:47:53Z" lastTriggeredImageID: image-registry.openshift-image-registry.svc:5000/bc-ict-example-namespace/input@sha256:0f88ffbeb9d25525720bfa3524cb1bf0908b7f791057cf1acfae917b11266a69 - from: name: input2:latest namespace: bc-ict-example-namespace lastTriggeredImageID: image-registry.openshift-image-registry.svc:5000/bc-ict-example-namespace/input2@sha256:0f88ffbeb9d25525720bfa3524cb2ce0908b7f791057cf1acfae917b11266a69 lastVersion: 1
本例省略了与镜像更改触发器无关的元素。
先决条件
- 您已配置了多个镜像更改触发器。这些触发器已触发一个或多个构建。
流程
在
buildConfig.status.imageChangeTriggers
中,标识具有最新时间戳的lastTriggerTime
。这个
ImageChangeTriggerStatus
Then you use the `name` and `namespace` from that build to find the corresponding image change trigger in `buildConfig.spec.triggers`.
-
在
UnderimageChangeTriggers
下,比较时间戳以标识最新的
镜像更改触发器
在构建配置中,buildConfig.spec.triggers
是构建触发器策略 BuildTriggerPolicy
的数组。
每个 BuildTriggerPolicy
都有 type
字段和指针字段。每个指针字段对应于 type
字段允许的值之一。因此,您只能将 BuildTriggerPolicy
设置为一个指针字段。
对于镜像更改触发器,type
的值为 ImageChange
。然后,imageChange
字段是指向 ImageChangeTrigger
对象的指针,其具有以下字段:
-
lastTriggeredImageID
:此字段在 OpenShift Container Platform 4.8 中已弃用,并将在以后的发行版本中被忽略。它包含从此BuildConfig
触发最后一次构建时的ImageStreamTag
的已解析镜像引用。 -
paused
:您可以使用此字段(示例中未显示)暂时禁用此特定镜像更改触发器。 -
from
:您使用此字段引用驱动此镜像更改触发器的ImageStreamTag
。其类型是核心 Kubernetes 类型OwnerReference
。
from
字段有以下备注字段: kind
: 对于镜像更改触发器,唯一支持的值是 ImageStreamTag
。 namespace
:您可以使用此字段指定 ImageStreamTag
的命名空间。** name
:您可以使用此字段指定 ImageStreamTag
。
镜像更改触发器状态
在构建配置中,buildConfig.status.imageChangeTriggers
是 ImageChangeTriggerStatus
元素的数组。每个 ImageChangeTriggerStatus
元素都包含上例中所示的 from
、lastTriggeredImageID
和 lastTriggerTime
元素。
具有最新 lastTriggerTime
的 ImageChangeTriggerStatus
触发了最新的构建。您可以使用其 name
和 namespace
来识别触发构建的 buildConfig.spec.triggers
中的镜像更改触发器。
带有最新时间戳的 lastTriggerTime
表示最后一个构建的 ImageChangeTriggerStatus
。此 ImageChangeTriggerStatus
的name
和 namespace
与触发构建的 buildConfig.spec.triggers
中的镜像更改触发器相同。
其他资源
2.8.1.4. 配置更改触发器
通过配置更改触发器,您可以在创建新 BuildConfig
时立即自动调用构建。
如下是 BuildConfig
中的示例触发器定义 YAML:
type: "ConfigChange"
配置更改触发器目前仅在创建新 BuildConfig
时运作。在未来的版本中,配置更改触发器也可以在每当 BuildConfig
更新时启动构建。
2.8.1.4.1. 手动设置触发器
您可以使用 oc set triggers
在构建配置中添加和移除触发器。
流程
要在构建配置上设置 GitHub Webhook 触发器,请使用:
$ oc set triggers bc <name> --from-github
要设置镜像更改触发器,请使用:
$ oc set triggers bc <name> --from-image='<image>'
要移除触发器,请添加
--remove
:$ oc set triggers bc <name> --from-bitbucket --remove
如果 Webhook 触发器已存在,再次添加它会重新生成 Webhook secret。
如需更多信息,请查阅帮助文档
$ oc set triggers --help
2.8.2. 构建 hook
通过构建 hook,可以将行为注入到构建过程中。
BuildConfig
对象的 postCommit
字段在运行构建输出镜像的临时容器内执行命令。Hook 的执行时间是紧接在提交镜像的最后一层后,并且在镜像推送到 registry 之前。
当前工作目录设置为镜像的 WORKDIR
,即容器镜像的默认工作目录。对于大多数镜像,这是源代码所处的位置。
如果脚本或命令返回非零退出代码,或者启动临时容器失败,则 hook 将失败。当 hook 失败时,它会将构建标记为失败,并且镜像也不会推送到 registry。可以通过查看构建日志来检查失败的原因。
构建 hook 可用于运行单元测试,以在构建标记为完成并在 registry 中提供镜像之前验证镜像。如果所有测试都通过并且测试运行器返回退出代码 0
,则构建标记为成功。如果有任何测试失败,则构建标记为失败。在所有情况下,构建日志将包含测试运行器的输出,这可用于识别失败的测试。
postCommit
hook 不仅限于运行测试,也可用于运行其他命令。由于它在临时容器内运行,因此 hook 所做的更改不会持久存在;也就是说,hook 执行无法对最终镜像造成影响。除了其他用途外,也可借助此行为来安装和使用会自动丢弃并且不出现在最终镜像中的测试依赖项。
2.8.2.1. 配置提交后构建 hook
配置提交后构建 hook 的方法有多种。以下示例中所有形式具有同等作用,也都执行 bundle exec rake test --verbose
。
流程
Shell 脚本:
postCommit: script: "bundle exec rake test --verbose"
script
值是通过/bin/sh -ic
执行的 shell 脚本。当 shell 脚本适合执行构建 hook 时可使用此选项。例如,用于运行前文所述的单元测试。若要控制镜像入口点,或者如果镜像没有/bin/sh
,可使用command
和/或args
。注意引入的额外
-i
标志用于改进搭配 CentOS 和 RHEL 镜像时的体验,未来的发行版中可能会剔除。命令作为镜像入口点:
postCommit: command: ["/bin/bash", "-c", "bundle exec rake test --verbose"]
在这种形式中,
command
是要运行的命令,它会覆盖 exec 形式中的镜像入口点,如 Dockerfile 引用中所述。如果镜像没有/bin/sh
,或者您不想使用 shell,则需要这样做。在所有其他情形中,使用script
可能更为方便。命令带有参数:
postCommit: command: ["bundle", "exec", "rake", "test"] args: ["--verbose"]
这种形式相当于将参数附加到
command
。
同时提供 script
和 command
会产生无效的构建 hook。
2.8.2.2. 使用 CLI 设置提交后构建 hook
oc set build-hook
命令可用于为构建配置设置构建 hook。
流程
将命令设置为提交后构建 hook:
$ oc set build-hook bc/mybc \ --post-commit \ --command \ -- bundle exec rake test --verbose
将脚本设置为提交后构建 hook:
$ oc set build-hook bc/mybc --post-commit --script="bundle exec rake test --verbose"
2.9. 执行高级构建
以下小节提供了有关高级构建操作的说明,包括设置构建资源和最长持续时间、将构建分配给节点、串联构建、修剪构建,以及构建运行策略。
2.9.1. 设置构建资源
默认情况下,构建由 Pod 使用未绑定的资源(如内存和 CPU)来完成。这些资源可能会有限制。
流程
您可以以两种方式限制资源使用:
- 通过在项目的默认容器限值中指定资源限值来限制资源使用。
在构建配置中通过指定资源限值来限制资源使用。** 在以下示例中,每个
resources
、cpu
和memory
参数都是可选的:apiVersion: "v1" kind: "BuildConfig" metadata: name: "sample-build" spec: resources: limits: cpu: "100m" 1 memory: "256Mi" 2
不过,如果您的项目定义了配额,则需要以下两项之一:
设定了显式
requests
的resources
部分:resources: requests: 1 cpu: "100m" memory: "256Mi"
- 1
requests
对象包含与配额中资源列表对应的资源列表。
项目中定义的限值范围,其中
LimitRange
对象中的默认值应用到构建过程中创建的 Pod。否则,构建 Pod 创建将失败,说明无法满足配额要求。
2.9.2. 设置最长持续时间
定义 BuildConfig
对象时,您可以通过设置 completionDeadlineSeconds
字段来定义其最长持续时间。以秒为单位指定,默认情况下不设置。若未设置,则不强制执行最长持续时间。
最长持续时间从构建 Pod 调度到系统中的时间开始计算,并且定义它在多久时间内处于活跃状态,这包括拉取构建器镜像所需的时间。达到指定的超时后,OpenShift Container Platform 将终止构建。
流程
要设置最长持续时间,请在
BuildConfig
中指定completionDeadlineSeconds
。下例显示了BuildConfig
的部分内容,它指定了值为 30 分钟的completionDeadlineSeconds
字段:spec: completionDeadlineSeconds: 1800
Pipeline 策略选项不支持此设置。
2.9.3. 将构建分配给特定的节点
通过在构建配置的 nodeSelector
字段中指定标签,可以将构建定位到在特定节点上运行。nodeSelector
值是一组键值对,在调度构建 pod 时与 Node
标签匹配。
nodeSelector
值也可以由集群范围的默认值和覆盖值控制。只有构建配置没有为 nodeSelector 定义任何键值对,也没有为 nodeSelector
:{}
定义显式的空映射值,才会应用默认值。覆盖值将逐个键地替换构建配置中的值。
如果指定的 NodeSelector
无法与具有这些标签的节点匹配,则构建仍将无限期地保持在 Pending
状态。
流程
通过在
BuildConfig
的nodeSelector
字段中指定标签,将构建分配到特定的节点上运行,如下例所示:apiVersion: "v1" kind: "BuildConfig" metadata: name: "sample-build" spec: nodeSelector:1 key1: value1 key2: value2
- 1
- 与此构建配置关联的构建将仅在具有
key1=value2
和key2=value2
标签的节点上运行。
2.9.4. 串联构建
对于编译语言(例如 Go、C、C ++ 和 Java),在应用程序镜像中包含编译所需的依赖项可能会增加镜像的大小,或者引入可被利用的漏洞。
为避免这些问题,可以将两个构建串联在一起。一个生成编译工件的构建,另一个构建将工件放置在运行工件的独立镜像中。
在以下示例中,Source-to-Image(S2I)构建与 Docker 构建相结合,以编译工件并将其置于单独的运行时镜像中。
虽然本例串联了 Source-to-Image(S2I) 构建和 Docker 构建,但第一个构建可以使用任何策略来生成包含所需工件的镜像,第二个构建则可以使用任何策略来消耗镜像中的输入内容。
第一个构建获取应用程序源,并生成含有 WAR
文件的镜像。镜像推送到 artifact-image
镜像流。输出工件的路径取决于使用的 S2I 构建器的 assemble
脚本。在这种情况下,它会输出到 /wildfly/standalone/deployments/ROOT.war
。
apiVersion: build.openshift.io/v1 kind: BuildConfig metadata: name: artifact-build spec: output: to: kind: ImageStreamTag name: artifact-image:latest source: git: uri: https://github.com/openshift/openshift-jee-sample.git ref: "master" strategy: sourceStrategy: from: kind: ImageStreamTag name: wildfly:10.1 namespace: openshift
第二个构建使用路径指向第一个构建中输出镜像内的 WAR 文件的镜像源。内联 dockerfile
将该 WAR
文件复制到运行时镜像中。
apiVersion: build.openshift.io/v1 kind: BuildConfig metadata: name: image-build spec: output: to: kind: ImageStreamTag name: image-build:latest source: dockerfile: |- FROM jee-runtime:latest COPY ROOT.war /deployments/ROOT.war images: - from: 1 kind: ImageStreamTag name: artifact-image:latest paths: 2 - sourcePath: /wildfly/standalone/deployments/ROOT.war destinationDir: "." strategy: dockerStrategy: from: 3 kind: ImageStreamTag name: jee-runtime:latest triggers: - imageChange: {} type: ImageChange
此设置的结果是,第二个构建的输出镜像不需要包含创建 WAR
文件所需的任何构建工具。此外,由于第二个构建包含镜像更改触发器,因此每当运行第一个构建并生成含有二进制工件的新镜像时,将自动触发第二个构建,以生成包含该工件的运行时镜像。所以,两个构建表现为一个具有两个阶段的构建。
2.9.5. 修剪构建
默认情况下,生命周期已结束的构建将无限期保留。您可以限制要保留的旧构建数量。
流程
通过为
BuildConfig
中的successfulBuildsHistoryLimit
或failedBuildsHistoryLimit
提供正整数值,限制要保留的旧构建的数量,如下例中所示:apiVersion: "v1" kind: "BuildConfig" metadata: name: "sample-build" spec: successfulBuildsHistoryLimit: 2 1 failedBuildsHistoryLimit: 2 2
通过以下操作之一来触发构建修剪:
- 更新构建配置。
- 等待构建结束其生命周期。
构建按其创建时间戳排序,首先修剪最旧的构建。
管理员可以使用 oc adm 对象修剪命令来手动修剪构建。
2.9.6. 构建运行策略
构建运行策略描述从构建配置创建的构建应运行的顺序。这可以通过更改 Build
规格的 spec
部分中的 runPolicy
字段的值来完成。
还可以通过以下方法更改现有构建配置的 runPolicy
值:
-
如果将
Parallel
改为Serial
或SerialLatestOnly
,并从此配置触发新构建,这会导致新构建需要等待所有并行构建完成,因为串行构建只能单独运行。 -
如果将
Serial
更改为SerialLatestOnly
并触发新构建,这会导致取消队列中的所有现有构建,但当前正在运行的构建和最近创建的构建除外。最新的构建接下来运行。
2.10. 在构建中使用红帽订阅
按照以下小节中的内容在 OpenShift Container Platform 上运行授权构建。
2.10.1. 为红帽通用基础镜像创建镜像流标签
要在构建中使用红帽订阅,您可以创建一个镜像流标签来引用通用基础镜像(UBI)。
要让 UBI 在集群中的每个项目中都可用,您需要将镜像流标签添加到 openshift
命名空间中。否则,若要使其在一个特定项目中可用,您要将镜像流标签添加到该项目。
以这种方式使用镜像流标签的好处是,根据安装 pull secret 中的 registry.redhat.io
凭证授予对 UBI 的访问权限,而不会向其他用户公开 pull secret。这比要求每个开发人员使用项目中的 registry.redhat.io
凭证安装 pull secret 更为方便。
流程
要在
openshift
命名空间中创建ImageStreamTag
,因此所有项目中的开发人员可使用它,请输入:$ oc tag --source=docker registry.redhat.io/ubi8/ubi:latest ubi:latest -n openshift
提示您还可以应用以下 YAML 在
openshift
命名空间中创建ImageStreamTag
:apiVersion: image.openshift.io/v1 kind: ImageStream metadata: name: ubi namespace: openshift spec: tags: - from: kind: DockerImage name: registry.redhat.io/ubi8/ubi:latest name: latest referencePolicy: type: Source
要在单个项目中创建
ImageStreamTag
,请输入:$ oc tag --source=docker registry.redhat.io/ubi8/ubi:latest ubi:latest
提示您还可以应用以下 YAML 在单个项目中创建
ImageStreamTag
:apiVersion: image.openshift.io/v1 kind: ImageStream metadata: name: ubi spec: tags: - from: kind: DockerImage name: registry.redhat.io/ubi8/ubi:latest name: latest referencePolicy: type: Source
2.10.2. 将订阅权利添加为构建 secret
使用红帽订阅安装内容的构建需要包括做为一个构件 secret 的权利密钥。
先决条件
您必须可通过您的订阅访问红帽权利。Insights Operator 会自动创建授权 secret。
使用 Red Hat Enterprise Linux(RHEL)7 执行 Entitlement Build 时,在运行任何 yum
命令前,必须在 Dockerfile 中包含以下指令:
RUN rm /etc/rhsm-host
流程
在构建配置的 Docker 策略中将 etc-pki-entitlement secret 添加为构建卷:
strategy: dockerStrategy: from: kind: ImageStreamTag name: ubi:latest volumes: - name: etc-pki-entitlement mounts: - destinationPath: /etc/pki/entitlement source: type: Secret secret: secretName: etc-pki-entitlement
2.10.3. 使用 Subscription Manager 运行构建
2.10.3.1. 使用 Subscription Manager 执行 Docker 构建
Docker 策略构建可以使用 Subscription Manager 来安装订阅内容。
先决条件
必须将授权密钥添加为构建策略卷。
流程
使用以下示例 Dockerfile 来通过 Subscription Manager 安装内容:
FROM registry.redhat.io/ubi8/ubi:latest RUN dnf search kernel-devel --showduplicates && \ dnf install -y kernel-devel
2.10.4. 使用 Red Hat Satellite 订阅运行构建
2.10.4.1. 将 Red Hat Satellite 配置添加到构建中
使用 Red Hat Satellite 安装内容的构建必须提供适当的配置,以便从 Satellite 存储库获取内容。
先决条件
您必须提供或创建与
yum
兼容的存储库配置文件,该文件将从 Satellite 实例下载内容。仓库配置示例
[test-<name>] name=test-<number> baseurl = https://satellite.../content/dist/rhel/server/7/7Server/x86_64/os enabled=1 gpgcheck=0 sslverify=0 sslclientkey = /etc/pki/entitlement/...-key.pem sslclientcert = /etc/pki/entitlement/....pem
流程
创建包含 Satellite 存储库配置文件的
ConfigMap
:$ oc create configmap yum-repos-d --from-file /path/to/satellite.repo
将 Satellite 存储库配置和授权密钥添加为构建卷:
strategy: dockerStrategy: from: kind: ImageStreamTag name: ubi:latest volumes: - name: yum-repos-d mounts: - destinationPath: /etc/yum.repos.d source: type: ConfigMap configMap: name: yum-repos-d - name: etc-pki-entitlement mounts: - destinationPath: /etc/pki/entitlement source: type: Secret secret: secretName: etc-pki-entitlement
2.10.4.2. 使用 Red Hat Satellite 订阅构建 Docker
Docker 策略构建可以使用 Red Hat Satellite 软件仓库来安装订阅内容。
先决条件
- 您已将授权密钥和 Satellite 存储库配置添加为构建卷。
流程
使用以下示例 Dockerfile 来通过 Satellite 安装内容:
FROM registry.redhat.io/ubi8/ubi:latest RUN dnf search kernel-devel --showduplicates && \ dnf install -y kernel-devel
2.10.6. 其他资源
2.11. 通过策略保护构建
OpenShift Container Platform 中的构建在特权容器中运行。根据所用的构建策略,如果您有权限,可以运行构建来升级其在集群和主机节点上的权限。为安全起见,请限制可以运行构建的人员以及用于这些构建的策略。Custom 构建本质上不如 Source 构建安全,因为它们可以在特权容器内执行任何代码,这在默认情况下是禁用的。请谨慎授予 docker 构建权限,因为 Dockerfile 处理逻辑中的漏洞可能会导致在主机节点上授予特权。
默认情况下,所有能够创建构建的用户都被授予相应的权限,可以使用 docker 和 Source-to-Image (S2I) 构建策略。具有集群管理员特权的用户可启用自定义构建策略,如在全局范围内限制用户使用构建策略部分中所述。
您可以使用授权策略来控制谁能够构建以及他们可以使用哪些构建策略。每个构建策略都有一个对应的构建子资源。用户必须有权创建构建,并在构建策略子资源上创建构建的权限,才能使用该策略创建构建。提供的默认角色用于授予构建策略子资源的 create 权限。
策略 | 子资源 | 角色 |
---|---|---|
Docker | builds/docker | system:build-strategy-docker |
Source-to-Image | builds/source | system:build-strategy-source |
Custom | builds/custom | system:build-strategy-custom |
JenkinsPipeline | builds/jenkinspipeline | system:build-strategy-jenkinspipeline |
2.11.1. 在全局范围内禁用构建策略访问
要在全局范围内阻止对特定构建策略的访问,请以具有集群管理源权限的用户身份登录,从 system:authenticated
组中移除对应的角色,再应用注解 rbac.authorization.kubernetes.io/autoupdate: "false"
以防止它们在 API 重启后更改。以下示例演示了如何禁用 Docker 构建策略。
流程
应用
rbac.authorization.kubernetes.io/autoupdate
注解:$ oc edit clusterrolebinding system:build-strategy-docker-binding
输出示例
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: annotations: rbac.authorization.kubernetes.io/autoupdate: "false" 1 creationTimestamp: 2018-08-10T01:24:14Z name: system:build-strategy-docker-binding resourceVersion: "225" selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Abuild-strategy-docker-binding uid: 17b1f3d4-9c3c-11e8-be62-0800277d20bf roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:build-strategy-docker subjects: - apiGroup: rbac.authorization.k8s.io kind: Group name: system:authenticated
- 1
- 将
rbac.authorization.kubernetes.io/autoupdate
注解的值更改为"false"
。
移除角色:
$ oc adm policy remove-cluster-role-from-group system:build-strategy-docker system:authenticated
确保也从这些角色中移除构建策略子资源:
$ oc edit clusterrole admin
$ oc edit clusterrole edit
对于每个角色,指定与要禁用的策略资源对应的子资源。
为 admin 禁用 docker Build 策略:
kind: ClusterRole metadata: name: admin ... - apiGroups: - "" - build.openshift.io resources: - buildconfigs - buildconfigs/webhooks - builds/custom 1 - builds/source verbs: - create - delete - deletecollection - get - list - patch - update - watch ...
- 1
- 添加
builds/custom
和builds/source
,以在全局范围内为具有 admin 角色的用户禁用 docker 构建。
2.11.2. 在全局范围内限制用户使用构建策略
您可以允许某一组用户使用特定策略来创建构建。
先决条件
- 禁用构建策略的全局访问。
流程
将与构建策略对应的角色分配给特定用户。例如,将
system:build-strategy-docker
集群角色添加到用户devuser
:$ oc adm policy add-cluster-role-to-user system:build-strategy-docker devuser
警告如果在集群级别授予用户对
builds/docker
子资源的访问权限,那么该用户将能够在他们可以创建构建的任何项目中使用 docker 策略来创建构建。
2.11.3. 在项目范围内限制用户使用构建策略
与在全局范围内向用户授予构建策略角色类似,您只能允许项目中的某一组特定用户使用特定策略来创建构建。
先决条件
- 禁用构建策略的全局访问。
流程
将与构建策略对应的角色分配给项目中的特定用户。例如,将
devproject
项目中的system:build-strategy-docker
角色添加到用户devuser
:$ oc adm policy add-role-to-user system:build-strategy-docker devuser -n devproject
2.12. 构建配置资源
使用以下步骤来配置构建设置。
2.12.1. 构建控制器配置参数
build.config.openshift.io/cluster
资源提供以下配置参数。
参数 | 描述 |
---|---|
|
包含有关如何处理构建的集群范围内信息。规范且唯一有效的名称是
|
| 控制构建的默认信息。
您可以通过设置
此处未设置的值将从 DefaultProxy 继承。
|
|
|
| 控制构建的覆盖设置。
|
|
|
2.12.2. 配置构建设置
您可以通过编辑 build.config.openshift.io/cluster
资源来配置构建设置。
流程
编辑
build.config.openshift.io/cluster
资源:$ oc edit build.config.openshift.io/cluster
以下是
build.config.openshift.io/cluster
资源的示例:apiVersion: config.openshift.io/v1 kind: Build1 metadata: annotations: release.openshift.io/create-only: "true" creationTimestamp: "2019-05-17T13:44:26Z" generation: 2 name: cluster resourceVersion: "107233" selfLink: /apis/config.openshift.io/v1/builds/cluster uid: e2e9cc14-78a9-11e9-b92b-06d6c7da38dc spec: buildDefaults:2 defaultProxy:3 httpProxy: http://proxy.com httpsProxy: https://proxy.com noProxy: internal.com env:4 - name: envkey value: envvalue gitProxy:5 httpProxy: http://gitproxy.com httpsProxy: https://gitproxy.com noProxy: internalgit.com imageLabels:6 - name: labelkey value: labelvalue resources:7 limits: cpu: 100m memory: 50Mi requests: cpu: 10m memory: 10Mi buildOverrides:8 imageLabels:9 - name: labelkey value: labelvalue nodeSelector:10 selectorkey: selectorvalue tolerations:11 - effect: NoSchedule key: node-role.kubernetes.io/builds operator: Exists
- 1
Build
:包含有关如何处理构建的集群范围内信息。规范且唯一有效的名称是cluster
。- 2
buildDefaults
:控制构建的默认信息。- 3
defaultProxy
:包含所有构建操作的默认代理设置,包括镜像拉取或推送以及源代码下载。- 4
env
:一组应用到构建的默认环境变量,条件是构建中不存在指定的变量。- 5
gitProxy
:仅包含 Git 操作的代理设置。如果设置,这将覆盖所有 Git 命令的任何代理设置,例如git clone
。- 6
imageLabels
:应用到生成的镜像的标签列表。您可以通过在BuildConfig
中提供具有相同名称的标签来覆盖默认标签。- 7
resources
:定义执行构建的资源要求。- 8
buildOverrides
:控制构建的覆盖设置。- 9
imageLabels
:应用到生成的镜像的标签列表。如果您在BuildConfig
中提供了与此表中名称相同的标签,您的标签将会被覆盖。- 10
nodeSelector
:一个选择器,必须为 true 才能使构建 Pod 适合节点。- 11
tolerations
:一个容忍度列表,覆盖构建 Pod 上设置的现有容忍度。
2.13. 构建故障排除
使用以下内容来排除构建问题。
2.13.1. 解决资源访问遭到拒绝的问题
如果您的资源访问请求遭到拒绝:
- 问题
- 构建失败并显示以下信息:
requested access to the resource is denied
- 解决方案
- 您已超过项目中设置的某一镜像配额。检查当前的配额,并验证应用的限值和正在使用的存储:
$ oc describe quota
2.13.2. 服务证书生成失败
如果您的资源访问请求遭到拒绝:
- 问题
-
如果服务证书生成失败并显示以下信息( 服务的
service.beta.openshift.io/serving-cert-generation-error
注解包含):
输出示例
secret/ssl-key references serviceUID 62ad25ca-d703-11e6-9d6f-0e9c0057b608, which does not match 77b6dd80-d716-11e6-9d6f-0e9c0057b60
- 解决方案
-
生成证书的服务不再存在,或者具有不同的
serviceUID
。您必须删除旧 secret 并清除服务上的以下注解service.beta.openshift.io/serving-cert-generation-error
和service.beta.openshift.io/serving-cert-generation-error-num
以强制重新生成证书:
$ oc delete secret <secret_name>
$ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-
$ oc annotate service <service_name> service.beta.openshift.io/serving-cert-generation-error-num-
在用于移除注解的命令中,要移除的注解后面有一个 -
。
2.14. 为构建设置其他可信证书颁发机构
在从镜像 registry 中拉取镜像时,参照以下部分设置构建可信任的额外证书颁发机构 (CA) 。
此流程要求集群管理员创建 ConfigMap
,并在 ConfigMap
中添加额外的 CA 作为密钥。
-
ConfigMap
必须在openshift-config
命名空间中创建。 domain
是ConfigMap
中的键,value
是 PEM 编码的证书。-
每个 CA 必须与某个域关联。域格式是
hostname[..port]
。
-
每个 CA 必须与某个域关联。域格式是
-
ConfigMap
名称必须在image.config.openshift.io/cluster
集群范围配置资源的spec.additionalTrustedCA
字段中设置。
2.14.1. 在集群中添加证书颁发机构
您可以按照以下流程将证书颁发机构 (CA) 添加到集群,以便在推送和拉取镜像时使用。
先决条件
- 您必须具有集群管理员特权。
-
您必须有权访问 registry 的公共证书,通常是位于
/etc/docker/certs.d/
目录中的hostname/ca.crt
文件。
流程
在
openshift-config
命名空间中创建一个ConfigMap
,其中包含使用自签名证书的 registry 的可信证书。对于每个 CA 文件,确保ConfigMap
中的键是hostname[..port]
格式的容器镜像仓库的主机名:$ oc create configmap registry-cas -n openshift-config \ --from-file=myregistry.corp.com..5000=/etc/docker/certs.d/myregistry.corp.com:5000/ca.crt \ --from-file=otherregistry.com=/etc/docker/certs.d/otherregistry.com/ca.crt
更新集群镜像配置:
$ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-cas"}}}' --type=merge
2.14.2. 其他资源
第 3 章 从 Jenkins 迁移到 Tekton
3.1. 从 Jenkins 迁移到 Tekton
Jenkins 和 Tekton 广泛用于自动化构建、测试和部署应用和项目的过程。但是,Tekton 是一个云原生 CI/CD 解决方案,它可与 Kubernetes 和 OpenShift Container Platform 无缝配合工作。本文档可帮助您将 Jenkins CI/CD 工作流迁移到 Tekton。
3.1.1. Jenkins 和 Tekton 概念的比较
本节总结了 Jenkins 和 Tekton 中使用的基本术语,并比较了相同的术语。
3.1.1.1. Jenkins 术语
Jenkins 提供声明式和脚本化管道,它们可以使用共享库和插件扩展。Jenkins 中的一些基本术语如下:
- 管道(Pipeline):利用 Groovy 语法自动化构建、测试和部署应用的整个流程。
- 节点(Node):能够编配或执行脚本化管道的计算机。
- 阶段(Stage):在管道中执行的概念上不同的任务子集。插件或用户界面通常使用此块来显示任务的状态或进度。
- 步骤(Step):一项任务指定要执行的确切操作,可使用命令或脚本。
3.1.1.2. Tekton 术语
Tekton 使用 YAML 语法用于声明管道,由任务组成。Tekton 中的一些基本术语如下:
- 频道(Pipeline):一组串行或并行(或两者)任务。
- 任务(Task) :作为命令、二进制文件或脚本的步骤序列。
- 管道运行(PipelineRun):执行包含一个或多个任务的管道。
任务运行(TaskRun):通过一个或多个步骤执行任务。
注意您可以使用一组输入(如参数和工作区)启动 PipelineRun 或 TaskRun,执行会产生一组输出和工件。
工作区(Workspace):在 Tekton 中,工作区是概念块,用于以下目的:
- 存储输入、输出和构建工件.
- 在任务间共享数据的通用空间.
- 在 secret 中保存的凭证挂载点、配置映射中保存的配置以及机构共享的通用工具。
注意在 Jenkins 中,没有 Tekton 工作区直接等效的工作区。您可以将控制节点视为工作区,因为它存储克隆的代码存储库、构建历史记录和工件。当作业分配到其他节点时,克隆的代码和生成的工件会存储在该节点中,但构建历史记录由控制节点维护。
3.1.1.3. 概念映射
Jenkins 和 Tekton 的构建块并不匹配,对它们的比较在技术上并不是准确的映射。Jenkins 和 Tekton 中的以下术语和概念一般相对应:
Jenkins | Tekton |
---|---|
Pipeline | Pipeline 和 PipelineRun |
Stage | 任务 |
Step | 一个任务中的一个步骤 |
3.1.2. 将示例管道从 Jenkins 迁移到 Tekton
本节提供了 Jenkins 和 Tekton 中的等效管道示例,可帮助您将构建、测试和部署管道从 Jenkins 迁移到 Tekton。
3.1.2.1. Jenkins 管道
考虑在 Groovy 中编写的 Jenkins 管道,用于构建、测试和部署:
pipeline { agent any stages { stage('Build') { steps { sh 'make' } } stage('Test'){ steps { sh 'make check' junit 'reports/**/*.xml' } } stage('Deploy') { steps { sh 'make publish' } } } }
3.1.2.2. Tekton pipeline
在 Tekton 中,Jenkins 管道的等效示例由三个任务组成,每个任务都可以使用 YAML 语法来声明编写:
build
任务示例
apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: myproject-build spec: workspaces: - name: source steps: - image: my-ci-image command: ["make"] workingDir: $(workspaces.source.path)
test
任务示例:
apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: myproject-test spec: workspaces: - name: source steps: - image: my-ci-image command: ["make check"] workingDir: $(workspaces.source.path) - image: junit-report-image script: | #!/usr/bin/env bash junit-report reports/**/*.xml workingDir: $(workspaces.source.path)
deploy
任务示例:
apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: myprojectd-deploy spec: workspaces: - name: source steps: - image: my-deploy-image command: ["make deploy"] workingDir: $(workspaces.source.path)
您可以按顺序组合三个任务组成 Tekton 管道:
示例:用于构建、测试和部署的 Tekton 管道
apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: myproject-pipeline spec: workspaces: - name: shared-dir tasks: - name: build taskRef: name: myproject-build workspaces: - name: source workspace: shared-dir - name: test taskRef: name: myproject-test workspaces: - name: source workspace: shared-dir - name: deploy taskRef: name: myproject-deploy workspaces: - name: source workspace: shared-dir
3.1.3. 从 Jenkins 插件迁移到 Tekton Hub 任务
您可以使用 插件 来扩展 Jenkins 的功能。要在 Tekton 中实现类似的可扩展性,请使用 Tekton Hub 中的任何可用任务。
例如,请考虑 Tekton Hub 中可用的 git-clone 任务,它对应于 Jenkins 的 git 插件。
示例:Tekton Hub 中的 git-clone
任务
apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: demo-pipeline spec: params: - name: repo_url - name: revision workspaces: - name: source tasks: - name: fetch-from-git taskRef: name: git-clone params: - name: url value: $(params.repo_url) - name: revision value: $(params.revision) workspaces: - name: output workspace: source
3.1.4. 使用自定义任务和脚本扩展 Tekton 功能
在 Tekton 中,如果您在 Tekton Hub 中找不到正确的任务,或需要对任务进行更大的控制,您可以创建自定义任务和脚本来扩展 Tekton 的功能。
示例:运行 maven test
命令的自定义任务
apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: maven-test spec: workspaces: - name: source steps: - image: my-maven-image command: ["mvn test"] workingDir: $(workspaces.source.path)
示例:通过提供自定义 shell 脚本的路径
... steps: image: ubuntu script: | #!/usr/bin/env bash /workspace/my-script.sh ...
示例:在 YAML 文件中写入一个自定义 Python 脚本
... steps: image: python script: | #!/usr/bin/env python3 print(“hello from python!”) ...
3.1.5. Jenkins 和 Tekton 执行模型的比较
Jenkins 和 Tekton 提供了类似的功能,但在架构和执行方面有所不同。本节概述了这两种执行模型的简要比较。
Jenkins | Tekton |
---|---|
Jenkins 有一个控制节点。Jenkins 集中执行管道和步骤,或者编排其他节点上运行的作业。 | Tekton 是无服务器且分布式的,它的执行并不依赖于一个中心系统。 |
容器由控制节点通过管道启动。 | Tekton 采用"容器先行"方法,其中每一步骤都作为容器集中运行的容器执行(等同于 Jenkins 中的节点)。 |
使用插件可实现可扩展性。 | 使用 Tekton Hub 中的任务或创建自定义任务和脚本来实现可扩展性。 |
3.1.6. 常见使用案例示例
Jenkins 和 Tekton 都提供通用 CI/CD 用例的功能,例如:
- 使用 maven 编译、构建和部署镜像
- 使用插件扩展核心功能
- 重新使用可共享库和自定义脚本
3.1.6.1. 在 Jenkins 和 Tekton 中运行 maven 管道
您可以在 Jenkins 和 Tekton 工作流中使用 maven 来编译、构建和部署镜像。要将现有 Jenkins 工作流映射到 Tekton,请考虑以下示例:
示例:编译并构建镜像,并使用 Jenkins 中的 maven 将它部署到 OpenShift
#!/usr/bin/groovy node('maven') { stage 'Checkout' checkout scm stage 'Build' sh 'cd helloworld && mvn clean' sh 'cd helloworld && mvn compile' stage 'Run Unit Tests' sh 'cd helloworld && mvn test' stage 'Package' sh 'cd helloworld && mvn package' stage 'Archive artifact' sh 'mkdir -p artifacts/deployments && cp helloworld/target/*.war artifacts/deployments' archive 'helloworld/target/*.war' stage 'Create Image' sh 'oc login https://kubernetes.default -u admin -p admin --insecure-skip-tls-verify=true' sh 'oc new-project helloworldproject' sh 'oc project helloworldproject' sh 'oc process -f helloworld/jboss-eap70-binary-build.json | oc create -f -' sh 'oc start-build eap-helloworld-app --from-dir=artifacts/' stage 'Deploy' sh 'oc new-app helloworld/jboss-eap70-deploy.json' }
示例:编译并构建镜像,并使用 Tekton 中的 maven 将它部署到 OpenShift。
apiVersion: tekton.dev/v1beta1 kind: Pipeline metadata: name: maven-pipeline spec: workspaces: - name: shared-workspace - name: maven-settings - name: kubeconfig-dir optional: true params: - name: repo-url - name: revision - name: context-path tasks: - name: fetch-repo taskRef: name: git-clone workspaces: - name: output workspace: shared-workspace params: - name: url value: "$(params.repo-url)" - name: subdirectory value: "" - name: deleteExisting value: "true" - name: revision value: $(params.revision) - name: mvn-build taskRef: name: maven runAfter: - fetch-repo workspaces: - name: source workspace: shared-workspace - name: maven-settings workspace: maven-settings params: - name: CONTEXT_DIR value: "$(params.context-path)" - name: GOALS value: ["-DskipTests", "clean", "compile"] - name: mvn-tests taskRef: name: maven runAfter: - mvn-build workspaces: - name: source workspace: shared-workspace - name: maven-settings workspace: maven-settings params: - name: CONTEXT_DIR value: "$(params.context-path)" - name: GOALS value: ["test"] - name: mvn-package taskRef: name: maven runAfter: - mvn-tests workspaces: - name: source workspace: shared-workspace - name: maven-settings workspace: maven-settings params: - name: CONTEXT_DIR value: "$(params.context-path)" - name: GOALS value: ["package"] - name: create-image-and-deploy taskRef: name: openshift-client runAfter: - mvn-package workspaces: - name: manifest-dir workspace: shared-workspace - name: kubeconfig-dir workspace: kubeconfig-dir params: - name: SCRIPT value: | cd "$(params.context-path)" mkdir -p ./artifacts/deployments && cp ./target/*.war ./artifacts/deployments oc new-project helloworldproject oc project helloworldproject oc process -f jboss-eap70-binary-build.json | oc create -f - oc start-build eap-helloworld-app --from-dir=artifacts/ oc new-app jboss-eap70-deploy.json
3.1.6.2. 使用插件扩展 Jenkins 和 Tekton 的核心功能
Jenkins 利用了其广泛的用户群来多年开发的大量插件生态系统。您可以在 Jenkins 插件索引中搜索和浏览插件。
Tekton 还有许多任务由社区和企业用户开发并贡献。Tekton Hub 中提供了可重复使用 Tekton 任务的公开可用目录。
另外,Tekton 在其核心功能中纳入了 Jenkins 生态系统的许多插件。例如,授权是 Jenkins 和 Tekton 中的关键功能。虽然 Jenkins 使用基于角色的访问控制插件来确保授权,Tekton 使用 OpenShift 的内置基于角色的访问控制系统。
3.1.6.3. 在 Jenkins 和 Tekton 中共享可重复使用的代码
Jenkins 共享库 为 Jenkins 管道的各部分提供可重复使用的代码。该库在 Jenkinsfile 之间共享,以创建高度模块化的管道,而不重复代码。
虽然 Tekton 中没有 Jenkins 共享库直接对应的,但您可以使用 Tekton Hub 中的任务实现类似的工作流,从而结合使用自定义任务和脚本。
3.1.7. 其他资源
第 4 章 Pipelines
4.1. Red Hat OpenShift Pipelines 发行注记
Red Hat OpenShift Pipelines 是基于 Tekton 项目的一个云原生 CI/CD 环境,它提供:
- 标准 Kubernetes 原生管道定义 (CRD)。
- 无需 CI 服务器管理开销的无服务器管道。
- 使用任何 Kubernetes 工具(如 S2I、Buildah、JIB 和 Kaniko)构建镜像。
- 不同 Kubernetes 发布系统间的可移植性。
- 用于与管道交互的强大 CLI。
- 使用 OpenShift Container Platform Web 控制台的 Developer 视角集成用户体验。
如需了解 Red Hat OpenShift Pipelines 的概述,请参阅了解 OpenShift Pipelines。
4.1.1. 兼容性和支持列表
这个版本中的一些功能当前还只是一个技术预览。它们并不适用于在生产环境中使用。
在下表中,被标记为以下状态的功能:
TP | 技术预览 |
GA | 公开发行 |
Red Hat OpenShift Pipelines 版本 | 组件版本 | OpenShift 版本 | 支持状态 | ||||||
---|---|---|---|---|---|---|---|---|---|
Operator | Pipelines | 触发器 | CLI | 目录 | 链 | Hub | Pipelines 作为代码 | ||
1.10 | 0.44.x | 0.23.x | 0.30.x | 不适用 | 0.15.x (TP) | 1.12.x (TP) | 0.17.x (GA) | 4.10, 4.11, 4.12, 4.13 | GA |
1.9 | 0.41.x | 0.22.x | 0.28.x | 不适用 | 0.13.x (TP) | 1.11.x (TP) | 0.15.x (GA) | 4.10, 4.11, 4.12, 4.13 | GA |
1.8 | 0.37.x | 0.20.x | 0.24.x | 不适用 | 0.9.0 (TP) | 1.8.x (TP) | 0.10.x (TP) | 4.10, 4.11, 4.12 | GA |
1.7 | 0.33.x | 0.19.x | 0.23.x | 0.33 | 0.8.0 (TP) | 1.7.0 (TP) | 0.5.x (TP) | 4.9, 4.10, 4.11 | GA |
1.6 | 0.28.x | 0.16.x | 0.21.x | 0.28 | N/A | N/A | N/A | 4.9 | GA |
1.5 | 0.24.x | 0.14.x (TP) | 0.19.x | 0.24 | N/A | N/A | N/A | 4.8 | GA |
1.4 | 0.22.x | 0.12.x (TP) | 0.17.x | 0.22 | N/A | N/A | N/A | 4.7 | GA |
另外,在 ARM 硬件上运行 Red Hat OpenShift Pipelines 当前只是一个技术预览。
如果您有疑问或希望提供反馈信息,请向产品团队发送邮件 pipelines-interest@redhat.com。
4.1.2. 使开源包含更多
红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。我们从这四个术语开始:master、slave、黑名单和白名单。由于此项工作十分艰巨,这些更改将在即将推出的几个发行版本中逐步实施。有关更多详情,请参阅我们的首席技术官 Chris Wright 提供的消息。
4.1.3. Red Hat OpenShift Pipelines 正式发行(GA)1.10 发行注记
在这个版本中,Red Hat OpenShift Pipelines 正式发行(GA) 1.10 包括在 OpenShift Container Platform 4.11、4.12 和 4.13 中。
4.1.3.1. 新功能
除了包括修复和稳定性改进的信息外,以下小节突出介绍了 Red Hat OpenShift Pipelines 1.10 中的新内容。
4.1.3.1.1. Pipelines
-
在这个版本中,您可以在
PipelineRun
或TaskRun
pod 模板中指定环境变量来覆盖或附加任务或步骤中配置的变量。另外,您可以在默认 pod 模板中指定环境变量,以对所有PipelineRuns
和TaskRuns
全局使用这些变量。在这个版本中,添加了一个名为forbidden-envs
的新默认配置来过滤环境变量,同时从 pod 模板传播。 在这个版本中,管道中的自定义任务会被默认启用。
注意要禁用此次更新,请在
feature-flags
配置自定义资源中将enable-custom-tasks
标志设置为false
。-
在这个版本中,支持
v1beta1.CustomRun
API 版本进行自定义任务。 在这个版本中,增加了对
PipelineRun
reconciler 的支持,以创建自定义运行。例如,从PipelineRuns
创建的自定义TaskRuns
现在可以使用v1beta1.CustomRun
API 版本而不是v1alpha1.Run
,如果custom-task-version
功能标记被设置为v1beta1
,而不是默认值v1alpha1
。注意您需要更新自定义任务控制器,以侦听
*v1beta1.CustomRun
API 版本,而不是*v1alpha1.Run
以响应v1beta1.CustomRun
请求。-
在这个版本中,在
v1beta1.TaskRun
和v1.TaskRun
规格中添加了一个新的retries
字段。
4.1.3.1.2. 触发器
-
在这个版本中,触发器支持创建
v1
API 版本的Pipelines
,Tasks
,PipelineRuns
, 和TaskRuns
对象,以及v1beta1
API 版本的CustomRun
对象。 在这个版本中,GitHub Interceptor 会阻止执行拉取请求触发器,除非由拥有者调用或所有者使用可配置的注释。
注意要启用或禁用此更新,请在 GitHub Interceptor 配置文件中将
githubOwners
参数的值设置为true
或false
。-
在这个版本中,GitHub Interceptor 能够添加以逗号分隔的、用于推送和拉取请求事件更改的所有文件的列表。更改的文件列表添加到顶层 extensions 字段中事件有效负载的
changed_files
属性中。 -
在这个版本中,TLS 的
MinVersion
改为tls.VersionTLS12
,以便在启用了联邦信息处理标准 (FIPS) 模式时在 OpenShift Container Platform 上运行触发器。
4.1.3.1.3. CLI
-
在这个版本中,增加了对在启动一个
Task
,ClusterTask
或Pipeline
时传递一个 CSI(Container Storage Interface)文件作为工作区的功能。 -
在这个版本中,为与任务、管道运行和任务运行资源关联的所有 CLI 命令添加了
v1
API 支持。Tekton CLI 适用于这些资源的v1beta1
和v1
API。 -
在这个版本中,增加了对
start
和describe
命令中的对象类型参数的支持。
4.1.3.1.4. Operator
-
在这个版本中,在可选管道属性中添加了
default-forbidden-env
参数。参数包括禁止的环境变量,在通过 pod 模板提供时不应传播它们。 -
在这个版本中,增加了对 Tekton Hub UI 中的自定义徽标的支持。要添加自定义徽标,请在 Tekton Hub CR 中将
customLogo
参数的值设置为 base64 编码 URI。 - 在这个版本中,git-clone 任务的版本号增加到 0.9。
4.1.3.1.5. Tekton Chains
Tekton 链只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
-
在这个版本中,在测试时为
PipelineRun
和TaskRun
添加注解和标签。 -
此更新添加了一个名为
slsa/v1
的新格式,它生成与以in-toto
格式请求时生成的相同度。 - 在这个版本中,Sigstore 功能从实验性功能中移出。
-
在这个版本中,
predicate.materials
函数包括来自TaskRun
对象的所有步骤和 sidecar 的镜像 URI 和摘要信息。
4.1.3.1.6. Tekton Hub
Tekton Hub 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
-
在这个版本中,支持在集群中安装、升级或降级
v1
API 版本的 Tekton 资源。 - 在这个版本中,支持添加自定义徽标来代替 UI 中的 Tekton Hub 徽标。
-
在这个版本中,对
tkn hub install
命令进行了扩展,增加了一个--type artifact
标记,它会从 Artifact Hub 获取资源并将其安装到集群中。 - 在这个版本中,增加了将 tier, catalog, 和 org 的信息作为标签添加到从 Artifact Hub 安装到您的集群中的资源的支持。
4.1.3.1.7. Pipelines 作为代码(Pipelines as Code)
-
这个版本增强了传入的 Webhook 支持。对于在 OpenShift Container Platform 集群上安装的 GitHub 应用程序,您不需要为传入的 webhook 提供
git_provider
规格。相反,Pipelines as Code 会检测 secret,并将其用于传入的 Webhook。 - 在这个版本中,您可以使用同一令牌从带有非默认分支的 GitHub 上的同一主机获取远程任务。
-
在这个版本中,Pipelines 作为代码支持 Tekton
v1
模板。您可以使用v1
和v1beta1
模板,Pipelines 作为 PR 生成的代码读取。PR 在集群上以v1
的形式创建。 -
在此次更新之前,当 OpenShift 命名空间中找不到运行时模板时,OpenShift 控制台 UI 将使用硬编码的管道运行模板作为回退模板。在这个版本中,
pipelines-as-code
配置映射中提供了一个新的默认管道运行模板,名为pipelines-as-code-template-default
供控制台使用。 - 在这个版本中,Pipelines as Code 支持 Tekton Pipelines 0.44.0 最小状态。
-
在这个版本中,Pipelines as Code 支持 Tekton
v1
API,这意味着 Pipelines as Code 现在与 Tekton v0.44 及更新的版本兼容。 - 在这个版本中,除了为 OpenShift 和 Tekton 仪表板为 k8s 配置控制台外,您还可以配置自定义控制台仪表板。
-
在这个版本中,Pipelines as Code 会检测使用
tkn pac create repo
命令启动的 GitHub 应用程序的安装,如果全局安装,则不需要 GitHub Webhook。 -
在此次更新之前,如果
PipelineRun
执行出现错误,而不是附加到PipelineRun
的任务,Pipelines as Code 无法正确报告失败。在这个版本中,Pipelines as Code 会在无法创建PipelineRun
时在 GitHub 检查中正确报告错误。 -
在这个版本中,Pipelines as Code 包含一个
target_namespace
变量,它扩展至执行PipelineRun
的当前运行命名空间。 - 在这个版本中,Pipelines 作为代码可让您绕过 CLI bootstrap GitHub 应用程序中的 GitHub Enterprise 问题。
- 在这个版本中,当找不到存储库 CR 时,Pipelines as Code 不会报告错误。
- 在这个版本中,如果找到多个管道使用相同名称运行,Pipelines as Code 会报告一个错误。
4.1.3.2. 可能会造成问题的更改
-
在这个版本中,
tkn
命令的早期版本与 Red Hat OpenShift Pipelines 1.10 不兼容。 -
在这个版本中,从 Tekton CLI 删除了对
Cluster
和CloudEvent
管道资源的支持。您不能使用tkn pipelineresource create
命令创建管道资源。另外,任务、集群任务或管道的start
命令中不再支持管道资源。 -
在这个版本中,从 Tekton 链中删除
tekton
作为公认格式。
4.1.3.3. 弃用和删除的功能
-
在 Red Hat OpenShift Pipelines 1.10 中,
ClusterTask
命令现已弃用,计划在以后的发行版本中删除。此更新中还弃用了tkn task create
命令。 -
在 Red Hat OpenShift Pipelines 1.10 中,
tkn task start
命令中使用的标记-i
和-o
现已弃用,因为v1
API 不支持管道资源。 -
在 Red Hat OpenShift Pipelines 1.10 中,
tkn pipeline start
命令一起使用的标志-r
已被弃用,因为v1
API 不支持管道资源。 -
Red Hat OpenShift Pipelines 1.10 更新将
openshiftDefaultEmbeddedStatus
参数设置为both
,带有full
和minimal
嵌入式状态。更改默认嵌入式状态的标记也已弃用,并将被删除。另外,管道默认嵌入式状态将在以后的版本中更改为minimal
。
4.1.3.4. 已知问题
这个版本包括以下向后兼容的更改:
-
删除
PipelineResources
集群 -
删除
PipelineResources
云事件
-
删除
如果在集群升级后管道指标功能无法正常工作,请运行以下命令作为临时解决方案:
$ oc get tektoninstallersets.operator.tekton.dev | awk '/pipeline-main-static/ {print $1}' | xargs oc delete tektoninstallersets
- 在这个版本中,IBM Power、IBM Z 和 {linuxoneProductName} 不支持使用外部数据库,如 Crunchy PostgreSQL。反之,使用默认的 Tekton Hub 数据库。
4.1.3.5. 修复的问题
-
在此次更新之前,
opc pac
命令会生成一个运行时错误,而不是显示任何帮助。在这个版本中修复了opc pac
命令来显示帮助信息。 -
在此次更新之前,运行
tkn pac create repo
命令创建仓库需要 Webhook 详情。在这个版本中,tkn-pac create repo
命令在安装 GitHub 应用程序时不会配置 Webhook。 -
在此次更新之前,当 Tekton Pipelines 创建
PipelineRun
资源时遇到问题时,Pipelines as Code 不会报告管道运行创建错误。例如,管道运行中的不存在的任务不会显示任何状态。在这个版本中,Pipelines as Code 显示来自 Tekton Pipelines 的正确错误消息以及缺少的任务。 - 在这个版本中,UI 页面在成功身份验证后重定向。现在,您会被重定向到您试图登录到 Tekton Hub 的同一页面。
-
在这个版本中修复了带有标志
--all-namespaces
和--output=yaml
的list
命令,用于集群任务、单个任务和管道。 -
在这个版本中,删除了
repo.spec.url
URL 末尾的正斜杠,使其与来自 GitHub 的 URL 匹配。 -
在此次更新之前,
marshalJSON
函数不会编译对象列表。在这个版本中,marshalJSON
函数会对对象列表进行 marshals 处理。 - 在这个版本中,Pipelines 作为代码可让您绕过 CLI bootstrap GitHub 应用程序中的 GitHub Enterprise 问题。
- 在这个版本中,当您的存储库有超过 100 个用户时,GitHub collaborator 会检查。
-
在这个版本中,任务或管道的
sign
和verify
命令现在可以在没有 kubernetes 配置文件的情况下正常工作。 - 在这个版本中,如果在命名空间中跳过修剪器,Tekton Operator 会清理保留的修剪器 cron 作业。
-
在此次更新之前,API
ConfigMap
对象不会更新为目录刷新间隔配置的值。在这个版本中修复了 Tekon Hub CR 中的CATALOG_REFRESH_INTERVAL
API。 在这个版本中,在更改
EmbeddedStatus
功能标记时,PipelineStatus
的协调已被修复。在这个版本中重置以下参数:-
status.runs
和status.taskruns
参数为nil
,带有minimal EmbeddedStatus
-
status.childReferences
参数为nil
,带有full EmbeddedStatus
-
-
在这个版本中,添加了一个到
ResolutionRequest
CRD 的转换配置。在这个版本中,可以正确地配置从v1alpha1.ResolutionRequest
请求到v1beta1.ResolutionRequest
请求的转换。 - 在这个版本中会检查与一个管道任务关联的重复工作区。
- 在这个版本中修复了在代码中启用解析器的默认值。
-
在这个版本中,使用解析器修复了
TaskRef
和PipelineRef
名称转换的问题。
4.1.3.6. Red Hat OpenShift Pipelines 正式发行(GA)1.10.1 发行注记
在这个版本中,Red Hat OpenShift Pipelines 正式发行(GA) 1.10.1 包括在 OpenShift Container Platform 4.11、4.12 和 4.13 中。
4.1.3.6.1. 修复了 Pipelines as Code 的问题
-
在此次更新之前,如果来自有效负载的源分支信息包含
refs/heads/
,但用户配置的目标分支仅包含分支名称,main
在 CEL 表达式中,推送请求将失败。在这个版本中,Pipelines as Code 会传递推送请求,并在有效负载中基本分支或目标分支具有refs/heads/
时触发管道。 -
在此次更新之前,当无法创建
PipelineRun
对象时,从 Tekton 控制器接收的错误不会被报告给用户。在这个版本中,Pipelines as Code 会向 GitHub 界面报告错误消息,以便用户可以对错误进行故障排除。Pipelines as Code 还会报告管道执行过程中发生的错误。 - 在这个版本中,当因为基础架构问题而无法在 OpenShift Container Platform 集群中创建 secret 时,Pipelines as Code 不会将 secret 回滚到 GitHub 检查接口。
- 在这个版本中,删除了从 Red Hat OpenShift Pipelines 不再使用的已弃用的 API。
4.1.3.7. Red Hat OpenShift Pipelines 正式发布 1.10.2 发行注记
在这个版本中,Red Hat OpenShift Pipelines 正式发行(GA) 1.10.2 包括在 OpenShift Container Platform 4.11、4.12 和 4.13 中。
4.1.3.7.1. 修复的问题
在此次更新之前,Tekton Operator 中的一个问题会阻止用户将 enable-api-fields
标志的值设置为 beta
。在这个版本中解决了这个问题。现在,您可以在 TektonConfig
CR 中将 enable-api-fields
标志的值设置为 beta
。
4.1.3.8. Red Hat OpenShift Pipelines 正式发布 1.10.3 发行注记
在这个版本中,Red Hat OpenShift Pipelines 正式发行(GA) 1.10.3 包括在 OpenShift Container Platform 4.11、4.12 和 4.13 中。
4.1.3.8.1. 修复的问题
在此次更新之前,Tekton Operator 不会公开任何自定义的性能配置字段。在这个版本中,作为集群管理员,您可以根据您的需要自定义 TektonConfig
CR 中的以下性能配置字段:
-
disable-ha
-
bucket
-
kube-api-qps
-
kube-api-burst
-
threads-per-controller
4.1.3.9. Red Hat OpenShift Pipelines 正式发行 1.10.4 发行注记
在这个版本中,Red Hat OpenShift Pipelines 正式发行(GA) 1.10.4 包括在 OpenShift Container Platform 4.11、4.12 和 4.13 中。
4.1.3.9.1. 修复的问题
-
在这个版本中解决了管道运行中的
PipelineRef
字段的捆绑包解析器转换问题。现在,转换功能会在转换后将kind
字段的值设置为Pipeline
。 -
在此次更新之前,
pipelinerun.timeouts
字段被重置为timeout.pipeline
值,忽略timeout.tasks
和timeout.finally
值。在这个版本中解决了这个问题,并为PipelineRun
资源设置正确的默认超时值。 - 在此次更新之前,控制器日志包含不必要的数据。在这个版本中解决了这个问题。
4.1.3.10. Red Hat OpenShift Pipelines 正式发布(GA)1.10.5 发行注记
在这个版本中,除了 4.11、4.12 和 4.13 外,Red Hat OpenShift Pipelines 正式发布 (GA) 1.10.5 包括在 OpenShift Container Platform 4.10 中。
Red Hat OpenShift Pipelines 1.10.5 仅适用于 OpenShift Container Platform 4.10、4.11、4.12 和 4.13 上的 pipelines-1.10
频道。它不适用于任何 OpenShift Container Platform 版本的 latest
频道。
4.1.3.10.1. 修复的问题
-
在此次更新之前,使用
oc
和tkn
命令无法列出或删除大型管道运行。在这个版本中,通过压缩导致这个问题的巨页注解解决了这个问题。请注意,如果管道运行在压缩后仍然太大,则还会出现同样的错误。 -
在此次更新之前,只有
pipelineRun.spec.taskRunSpecs[].podTemplate
对象中指定的 pod 模板才会被视为管道运行。在这个版本中,pipelineRun.spec.podTemplate
对象中指定的 pod 模板也会被考虑,并与pipelineRun.spec.taskRunSpecs[].podTemplate
对象中指定的模板合并。
4.1.4. Red Hat OpenShift Pipelines 正式发布 1.9 发行注记
在这个版本中,Red Hat OpenShift Pipelines 正式发行(GA) 1.9 包括在 OpenShift Container Platform 4.11、4.12 和 4.13 中。
4.1.4.1. 新功能
除了包括修复和稳定性改进的信息外,以下小节突出介绍了 Red Hat OpenShift Pipelines 1.9 中的新内容。
4.1.4.1.1. Pipelines
- 在这个版本中,您可以指定管道参数,并产生数组和对象字典形式。
- 在这个版本中,为您的工作区提供 Container Storage Interface (CSI) 和投射卷支持。
-
在这个版本中,您可以在定义管道步骤时指定
stdoutConfig
和stderrConfig
参数。定义这些参数有助于将标准输出和标准错误(与步骤相关联)捕获到本地文件。 -
在这个版本中,您可以在
steps[].onError
事件处理程序中添加变量,例如$(params.CONTINUE)
。 -
在这个版本中,您可以使用
PipelineResults
定义中的finally
任务的输出。例如,$(finally.<pipelinetask-name>.result.<result-name>)
,其中<pipelinetask-name>
代表管道任务名称,<result-name>
代表结果名称。 - 在这个版本中,支持任务运行的任务级资源要求。
- 在这个版本中,您不需要根据名称重新创建在管道和定义的任务之间共享的参数。这个版本是开发人员预览功能的一部分。
- 在这个版本中,增加了对远程解析的支持,如内置 git、集群、捆绑包和 hub 解析器。
4.1.4.1.2. 触发器
-
在这个版本中,添加了
Interceptor
CRD 来定义NamespacedInterceptor
。您可以在触发器的拦截器引用的kind
部分,或EventListener
规格中使用NamespacedInterceptor
。 -
这个版本启用了
CloudEvents
。 - 在这个版本中,您可以在定义触发器时配置 Webhook 端口号。
-
在这个版本中,支持使用触发器
eventID
作为TriggerBinding
的输入。 在这个版本中,支持为
ClusterInterceptor
服务器验证和轮转证书。-
触发器对核心拦截器执行证书验证,并在其证书过期时将新证书轮转到
ClusterInterceptor
。
-
触发器对核心拦截器执行证书验证,并在其证书过期时将新证书轮转到
4.1.4.1.3. CLI
-
在这个版本中,支持在
describe
命令中显示注释。 -
此更新支持在
pr describe
命令中显示管道、任务和超时。 -
在这个版本中,添加了在
pipeline start
命令中提供管道、任务和超时的标志。 -
在这个版本中,支持在任务和管道的
describe
命令中显示工作区(可选或强制)存在。 -
在这个版本中,添加了
timestamp
标记来显示带有时间戳的日志。 -
在这个版本中,添加了一个新的标记
--ignore-running-pipelinerun
,它会忽略删除与PipelineRun
关联的TaskRun
。 -
在这个版本中,增加了对实验性命令的支持。在这个版本中,对
tkn
CLI 工具增加了实验性的子命令sign
和verify
。 - 在这个版本中,Zsh (Zsh) 完成功能可在不生成任何文件的情况下使用。
此更新引入了一个名为
opc
的新 CLI 工具。预计即将推出的发行版本会将tkn
CLI 工具替换为opc
。重要-
新的 CLI 工具
opc
是一个技术预览功能。 -
opc
将是一个带有额外 Red Hat OpenShift Pipelines 特定功能的tkn
的替代,这些功能不一定适合tkn
。
-
新的 CLI 工具
4.1.4.1.4. Operator
在这个版本中,Pipelines as Code 会被默认安装。您可以使用
-p
标志禁用 Pipelines as Code:$ oc patch tektonconfig config --type="merge" -p '{"spec": {"platforms": {"openshift":{"pipelinesAsCode": {"enable": false}}}}}'
-
在这个版本中,您还可以在
TektonConfig
CRD 中修改 Pipelines 作为代码配置。 - 在这个版本中,如果禁用了开发人员视角,Operator 不会安装与开发人员控制台相关的自定义资源。
-
在这个版本中,包括对 Bitbucket 服务器和 Bitbucket 云的
ClusterTriggerBinding
支持,可帮助您在整个集群中重复使用TriggerBinding
。
4.1.4.1.5. 解析器
解析器只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
在这个版本中,您可以在
TektonConfig
CRD 中配置管道解析器。您可以启用或禁用这些管道解析器:enable-bundles-resolver
,enable-cluster-resolver
,enable-git-resolver
, 和enable-hub-resolver
。apiVersion: operator.tekton.dev/v1alpha1 kind: TektonConfig metadata: name: config spec: pipeline: enable-bundles-resolver: true enable-cluster-resolver: true enable-git-resolver: true enable-hub-resolver: true ...
您还可以在
TektonConfig
中提供特定于解析器的配置。例如,您可以使用map[string]string
格式定义以下字段来为单个解析器设置配置:apiVersion: operator.tekton.dev/v1alpha1 kind: TektonConfig metadata: name: config spec: pipeline: bundles-resolver-config: default-service-account: pipelines cluster-resolver-config: default-namespace: test git-resolver-config: server-url: localhost.com hub-resolver-config: default-tekton-hub-catalog: tekton ...
4.1.4.1.6. Tekton Chains
Tekton 链只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
-
在此次更新之前,只有开放容器项目 (OCI) 镜像可以作为 in-toto provenance 代理的
TaskRun
输出被支持。在这个版本中,通过使用以下后缀增加了 in-toto provenance 元数据作为输出的支持:ARTIFACT_URI
和ARTIFACT_DIGEST
。 -
在此次更新之前,只支持
TaskRun
attestations。在这个版本中,还添加了对PipelineRun
attestations 的支持。 -
在这个版本中,添加了对 Tekton Chains 的支持,以获取 pod 模板中的
imgPullSecret
参数。在这个版本中,您可以基于每个管道运行或任务运行配置存储库身份验证,而无需修改服务帐户。
4.1.4.1.7. Tekton Hub
Tekton Hub 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
在这个版本中,作为管理员,您可以使用外部数据库,如带有 Tekton Hub 的 Crunchy PostgreSQL,而不是使用默认的 Tekton Hub 数据库。这个版本可帮助您执行以下操作:
- 指定用于 Tekton Hub 的外部数据库的协调
- 禁用 Operator 部署的默认 Tekton Hub 数据库
在这个版本中,
config.yaml
从外部 Git 存储库删除依赖项,并将完整的配置数据移到 APIConfigMap
中。这个版本可帮助管理员执行以下操作:- 在 Tekton Hub 自定义资源中添加配置数据,如类别、目录、范围和 defaultScope。
- 修改集群中的 Tekton Hub 配置数据。所有修改都会在 Operator 升级时保留。
- 更新 Tekton Hub 目录列表
更改 Tekton Hub 的类别
注意如果没有添加任何配置数据,您可以使用 Tekton Hub 配置的 API
ConfigMap
中的默认数据。
4.1.4.1.8. Pipelines 作为代码(Pipelines as Code)
-
在这个版本中,增加了对
Repository
CRD 中并发限制的支持,以定义一次为仓库运行的最大PipelineRuns
数。来自拉取请求或推送事件的PipelineRuns
以字母顺序排列。 -
在这个版本中,添加了一个新的命令
tkn pac logs
,用于显示仓库的最新管道运行的日志。 在这个版本中,支持在文件路径上实现高级事件匹配,以便推送和拉取请求到 GitHub 和 GitLab。例如,只有当一个路径在
docs
目录中的任何 markdown 文件中都更改时,您才可以使用 Common Expression Language (CEL) 来运行管道。... annotations: pipelinesascode.tekton.dev/on-cel-expression: | event == "pull_request" && "docs/*.md".pathChanged()
-
在这个版本中,您可以使用注解在
pipelineRef:
对象中引用远程管道。 -
在这个版本中,您可以使用 Pipelines 作为代码自动配置新的 GitHub 仓库,它会设置命名空间并为 GitHub 仓库创建
Repository
CRD。 -
在这个版本中,Pipelines 作为代码为
PipelineRuns
生成指标,并带有供应商信息。 在这个版本中,为
tkn-pac
插件提供以下改进:- 正确检测运行的管道
- 修复了在没有失败完成时间显示持续时间的修复
-
在
tkn-pac describe
命令中显示错误片段,并突出显示错误的正则表达式模式 -
在
tkn-pac ls
和tkn-pac describe
命令中添加use-real-time
开关 -
导入
tkn-pac
日志文档 -
在
tkn-pac ls
和tkn-pac describe
命令中显示pipelineruntimeout
作为失败。 -
使用
--target-pipelinerun
选项显示特定的管道运行失败。
- 在这个版本中,您可以使用版本控制系统 (VCS) 注释或 GitHub 检查中的小片断的形式查看管道运行的错误。
- 在这个版本中,Pipelines 作为代码可以选择地检测任务中的错误(如果它们是简单格式),并在 GitHub 中将这些任务添加为注解。这个版本是开发人员预览功能的一部分。
在这个版本中添加了以下新命令:
-
tkn-pac webhook add
:在项目存储库设置中添加了一个 webhook,并在现有的k8s Secret
对象中更新了webhook.secret
键,而无需更新存储库。 -
tkn-pac webhook update-token
: 更新现有k8s Secret
对象的供应商令牌,而无需更新存储库。
-
-
这个版本增强了
tkn-pac create repo
命令的功能,该命令为 GitHub、GitLab 和 BitbucketCloud 创建并配置 Webhook,以及创建存储库。 -
在这个版本中,
tkn-pac describe
命令以一定的排序顺序显示最新的五十个事件。 -
在这个版本中,在
tkn-pac logs
命令中添加了--last
选项。 -
在这个版本中,
tkn-pac resolve
命令会在文件模板中检测git_auth_secret
时提示输入令牌。 - 在这个版本中,Pipelines 作为代码从日志片断中隐藏 secret,以避免在 GitHub 界面中公开 secret。
-
在这个版本中,为
git_auth_secret
自动生成 secret 是PipelineRun
的所有者引用。使用PipelineRun
清理 secret,而不是在管道运行执行后进行。 -
在这个版本中,增加了对使用
/cancel
注释取消管道运行的支持。 在此次更新之前,没有定义 GitHub 应用程序令牌范围,并将在每个存储库安装中使用令牌。在这个版本中,您可以使用以下参数将 GitHub 应用令牌范围到目标存储库:
-
secret-github-app-token-scoped
:将应用程序令牌范围到目标仓库,而不是应用程序安装可访问的每个存储库。 -
secret-github-app-scope-extra-repos
:使用额外的所有者或存储库自定义应用程序令牌的范围。
-
- 在这个版本中,您可以将 Pipelines 用作代码与在 GitLab 上托管的自己的 Git 存储库一起使用。
- 在这个版本中,您可以使用命名空间中的 kubernetes 事件的形式访问管道执行详情。这些详细信息可帮助您对管道错误进行故障排除,而无需访问 admin 命名空间。
- 在这个版本中,支持通过 Git 供应商在 Pipelines 中作为代码解析器验证 URL。
-
在这个版本中,您可以使用
pipelines-as-code
配置映射中的设置来设置 hub 目录的名称。 -
在这个版本中,您可以为
max-keep-run
参数设置最大和默认限值。 - 在这个版本中,添加了有关如何注入 Pipelines 作为代码中的自定义安全套接字层 (SSL) 证书的文档,可让您使用自定义证书连接到供应商实例。
-
在这个版本中,
PipelineRun
资源定义包含的日志 URL 作为注解。例如,tkn-pac describe
命令在描述PipelineRun
时显示日志链接。 -
在这个版本中,
tkn-pac
日志显示存储库名称,而不是PipelineRun
名称。
4.1.4.2. 可能会造成问题的更改
-
在这个版本中,
Conditions
自定义资源定义(CRD) 类型已被删除。作为替代方案,请使用WhenExpressions
替代。 -
在这个版本中,删除了
tekton.dev/v1alpha1
API pipeline 资源,如 Pipeline、PipelineRun、Task、Clustertask 和 TaskRun。 -
在这个版本中,
tkn-pac setup
命令已被删除。使用tkn-pac webhook add
命令将 webhook 重新添加到现有 Git 仓库。使用tkn-pac webhook update-token
命令为 Git 仓库中的现有 Secret 对象更新个人供应商访问令牌。 -
在这个版本中,运行带有默认设置的管道的命名空间不会将
pod-security.kubernetes.io/enforce:privileged
标签应用到工作负载。
4.1.4.3. 弃用和删除的功能
-
在 Red Hat OpenShift Pipelines 1.9.0 发行版本中,
ClusterTasks
已被弃用,计划在以后的发行版本中删除。作为替代方案,您可以使用Cluster Resolver
。 -
在 Red Hat OpenShift Pipelines 1.9.0 发行版本中,在单个
EventListener
规格中使用triggers
和namespaceSelector
字段已弃用,并计划在以后的发行版本中删除。您可以在不同的EventListener
规格中成功使用这些字段。 -
在 Red Hat OpenShift Pipelines 1.9.0 发行版本中,
tkn pipelinerun describe
命令不会显示PipelineRun
资源的超时。 -
在 Red Hat OpenShift Pipelines 1.9.0 发行版本中,PipelineResource' 自定义资源(CR) 已被弃用。
PipelineResource
CR 是一个技术预览功能,它是tekton.dev/v1alpha1
API 的一部分。 - 在 Red Hat OpenShift Pipelines 1.9.0 发行版本中,集群任务中的自定义镜像参数已弃用。另外,您可以复制集群任务并在其中使用自定义镜像。
4.1.4.4. 已知问题
-
卸载 Red Hat OpenShift Pipelines Operator 后会删除
chains-secret
和chains-config
配置映射。当它们包含用户数据时,应保留且不删除它们。
当在 Windows 上运行
tkn pac
命令集时,您可能会收到以下出错信息:Command finished with error: not supported by Windows。
临时解决方案:将
NO_COLOR
环境变量设置为true
。如果
tkn pac resolve
命令使用已模板化的参数值,则运行tkn pac resolve -f <filename> | oc create -f
命令可能无法提供预期的结果。临时解决方案: 要缓解这个问题,请通过运行
tkn pac resolve -f <filename> -o tempfile.yaml
命令将tkn pac resolve
命令的输出保持在一个临时文件中,然后运行oc create -f tempfile.yaml
命令。例如:tkn pac resolve -f <filename> -o /tmp/pull-request-resolved.yaml && oc create -f /tmp/pull-request-resolved.yaml
。
4.1.4.5. 修复的问题
- 在此次更新之前,在替换空数组后,原始阵列返回一个空字符串,从而导致其中的参数无效。在这个版本中,这个问题已被解决,原始阵列返回为空。
- 在此次更新之前,如果管道运行的服务帐户中存在重复的 secret,则会导致任务 pod 创建失败。在这个版本中,这个问题已解决,即使服务帐户中存在重复的 secret,任务 pod 也会成功创建。
-
在此次更新之前,通过查看 TaskRun 的
spec.StatusMessage
字段,用户无法区分TaskRun
是否已被用户取消或作为它一部分的PipelineRun
。在这个版本中,这个问题已被解决,用户可以通过查看TaskRun
的spec.StatusMessage
字段来区分 TaskRun 的状态。 - 在此次更新之前,在删除旧版本的无效对象时,webhook 验证会被删除。在这个版本中,这个问题已解决。
在此次更新之前,如果您将
timeouts.pipeline
参数设置为0
,您将无法设置timeouts.tasks
参数或timeouts.finally
参数。这个版本解决了这个问题。现在,当您设置timeouts.pipeline
参数值时,可以设置 `timeouts.tasks` 参数或timeouts.finally
参数。例如:yaml kind: PipelineRun spec: timeouts: pipeline: "0" # No timeout tasks: "0h3m0s"
- 在此次更新之前,如果 PipelineRun 或 TaskRun 上的另一个工具更新了标签或注解,则可能会出现竞争条件。在这个版本中,这个问题已被解决,您可以合并标签或注解。
- 在此次更新之前,日志密钥与管道控制器中的密钥不同。在这个版本中,这个问题已被解决,日志密钥已被更新,以匹配管道控制器的日志流。日志中的键已从 "ts" 改为 "timestamp",从 "level" 改为 "severity",从 "message" 改为 "msg"。
- 在此次更新之前,如果一个 PipelineRun 被删除并带有未知状态,则不会生成错误消息。在这个版本中,这个问题已解决,并生成错误消息。
-
在此次更新之前,若要访问
list
和push
等捆绑包命令,需要使用kubeconfig
文件。在这个版本中,这个问题已被解决,且kubeconfig
文件不需要访问捆绑包命令。 - 在此次更新之前,如果在删除 TaskRuns 时运行父 PipelineRun,则将删除 TaskRuns。在这个版本中,这个问题已被解决,如果父 PipelineRun 正在运行,TaskRuns 不会被删除。
- 在此次更新之前,如果用户试图构建带有超过管道控制器的对象的捆绑包,Tekton CLI 不会显示错误消息。在这个版本中,这个问题已解决,如果用户试图构建比管道控制器中允许的限制更多的对象,Tekton CLI 会显示错误消息。
-
在此次更新之前,如果从集群中删除命名空间,Operator 不会从
ClusterInterceptor ClusterRoleBinding
主题中删除命名空间。在这个版本中,这个问题已被解决,Operator 会从ClusterInterceptor ClusterRoleBinding
主题中删除命名空间。 -
在此次更新之前,Red Hat OpenShift Pipelines Operator 的默认安装会导致集群中的
pipelines-scc-rolebinding 安全上下文约束
(SCC) 角色绑定资源。在这个版本中,Red Hat OpenShift Pipelines Operator 的默认安装会导致pipelines-scc-rolebinding 安全性上下文约束
(SCC) 角色绑定资源被从集群中移除。
-
在此次更新之前,Pipelines as Code 不会从 Pipelines as Code
ConfigMap
对象获取更新的值。在这个版本中,这个问题已被解决,Pipelines as CodeConfigMap
对象会查找任何新的更改。 -
在此次更新之前,Pipelines as Code 控制器不会等待
tekton.dev/pipeline
标签被更新并添加checkrun id
标签,这会导致竞争条件。在这个版本中,Pipelines as Code 控制器会等待tekton.dev/pipeline
标签更新,然后添加checkrun id
标签,这有助于避免竞争条件。 -
在此次更新之前,如果 git 仓库中已存在,
tkn-pac create repo
命令不会覆盖PipelineRun
。在这个版本中,tkn-pac create
命令已被修复,如果 git 仓库中存在PipelineRun
,这会成功覆盖它。 -
在此次更新之前,
tkn pac describe
命令不会显示每个消息的原因。在这个版本中,这个问题已被解决,tkn pac describe
命令会显示每个消息的原因。 -
在此次更新之前,如果使用 regex 表单的注解中的用户提供值,则拉取请求会失败,如
refs/head/rel-*
。拉取请求失败,因为它在基础分支中缺少refs/heads
。在这个版本中,添加了前缀,并检查它是否匹配。这解决了这个问题,拉取请求可以成功。
4.1.4.6. Red Hat OpenShift Pipelines 正式发布 1.9.1 发行注记
在这个版本中,Red Hat OpenShift Pipelines 正式发行(GA) 1.9.1 包括在 OpenShift Container Platform 4.11、4.12 和 4.13 中。
4.1.4.7. 修复的问题
-
在此次更新之前,
tkn pac repo list
命令不会在 Microsoft Windows 上运行。在这个版本中解决了这个问题,您可以在 Microsoft Windows 上运行tkn pac repo list
命令。 - 在此次更新之前,Pipelines as Code watcher 不会接收所有配置更改事件。在这个版本中,Pipelines as Code watcher 已被更新,现在 Pipelines as Code watcher 不会丢失配置更改事件。
-
在此次更新之前,由 Pipelines as Code 创建的 pod,如
TaskRuns
或PipelineRuns
无法访问集群中用户公开的自定义证书。在这个版本中解决了这个问题,您可以从集群中的TaskRuns
或PipelineRuns
pod 访问自定义证书。 -
在此次更新之前,在使用 FIPS 启用的集群中,
Trigger
资源中使用的tekton-triggers-core-interceptors
内核拦截器在 Pipelines Operator 升级到 1.9 后无法正常工作。这个版本解决了这个问题。现在,OpenShift 将 MInTLS 1.2 用于其所有组件。因此,tekton-triggers-core-interceptors
core interceptor 对 TLS 版本 1.2 及其功能进行准确运行。 在此次更新之前,当使用带有内部 OpenShift 镜像 registry 的管道运行时,必须在管道运行定义中硬编码到镜像的 URL。例如:
... - name: IMAGE_NAME value: 'image-registry.openshift-image-registry.svc:5000/<test_namespace>/<test_pipelinerun>' ...
当在 Pipelines 作为代码上下文中使用管道运行时,这些硬编码值会阻止管道运行定义在不同的集群和命名空间中使用。
在这个版本中,您可以使用动态模板变量,而不是硬编码命名空间和管道运行名称的值,以常规化管道运行定义。例如:
... - name: IMAGE_NAME value: 'image-registry.openshift-image-registry.svc:5000/{{ target_namespace }}/$(context.pipelineRun.name)' ...
- 在此次更新之前,Pipelines as Code 使用相同的 GitHub 令牌获取默认 GitHub 分支上同一主机上提供的远程任务。这个版本解决了这个问题。现在,Pipelines as Code 使用相同的 GitHub 令牌从任何 GitHub 分支获取远程任务。
4.1.4.8. 已知问题
CATALOG_REFRESH_INTERVAL
的值(Tekton Hub CR 中使用的 Hub APIConfigMap
对象中的一个字段)不会更新,无法使用用户提供的自定义值进行更新。临时解决方案:无.您可以跟踪问题 SRVKP-2854。
4.1.4.9. 可能会造成问题的更改
- 在这个版本中,引入了一个 OLM 错误配置问题,这会阻止升级 OpenShift Container Platform。这个问题将在以后的发行版本中解决。
4.1.4.10. Red Hat OpenShift Pipelines 正式发布 1.9.2 发行注记
在这个版本中,Red Hat OpenShift Pipelines 正式发行(GA) 1.9.2 包括在 OpenShift Container Platform 4.11、4.12 和 4.13 中。
4.1.4.11. 修复的问题
- 在此次更新之前,之前的版本中引入了一个 OLM 错误配置问题,这会阻止 OpenShift Container Platform 升级。在这个版本中,这个错误问题已被修复。
4.1.4.12. Red Hat OpenShift Pipelines 正式发布(GA)1.9.3 发行注记
在这个版本中,除了 4.11、4.12 和 4.13 外,Red Hat OpenShift Pipelines 正式发布 (GA) 1.9.3 包括在 OpenShift Container Platform 4.10 中。
4.1.4.13. 修复的问题
- 在这个版本中解决了大型管道的性能问题。现在,CPU 的使用率减少了 61%,内存用量减少了 44%。
-
在此次更新之前,如果某个任务因为
when
表达式而没有运行,则管道运行会失败。在这个版本中,通过防止在管道结果中验证跳过的任务结果解决了这个问题。现在,管道结果不会被发送,管道运行不会因为缺少结果而失败。 -
在这个版本中,为
v1beta1
API 修复了pipelineref.bundle
转换到捆绑包解析器的问题。现在,转换功能会在转换完成后将kind
字段的值设置为Pipeline
。 -
在此次更新之前,Pipelines Operator 中的一个问题会阻止用户将
spec.pipeline.enable-api-fields
字段的值设置为beta
。在这个版本中解决了这个问题。现在,您可以在TektonConfig
自定义资源中将值设为beta
、alpha
和stable
。 - 在此次更新之前,因为集群错误,Pipelines as Code 无法创建 secret 时,它会在 GitHub 的 check run 过程中显示临时令牌(这个过程是公开的)。在这个版本中解决了这个问题。现在,在创建 secret 失败时,这个令牌不再显示在 GitHub 检查界面中。
4.1.4.14. 已知问题
- 目前,在 OpenShift Container Platform Web 控制台中的管道运行的 stop 选项存在一个已知问题。Actions 下拉列表中的 stop 选项无法正常工作,它无法取消管道运行。
因为自定义资源定义转换失败,升级到 Pipelines 版本 1.9.x 存在一个已知问题。
临时解决方案:在升级到 Pipelines 版本 1.9.x 之前,请执行红帽客户门户网站中解决方案中提到的步骤。
4.1.5. Red Hat OpenShift Pipelines 正式发布 1.8 发行注记
在这个版本中,Red Hat OpenShift Pipelines 正式发行(GA) 1.8 包括在 OpenShift Container Platform 4.10, 4.11 和 4.12 中。
4.1.5.1. 新功能
除了包括修复和稳定性改进的信息外,以下小节突出介绍了 Red Hat OpenShift Pipelines 1.8 中的新内容。
4.1.5.1.1. Pipelines
-
在这个版本中,您可以在在 ARM 硬件上运行 Red Hat OpenShift Pipelines GA 1.8 及更新的版本。这包括对
ClusterTask
资源和tkn
CLI 工具的支持。
在 ARM 硬件上运行 Red Hat OpenShift Pipelines 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
-
在这个版本中,为
TaskRun
资源实现了Step
和Sidecar
覆盖。 在这个版本中,在
PipelineRun
状态下添加了最小的TaskRun
和Run
状态。要启用此功能,在
TektonConfig
自定义资源定义的pipeline
部分,您必须将enable-api-fields
字段设置为alpha
。在这个版本中,管道运行功能的安全终止会从 alpha 功能提升到 stable 功能。因此,之前弃用的
PipelineRunCancelled
状态会保持弃用,计划在以后的发行版本中被删除。由于这个功能默认可用,所以您不再需要在
TektonConfig
自定义资源定义中将pipeline.enable-api-fields
字段设置为alpha
。在这个版本中,您可以使用工作区名称为管道任务指定工作区。这个更改可让您更轻松地为
Pipeline
和PipelineTask
资源指定共享的工作区。您还可以继续显式映射工作区。要启用此功能,在
TektonConfig
自定义资源定义的pipeline
部分,您必须将enable-api-fields
字段设置为alpha
。- 在这个版本中,内嵌规格中的参数会在不修改的情况下传播。
-
在这个版本中,您可以使用注解和标签指定
PipelineRun
资源引用的Task
资源所需的元数据。这样,在管道运行过程中,依赖执行上下文的Task
元数据可用。 -
在这个版本中,
params
和results
值增加了对象和字典类型。这个变化会影响向后兼容性,有时会破坏转发兼容性,比如使用较早的客户端和以后的 Red Hat OpenShift Pipelines 版本。这个版本更改了ArrayOrStruct
结构,它会影响使用 Go 语言 API 作为库的项目。 -
在这个版本中,为
PipelineRun
状态字段的SkippedTasks
字段添加了一个SkippingReason
值,以便用户了解跳过给定 PipelineTask 的原因。 在这个版本中,支持一个 alpha 功能,您可以使用
数组
类型从Task
对象发出结果。结果类型从字符串
改为ArrayOrString
。例如,任务可以指定类型来生成数组结果:kind: Task apiVersion: tekton.dev/v1beta1 metadata: name: write-array annotations: description: | A simple task that writes array spec: results: - name: array-results type: array description: The array results ...
另外,您可以运行一个任务脚本来填充数组的结果:
$ echo -n "[\"hello\",\"world\"]" | tee $(results.array-results.path)
要启用此功能,在
TektonConfig
自定义资源定义的pipeline
部分,您必须将enable-api-fields
字段设置为alpha
。这个功能正在进行中,它是 TEP-0076 的一部分。
4.1.5.1.2. 触发器
在这个版本中,
EventListener
规格中的TriggerGroups
字段从 alpha 功能转换为 stable 功能。使用此字段,您可以在选择和运行一组触发器前指定一组拦截器。由于这个功能默认可用,所以您不再需要在
TektonConfig
自定义资源定义中将pipeline.enable-api-fields
字段设置为alpha
。-
在这个版本中,
Trigger
资源通过运行使用 HTTPS 的ClusterInterceptor
服务器来支持端到端安全连接。
4.1.5.1.3. CLI
-
在这个版本中,您可以使用
tkn taskrun export
命令,将集群中运行的 live 任务导出到 YAML 文件,您可以使用它来将任务运行导入到另一个集群。 -
在这个版本中,您可以在
tkn pipeline start
命令中添加-o name
标志,以便在启动后打印管道运行的名称。 -
在这个版本中,在
tkn --help
命令的输出中添加了可用插件列表。 -
在这个版本中,在删除管道运行或任务运行时,您可以同时使用
--keep
和--keep-since
标志。 -
在这个版本中,您可以使用
Cancelled
作为spec.status
字段的值,而不是弃用的PipelineRunCancelled
值。
4.1.5.1.4. Operator
- 在这个版本中,作为管理员,您可以将本地 Tekton Hub 实例配置为使用自定义数据库,而不是默认数据库。
在这个版本中,作为集群管理员,如果您启用本地 Tekton Hub 实例,它会定期刷新数据库,以便目录中的更改出现在 Tekton Hub web 控制台中。您可以调整刷新之间的周期。
在以前的版本中,要将目录中的任务和管道添加到数据库中,您需要手动执行该任务或设置 cron 任务来为您完成这个任务。
- 在这个版本中,您可以使用最小配置安装并运行 Tekton Hub 实例。这样,您可以开始使用团队来确定他们可能需要的其他自定义。
-
在这个版本中,将
GIT_SSL_CAINFO
添加到git-clone
任务,以便您可以克隆安全的存储库。
4.1.5.1.5. Tekton Chains
Tekton 链只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
- 在这个版本中,您可以使用 OIDC 而不是静态令牌登录到 vault。这个更改意味着 Spire 可以生成 OIDC 凭证,以便只允许可信工作负载登录到 vault。另外,您可以将 vault 地址作为配置值传递,而不是将其作为环境变量注入。
-
在升级 Red Hat OpenShift Pipelines Operator 后,
openshift-pipelines
命名空间中的 Tekton Chains 的chains-config
配置映射会自动重置为 default,因为在使用 Red Hat OpenShift Pipelines Operator 安装时不支持直接更新配置映射。但是,在此次更新中,您可以使用TektonChain
自定义资源配置 Tekton 链。这个功能可让您在升级后保留配置,这与chains-config
配置映射不同,这在升级过程中会被覆盖。
4.1.5.1.6. Tekton Hub
Tekton Hub 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
在这个版本中,如果您使用 Operator 安装一个新的 Tekton Hub 实例,则 Tekton Hub 登录默认是禁用的。要启用登录和评级功能,必须在安装 Tekton Hub 时创建 Hub API secret。
注意因为在 Red Hat OpenShift Pipelines 1.7 中默认启用了 Tekton Hub 登录,所以如果升级 Operator,在 Red Hat OpenShift Pipelines 1.8 中会默认启用登录。要禁用此登录,请参阅从 OpenShift Pipelines 1.7.x -→ 1.8.x 升级后禁用 Tekton Hub 登录
在这个版本中,作为管理员,您可以将本地 Tekton Hub 实例配置为使用自定义 PostgreSQL 13 数据库,而不是默认数据库。为此,请创建一个名为
tekton-hub-db
的Secret
资源。例如:apiVersion: v1 kind: Secret metadata: name: tekton-hub-db labels: app: tekton-hub-db type: Opaque stringData: POSTGRES_HOST: <hostname> POSTGRES_DB: <database_name> POSTGRES_USER: <username> POSTGRES_PASSWORD: <password> POSTGRES_PORT: <listening_port_number>
- 在这个版本中,您不再需要登录到 Tekton Hub web 控制台,将目录中的资源添加到数据库。现在,当 Tekton Hub API 首次运行时,这些资源会自动添加。
- 在这个版本中,通过调用目录刷新 API 作业,每 30 分钟自动刷新目录。用户可以配置这个间隔。
4.1.5.1.7. Pipelines 作为代码(Pipelines as Code)
Pipelines as Code (PAC) 只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
-
在这个版本中,作为开发人员,如果您试图将重复的存储库添加到 Pipelines 作为代码运行,则从
tkn-pac
CLI 工具获得通知。输入tkn pac create repository
时,每个仓库必须具有一个唯一的 URL。此通知还有助于防止劫持漏洞攻击。 -
在这个版本中,作为开发人员,您可以使用新的
tkn-pac setup cli
命令,使用 webhook 机制将 Git 存储库作为代码添加到 Pipelines 中。这样,即使在使用 GitHub Apps 时也可以使用 Pipelines 作为代码。此功能包括对 GitHub、GitLab 和 BitBucket 上的存储库的支持。 在这个版本中,Pipelines 作为代码支持 GitLab 与特征集成,如下所示:
- 项目或组的 ACL(访问权限控制列表)
-
允许的用户的
/ok-to-test
支持 -
/retest
支持。
在这个版本中,您可以使用通用表达式语言 (CEL) 执行高级管道过滤。使用 CEL,您可以使用
PipelineRun
资源中的注解匹配带有不同 Git 供应商事件的管道运行。例如:... annotations: pipelinesascode.tekton.dev/on-cel-expression: | event == "pull_request" && target_branch == "main" && source_branch == "wip"
-
在以前的版本中,作为开发人员,每个 Git 事件在
.tekton
目录中只能运行一个管道运行,如拉取请求。在这个版本中,您可以在.tekton
目录中运行多个管道。Web 控制台显示运行的状态和报告。管道并行运行,并报告回 Git 提供程序接口。 -
在这个版本中,您可以通过对拉取请求为
/test
或/retest
添加注释来测试或重新测试管道运行。您还可以按名称指定管道运行。例如,您可以输入/test <pipelinerun_name>
或/retest <pipelinerun-name>
。 -
在这个版本中,您可以使用新的
tkn-pac delete repository
命令删除存储库自定义资源及其关联的 secret。
4.1.5.2. 可能会造成问题的更改
在这个版本中,
TaskRun
和PipelineRun
资源的默认指标级别改为以下值:apiVersion: v1 kind: ConfigMap metadata: name: config-observability namespace: tekton-pipelines labels: app.kubernetes.io/instance: default app.kubernetes.io/part-of: tekton-pipelines data: _example: | ... metrics.taskrun.level: "task" metrics.taskrun.duration-type: "histogram" metrics.pipelinerun.level: "pipeline" metrics.pipelinerun.duration-type: "histogram"
-
在这个版本中,如果
Pipeline
和PipelineRun
资源中存在注解或标签,Run
类型中的值将具有优先权。如果Task
和TaskRun
资源中存在注解或标签,则也是如此。 -
在 Red Hat OpenShift Pipelines 1.8 中,之前弃用的
PipelineRun.Spec.ServiceAccountNames
字段已被删除。使用PipelineRun.Spec.TaskRunSpecs
字段替代。 -
在 Red Hat OpenShift Pipelines 1.8 中,之前已弃用的
TaskRun.Status.ResourceResults.ResourceRef
字段已被删除。使用TaskRun.Status.ResourceResults.ResourceName
字段。 -
在 Red Hat OpenShift Pipelines 1.8 中,之前已弃用的
Conditions
资源类型已被删除。从包含它的Pipeline
资源定义中删除Conditions
资源。在PipelineRun
定义中使用when
表达式。
-
对于 Tekton 链,在这个发行版本中删除了
tekton-provenance
格式。通过在TektonChain
自定义资源中设置"artifacts.taskrun.format": "in-toto"
来使用in-toto
格式。
Red Hat OpenShift Pipelines 1.7.x 作为代码 0.5.x 附带。当前的更新附带了 Pipelines,作为代码 0.10.x。此更改在新控制器的
openshift-pipelines
命名空间中创建新路由。您必须在使用 Pipelines 作为代码的 GitHub Apps 或 Webhook 中更新此路由。要获取路由,请使用以下命令:$ oc get route -n openshift-pipelines pipelines-as-code-controller \ --template='https://{{ .spec.host }}'
-
在这个版本中,Pipelines 作为 Code 会重命名
Repository
自定义资源定义 (CRD) 的默认 secret 密钥。在 CRD 中,将token
替换为provider.token
,并将secret
替换为webhook.secret
。 -
在这个版本中,Pipelines 作为代码将特殊模板变量替换为支持用于私有仓库的多个管道运行的特殊模板变量。在管道运行中,将
secret: pac-git-basic-auth-{{repo_owner}}-{{repo_name}}
替换为secret: {{ git_auth_secret }}
。 在这个版本中,Pipelines as Code 更新
tkn-pac
CLI 工具中的以下命令:-
将
tkn pac repository create
替换为tkn pac create repository
。 -
将
tkn pac repository delete
替换为tkn pac delete repository
。 -
将
tkn pac repository list
替换为tkn pac list
。
-
将
4.1.5.3. 弃用和删除的功能
从 OpenShift Container Platform 4.11 开始,会删除用于安装和升级 Red Hat OpenShift Pipelines Operator 的
preview
和stable
频道。要安装和升级 Operator,请使用适当的pipelines-<version>
频道,或最新稳定版本的latest
频道。例如,要安装 Pipelines Operator 版本1.8.x
,请使用pipelines-1.8
频道。注意在 OpenShift Container Platform 4.10 及更早的版本中,您可以使用
preview
和stable
频道来安装和升级 Operator。对
tekton.dev/v1alpha1
API 版本的支持(在 Red Hat OpenShift Pipelines GA 1.6 中已弃用)计划在以后的 Red Hat OpenShift Pipelines GA 1.9 发行版本中删除。此更改会影响管道组件,其中包括
TaskRun
,PipelineRun
,Task
,Pipeline
, 和tekton.dev/v1alpha1
类似。另外,将现有资源更新为使用apiVersion: tekton.dev/v1beta1
,如 Migrating From Tekton v1alpha1 to Tekton v1beta1 所述。对
tekton.dev/v1alpha1
API 版本的程序错误修复和支持仅到当前 GA 1.8 生命周期结束为止。重要对于 Tekton Operator,
operator.tekton.dev/v1alpha1
API 版本没有弃用。您不需要更改此值。-
在 Red Hat OpenShift Pipelines 1.8 中,
PipelineResource
自定义资源 (CR) 可用,但不再被支持。PipelineResource
CR 是一个技术预览功能,它属于tekton.dev/v1alpha1
API 的一部分,它已被弃用,并计划在以后的 Red Hat OpenShift Pipelines GA 1.9 发行版本中删除。 -
在 Red Hat OpenShift Pipelines 1.8 中,
Condition
自定义资源 (CR) 已删除。Condition
CR 是tekton.dev/v1alpha1
API 的一部分,它已被弃用,计划在以后的 Red Hat OpenShift Pipelines GA 1.9 发行版本中删除。 -
在 Red Hat OpenShift Pipelines 1.8 中,
gsutil
的gcr.io
镜像已被删除。这个删除可能会破坏带有依赖于此镜像的Pipeline
资源的集群。程序错误修复和支持只到 Red Hat OpenShift Pipelines 1.7 生命周期结束为主。
-
在 Red Hat OpenShift Pipelines 1.8 中,
Pipeline.Status.TaskRuns
和PipelineRun.Status.Runs
字段已弃用,计划在以后的发行版本中被删除。请参阅 PipelineRuns 中的 TEP-0100: 嵌入式 TaskRuns 和 Runs Status。 在 Red Hat OpenShift Pipelines 1.8 中,
pipelineRunCancelled
状态已弃用,计划在以后的发行版本中被删除。现在,PipelineRun
对象的安全终止已从 alpha 功能提升到 stable 功能。(请参阅 TEP-0058: Graceful Pipeline Run Termination。) 另外,您可以使用Cancelled
状态替换pipelineRunCancelled
状态。您不需要更改
Pipeline
和Task
资源。如果您有会取消管道运行的工具,则必须在下一个发行版本中更新这些工具。这个更改也会影响 CLI、IDE 扩展等工具,以便支持新的PipelineRun
状态。由于这个功能默认可用,所以您不再需要在
TektonConfig
自定义资源定义中将pipeline.enable-api-fields
字段设置为alpha
。在 Red Hat OpenShift Pipelines 1.8 中,
PipelineRun
中的timeout
字段已弃用。反之,使用PipelineRun.Timeouts
字段,它现在从 alpha 功能提升到 stable 功能。由于这个功能默认可用,所以您不再需要在
TektonConfig
自定义资源定义中将pipeline.enable-api-fields
字段设置为alpha
。-
在 Red Hat OpenShift Pipelines 1.8 中,
init
容器在LimitRange
对象的默认请求计算中省略。
4.1.5.4. 已知问题
s2i-nodejs
管道无法使用nodejs:14-ubi8-minimal
镜像流来执行 source-to-image (S2I) 构建。使用该镜像流会生成一个error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127
信息。临时解决方案: 使用
nodejs:14-ubi8
而不是nodejs:14-ubi8-minimal
镜像流。
当您运行 Maven 和 Jib-Maven 集群任务时,默认容器镜像仅支持 Intel(x86)架构。因此,在 ARM、IBM Power Systems(ppc64le)、IBM Z 和 LinuxONE (s390x) 集群上的任务将失败。
作为临时解决方案,您可以通过将
MAVEN_IMAGE
参数值设置为maven:3.6.3-adoptopenjdk-11
来指定自定义镜像。提示在您使用
tkn hub
在 ARM、IBM Power Systems(ppc64le)、IBM Z 和 LinuxONE(s390x) 上基于 Tekton Catalog 安装任务前,请验证是否可以在这些平台上执行任务。要检查ppc64le
和s390x
是否列在任务信息的"Platforms"部分,您可以运行以下命令:tkn hub info task <name>
-
在 ARM、IBM Power Systems、IBM Z 和 LinuxONE 中,不支持
s2i-dotnet
集群任务。
-
隐式参数映射会错误地将参数从顶级
Pipeline
或PipelineRun
定义传递给taskRef
任务。映射应该只在顶层资源中使用任务进行,并带有非线taskSpec
规格。这个问题只通过将TektonConfig
自定义资源定义的pipeline
部分中的enable-api-fields
字段设置为alpha
来影响启用了这个功能的集群。
4.1.5.5. 修复的问题
- 在此次更新之前,管道的指标在 Web 控制台的 Developer 视图中运行的指标不完整且过期。在这个版本中,这个问题已被解决,指标正确。
-
在此次更新之前,如果管道有两个失败并有
retries=2
的并行任务,则最终任务永不会运行,管道超时并且无法运行。例如,pipelines-operator-subscription
任务会间歇性地失败,并显示以下错误消息:Unable to connect to server: EOF
。在这个版本中,这个问题已被解决,以便最终任务始终运行。 -
在此次更新之前,如果管道运行因为任务运行失败而停止,则其他任务运行可能无法完成重试。因此,不会调度
finally
任务,这会导致管道挂起。 这个版本解决了这个问题。TaskRuns
和Run
对象可以在管道运行停止时重试,即使是安全停止也是如此,以便管道运行可以完成。 -
在这个版本中,当
TaskRun
对象的命名空间中存在一个或多个LimitRange
对象时,会改变如何计算资源要求。现在,当从LimitRange
对象发出请求时,调度程序现在考虑step
容器并排除所有其他应用容器,如 sidecar 容器。 -
在此次更新之前,在特定的条件下,标志软件包可能会错误地解析子命令,并带有双短划线终止符
--
。在这种情况下,它会运行 entrypoint 子命令,而不是实际命令。在这个版本中解决了这个问题,这个问题会解决,entrypoint 会运行正确的命令。 -
在此次更新之前,如果拉取镜像失败,控制器可能会生成多个 panics,或者其拉取 (pull) 状态不完整。在这个版本中解决了这个问题,方法是检查
step.ImageID
值而不是status.TaskSpec
值。 -
在此次更新之前,取消一个包含未计划的自定义任务的管道运行会生成
PipelineRunCouldntCancel
错误。在这个版本中解决了这个问题。您可以取消包含非调度自定义任务的管道运行,而不会生成这个错误。 在此次更新之前,如果在
$params["<NAME>"]
或$params['<NAME>']
的<NAME>
中包括了一个句点字符 (.
),则不会提取句点右侧的任何部分。例如,对于$params["org.ipsum.lorem"]
,只会提取yorg
部分。在这个版本中解决了这个问题,
$params
可以提取完整的值。例如,$params["org.ipsum.lorem"]
和$params['org.ipsum.lorem']
是有效的,<NAME>
的完整值org.ipsum.lorem
都会被提取。如果
<NAME>
没有包含在单引号或双引号中,还会抛出一个错误。例如,$params.org.ipsum.lorem
是无效,并生成验证错误。
-
在这个版本中,
Trigger
资源支持自定义拦截器,并确保自定义拦截器服务的端口与ClusterInterceptor
定义文件中的端口相同。
-
在此次更新之前,Tekton Chains 和 Operator 组件的
tkn version
命令无法正常工作。在这个版本中解决了这个问题,命令可以正常工作,并返回这些组件的版本信息。 -
在此次更新之前,如果您运行
tkn pr delete --ignore-running
命令,且管道运行没有status.condition
值,tkn
CLI 工具会生成 null-pointer 错误 (NPE)。在这个版本中解决了这个问题,CLI 工具现在会生成错误,并正确忽略仍然运行的管道运行。 -
在此次更新之前,如果您使用
tkn pr delete --keep <value>
或tkn tr delete --keep <value>
命令,且管道运行或任务运行的数量小于其中的值,则命令不会如预期返回一个错误。在这个版本中解决了这个问题,以便命令在这些条件下正确返回错误。 -
在此次更新之前,如果您使用
tkn pr delete
或tkn tr delete
命令以及-p
或-t
标志与--ignore-running
标志一起,则命令会错误地删除运行或待处理资源。在这个版本中解决了这个问题,这些命令可以正确地忽略运行或待处理资源。
-
在此版本中,您可以使用
TektonChain
自定义资源配置 Tekton 链。这个功能可让您在升级后保留配置,这与chains-config
配置映射不同,这在升级过程中会被覆盖。 -
在这个版本中,除了
buildah
和s2i
集群任务外,ClusterTask
资源不再默认以 root 用户身份运行。 -
在此次更新之前,当将
init
用作第一个参数并后跟两个或更多个参数时,Red Hat OpenShift Pipelines 1.7.1 上的任务会失败。在这个版本中,这些标志会被正确解析,任务可以运行成功。 在此次更新之前,因为存在无效的角色绑定,在 OpenShift Container Platform 4.9 和 4.10 上安装 Red Hat OpenShift Pipelines Operator 会失败,并显示以下错误消息:
error updating rolebinding openshift-operators-prometheus-k8s-read-binding: RoleBinding.rbac.authorization.k8s.io "openshift-operators-prometheus-k8s-read-binding" is invalid: roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"Role", Name:"openshift-operator-read"}: cannot change roleRef
在这个版本中解决了这个问题,不再会发生失败。
-
在以前的版本中,升级 Red Hat OpenShift Pipelines Operator 会导致重新创建
pipeline
服务帐户,这意味着链接到服务帐户的 secret 会丢失。在这个版本中解决了这个问题。在升级过程中,Operator 不再重新创建pipeline
服务帐户。因此,已附加到pipeline
服务帐户的 secret 在升级后会保留,资源(任务和管道)可以继续正常工作。 -
在这个版本中,如果在
TektonConfig
自定义资源 (CR) 中配置了基础架构节点设置,Pipelines as Code pod 在基础架构节点上运行。 在以前的版本中,使用资源修剪器时,每个命名空间 Operator 创建了一个在独立容器中运行的命令。这个设计在有大量命名空间的集群中消耗太多资源。例如,要运行单个命令,带有 1000 个命名空间的集群会在 pod 中生成 1000 个容器。
在这个版本中解决了这个问题。它将基于命名空间的配置传递给作业,以便所有命令在循环中的一个容器中运行。
-
在 Tekton Chains 中,您必须定义一个名为
signed-secrets
的 secret,以存放用于签名任务和镜像的密钥。但是,在更新前,更新 Red Hat OpenShift Pipelines Operator 会重置或覆盖这个 secret,密钥会丢失。在这个版本中解决了这个问题。现在,如果在通过 Operator 安装 Tekton Chains 后配置了 secret,secret 会保留,且升级不会覆盖它。 在此次更新之前,所有 S2I 构建任务都会失败,并显示类似以下消息的错误:
Error: error writing "0 0 4294967295\n" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted time="2022-03-04T09:47:57Z" level=error msg="error writing \"0 0 4294967295\\n\" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted" time="2022-03-04T09:47:57Z" level=error msg="(unable to determine exit status)"
在这个版本中,
pipeline-scc
安全性上下文约束 (SCC) 与Buildah
和S2I
集群任务所需的SETFCAP
功能兼容。因此,Buildah
和S2I
构建任务可以成功运行。要成功运行
Buildah
集群任务和S2I
构建任务,适用于使用各种语言和框架编写的应用程序,添加以下适当的steps
对象(如build
和push
)的代码片段。securityContext: capabilities: add: ["SETFCAP"]
- 在此次更新之前,安装 Red Hat OpenShift Pipelines Operator 所需的时间比预期的要长。这个版本会优化一些设置来加快安装过程。
-
在这个版本中,Buildah 和 S2I 集群任务比之前的版本要少。有些步骤已合并到一个步骤中,它们最好使用
ResourceQuota
和LimitRange
对象,且不需要更多资源。 -
在这个版本中,在集群任务中升级 Buildah、
tkn
CLI 工具和skopeo
CLI 工具版本。 -
在此次更新之前,如果任何命名空间处于
Terminating
状态,Operator 会在创建 RBAC 资源时失败。在这个版本中,Operator 忽略了命名空间处于Terminating
状态,并创建 RBAC 资源。 -
在此次更新之前,prune cronjobs 的 pod 没有在基础架构节点上调度。相反,它们被调度到 worker 节点上,或没有调度到任何节点。在这个版本中,如果在
TektonConfig
自定义资源 (CR) 中进行了配置,这些类型的 pod 可以在基础架构节点上调度。
4.1.5.6. Red Hat OpenShift Pipelines 正式发布 1.8.1 发行注记
在这个版本中,Red Hat OpenShift Pipelines 正式发行(GA) 1.8.1 包括在 OpenShift Container Platform 4.10, 4.11 和 4.12 中。
4.1.5.6.1. 已知问题
默认情况下,容器具有 restricted 权限来提高安全性。restricted 权限适用于 Red Hat OpenShift Pipelines Operator 中的所有控制器 pod,以及一些集群任务。由于权限受限,
git-clone
集群任务在特定配置下会失败。临时解决方案:无.您可以跟踪此问题 SRVKP-2634。
当安装程序集合处于失败状态时,
TektonConfig
自定义资源的状态会被错误地显示为True
,而不是False
。示例:失败的安装程序集
$ oc get tektoninstallerset NAME READY REASON addon-clustertasks-nx5xz False Error addon-communityclustertasks-cfb2p True addon-consolecli-ftrb8 True addon-openshift-67dj2 True addon-pac-cf7pz True addon-pipelines-fvllm True addon-triggers-b2wtt True addon-versioned-clustertasks-1-8-hqhnw False Error pipeline-w75ww True postpipeline-lrs22 True prepipeline-ldlhw True rhosp-rbac-4dmgb True trigger-hfg64 True validating-mutating-webhoook-28rf7 True
示例: 不正确的
TektonConfig
状态$ oc get tektonconfig config NAME VERSION READY REASON config 1.8.1 True
4.1.5.6.2. 修复的问题
-
在此次更新之前,pruner 会删除运行管道的任务运行,并显示以下警告:
some tasks were indicated completed without ancestors being done
。在这个版本中,pruner 会保留作为运行管道一部分的任务运行。 -
在此次更新之前,
pipeline-1.8
是安装 Red Hat OpenShift Pipelines Operator 1.8.x 的默认频道。在这个版本中,latest
是默认频道。 - 在此次更新之前,作为 Code 控制器 pod 的 Pipelines 无法访问用户公开的证书。在这个版本中,Pipelines as Code 可以访问路由,Git 存储库由自签名或自定义证书保护。
- 在此次更新之前,在从 Red Hat OpenShift Pipelines 1.7.2 升级到 1.8.0 后,任务会失败并带有 RBAC 错误。在这个版本中,任务会成功运行,不会出现 RBAC 错误。
-
在此次更新之前,无法使用
tkn
CLI 工具删除包含类型为array
的result
对象的任务运行和管道运行。在这个版本中,可以使用tkn
CLI 工具删除包含类型为array
的result
对象的任务运行和管道运行。 -
在此次更新之前,如果管道规格包含带有类型为
array
的ENV_VARS
参数的任务,则管道运行会失败,并带有以下错误:invalid input params for task func-buildpacks: param types don’t match the user-specified type: [ENV_VARS]
。在这个版本中,带有这样的管道和任务规格的管道不会失败。 -
在此次更新之前,集群管理员无法向
Buildah
集群任务提供config.json
文件来访问容器 registry。在这个版本中,集群管理员可以使用dockerconfig
工作区为Buildah
集群任务提供config.json
文件。
4.1.5.7. Red Hat OpenShift Pipelines General Availability 1.8.2 发行注记
在这个版本中,Red Hat OpenShift Pipelines 正式发行(GA) 1.8.2 包括在 OpenShift Container Platform 4.10, 4.11 和 4.12 中。
4.1.5.7.1. 修复的问题
-
在此次更新之前,当使用 SSH 密钥克隆存储库时,
git-clone
任务会失败。在这个版本中,git-init
任务中的非 root 用户的角色会被删除,SSH 程序会在$HOME/.ssh/
目录中查找正确的密钥。
4.1.6. Red Hat OpenShift Pipelines 正式发行 1.7 发行注记
在这个版本中,Red Hat OpenShift Pipelines 正式发行(GA)1.7 包括在 OpenShift Container Platform 4.9, 4.10, 和 4.11 中。
4.1.6.1. 新功能
除了包括修复和稳定性改进的信息外,以下小节突出介绍了 Red Hat OpenShift Pipelines 1.7 中的新内容。
4.1.6.1.1. Pipelines
在这个版本中,
pipelines-<version>
是安装 Red Hat OpenShift Pipelines Operator 的默认频道。例如,安装 Pipelines Operator1.7
的默认频道是pipelines-1.7
。集群管理员还可使用latest
频道来安装 Operator 的最新稳定版本。注意preview
和stable
频道将在以后的版本中被弃用并删除。当您在用户命名空间中运行命令时,您的容器以
root
身份运行(用户 ID0
),但对主机具有用户特权。在这个版本中,要在用户命名空间中运行 pod,您必须传递 CRI-O 期望的注解。-
要为所有用户添加这些注解,请运行
oc edit clustertask buildah
命令并编辑buildah
集群任务。 - 要将注解添加到特定命名空间,请将集群任务导出为该命名空间的任务。
-
要为所有用户添加这些注解,请运行
在此次更新之前,如果没有满足某些条件,则
when
表达式会跳过一个Task
对象及其依赖的任务。在这个版本中,您可以限制when
表达式只保护Task
对象,而不是它的依赖项任务。要启用此更新,请在TektonConfig
CRD 中将scope-when-expressions-to-task
标志设置为true
。注意scope-when-expressions-to-task
标记已弃用,并将在以后的发行版本中删除。作为 Pipelines 的最佳实践,请只使用when
表达式范围到被保证的Task
。-
在这个版本中,您可以在任务中的工作区的
subPath
字段中使用变量替换。 在这个版本中,您可以使用带单引号或双引号的 bracket 表示法引用参数和结果。在此次更新之前,只能使用点表示法。例如,现在以下内容等同于:
$(param.myparam)
,$(param['myparam'])
, and$(param["myparam"])
.您可以使用单引号或双引号括起包含有问题的字符的参数名称,如
"."
。例如,$(param['my.param'])
和$(param["my.param"])
。
-
在这个版本中,您可以在任务定义中包含步骤的
onError
参数,而无需启用enable-api-fields
标志。
4.1.6.1.2. 触发器
-
在这个版本中,
feature-flag-triggers
配置映射具有一个新的字段labels-exclusion-pattern
。您可以将此字段的值设置为正则表达式(regex)模式。控制器过滤出与事件监听器从事件监听器传播到为事件监听器创建的资源匹配的正则表达式模式的标签。 -
在这个版本中,
TriggerGroups
字段添加到EventListener
规格中。使用此字段,您可以在选择和运行一组触发器前指定要运行的拦截器。要启用此功能,在TektonConfig
自定义资源定义的pipeline
部分,您必须将enable-api-fields
字段设置为alpha
。 -
在这个版本中,
Trigger
资源支持TriggerTemplate
模板定义的自定义运行。 -
在这个版本中,Triggers 支持从
EventListener
pod 发送 Kubernetes 事件。 -
在这个版本中,以下对象提供了计数指标:
ClusterInteceptor
、EventListener
、TriggerTemplate
、ClusterTriggerBinding
和TriggerBinding
。 -
在这个版本中,
ServicePort
规格添加到 Kubernetes 资源。您可以使用此规格来修改公开事件监听器服务的端口。默认端口为8080
。 -
在这个版本中,您可以使用
EventListener
规格中的targetURI
字段在触发器处理过程中发送云事件。要启用此功能,在TektonConfig
自定义资源定义的pipeline
部分,您必须将enable-api-fields
字段设置为alpha
。 -
在这个版本中,
tekton-triggers-eventlistener-roles
对象除了已存在的create
动词外,现在还添加了一个patch
动词。 -
在这个版本中,
securityContext.runAsUser
参数会从事件监听器部署中删除。
4.1.6.1.3. CLI
在这个版本中,
tkn [pipeline | pipelinerun] export
命令会导出一个管道或管道作为 YAML 文件运行。例如:在
openshift-pipelines
命名空间中导出名为test_pipeline
的管道:$ tkn pipeline export test_pipeline -n openshift-pipelines
在
openshift-pipelines
命名空间中导出名为test_pipeline_run
的管道运行:$ tkn pipelinerun export test_pipeline_run -n openshift-pipelines
-
在这个版本中,
--grace
选项添加到tkn pipelinerun cancel
中。使用--grace
选项终止管道运行,而不是强制终止。要启用此功能,在TektonConfig
自定义资源定义的pipeline
部分,您必须将enable-api-fields
字段设置为alpha
。 在这个版本中,在
tkn version
命令的输出中添加了 Operator 和链版本。重要Tekton 链是技术预览功能。
-
在这个版本中,当取消管道运行时,
tkn pipelinerun describe
命令显示所有取消的任务运行。在此修复之前,仅显示一个任务运行。 -
在这个版本中,您可以在运行
tkn [t | p | p | ct] start
命令时跳过使用--skip-optional-workspace
标记时,为可选工作区提供请求规格。您也可以在以交互模式运行时跳过它。 在这个版本中,您可以使用
tkn chain
命令管理 Tekton 链。您还可以使用--chains-namespace
选项指定要安装 Tekton 链的命名空间。重要Tekton 链是技术预览功能。
4.1.6.1.4. Operator
在这个版本中,您可以使用 Red Hat OpenShift Pipelines Operator 来安装和部署 Tekton Hub 和 Tekton 链。
重要集群中的 Tekton Hub 链和部署是技术预览功能。
在这个版本中,您可以查找并使用 Pipelines 作为代码(PAC)作为附加选项。
重要作为代码,管道是技术预览功能。
在这个版本中,您可以通过将
communityClusterTasks
参数设置为false
来禁用社区集群任务的安装。例如:... spec: profile: all targetNamespace: openshift-pipelines addon: params: - name: clusterTasks value: "true" - name: pipelineTemplates value: "true" - name: communityClusterTasks value: "false" ...
在这个版本中,您可以通过 Developer 视角禁用 Tekton Hub 集成,方法是将
TektonConfig
自定义资源中的enable-devconsole-integration
标志设置为false
。例如:... hub: params: - name: enable-devconsole-integration value: "true" ...
-
在这个版本中,
operator-config.yaml
配置映射启用tkn version
命令的输出来显示 Operator 版本。 -
在这个版本中,
argocd-task-sync-and-wait
任务的版本被修改为v0.2
。 -
对于这个版本的
TektonConfig
CRD ,oc get tektonconfig
命令会显示 OPerator 版本。 - 在这个版本中,服务监控器添加到 Triggers 指标中。
4.1.6.1.5. Hub
在集群中部署 Tekton Hub 是一个技术预览功能。
Tekton Hub 可帮助您发现、搜索和共享 CI/CD 工作流可重复使用的任务和管道。Tekton Hub 的一个公共实例位于 hub.tekton.dev 中。
集群管理员可以使用 Red Hat OpenShift Pipelines 1.7 推出,集群管理员也可以在企业集群中安装并部署 Tekton Hub 的自定义实例。您可以使用特定于您的机构的可重复使用的任务和管道来策展目录。
4.1.6.1.6. 链
Tekton 链是技术预览功能。
Tekton Chains 是一个 Kubernetes 自定义资源定义(CRD)控制器。您可以使用它来管理使用 Red Hat OpenShift Pipelines 创建的任务和管道的供应链安全。
默认情况下,Tekton Chains 会监控 OpenShift Container Platform 集群中运行的任务。链会对完成的任务运行进行快照,将其转换为一个或多个标准有效负载格式,并签署并存储所有工件。
Tekton Chains 支持以下功能:
-
您可以使用加密密钥类型和服务(如
cosign
)为任务运行、任务运行结果和 OCI registry 镜像签名。 -
您可以使用"测试"格式,如
in-toto
。 - 您可以使用 OCI 存储库作为存储后端安全存储签名和签名工件。
4.1.6.1.7. 管道作为代码(PAC)
作为代码,管道是技术预览功能。
使用 Pipelines 作为 Code,具有所需权限的集群管理员和用户可以将管道模板定义为源代码 Git 存储库的一部分。当由源代码推送或配置的 Git 存储库的拉取请求触发时,该功能将运行管道和报告状态。
作为代码的管道支持以下功能:
- 拉取请求状态。在迭代拉取请求时,拉取请求的状态和控制会在托管 Git 存储库的平台上进行。
- GitHub 检查 API 来设置管道运行的状态,包括重新检查。
- GitHub 拉取请求和提交事件。
-
在注释中拉取请求操作,如
/retest
。 - Git 事件过滤,以及每个事件的独立管道。
- Pipelines 中的自动任务解析用于本地任务、Tekton Hub 和远程 URL。
- 使用 GitHub blob 和对象 API 来检索配置。
-
通过 GitHub 机构或使用 Prow 风格的
OWNER
文件访问控制列表(ACL) -
tkn
CLI 工具的tkn pac
插件,您可以使用它们管理 Pipelines 作为代码软件仓库和 bootstrap。 - 支持 GitHub 应用程序、GitHub Webhook、Bitbucket 服务器和 Bitbucket 云。
4.1.6.2. 已弃用的功能
-
中断更改:此更新从
TektonConfig
自定义资源(CR)中删除disable-working-directory-overwrite
和disable-home-env-overwrite
字段。因此,TektonConfig
CR 不再自动设置$HOME
环境变量和workingDir
参数。您仍然可以使用Task
自定义资源定义(CRD)中的env
和workingDir
字段来设置$HOME
环境变量和workingDir
参数。
-
Conditions
自定义资源定义(CRD)类型已弃用,计划在以后的发行版本中删除。反之,使用推荐的when
表达式。
-
有问题的更改:
Triggers
资源验证模板,并在没有指定EventListener
和TriggerBinding
值时生成错误。
4.1.6.3. 已知问题
当您运行 Maven 和 Jib-Maven 集群任务时,默认容器镜像仅支持 Intel(x86)架构。因此,在 ARM、IBM Power Systems(ppc64le)、IBM Z 和 LinuxONE (s390x) 集群上的任务将失败。作为临时解决方案,您可以通过将
MAVEN_IMAGE
参数值设置为maven:3.6.3-adoptopenjdk-11
来指定自定义镜像。提示在您使用
tkn hub
在 ARM、IBM Power Systems(ppc64le)、IBM Z 和 LinuxONE(s390x) 上基于 Tekton Catalog 安装任务前,请验证是否可以在这些平台上执行任务。要检查ppc64le
和s390x
是否列在任务信息的"Platforms"部分,您可以运行以下命令:tkn hub info task <name>
-
在 IBM Power Systems、IBM Z 和 LinuxONE 中,不支持
s2i-dotnet
集群任务。 您无法使用
nodejs:14-ubi8-minimal
镜像流,因为这样做会生成以下错误:STEP 7: RUN /usr/libexec/s2i/assemble /bin/sh: /usr/libexec/s2i/assemble: No such file or directory subprocess exited with status 127 subprocess exited with status 127 error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127 time="2021-11-04T13:05:26Z" level=error msg="exit status 127"
-
隐式参数映射会错误地将参数从顶级
Pipeline
或PipelineRun
定义传递给taskRef
任务。映射应该只在顶层资源中使用任务进行,并带有非线taskSpec
规格。这个问题只通过将TektonConfig
自定义资源定义的pipeline
部分中的enable-api-fields
字段设置为alpha
来影响启用了这个功能的集群。
4.1.6.4. 修复的问题
-
在这个版本中,如果
Pipeline
和PipelineRun
对象定义中存在labels
和annotations
的元数据,PipelineRun
类型中的值会具有优先权。您可以观察Task
和TaskRun
对象的类似行为。 -
在这个版本中,如果
timeout.tasks
字段或timeout.finally
字段设置为0
,则timeout.pipeline
也被设置为0
。 -
在这个版本中,
-x
set 标记已从不使用 shebang 的脚本中删除。在这个版本中,减少了脚本执行的潜在数据泄漏。 -
在这个版本中,Git 凭证中的用户名中存在的任何反斜杠字符都会被转义,并带有
.gitconfig
文件中的额外反斜杠。
-
在这个版本中,
EventListener
对象的finalizer
属性不需要清理日志记录和配置映射。 - 在这个版本中,与事件监听器服务器关联的默认 HTTP 客户端会被删除,并添加自定义 HTTP 客户端。因此,超时有所改进。
- 在这个版本中,Triggers 集群角色现在可以处理所有者引用。
- 在这个版本中,当多个拦截器返回扩展时,事件监听器中的竞争条件不会发生。
-
在这个版本中,
tkn pr delete
命令不会删除使用ignore-running
标记运行的管道。
- 在这个版本中,当您修改任何附加组件参数时,Operator pod 不会继续重启。
-
在这个版本中,如果订阅和配置自定义资源中没有配置,
tkn serve
CLI pod 会被调度到 infra 节点上。 - 在这个版本中,在升级过程中不会删除指定版本的集群任务。
4.1.6.5. Red Hat OpenShift Pipelines 正式发行 1.7.1 发行注记
在这个版本中,Red Hat OpenShift Pipelines 正式发行(GA)1.7.1 包括在 OpenShift Container Platform 4.9, 4.10, 和 4.11 中。
4.1.6.5.1. 修复的问题
- 在此次更新之前,升级 Red Hat OpenShift Pipelines Operator 会删除与 Tekton Hub 关联的数据库中的数据并安装新的数据库。在这个版本中,Operator 升级会保留数据。
- 在此次更新之前,只有集群管理员才能访问 OpenShift Container Platform 控制台中的管道指标。在这个版本中,与其他集群角色的用户也可以访问管道指标。
-
在此次更新之前,管道对包含发出大型终止消息的任务的管道运行失败。管道运行失败,因为 pod 中所有容器的终止信息总数不能超过 12 KB。在这个版本中,使用同一镜像的
place-tools
和step-init
初始化容器会合并,以减少每个任务的 pod 中运行的容器数量。该解决方案可减少运行失败管道的几率,这可尽量减少在任务 pod 中运行的容器数量。但是,它不会删除终止消息的最大允许大小限制。 -
在此次更新之前,直接从 Tekton Hub web 控制台访问资源 URL 会导致 Nginx
404
错误。在这个版本中,Tekton Hub web 控制台镜像已被修复,以便直接从 Tekton Hub web 控制台访问资源 URL。 - 在此次更新之前,对于每个命名空间,资源修剪器作业都会创建一个单独的容器来修剪资源。在这个版本中,资源修剪器作业作为一个容器中的一个循环运行所有命名空间的命令。
4.1.6.6. Red Hat OpenShift Pipelines 正式发布 1.7.2 发行注记
在这个版本中,Red Hat OpenShift Pipelines General Availability (GA)1.7.2 包括在 OpenShift Container Platform 4.9、4.10 及以后的版本中。
4.1.6.6.1. 已知问题
-
在升级 Red Hat OpenShift Pipelines Operator 后,
openshift-pipelines
命名空间中的 Tekton Chains 的chains-config
配置映射会自动重置为默认。目前,这个问题还没有临时解决方案。
4.1.6.6.2. 修复的问题
-
在此次更新之前,当将
init
用作第一个参数并后跟两个或更多个参数时,Pipelines 1.7.1 上的任务会失败。在这个版本中,这些标志会被正确解析,任务可以运行成功。 在此次更新之前,因为存在无效的角色绑定,在 OpenShift Container Platform 4.9 和 4.10 上安装 Red Hat OpenShift Pipelines Operator 会失败,并显示以下错误消息:
error updating rolebinding openshift-operators-prometheus-k8s-read-binding: RoleBinding.rbac.authorization.k8s.io "openshift-operators-prometheus-k8s-read-binding" is invalid: roleRef: Invalid value: rbac.RoleRef{APIGroup:"rbac.authorization.k8s.io", Kind:"Role", Name:"openshift-operator-read"}: cannot change roleRef
在这个版本中,Red Hat OpenShift Pipelines Operator 安装有不同的角色绑定命名空间,以避免与其他 Operator 安装冲突。
在此次更新之前,升级 Operator 会触发 Tekton Chains 的
signed-secrets
secret 键重置为默认值。在这个版本中,在升级 Operator 后自定义 secret 密钥会保留。注意升级到 Red Hat OpenShift Pipelines 1.7.2 会重置密钥。但是,当您升级到将来的版本时,会需要保留该密钥。
在此次更新之前,所有 S2I 构建任务都会失败,并显示类似以下消息的错误:
Error: error writing "0 0 4294967295\n" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted time="2022-03-04T09:47:57Z" level=error msg="error writing \"0 0 4294967295\\n\" to /proc/22/uid_map: write /proc/22/uid_map: operation not permitted" time="2022-03-04T09:47:57Z" level=error msg="(unable to determine exit status)"
在这个版本中,
pipeline-scc
安全性上下文约束 (SCC) 与Buildah
和S2I
集群任务所需的SETFCAP
功能兼容。因此,Buildah
和S2I
构建任务可以成功运行。要成功运行
Buildah
集群任务和S2I
构建任务,适用于使用各种语言和框架编写的应用程序,添加以下适当的steps
对象(如build
和push
)的代码片段。securityContext: capabilities: add: ["SETFCAP"]
4.1.6.7. Red Hat OpenShift Pipelines 正式发布 1.7.3 发行注记
在这个版本中,Red Hat OpenShift Pipelines 正式发行(GA)1.7.3 包括在 OpenShift Container Platform 4.9, 4.10, 和 4.11 中。
4.1.6.7.1. 修复的问题
-
在此次更新之前,如果任何命名空间处于
Terminating
状态,Operator 会在创建 RBAC 资源时失败。在这个版本中,Operator 忽略了命名空间处于Terminating
状态,并创建 RBAC 资源。 -
在以前的版本中,升级 Red Hat OpenShift Pipelines Operator 会导致重新创建
pipeline
服务帐户,这意味着链接到服务帐户的 secret 会丢失。在这个版本中解决了这个问题。在升级过程中,Operator 不再重新创建pipeline
服务帐户。因此,已附加到pipeline
服务帐户的 secret 在升级后会保留,资源(任务和管道)可以继续正常工作。
4.1.7. Red Hat OpenShift Pipelines 正式发行 1.6 发行注记
在这个版本中,Red Hat OpenShift Pipelines 正式发行(GA)1.6 包括在 OpenShift Container Platform 4.9 中。
4.1.7.1. 新功能
除了包括修复和稳定性改进的信息外,以下小节突出介绍了 Red Hat OpenShift Pipelines 1.6 中的新内容。
-
在这个版本中,您可以配置管道或任务的
start
命令(使用--output <string>
,其中<string>
是yaml
或json
)来返回 YAML 或 JSON 格式的字符串。如果没有使用--output
选项,start
命令会返回人类友好的消息,而其他程序很难解析该消息。返回 YAML 或 JSON 格式的字符串对于持续集成(CI)环境非常有用。例如,在创建了资源后,您可以使用yq
或jq
解析有关资源的 YAML 或 JSON 格式消息,并等待该资源终止而不使用showlog
选项。 -
在这个版本中,您可以使用 Podman 的
auth.json
身份验证文件对 registry 进行身份验证。例如,您可以使用tkn bundle push
来使用 Podman 而不是 Docker CLI 推送到远程 registry。 -
在这个版本中,如果您使用
tkn [taskrun | pipelinerun] delete --all
命令,您可以使用新的--keep-since <minutes>
选项来指定一个分钟数,存在时间少于这个分钟数的运行会被保留。例如,若要保持存在的时间少于五分钟的运行,输入tkn [taskrun | pipelinerun] delete -all --keep-since 5
。 -
在这个版本中,当删除任务运行或管道运行时,您可以将
--parent-resource
和--keep-since
选项一起使用。例如,tkn pipelinerun delete --pipeline pipelinename --keep-since 5
命令会保留其父资源名为pipelinename
,其存在时间为五分钟或更短的管道运行。对于任务运行,tkn tr delete -t <taskname> --keep-since 5
和tkn tr delete --clustertask <taskname> --keep-since 5
有类似效果。 -
在这个版本中,增加了对用于
v1beta1
资源的触发器资源的支持。
-
在这个版本中,在
tkn pipelinerun delete
和tkn taskrun delete
命令中添加了一个ignore-running
选项。 -
在这个版本中,为
tkn task
和tkn clustertask
命令添加一个create
子命令。 -
在这个版本中,当使用
tkn pipelinerun delete --all
命令时,您可以使用新的--label <string>
选项来根据标签过滤管道运行。另外,您还可以在--label
选项中使用=
和==
作为相等运算符,或者!=
作为不相等运算符。例如,tkn pipelinerun delete --all --label asdf
和tkn pipelinerun delete --all --label==asdf
命令都会删除带有asdf
标签的所有管道运行。 - 在这个版本中,您可以从配置映射获取已安装的 Tekton 组件版本,或者从部署控制器获取配置映射的版本。
-
在这个版本中,触发器支持使用
feature-flags
和config-defaults
配置映射来分别配置功能标记和设置默认值。 -
在这个版本中,添加了一个新的指标
eventlistener_event_count
,您可以使用它来统计EventListener
资源接收的事件。 在这个版本中添加了
v1beta1
Go API 类型。在这个版本中,触发器支持v1beta1
API 版本。在当前发行版本中,
v1alpha1
功能已弃用,并将在以后的发行版本中删除。改为使用v1beta1
功能替代。
在当前发行版本中,默认启用自动运行资源。另外,您可以使用以下新注解为每个命名空间单独配置自动运行任务运行和管道运行:
-
operator.tekton.dev/prune.schedule
:如果此注解的值与TektonConfig
自定义资源定义中指定的值不同,则会在该命名空间中创建新的 cron 作业。 -
operator.tekton.dev/prune.skip
:设置为true
时,配置它的命名空间不会被修剪。 -
operator.tekton.dev/prune.resources
:此注解接受以逗号分隔的资源列表。要修剪单一资源,如管道运行,将此注解设置为"pipelinerun"
。要修剪多个资源,如任务运行和管道运行,将此注解设置为"taskrun, pipelinerun"
。 -
operator.tekton.dev/prune.keep
:使用此注解保留资源而不进行修剪。 operator.tekton.dev/prune.keep-since
:使用此注解来根据其存在的时间来保留资源。此注解的值必须等于资源的年龄(以分钟为单位)。例如,若要保留在五天内创建的资源,请将keep-since
设置为7200
。注意keep
和keep-since
注释是互斥的。对于任何资源,您只能配置其中一个。-
operator.tekton.dev/prune.strategy
:将此注解的值设置为keep
或keep-since
。
-
-
管理员可以禁用在整个集群中创建
pipeline
服务帐户创建,从而防止因为错误地使用关联的 SCC(这与anyuid
非常相似)造成权限升级的问题。 -
现在,您可以使用
TektonConfig
自定义资源(CR)和单个组件的 CR 配置功能标记和组件,如TektonPipeline
和TektonTriggers
。此级别的颗粒度有助于为各个组件的 Tekton OCI 捆绑包自定义和测试 alpha 功能。 -
现在,您可以为
PipelineRun
资源配置可选的Timeouts
字段。例如,您可以单独为管道运行、每个任务运行以及finally
任务配置超时。 -
TaskRun
资源生成的 Pod 现在会设置 pod 的activeDeadlineSeconds
字段。这可让 OpenShift 将它们视为终止,并允许您将具有特定作用域的ResourceQuota
对象用于容器集。 - 您可以使用 configmaps 在任务运行、管道运行、任务和管道上消除指标标签或标签类型。另外,您可以为测量持续时间配置不同类型的指标,如直方图、量表或最后一个值。
-
您可以统一定义 pod 的请求和限值,因为 Tekton 现在通过考虑
Min
、Max
、Default
和DefaultRequest
字段来全面支持LimitRange
对象。 引入了以下 alpha 功能:
现在,管道运行可以在运行
finally
任务后停止,而不是之前停止直接运行所有任务的行为。在这个版本中添加了以下spec.status
值:-
StoppedRunFinally
将在当前运行的任务完成后停止,然后运行finally
任务。 -
CancelledRunFinally
将立即取消正在运行的任务,然后运行finally
任务。 Cancelled
将保留PipelineRunCancelled
状态提供的以前行为。注意Cancelled
状态替换已弃用的PipelineRunCancelled
状态,该状态将在v1
版本中删除。
-
-
现在,您可以使用
oc debug
命令将任务运行设置为 debug 模式,这会暂停执行并允许您检查 pod 中的特定步骤。 -
当您将一个步骤的
onError
字段设置为continue
时,会记录该步骤的退出代码并传递给后续步骤。但是,任务运行不会失败,任务中其余步骤的执行将继续。要保留现有的行为,您可以将onError
字段的值设置为stopAndFail
。 - 任务现在可以接受比实际使用更多的参数。启用 alpha 功能标记时,参数可以隐式传播到内联规格。例如,内联任务可以访问其父管道运行的参数,而不必为任务明确定义每个参数。
-
如果您为 alpha 功能启用标记,则
When
表达式下的条件将仅适用于直接关联的任务,而不是任务的依赖项。要将When
表达式应用到关联的任务及其依赖关系中,您必须将表达式与每个相依任务单独关联。请注意,进入下一步是 Tekton 的任何新 API 版本中When
表达式的默认行为。现有的默认行为将被弃用,而由此更新替代。
当前发行版本允许您通过在
TektonConfig
自定义资源(CR)中指定nodeSelector
和tolerations
值来配置节点选择。Operator 将这些值添加到它创建的所有部署中。-
要为 Operator 的控制器和 webhook 部署配置节点选择,请在安装 Operator 后编辑
Subscription
CR 规格中的config.nodeSelector
和config.tolerations
字段。 -
要在基础架构节点上部署 OpenShift Pipelines 的其余 control plane pod,请使用
nodeSelector
和tolerations
字段更新TektonConfig
CR。然后,修改会应用到 Operator 创建的所有 pod。
-
要为 Operator 的控制器和 webhook 部署配置节点选择,请在安装 Operator 后编辑
4.1.7.2. 已弃用的功能
-
在 CLI 0.21.0 中,已弃用了对
clustertask
,task
,taskrun
,pipeline
, 和pipelinerun
的所有v1alpha1
资源的支持。这些资源现已过时,并将在以后的发行版本中删除。
在 Tekton Triggers v0.16.0 中,冗余的
status
标签已从EventListener
资源的指标中删除。重要中断更改:
status
标签已从eventlistener_http_duration_seconds_*
指标中删除。删除基于status
标签的查询。-
在当前发行版本中,
v1alpha1
功能已弃用,并将在以后的发行版本中删除。在这个版本中,您可以改为使用v1beta1
Go API 类型。触发器现在支持v1beta1
API 版本。 在当前发行版本中,
EventListener
资源会在触发器完成处理前发送响应。重要中断更改:使用此更改时,
EventListener
资源会在创建资源时停止响应201 Created
的状态代码。相反,它使用202 Accepted
的响应代码进行响应。当前发行版本从
EventListener
资源中删除podTemplate
字段。重要中断更改:删除了作为 #1100 一部分的
podTemplate
字段。当前发行版本从
EventListener
资源规格中删除已弃用的replicas
字段。重要中断更改:已弃用的
replicas
字段已被删除。
在 Red Hat OpenShift Pipelines 1.6 中,
HOME="/tekton/home"
和workingDir="/workspace"
的值从Step
对象的规格中删除。相反,Red Hat OpenShift Pipelines 将
HOME
和workingDir
设置为运行Step
对象的容器定义的值。您可以在Step
对象的规格中覆盖这些值。要使用旧的行为,您可以将
TektonConfig
CR 中的disable-working-directory-overwrite
和disable-home-env-overwrite
字段改为false
:apiVersion: operator.tekton.dev/v1alpha1 kind: TektonConfig metadata: name: config spec: pipeline: disable-working-directory-overwrite: false disable-home-env-overwrite: false ...
重要TektonConfig
CR 中的disable-working-directory-overwrite
和disable-home-env-overwrite
字段现已弃用,并将在以后的发行版本中删除。
4.1.7.3. 已知问题
-
当您运行 Maven 和 Jib-Maven 集群任务时,默认容器镜像仅支持 Intel(x86)架构。因此,在 IBM Power Systems(ppc64le)、IBM Z 和 LinuxONE(s390x)集群上的任务将失败。作为临时解决方案,您可以通过将
MAVEN_IMAGE
参数值设置为maven:3.6.3-adoptopenjdk-11
来指定自定义镜像。 -
在 IBM Power Systems、IBM Z 和 LinuxONE 中,不支持
s2i-dotnet
集群任务。 -
在您使用
tkn hub
在 IBM Power Systems(ppc64le)、IBM Z 和 LinuxONE(s390x) 上基于 Tekton Catalog 安装任务前,请验证是否可以在这些平台上执行任务。要检查ppc64le
和s390x
是否列在任务信息的"Platforms"部分,您可以运行以下命令:tkn hub info task <name>
您无法使用
nodejs:14-ubi8-minimal
镜像流,因为这样做会生成以下错误:STEP 7: RUN /usr/libexec/s2i/assemble /bin/sh: /usr/libexec/s2i/assemble: No such file or directory subprocess exited with status 127 subprocess exited with status 127 error building at STEP "RUN /usr/libexec/s2i/assemble": exit status 127 time="2021-11-04T13:05:26Z" level=error msg="exit status 127"
4.1.7.4. 修复的问题
-
现在,IBM Power Systems、IBM Z 和 LinuxONE 支持
tkn hub
命令。
-
在更新前,当用户运行
tkn
命令并完成管道运行后,终端不可用,即使指定了retries
也是如此。在任务运行或管道运行中指定超时无效。在这个版本中解决了这个问题,终端可以在运行命令后可用。 -
在更新前,运行
tkn pipelinerun delete --all
会删除所有资源。在这个版本中,处于 running 状态的资源无法被删除。 -
在这个版本中,使用
tkn version --component=<component>
命令不会返回组件版本。在这个版本中解决了这个问题,这个命令会返回组件版本。 -
在更新前,当您使用
tkn pr logs
命令时,它会以错误的任务顺序显示管道输出日志。在这个版本中解决了这个问题,已完成的PipelineRuns
的日志会在适当的TaskRun
执行顺序中列出。
-
在这个版本中,编辑正在运行的管道规格可能会阻止管道运行在完成后停止。在这个版本中,只获取定义一次,然后使用存储在状态中的规格进行验证,从而解决了这个问题。当
PipelineRun
或TaskRun
指代的Pipeline
或Task
在运行时会发生变化,这个变化减少了出现竞争条件的可能性。 -
When
表达式值可以有数组参数引用,例如values: [$(params.arrayParam[*])]
。
4.1.7.5. Red Hat OpenShift Pipelines 正式发行版本 1.6.1 发行注记
4.1.7.5.1. 已知问题
从旧版本升级到 Red Hat OpenShift Pipelines 1.6.1 后,Pipelines 可能会进入不一致的状态,因为您无法对 Tekton 资源(tasks 和 pipelines)执行任何操作(create/delete/apply)。例如,在删除资源时,您可能会遇到以下错误:
Error from server (InternalError): Internal error occurred: failed calling webhook "validation.webhook.pipeline.tekton.dev": Post "https://tekton-pipelines-webhook.openshift-pipelines.svc:443/resource-validation?timeout=10s": service "tekton-pipelines-webhook" not found.
4.1.7.5.2. 修复的问题
Red Hat OpenShift Pipelines 设置的
SSL_CERT_DIR
环境变量(/tekton-custom-certs
)不会用证书文件覆盖以下默认系统目录:-
/etc/pki/tls/certs
-
/etc/ssl/certs
-
/system/etc/security/cacerts
-
- Horizontal Pod Autoscaler 可以管理 Red Hat OpenShift Pipelines Operator 控制的部署副本数。在这个发行版本中,如果最终用户或集群代理更改了计数,Red Hat OpenShift Pipelines Operator 不会重置管理的部署的副本计数。但是,升级 Red Hat OpenShift Pipelines Operator 时会重置副本。
-
现在,根据
TektonConfig
自定义资源中指定的节点选择器和容限(toleration)限制将把tkn
CLI 的 pod 调度到节点上。
4.1.7.6. Red Hat OpenShift Pipelines 正式发行版本 1.6.2 发行注记
4.1.7.6.1. 已知问题
-
当您创建新项目时,
pipeline
服务帐户的创建会被延迟,并删除现有集群任务和管道模板需要超过 10 分钟。
4.1.7.6.2. 修复的问题
-
在此次更新之前,在从旧版本升级到 Red Hat OpenShift Pipelines 1.6.1 后,会为管道创建多个 Tekton 安装程序集实例。在这个版本中,Operator 可确保升级后每个类型为
TektonInstallerSet
的一个实例都存在。 - 在此次更新之前,Operator 中的所有协调程序都使用组件版本在升级到旧版本的 Red Hat OpenShift Pipelines 1.6.1 期间决定资源重新创建。因此,这些资源不会被重新创建,其组件版本没有在升级过程中改变。在这个版本中,Operator 使用 Operator 版本而不是组件版本来决定升级过程中的资源重新创建。
- 在此次更新之前,升级后,集群中缺少管道 Webhook 服务。这是因为配置映射上的升级死锁。在这个版本中,如果集群中不存在配置映射,添加了一个机制来禁用 Webhook 验证。因此,在升级后管道 Webhook 服务会保留在集群中。
- 在此次更新之前,在任何配置更改到命名空间后,自动运行操作的 cron 作业会被重新创建。在这个版本中,只有在命名空间中有相关注解改变时,才会重新创建 auto-pruning 的 cron 任务。
Tekton Pipelines 的上游版本被修订为
v0.28.3
,它包括以下修复:-
修复
PipelineRun
或TaskRun
对象,以允许进行标签或注解。 对于隐式参数:
-
不要将
PipelineSpec
参数应用到TaskRefs
对象。 -
禁用
Pipeline
对象的隐式参数行为。
-
不要将
-
修复
4.1.7.7. Red Hat OpenShift Pipelines 正式发布 1.6.3 发行注记
4.1.7.7.1. 修复的问题
在此次更新之前,Red Hat OpenShift Pipelines Operator 从组件(如 Pipelines 和 Triggers)中安装 Pod 安全策略。但是,作为组件的一部分提供的 Pod 安全策略在以前的版本中已被弃用。在这个版本中,Operator 会停止从组件安装 Pod 安全策略。因此,以下升级路径会受到影响:
- 从 Pipelines 1.6.1 或 1.6.2 升级到 Pipelines 1.6.3 会删除 Pod 安全策略,包括 Pipelines 和 Triggers 组件中的 Pod 安全策略。
从 Pipelines 1.5.x 升级到 1.6.3 会保留从组件安装的 Pod 安全策略。作为集群管理员,您可以手动删除它们。
注意当您升级到将来的版本时,Red Hat OpenShift Pipelines Operator 会自动删除所有过时的 Pod 安全策略。
- 在此次更新之前,只有集群管理员才能访问 OpenShift Container Platform 控制台中的管道指标。在这个版本中,与其他集群角色的用户也可以访问管道指标。
- 在此次更新之前,带有 Pipelines Operator 的基于角色的访问控制(RBAC)问题会导致升级或安装组件的问题。这个版本提高了安装各种 Red Hat OpenShift Pipelines 组件的可靠性和一致性。
-
在此次更新之前,在
TektonConfig
CR 中将clusterTasks
和pipelineTemplates
字段设置为false
时,会降低删除集群任务和管道模板。这个版本提高了 Tekton 资源(如集群任务和管道模板)的生命周期管理速度。
4.1.7.8. Red Hat OpenShift Pipelines 正式发布 1.6.4 发行注记
4.1.7.8.1. 已知问题
从 Red Hat OpenShift Pipelines 1.5.2 升级到 1.6.4 后,访问事件监听程序路由会返回
503
错误。临时解决方案:修改事件监听器路由的 YAML 文件中的目标端口。
为相关命名空间提取路由名称。
$ oc get route -n <namespace>
编辑路由以修改
targetPort
字段的值。$ oc edit route -n <namespace> <el-route_name>
示例:现有事件监听程序路由
... spec: host: el-event-listener-q8c3w5-test-upgrade1.apps.ve49aws.aws.ospqa.com port: targetPort: 8000 to: kind: Service name: el-event-listener-q8c3w5 weight: 100 wildcardPolicy: None ...
示例:修改事件监听程序路由
... spec: host: el-event-listener-q8c3w5-test-upgrade1.apps.ve49aws.aws.ospqa.com port: targetPort: http-listener to: kind: Service name: el-event-listener-q8c3w5 weight: 100 wildcardPolicy: None ...
4.1.7.8.2. 修复的问题
-
在此次更新之前,如果任何命名空间处于
Terminating
状态,Operator 会在创建 RBAC 资源时失败。在这个版本中,Operator 忽略了命名空间处于Terminating
状态,并创建 RBAC 资源。 - 在此次更新之前,该任务会在没有注解指定关联的 Tekton 控制器发行版本而运行失败或重启。在这个版本中,包含适当的注解会被自动运行,没有失败或重启的任务。
4.1.8. Red Hat OpenShift Pipelines 正式发行 1.5 发行注记
Red Hat OpenShift Pipelines General Availability (GA) 1.5 现在包括在 OpenShift Container Platform 4.8 中。
4.1.8.1. 兼容性和支持列表
这个版本中的一些功能当前还只是一个技术预览。它们并不适用于在生产环境中使用。
在下表中,被标记为以下状态的功能:
TP | 技术预览 |
GA | 公开发行 |
请参阅红帽门户网站中关于对技术预览功能支持范围的信息:
功能 | 版本 | 支持状态 |
---|---|---|
Pipelines | 0.24 | GA |
CLI | 0.19 | GA |
目录 | 0.24 | GA |
触发器 | 0.14 | TP |
Pipeline 资源 | - | TP |
如果您有疑问或希望提供反馈信息,请向产品团队发送邮件 pipelines-interest@redhat.com。
4.1.8.2. 新功能
除了包括修复和稳定性改进的信息外,以下小节突出介绍了 Red Hat OpenShift Pipelines 1.5 中的新内容。
Pipeline 运行和任务运行将由目标命名空间中的 cron 作业自动修剪。cron 作业使用
IMAGE_JOB_PRUNER_TKN
环境变量来获取tkn image
的值。在这个版本中,TektonConfig
自定义资源包括以下字段:... pruner: resources: - pipelinerun - taskrun schedule: "*/5 * * * *" # cron schedule keep: 2 # delete all keeping n ...
在 OpenShift Container Platform 中,您可以通过修改
TektonConfig
自定义资源中的新参数clusterTasks
和pipelinesTemplates
的值来自定义 Tekton Add-ons 组件的安装:apiVersion: operator.tekton.dev/v1alpha1 kind: TektonConfig metadata: name: config spec: profile: all targetNamespace: openshift-pipelines addon: params: - name: clusterTasks value: "true" - name: pipelineTemplates value: "true" ...
如果您使用
TektonConfig
创建附加组件,或者直接使用 Tekton Add-ons 创建附加组件,则允许进行自定义。但是,如果没有传递参数,控制器会添加带有默认值的参数。注意-
如果使用
TektonConfig
自定义资源创建附加组件,并且稍后在Addon
自定义资源中更改参数值,则TektonConfig
自定义资源中的值将覆盖更改。 -
只有在
clusterTasks
参数的值为true
时,才可将pipelinesTemplates
参数的值设置为true
。
-
如果使用
enableMetrics
参数添加到TektonConfig
自定义资源中。您可以使用它来禁用服务监控器,这是 OpenShift Container Platform 的 Tekton Pipelines 的一部分。apiVersion: operator.tekton.dev/v1alpha1 kind: TektonConfig metadata: name: config spec: profile: all targetNamespace: openshift-pipelines pipeline: params: - name: enableMetrics value: "true" ...
- 添加了 EventListener OpenCensus 指标(在进程级别捕获指标)。
- 触发器现在具有标签选择器;您可以使用标签为事件监听程序配置触发器。
添加了用于注册拦截器的
ClusterInterceptor
自定义资源定义,允许您注册您可以插入的新Interceptor
类型。另外,还会进行以下相关更改:-
在触发器规格中,您可以使用包含
ref
字段的新 API 来配置拦截器来引用集群拦截器。另外,您可以使用params
字段添加传递到拦截器进行处理的参数。 -
捆绑的拦截器 CEL、GitHub、GitLab 和 BitBucket 已迁移。它们使用新的
ClusterInterceptor
自定义资源定义来实施。 -
核心拦截器迁移到新格式,使用旧语法创建的任何新触发器都会自动切换到新的
ref
或params
语法。
-
在触发器规格中,您可以使用包含
-
要在显示日志时禁用任务名称的前缀或步骤,可将
--prefix
选项用于log
命令。 -
要显示特定组件的版本,请使用
tkn version
命令中的新的--component
标志。 -
添加了
tkn hub check-upgrade
命令,其他命令会根据管道版本进行修改。此外,search
命令输出中也会显示目录名称。 -
在
start
命令中添加了对可选工作区的支持。 -
如果
plugins
目录中不存在插件,则会在当前路径中搜索它们。 tkn start [task | clustertask | pipeline]
命令以互动方式启动,并询问params
值,即使指定了默认参数也是如此。若要停止交互式提示,可在调用 命令时传递--use-param-defaults
标志。例如:$ tkn pipeline start build-and-deploy \ -w name=shared-workspace,volumeClaimTemplateFile=https://raw.githubusercontent.com/openshift/pipelines-tutorial/pipelines-1.10/01_pipeline/03_persistent_volume_claim.yaml \ -p deployment-name=pipelines-vote-api \ -p git-url=https://github.com/openshift/pipelines-vote-api.git \ -p IMAGE=image-registry.openshift-image-registry.svc:5000/pipelines-tutorial/pipelines-vote-api \ --use-param-defaults
-
version
字段在tkn task describe
命令中添加。 -
如果只有一个资源,则会自动选择
TriggerTemplate
或TriggerBinding
或ClusterTriggerBinding
或Eventlistener
等资源的选项会添加到describe
命令中。 -
在
tkn pr describe
命令中添加了跳过的任务部分。 -
添加了对
tkn clustertask logs
的支持。 -
移除
config.yaml
中的 YAML 合并和变量。另外,现在kustomize
和ytt
等工具可以更轻松地使用release.yaml
文件。 - 添加了对包含句点字符(".")的资源名称的支持。
-
PodTemplate
规格中的hostAliases
数组添加到主机名解析的 pod 级别覆盖中。它通过修改/etc/hosts
文件来实现。 -
引入了一个变量
$(tasks.status)
,用于访问任务的聚合执行状态。 - 为 Windows 添加入口点二进制构建。
4.1.8.3. 已弃用的功能
在
when
表达式中,对写入的字段的支持会被删除。when
表达式仅支持使用小写字母编写的字段。注意如果您在 Tekton Pipelines
v0.16
(Operatorv1.2.x
) 中应用了一个带有when
表达式的管道,则必须重新应用它。当您将 Red Hat OpenShift Pipelines Operator 升级到
v1.5
时,openshift-client
和openshift-client-v-1-5-0
集群任务会具有SCRIPT
参数。但是,ARGS
参数和git
资源会从openshift-client
集群任务的规格中删除。这个变化可能会造成问题,只有在ClusterTask
资源的name
字段中没有特定版本的集群任务才可以无缝地进行升级。要防止管道运行出现问题,在升级后使用
SCRIPT
参数,因为它会将之前在ARGS
参数中指定的值移到集群任务的SCRIPT
参数中。例如:... - name: deploy params: - name: SCRIPT value: oc rollout status <deployment-name> runAfter: - build taskRef: kind: ClusterTask name: openshift-client ...
当您从 Red Hat OpenShift Pipelines Operator
v1.4
升级到v1.5
时,TektonConfig
自定义资源的配置集名称现在会改变。表 4.3. TektonConfig 自定义资源的配置集 Pipelines 1.5 中的配置集 Pipelines 1.4 中的对应的配置集 安装的 Tekton 组件 All (默认配置集)
All (默认配置集)
Pipelines、Triggers、Add-ons
Basic
默认
Pipelines、Triggers
Lite
Basic
Pipelines
注意如果在
TektonConfig
自定义资源的config
实例中使用profile: all
,则不需要更改资源规格。但是,如果安装的 Operator 在升级前是 Default 或 Basic 配置集,则必须在升级后编辑
TektonConfig
自定义资源的config
实例。例如,如果配置在升级前是profile: basic
,请确保在升级到 Pipelines 1.5 后为profile: lite
。disable-home-env-overwrite
和disable-working-dir-overwrite
字段现已弃用,并将在以后的发行版本中删除。在本发行版本中,这些标志的默认值被设置为true
,以便向后兼容。注意在下一个发行版本 (Red Hat OpenShift Pipelines 1.6) 中,
HOM