OpenShift 快速指南



OpenShift - 概述

OpenShift 是一個由 Red Hat 託管的雲開發平臺即服務 (PaaS)。它是一個開源的基於雲的、使用者友好的平臺,用於建立、測試和執行應用程式,並最終將其部署到雲中。

OpenShift 能夠管理用不同語言編寫的應用程式,例如 Node.js、Ruby、Python、Perl 和 Java。OpenShift 的關鍵特性之一是它具有可擴充套件性,這有助於使用者支援用其他語言編寫的應用程式。

OpenShift 帶有各種虛擬化概念作為其抽象層。OpenShift 背後的基本概念是基於虛擬化的。

虛擬化

一般來說,虛擬化可以定義為建立虛擬系統,而不是任何事物的物理或實際版本,從系統、儲存或作業系統開始。虛擬化的主要目標是使 IT 基礎設施更具可擴充套件性和可靠性。虛擬化的概念已經存在了幾十年,並且隨著當今 IT 行業的發展,它可以應用於從系統級、硬體級到伺服器級虛擬化的廣泛層級。

工作原理

它可以描述為一種技術,其中任何應用程式或作業系統都與其實際物理層分離。虛擬化技術的關鍵用途之一是伺服器虛擬化,它使用稱為管理程式的軟體從底層硬體中抽象出層。在虛擬化上執行的作業系統的效能與在物理硬體上執行時一樣好。但是,虛擬化的概念很流行,因為大多數執行的系統和應用程式不需要使用底層硬體。

物理架構與虛擬架構

Physical vs Virtual Architecture

虛擬化型別

  • 應用程式虛擬化 - 在此方法中,應用程式與底層作業系統分離。此方法非常有用,因為可以在隔離環境中執行應用程式,而無需依賴底層作業系統。

  • 桌面虛擬化 - 此方法用於減少工作站負載,其中使用者可以使用桌面上的瘦客戶端遠端訪問桌面。在此方法中,桌面主要在資料中心執行。一個典型的例子可以是虛擬桌面映像 (VDI),它在大多陣列織中使用。

  • 資料虛擬化 - 它是抽象化並擺脫傳統資料和資料管理方法的一種方法。

  • 伺服器虛擬化 - 在此方法中,與伺服器相關的資源被虛擬化,包括物理伺服器、程序和作業系統。啟用此抽象的軟體通常稱為管理程式。

  • 儲存虛擬化 - 它是將多個儲存裝置合併到一個儲存裝置中的過程,該儲存裝置由單箇中央控制檯管理。

  • 網路虛擬化 - 它是將所有可用網路資源組合起來的方法,方法是將可用頻寬和通道分成多個部分,每個部分彼此獨立。

OpenShift

OpenShift 是一個支援雲的應用程式平臺即服務 (PaaS)。它是一種開源技術,可幫助組織將其傳統的應用程式基礎設施和平臺從物理、虛擬媒介遷移到雲中。

OpenShift 支援各種各樣的應用程式,這些應用程式可以輕鬆地開發和部署在 OpenShift 雲平臺上。OpenShift 主要為開發人員和使用者提供三種平臺。

基礎設施即服務 (IaaS)

在此格式中,服務提供商提供具有某些預定義虛擬硬體配置的硬體級虛擬機器。在這個領域有多個競爭對手,從 AWS 谷歌雲、Rackspace 等開始。

在經過漫長的設定和投資過程後,使用 IaaS 的主要缺點是,您仍然負責安裝和維護作業系統和伺服器軟體包、管理基礎設施網路以及處理基本的系統管理。

軟體即服務 (SaaS)

使用 SaaS,您無需擔心底層基礎設施。它就像即插即用一樣簡單,使用者只需註冊服務即可開始使用。此設定的主要缺點是,使用者只能執行服務提供商允許的少量自定義。SaaS 最常見的例子是 Gmail,使用者只需登入即可開始使用。使用者還可以對其帳戶進行一些小的修改。但是,從開發人員的角度來看,它不是很有用。

平臺即服務 (PaaS)

它可以被視為 SaaS 和 IaaS 之間的中間層。PaaS 評估的主要目標是開發人員,他們可以在其中使用一些命令啟動開發環境。這些環境的設計方式是為了滿足所有開發需求,從擁有帶資料庫的 Web 應用程式伺服器開始。要做到這一點,您只需要一個命令,服務提供商就會為您完成所有工作。

為什麼要使用 OpenShift?

OpenShift 為企業單位提供了一個通用平臺,可以在雲上託管其應用程式,而無需擔心底層作業系統。這使得在雲上使用、開發和部署應用程式變得非常容易。關鍵特性之一是,它為各種開發和測試提供託管的硬體和網路資源。使用 OpenShift,PaaS 開發人員可以自由設計其所需的環境及其規範。

OpenShift 在服務計劃方面提供了不同型別的服務級別協議。

免費 - 此計劃限於三年,每個計劃 1GB 空間。

青銅 - 此計劃包含 3 年,最多可擴充套件至 16 年,每年 1GB 空間。

- 這是青銅的 16 年計劃,但是儲存容量為 6GB,無需額外費用。

除了上述功能外,OpenShift 還提供名為 OpenShift Enterprise 的本地版本。在 OpenShift 中,開發人員可以利用設計可擴充套件和不可擴充套件的應用程式,這些設計使用 HAproxy 伺服器實現。

特性

OpenShift 支援多種功能。其中一些是 -

  • 多語言支援
  • 多資料庫支援
  • 可擴充套件的 Cartridge 系統
  • 原始碼版本管理
  • 一鍵部署
  • 多環境支援
  • 標準化的開發人員工作流程
  • 依賴項和構建管理
  • 自動應用程式擴充套件
  • 響應式 Web 控制檯
  • 豐富的命令列工具集
  • 遠端 SSH 登入到應用程式
  • Rest API 支援
  • 自助式按需應用程式堆疊
  • 內建資料庫服務
  • 持續整合和釋出管理
  • IDE 整合
  • 應用程式的遠端除錯

OpenShift - 型別

OpenShift 誕生於其名為 OpenShift V2 的基礎,該基礎主要基於年和 Cartridge 的概念,其中每個元件都有其規範,從機器建立到應用程式部署,從構建到部署應用程式。

Cartridge - 它們是構建新應用程式的焦點,從應用程式型別到環境執行它們所需的依賴項,都在此部分滿足。

- 它可以定義為具有關於資源、記憶體和 CPU 的某些規範的裸機或伺服器。它們被認為是執行應用程式的基本單元。

應用程式 - 這些僅指將在 OpenShift 環境中部署和執行的應用程式或任何整合應用程式。

隨著我們深入本節,我們將討論 OpenShift 的不同格式和產品。在早期,OpenShift 有三個主要版本。

OpenShift Origin - 這是 OpenShift 的社群版本或開源版本。它也被稱為其他兩個版本的的上游專案。

OpenShift Online - 它是在 AWS 上託管的公共 PaaS 即服務。

OpenShift Enterprise - 是 OpenShift 的強化版本,具有 ISV 和供應商許可證。

OpenShift Online

OpenShift Online 是 OpenShift 社群的產物,使用者可以使用它在公共雲上快速構建、部署和擴充套件容器化應用程式。它是 Red Hat 的公共雲應用程式開發和託管平臺,它支援應用程式的自動化供應、管理和擴充套件,幫助開發人員專注於編寫應用程式邏輯。

在 Red Hat OpenShift Online 上設定帳戶

步驟 1 - 開啟瀏覽器並訪問網站 https://manage.openshift.com/

RedHat Account Setting Step1

步驟 2 - 如果您有 Red Hat 帳戶,請使用以下 URL 使用 Red Hat 登入 ID 和密碼登入 OpenShift 帳戶。 https://developers.redhat.com

RedHat Account Setting Step2

步驟 3 - 如果您沒有 Red Hat 帳戶登入,請使用以下連結註冊 OpenShift 線上服務。

https://developers.redhat.com/auth/realms/rhd/login-actions/registration?code=G4w-myLd3GCH_QZCqMUmIOQlU7DIf_gfIvGu38nnzZQ.cb229a9d-3cff-4c58-b7f6-7b2c9eb17926

RedHat Account Setting Step3-1

登入後,您將看到以下頁面。

RedHat Account Setting Step3-2

一旦您準備就緒,Red Hat 將顯示一些基本帳戶詳細資訊,如下面的螢幕截圖所示。

RedHat Account Setting Step3-3

最後,登入後,您將看到以下頁面。

RedHat Account Setting LogIn

OpenShift 容器平臺

OpenShift 容器平臺是一個企業級平臺,它幫助多個團隊(例如開發團隊和 IT 運維團隊)構建和部署容器化基礎設施。所有在 OpenShift 中構建的容器都使用非常可靠的 Docker 容器化技術,可以部署在任何資料中心或公開託管的雲平臺上。

OpenShift 容器平臺以前稱為 OpenShift 企業版。它是一個基於 Red Hat 的本地私有平臺即服務,構建於以 Docker 為動力的應用程式容器的核心概念之上,其中編排和管理由 Kubernetes 負責。

換句話說,OpenShift 將 Docker 和 Kubernetes 整合到企業級。它是一個容器平臺軟體,供企業單位在其選擇的架構中部署和管理應用程式。例如,在 AWS 例項上託管 OpenShift 例項。

OpenShift 容器平臺提供 **兩種軟體包級別**。

**OpenShift 容器本地版** - 適用於希望在本地機器上部署和測試應用程式的開發人員。此軟體包主要由開發團隊用於開發和測試應用程式。

**OpenShift 容器實驗室版** - 旨在擴充套件應用程式評估,從開發到部署到預生產環境。

OpenShift Container Platform

OpenShift 專屬版

這是新增到 OpenShift 產品組合中的另一個產品,其中客戶可以選擇在其選擇的任何公共雲上託管容器化平臺。這為終端使用者提供了真正的多雲產品體驗,他們可以在滿足其需求的任何雲上使用 OpenShift。

這是 Red Hat 最新的產品之一,終端使用者可以使用 OpenShift 在託管在雲上的 OpenShift 上構建、測試、部署和執行其應用程式。

OpenShift 專屬版的功能

OpenShift 專屬版在公共雲上提供定製的解決方案應用程式平臺,並且繼承自 OpenShift 3 技術。

  • **可擴充套件和開放** - 因為它基於 Docker 的開放概念並在雲上部署,因此可以根據需要擴充套件自身。

  • **可移植性** - 由於它使用 Docker 構建,因此在 Docker 上執行的應用程式可以輕鬆地從一個地方運送到另一個支援 Docker 的地方。

  • **編排** - 使用 OpenShift 3,容器編排和叢集管理的關鍵功能之一是透過 Kubernetes 支援的,Kubernetes 是從 OpenShift 版本 3 開始提供的。

  • **自動化** - 此版本的 OpenShift 啟用了原始碼管理、構建自動化和部署自動化功能,使其在市場上作為平臺即服務提供商非常受歡迎。

OpenShift 的競爭對手

**Google App Engine** - 這是 Google 用於開發和託管 Web 應用程式的免費平臺。Google 的 App Engine 提供快速開發和部署平臺。

**Microsoft Azure** - Azure 雲由 Microsoft 在其資料中心託管。

**Amazon Elastic Cloud Compute** - 它們是 Amazon 提供的內建服務,有助於在雲上開發和託管可擴充套件的 Web 應用程式。

**Cloud Foundry** - 是一個開源 PaaS 平臺,用於 Java、Ruby、Python 和 Node.js 應用程式。

**CloudStack** - Apache 的 CloudStack 是 Citrix 開發的一個專案,旨在成為 OpenShift 和 OpenStack 的直接競爭對手。

**OpenStack** - Red Hat 提供的另一種用於雲計算的雲技術。

**Kubernetes** - 它是一種直接的編排和叢集管理技術,旨在管理 Docker 容器。

OpenShift - 架構

OpenShift 是一個分層系統,其中每一層都使用 Kubernetes 和 Docker 叢集與其他層緊密繫結。OpenShift 的架構設計為能夠支援和管理 Docker 容器,這些容器使用 Kubernetes 託管在所有層之上。與早期的 OpenShift V2 版本不同,新的 OpenShift V3 版本支援容器化基礎設施。在此模型中,Docker 幫助建立輕量級的基於 Linux 的容器,而 Kubernetes 支援在多個主機上編排和管理容器的任務。

OpenShift Container Platform Architecture

OpenShift 的元件

OpenShift 架構的關鍵元件之一是在 Kubernetes 中管理容器化基礎設施。Kubernetes 負責基礎設施的部署和管理。在任何 Kubernetes 叢集中,我們都可以擁有多個主節點和多個工作節點,從而確保設定中沒有單點故障。

Key Components of OpenShift Architecture

