您的位置:首頁>互聯網>正文

CodePipeline聯動容器的DevOps實踐

摘要:雲棲TechDay41期, 阿裡雲資深開發工程師流生帶來CodePipeline聯動容器的DevOps實踐。 開發界關注如何讓Docker的持續交付更簡單、安全、高效。 在推出容器服務之後, 阿裡雲研發了開源持續交付工具CodePipeline, 它提供多種語言的持續交付嚮導範本, 通過範本快速填寫進行持續集成, 從而實現多平臺、多環境的持續交付。

以下是內容整理:

開發者在雲上的“最後一公里問題”

雲計算的最後一公里是說雲計算技術已經成熟了, 很快或者是平滑的落實到企業當中, 這幅圖其實是RightScale2017年最新關於雲計算市場的調研, 可以看到只有1%的企業現在沒有使用雲技術, 或者是沒有計劃去使用雲平臺, 由此可見雲計算已經很普及了。 雲趨勢越來越明顯, 越來越多的開發者把開發工作放到雲上, 開發者在雲上最後一公里問題, 其實是要怎麼樣解決從代碼提交到服務發佈與運營整個階段的問題, 包括配置管理、集成、測試、部署以及技術運營等領域。

怎麼樣做好這一步?我覺得就是要開發者和服務運營人員之間能夠有一種互相延伸的能力, 開發者可以參與到運營的工作裡邊, 運營也可以參與到開發設計工作當中, 以及他們之間的互相回饋資訊能力, 對使用者的價值會更凸顯出來。 走好開發者在雲上的最後一公里的技術價值在於:

1. 提高交付的頻率;

2. 降低交付的故障率;

3. 縮短交付週期;

4. 縮短平均修復問題的時間;

5. 專注于創造有價值的開發活動。

舉個簡單例子, 我們在剛剛公測產品的時候, 只提供了Java和Node.JS兩個構建環境, 那當時就有用戶說我們用的是PHP語言, 能不能儘快把構建環境給我們提供出來, 我們當時的開發優先順序其實是添加海外的構建節點,

或者是對開源雲code的一些集成。 由於能夠及時得到用戶的需求回饋, 所以我們才會把它調整為優先順序最高, 也意識到用戶提出來的才是最有價值的。 然後從開發測試到驗證到上線大概有三個工作日, 用戶已經可以用到這個功能。

Jenkins 與容器技術

Jenkins工具在開源界多年, 其實經過了生產實踐檢驗, 它有龐大的社區, 認知廣泛, 1000+外掛程式體系。 它是能夠集成端到端的持續交付工具鏈, 還給你提供了一些擴展介面, 想要自己做集成就可以通過它的介面擴展做開發, 然後它的構建部分也提供了介面, 如果社區沒有這樣的外掛程式也可以做自己的二次開發。 2016 Java開發工具調查占比60% , 2016中國開發者白皮書調查占比70%,

CI市場占比70%, 2017技術趨勢預測中最受歡迎持續集成工具第一。

Jekins是master加slave的架構, master負責作業調度, Slave負責作業執行, 然後slave節點都可以打標籤分類, 我們在使用的時候一定要做到構建分類, 比如用於測試構建的作業要綁定到用於測試的節點上, 不要混用, 因為可能會產生資料污染, 還可能會因為在構建裝包的時候因為依賴版本不同會把舊的升級到新的, 導致構建作業的失敗。

在開發過程當中可能用到源碼倉庫、打包構建、部署進行測試、再部署進行驗證,

以及環境當中出現任何問題都能得到及時溝通回饋, 都可以通過Jenkins Master來做, 每一個部分其實都是一個作業, 如果有依賴可以循序執行, 如果沒有依賴可以並存執行, 可以最大效率的把構建作業的運行週期縮短。 一個Jenkins作業的基本配置, 包括基本資訊以及源碼管理、構建觸發器、構建和部署, 還有構建後的操作, 主要就是一些郵件通知以及釘釘或者其他一些通訊工具的通知。

DevOps

DevOps工具裡邊容器包括Docker、Chef這些容器技術, 容器技術的使用占比已經達到60%以上。

Docker用來打包標準套裝軟體, 這些套裝軟體可以用於開發、部署、交付, 它跟虛擬機器比起來, 底層架構容器主要是共用宿主機的一個OS內核, 虛擬機器要在物理環境上安裝一個Hypervisor, 虛擬機器需要用到CPU記憶體都是Hypervisor虛擬出來, 虛擬機器是自己獨享自己的作業系統, 自己獨享自己的內核,容器在佔用資源、啟動速度以及併發性和性能資源利用率方面都要強於VM,因為它要具備儘量快、資源的利用率高、高性能損害小這些特點,這與DevOps要縮短交付週期理念是很契合的。

