应用的自动构建：Openshift开发系列第二篇

发布企业容器镜像

比较企业注册表和公共注册表

许多开发人员从公共容器镜像注册表建立容器，例如 docker.io 的 Docker Hub 和 registry.access.redhat.com 的红帽注册表。 这些公共注册表很方便，但许多企业不容许开发人员从他们从互联网下载的镜像提取和运行容器。这些企业限制开发人员只能使用一组符合安全性、质量和一致性标准的容器镜像。

限制从互联网访问容器镜像的一种方法是在企业内部署企业注册表，也称为私有注册表。而后，将企业内的容器主机配置为仅从企业注册表中提取镜像。

企业注册表也可用于许多其余方案，例如：

• 企业批准不一样的容器镜像以供不一样环境使用：例如开发、QA 和生产。每一个环境都有不一样的私有注册表。

• 供应商提供预构建的容器镜像，但企业不但愿为运行容器的每一个主机从互联网手动提取这些镜像。

• 企业提供内部为外部用户和客户建立的容器镜像。

• 无需访问互联网便可安装和运行 OpenShift 如下载 OpenShift 容器镜像，例如路由器和 S2I 构建器镜像。

部署企业注册表

Docker 社区提供了两个开源容器镜像注册表服务器，由红帽做为 RHEL 7 附加通道的一部分进行打包并提供支持：

1. docker-registry 软件包实施了较旧的 v1 注册表 API，而且已知存在磁盘和网络 I/O 方面的性能问题。

2. docker-distribution 软件包实施了较新的 v2 注册表 API。除了性能和可扩展性改进以外，此镜像注册表服务器设计成能够嵌入到其余软件包中。

红帽建议使用较新的 docker-distribution 软件包代替较旧的 docker-registry 软件包。不幸的是，docker-distribution 软件包没有实施搜索功能。每一个提供搜索功能的供应商（包括 Docker Hub）都以专有方式完成。

多个供应商（如 JFrog、Sonatype、Docker Inc 和红帽）提供商业支持的容器镜像注册表服务器。 其中许多都基于 docker-distribution 软件包源代码。

红帽提供了两种用于部署注册表服务器的产品：

• 红帽卫星：此注册表服务器是外部注册表的代理。它不提供推送功能。 若是您的企业已使用红帽卫星系统管理功能在内部分发 RPM 软件包，您能够考虑使用红帽卫星在内部分发容器镜像。

• 红帽 OpenShift 容器注册表：这是专门用于运行安全的企业注册表的红帽 OpenShift 容器平台集群安装。与 docker-distribution 软件包相比，红帽 OpenShift 容器注册表在高可用性、安全性和管理方面提供了加强功能。

将企业注册表与 OpenShift 一块儿使用

OpenShift 能够直接从存储在企业注册表中的镜像部署应用。OpenShift 将这些企业注册表命名为外部注册表，以区别于 OpenShift 内部注册表。

有两种方法可使用带 OpenShift 的外部注册表中的容器镜像：

1. 将存储在外部注册表中的容器镜像的完整 URL 提供给 oc new-app 等命令。

2. 建立指向外部注册表中的镜像的镜像流资源。

推荐的方法是使用镜像流资源。除了其余优点以外，镜像流还容许集群管理员使用 oc import-image 命令更新镜像流中的元数据，并触发 OpenShift 集群内的构建和部署。

安装并配置 docker-distribution 注册表

RHEL 7 的 docker-distribution 软件包配置了 docker-distribution 服务并安装了随时可运行的配置，但须要注意几点：

• 注册表不须要身份验证来推送或提取容器镜像。

• 注册表拒绝删除容器镜像的请求。

本书未介绍如何为模拟生产环境配置 docker-distribution 软件包。有关配置身份验证、存储、缓存和其余设置的信息，请查看本节末尾的参考资料。

没法删除容器镜像可能会产生磁盘空间问题。要容许从注册表存储中删除镜像，请将 delete.enabled 属性添加到位于 /etc/docker-distribution/registry/config.yml 的 docker-distribution 配置文件的 storage 部分：

skopeo 命令

docker 命令提供动词以将容器镜像从注册表提取并推送到本地容器存储，但不是用于管理存储在注册表中的容器镜像的完整解决方案。

红帽支持使用 skopeo 命令管理容器镜像注册表中的镜像。与 docker 命令相比，skopeo 命令提供了一些好处：

• 以普通用户身份运行，没有等同于 root 的特权。

• 支持从注册表删除镜像。

• 支持镜像签名。

• 直接在两个注册表之间或注册表与本地文件系统之间传输容器镜像，无需经过容器运行时守护进程发送。

• 支持标准开放容器项目 (OCI) 文件格式。

开放容器项目 (OCI) 定义了容器运行时和容器镜像格式的开放标准。OCI 容器镜像格式是文件系统文件夹，包含存储容器镜像清单、元数据和图层的离散文件。