Kubernetes 主節點元件

**etcd** - 它儲存配置資訊,叢集中的每個節點都可以使用這些資訊。它是一個高可用性的鍵值儲存,可以在多個節點之間分佈。它只能由 Kubernetes API 伺服器訪問,因為它可能包含敏感資訊。它是一個分散式的鍵值儲存,所有節點都可以訪問。

**API 伺服器** - Kubernetes 是一個 API 伺服器,它使用 API 提供叢集上的所有操作。API 伺服器實現了一個介面,這意味著不同的工具和庫可以輕鬆地與之通訊。kubeconfig 是一個與伺服器端工具一起提供的軟體包,可用於通訊。它公開了 Kubernetes API”。

**控制器管理器** - 此元件負責大多數調節叢集狀態並執行任務的控制器。它可以被認為是一個在非終止迴圈中執行的守護程序,負責收集資訊並將其傳送到 API 伺服器。它致力於獲取叢集的共享狀態,然後進行更改以將伺服器的當前狀態更改為所需狀態。關鍵控制器包括複製控制器、端點控制器、名稱空間控制器和服務帳戶控制器。控制器管理器執行不同型別的控制器來處理節點、端點等。

**排程器** - 它是 Kubernetes 主節點的關鍵元件。它是在主節點中負責分配工作負載的服務。它負責跟蹤叢集節點上的工作負載利用率,然後將工作負載放置在具有可用資源並接受工作負載的節點上。換句話說,這是負責將 Pod 分配給可用節點的機制。排程器負責工作負載利用率並將 Pod 分配給新的節點。

Kubernetes 工作節點元件

以下是工作節點伺服器的關鍵元件,它們對於與 Kubernetes 主節點通訊是必需的。

**Docker** - 每個節點的第一個要求是 Docker,它有助於在相對隔離但輕量級的操作環境中執行封裝的應用程式容器。

**Kubelet 服務** - 這是每個節點中的一項小型服務,負責在控制平面服務之間中繼資訊。它與 etcd 儲存互動以讀取配置詳細資訊並寫入值。它與主節點元件通訊以接收命令和工作。然後,kubelet 程序承擔維護工作狀態和節點伺服器狀態的責任。它管理網路規則、埠轉發等。

**Kubernetes 代理服務** - 這是一項在每個節點上執行的代理服務,有助於使服務可供外部主機使用。它有助於將請求轉發到正確的容器。Kubernetes 代理服務能夠執行基本的負載均衡。它確保網路環境是可預測且可訪問的,但同時也是隔離的。它管理節點上的 Pod、卷、金鑰、建立新的容器健康檢查等。

整合的 OpenShift 容器登錄檔

OpenShift 容器登錄檔是 Red Hat 的內建儲存單元,用於儲存 Docker 映象。隨著 OpenShift 最新整合版本的推出,它提供了一個使用者介面來檢視 OpenShift 內部儲存中的映象。這些登錄檔能夠儲存帶有指定標籤的映象,這些映象稍後將用於從中構建容器。

常用術語

**映象** - Kubernetes(Docker)映象是容器化基礎設施的關鍵構建塊。目前,Kubernetes 僅支援 Docker 映象。Pod 中的每個容器在其內部執行其 Docker 映象。在配置 Pod 時,配置檔案中的映象屬性與 Docker 命令具有相同的語法。

**專案** - 它們可以定義為在早期版本的 OpenShift V2 中存在的域的重新命名版本。

**容器** - 它們是在映象部署到 Kubernetes 叢集節點後建立的。

**節點** - 節點是 Kubernetes 叢集中的工作機器,也稱為主節點的從屬節點。它們是工作單元,可以是物理機、虛擬機器或雲實例。

**Pod** - Pod 是 Kubernetes 叢集節點中容器及其儲存的集合。可以建立一個包含多個容器的 Pod。例如,將資料庫容器和 Web 伺服器容器保留在 Pod 內。

OpenShift - 環境設定

在本章中,我們將學習 OpenShift 的環境設定。

系統要求

為了設定企業級 OpenShift,需要擁有一個有效的 Red Hat 帳戶。由於 OpenShift 在 Kubernetes 主節點和工作節點架構上執行,因此我們需要在不同的機器上設定它們,其中一臺機器充當主節點,另一臺機器充當工作節點。為了設定兩者,有一些最低系統要求。

主節點配置

以下是主節點配置的最低系統要求。

  • 在物理機、虛擬機器或任何雲環境中託管的基礎機器。

  • 至少 Linux 7 及其所需的軟體包。

  • 2 個 CPU 核心。

  • 至少 8 GB RAM。

  • 30 GB 的內部硬碟儲存空間。

工作節點配置

  • 與主節點相同的物理或虛擬基礎映象。
  • 機器上至少安裝 Linux 7。
  • 安裝 Docker,版本不低於 1.6。
  • 1 個 CPU 核心。
  • 8 GB RAM。
  • 15 GB 硬碟用於託管映象,15 GB 用於儲存映象。

OpenShift 設定的分步指南

在以下說明中,我們將設定 OpenShift 實驗室環境,該環境可以稍後擴充套件到更大的叢集。由於 OpenShift 需要主節點和工作節點設定,因此我們需要至少兩臺機器託管在雲、物理機或虛擬機器上。

**步驟 1** - 首先在兩臺機器上安裝 Linux,其中 Linux 7 應為最低版本。如果擁有有效的 Red Hat 訂閱,則可以使用以下命令完成此操作。

# subscription-manager repos --disable = "*"

# subscription-manager repos --enable = "rhel-7-server-rpms"

# subscription-manager repos --enable = "rhel-7-server-extras-rpms"

# subscription-manager repos --enable = "rhel-7-server-optional-rpms"

# subscription-manager repos --enable = "rhel-7-server-ose-3.0-rpms"

# yum install wget git net-tools bind-utils iptables-services bridge-utils

# yum install wget git net-tools bind-utils iptables-services bridge-utils

# yum install python-virtualenv

# yum install gcc

# yum install httpd-tools

# yum install docker

# yum update

在兩臺機器上安裝了所有上述基本軟體包後,下一步將在相應的機器上設定 Docker。

**步驟 2** - 配置 Docker,使其僅允許在本地網路上進行不安全的通訊。為此,編輯 /etc/sysconfig 內的 Docker 檔案。如果檔案不存在,則需要手動建立它。

# vi /etc/sysconfig/docker
OPTIONS = --selinux-enabled --insecure-registry 192.168.122.0/24

在主節點上配置 Docker 後,我們需要設定兩臺機器之間的無密碼通訊。為此,我們將使用公鑰和私鑰身份驗證。

**步驟 3** - 在主節點上生成金鑰,然後將 id_rsa.pub 金鑰複製到工作節點的 authorized_keys 檔案中,這可以透過以下命令完成。

# ssh-keygen

# ssh-copy-id -i .ssh/id_rsa.pub root@ose3-node.test.com

完成上述所有設定後,接下來是在主節點上設定 OpenShift 版本 3。

步驟 4 − 在主節點機器上,執行以下 curl 命令。

# sh <(curl -s https://install.openshift.com/ose)

以上命令將為 OSV3 設定環境。下一步是在機器上配置 OpenShift V3。

如果您無法直接從網際網路下載,則可以從 https://install.openshift.com/portable/oo-install-ose.tgz 下載為 tar 包,安裝程式可以在本地主節點機器上執行。

一旦我們準備好設定,那麼我們需要開始在機器上實際配置 OSV3。此設定非常具體,用於測試實際生產環境,我們已經配置了 LDAP 和其他內容。

步驟 5 − 在主節點機器上,配置位於 /etc/openshift/master/master-config.yaml 下面的以下程式碼。

# vi /etc/openshift/master/master-config.yaml
identityProviders:
- name: my_htpasswd_provider
challenge: true
login: true
provider:
apiVersion: v1
kind: HTPasswdPasswordIdentityProvider
file: /root/users.htpasswd
routingConfig:
subdomain: testing.com

接下來,建立一個標準使用者用於預設管理。

# htpasswd -c /root/users.htpasswd admin

步驟 6 − 由於 OpenShift 使用 Docker 映象倉庫來配置映象,我們需要配置 Docker 映象倉庫。它用於在構建後建立和儲存 Docker 映象。

使用以下命令在 OpenShift 節點機器上建立一個目錄。

# mkdir /images

接下來,使用預設的管理員憑據登入主節點機器,這些憑據在設定映象倉庫時建立。

# oc login
Username: system:admin

切換到預設建立的專案。

# oc project default

步驟 7 − 建立一個 Docker 映象倉庫。

#echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"registry"}}' | oc create -f -

編輯使用者許可權。

#oc edit scc privileged
users:
- system:serviceaccount:openshift-infra:build-controller
- system:serviceaccount:default:registry

建立和編輯映象倉庫。

#oadm registry --service-account = registry --
config = /etc/openshift/master/admin.kubeconfig --
credentials = /etc/openshift/master/openshift-registry.kubeconfig --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}' --
mount-host = /images

步驟 8 − 建立預設路由。

預設情況下,OpenShift 使用 OpenVswitch 作為軟體網路。使用以下命令建立預設路由。它用於負載均衡和代理路由。路由器類似於 Docker 映象倉庫,也執行在映象倉庫中。

# echo '{"kind":"ServiceAccount","apiVersion":"v1","metadata":{"name":"router"}}' | oc create -f -

接下來,編輯使用者的許可權。

#oc edit scc privileged
users:
   - system:serviceaccount:openshift-infra:build-controller
   - system:serviceaccount:default:registry
   - system:serviceaccount:default:router

#oadm router router-1 --replicas = 1 --
credentials = '/etc/openshift/master/openshift-router.kubeconfig' --
images = 'registry.access.redhat.com/openshift3/ose-${component}:${version}'

步驟 9 − 配置 DNS。

為了處理 URL 請求,OpenShift 需要一個可用的 DNS 環境。此 DNS 配置需要建立一個萬用字元,該萬用字元用於建立指向路由器的 DNS 萬用字元。

# yum install bind-utils bind

# systemctl start named

# systemctl enable named