交付環境

另外,容器可以打包標準的交付環境,我們有時候可能把64位開發環境下開發的程式放到32位元的機器上去運行,會有相容性的問題,或者還有一些依賴性問題,容器都可以通過打包一個Docker Image把這些解決掉,它的Docker Image聯合檔案系統一層加一,最下邊是Base Image,如Ubuntu等都是Docker公司自己做的,再往上安裝自己的依賴,再安裝自己的應用,所以打包出來的話,無論你以後要部署到哪裡,你的應用都是部署在上邊,就不會有相容性問題以及依賴問題。

如果你的應用比較複雜,比如說應用後面還依賴一些資料庫服務,他們之間要有個先後的啟動順序,以及資料庫要提供一些參數給前面的服務,這樣的編排就可以用Docker compose,它的優點就是能夠把比較複雜的應用簡單化。

你的應用想要真正的部署線上上服務給使用者的話,其實還需要放到集群裡邊,這個集群可以給你提供網路存儲調度以及編排,還可以幫你做服務的高可用性,你可以在裡邊做多個副本,,不至於有一個節點出問題會導致整個服務停止。

CodePipeline 聯動容器技術的實踐

圖為開發者從提交代碼到部署到自己的測試環境或者是預發環境的一個過程,首先要有一個原始程式碼的管理倉庫,可以是私有的,可以是公有的,像阿裡雲它有自己的阿裡雲Code產品,然後公網上邊還有GitHub,私有現在用的比較多的是Gitlab,其實Jenkins這方面的外掛程式支持都是很豐富的,代碼管理倉庫下來就是Jenkins CI server和CD server,CI要配一個源碼的觸發器,你在這邊提交代碼以後, CI要根據自己的需求配一個觸發器來監聽動作,自動化的觸發作業,作業觸發以後要做構建,然後再做打包,再放到Docker Image裡邊,通過DockerFile打包自己的Docker私有鏡像倉庫裡邊。然後下一步部署的時候,通過自己的Docker Compose編排範本來進行部署,要把服務做成幾個副本,然後你的服務開放埠是多少,這些東西我們不管是在公有雲還是私有雲上都可以這樣去做,應用部署我們建議使用容器集群去做。

開發者自行搭建DevOps的過程中可能會遇到一些痛點如下:

日常運維。日常運維最主要的是資料方面,哪一些是有用的資料,你要及時的做備份,哪一些是沒用的資料,你要及時的做定期處理。備份如果是私有雲環境可能要依賴于存儲的高可用性做保證,資料清理可能需要自己去寫腳本,定期做清理。升級。如果是自己搭建,Jenkins master的反覆運算速度說快不快說慢也不慢了,外掛程式這一部分會有很多的漏洞需要你去升級。所以這些東西都需要你自己去監控,及時的去做更新,包括裡邊應用一些JDK,或者其他開源工具,有更新的時候都得自己去維護。安全隱患。這些開源工具都是有很多的漏洞需要自己去補。有些使用者使用阿裡雲的產品,自己在上邊搭建Jenkins服務端,可能用到其他阿裡雲服務,都需要自己去整合,比如說你要用容器服務,就要自己寫用戶端去調用API使用一些服務。

CodePipeline與容器技術

CodePipeline的解決方案如下:

一個SaaS化持續交付引擎:無需運維,開箱即用;資源按需使用,動態生成;全量相容Jenkins外掛程式:提供經過阿裡雲安全加固的Jenkins外掛程式,根據開發者需求不斷開放。與阿裡雲產品生態無縫集成:客戶私有OSS提供安全構建分發,支援ECS、容器服務持續部署,我們自己開發了外掛程式已經包括服務用戶名密碼,在CodePipeline的過程中已經可以自由的調動三個服務所提供的能力。多維度安全性原則保障:容器化構建環境用完即焚,構建物私有倉庫存儲。全語言環境支援:公測開放Java、Node.js、PHP、Python等,已支持Go、C++等。多維度部署方式:支持跨Region部署(經典、VPC),支持本地集群、遠端集群混合部署(高級)。引導式交互:提供特定語言最佳實踐的嚮導範本。及時用自己公司內部的私有雲環境,我們也有解決方案可以連接到用戶的私有雲裡邊去做一個構建,這是我們做的範本幫使用者去使用。

