Ansible Tower 3 OpenStack OpenShift Waterfall Container Inventory Playbook Ansible Puppet DevOps JASON Chef YAML

善用自動化協同平台 實踐DevOps作業流程

2016-10-28
在以往專業分工思維下,資訊部門職掌開發(Development)與維運(Operations),通常配置兩組不同團隊,各自擁有不同專業技能。但對於公司營運以行動應用為主軸、或業務模式必須轉型提供終端用戶更方便使用的App,面對的是需求快速轉變的市場型態,亟需仰賴開發與維運人員密切合作來協助企業發展。
然而,兩組團隊因角色不同,思維也不一樣,開發人員有應用服務快速上架的時間壓力,往往選擇最方便、簡易的作法達成目標;維運人員的訴求則是安全、穩定、便於維護的IT環境,因此長期以來,兩組團隊通常各自為政、協同效率不彰。

為了減少雙方之間的磨合、提高溝通效率,讓新業務或應用快速推向市場,歐美國家開始提倡「DevOps」,意即建立開發(Dev)團隊與維運(Ops)團隊雙方的協同工作模式,運用自動化工具輔助轉化軟體交付與架構變更流程,讓企業在快速變化的市場中贏得競爭力。

市場需求快速變化 推動IT本質改變

近年來DevOps經常在許多解決方案中被提及,例如OpenStack、OpenShift、Ansible等,但紅帽台灣區資深解決方案架構師游政杰強調,DevOps既非技術名詞,也不是解決方案,而是偏重於組織文化與工作流程的改善,至於技術只是用來輔助執行。

▲紅帽台灣區資深解決方案架構師游政杰提醒,現代IT人員面臨大環境的改變,必須持續提升、計畫性地嘗試新技術,才能在新浪潮來臨後免於被革命。
在行動為王的時代,都會生活、工作環境皆無法脫離網路,欲吸引潛在客戶的青睞,鞏固顧客忠誠度,需要的是能快速回應市場變化的應用服務。游政杰舉例,若以二十年前的思維,全新開發應用程式須依循系統發展生命週期(SDLC),並以宏觀的角度,根據分析數據預測評估未來十年的業務成長量,來規劃設計程式結構與配置運行環境。

因此以往盛行的是瀑布型(Waterfall)開發方式,至少需一年的開發期程,來建置可服務十?年的應用系統。

伴隨著任務型態的改變,現在的需求面,生命週期變得相當短,且難以預測。 例如近來在全球掀起熱潮的Pokemon GO遊戲,或於此之前的憤怒鳥、Candy Crash,這些公司皆因為遊戲大受歡迎,全球下載數量相當多而增加營收,但是生命週期並不長。在這種求新、求變的年代下,欲提供行動裝置上運行的應用服務,若是領域中第一名的廠商要講究競爭力,就必須持續性地領先他人一步。問題是,現在的開發模式,以及後端基礎架構的支援,無法符合如此快速的變化,才會推動IT朝向雲端、DevOps等方向發展。

DevOps部門協助仲裁 處理「人」的問題

就企業運作邏輯來看,專案程序通常是由業務單位發起需求後,交給程式開發團隊撰寫應用服務,過程中需要基礎架構支援。但是在專業分工方面,開發團隊職責不包含維運,自然不在考量之列;維運單位則可能認為自身工作的重點不在於扶助開發團隊與業務單位的特定任務。在各自捍衛立場的情況下,永遠不會有交集,於是形成常態性問題。

以往之所以未被正視,游政杰觀察,主因在於兩組團隊尚有足夠時間相互對峙、慢慢協調,而如今為了因應變化快速的市場環境,已無法允許此狀況持續發生。DevOps即是解決自動化機制建立後,讓開發與維運之間的溝通也轉換為標準化。「其實技術層面不難,關鍵在於『人』。我跟客戶溝通過程中,發現大多認同問題確實存在,但回應通常是不知如何落實DevOps。就全球應用案例來看,甚至有企業直接成立新的DevOps部門,網羅同時擁有雙方領域經驗的人才,成為仲裁者的角色,去杜絕企業環境中常見非必要、重複的工作流程,避免讓問題變成無窮迴圈。」

他進一步說明,DevOps運行模式就是要不斷地嘗試與修正,因為對企業而言,DevOps團隊的協同作業根本無法擬定一套標準直接套用執行,必須不斷地嘗試後才能取得對於團隊而言最合適的工作流程。

Ansible助DevOps落實溝通、協作、整合

「資訊科技的進步正在改變世界,大家都必須學習往前進,Red Hat也不例外。」游政杰強調,Red Hat身為開放原始碼軟體解決方案廠商,以往提供的是Linux系統、叢集、統一管理工具,如今跨入雲端世代,除了有Enterprise Virtualization建立伺服器虛擬化平台,亦提供OpenStack建置IaaS環境,以及架構於OpenShift的Container等新技術。日前又經由併購取得Ansible,用以協助應用程式的部署建置、生命週期管理、組態管理等IT維運工作。

Ansible實作方式是把原本需要知識領域的人力處理環節,轉換為自動化流程。可事先透過Playbook來定義工作流程,之後透過SSH直接連線到Linux環境,或是遠端管理(WinRM)連線到Windows環境,自動呼叫不同模組執行。該應用模組可能分散架構在多台伺服器環境,只要在Inventory檔案中指定接受控管的主機資訊即可,不需要實際架設代理程式。

「之所以要強調Ansible並非代理程式的作法,是因為類似的方案,例如Chef、Puppet等,都需要安裝代理程式,才能從受控管的伺服器端定期取回狀態值;非代理程式的作法則不同,主要透過跟Linux、Windows環境的高度整合來執行相關工作。」游政杰說。「我們在很多管理工作方面提供自動化,以伺服器虛擬化技術已經建立的自動化機制為例,可透過虛擬主機的範本快速地Provision應用程式與資料庫所需運行的環境,完成後兩者之間要配置連線溝通,即可透過Ansible的變數欄位設定,把資料庫系統的IP位址藉此提供給應用程式。若此工作流程具備邏輯順序,則可被配置為自動化執行。」

以往IT管理方式大多是直接操作指令,或是撰寫Script,觀察執行結果取得資訊。欲提升管理效率,則可經由事先定義符合控管規範的文件檔,可能是基於YAML、JASON等語法所撰寫,按照標準格式描述執行工作,就像Playbook運用的是YAML語法,讓工作得以按照定義逐步被執行;或者也可採用圖形化介面設計的Ansible Tower 3,簡化IT管理者配置工作流程的追蹤機制,甚至可執行基於角色定義的存取控管,僅允許指定的帳號才有權限在特定資產上執行工作,建立安全運行環境。


追蹤我們Featrue us

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

我知道了!