Red Hat展現雲端技術力 強勢助攻企業數位轉型
- 尤嘉禾／台北
-
隨著疫情蔓延，不僅造成線上雲端資安需求爆量，連帶刺激企業加速推動數位轉型。此一形勢迫使多數企業IT部門加快行動、積極規劃混合雲策略，期望在滿足公司業務服務所需資源之餘，也讓企業從雲原生技術得利，如願促進營運體質的強化。
為協助企業加速前進，Red Hat於日前特別舉辦「Red Hat Innovation Day雲端技術暨數位轉型解決方案」線上研討會，大舉鋪陳開放式混合雲基礎架構、自動化管理、雲端原生應用程式開發、高效能Linux、容器與Kubernetes等多項關鍵技術，期盼帶領企業IT從業人員提升雲端基礎架構與開發技能，躋身企業數位轉型的強力助攻手。
RHEL for Edge，助用戶迅速佈建邊緣運算節點
Red Hat首席資深解決方案架構經理游政杰率先開講，以「Red Hat Enterprise Linux(RHEL)的創新與演進」為題發表演說。他指出全球約有百萬個開源社群，有的歷史悠久、有的為後起之秀，如何從其中萃取創意精華、組合成對企業有利且易於安裝使用的方案，一直是Red Hat致力實現的願景。
Red Hat贊助一些社群，同樣秉持開源精神，免費提供廣大用戶使用其成果，並以此作為企業級方案的雛型，透過適當組成與驗證，若確認達到一定的穩定度，便啟動QA程序，將它轉變為商用產品，為客戶提供穩定生命週期保障與對應服務支持。像是Fedora，即屬於Red Hat贊助的社群。
另一為人熟知的CentOS社群，其實與Red Hat無直接關係，只是CentOS將RHEL的開放原始碼重新打包與編譯、形成自己的版本，提供眾多用戶使用。但不少用戶期望將一些源自CentOS的應用效益，轉移至Red Hat企業級產品，卻事與願違；因企業級產品講求穩固安全，不輕易採用未經測試的元件。
為此CentOS創立新的發行版本(Distribution)「CentOS Stream」，自我定位在Fedora之後、RHEL之前，不像CentOS處於價值鏈最下游，相對適合發展RHEL下一版本雛型。
游政杰解釋，每個開源版本皆有專注領域，Fedora發展RHEL下一個大版本，如Red Hat於5月發表最新版RHEL 9，Fedora就著手研發RHEL 10。CentOS Stream發展RHEL下一個小版本，如RHEL 8.6問世、CentOS Stream就發展RHEL 8.7雛型。反觀CentOS是RHEL追隨者，版本是切齊的，故對社群開發並無助益，CentOS Stream即可化解此問題，有望讓開源創新的反饋迴路(Feedback Loop)回歸正軌。
關於剛問世的RHEL 9，相較於RHEL 8有一些改變，例如SELinux的Disable方式出現調整；此外廢止SCP SSH拷貝檔案的指令，鼓勵用戶轉而採用SFTP。此外也有許多不變之處，包括提供長達10年的生命週期支援，並持續發展軟硬體認證生態，確保用戶在企業級應用中獲得最大支持。
值得一提，RHEL 9在安全性部份出現顯著優化，包含改善SSSD Logging、改善SELinux效能、整合最新OpenSSL 3、SSH預設允許禁止Root Login、停用SHA-1加密機制、運用新的 Cgroup 2來管控資源；此外支援subuid機制，以確保容器安全性。
至於RHEL 9內含的Kernal 5.14，亦有新功能，像是整合WireGuard輕量級VPN、支援最新加密機制與更快速的回應時間，同時還支援Core Scheduling功能，好處是幫助使用者進行更妥善的效能規劃與安排，也一併增強安全隔離、避免受到類似Spectre或Meltdown弱點影響。
RHEL可支援多種環境，包括x86、IBM Mainframe或Power System，並支持雲端環境、地端虛擬環境，甚至也開始支持Arm。另一方面，RHEL因應快速崛起的邊緣運算趨勢，順勢提供RHEL for Edge版本，標榜能做到零接觸部署，可藉由輕量方式、自動安裝完所有OS與相關設定；用戶亦可在RHEL for Edge上直接以容器方式部署應用程式，並藉由容器映像檔(Image)封裝的一致性，確保應用程式的部署趨於標準化，加速拓展到世界各角落。
另外RHEL 9以Podman作為容器Runtime，其中有一功能對管理者頗有助益，可針對容器執行Auto Update，若Update完卻出現問題，還可利用容器回撤機制加以補救，大幅減少人工維護時間與心力。Edge版OS本身也可像容器一樣運作，假使你需要做系統升級，可安裝另一映像檔在背景，避免影響Runtime，等到下次Reboot時，新的Runtime就會取代舊的Runtime，可確保Downtime最小化。
借助Ansible平台，輕鬆達成IT維運自動化
Red Hat資深解決方案架構師陳柏青強調，過去一年來，IT維運自動化已從「Nice to Have」躍升為「Must to Have」，重要性節節攀高。其中Ansible Automation Platform在整個企業IT自動化的應用也越來越廣泛，利用這個高效、簡單、易於分享個工具減少了IT日常維運負荷與提高重要工作執行時的安全性。
綜觀Red Hat Ansible的Playbook，主要內含Plays、Modules及Plugins三大角色。一個Playbook可以有許多Plays，Plays內含許多Task、即是我們希望腳本能幫忙執行的內容，當然也包含Modules、Plugins，這些都是組成Plays的重要元件。惟IT環境變化甚大，故企業會因應運行目標的不同，創建自己的模組與插件、在自己的平台上運行，倘若此腳本分享給其他用戶，往往會出現不匹配，為此Red Hat想出一個方法，將Modules和Plugins打包成為Collections，一個Collection連同腳本運行，會主動呼叫需要的模組與插件，以及此Collection的使用方法、測試方法。
陳柏青說，Collection由目錄形式組成，在檔案結構中置入Modules、Plugins、Role、Docs、Tests等素材，讓使用者輕鬆匯入並使用。顯見Collection極為重要，有助讓整個組織的自動化程度愈趨成熟與快速。企業除可自行編寫Collection裡的Modules或Plugins外，亦可取用社群寫好的Collection，或從Red Hat Automation Hub下載對於組織有必要性的Collection。
不可諱言，運行Collection仍需借助函式庫(Library)、Python程式，使用者須確保它們版本的統一化。此時可利用「Execution Environments」這樣的新概念，將所需Collection、Library、Runtime通通打包為一個容器映檔；如此就算接獲他人分享的Collection，也不必擔心因環境的Library或Code版本不同、導致運行腳本時發生狀況。
另外企業在創建自動化內容時，可利用幾項實用工具。首先是Ansible-Navigator，用於檢視Execution Environments內容，舉凡擁有哪些Collections、Inventories、Plugins，皆可透過指令來監看；它也可以運行一些Playbooks，將Playbooks指令簡化為「ansible-navigator run」來執行。其次為Ansible-Builder，可協助用戶收集設定好的Collections、Libraries、Codes，整合為一個Execution Environment。
活用Podman／Buildah／Skopeo，展開容器化旅程
Red Hat客戶技術經理廖偉翔表示，許多企業已體認容器為大勢所趨，但從傳統架構要轉到容器化，常會有的疑問是「要從哪裡開始？」從何跨出第一步確實是企業 IT 轉型上常見的疑問，如果容器化被形容是一段旅程，旅程可能有一個比較遠的、長期的目標，可能最終是要做到 Container Orchestration、上雲，或甚至到混合雲，但所有旅程總會有一個最初的起步點、跨出的第一步，因此藉由這個議程，分享如果企業內部已正在使用RHEL，如何在RHEL上透過Podman作為展開容器化旅程的起點。
Linux容器其實技術上就是Linux Process，但透過Namespace及Cgroup技術做到隔離環境與資源控管。它與VM的差異，在於不以一個個OS為單位，而以應用程式為單位，由於 是共用Kernel，故相對於VM有著更輕量化與節省資源的優點。
Linux Namespace 為Linux提供的Kernel級別環境隔離方法，透過PID、IPC、UTS、Mount、Network、User等不同類別的Namespace來做到不同類別的隔離，如果要比喻的話，假設Host為一間公寓，Namespace可以形容為房間，房間的人只能看到與使用到自己房內物品。
在透過Namespace做到隔離環境後，容器內的Process仍可能任意使用主機資源，可能衍生資源競爭並影響容器運行。此時即需一個容器資源控管機制，可由Linux Kernel的Control Group(Cgroup)功能來負責；Cgroup可限制Process使用的 CPU、記憶體、I/O 等資源，並執行優先層級的控制。如果使用同樣的公寓房間比喻的話，可以想像成是房間自來水或是用電量的這類資源的限制。
「千里之行，始於足下。假設您的組織已經在使用RHEL，您可利用RHEL搭配Podman開啟您容器化旅程的第一步。」廖偉翔說， Logo是「三隻小海豹」的Podman是由 Pod Manager簡稱而來，其中的Pod與Kubernetes(K8s)的Pod是一樣概念，可容納一或多個容器管理單位；Podman指令相容於Docker CLI，故熟悉Docker的用戶幾乎都能無縫銜接，但即便Podman與Docker操作方式一致，但底層運作架構則不同，相較於Docker，Podman有它的獨特優勢，包括「Rootless」，在建立容器時不一定需要 Root權限，有助提升系統安全，以及「Daemonless」，不需像Docker需要Daemon ，可直接呼叫OCI Runtime的RunC。
另外在RHEL上還有兩項搭配Podman的容器工具分別為為Buildah、Skopeo。Buildah可以用於創建容器映像檔，如透過from/run/copy/add/commmit指令，或從 Containerfiles或Dockerfiles建立容器映像檔。Skopeo則可用於查詢遠端映像檔的資訊。
雖然每個容器執行的應用程式彼此獨立、互不干擾，但Podman主要是在單台主機的使用情境，假設企業的使用需求較大、單機資源不敷使用，即需擴展主機，此時便亟需利用Orchestration(如Red Hat OpenShift、K8s)針對Multi-Node情境執行新舊資源的統合調度，不必耗時費工進行主機汰換。
而若企業已採用OpenShift或K8s，Podman是否即無用武之地？其實不然，Podman可將容器／Pod導出成K8s相容的YMAL檔，也可執行K8s YAML檔。換言之企業若有 OpenShift或K8s營運環境，開發人員即可使用Podman在本地開發容器內容與進行簡單測試，然後再Lift到K8s環境。
以一致的營運、部署與使用模式，實現極大化商業價值
擔綱壓軸講師的Red Hat資深全球顧問卓俊宇，闡述如何運用OpenShift在多雲環境實踐商業價值。他透露，曾有企業問到，公有雲上也有容器編排服務，相形之下OpenShift有何優勢？他將順勢揭曉箇中答案。
卓俊宇歸納，常見的雲環境有三。第一是混合雲，即雲地結合的情境，通常地端為核心中心，雲端是擴充中心，企業可利用雲擴展服務節點，允許突發性大流量進入，又能兼顧法遵與機敏資料保全需求。第二是多重雲，企業把雲視為商品，端看哪個平台便宜、或最能滿足所需功能，便考慮選用。第三是聚合雲(Poly Cloud)，象徵混合雲的專業化延伸，訴求一個應用服務可同時擷取不同公有雲的優點，如AWS的S3、Azure的AD、GCP的AI/ML，彙整多雲優勢來滿足企業當下業務目標。
談到為何以OpenShift執行雲策略？係因OpenShift提供彈性的產品模式，可適應各種雲策略。其應用方式包括：一、作為標準化容器平台，讓企業使用既有功能。二、採取託管模式，選項包括Red Hat OpenShift Dedicated、ARO(Azure Red Hat OpenShift)、ROSA(Red Hat OpenShift Service on AWS)等。三、啟用Red Hat OpenShift Platform Plus，較OpenShift標準版多出ACS與ACM兩項功能，後者作為中控管理系統，前者用於檢視環境的安全狀況。
上述三種方案皆可支援混合雲、多重雲、聚合雲不同架構，意謂用戶即使遷移新的雲環境，也不必學習操作新的管理工具，即可藉由OpenShift一以貫之，維持一致的營運、部署與使用方式。
深究OpenShift可望為企業帶來的商業價值，首先為「利潤增長」，讓企業加快至少30%的Time to Market速度，帶動盈利與市佔的同步增長。其次為「成本優化」：由於不管在什麼環境都能維持一致，讓用戶無需重新學習與適應，加上亦能促使企業策略或資產走向標準化與重用，故可減少建置與維運成本。
第三是「風險避免」，提供Compliance Operator工具，幫助企業監管所有應用的合規性，亦透過「6項流程＋12道工法」建構強力安全把關機制、嚴格確保上游開源軟體元件的安全性，另藉由標準化平台特質，協助企業消弭供應商鎖定(Vendor Locking)風險。第四為「達成策略目標」，主要藉由自動化、標準化功能及一致性體驗，減少企業IT人力資源的耗損，讓他們有餘力做更有價值的事情。
大致上來說，企業可藉由OpenShift化繁為簡，把任何想要連接的點、順暢地串連起來，實現最大化商業價值，並可準確地測量你的雲策略對商業目標所帶來的影響；更重要的，OpenShift讓企業獲取最具選擇性、保護性、平衡性的雲戰略科技，持續安全地擴展及執行現代化工作負載。
總括而論，本次線上論壇全面揭示開源技術創新的雲開發環境、營運管理及各大知名開源專案，從而透過這些前沿技術發展趨勢的分享，協助企業從容因應數位轉型挑戰，打造更高效、敏捷、彈性及安全的工作環境。