首先就是構建環境,Slave可以是虛擬機器,可以是容器,我們為什麼不用虛擬機器是因為它沒法去做動態的創建。如果好多用戶都用一個虛擬機器去做構建,那他們的資料隔離性其實不是很強,可能會造成資料污染,這樣就不是很安全,所以我們用的容器還是臨時的Slave模式,我們slave節點資源池是一個Swarm容器集群,在有作業構建任務來的時候,我們才會從集群裡邊去創建一個容器,然後把容器獨享給這個任務,這個任務在容器裡邊做構建執行,它產生的資料會上傳到使用者自己的私有倉庫裡邊,等作業構建完了以後,這個容器就會銷毀,所以在沒有作業運行的時候,CI集群裡邊是沒有Slave節點的,在有作業需要構建的時候我們才給它創建,這樣就是最大限度的利用了資源,這樣做的好處一個是安全,一個是靈活性,按需分配。

構建節點類型有海外節點跟國內節點,我們的考慮就是不要因為網路的問題影響構建效率,其實大家在自己做的時候還是分類,還有不同語言的構建環境,像源碼管理跟觸發器管理,我們現在要做的構建和部署有兩部分,一個是鏡像的構建和發佈,一個是部署容器服務的應用。鏡像構建就是用戶要自己搭一個鏡像倉庫,要把自己倉庫名稱版本鏡像的版本號放上去,然後倉庫的地址以及證書、dockerfile默認git代碼裡邊的Root路徑的dockerfile,打包好以後就會上傳到倉庫裡邊,然後再把打包好的應用鏡像部署到集群裡邊,這個是集群的接入入口、集群的證書以及應用的名字、編排的範本,最後有一個發佈策略,發佈策略有兩個,一個是標準發佈,就是直接新的應用把舊的應用踢下去,先把舊的容器刪掉,然後再部署新的,藍綠發佈是舊的服務繼續運行,新的服務先上來,上來以後有一個路由權重,網路流量其實還是走舊的,新的網路流量是0,在你經過驗證確認以後,再把網路流量調過去,這樣就是容器的服務升級,服務升級之間的間隙會儘量降到最低。

自己獨享自己的內核,容器在佔用資源、啟動速度以及併發性和性能資源利用率方面都要強於VM,因為它要具備儘量快、資源的利用率高、高性能損害小這些特點,這與DevOps要縮短交付週期理念是很契合的。

交付環境

另外,容器可以打包標準的交付環境,我們有時候可能把64位開發環境下開發的程式放到32位元的機器上去運行,會有相容性的問題,或者還有一些依賴性問題,容器都可以通過打包一個Docker Image把這些解決掉,它的Docker Image聯合檔案系統一層加一,最下邊是Base Image,如Ubuntu等都是Docker公司自己做的,再往上安裝自己的依賴,再安裝自己的應用,所以打包出來的話,無論你以後要部署到哪裡,你的應用都是部署在上邊,就不會有相容性問題以及依賴問題。

如果你的應用比較複雜,比如說應用後面還依賴一些資料庫服務,他們之間要有個先後的啟動順序,以及資料庫要提供一些參數給前面的服務,這樣的編排就可以用Docker compose,它的優點就是能夠把比較複雜的應用簡單化。

你的應用想要真正的部署線上上服務給使用者的話,其實還需要放到集群裡邊,這個集群可以給你提供網路存儲調度以及編排,還可以幫你做服務的高可用性,你可以在裡邊做多個副本,,不至於有一個節點出問題會導致整個服務停止。

CodePipeline 聯動容器技術的實踐

圖為開發者從提交代碼到部署到自己的測試環境或者是預發環境的一個過程,首先要有一個原始程式碼的管理倉庫,可以是私有的,可以是公有的,像阿裡雲它有自己的阿裡雲Code產品,然後公網上邊還有GitHub,私有現在用的比較多的是Gitlab,其實Jenkins這方面的外掛程式支持都是很豐富的,代碼管理倉庫下來就是Jenkins CI server和CD server,CI要配一個源碼的觸發器,你在這邊提交代碼以後, CI要根據自己的需求配一個觸發器來監聽動作,自動化的觸發作業,作業觸發以後要做構建,然後再做打包,再放到Docker Image裡邊,通過DockerFile打包自己的Docker私有鏡像倉庫裡邊。然後下一步部署的時候,通過自己的Docker Compose編排範本來進行部署,要把服務做成幾個副本,然後你的服務開放埠是多少,這些東西我們不管是在公有雲還是私有雲上都可以這樣去做,應用部署我們建議使用容器集群去做。

