Red Hat舉辦實機體驗營，助企業淬鍊現代化應用程式開發能力
- 尤嘉禾／台北
-
隨著數位浪潮持續推移，身為「創新者」的企業老闆，對於數位轉型難免產生愈來愈多的憧憬，期望藉由將應用轉移上雲，藉此享有前所未有的高擴充性、高可用性、降低成本…等效益，進而讓商業運轉得更為順暢。但身為下屬的「實踐者」，對於接踵而來的改變，卻懷抱著不安與恐懼。
儘管這些實踐者深知現今全球軟體開發都往雲原生、容器化、微服務化等路線靠攏，也明瞭必須落實這些基本功，才能滿足老闆心中的宏願。無奈礙於知識落差、抗拒一次性修改、生怕無法展現實際效益…等阻力，使得現代化應用開發進度載浮載沈，經過許久依然不符合老闆的期待。
為了幫助大家加速解決種種難題，Red Hat於日前舉辦「現代化應用開發實機體驗營」，透過迥異於一般研討會的獨特實踐體驗，既有資深講師闡釋企業組織如何善用Red Hat OpenShift Container Platform（RHOCP）與相關產品，順利在混合雲平台上展開現代化應用程式開發旅程；亦針對開發人員與技術專家，手把手提供實機體驗環境，讓學員們更加理解如何重構應用，並將新的應用程式部署至RHOCP，接著在RHOCP平台上實踐應用程式的持續整合／持續部署（CI/CD）。
OpenShift轉型平台，助企業暢遊雲原生旅程
Red Hat台灣資深解決方案架構師Michael Suen，率先登場講述「現代化應用開發概觀與趨勢」。他強調雲原生是轉型關鍵，而雲原生轉型平台的三大基石，涵蓋了「從瀑布型到CI／CD開發維運」、「從資料中心到任一雲」、「從單體式到微服務」。
至於容器之於雲原生的優勢，在於它能夠更高效地利用系統資源、更快的啟動速度、雲地一致的運行環境、持續交付與部署、更輕鬆的遷移，以及更輕鬆的維護與擴展。也就是說，雖然容器開發並非為了呼應上述三大基礎所應運而生的技術，但卻能完全美契合這些趨勢脈絡。
因此，企業可憑藉基於容器及Kubernetes（K8s）的混合雲策略，漸進式的上雲，以確保On-premise投資不會打水漂，且基於開源技術100%相容於產業標準規範；更重要的，企業可藉由一致的技術棧，維持相同的DevSecOps體驗，隨需橫跨不同的公有雲。
但企業也必須認知到，投入雲原生轉型，最迫切需要的是平台，而非工具；此轉型平台上既要有作業系統及基礎平台，同時也需要雲端管理和自動化系統、以及管理工具。Red Hat OpenShift不僅蘊含從底層到上層、從縱向到橫向等完整轉型平台要素，且一舉整合了大量適合企業容器平台的專案，因而能全面兼顧PaaS三種使用者角色「開發、維運、資安」的作業需求，讓他們在共同環境中無縫協作，齊力驅動CI／CD交付鏈的流暢運行。
現代化應用開發平台，不單是容器平台而已
Michael Suen接著說，企業轉型之所以需要借助雲原生平台，係因它蘊含了多重價值，可協企業一舉實現多重目的。首先是「現代化現行應用」，需要利用此先進開發平台來改進舊系統，以降低營運成本並縮短應用部署生命週期。其次是「部署新應用」，在保持安全性及高品質的前提下，讓新的應用服務和功能快速推陳出新。再者為「軟體供應鏈安全」，在整個建構、部署與運行過程中，能夠提供安全並保護應用服務。
第四是「持續部署」，採用一致且內建的安全防護機制，達到跨混合雲環境自動建構及交付應用服務。第五是「環境一致性」，可確保雲地一致的交付和營運模式。最後是「DevOps 平台」，利用自助的DevOps平台，建立開發者的應用服務開發交付體驗。
由此可見，足以全面涵蓋上述所有環節的OpenShift，並非只是Kubernetes（K8s），正確來說可以是K8s-powered應用平台。
主要是因為，一個完整的雲原生開發生命週期，必須能支持「賦能開發團隊」，意即自助開發平台、微服務開發語言、快速開發驗證體驗。換言之在大規模開發、構建、部署和運行容器應用的前提下，K8s僅是偌大平台當中的一個部分；亦可支持「自動化安全流水線」，支援持續整合及安全左移，並提供軟體安全及稽核紀錄；此外還要能「持續投入生產」，具有可追蹤的自動化部署、洞察應用及零信任實踐。
所以，一個完善的應用開發平台絕對不等於容器平台，另需要整合開發工具及服務，如此才能讓應用交付更加快速。
具體來說，OpenShift之所以在容器平台市場掌握47.8%高佔有率，遙遙領先其他品牌，正是因為它超越了單純的容器平台層次，不僅富含完整的雲和地平台管理功能，更能支撐橫跨雲和地的一致開發體驗，使企業能夠憑藉一致的指令、一致的工具鏈、一致的技術力…等倚仗，朝向雲原生目標順利推進，過程中無踩坑或跌跤之虞。
欲實踐DevOps，首先須從形塑文化著手
Red Hat台灣解決方案架構師Dennis Chou，進一步分享「如何在Red Hat OpenShift Container Platform上實踐應用持續整合與持續部署」箇中要領。
他表示，時至今日大家對於DevOps已不再陌生，而且它也並不是新名詞。簡言之，它的目的是讓開發者更快速交付業務功能、符合業務發展需求；與此同時，又能迎合維運團隊力求運行環境穩定性的初衷，兩造的期望能夠完美兼顧，沒有衝突矛盾。
至於如何導入DevOps？Dennis Chou提醒，並非從DevOps工具鏈中選用幾套工具，就真的實現DevOps，必須確實發揮更快速的部署、更敏捷的開發，且讓業務系統更快交付等功效，才算是符合要求。
因此實踐DevOps的第一個重點，其實不在於採用什麼犀利的工具，而在於能否形塑出讓開發人員、維運人員彼此更容易合作的流程。因此要想落實DevOps，首要之務其實是「文化」；唯有建立DevOps文化，才能真正消除開發和維運之間的壁壘，在相同技術架構上共同合作。至於要填補雙方的Gap，在技術上有一項不可或缺的基石，便是自動化部署，如此方能達到更快速的變更與迭代，且將可能出現人為失誤機率降到最低。
以四大關鍵指標，衡量DevOps實踐成果
接下來，企業需要建立一個衡量機制，藉以判斷DevOps的實踐成果究竟是好是壞。大致上來說，這個衡量機制必須依循四個關鍵指標。第一是「交付時間」，意指從提交程式碼，到運行至生產環境的所需時間。第二是「部署頻率」，指的是部署上線到生產環境的頻率。第三是「變更錯誤」，端看有多少百分比的變更出現錯誤，並且需要修改。第四則是「恢復時間」，究竟需要多久時間，才能從意外事件中恢復正常。
當然，關於這四個關鍵指標，各有各的持續精進方法。首先談到如何縮短交付時間，重點就在於自動化，以往之所以耗時甚鉅，主要癥結就是人工部署、人工打包，若能將打包與部署、連同中間的測試過程通通導向自動化，就可望出現大幅改善。
其次談到如何提高部署頻率，透過敏捷式開發，儘可能縮小每次的部署量，就越少機會出現錯誤，也不必花太多時間進行程式整合，堪稱立竿見影的做法。
至於如何減少變更錯誤率，如前所述，藉由自動化可減少人為錯誤，而每次部署的量越少，也就越能執行完整的測試，錯誤率就會顯著降低。另可歸功於一致性環境，即便有錯誤，通常會在前面的開發或測試階段發現問題、及早除錯，而容器即是打造一致性環境的關鍵技術。
最後談及如何縮短恢復時間，可採用進階部署策略，如藍綠部署、金絲雀部署，並且搭配自動回滾策略，避免在生產環境中修改錯誤。
藉由Build、Tekton與GitOps，實踐CI／CD流水線
更重要的，要改善四大問題，還可倚靠另一項重要解方，即是最基礎的CI／CD Pipeline。依據雲原生標準的CI／CD實踐方式，分上下兩塊。針對下面的CD，OpenShift採用GitOps工具，上面的CI則採用Build、Pipeline兩套工具。
Build負責將原始碼打包成鏡像檔，再往下走到OpneShift的CI Pipeline「Tekton」（Tekton為K8s原生宣告式流水線服務）。Tekton的優點在於它是Serverless CI/CD，用戶無須維護及管理CI伺服器；其次它能夠在包含所需依賴的個別獨立容器中運行流水線，可擴展性甚高；再者它也能輕易整合Web、CLI、VS Code或IDE Plugins等各種開發工具。而用戶可自行定義流水線，只要Tekton讀取到定義，就能幫忙執行該任務。
關於流水線中的執行步驟，首先需定義Step、即為任務執行步驟。將這些Step組合在一起便成為一個Task，是流水線中最小的運行單位，而Step容器會在Task Pod中運行。再往上一層，就是完整的Pipeline流水線，負責定義Tasks執行順序，並透過Workspaces共享Tasks之間的資料，且允許橫跨不同Projects重複運用。
論及OpneShift用來作為CD工具的GitOps，是一組利用Git工作流來管理基礎架構和應用程式配置的實踐。它利用Git儲存庫作為真實來源，允許DevOps團隊將叢集配置的整個狀態儲存在Git中，好讓它的所有更改軌跡，都是可視化及可稽核的。
雲原生平台所有的部署檔皆以YAML形式撰寫，用戶可將YAML檔存放到Git版控程式裡，其中有專門的應用負責監控版控程式上的設定值，且會自動確保叢集與版控的設定狀態相同，接著透過此方式進行宣告式部署。而GitOps除可用於部署應用程式外，另外也能執行基礎建設管理，甚至可以延伸到其他細部應用，像是執行更為進階的部署策略，抑或進行DR切換。
值得一提，RHOCP GitOps工具的上游專案為ArgoCD，它會比對Target State（應用的目標狀態，存放在 Git）、Live State（應用的真實狀態，即Pods等應用服務部署的情形），若發現兩邊不相符，就啟動Sync流程。
標準CI／CD範例如下。當程式碼交付到版控，便進入CI階段，結束後會產生出可部署檔案，最後進入CD階段，把部署檔佈建到各環境。
啟動安全措施，從CI／CD推進至DevSecOps
當用戶開發完成、要部署至容器平台，需先描述應用，打包為鏡像檔。建議用戶選擇驗證過的鏡像檔作為打包基底，且最好選擇最小化鏡像檔，只因它更輕量，更易於快速啟動，且因內容較少、可被攻擊的漏洞更少。
當完成前述撰寫後，連同Dockerfile、程式碼放到Git，便進入CI階段，會自動觸發Image、Build Pipeline，此時將產生JAR檔，需將它放到一個專門放JAR檔的Repository裡，再打包JAR檔為鏡像檔，放至Image Registry。上傳完成後有一步驟，需針對Registry做安全掃描，確保鏡像檔安全無虞，至此完成CI。再往下走即進入CD。把YAML檔放上GitOps，再執行自動部署。
如何從CI／CD到DevSecOps？首先鏡像檔打包時要有安全來源，即Red Hat驗證過的UBI，並搭配上述Image Registry的掃描程序。此外可在流水線中加入安全簽章流程，先以打包好的鏡像檔做簽章，確保不會被人擅自替換。另一方面可在整個部署完成後，啟用持續偵測的安全機制，譬如Runtime Detection、ACS等。
技術交流工作坊，引導學員將應用遷移至RHOCP
活動的後半段，係由Red Hat台灣的Kai-Feng Chang等多名客戶技術經理（TAM），聯手舉行技術交流工作坊。
TAM引導大批學員展開「將應用程式遷移至RHOCP」的實機演練，首先啟動準備程序，讓學員存取Red Hat備妥的Lab環境、VS Code Server、Gitea；接著利用MTA （Migration Toolkit for Applications）對應用進行評估與分析。
再藉由TAM的指點，使學員知道如何因應分析結果執行重構（Refactor）、然後部署至RHOCP。最終在RHOCP啟用Pipeline 與GitOps，實現應用程式的持續整合與持續部署（CI／CD），為一整天的活動劃下圓滿句點。
