2.9. 部署容器
您可以使用各种技术来确保所部署的容器包含最新的生产级内容,并确保这些容器没有被修改。这些技术包括设置构建触发器以纳入最新的代码,以及使用签名来确保容器来自可信源且未修改。
2.9.1. 使用触发器控制容器部署
如果在构建过程中发生某种情况,或者部署了镜像后发现一个漏洞,您可以使用基于策略的自动化部署工具进行修复。您可以使用触发器来重建和替换镜像,确保不可变的容器进程,而不是修补正在运行的容器,这种做法是不推荐的。
例如,您使用三个容器镜像层构建了一个应用程序:核心、中间件和应用程序。由于在核心镜像中发现了一个问题,该镜像被重建。构建完成后,该镜像被推送到 OpenShift Container Registry。OpenShift Container Platform 检测到镜像已更改,并根据定义的触发器自动重建并部署应用程序镜像。这一更改包含了固定的库,并确保产品代码与最新镜像是一致的。
您可以使用 oc set triggers
命令来设置部署触发器。例如,要为名为 deployment-example 的部署设置触发器:
$ oc set triggers deploy/deployment-example \ --from-image=example:latest \ --containers=web
2.9.2. 控制可以部署的镜像源
务必要确保实际部署了所需的镜像,还要确保包括容器内容的镜像来自可信源,且尚未更改。加密签名提供了这一保证。OpenShift Container Platform 可让集群管理员应用广泛或狭窄的安全策略,以反应部署环境和安全要求。该策略由两个参数定义:
- 一个或多个带有可选项目命名空间的 registry
- 信任类型,如接受、拒绝或要求公钥
您可以使用这些策略参数来允许、拒绝整个 registry、部分 registry 或单独的镜像,或者要求具有信任关系。使用可信公钥,您可以确保以加密的方式验证源。该策略规则应用于节点。策略可以在所有节点中统一应用,或针对不同的节点工作负载(例如:构建、区域或环境)加以应用。
镜像签名策略文件示例
{ "default": [{"type": "reject"}], "transports": { "docker": { "access.redhat.com": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release" } ] }, "atomic": { "172.30.1.1:5000/openshift": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPath": "/etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release" } ], "172.30.1.1:5000/production": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPath": "/etc/pki/example.com/pubkey" } ], "172.30.1.1:5000": [{"type": "reject"}] } } }
该策略可以在节点上保存为 /etc/containers/policy.json
。最好使用新的 MachineConfig
对象将此文件保存到节点。这个示例强制执行以下规则:
-
要求 Red Hat Registry (
registry.access.redhat.com
) 中的镜像由红帽公钥签名。 -
要求
openshift
命名空间中的 OpenShift Container Registry 中的镜像由 Red Hat 公钥签名。 -
要求
production
命名空间中的 OpenShift Container Registry 中的镜像由example.com
的公钥签名。 -
拒绝未由全局
默认
定义指定的所有其他 registry。
2.9.3. 使用签名传输
签名传输是一种存储和检索二进制签名 blob 的方法。签名传输有两种类型。
-
Atomic
:由 OpenShift Container Platform API 管理。 -
Docker
:作为本地文件或通过 Web 服务器提供。
OpenShift Container Platform API 负责管理使用 atomic
传输类型的签名。您必须将使用此签名类型的镜像存储在 OpenShift Container Registry 中。由于 docker/distribution extensions
API 会自动发现镜像签名端点,因此不需要额外的配置。
使用 docker
传输类型的签名由本地文件或者 Web 服务器提供。这些签名更为灵活,您可以提供来自任何容器镜像 registry 的镜像,并使用独立的服务器来提供二进制签名。
但是,docker
传输类型需要进行额外的配置。您必须为节点配置签名服务器的 URI,方法是将随机命名的 YAML 文件放在主机系统上的目录中,默认为 /etc/containers/registries.d
。YAML 配置文件包含 registry URI 和签名服务器 URI,或 sigstore:
Registries.d 文件示例
docker: access.redhat.com: sigstore: https://access.redhat.com/webassets/docker/content/sigstore
在这个示例中,Red Hat Registry access.redhat.com
是为 docker
传输类型提供签名的签名服务器。其 URI 在 sigstore
参数中定义。您可以将此文件命名为 /etc/containers/registries.d/redhat.com.yaml
,并使用 Machine Config Operator 自动将文件放在集群中的每个节点上。由于策略和 registry.d
文件由容器运行时动态加载,因此不需要重启服务。
2.9.4. 创建 secret 和配置映射
Secret
对象类型提供了一种机制来保存敏感信息,如密码、OpenShift Container Platform 客户端配置文件、dockercfg
文件和私有源存储库凭证。Secret 将敏感内容与 Pod 分离。您可以使用卷插件将 secret 信息挂载到容器中,系统也可以使用 secret 代表 Pod 执行操作。
例如,要在部署配置中添加 secret,以便它可以访问私有镜像存储库,请执行以下操作:
流程
- 登陆到 OpenShift Container Platform Web 控制台。
- 创建新项目。
-
导航到 Resources
Secrets 并创建新 secret。将 Secret Type
设为Image Secret
,并将Authentication Type
设为Image Registry Credentials
,以输入用于访问私有镜像存储库的凭证。 -
在创建部署配置时(例如,从 Add to Project
Deploy Image 页面),将 Pull Secret
设置为您的新 secret。
配置映射与 secret 类似,但设计为能支持与不含敏感信息的字符串配合使用。ConfigMap
对象包含配置数据的键值对,这些数据可在 Pod 中消耗或用于存储控制器等系统组件的配置数据。
2.9.5. 自动化持续部署
您可以将自己的持续部署 (CD) 工具与 OpenShift Container Platform 集成。
利用 CI/CD 和 OpenShift Container Platform,您可以自动执行重建应用程序的过程,以纳入最新的修复、测试,并确保它在环境中随处部署。
其他资源