開發者自行搭建DevOps的過程中可能會遇到一些痛點如下:

日常運維。日常運維最主要的是資料方面,哪一些是有用的資料,你要及時的做備份,哪一些是沒用的資料,你要及時的做定期處理。備份如果是私有雲環境可能要依賴于存儲的高可用性做保證,資料清理可能需要自己去寫腳本,定期做清理。升級。如果是自己搭建,Jenkins master的反覆運算速度說快不快說慢也不慢了,外掛程式這一部分會有很多的漏洞需要你去升級。所以這些東西都需要你自己去監控,及時的去做更新,包括裡邊應用一些JDK,或者其他開源工具,有更新的時候都得自己去維護。安全隱患。這些開源工具都是有很多的漏洞需要自己去補。有些使用者使用阿裡雲的產品,自己在上邊搭建Jenkins服務端,可能用到其他阿裡雲服務,都需要自己去整合,比如說你要用容器服務,就要自己寫用戶端去調用API使用一些服務。

CodePipeline與容器技術

CodePipeline的解決方案如下:

一個SaaS化持續交付引擎:無需運維,開箱即用;資源按需使用,動態生成;全量相容Jenkins外掛程式:提供經過阿裡雲安全加固的Jenkins外掛程式,根據開發者需求不斷開放。與阿裡雲產品生態無縫集成:客戶私有OSS提供安全構建分發,支援ECS、容器服務持續部署,我們自己開發了外掛程式已經包括服務用戶名密碼,在CodePipeline的過程中已經可以自由的調動三個服務所提供的能力。多維度安全性原則保障:容器化構建環境用完即焚,構建物私有倉庫存儲。全語言環境支援:公測開放Java、Node.js、PHP、Python等,已支持Go、C++等。多維度部署方式:支持跨Region部署(經典、VPC),支持本地集群、遠端集群混合部署(高級)。引導式交互:提供特定語言最佳實踐的嚮導範本。及時用自己公司內部的私有雲環境,我們也有解決方案可以連接到用戶的私有雲裡邊去做一個構建,這是我們做的範本幫使用者去使用。

首先就是構建環境,Slave可以是虛擬機器,可以是容器,我們為什麼不用虛擬機器是因為它沒法去做動態的創建。如果好多用戶都用一個虛擬機器去做構建,那他們的資料隔離性其實不是很強,可能會造成資料污染,這樣就不是很安全,所以我們用的容器還是臨時的Slave模式,我們slave節點資源池是一個Swarm容器集群,在有作業構建任務來的時候,我們才會從集群裡邊去創建一個容器,然後把容器獨享給這個任務,這個任務在容器裡邊做構建執行,它產生的資料會上傳到使用者自己的私有倉庫裡邊,等作業構建完了以後,這個容器就會銷毀,所以在沒有作業運行的時候,CI集群裡邊是沒有Slave節點的,在有作業需要構建的時候我們才給它創建,這樣就是最大限度的利用了資源,這樣做的好處一個是安全,一個是靈活性,按需分配。

構建節點類型有海外節點跟國內節點,我們的考慮就是不要因為網路的問題影響構建效率,其實大家在自己做的時候還是分類,還有不同語言的構建環境,像源碼管理跟觸發器管理,我們現在要做的構建和部署有兩部分,一個是鏡像的構建和發佈,一個是部署容器服務的應用。鏡像構建就是用戶要自己搭一個鏡像倉庫,要把自己倉庫名稱版本鏡像的版本號放上去,然後倉庫的地址以及證書、dockerfile默認git代碼裡邊的Root路徑的dockerfile,打包好以後就會上傳到倉庫裡邊,然後再把打包好的應用鏡像部署到集群裡邊,這個是集群的接入入口、集群的證書以及應用的名字、編排的範本,最後有一個發佈策略,發佈策略有兩個,一個是標準發佈,就是直接新的應用把舊的應用踢下去,先把舊的容器刪掉,然後再部署新的,藍綠發佈是舊的服務繼續運行,新的服務先上來,上來以後有一個路由權重,網路流量其實還是走舊的,新的網路流量是0,在你經過驗證確認以後,再把網路流量調過去,這樣就是容器的服務升級,服務升級之間的間隙會儘量降到最低。

喜欢就按个赞吧!!!
点击关闭提示