vi /etc/named.conf
options {listen-on port 53 { 10.123.55.111; };
forwarders {
   10.38.55.13;
   ;
};

zone "lab.com" IN {
   type master;
   file "/var/named/dynamic/test.com.zone";
   allow-update { none; };
};

步驟 10 − 最後一步是在 OpenShift V3 主節點機器上設定 github 伺服器,這是可選的。這可以透過以下命令序列輕鬆完成。

#yum install curl openssh-server

#systemctl enable sshd

# systemctl start sshd

# firewall-cmd --permanent --add-service = http

# systemctl reload firewalld

#curl https://packages.gitlab.com/install/repositories/gitlab/gitlab-

#yum install gitlab-ce

# gitlab-ctl reconfigure

完成以上設定後,您可以透過測試和部署應用程式進行驗證,我們將在後續章節中詳細瞭解。

OpenShift - 基本概念

在開始實際設定和部署應用程式之前,我們需要了解 OpenShift V3 中使用的一些基本術語和概念。

容器和映象

映象

這些是 OpenShift 的基本構建塊,由 Docker 映象構成。在 OpenShift 上的每個 Pod 中,叢集都有自己的映象在其內部執行。當我們配置 Pod 時,我們有一個欄位將從映象倉庫中提取。此配置檔案將拉取映象並在叢集節點上部署它。

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> Name of Pod
      spec:
containers:
- name: neo4j-server ------------------------> Name of the image
image: <Name of the Docker image>----------> Image to be pulled
imagePullPolicy: Always ------------->Image pull policy
command: [“echo”, “SUCCESS”] -------------------> Massage after image pull

為了拉取並從中建立一個映象,請執行以下命令。OC 是在登入後與 OpenShift 環境通訊的客戶端。

$ oc create –f Tesing_for_Image_pull

容器

當 Docker 映象部署到 OpenShift 叢集時,就會建立容器。在定義任何配置時,我們在配置檔案中定義容器部分。一個容器可以有多個映象在其內部執行,並且叢集節點上執行的所有容器都由 OpenShift Kubernetes 管理。

spec:
   containers:
   - name: py ------------------------> Name of the container
   image: python----------> Image going to get deployed on container
   command: [“python”, “SUCCESS”]
   restartPocliy: Never --------> Restart policy of container

以下是定義包含多個映象執行的容器的規範。

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
   image: tomcat: 8.0
   ports:
   - containerPort: 7500
      imagePullPolicy: Always
      -name: Database
      Image: mongoDB
      Ports:
      - containerPort: 7501
imagePullPolicy: Always

在以上配置中,我們定義了一個多容器 Pod,其中包含兩個 Tomcat 和 MongoDB 映象。

Pod 和服務

Pod

Pod 可以定義為 OpenShift (Kubernetes) 叢集節點內容器及其儲存的集合。通常,我們有兩種型別的 Pod,從單容器 Pod 到多容器 Pod。

單容器 Pod − 這些可以透過 OC 命令或基本的配置檔案輕鬆建立。

$ oc run <name of pod> --image = <name of the image from registry>

使用以下簡單的 yaml 檔案建立它。

apiVersion: v1
kind: Pod
metadata:
   name: apache
spec:
   containers:
   - name: apache
   image: apache: 8.0
   ports:
      - containerPort: 7500
imagePullPolicy: Always

建立上述檔案後,它將使用以下命令生成一個 Pod。

$ oc create –f apache.yml

多容器 Pod − 多容器 Pod 是那些在其內部執行多個容器的 Pod。它們使用 yaml 檔案建立,如下所示。

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
   image: tomcat: 8.0
   ports:
      - containerPort: 7500
imagePullPolicy: Always
   -name: Database
   Image: mongoDB
   Ports:
      - containerPort: 7501
imagePullPolicy: Always

建立這些檔案後,我們可以簡單地使用與上面相同的方法來建立容器。

服務 − 正如我們有一組容器在 Pod 內執行一樣,我們也有一個服務,可以將其定義為 Pod 的邏輯集合。它是 Pod 之上的一個抽象層,它提供一個單一的 IP 和 DNS 名稱,透過該名稱可以訪問 Pod。服務有助於管理負載均衡配置並非常輕鬆地擴充套件 Pod。在 OpenShift 中,服務是一個 REST 物件,其定義可以釋出到 OpenShift 主節點上的 apiService 以建立新例項。

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
      - port: 8080
         targetPort: 31999

構建和流

構建

在 OpenShift 中,構建是將映象轉換為容器的過程。它是將原始碼轉換為映象的過程。此構建過程基於預定義的策略將原始碼構建為映象。

構建處理多種策略和源。

構建策略

  • 源到映象 − 這基本上是一個工具,它有助於構建可重現的映象。這些映象始終處於就緒狀態,可以使用 Docker run 命令執行。

  • Docker 構建 − 這是使用 Dockerfile 透過執行簡單的 Docker build 命令構建映象的過程。

  • 自定義構建 − 這些是用於建立基本 Docker 映象的構建。

構建源

Git − 當使用 git 倉庫構建映象時,使用此源。Dockerfile 是可選的。原始碼中的配置如下所示。

source:
type: "Git"
git:
   uri: "https://github.com/vipin/testing.git"
   ref: "master"
contextDir: "app/dir"
dockerfile: "FROM openshift/ruby-22-centos7\nUSER example"

Dockerfile − Dockerfile 用作配置檔案中的輸入。

source:
   type: "Dockerfile"
   dockerfile: "FROM ubuntu: latest
   RUN yum install -y httpd"

映象流 − 拉取映象後建立映象流。映象流的優點是它會查詢新版本映象的更新。它用於比較由標籤標識的任意數量的 Docker 格式的容器映象。

映象流可以在建立新映象時自動執行操作。所有構建和部署都可以監視映象操作並相應地執行操作。以下是我們如何定義構建流。

apiVersion: v1
kind: ImageStream
metadata:
   annotations:
      openshift.io/generated-by: OpenShiftNewApp
   generation: 1
   labels:
      app: ruby-sample-build
   selflink: /oapi/v1/namespaces/test/imagestreams/origin-ruby-sample
   uid: ee2b9405-c68c-11e5-8a99-525400f25e34
spec: {}
status:
   dockerImageRepository: 172.30.56.218:5000/test/origin-ruby-sample
   tags:
   - items:
      - created: 2016-01-29T13:40:11Z
      dockerImageReference: 172.30.56.218:5000/test/origin-apache-sample
      generation: 1
      image: vklnld908.int.clsa.com/vipin/test
   tag: latest

路由和模板

路由

在 OpenShift 中,路由是一種透過建立和配置外部可訪問的主機名來將服務暴露給外部世界的方法。路由和端點用於將服務暴露給外部世界,使用者可以從中使用名稱連線(DNS)訪問定義的應用程式。

在 OpenShift 中,路由是透過 OpenShift 管理員在叢集上部署的路由器建立的。路由器用於將 HTTP (80) 和 https (443) 埠繫結到外部應用程式。

以下是路由支援的不同型別的協議 −

  • HTTP
  • HTTPS
  • TSL 和 Websocket

在配置服務時,選擇器用於配置服務並使用該服務查詢端點。以下是如何使用適當的協議建立服務及其路由的示例。

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {"name": "Openshift-Rservice"},
   "spec": {
      "selector": {"name":"RService-openshift"},
      "ports": [
         {
            "protocol": "TCP",
            "port": 8888,
            "targetPort": 8080
         }
      ]
   }
}

接下來,執行以下命令,服務將建立。

$ oc create -f ~/training/content/Openshift-Rservice.json

這是建立後服務的樣子。

$ oc describe service Openshift-Rservice

Name:              Openshift-Rservice
Labels:            <none>
Selector:          name = RService-openshift
Type:              ClusterIP
IP:                172.30.42.80
Port:              <unnamed> 8080/TCP
Endpoints:         <none>
Session Affinity:  None
No events.

使用以下程式碼為服務建立路由。

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {"name": "Openshift-service-route"},
   "spec": {
      "host": "hello-openshift.cloudapps.example.com",
      "to": {
         "kind": "Service",
         "name": "OpenShift-route-service"
      },
      "tls": {"termination": "edge"}
   }
}

當使用 OC 命令建立路由時,將建立一個新的路由資源例項。

模板

模板在 OpenShift 中定義為一個標準物件,可以多次使用。它使用佔位符列表進行引數化,這些佔位符用於建立多個物件。它可以用於建立任何內容,從 Pod 到網路,使用者有權建立。如果來自 CLI 或 GUI 介面中的映象的模板上傳到專案目錄,則可以建立物件列表。

apiVersion: v1
kind: Template
metadata:
   name: <Name of template>
   annotations:
      description: <Description of Tag>
      iconClass: "icon-redis"
      tags: <Tages of image>
objects:
   - apiVersion: v1
   kind: Pod
   metadata:
      name: <Object Specification>
spec:
   containers:
      image: <Image Name>
      name: master
      ports:
      - containerPort: <Container port number>
         protocol: <Protocol>
labels:
   redis: <Communication Type>

身份驗證和授權

身份驗證

在 OpenShift 中,在配置主節點和客戶端結構時,主節點自帶 OAuth 伺服器的功能。OAuth 伺服器用於生成令牌,該令牌用於對 API 進行身份驗證。由於 OAuth 是主節點的預設設定,因此我們預設使用“允許所有”身份提供程式。存在不同的身份提供程式,可以在 /etc/openshift/master/master-config.yaml 中進行配置。

OAuth 中存在不同型別的身份提供程式。

  • 允許所有
  • 拒絕所有
  • HTPasswd
  • LDAP
  • 基本身份驗證

允許所有

apiVersion: v1
   kind: Pod
   metadata:
      name: redis-master
   spec:
      containers:
         image: dockerfile/redis
         name: master
      ports:
      - containerPort: 6379
         protocol: TCP
      oauthConfig:
      identityProviders:
      - name: my_allow_provider
         challenge: true
         login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

拒絕所有

apiVersion: v1
kind: Pod
metadata:
   name: redis-master
spec:
   containers:
      image: dockerfile/redis
   name: master
   ports:
   - containerPort: 6379
      protocol: TCP
   oauthConfig:
   identityProviders:
   - name: my_allow_provider
      challenge: true
      login: true
   provider:
      apiVersion: v1
      kind: DenyAllPasswordIdentityProvider

HTPasswd

為了使用 HTPasswd,我們需要首先在主節點機器上設定 Httpd-tools,然後以與其他身份提供程式相同的方式進行配置。

identityProviders:
   - name: my_htpasswd_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider

授權

授權是 OpenShift 主節點的一項功能,用於驗證使用者。這意味著它會檢查嘗試執行操作的使用者,以檢視該使用者是否有權對給定專案執行該操作。這有助於管理員控制對專案的訪問。

授權策略使用以下內容進行控制 −

  • 規則
  • 角色
  • 繫結

授權評估使用以下內容進行 −

  • 身份
  • 操作
  • 繫結

使用策略 −

  • 叢集策略
  • 本地策略

OpenShift - 入門

OpenShift 包含兩種建立和部署應用程式的方法,可以透過 GUI 或 CLI。在本章中,我們將使用 CLI 建立一個新應用程式。我們將使用 OC 客戶端與 OpenShift 環境通訊。

建立新應用程式

在 OpenShift 中,有三種建立新應用程式的方法。

  • 從原始碼
  • 從映象
  • 從模板

從原始碼

當我們嘗試從原始碼建立應用程式時,OpenShift 會查詢應該存在於儲存庫中的 Dockerfile,該檔案定義了應用程式構建流程。我們將使用 oc new-app 建立應用程式。

使用儲存庫時首先要記住的是,它應該指向儲存庫中的一個源,OpenShift 將從中拉取程式碼並構建它。

如果倉庫克隆在安裝了 OC 客戶端的 Docker 機器上,並且使用者位於同一目錄下,則可以使用以下命令建立它。

$ oc new-app . <Hear. Denotes current working directory>

以下是嘗試從遠端倉庫構建特定分支的示例。

$ oc new-app https://github.com/openshift/Testing-deployment.git#test1

這裡,test1 是我們嘗試在 OpenShift 中建立新應用程式的分支。

在倉庫中指定 Docker 檔案時,我們需要定義如下所示的構建策略。

$ oc new-app OpenShift/OpenShift-test~https://github.com/openshift/Testingdeployment.git

從映象

在使用映象構建應用程式時,映象存在於本地 Docker 伺服器、內部託管的 Docker 倉庫或 Docker Hub 上。使用者只需要確保能夠無問題地從 Hub 拉取映象。

OpenShift 能夠確定使用的源,無論是 Docker 映象還是源流。但是,如果使用者希望,他可以明確定義它是映象流還是 Docker 映象。

$ oc new-app - - docker-image tomcat

使用映象流 -

$ oc new-app tomcat:v1

從模板

模板可用於建立新的應用程式。它可以是已有的模板,也可以是建立新的模板。

以下 YAML 檔案基本上是一個可用於部署的模板。

apiVersion: v1
kind: Template
metadata:
   name: <Name of template>
   annotations:
      description: <Description of Tag>
      iconClass: "icon-redis"
      tags: <Tages of image>
objects:
   - apiVersion: v1
   kind: Pod
   metadata:
      name: <Object Specification>
spec:
   containers:
      image: <Image Name>
      name: master
      ports:
      - containerPort: <Container port number>
         protocol: <Protocol>
labels:
   redis: <Communication Type>

開發和部署 Web 應用程式

在 OpenShift 中開發新應用程式

為了在 OpenShift 中建立新應用程式,我們必須編寫新的應用程式程式碼並使用 OpenShift OC 構建命令進行構建。如前所述,我們有多種建立新映象的方法。在這裡,我們將使用模板來構建應用程式。此模板將在使用 oc new-app 命令執行時構建新應用程式。

以下模板將建立 - 兩個前端應用程式和一個數據庫。此外,它將建立兩個新服務,並且這些應用程式將部署到 OpenShift 叢集。在構建和部署應用程式時,最初我們需要在 OpenShift 中建立一個名稱空間並在該名稱空間下部署應用程式。

建立一個新的名稱空間

$ oc new-project openshift-test --display-name = "OpenShift 3 Sample" --
description = "This is an example project to demonstrate OpenShift v3"

模板

{
   "kind": "Template",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-helloworld-sample",
      "creationTimestamp": null,
         "annotations": {
         "description": "This example shows how to create a simple openshift
         application in openshift origin v3",
         "iconClass": "icon-openshift",
         "tags": "instant-app,openshift,mysql"
      }
   }
},

物件定義

模板中的金鑰定義

"objects": [
{
   "kind": "Secret",
   "apiVersion": "v1",
   "metadata": {"name": "dbsecret"},
   "stringData" : {
      "mysql-user" : "${MYSQL_USER}",
      "mysql-password" : "${MYSQL_PASSWORD}"
   }
},

模板中的服務定義

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   },
   "spec": {
      "ports": [
         {
            "name": "web",
            "protocol": "TCP",
            "port": 5432,
            "targetPort": 8080,
            "nodePort": 0
         }
      ],
      "selector": {"name": "frontend"},
      "type": "ClusterIP",
      "sessionAffinity": "None"
   },
   "status": {
      "loadBalancer": {}
   }
},

模板中的路由定義

