紅帽 OpenShift 作為企業級容器應用平台，提供簡化的開發、佈署和管理流程。本文除了介紹 OpenShift 的核心功能，也涵蓋 DevOps 的整合、OKD 的關聯以及不同版本的 OpenShift 與佈署選項。更進一步探討 OpenShift 的核心資源，如 Route、Service、Deployment 和 Pod，並提供建置和佈署策略的說明，讓讀者能快速上手 OpenShift。同時，本文也涵蓋 Docker 映像檔管理、Dockerfile 的撰寫以及容器管理的最佳實踐，幫助讀者建立更有效率的容器化工作流程。最後，也將探討 Docker 映像檔層級結構和標籤管理，並展望未來發展方向，提供讀者全面的容器技術視野。
紅帽OpenShift容器平台：企業級容器應用開發與佈署
紅帽OpenShift容器平台為企業提供了在實體、虛擬和公有雲基礎設施中輕鬆開發、佈署和管理現有及新應用程式的能力。最新版本可於https://www.redhat.com/en/openshift-4/details 取得。除了採用更新版本的Kubernetes外，CRI-O將作為預設的容器執行環境。
OpenShift作為平台即服務（PaaS）
平台即服務（PaaS）是一種雲端服務型別，其中交付了一個平台，用於執行應用程式的服務和功能，同時將操作負擔降至最低。在PaaS模型中，開發人員主要專注於其程式碼，將繁重的平台工作（如定義應用程式執行的環境、高用性或作業系統維護等）交由平台處理。
紅帽OpenShift提供了一個完整的容器平台，整合了Docker和Kubernetes作為原生執行技術和容器協調，並具備一系列特殊功能來管理許可權、儲存、應用程式生命週期等企業級功能，根據紅帽企業Linux。
OpenShift中的DevOps實踐
OpenShift的另一個重要優勢是為企業的開發團隊和維運團隊提供了一個共同的平台和工具集，促進了兩者在應用程式開發和維護過程中的協同工作。這使得企業能夠消除緩慢或手動的流程，提高工作效率以滿足業務需求。
OKD與OpenShift的關係
OKD（https://www.okd.io）是Kubernetes的一個發行版，針對持續應用程式開發和多租戶佈署進行了最佳化。OKD也作為紅帽OpenShift Online和紅帽OpenShift容器平台的上游程式碼函式庫。有關更多資訊，請參閱檔案https://docs.okd.io/index.html。
OpenShift的DevOps功能
OpenShift根據Kubernetes容器協調系統，並具備一系列額外的功能，使其成為整合DevOps環境的理想平台：
- 支援傳統和雲原生應用程式開發：提供整合的中介軟體平台，用於應用程式的開發和佈署。
- 容器化應用程式生命週期管理：支援根據容器的應用程式生命週期管理。
- 原始碼到映像（Source-to-Image）：提供工具將原始碼轉換為執行中的應用程式。
作為DevOps工具，OpenShift透過以下功能改善開發和維運團隊之間的溝通，並消除兩者之間的整合障礙：
自助服務：開發人員可以透過簡單的命令請求所需的硬體、軟體和網路資源，大大縮短了從應用架構設計到開始編寫程式碼的時間。
# 示例：使用OpenShift CLI建立新專案 oc new-project my-demo-project多語言支援：允許使用不同的語言、平台和資料函式庫，使開發人員能夠充分利用Docker的功能。
# 示例：Dockerfile支援多語言應用 FROM python:3.9-slim WORKDIR /app COPY . /app RUN pip install -r requirements.txt CMD ["python", "app.py"]
內容解密：
此Dockerfile範例展示瞭如何構建一個Python應用程式的Docker映像。首先，它使用Python 3.9的官方映像作為基礎，接著設定工作目錄並複製應用程式檔案到容器中。然後，它安裝requirements.txt中指定的Python套件。最後，定義了容器啟動時執行的命令。
自動化：提供自動化的系統來管理應用程式的生命週期，提高效率。
# 示例：OpenShift中的佈署組態 apiVersion: apps/v1 kind: Deployment metadata: name: my-demo-app spec: replicas: 3 selector: matchLabels: app: my-demo-app template: metadata: labels: app: my-demo-app spec: containers: - name: my-demo-app image: my-demo-app:latest ports: - containerPort: 8080
內容解密：
此YAML檔案定義了一個Kubernetes佈署物件，用於在OpenShift中佈署應用程式。它指定了佈署名稱、副本數量、選擇器和Pod範本。在此範例中，我們佈署了一個名為my-demo-app的應用，使用my-demo-app:latest映像，並開放了8080埠。
OpenShift版本與佈署選項
目前有四種版本的OpenShift：
- OpenShift Origin：允許您擁有一個由紅帽管理的OpenShift叢集來佈署您的應用程式。
- OpenShift Online：允許您在紅帽提供的公有雲中建立和執行應用程式。
- OpenShift Dedicated：提供一個由紅帽管理的OpenShift叢集，用於佈署您的應用程式。
- OpenShift Container Platform：允許您在自己的基礎設施上擁有一個由紅帽管理的OpenShift叢集。
要在本地環境中佈署OpenShift叢集例項，有兩個選項：
在容器中執行OKD：遵循docs.okd.io網站上的檔案說明。
# 示例：在容器中執行OKD docker run -d --name okd-cluster \ -p 8443:8443 \ openshift/origin-control-plane:latest
內容解密：
此命令用於在容器中啟動一個OKD叢集。它將容器的8443埠對映到主機的8443埠，以便存取叢集。
- 使用Minishift試用OKD：Minishift允許您在本機機器上使用虛擬機器建立一個單節點的叢集。相關檔案和說明可參閱https://www.okd.io/minishift。
OpenShift 核心資源介紹
OpenShift 是一個強大的容器應用平台（PaaS），提供多種資源以支援容器化應用的開發、佈署和管理。在本章中，我們將探討 OpenShift 的核心資源，包括 Route、Service、Deployment 和 Pod，並瞭解如何利用這些資源來構建和管理容器化應用。
OpenShift 資源概覽
在 OpenShift 控制檯中，我們可以看到專案的概覽頁面，如下圖所示：
此圖示呈現了 OpenShift 專案的整體架構，包括 Route、Service、Deployment 和 Pod 等核心資源。接下來，我們將逐一介紹這些資源的功能和組態。
Route（路由）
Route 是 OpenShift 中的一個重要資源，它代表了一個服務的 URL 地址，使得外部使用者可以透過該 URL 存取服務。Route 可以組態為對外開放或僅供內部使用。
Route 組態範例
apiVersion: route.openshift.io/v1
kind: Route
metadata:
name: welcome-php
spec:
host: welcome-php-demo.cloudapps.example.com
port:
targetPort: 8080
tls:
insecureEdgeTerminationPolicy: Allow
termination: edge
內容解密：
apiVersion和kind定義了該資源的 API 版本和型別。metadata包含了 Route 的元資料，如名稱等。spec定義了 Route 的具體組態，包括主機名稱、目標埠和 TLS 組態。
Service（服務）
Service 是 OpenShift 中的另一個核心資源，它代表了一個應用的入口點，並暴露特定的埠以供其他元件或外部存取。
Service 組態範例
apiVersion: v1
kind: Service
metadata:
name: welcome-php
spec:
selector:
app: welcome-php
ports:
- name: http
port: 8080
targetPort: 8080
內容解密：
spec.selector定義了 Service 所選擇的 Pod，通常是根據標籤選擇器來匹配的。spec.ports定義了 Service 所暴露的埠及其對應的目標埠。
Deployment（佈署）
Deployment 是 OpenShift 中用於管理應用佈署的資源，它定義了應用的佈署組態，包括例項數量、容器映像檔和擴充套件引數等。
Deployment 組態範例
apiVersion: apps/v1
kind: Deployment
metadata:
name: welcome-php
spec:
replicas: 2
selector:
matchLabels:
app: welcome-php
template:
metadata:
labels:
app: welcome-php
spec:
containers:
- name: welcome-php
image: docker.io/openshift/welcome-php:latest
ports:
- containerPort: 8080
內容解密：
spec.replicas定義了 Deployment 所管理的 Pod 例項數量。spec.template.spec.containers定義了容器映像檔和其他相關組態。
Pod（容器例項）
Pod 是 OpenShift 中的基本執行單元，它代表了一個或多個容器的集合。Pod 中的容器分享相同的網路名稱空間和儲存卷。
Pod 組態範例
apiVersion: v1
kind: Pod
metadata:
name: welcome-php-1
spec:
containers:
- name: welcome-php
image: docker.io/openshift/welcome-php:latest
ports:
- containerPort: 8080
內容解密：
spec.containers定義了 Pod 中的容器及其相關組態。
建置和佈署策略
OpenShift 提供了多種建置和佈署策略，包括 Source-to-Image（S2I）、Docker 建置和自定義建置等。
- Source-to-Image（S2I）：S2I 是一種框架，可以根據應用程式原始碼生成 Docker 映像檔。它支援多種程式語言，包括 Java、JavaScript、Perl、PHP、Python 和 Ruby。
- Docker 建置：Docker 建置策略會執行 Docker 建置並等待映像檔生成後再佈署。
- 自定義建置：自定義建置策略允許使用者自定義建置過程，可以用於複雜的建置場景。
圖表翻譯：OpenShift 建置流程
圖表翻譯：
此圖表呈現了 OpenShift 的建置流程。首先，原始碼透過 S2I 建置生成 Docker 映像檔。然後，映像檔被推播到映像檔倉函式庫。最後，OpenShift 從倉函式庫中提取映像檔並佈署到 Pod 中。
Docker 與容器管理
Docker 是一種流行的容器化技術，允許開發者將應用程式及其依賴項封裝成一個可移植的容器。在本章中，我們將探討 Docker 的核心概念，包括映像檔、容器和 Dockerfile，並瞭解如何使用 Docker 命令列工具來管理容器和映像檔。
Docker 映像檔管理
Docker 映像檔是一個唯讀的範本，用於建立容器。映像檔可以透過 Dockerfile 或從現有的容器建立。Docker 映像檔由多個層組成，每一層代表了一個變更或新增的檔案。
Docker 映像檔命令
以下是一些常用的 Docker 映像檔命令：
docker pull <image_name>：從 Docker Hub 或其他倉函式庫提取映像檔。docker images：列出本地的所有 Docker 映像檔。docker rmi <image_id>：刪除指定的 Docker 映像檔。docker tag <image_id> <new_name>：為指定的 Docker 映像檔建立一個新的標籤。
Dockerfile 命令
Dockerfile 是一種文字檔案，用於定義 Docker 映像檔的建立過程。Dockerfile 中包含了一系列命令，用於指定基礎映像檔、複製檔案、安裝依賴項和設定環境變數等。
常用的 Dockerfile 命令
以下是一些常用的 Dockerfile 命令：
FROM <base_image>：指定基礎映像檔。RUN <command>：在映像檔中執行命令。COPY <src> <dest>：將檔案或目錄從主機複製到映像檔中。EXPOSE <port>：暴露指定的埠。ENV <key> <value>：設定環境變數。
Dockerfile 範例
FROM python:3.9-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
EXPOSE 8000
CMD ["python", "app.py"]
內容解密：
FROM python:3.9-slim指定了基礎映像檔為 Python 3.9。WORKDIR /app設定了工作目錄為/app。COPY requirements.txt .將requirements.txt複製到工作目錄。RUN pip install -r requirements.txt安裝了依賴項。COPY . .將當前目錄的所有檔案複製到工作目錄。EXPOSE 8000暴露了埠 8000。CMD ["python", "app.py"]設定了預設的啟動命令。
Docker 容器管理
Docker 容器是根據 Docker 映像檔建立的可執行例項。容器可以被建立、啟動、停止和刪除。
Docker 容器命令
以下是一些常用的 Docker 容器命令：
docker run <image_name>：建立並啟動一個新的容器。docker ps：列出所有正在執行的容器。docker stop <container_id>：停止指定的容器。docker rm <container_id>：刪除指定的容器。
圖表翻譯：Docker 容器生命週期
圖表翻譯：
此圖表呈現了 Docker 容器的生命週期。首先，透過 docker run 命令建立並啟動一個新的容器。當容器執行時，可以透過 docker stop 命令停止它。停止的容器可以透過 docker start 命令重新啟動，也可以透過 docker rm 命令刪除。
Docker 映像檔的管理與最佳實踐
Docker 映像檔是容器化的基礎，理解其內部結構和管理方式對於高效使用 Docker 至關重要。本文將探討 Docker 映像檔的層級結構、標籤管理以及建立映像檔的最佳實踐。
Docker 映像檔的層級結構
Docker 映像檔是由多個唯讀層（read-only layers）堆積疊而成，每一層代表著檔案系統的變更。最後一層則是以讀寫模式掛載，提供容器執行時的資料儲存空間。這種設計使得多個容器可以共用相同的基礎映像檔，同時保持各自的獨立性。
# 檢視映像檔的層級歷史
docker image history python
內容解密：
此命令用於顯示指定映像檔的層級歷史。每一行代表一個層級，包含了建立該層級的命令、大小等資訊。透過分析這些資訊，可以瞭解映像檔的構建過程和各層級的大小，從而最佳化映像檔的構建。
映像檔標籤的管理
映像檔標籤（Image Tags）是用於標識映像檔版本的重要機制。透過標籤，可以方便地管理和使用不同版本的映像檔。例如，在 Docker Hub 上，可以看到 Python 官方映像檔提供了多個版本的標籤，如 latest、3.8-rc-alpine3.10 等。
# 提取特定版本的 Python 映像檔
docker image pull python:3.8-rc-alpine3.10
內容解密：
此命令示範瞭如何提取特定版本的映像檔。在實際應用中，應根據需求選擇合適的版本標籤，以確保環境的一致性和穩定性。
建立 Docker 映像檔的最佳實踐
- 最小化映像檔大小：較小的映像檔具有更好的穩定性、安全性和載入速度。建議在開發過程中僅安裝必要的工具和套件。
- 選擇合適的基礎映像檔：基礎映像檔的選擇直接影響到最終映像檔的大小和功能。應根據應用需求選擇官方或評價良好的基礎映像檔。
- 使用 Dockerfile 自動化構建：透過編寫 Dockerfile，可以自動化地構建映像檔，確保構建過程的一致性和可重複性。
Dockerfile 的基本語法和指令
Dockerfile 是一種文字檔案，包含了用於構建映像檔的指令集。Docker 將按照指令順序執行這些命令，最終生成所需的映像檔。
# 使用官方 Python 基礎映像檔
FROM python:3.9-slim
# 設定工作目錄
WORKDIR /app
# 複製應用程式碼
COPY . /app
# 安裝依賴套件
RUN pip install -r requirements.txt
# 暴露應用程式埠
EXPOSE 8000
# 設定容器啟動命令
CMD ["python", "app.py"]
內容解密：
此 Dockerfile 示範瞭如何從官方 Python 基礎映像檔構建一個新的映像檔。首先，它設定了工作目錄並複製了應用程式碼。接著，安裝了依賴套件並暴露了應用程式的埠。最後，定義了容器啟動時執行的命令。
從 Dockerfile 建立映像檔
使用 docker build 命令可以根據 Dockerfile 建立映像檔。
# 建立映像檔
docker build -t my-python-app .
內容解密：
此命令示範瞭如何使用 docker build 命令建立一個名為 my-python-app 的映像檔。-t 選項用於指定映像檔的名稱和標籤。
隨著容器化技術的不斷發展，未來 Docker 映像檔的管理和構建將朝著更加自動化、安全化和高效化的方向發展。開發者需要持續關注最新的技術趨勢和最佳實踐，以保持在容器化技術領域的競爭力。
Docker 映像檔層級結構示意圖
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title OpenShift容器平台應用開發佈署
package "Kubernetes Cluster" {
package "Control Plane" {
component [API Server] as api
component [Controller Manager] as cm
component [Scheduler] as sched
database [etcd] as etcd
}
package "Worker Nodes" {
component [Kubelet] as kubelet
component [Kube-proxy] as proxy
package "Pods" {
component [Container 1] as c1
component [Container 2] as c2
}
}
}
api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2
note right of api
核心 API 入口
所有操作經由此處
end note
@enduml圖表翻譯： 此圖示展示了 Docker 映像檔的層級結構，從基礎映像檔開始，每一層代表著檔案系統的變更，最後一層以讀寫模式掛載，提供容器執行時的資料儲存空間。