skopeo verb [options] location...

• copy 将镜像从一个位置复制到另外一个位置

• delete 从注册表删除镜像

• inspect 查看有关镜像的元数据。

主要选项是：

• --creds username:password 向注册表提供登陆凭据。

• --[src-|dest-]tls-verify=false 不须要 HTTPS，也不须要 TLS 证书。

要将容器镜像从 myimage OCI 格式的文件夹复制到位于 registry.example.com 的不安全的注册表：
skopeo copy --dest-tls-verify=false oci:myimage docker://registry.example.com/myimage

要从位于 registry.example.com 的不安全的注册表删除 myimage 容器镜像：skopeo delete --tls-verify=false docker://registry.example.com/myimage

建立独立注册表

firewall-cmd --zone=trusted --add-port 5000/tcp --permanent
firewall-cmd --reload

vi /etc/docker-distribution/registry/config.yml

经过从磁盘上的开放容器项目 (OCI) 兼容文件向其推送镜像来测试独立注册表。

检查本地磁盘中的 rhel7-sleep 容器 OCI 镜像层。OCI 镜像存储为包含多个文件的文件系统文件夹：

配置本地 Docker 守护进程以将独立注册表用做不安全的注册表。

将独立注册表主机和端口添加到 Docker 守护进程配置中的 INSECURE_REGISTRY 环境变量。

以 root 用户身份，使用文本编辑器打开 /etc/sysconfig/docker 文件并找到如下行：
INSECURE_REGISTRY='--insecure-registry registry.lab.example.com:5000 --insecure-registry workstation.lab.example.com:5000'
systemctl restart docker

从独立注册表中的镜像启动测试容器：

从独立注册表中的容器镜像部署应用

构建流程

红帽 OpenShift 容器平台可经过构建流程，将输入参数转变为容器镜像。在大多数状况下，红帽 OpenShift 容器平台会下载源代码应用，并构建相应的容器镜像以用于在该平台上实施新的部署。

OpenShift 须要使用 BuildConfig 资源以构建容器镜像。对于这类资源，须要配置一个策略以及一个或多个输入源。
构建策略

如下是 OpenShift 中可供使用的构建策略：

Source

Pipeline

Docker

Custom

每种策略都须要使用相应的容器镜像。OpenShift 提供了用于实施 Source、Pipeline 和 Docker 的容器镜像。

Source

Source 策略会基于应用源代码建立新的容器镜像。OpenShift 会克隆兼容构建器镜像中的应用源代码，而后经过汇编方式构建一个能够即刻在该平台中进行部署的新容器镜像。

该策略能够简化开发人员构建容器镜像的方式，由于该策略会使用与容器镜像相似的工具，而不是使用低级别的 OS 命令，如包含 Dockerfiles 的 yum。

Source 策略基于 source-to-image (S2I) 流程。

Pipeline

pipeline 策略会使用 Jenkins pipeline 插件来建立新的容器镜像。虽然这些容器镜像是 Jenkins 构建的，但构建可由 OpenShift 来启动、监控和管理。

BuildConfig 资源可在构建配置或 Git 存储库中直接引用包含管道工做流的 Jenkinsfile。

OpenShift 会启动新的 Jenkins 服务器，以便在第一次构建时采用管道策略来执行管道。项目中的后续管道构建配置则会共享这个 Jenkins 服务器。

Docker

docker 策略会运行 docker build 命令以构建新的容器镜像。该策略须要使用包含 Dockerfile 的 Git 存储库以及相应的构建构件。

Docker build 会做为 OpenShift 集群内部的一个 Pod 来运行。无需在开发人员的工做站上构建 Docker 环境。

Custom

custom 策略会指定负责实施构建流程的构建器镜像。它容许开发人员自定义构建流程。请参见本单元中的“参考资料”部分，以查找有关如何建立自定义构建器镜像的更多信息。

构建输入源

构建输入源可为构建提供源内容。OpenShift 支持六种类型来源：

• Git：从 Git 存储库克隆输入源。能够将该存储库中的某个位置配置为默认位置，以便在构建时从中查找应用源代码。

• Dockerfile：指定用于构建镜像的内联 Dockerfile。这个 Dockerfile 会覆盖来自 Git 存储库的 Dockerfile。

• Binary：容许将本地文件系统中的二进制内容流化至构建器。

• Image：可为构建流程提供来自镜像的其余文件。

• Input secrets：容许为构建建立在最终应用镜像中不可用的凭据。

• External artifacts：容许将二进制文件复制到构建流程中。

可将多个输入整合到单个构建中。Binary 和 Git 是两种互斥的输入类型。

虽然 OpenShift 提供了多种策略和输入源，但最多见的场景是使用 Source 或 Docker 策略并将 Git 存储库做为惟一的输入源。