{
   "kind": "Route",
   "apiVersion": "v1",
   "metadata": {
      "name": "route-edge",
      "creationTimestamp": null,
      "annotations": {
         "template.openshift.io/expose-uri": "http://{.spec.host}{.spec.path}"
      }
   },
   "spec": {
      "host": "www.example.com",
      "to": {
         "kind": "Service",
         "name": "frontend"
      },
      "tls": {
         "termination": "edge"
      }
   },
   "status": {}
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "origin-openshift-sample",
      "creationTimestamp": null
   },
   "spec": {},
   "status": {
      "dockerImageRepository": ""
   }
},
{ 
   "kind": "ImageStream",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-22-ubuntu7",
      "creationTimestamp": null 
   },
   "spec": {
      "dockerImageRepository": "ubuntu/openshift-22-ubuntu7"
   },
   "status": {
      "dockerImageRepository": ""
   }
},

模板中的構建配置定義

{
   "kind": "BuildConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "openshift-sample-build",
      "creationTimestamp": null,
      "labels": {name": "openshift-sample-build"}
   },
   "spec": {
      "triggers": [
         { "type": "GitHub",
            "github": {
            "secret": "secret101" } 
         },
         {
            "type": "Generic",
            "generic": {
               "secret": "secret101",
               "allowEnv": true } 
         },
         { 
            "type": "ImageChange",
            "imageChange": {} 
         },
         { "type": "ConfigChange”}
      ],
      "source": {
         "type": "Git",
         "git": {
            "uri": https://github.com/openshift/openshift-hello-world.git } 
      },
      "strategy": {
         "type": "Docker",
         "dockerStrategy": {
            "from": {
               "kind": "ImageStreamTag",
               "name": "openshift-22-ubuntu7:latest” 
            },
            "env": [
               {
                  "name": "EXAMPLE",
                  "value": "sample-app"
               } 
            ]
         }
      },
      "output": {
         "to": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      },
      "postCommit": {
         "args": ["bundle", "exec", "rake", "test"]
      },
      "status": {
         "lastVersion": 0
      }
   }
},

模板中的部署配置

"status": {
   "lastVersion": 0
}
{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "frontend",
      "creationTimestamp": null
   }
}, 
"spec": {
   "strategy": {
      "type": "Rolling",
      "rollingParams": {
         "updatePeriodSeconds": 1,
         "intervalSeconds": 1,
         "timeoutSeconds": 120,
         "pre": {
            "failurePolicy": "Abort",
            "execNewPod": {
               "command": [
                  "/bin/true"
               ],
               "env": [
                  { 
                     "name": "CUSTOM_VAR1",
                     "value": "custom_value1"
                  }
               ]
            }
         }
      }
   }
}
"triggers": [
   {
      "type": "ImageChange",
      "imageChangeParams": {
         "automatic": true,
         "containerNames": [
            "openshift-helloworld"
         ],
         "from": {
            "kind": "ImageStreamTag",
            "name": "origin-openshift-sample:latest"
         }
      }
   },
   {
      "type": "ConfigChange"
   }
],
"replicas": 2,
"selector": {
   "name": "frontend"
},
"template": {
   "metadata": {
      "creationTimestamp": null,
      "labels": {
         "name": "frontend"
      }
   },
   "spec": {
      "containers": [
         {
            "name": "openshift-helloworld",
            "image": "origin-openshift-sample",
            "ports": [
               { 
                  "containerPort": 8080,
                  "protocol": "TCP” 
               }
            ],
            "env": [
               {
                  "name": "MYSQL_USER",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-user"
                     }
                  }
               },
               {
                  "name": "MYSQL_PASSWORD",
                  "valueFrom": {
                     "secretKeyRef" : {
                        "name" : "dbsecret",
                        "key" : "mysql-password"
                     }
                  }
               },
               {
                  "name": "MYSQL_DATABASE",
                  "value": "${MYSQL_DATABASE}"
               }
            ],
            "resources": {},
            "terminationMessagePath": "/dev/termination-log",
            "imagePullPolicy": "IfNotPresent",
            "securityContext": {
               "capabilities": {},
               "privileged": false
            }
         }
      ],
      "restartPolicy": "Always",
      "dnsPolicy": "ClusterFirst"
   },
   "status": {}
},

模板中的服務定義

{
   "kind": "Service",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null 
   },
   "spec": {
   "ports": [
      {
         "name": "db",
         "protocol": "TCP",
         "port": 5434,
         "targetPort": 3306,
         "nodePort": 0
      } 
   ],
   "selector": {
      "name": "database 
   },
   "type": "ClusterIP",
   "sessionAffinity": "None" },
   "status": {
      "loadBalancer": {}
   }
},

模板中的部署配置定義

{
   "kind": "DeploymentConfig",
   "apiVersion": "v1",
   "metadata": {
      "name": "database",
      "creationTimestamp": null
   },
   "spec": {
      "strategy": {
         "type": "Recreate",
         "resources": {}
      },
      "triggers": [
         {
            "type": "ConfigChange"
         }
      ],
      "replicas": 1,
      "selector": {"name": "database"},
      "template": {
         "metadata": {
            "creationTimestamp": null,
            "labels": {"name": "database"}
         },
         "template": {
            "metadata": {
               "creationTimestamp": null,
               "labels": {
                  "name": "database"
               } 
            },
            "spec": {
               "containers": [
                  {
                     "name": "openshift-helloworld-database",
                     "image": "ubuntu/mysql-57-ubuntu7:latest",
                     "ports": [
                        {
                           "containerPort": 3306,
                           "protocol": "TCP" 
                        }
                     ],
                     "env": [
                        {
                           "name": "MYSQL_USER",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-user"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_PASSWORD",
                           "valueFrom": {
                              "secretKeyRef" : {
                                 "name" : "dbsecret",
                                 "key" : "mysql-password"
                              }
                           }
                        },
                        {
                           "name": "MYSQL_DATABASE",
                           "value": "${MYSQL_DATABASE}" 
                        } 
                     ],
                     "resources": {},
                     "volumeMounts": [
                        {
                           "name": "openshift-helloworld-data",
                           "mountPath": "/var/lib/mysql/data"
                        }
                     ],
                     "terminationMessagePath": "/dev/termination-log",
                     "imagePullPolicy": "Always",
                     "securityContext": {
                        "capabilities": {},
                        "privileged": false
                     } 
                  }
               ],
               "volumes": [
                  { 
                     "name": "openshift-helloworld-data",
                     "emptyDir": {"medium": ""} 
                  } 
               ],
               "restartPolicy": "Always",
               "dnsPolicy": "ClusterFirst” 
            } 
         }
      },
      "status": {} 
   },
   "parameters": [
      { 
         "name": "MYSQL_USER",
         "description": "database username",
         "generate": "expression",
         "from": "user[A-Z0-9]{3}",
         "required": true 
      },
      {
         "name": "MYSQL_PASSWORD",
         "description": "database password",
         "generate": "expression",
         "from": "[a-zA-Z0-9]{8}",
         "required": true
      }, 
      {
         "name": "MYSQL_DATABASE",
         "description": "database name",
         "value": "root",
         "required": true 
      } 
   ],
   "labels": {
      "template": "application-template-dockerbuild" 
   } 
}

上述模板檔案需要一次性編譯。我們需要先將所有內容複製到一個檔案中,並在完成後將其命名為 YAML 檔案。

我們需要執行以下命令來建立應用程式。

$ oc new-app application-template-stibuild.json
--> Deploying template openshift-helloworld-sample for "application-template-stibuild.json"

   openshift-helloworld-sample
   ---------
   This example shows how to create a simple ruby application in openshift origin v3
   * With parameters:
      * MYSQL_USER = userPJJ # generated
      * MYSQL_PASSWORD = cJHNK3se # generated
      * MYSQL_DATABASE = root

--> Creating resources with label app = ruby-helloworld-sample ...
   service "frontend" created
   route "route-edge" created
   imagestream "origin-ruby-sample" created
   imagestream "ruby-22-centos7" created
   buildconfig "ruby-sample-build" created
   deploymentconfig "frontend" created
   service "database" created
   deploymentconfig "database" created
   
--> Success
   Build scheduled, use 'oc logs -f bc/ruby-sample-build' to track its progress.
   Run 'oc status' to view your app.

如果我們希望監視構建,可以使用 -

$ oc get builds

NAME                        TYPE      FROM          STATUS     STARTED         DURATION
openshift-sample-build-1    Source   Git@bd94cbb    Running    7 seconds ago   7s

我們可以使用 - 檢查 OpenShift 上已部署的應用程式。

$ oc get pods
NAME                            READY   STATUS      RESTARTS   AGE
database-1-le4wx                1/1     Running     0          1m
frontend-1-e572n                1/1     Running     0          27s
frontend-1-votq4                1/1     Running     0          31s
opeshift-sample-build-1-build   0/1     Completed   0          1m

我們可以使用以下命令檢查應用程式服務是否根據服務定義建立。

$ oc get services
NAME        CLUSTER-IP      EXTERNAL-IP     PORT(S)      SELECTOR          AGE
database    172.30.80.39    <none>         5434/TCP     name=database      1m
frontend    172.30.17.4     <none>         5432/TCP     name=frontend      1m

OpenShift - 自動構建

在 OpenShift 中,我們有多種自動化構建管道的方法。為此,我們需要建立一個 BuildConfig 資源來描述構建流程。BuildConfig 中的流程可以與 Jenkins 作業定義中的作業定義進行比較。在建立構建流程時,我們必須選擇構建策略。

BuildConfig 檔案

在 OpenShift 中,BuildConfig 是一個用於連線 API 並建立新例項的 REST 物件。

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "<Name of build config file>"
spec:
   runPolicy: "Serial"
   triggers:
   -
      type: "GitHub"
      github:
         secret: "<Secrete file name>"
   - type: "Generic"
   generic:
      secret: "secret101"
   -
   type: "ImageChange"
   source:
      type: "<Source of code>"
      git:
   uri: "https://github.com/openshift/openshift-hello-world"
   dockerfile: "FROM openshift/openshift-22-centos7\nUSER example"
   strategy:
      type: "Source"
      
sourceStrategy:
   from:
      kind: "ImageStreamTag"
      name: "openshift-20-centos7:latest"
   output:
      to:
         kind: "ImageStreamTag"
         name: "origin-openshift-sample:latest"
   postCommit:
      script: "bundle exec rake test"

在 OpenShift 中,有四種類型的構建策略。

  • 源到映象策略
  • Docker 策略
  • 自定義策略
  • 管道策略

源到映象策略

允許從原始碼開始建立容器映象。在此流程中,實際程式碼首先下載到容器中,然後在其中進行編譯。編譯後的程式碼部署到同一個容器中,並從該程式碼構建映象。

strategy:
   type: "Source"
   sourceStrategy:
      from:
         kind: "ImageStreamTag"
         name: "builder-image:latest"
      forcePull: true

有多種策略策略。

  • 強制拉取
  • 增量構建
  • 外部構建

Docker 策略

在此流程中,OpenShift 使用 Dockerfile 構建映象,然後將建立的映象上傳到 Docker 倉庫。

strategy:
   type: Docker
   dockerStrategy:
      from:
         kind: "ImageStreamTag"
         name: "ubuntu:latest"

Docker 檔案選項可用於多個位置,從檔案路徑、無快取和強制拉取開始。

  • 從映象
  • Dockerfile 路徑
  • 無快取
  • 強制拉取

自定義策略

這是不同型別的構建策略之一,其中沒有強制要求構建的輸出將是映象。它可以比作 Jenkins 的自由風格作業。透過它,我們可以建立 Jar、rpm 和其他包。

strategy:
   type: "Custom"
   customStrategy:
      from:
         kind: "DockerImage"
         name: "openshift/sti-image-builder"

它包含多個構建策略。

  • 公開 Docker 套接字
  • 金鑰
  • 強制拉取

管道策略

管道策略用於建立自定義構建管道。這主要用於在管道中實現工作流。此構建流程使用 Groovy DSL 語言使用自定義構建管道流程。OpenShift 將在 Jenkins 中建立一個管道作業並執行它。此管道流程也可用於 Jenkins。在此策略中,我們使用 Jenkinsfile 並將其附加到構建配置定義中。

Strategy:
   type: "JenkinsPipeline"
   jenkinsPipelineStrategy:
   jenkinsfile: "node('agent') {\nstage 'build'\nopenshiftBuild(buildConfig: 'OpenShift-build', showBuildLogs: 'true')\nstage 'deploy'\nopenshiftDeploy(deploymentConfig: 'backend')\n}"

使用構建管道

kind: "BuildConfig"
apiVersion: "v1"
metadata:
   name: "test-pipeline"
spec:
   source:
      type: "Git"
      git:
         uri: "https://github.com/openshift/openshift-hello-world"
   strategy:
      type: "JenkinsPipeline"
      jenkinsPipelineStrategy:
         jenkinsfilePath: <file path repository>

