OpenShift基本建置在Docker與Kubernetes management之上的平台(環境)
運用Docker image技術，快速建置可運行的主機與應用程式:
試想一下舊有的應用程式服務佈署方式
當開發者遞交已打包的程式如Java Jar或War時
要將Jar或War佈建在伺服器上該如何操作?
開啟實體或虛擬機台2min，將Jar佈署上去並運行1min
假設上述動作共要3分鐘
同樣的應用程式在Docker image技術應用下，完成上述動作大約剩10秒
2.K8s(Kubernetes) management技術應用:
同第一點Docker image的應用
而管理分配資源(記憶體 CPU...etc)調配就是Kubernetes management
在OpenShift架構下應用程式服務仍是生長在定義為Worker的Linux主機上
不同以往的點在於他是在Worker主機內部又生出一個主機來佈署應用程式
概念圖如下:
有一重點在於，不論哪一個內部應用程式主機
與實際的Worker主機本身斷開(無法取得Worker機本身的檔案資料)
但是內部應用程式主機佈建的應用程式主機間透過Dokcer技術可以互通網路
另外一個重點是同樣一個Jar或War可以透過K8s生成複數內部主機服務
以因應像電商面對雙11節日的流量衝擊
另外當內部某一主機刪除，該內部主機內的程式或產生的資料將全數消失
基礎機台配置:
BASION(堡壘機):大多數使用OpenShift的管理者，都於此機台下oc指令
infra:管理生長在worker機上的應用程式服務對外的網路接口
master:(開發者角度暫無相關操作，有部分關聯的應用程式平台生長於此)
logger:管理生長在worker機上的應用程式服務的相關console log
通常會使用kibana應用程式搜集log資訊至kibana的資料庫
worker:實際佈建一般開發者的應用程式服務的主機，如上面的概念圖
而且通常會很多台，並隨機佈建在一台
應用程式服務間網路為互通(不論長在哪一台Worker上)
但是無法通到Worker主機群之外的環境
OpenShift平台基本特殊(物件)關鍵字說明:
namespace:用以分類建置於OpenShift平台上的內部主機應用程式
其中有個特別的namespcae叫openshift是全域的namespace!
Pod:即內部主機與應用程式服務
route:連接Pod對外網路環境的通路
讓生於Worker機內部主機應用程式服務(上述的pod)的網路能到達對外環境
所開啟連至可對外接口infra機的道路
即一般電腦client端使用者無法直接調用pod上的API url
horizontal pod autoscaler(hpa):透過上面k8s管理技術
應用程式服務的image於什麼條件生成複數pod
buildConfig(bc):管理佈建pod的策略，pod怎麼建立
通常使用Source-to-Image (S2I)策略
deployConfig(dc):實際部署pod的設置
部署時dc本身也會長一個臨時性的pod來完成實際的應用程式的pod的部署
template:可選擇性使用的設置策略，依內容可簡化整個部署應用程式流程
通常會將其建立在openshift這個namespace內
之後其他namespcae都可以調用