管理应用构建

• OpenJDK S2I 构建器镜像 (redhat-openjdk-18/openjdk18-openshift)。

• 应用 Git 存储库 (java-serverhost)。

基于 Git 中的来源建立新应用。将应用命名为 jhost，并在 oc new-app 命令中使用 --build-env 选项来定义构建环境变量和 maven 存储库位置。

oc new-app --name jhost
--build-env MAVEN_MIRROR_URL=\http://services.lab.example.com:8081/nexus/content/groups/training-java
-i redhat-openjdk18-openshift
http://services.lab.example.com/java-serverhost

将应用更新至 2.0 版。

编辑 /home/student/java-serverhost/src/main/java/com/redhat/training/example/ 文件夹中的 ServerHostEndPoint.java 文件，并更新至 2.0 版：

使用构建触发器

您能够定义 OpenShift 构建触发器，以容许新构建自动启动。这些触发器可基于新的容器镜像和各类配置变化，不断更新应用容器。OpenShift 能够定义两类构建触发器：

镜像更改触发器
镜像更改触发器会从新构建应用容器镜像，以体现其父镜像所作的更改。

配置更改触发器
配置更改触发器会在构建配置建立后构建应用容器镜像。

在之后的红帽 OpenShift 容器平台版本中，构建配置触发器也会在构建配置发生变化时启动新的应用构建。

镜像更改触发器使得开发人员无需密切留意应用父镜像中的各类变化。镜像更改触发器会由可向 OpenShift 主控机发送相关通知的注册表服务器（如 OpenShift 内部注册表）自动激活。若是注册表服务器不支持通知功能，则您须要按期运行 oc import-image 命令，以验证注册表服务器中的容器镜像是否有所变化。
oc new-app 命令会自动采用 Source 或 Docker 构建策略为应用建立镜像更改触发器。

• 采用 Source 策略时，父镜像就是应用编程语言的 S2I 构建器镜像。

• 采用 Docker 策略时，父镜像就是应用 Dockerfile 中 FROM 指令所引用的镜像。

要为构建配置添加镜像更改触发器，请使用 oc set triggers 命令：

oc set triggers bc/name --from-image=project/image:tag

一个构建配置能够包含多个镜像更改触发器，可是采用 Source 和 Docker 策略的构建配置应该只须要一个镜像更改触发器。

使用 webhook 触发器

OpenShift webhook 触发器是可启动新构建的 HTTP API 端点。若是使用 webhook 以更改源代码的方式将 OpenShift 与版本控制系统 (VCS)（如 Git）进行整合，则会在 OpenShift 中启动新的构建。

即便软件并不是 VCS，也可使用这些 API 端点，可是 OpenShift 构建只能从 Git 服务器获取源代码。
红帽 OpenShift 容器平台 3.6 提供了专用的 webhook 类型，用于支持与如下 VCS 软件兼容的 API 端点：

GitLab
GitHub
Bitbucket

红帽 OpenShift 容器平台 3.6 还提供了一种通用 webhook 类型，用于获取 OpenShift 定义的载荷。通用 webhook 可供任意软件用于启动 OpenShift 构建。请参见本节末尾的产品文档参考资料，以了解通用 webhook 载荷的语法以及可针对各种 webhook 提出的 HTTP API 请求。

oc new-app 命令能够建立通用 webhook 和 Git webhook。要向构建配置添加其余类型的 webhook，请使用 oc set triggers 命令。例如，要向构建配置添加 GitLab webhook，请使用如下命令：

oc set triggers bc/name --from-gitlab

若是构建配置已包含 GitLab webhook，则先前的命令会重置嵌在 URL 中的身份验证机密。您必须更新本身的 GitLab 项目，以使用新的 webhook URL。

触发构建

• PHP S2I 构建器镜像 (rhscl/php-70-rhel7:latest)。

• PHP S2I 构建器镜像的新版本 (php-70-rhel7-newer.tar.gz)

• 应用 Git 存储库 (trigger-builds)。

基于 Git 中的来源建立新应用。将应用命名为 trigger。

若是镜像流检测到其基础镜像有所变化，则最后一个触发器（即 ImageChange 触发器）会启动新构建。

更新镜像流以启动新构建。查看用于标记 rhscl/php-70-rhel7 的新版本并将其推送至课堂私有注册表的脚本。该脚本位于 /home/student/DO288/labs/trigger-builds 文件夹中：

要更新 openshift 命名空间中的镜像流，用户须要拥有集群管理员特权。以集群管理员身份登陆 OpenShift。

更新 php 镜像流，以重新的容器镜像中获取元数据。外部注册表会使用 docker-distribution 软件包，并且不会向 OpenShift 发送镜像更改通知。

镜像流更新操做触发了新的构建。列出全部构建，以验证第二个构建是否已启动：