應用的自動構建：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 發送鏡像更改通知。

鏡像流更新操做觸發了新的構建。列出全部構建，以驗證第二個構建是否已啓動：