OpenShift - CLI

OpenShift CLI 用於從命令列管理 OpenShift 應用程式。OpenShift CLI 能夠管理端到端應用程式生命週期。通常,我們將使用 OC(OpenShift 客戶端)與 OpenShift 通訊。

OpenShift CLI 設定

為了在不同的作業系統上設定 OC 客戶端,我們需要經歷不同的步驟序列。

Windows 版 OC 客戶端

步驟 1 - 從以下連結下載 oc cli https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

步驟 2 - 將包解壓縮到機器上的目標路徑。

步驟 3 - 編輯系統的路徑環境變數。

C:\Users\xxxxxxxx\xxxxxxxx>echo %PATH%

C:\oraclexe\app\oracle\product\10.2.0\server\bin;C:\Program Files 
(x86)\Intel\iCLS Client\;C:\Program Files\Intel\iCLS Client\;C:\Program Files 
(x86)\AMD APP\bin\x86_64;C:\Program Files (x86)\AMD APP\bin\x86;

C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\
v1.0\;C:\Program Files (x86)\Windows Live\Shared;C:\Program Files 
(x86)\ATI Technologies\ATI.ACE\C

ore-Static;C:\Program Files\Intel\Intel(R) Management Engine 
Components\DAL;C:\Program Files\Intel\Intel(R) Management Engine 
Components\IPT;C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL;

步驟 4 - 驗證 Windows 上的 OC 設定。

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc version
oc v3.6.0-alpha.2+3c221d5
kubernetes v1.6.1+5115d708d7
features: Basic-Auth

Mac OS X 版 OC 客戶端

我們可以從與 Windows 相同的位置下載 Mac OS 設定二進位制檔案,然後將其解壓縮到某個位置,並在環境 PATH 變數下設定可執行檔案的路徑。

或者

我們可以使用 Home brew 並使用以下命令進行設定。

$ brew install openshift-cli

Linux 版 OC 客戶端

在同一頁面上,我們有用於 Linux 安裝的 tar 檔案,可用於安裝。之後,可以設定一個路徑變數指向該特定可執行檔案位置。

https://github.com/openshift/origin/releases/tag/v3.6.0-alpha.2

使用以下命令解壓縮 tar 檔案。

$ tar –xf < path to the OC setup tar file >

執行以下命令以檢查身份驗證。

