DevOps redhat Pipeline OpenShift Jenkins

Red Hat結合開源工具鏈 為Pipeline流程打造敲門磚

DevOps發展非一蹴可幾 逐步累積經驗方能實踐

2019-09-16
從商業價值切入,找到實務應用的新場景,正是各產業積極發展轉型的目標。腳步較快的本土企業,近兩年開始藉由成立DevOps團隊,從實踐的過程中累積經驗,逐步調整開放原始碼套件所組合而成的工具鏈,進而藉由自動化機制,減少人力介入操作,以成功達到及時回應市場與展現價值。

 

Red Hat資深解決方案架構師張均合指出,切勿以為導入建置一套軟體工具即可做DevOps,實踐的本質是為了讓公司內部形成一種氛圍或文化,IT部門中不同技術領域的工作者得以自然地合作,推動應用服務快速上線運行。就像是新創公司,核心思維為了存活必須得加快速度,類似於程式開發的快速失敗(Fail-fast)概念,至於採用的工具則取決於團隊擅長的技能,並無一定的標準,況且主要技術皆來自開放陣營,版本更迭速度相當快,且實作技術不斷推陳出新,若單純仰賴工具,隨後恐面臨發展瓶頸。

工具鏈本身可視為DevOps團隊的敲門磚,藉此讓團隊成員開始熟悉彼此溝通與協同合作模式,例如運用Slack等App,工程師可透過幾個簡單關鍵字,讓後端程式碼自動執行。

自動化機制提升Pipeline流程效率 

張均合進一步說明,所謂的創新,應該是由小而大、由下而上,主要因素在於,從實際接觸客戶的經驗發現,許多企業的高階主管是接收到同業正在推動DevOps,為了加緊腳步跟進,要求IT部門基於同業採用的工具鏈來執行任務,結果往往是被動式配合高層下達的指定,卻無法在實務上發揮作用。不如讓團隊自發性地感受新工具帶來的改變,先行運用到日常工作提升效率。再逐步推展小專案,從中尋找商業模式,同時也可藉此增進開發與維運者彼此之間的協同合作默契,逐步累積經驗並加以改善,經過整理收斂後,建立最合適的工作流程。

就台灣產業發展現況來看,張均合指出,DevOps發展速度較快的當屬金融業,已經充分感受到來自跨界競爭的壓力,也很想從體質面盡快著手改變,促進團隊之間合作模式、彼此的溝通,或者是直接增設DevOps架構師職務,引領團隊執行新業務需求任務。

「其實DevOps早在15年前就已經出現,只是當時稱之為Enterprise Management Control,或者是Change Management Control,概念上皆類似,如今演進到DevOps並非全新的概念。許多大型企業會找顧問或軟體廠商協助共同制定出DevOps實作方法,但是聽完高大上的目標之後,最終落地仍舊得回歸到企業內部。從我參與幾個客戶實施的經驗,就如同前述說明,必須由下而上、由小而大、由淺入深,逐步累積經驗與知識。當然,前提是要高階管理層的支持,至於如何達到目標,則是由一線單位自行創造新的工作方法。」張均合說。

Red Hat資深解決方案架構師張均合指出,Pipeline流程的工具鏈組成,主要為開源陣營發展的技術,此時Red Hat即可發揮強項,基於長期以來累積的經驗與知識,協助把關與評估,讓企業環境得以運用穩定性較高的版本發展新應用。

採用DevOps工作流程指的是程式碼從撰寫完成後直到上線運行,整體操作細節是經由Pipeline來實作,可能受到企業文化、管理政策、人員技能等因素所影響,難以將單一方法論套用到每個企業。IT廠商可協助之處,主要是改善Pipeline運行效率,減少過程中許多人為介入造成的中斷點。例如開發人員撰寫完成的程式碼,準備進入測試,傳統的做法是透過郵件通知相關人員,真正執行的時間最快通常是隔天。這段常見的工作流程,值得探討之處在於郵件溝通模式,如今已可運用像是Slack等App來提升效率,甚至根本無需通知,在程式碼簽入(Check-in)到版本控管系統當下即可觸發事前撰寫的自動化測試腳本,省去測試人員進入系統查看的動作。此即為逐步地在Pipeline中增添自動化機制,減少人力介入以提升效率。

容器化實現一次建構、隨需部署 

針對Pipeline的設計,可切分為多個階段執行,不見得要一步到位。張均合以製造業客戶為例,常見的內部開發流程是基於檔案伺服器來管理,程式碼開發完成後,依照上傳的日期命名存檔,再透過郵件通知下一關測試人員。經過測試完成後,再郵件通知部署與維運人員,把此開發專案的資料夾搬移到線上的應用系統。若隔天馬上改版,就依照資料夾定義版本別,同樣動作再做一次。問題是過多的人力介入,可能發生誤刪除、存放位置出錯等問題。過程中假設有10個單位參與,即表示整個Pipeline會有10個斷點,每個斷點勢必都有改善空間,或者可予以收斂減少流程所花費的時間。

至於實作環境,則可藉助容器化之力簡化操作細節,達到快速部署與上線運行的目標。張均合舉例,開發單位常見的狀況是撰寫完成的程式碼,須在測試環境先行建構與部署,通過後進入下一個壓力測試環境,重新再建構與部署。透過容器則可做到「Build once, deploy anywhere」,意思是,程式碼一旦經過編譯封裝後,內容即無法被變更,可直接把打包封裝完成的檔案放置在各種異質環境執行,不僅省去許多無效率的操作,甚至比過去的重新建構更能夠符合金融單位稽核的需求。

依照技術掌握度組成合適工具鏈 

整體Pipeline的流程,欲實作持續整合、持續發布,須由多種技術領域組成工具鏈來協助。首先是專案管理工具,由需求單位填寫申請表單,再派工給開發人員,基於.Net或Eclipse整合式開發環境(IDE)撰寫程式碼,完成後發布到GitHub、GitLab、SVN等版本控管系統;執行建構時,大多會採用Maven或Python、Ruby等的工具;進入到應用階段,可直接呼叫既有已經撰寫好的Library,整合成為可運行的應用項目,經過單元與壓力測試、弱點掃描、程式碼安全檢測,才可實際部署。

工具鏈選用的方式,須依照技術人員擅長的技能評估。其中最多被採用的Jenkins,主要是用於串連流程中的各項環節,讓建置容器環境、部署程式、上線啟用,得以自動化方式整合運行,就像是個管家的角色。

執行持續整合與持續發布過程中所選用的工具,皆可建置在容器環境,即可藉由Red Hat解決方案來奠定穩定的基礎。張均合說明,企業端建置Jenkins,過去需要採購三台伺服器,架構模式是單個Master得搭配三個Slave,可是通常只有在內部同仁提出申請單,工程師開始撰寫程式,才會觸發Jenkins執行。若為Red Hat提供的Jenkins容器化版本,則是在執行時才呼叫啟動,即可讓資源利用率發揮到極致。

 


熱門活動

more →

追蹤我們Featrue us

本站使用cookie及相關技術分析來改善使用者體驗。瞭解更多

我知道了!