C:\openshift-origin-client-tools-v3.6.0-alpha.2-3c221d5-windows>oc login
Server [https://:8443]:

CLI 配置檔案

OC CLI 配置檔案用於管理多個 OpenShift 伺服器連線和身份驗證機制。此配置檔案還用於儲存和管理多個配置檔案以及在它們之間切換。一個普通的配置檔案如下所示。

$ oc config view
apiVersion: v1
clusters:
   - cluster:
      server: https://vklnld908.int.example.com
   name: openshift
   
contexts:
- context:
   cluster: openshift
   namespace: testproject
   user: alice
   name: alice
current-context: alice
kind: Config
preferences: {}
users:
- name: vipin
   user:
      token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

設定 CLI 客戶端

用於設定使用者憑據

$ oc config set-credentials <user_nickname>
[--client-certificate = <path/to/certfile>] [--client-key=<path/to/keyfile>]
[--token = <bearer_token>] [--username = <basic_user>] [--password = <basic_password>]

用於設定叢集

$ oc config set-cluster <cluster_nickname> [--server = <master_ip_or_fqdn>]
[--certificate-authority = <path/to/certificate/authority>]
[--api-version = <apiversion>] [--insecure-skip-tls-verify = true]

示例

$ oc config set-credentials vipin --token = ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

用於設定上下文

$ oc config set-context <context_nickname> [--cluster = <cluster_nickname>]
[--user = <user_nickname>] [--namespace = <namespace>]

CLI 配置檔案

在一個 CLI 配置檔案中,我們可以有多個配置檔案,其中每個配置檔案都有不同的 OpenShift 伺服器配置,之後可用於在不同的 CLI 配置檔案之間切換。

apiVersion: v1
clusters: --→ 1
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld908.int.example.com:8443
   name: vklnld908.int.example.com:8443
- cluster:
   insecure-skip-tls-verify: true
   server: https://vklnld1446.int.example.com:8443
   name: vklnld1446.int.example.com:8443
contexts: ---→ 2
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: openshift-project
   user: vipin/vklnld908.int.example.com:8443
   name: openshift-project/vklnld908.int.example.com:8443/vipin
- context:
   cluster: vklnld908.int.example.com:8443
   namespace: testing-project
   user: alim/vklnld908.int.example.com:8443
   name: testproject-project/openshift1/alim
current-context: testing-project/vklnld908.int.example.com:8443/vipin - 3
kind: Config
preferences: {}

users:
- name: vipin/vklnld908.int.example.com:8443
user: ---→ 4
   token: ZCJKML2365jhdfafsdj797GkjgjGKJKJGjkg232

在上述配置中,我們可以看到它分為四個主要部分,從定義兩個 OpenShift 主機的例項的叢集開始。第二個上下文部分定義了兩個名為 vipin 和 alim 的上下文。當前上下文定義了當前正在使用的上下文。如果我們在此處更改定義,則可以將其更改為其他上下文或配置檔案。最後,定義了使用者定義及其身份驗證令牌,在本例中為 vipin。

如果我們想檢查當前正在使用的配置檔案,可以使用 - 進行檢查。

$ oc status
oc status
In project testing Project (testing-project)
$ oc project
Using project "testing-project" from context named "testing-
project/vklnld908.int.example.com:8443/vipin" on server "https://vklnld908.int.example.com:8443".

如果我們想切換到其他 CLI,可以使用以下命令從命令列進行切換。

$ oc project openshift-project
Now using project "Openshift-project" on server "
https://vklnld908.int.example.com:8443".

使用上述命令,我們可以在配置檔案之間切換。在任何時候,如果我們希望檢視配置,我們可以使用 $ oc config view 命令。

OpenShift - CLI 操作

OpenShift CLI 能夠執行所有基本和高階配置、管理、新增和應用程式部署。

我們可以使用 OC 命令執行不同型別的操作。此客戶端幫助您在任何與 OpenShift 或 Kubernetes 相容的平臺上開發、構建、部署和執行應用程式。它還包括用於在 'adm' 子命令下管理叢集的管理命令。

基本命令

下表列出了基本 OC 命令。

序號 命令和描述
1

型別

概念和型別的介紹

2

登入

登入伺服器

3

new-project

請求一個新的專案

4

new-app

建立一個新的應用程式

5

狀態

顯示當前專案的概述

6

專案

切換到另一個專案

7

專案

顯示現有專案

8

解釋

資源文件

9

叢集

啟動和停止 OpenShift 叢集

登入

登入到您的伺服器並儲存登入資訊以供後續使用。客戶端的新使用者應執行此命令以連線到伺服器,建立經過身份驗證的會話並將連線儲存到配置檔案。預設配置將儲存在您主目錄下的“.kube/config”中。

登入所需的資訊(例如使用者名稱和密碼、會話令牌或伺服器詳細資訊)可以透過標誌提供。如果未提供,則命令將根據需要提示使用者輸入。

用法

oc login [URL] [options]

示例

# Log in interactively
oc login

# Log in to the given server with the given certificate authority file
oc login localhost:8443 --certificate-authority = /path/to/cert.crt

# Log in to the given server with the given credentials (will not prompt interactively)
oc login localhost:8443 --username = myuser --password=mypass

選項 -

-p, --password = " - 密碼,如果未提供將提示輸入

-u, --username = " - 使用者名稱,如果未提供將提示輸入

--certificate-authority = " - 證書頒發機構的證書檔案的路徑

--insecure-skip-tls-verify = false - 如果為真,則不會檢查伺服器證書的有效性。這將使您的 HTTPS 連線不安全

--token = " - 用於對 API 伺服器進行身份驗證的承載令牌

要獲取有關任何命令的完整詳細資訊,請使用oc <命令名稱> --help命令。

構建和部署命令

下表列出了構建和部署命令。

序號 命令和描述
1

推出

管理 Kubernetes 部署或 OpenShift 部署

2

部署

檢視、啟動、取消或重試部署

3

回滾

將應用程式的一部分恢復到以前的狀態

4

new-build

建立一個新的構建配置

5

start-build

啟動一個新的構建

6

cancel-build

取消正在執行、掛起或新的構建

7

import-image

從 Docker 倉庫匯入映象

8

標籤

將現有映象標記到映象流中

應用程式管理命令

下表列出了應用程式管理命令。

序號 命令和描述
1

獲取

顯示一個或多個資源

2

描述

顯示特定資源或一組資源的詳細資訊

3

編輯

編輯伺服器上的資源

4

設定

有助於在物件上設定特定功能的命令

5

標籤

更新資源上的標籤

6

註釋

更新資源上的註釋

7

公開

將複製的應用程式公開為服務或路由

8

刪除

刪除一個或多個資源

9

縮放

更改部署中的 Pod 數量

10

自動縮放

自動縮放部署配置、部署、複製控制器或副本集

11

金鑰

管理金鑰

12

服務帳戶

管理專案中的服務帳戶

故障排除和除錯命令

下表列出了故障排除和除錯命令。

序號 命令和描述
1

日誌

列印資源的日誌

2

Rsh

在 Pod 中啟動 Shell 會話

3

Rsync

在本地檔案系統和 Pod 之間複製檔案

4

埠轉發

將一個或多個本地埠轉發到 Pod

5

除錯

啟動 Pod 的新例項以進行除錯

6

執行

在容器中執行命令

7

代理

執行到 Kubernetes API 伺服器的代理

9

附加

附加到正在執行的容器

10

執行

在叢集上執行特定映象

11

Cp

複製檔案和目錄到容器或從容器複製檔案和目錄

高階命令

下表列出了高階命令。

序號 命令和描述
1

adm

用於管理叢集的工具

2

create

透過檔名或標準輸入建立資源

3

replace

透過檔名或標準輸入替換資源

4

apply

透過檔名或標準輸入將配置應用於資源

5

patch

使用策略性合併補丁更新資源的欄位

6

process

將模板處理成資源列表

7

export

匯出資源以便在其他地方使用

8

extract

將金鑰或配置對映提取到磁碟

9

idle

使可擴充套件資源空閒

10

observe

觀察資源的變化並對其做出反應(實驗性)

11

policy

管理授權策略

12

auth

檢查授權

13

convert

在不同的API版本之間轉換配置檔案

14

import

匯入應用程式的命令

設定命令

下表列出了設定命令。

序號 命令和描述
1

Logout

結束當前伺服器會話

2

Config

更改客戶端的配置檔案

3

Whoami

返回有關當前會話的資訊

4

Completion

為指定的shell(bash或zsh)輸出shell補全程式碼

OpenShift - 叢集

OpenShift使用兩種安裝方法來設定OpenShift叢集。

  • 快速安裝方法
  • 高階配置方法

設定叢集

快速安裝方法

此方法用於執行快速未經人工干預的叢集設定配置。為了使用此方法,我們需要首先安裝安裝程式。這可以透過執行以下命令來完成。

互動式方法

$ atomic-openshift-installer install

當希望執行互動式設定時,此方法很有用。

無人值守安裝方法

此方法用於希望設定無人值守的安裝方法時,使用者可以在~/.config/openshift/下定義一個配置yaml檔案並將其命名為installer.cfg.yml。然後,可以執行以下命令來安裝–u標籤

$ atomic-openshift-installer –u install

預設情況下,它使用位於~/.config/openshift/下的配置檔案。另一方面,Ansible用作安裝的備份。

version: v2
variant: openshift-enterprise
variant_version: 3.1
ansible_log_path: /tmp/ansible.log

deployment:
   ansible_ssh_user: root
   hosts:
   - ip: 172.10.10.1
   hostname: vklnld908.int.example.com
   public_ip: 24.222.0.1
   public_hostname: master.example.com
   roles:
      - master
      - node
   containerized: true
   connect_to: 24.222.0.1
   
   - ip: 172.10.10.2
   hostname: vklnld1446.int.example.com
   public_ip: 24.222.0.2
   public_hostname: node1.example.com
   roles:
      - node
   connect_to: 10.0.0.2
   
   - ip: 172.10.10.3
   hostname: vklnld1447.int.example.com
   public_ip: 10..22.2.3
   public_hostname: node2.example.com
   roles:
      - node
   connect_to: 10.0.0.3

roles:
   master:
      <variable_name1>: "<value1>"
      <variable_name2>: "<value2>"
   node:
      <variable_name1>: "<value1>"

這裡,我們有特定於角色的變數,如果希望設定一些特定變數,可以定義這些變數。

完成後,我們可以使用以下命令驗證安裝。

$ oc get nodes
NAME                    STATUS    AGE
master.example.com      Ready     10d
node1.example.com       Ready     10d
node2.example.com       Ready     10d

高階安裝

高階安裝完全基於Ansible配置,其中包含有關主節點和節點配置的完整主機配置和變數定義。這包含有關配置的所有詳細資訊。

一旦我們完成了設定並且劇本準備就緒,我們只需執行以下命令即可設定叢集。

$ ansible-playbook -i inventry/hosts ~/openshift-ansible/playbooks/byo/config.yml

向叢集新增主機

我們可以使用以下方法將主機新增到叢集中:

  • 快速安裝程式工具
  • 高階配置方法

快速安裝程式工具在互動模式和非互動模式下均有效。使用以下命令。

$ atomic-openshift-installer -u -c </path/to/file> scaleup

應用程式配置檔案的縮放格式可以用於新增主節點和節點。

高階配置方法

在此方法中,我們更新Ansible的主機檔案,然後在此檔案中新增新的節點或伺服器詳細資訊。配置檔案如下所示。

[OSEv3:children]
masters
nodes
new_nodes
new_master

在同一個Ansible主機檔案中,新增有關新節點的變數詳細資訊,如下所示。

[new_nodes]
vklnld1448.int.example.com openshift_node_labels = "{'region': 'primary', 'zone': 'east'}"

最後,使用更新的主機檔案,執行新配置並呼叫配置檔案以使用以下命令完成設定。

$ ansible-playbook -i /inventory/hosts /usr/share/ansible/openshift-ansible/playbooks/test/openshift-node/scaleup.yml

管理叢集日誌

OpenShift叢集日誌只不過是從叢集的主節點和節點機器生成的日誌。這些可以管理任何型別的日誌,從伺服器日誌、主節點日誌、容器日誌、Pod日誌等。有多種技術和應用程式可用於容器日誌管理。

列出了可以實現日誌管理的一些工具。

  • Fluentd
  • ELK
  • Kabna
  • Nagios
  • Splunk

ELK棧- 在嘗試從所有節點收集日誌並以系統格式呈現它們時,此棧很有用。ELK棧主要分為三大類。

ElasticSearch- 主要負責從所有容器收集資訊並將其放入中心位置。

Fluentd- 用於將收集的日誌饋送到elasticsearch容器引擎。

Kibana- 用於以圖形介面形式將收集的資料作為有用的資訊呈現的圖形介面。

需要注意的一點是,當此系統部署在叢集上時,它會開始從所有節點收集日誌。

日誌診斷

OpenShift有一個內建的oc adm dignostics命令與OC一起使用,可以用於分析多種錯誤情況。此工具可以由叢集管理員從主節點使用。此實用程式在故障排除和診斷已知問題方面非常有用。它在主節點客戶端和節點上執行。

如果沒有任何引數或標誌執行,它將查詢客戶端、伺服器和節點機器的配置檔案,並將其用於診斷。可以透過傳遞以下引數單獨執行診斷:

  • AggregatedLogging
  • AnalyzeLogs
  • ClusterRegistry
  • ClusterRoleBindings
  • ClusterRoles
  • ClusterRouter
  • ConfigContexts
  • DiagnosticPod
  • MasterConfigCheck
  • MasterNode
  • MetricsApiProxy
  • NetworkCheck
  • NodeConfigCheck
  • NodeDefinitions
  • ServiceExternalIPs
  • UnitStatus

可以簡單地使用以下命令執行它們。

$ oc adm diagnostics <DiagnosticName>

升級叢集

叢集的升級涉及升級叢集中的多個內容,並使叢集更新為新的元件和升級。這包括:

  • 主節點元件的升級
  • 節點元件的升級
  • 策略的升級
  • 路由的升級
  • 映象流的升級

為了執行所有這些升級,我們需要首先準備好快速安裝程式或實用程式。為此,我們需要更新以下實用程式:

  • atomic-openshift-utils
  • atomic-openshift-excluder
  • atomic-openshift-docker-excluder
  • etcd包

在開始升級之前,我們需要備份主節點上的etcd,這可以透過使用以下命令來完成。

$ ETCD_DATA_DIR = /var/lib/origin/openshift.local.etcd
$ etcdctl backup \
   --data-dir $ETCD_DATA_DIR \
   --backup-dir $ETCD_DATA_DIR.bak.<date>

主節點元件的升級

在OpenShift主節點中,我們透過更新etcd檔案並然後轉到Docker來開始升級。最後,我們執行自動執行器以使叢集處於所需位置。但是,在開始升級之前,我們需要首先在每個主節點上啟用原子OpenShift包。這可以透過使用以下命令來完成。

步驟1- 刪除atomic-openshift包

$ atomic-openshift-excluder unexclude

步驟2- 升級所有主節點上的etcd。

$ yum update etcd

步驟3- 重新啟動etcd的服務並檢查它是否已成功啟動。

$ systemctl restart etcd
$ journalctl -r -u etcd

步驟4- 升級Docker包。

$ yum update docker

步驟5- 重新啟動Docker服務並檢查它是否已正確啟動。

$ systemctl restart docker
$ journalctl -r -u docker

步驟6- 完成後,使用以下命令重新啟動系統。

$ systemctl reboot
$ journalctl -r -u docker

步驟7- 最後,執行atomic-executer以將包重新新增到yum排除列表中。

$ atomic-openshift-excluder exclude

沒有強制升級策略的必要,只有在建議升級時才需要升級,這可以透過以下命令檢查。

$ oadm policy reconcile-cluster-roles

在大多數情況下,我們不需要更新策略定義。

節點元件的升級

主節點更新完成後,我們可以開始升級節點。需要注意的一點是,升級時間應該很短,以避免叢集出現任何問題。

步驟1- 從要執行升級的所有節點中刪除所有原子OpenShift包。

$ atomic-openshift-excluder unexclude

步驟2- 接下來,在升級前停用節點排程。

$ oadm manage-node <node name> --schedulable = false

步驟3- 將當前主機上的所有節點複製到其他主機。

$ oadm drain <node name> --force --delete-local-data --ignore-daemonsets

步驟4- 升級主機上的Docker設定。

$ yum update docker

步驟5- 重新啟動Docker服務,然後啟動Docker服務節點。

$systemctl restart docker
$ systemctl restart atomic-openshift-node

步驟6- 檢查兩者是否都已正確啟動。

$ journalctl -r -u atomic-openshift-node

步驟7- 升級完成後,重新啟動節點機器。

$ systemctl reboot
$ journalctl -r -u docker

步驟8- 重新啟用節點上的排程。

$ oadm manage-node <node> --schedulable.

步驟9- 執行atomic-openshift executer以將OpenShift包重新放到節點上。

$ atomic-openshift-excluder exclude

步驟10- 最後,檢查所有節點是否都可用。

$ oc get nodes

NAME                 STATUS   AGE
master.example.com   Ready    12d
node1.example.com    Ready    12d
node2.example.com    Ready    12d

OpenShift - 應用伸縮

自動擴充套件是OpenShift中的一項功能,其中部署的應用程式可以根據某些規範在需要時擴充套件和縮減。在OpenShift應用程式中,自動擴充套件也稱為Pod自動擴充套件。自動擴充套件型別如下所示。

垂直擴充套件

垂直擴充套件就是向單個機器新增越來越多的功能,這意味著新增更多的CPU和硬碟。這是OpenShift的舊方法,現在不受OpenShift版本的支援。

水平擴充套件

當需要透過增加機器數量來處理更多請求時,此型別的擴充套件很有用。

在OpenShift中,有兩種啟用擴充套件功能的方法

  • 使用部署配置檔案
  • 執行映象時

使用部署配置檔案

在此方法中,擴充套件功能透過部署配置yaml檔案啟用。為此,OC自動擴充套件命令與副本的最小值和最大值一起使用,這些副本需要在叢集的任何給定時間點執行。我們需要一個物件定義來建立自動擴充套件器。以下是Pod自動擴充套件器定義檔案的示例。

apiVersion: extensions/v1beta1
kind: HorizontalPodAutoscaler
metadata:
   name: database
spec:
   scaleRef:
      kind: DeploymentConfig
      name: database
      apiVersion: v1
      subresource: scale
   minReplicas: 1
   maxReplicas: 10
   cpuUtilization:
      targetPercentage: 80

一旦我們有了檔案,我們需要以yaml格式儲存它並執行以下命令進行部署。

$ oc create –f <file name>.yaml

執行映象時

也可以在沒有yaml檔案的情況下使用以下oc autoscale命令在oc命令列中進行自動擴充套件。

$ oc autoscale dc/database --min 1 --max 5 --cpu-percent = 75
deploymentconfig "database" autoscaled

此命令也會生成類似的檔案,以後可以將其用作參考。

OpenShift中的部署策略

OpenShift中的部署策略定義了具有不同可用方法的部署流程。在OpenShift中,以下是重要的部署策略型別

  • 滾動策略
  • 重新建立策略
  • 自定義策略

以下是一個部署配置檔案的示例,該檔案主要用於在OpenShift節點上進行部署。

kind: "DeploymentConfig"
apiVersion: "v1"
metadata:
   name: "database"
spec:
   template:
      metadata:
         labels:
            name: "Database1"
spec:
   containers:
      - name: "vipinopenshifttest"
         image: "openshift/mongoDB"
         ports:
            - containerPort: 8080
               protocol: "TCP"
replicas: 5
selector:
   name: "database"
triggers:
- type: "ConfigChange"
- type: "ImageChange"
   imageChangeParams:
      automatic: true
      containerNames:
         - "vipinopenshifttest"
      from:
         kind: "ImageStreamTag"
         name: "mongoDB:latest"
   strategy:
      type: "Rolling"

在上面的Deploymentconfig檔案中,我們的策略為Rolling。

我們可以使用以下OC命令進行部署。

$ oc deploy <deployment_config> --latest

滾動策略

滾動策略用於滾動更新或部署。此過程還支援生命週期鉤子,用於將程式碼注入任何部署流程。

strategy:
   type: Rolling
   rollingParams:
      timeoutSeconds: <time in seconds>
      maxSurge: "<definition in %>"
      maxUnavailable: "<Defintion in %>"
      pre: {}
      post: {}

重新建立策略

此部署策略具有滾動部署策略的一些基本功能,並且還支援生命週期鉤子。

strategy:
   type: Recreate
   recreateParams:
      pre: {}
      mid: {}
      post: {}

自定義策略

當用戶希望提供自己的部署流程或流程時,這非常有用。所有自定義都可以根據需要進行。

strategy:
   type: Custom
   customParams:
      image: organization/mongoDB
      command: [ "ls -l", "$HOME" ]
      environment:
         - name: VipinOpenshiftteat
         value: Dev1

OpenShift - 管理

在本章中,我們將涵蓋如何管理節點、配置服務帳戶等主題。

主節點和節點配置

在 OpenShift 中,我們需要使用 `start` 命令以及 `oc` 來啟動新的伺服器。在啟動新的主節點時,我們需要使用 `master` 以及 `start` 命令,而在啟動新節點時,我們需要使用 `node` 以及 `start` 命令。為了做到這一點,我們需要為主節點和節點建立配置檔案。我們可以使用以下命令為主節點和節點建立一個基本配置檔案。

主節點配置檔案

$ openshift start master --write-config = /openshift.local.config/master

節點配置檔案

$ oadm create-node-config --node-dir = /openshift.local.config/node-<node_hostname> --node = <node_hostname> --hostnames = <hostname>,<ip_address>

執行以下命令後,我們將獲得可作為配置起點的基本配置檔案。稍後,我們可以使用相同的配置檔案來啟動新伺服器。

apiLevels:
- v1beta3
- v1
apiVersion: v1
assetConfig:
   logoutURL: ""
   masterPublicURL: https://172.10.12.1:7449
   publicURL: https://172.10.2.2:7449/console/
      servingInfo:
         bindAddress: 0.0.0.0:7449
         certFile: master.server.crt
         clientCA: ""
keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 0
controllers: '*'
corsAllowedOrigins:
- 172.10.2.2:7449
- 127.0.0.1
- localhost
dnsConfig:
   bindAddress: 0.0.0.0:53
etcdClientInfo:
   ca: ca.crt
   certFile: master.etcd-client.crt
   keyFile: master.etcd-client.key
   urls:
   - https://10.0.2.15:4001
etcdConfig:
   address: 10.0.2.15:4001
   peerAddress: 10.0.2.15:7001
   peerServingInfo:
      bindAddress: 0.0.0.0:7001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   servingInfo:
      bindAddress: 0.0.0.0:4001
      certFile: etcd.server.crt
      clientCA: ca.crt
      keyFile: etcd.server.key
   storageDirectory: /root/openshift.local.etcd
etcdStorageConfig:
   kubernetesStoragePrefix: kubernetes.io
   kubernetesStorageVersion: v1
   openShiftStoragePrefix: openshift.io
   openShiftStorageVersion: v1
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: MasterConfig
kubeletClientInfo:
   ca: ca.crt
   certFile: master.kubelet-client.crt
   keyFile: master.kubelet-client.key
   port: 10250
kubernetesMasterConfig:
   apiLevels:
   - v1beta3
   - v1
   apiServerArguments: null
   controllerArguments: null
   masterCount: 1
   masterIP: 10.0.2.15
   podEvictionTimeout: 5m
   schedulerConfigFile: ""
   servicesNodePortRange: 30000-32767
   servicesSubnet: 172.30.0.0/16
   staticNodeNames: []
masterClients:
   externalKubernetesKubeConfig: ""
   openshiftLoopbackKubeConfig: openshift-master.kubeconfig
masterPublicURL: https://172.10.2.2:7449
networkConfig:
   clusterNetworkCIDR: 10.1.0.0/16
   hostSubnetLength: 8
   networkPluginName: ""
   serviceNetworkCIDR: 172.30.0.0/16
oauthConfig:
   assetPublicURL: https://172.10.2.2:7449/console/
   grantConfig:
      method: auto
   identityProviders:
   - challenge: true
   login: true
   name: anypassword
   provider:
      apiVersion: v1
      kind: AllowAllPasswordIdentityProvider
   masterPublicURL: https://172.10.2.2:7449/
   masterURL: https://172.10.2.2:7449/
   sessionConfig:
      sessionMaxAgeSeconds: 300
      sessionName: ssn
      sessionSecretsFile: ""
   tokenConfig:
      accessTokenMaxAgeSeconds: 86400
      authorizeTokenMaxAgeSeconds: 300
policyConfig:
   bootstrapPolicyFile: policy.json
   openshiftInfrastructureNamespace: openshift-infra
   openshiftSharedResourcesNamespace: openshift
projectConfig:
   defaultNodeSelector: ""
   projectRequestMessage: ""
   projectRequestTemplate: ""
   securityAllocator:
      mcsAllocatorRange: s0:/2
      mcsLabelsPerProject: 5
      uidAllocatorRange: 1000000000-1999999999/10000
routingConfig:
   subdomain: router.default.svc.cluster.local
serviceAccountConfig:
   managedNames:
   - default
   - builder
   - deployer
   
masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
servingInfo:
   bindAddress: 0.0.0.0:8443
   certFile: master.server.crt
   clientCA: ca.crt
   keyFile: master.server.key
   maxRequestsInFlight: 0
   requestTimeoutSeconds: 3600

節點配置檔案

allowDisabledDocker: true
apiVersion: v1
dnsDomain: cluster.local
dnsIP: 172.10.2.2
dockerConfig:
   execHandlerName: native
imageConfig:
   format: openshift/origin-${component}:${version}
   latest: false
kind: NodeConfig
masterKubeConfig: node.kubeconfig
networkConfig:
   mtu: 1450
   networkPluginName: ""
nodeIP: ""
nodeName: node1.example.com

podManifestConfig:
   path: "/path/to/pod-manifest-file"
   fileCheckIntervalSeconds: 30
servingInfo:
   bindAddress: 0.0.0.0:10250
   certFile: server.crt
   clientCA: node-client-ca.crt
   keyFile: server.key
volumeDirectory: /root/openshift.local.volumes

節點配置檔案看起來像這樣。一旦我們準備好這些配置檔案,就可以執行以下命令來建立主節點和節點伺服器。

$ openshift start --master-config = /openshift.local.config/master/master-
config.yaml --node-config = /openshift.local.config/node-<node_hostname>/node-
config.yaml

管理節點

在 OpenShift 中,我們有 `oc` 命令列實用程式,主要用於執行 OpenShift 中的所有操作。我們可以使用以下命令來管理節點。

列出節點

$ oc get nodes
NAME                             LABELS
node1.example.com     kubernetes.io/hostname = vklnld1446.int.example.com
node2.example.com     kubernetes.io/hostname = vklnld1447.int.example.com

描述節點詳細資訊

$ oc describe node <node name>

刪除節點

$ oc delete node <node name>

列出節點上的 Pod

$ oadm manage-node <node1> <node2> --list-pods [--pod-selector=<pod_selector>] [-o json|yaml]

評估節點上的 Pod

$ oadm manage-node <node1> <node2> --evacuate --dry-run [--pod-selector=<pod_selector>]

配置身份驗證

在 OpenShift 主節點中,有一個內建的 OAuth 伺服器,可用於管理身份驗證。所有 OpenShift 使用者都從該伺服器獲取令牌,這有助於他們與 OpenShift API 通訊。

OpenShift 中有不同型別的身份驗證級別,可以與主配置檔案一起配置。

  • 允許所有
  • 拒絕所有
  • HTPasswd
  • LDAP
  • 基本身份驗證
  • 請求頭

在定義主節點配置時,我們可以定義身份策略,在其中可以定義我們希望使用的策略型別。

允許所有

允許所有

oauthConfig:
   ...
   identityProviders:
   - name: Allow_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: AllowAllPasswordIdentityProvider

拒絕所有

這將拒絕所有使用者名稱和密碼的訪問。

oauthConfig:
   ...
   identityProviders:
   - name: deny_Authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: DenyAllPasswordIdentityProvider

HTPasswd

HTPasswd 用於根據加密的檔案密碼驗證使用者名稱和密碼。

要生成加密檔案,請使用以下命令。

$ htpasswd </path/to/users.htpasswd> <user_name>

使用加密檔案。

oauthConfig:
   ...
   identityProviders:
   - name: htpasswd_authontication
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: HTPasswdPasswordIdentityProvider
         file: /path/to/users.htpasswd

LDAP 身份提供程式

這用於 LDAP 身份驗證,其中 LDAP 伺服器在身份驗證中起關鍵作用。

oauthConfig:
   ...
   identityProviders:
   - name: "ldap_authontication"
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: LDAPPasswordIdentityProvider
         attributes:
            id:
            - dn
            email:
            - mail
            name:
            - cn
            preferredUsername:
            - uid
         bindDN: ""
         bindPassword: ""
         ca: my-ldap-ca-bundle.crt
         insecure: false
         url: "ldap://ldap.example.com/ou=users,dc=acme,dc=com?uid"

基本身份驗證

當用戶名和密碼的驗證針對伺服器到伺服器的身份驗證進行時,使用此方法。身份驗證在基本 URL 中受到保護,並以 JSON 格式呈現。

oauthConfig:
   ...
   identityProviders:
   - name: my_remote_basic_auth_provider
      challenge: true
      login: true
      provider:
         apiVersion: v1
         kind: BasicAuthPasswordIdentityProvider
         url: https://www.vklnld908.int.example.com/remote-idp
         ca: /path/to/ca.file
         certFile: /path/to/client.crt
         keyFile: /path/to/client.key

配置服務帳戶

服務帳戶提供了一種靈活的方式來訪問 OpenShift API,公開用於身份驗證的使用者名稱和密碼。

啟用服務帳戶

服務帳戶使用公鑰和私鑰對進行身份驗證。對 API 的身份驗證使用私鑰進行,並根據公鑰進行驗證。

ServiceAccountConfig:
   ...
   masterCA: ca.crt
   privateKeyFile: serviceaccounts.private.key
   publicKeyFiles:
   - serviceaccounts.public.key
   - ...

建立服務帳戶

使用以下命令建立服務帳戶

$ Openshift cli create service account <name of server account>

使用 HTTP 代理

在大多數生產環境中,對 Internet 的直接訪問受到限制。它們要麼未公開到 Internet,要麼透過 HTTP 或 HTTPS 代理公開。在 OpenShift 環境中,此代理機器定義設定為環境變數。

這可以透過在位於 **`/etc/sysconfig`** 下的主節點和節點檔案上新增代理定義來完成。這與我們對任何其他應用程式所做的類似。

主節點機器

/etc/sysconfig/openshift-master

HTTP_PROXY=http://USERNAME:PASSWORD@172.10.10.1:8080/
HTTPS_PROXY=https://USERNAME:PASSWORD@172.10.10.1:8080/
NO_PROXY=master.vklnld908.int.example.com

節點機器

/etc/sysconfig/openshift-node

HTTP_PROXY=http://USERNAME:PASSWORD@172.10.10.1:8080/
HTTPS_PROXY=https://USERNAME:PASSWORD@172.10.10.1:8080/
NO_PROXY=master.vklnld908.int.example.com

完成後,我們需要重新啟動主節點和節點機器。

用於 Docker 拉取

/etc/sysconfig/docker

HTTP_PROXY = http://USERNAME:PASSWORD@172.10.10.1:8080/
HTTPS_PROXY = https://USERNAME:PASSWORD@172.10.10.1:8080/
NO_PROXY = master.vklnld1446.int.example.com

為了使 Pod 在代理環境中執行,可以使用以下方法:

containers:
- env:
   - name: "HTTP_PROXY"
      value: "http://USER:PASSWORD@:10.0.1.1:8080"

可以使用 `oc env` 命令更新現有的環境變數。

OpenShift 使用 NFS 的儲存

在 OpenShift 中,持久卷和持久卷宣告的概念構成了持久儲存。這是關鍵概念之一,其中首先建立持久卷,然後宣告相同的卷。為此,我們需要在底層硬體上擁有足夠的容量和磁碟空間。

apiVersion: v1
kind: PersistentVolume
metadata:
   name: storage-unit1
spec:
   capacity:
      storage: 10Gi
   accessModes:
   - ReadWriteOnce
   nfs:
      path: /opt
      server: 10.12.2.2
   persistentVolumeReclaimPolicy: Recycle

接下來,使用 `oc create` 命令建立持久卷。

$ oc create -f storage-unit1.yaml

persistentvolume " storage-unit1 " created

宣告已建立的卷。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
   name: Storage-clame1
spec:
   accessModes:
      - ReadWriteOnce
   resources:
      requests:
         storage: 5Gi

建立宣告。

$ oc create -f Storage-claim1.yaml
persistentvolume " Storage-clame1 " created

使用者和角色管理

使用者和角色管理用於管理使用者、他們的訪問許可權以及對不同專案的控制。

建立使用者

可以使用預定義模板在 OpenShift 中建立新使用者。

kind: "Template"
apiVersion: "v1"
parameters:
   - name: vipin
   required: true
objects:
   - kind: "User"
   apiVersion: "v1"
   metadata:
   name: "${email}"
   
- kind: "Identity"
   apiVersion: "v1"
   metadata:
      name: "vipin:${email}"
   providerName: "SAML"
   providerUserName: "${email}"
- kind: "UserIdentityMapping"
apiVersion: "v1"
identity:
   name: "vipin:${email}"
user:
   name: "${email}"

使用 `oc create -f <檔名>` 建立使用者。

$ oc create –f vipin.yaml

使用以下命令刪除 OpenShift 中的使用者。

$ oc delete user <user name>

限制使用者訪問

ResourceQuotas 和 LimitRanges 用於限制使用者訪問級別。它們用於限制叢集上的 Pod 和容器。

apiVersion: v1
kind: ResourceQuota
metadata:
   name: resources-utilization
spec:
   hard:
      pods: "10"

使用以上配置建立配額

$ oc create -f resource-quota.yaml –n –Openshift-sample

描述資源配額

$ oc describe quota resource-quota  -n  Openshift-sample
Name:              resource-quota
Namespace:                              Openshift-sample
Resource           Used                  Hard
--------           ----                  ----
pods                3                    10

定義容器限制可用於限制已部署容器將使用的資源。它們用於定義某些物件的最大和最小限制。

使用者專案限制

這主要用於使用者在任何時間點可以擁有的專案數量。它們基本上是透過將使用者級別定義為青銅、白銀和黃金類別來完成的。

我們需要首先定義一個物件,該物件儲存青銅、白銀和黃金類別可以擁有的專案數量的值。這些需要在 `master-confif.yaml` 檔案中完成。

admissionConfig:
   pluginConfig:
      ProjectRequestLimit:
         configuration:
            apiVersion: v1
            kind: ProjectRequestLimitConfig
            limits:
            - selector:
               level: platinum
            - selector:
               level: gold
            maxProjects: 15
            - selector:
               level: silver
            maxProjects: 10
            - selector:
               level: bronze
            maxProjects: 5

重新啟動主節點伺服器。

將使用者分配到特定級別。

$ oc label user vipin level = gold

根據需要將使用者移出標籤。

$ oc label user <user_name> level-

向用戶新增角色。

$ oadm policy add-role-to-user  <user_name>

從使用者中刪除角色。

$ oadm policy remove-role-from-user  <user_name>

向用戶新增叢集角色。

$ oadm policy add-cluster-role-to-user  <user_name>

從使用者中刪除叢集角色。

$ oadm policy remove-cluster-role-from-user  <user_name>

向組新增角色。

$ oadm policy add-role-to-user  <user_name>

從組中刪除角色。

$ oadm policy remove-cluster-role-from-user  <user_name>

向組新增叢集角色。

$ oadm policy add-cluster-role-to-group  <groupname>

從組中刪除叢集角色。

$ oadm policy remove-cluster-role-from-group <role> <groupname>

叢集管理員使用者

這是最強大的角色之一,使用者能夠管理整個叢集,從建立到刪除叢集。

$ oadm policy add-role-to-user admin <user_name> -n <project_name>

擁有終極許可權的使用者

$ oadm policy add-cluster-role-to-user cluster-admin <user_name>

OpenShift - Docker 和 Kubernetes

OpenShift 建立在 Docker 和 Kubernetes 之上。所有容器都構建在 Docker 叢集之上,該叢集基本上是 Linux 機器上的 Kubernetes 服務,使用 Kubernetes 編排功能。

在此過程中,我們構建 Kubernetes 主節點,它控制所有節點並將容器部署到所有節點。Kubernetes 的主要功能是使用不同型別的配置檔案來控制 OpenShift 叢集和部署流程。與 Kubernetes 中使用 `kubectl` 的方式相同,我們使用 `oc` 命令列實用程式在叢集節點上構建和部署容器。

以下是用於在叢集中建立不同型別物件的不同型別的配置檔案。

  • 映象
  • Pod
  • 服務
  • 複製控制器
  • 副本集
  • 部署

映象

Kubernetes(Docker)映象是容器化基礎設施的關鍵構建塊。截至目前,Kubernetes 僅支援 **Docker** 映象。Pod 中的每個容器在其內部執行其 Docker 映象。

apiVersion: v1
kind: pod
metadata:
   name: Tesing_for_Image_pull -----------> 1
   spec:
   containers:
- name: neo4j-server ------------------------> 2
image: <Name of the Docker image>----------> 3
imagePullPolicy: Always ------------->4
command: [“echo”, “SUCCESS”] -------------------> 5

Pod

Pod 是 Kubernetes 叢集節點內容器及其儲存的集合。可以在其中建立一個包含多個容器的 Pod。以下是在同一 Pod 中保留資料庫容器和 Web 介面容器的示例。

apiVersion: v1
kind: Pod
metadata:
   name: Tomcat
spec:
   containers:
   - name: Tomcat
      image: tomcat: 8.0
      ports:
- containerPort: 7500
imagePullPolicy: Always

服務

服務可以定義為 Pod 的邏輯集合。它可以定義為 Pod 之上的抽象,它提供單個 IP 地址和 DNS 名稱,透過該名稱可以訪問 Pod。使用服務,可以很容易地管理負載均衡配置。它有助於 Pod 非常輕鬆地擴充套件。

apiVersion: v1
kind: Service
metadata:
   name: Tutorial_point_service
spec:
   ports:
   - port: 8080
      targetPort: 31999

複製控制器

複製控制器是 Kubernetes 的關鍵功能之一,負責管理 Pod 生命週期。它負責確保在任何時間點都執行指定數量的 Pod 副本。

apiVersion: v1
kind: ReplicationController
metadata:
   name: Tomcat-ReplicationController
spec:
   replicas: 3
   template:
   metadata:
      name: Tomcat-ReplicationController
   labels:
      app: App
      component: neo4j
   spec:
      containers:
      - name: Tomcat
      image: tomcat: 8.0
      ports:
      - containerPort: 7474

副本集

副本集確保應執行多少個 Pod 副本。它可以被視為複製控制器的替代品。

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   selector:
      matchLables:
      tier: Backend
   matchExpression:
      - { key: tier, operation: In, values: [Backend]}
   
   app: App
   component: neo4j
spec:
   containers:
   - name: Tomcat-
image: tomcat: 8.0
   ports:
containerPort: 7474

部署

部署是複製控制器的升級和更高版本。它們管理副本集的部署,副本集也是複製控制器的升級版本。它們能夠更新副本集,並且還能夠回滾到以前的版本。

apiVersion: extensions/v1beta1 --------------------->1
kind: Deployment --------------------------> 2
metadata:
   name: Tomcat-ReplicaSet
spec:
   replicas: 3
   template:
      metadata:
lables:
   app: Tomcat-ReplicaSet
   tier: Backend
spec:
   containers:
name: Tomcat-
   image: tomcat: 8.0
   ports:
   - containerPort: 7474

所有配置檔案都可以用於建立其各自的 Kubernetes 物件。

$ Kubectl create –f <file name>.yaml

以下命令可用於瞭解 Kubernetes 物件的詳細資訊和描述。

用於 Pod

$ Kubectl get pod <pod name>
$ kubectl delete pod <pod name>
$ kubectl describe pod <pod name>

用於複製控制器

$ Kubectl get rc <rc name>
$ kubectl delete rc <rc name>
$ kubectl describe rc <rc name>

用於服務

$ Kubectl get svc <svc name>
$ kubectl delete svc <svc name>
$ kubectl describe svc <svc name>

有關如何使用 Docker 和 Kubernetes 的更多詳細資訊,請訪問我們的 Kubernetes 教程,網址為:kubernetes

OpenShift - 安全性

OpenShift 安全性主要是兩個主要處理安全約束的元件的組合。

  • 安全上下文約束 (SCC)
  • 服務帳戶

安全上下文約束 (SCC)

它主要用於 Pod 限制,這意味著它定義了 Pod 的限制,例如它可以執行哪些操作以及它可以在叢集中訪問哪些內容。

OpenShift 提供了一組預定義的 SCC,管理員可以使用、修改和擴充套件這些 SCC。

$ oc get scc
NAME              PRIV   CAPS  HOSTDIR  SELINUX    RUNASUSER         FSGROUP   SUPGROUP  PRIORITY
anyuid            false   []   false    MustRunAs  RunAsAny          RunAsAny  RunAsAny  10
hostaccess        false   []   true     MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>
hostmount-anyuid  false   []   true     MustRunAs  RunAsAny          RunAsAny  RunAsAny  <none>
nonroot           false   []   false    MustRunAs  MustRunAsNonRoot  RunAsAny  RunAsAny  <none>
privileged        true    []   true     RunAsAny   RunAsAny          RunAsAny  RunAsAny  <none>
restricted        false   []   false    MustRunAs  MustRunAsRange    RunAsAny  RunAsAny  <none>

如果使用者希望使用任何預定義的 scc,可以透過簡單地將使用者或組新增到 scc 組來完成。

$ oadm policy add-user-to-scc <scc_name> <user_name>
$ oadm policy add-group-to-scc <scc_name> <group_name>

服務帳戶

服務帳戶主要用於控制對 OpenShift 主節點 API 的訪問,當從任何主節點或節點機器發出命令或請求時,該 API 會被呼叫。

任何時候,當應用程式或程序需要受限 SCC 未授予的功能時,您都必須建立一個特定的服務帳戶並將該帳戶新增到相應的 SCC。但是,如果 SCC 不符合您的要求,那麼最好建立滿足您特定要求的新 SCC,而不是使用最合適的 SCC。最後,將其設定為部署配置。

$ oc create serviceaccount Cadmin
$ oc adm policy add-scc-to-user vipin -z Cadmin

容器安全

在 OpenShift 中,容器的安全基於容器平臺的安全性以及容器執行位置的概念。當我們談論容器安全以及需要注意的事項時,會有很多事情需要考慮。

**映象來源** - 存在一個安全的標籤系統,用於準確且無可爭議地識別生產環境中執行的容器的來源。

**安全掃描** - 映象掃描程式會自動檢查所有映象是否存在已知的漏洞。

**審計** - 定期對生產環境進行審計,以確保所有容器都基於最新的容器,並且主機和容器都已安全配置。

**隔離和最小許可權** - 容器以有效執行所需的最低資源和許可權執行。它們無法過度干擾主機或其他容器。

執行時威脅檢測 - 一種在執行時檢測針對容器化應用程式的活動威脅並自動對其做出響應的功能。

訪問控制 - 使用 Linux 安全模組(例如 AppArmor 或 SELinux)來強制執行訪問控制。

容器安全可以通過幾種關鍵方法實現。

  • 透過 OAuth 控制訪問
  • 透過自助服務 Web 控制檯
  • 透過平臺證書

透過 OAuth 控制訪問

在這種方法中,透過獲取 OAuth 伺服器(內置於 OpenShift 主機)提供的安全令牌進行身份驗證來實現對 API 訪問的控制。作為管理員,您可以修改 OAuth 伺服器配置。

有關 OAuth 伺服器配置的更多詳細資訊,請參閱本教程的第 5 章。

透過自助服務 Web 控制檯

此 Web 控制檯安全功能內置於 OpenShift Web 控制檯中。此控制檯確保所有協同工作的團隊在未經身份驗證的情況下無法訪問其他環境。OpenShift 中的多租戶主節點具有以下安全功能:

  • 已啟用 TCL 層
  • 使用 x.509 證書進行身份驗證
  • 保護主節點上的 etcd 配置

透過平臺證書

在這種方法中,每個主機的證書在安裝期間透過 Ansible 進行配置。由於它透過 Rest API 使用 HTTPS 通訊協議,因此我們需要 TCL 安全連線到不同的元件和物件。這些是預定義的證書,但是,也可以在主節點叢集上安裝自定義證書以進行訪問。在主節點的初始設定期間,可以透過使用 **openshift_master_overwrite_named_certificates** 引數覆蓋現有證書來配置自定義證書。

示例

openshift_master_named_certificates = [{"certfile": "/path/on/host/to/master.crt", 
"keyfile": "/path/on/host/to/master.key", 
"cafile": "/path/on/host/to/mastercert.crt"}]

有關如何生成自定義證書的更多詳細資訊,請訪問以下連結:

https://www.linux.com/learn/creating-self-signed-ssl-certificates-apache-linux

網路安全

在 OpenShift 中,軟體定義網路 (SDN) 用於通訊。網路名稱空間用於叢集中的每個 Pod,其中每個 Pod 獲取自己的 IP 和一系列埠以在其上獲取網路流量。透過這種方法,可以隔離 Pod,因此它無法與其他專案中的 Pod 通訊。

隔離專案

叢集管理員可以透過從 CLI 使用以下 **oadm 命令**來實現此目的。

$ oadm pod-network isolate-projects <project name 1> <project name 2>

這意味著上面定義的專案無法與叢集中的其他專案通訊。

卷安全

卷安全明確表示保護 OpenShift 叢集中專案的 PV 和 PVC。在 OpenShift 中主要有四個部分來控制對卷的訪問。

  • 補充組
  • fsGroup
  • runAsUser
  • seLinuxOptions

補充組 - 補充組是常規的 Linux 組。當程序在系統中執行時,它以使用者 ID 和組 ID 執行。這些組用於控制對共享儲存的訪問。

使用以下命令檢查 NFS 掛載。

# showmount -e <nfs-server-ip-or-hostname>
Export list for f21-nfs.vm:
/opt/nfs *

使用以下命令檢查掛載伺服器上的 NFS 詳細資訊。

# cat /etc/exports
/opt/nfs *(rw,sync,no_root_squash)
...
# ls -lZ /opt/nfs -d
drwxrws---. nfsnobody 2325 unconfined_u:object_r:usr_t:s0 /opt/nfs
# id nfsnobody
uid = 65534(nfsnobody) gid = 454265(nfsnobody) groups = 454265(nfsnobody)

/opt/nfs/ 匯出可由 UID **454265** 和組 **2325** 訪問。

apiVersion: v1
kind: Pod
...
spec:
   containers:
   - name: ...
      volumeMounts:
      - name: nfs
         mountPath: /usr/share/...
   securityContext:
      supplementalGroups: [2325]
   volumes:
   - name: nfs
      nfs:
      server: <nfs_server_ip_or_host>
      path: /opt/nfs

fsGroup

fsGroup 代表檔案系統組,用於新增容器補充組。補充組 ID 用於共享儲存,而 fsGroup 用於塊儲存。

kind: Pod
spec:
   containers:
   - name: ...
   securityContext:
      fsGroup: 2325

runAsUser

runAsUser 使用使用者 ID 進行通訊。這用於在 Pod 定義中定義容器映象。如果需要,可以在所有容器中使用單個 ID 使用者。

執行容器時,將定義的 ID 與匯出上的所有者 ID 進行匹配。如果在外部定義了指定的 ID,則它對 Pod 中的所有容器都成為全域性的。如果它與特定 Pod 定義在一起,則它對單個容器具有特殊性。

spec:
   containers:
   - name: ...
      securityContext:
         runAsUser: 454265
廣告

© . All rights reserved.