有了IaaS，你的持續(xù)交付水平為何仍落后于Flickr？

作者：阮志敏 2015-10-26 10:34:20

云計算

IaaS 隨著云計算和開源軟件的發(fā)展，我們擁有了比Flickr更好的基礎條件：IaaS給我們提供了可編程的接口，我們不再受到物理資源的約束;GitHub帶給我們新型版本控制和代碼協(xié)作方式; Chef/Puppet等配置和自動化部署工具更加成熟;基于ELK的實時監(jiān)控和日志系統(tǒng)也很成熟。但是，即便如此，有多少企業(yè)達到了Flickr的持續(xù)部署和交付水平?

代縣ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18982081108（備注：SSL證書合作）期待與您的合作！

早在2009年，F(xiàn)lickr就分享了他們如何通過工具的支持和文化的改變，使之能夠支撐業(yè)務部門“每天部署10次”的要求。這些工具包括

• Automated infra
• Shared version control
• One step build and deploy
• Feature flags
• Shared metrics
• IRC and IM Robots

5年時間過去了，隨著云計算和開源軟件的發(fā)展，我們擁有了比Flickr更好的基礎條件：IaaS給我們提供了可編程的接口，我們不再受到物理資源的約束;GitHub帶給我們新型版本控制和代碼協(xié)作方式; Chef/Puppet等配置和自動化部署工具更加成熟;基于ELK的實時監(jiān)控和日志系統(tǒng)也很成熟。但是，即便如此，有多少企業(yè)達到了Flickr的持續(xù)部署和交付水平?

這里，我們把持續(xù)交付分解成三條主線(如下圖)：

• 從Code到Artifacts倉庫;
• 從Artifacts到Running Service;
• 從開發(fā)、測試環(huán)境到準生產、生產環(huán)境;

對于這三條主線，筆者發(fā)現(xiàn)大部分IT組織都存在三個類似的問題。

1. 從Code到Artifact倉庫：沒有統(tǒng)一的Artifacts倉庫

在很多企業(yè)IT組織中，由于歷史及其他各種各樣的原因，不同的項目，會采用不同的開發(fā)語言、框架，版本控制服務和持續(xù)集成工具。這是不可避免的。真正的問題是出在Artifact的管理上。有些人根本就沒有Artifact的概念，認為代碼就是artifact，部署應用時都是直接從svn等版本控制器上面直接獲取代碼進行部署。有些IT組織即便有aritfact倉庫，也沒有統(tǒng)一的規(guī)范，非?；靵y。

如何改進呢?

建立統(tǒng)一的Artifacts倉庫。這是后續(xù)自動化部署和多版本開發(fā)的基礎。

Artifacts倉庫的實現(xiàn)方式有三種，F(xiàn)TP、對象存儲(比如阿里云OSS，AWS S3等)和專業(yè)的Artifacts存儲倉庫。對象存儲、 FTP都重在存儲，只能實現(xiàn)最基礎的分目錄和權限管理。如果你的環(huán)境都在公有云上面，那么用公有云的對象存儲服務來管理Artifacts是很合適的，原因有以下幾個：

• 不用擔心可用性和可靠性。
• 上傳和下載速度快。
• 不同的項目可以用不同的Buckets來進行權限管理。如果是AWS S3，還可以使用IAM來進行更細粒度的權限控制。

專業(yè)的Artifacts存儲倉庫方面，目前有三個使用比較廣的選擇：Artifactory、Nexus和Archiva，其中Artifactory和Nexus也有商業(yè)版本。這三個工具雖然都源自Maven，但是他們不僅僅支持Java/Maven，任何項目和語言都可以使用Maven機制來打包Artifact，區(qū)分Artifact版本，并最終存儲到Repository中去。下圖是Nexus的一個截圖，可以清楚看出Artifacts倉庫所要解決的幾個問題：不同項目、不同組件artifacts的分類存儲;Artifacts格式的統(tǒng)一;用戶和權限控制;開發(fā)版本和發(fā)布版本區(qū)分、如何與CI服務器集成等。

2. 從Artifacts到Running service：不同環(huán)境的部署方法不一樣

這條主線解決的是，如何將Build artifacts部署到開發(fā)環(huán)境、測試環(huán)境、準生產環(huán)境和生產環(huán)境。

對于這條主線，當前普遍存在的問題是：不同環(huán)境的資源創(chuàng)建、服務器配置和代碼部署方法是不一樣的。很多時候大家只關注生產環(huán)境的部署管理，對于開發(fā)及測試的部署管理又不重視。比如，開發(fā)和測試環(huán)境是手工部署的，而生產環(huán)境是用工具進行自動部署的，因為部署方式不一致，因為在生產環(huán)境會經(jīng)常出現(xiàn)不可預知的錯誤。另外，隨著版本分支的增加，開發(fā)、測試和準生產環(huán)境會混亂不堪。

如何改進呢?

貌似PaaS的存在就是為了解決這個問題，開發(fā)人員只要專注于應用的開發(fā)，部署和Ops工作都是有PaaS本身完成。然而，現(xiàn)實是目前的PaaS仍然沒有進入主流，這是因為PaaS給予太多的限制、很好解決的80%問題，但是剩下20%很難解決。

在云計算(IaaS)支撐下，在云管理和部署工具的支持下(比如Rightscale, Cloudify，AWS Cloudformation, AWS CodeDeploy, FIT2CLOUD)，用戶可以實現(xiàn)從Artifacts到Running service整個過程的自動化，包括環(huán)境創(chuàng)建自動化、虛機安裝配置自動化和代碼部署自動化。

1. 環(huán)境創(chuàng)建：創(chuàng)建VMs、網(wǎng)絡、存儲、負載均衡，協(xié)調不同角色VMs的創(chuàng)建過程和配置。
2. 軟件安裝和配置：操作系統(tǒng)配置，比如創(chuàng)建用戶、組，設置ulimit參數(shù)等;基礎軟件安裝和配置，比如mysql/nginx。這些軟件的特點是變動不頻繁。
3. 應用部署(Code Deploy)：部署應用代碼，比如war包、db腳本、php/rails代碼等。這部分的變動是頻繁的。開發(fā)人員不僅僅是提供代碼，而且要提供部署代碼所需的腳本，比如AWS CodeDeploy規(guī)定Artifact中必須包括的部署這份代碼所需要的腳本。CodeDeploy雖然沒有編排功能及完備的插件和腳本庫(比如HP OO)，但是實現(xiàn)了應用代碼和部署腳本的統(tǒng)一融合，可以避免多版本同時開發(fā)、部署所導致的混亂。采用CodeDeploy，每個應用組件可以單獨、持續(xù)的繼續(xù)升級部署，不需要整體部署。

#p#

3. 從開發(fā)、測試環(huán)境到準生產、生產環(huán)境：開發(fā)、QA和運營仍然采用傳統(tǒng)的協(xié)作方式

這條主線涉及IT組織內部的合作和協(xié)調。傳統(tǒng)的協(xié)作方式及流程的設計是依據(jù)當時”非頻繁”交付設計的，不適應于當前對頻繁交付的要求。IT組織仍然固守傳統(tǒng)的運作和分工機制，做一件事需要開很多會，是一種類似瀑布流的組織方式，需要花很多時間。當下很多IT組織采用了敏捷開發(fā)、每天都可以產生很多構建(Build)，但是生產環(huán)境的部署節(jié)奏仍然很慢，這是普遍存在的問題。

如何改進呢?

實現(xiàn)DTAP的融合需要三個方面支持：觀念的轉變，組織結構和文化的更新及技術和工具的支撐。

首先是觀念上面的改變，并建立與新觀念相匹配的共享服務Metric和SLA信息。在競爭激烈的新時代，原來那種Dev和Ops隔離的方式已經(jīng)滿足不了云時代的快速迭代交互的需求。

其次是工具和流程上面的改進?；谏厦?**條、第二條主線達成的基礎，構建自動化的文化，并建立清晰、一致的DTAP流程。這樣Dev、Ops、QA因為是在一個流程和同樣工具下工作的，相互所有的細節(jié)都透明了，也就自然融合了。同時，DTAP環(huán)境都是用相同的方式進行自動化部署的，在進行生產環(huán)境部署前，這個部署方法已經(jīng)在開發(fā)、測試、準生產環(huán)境上面被反復驗證過?？偠灾?，用統(tǒng)一的流程和工具管理不同的環(huán)境，又能支持不同環(huán)境的不同策略，這是實現(xiàn)DTAP環(huán)境融合在技術和工具上的關鍵所在。

***，不同角色人員之間相互融合。比如，開發(fā)人員應該更加深入的參與測試及生產環(huán)境的運營，比如參與測試環(huán)境的部署、生產環(huán)境各個層面監(jiān)控指標的設計和開發(fā)。“You build it, you run it“，這是Amazon一年可以完成5000萬次部署，平均每個工程師每天部署超過50次的核心秘籍。

結束語

持續(xù)部署、持續(xù)交付能力的改進，是一個從自身情況出發(fā)的，持續(xù)的、不斷改進的過程。在文章結束之前，我還想分享下我的兩個體會。

1.不能把希望完全寄托在新興的技術，比如Docker，來提升持續(xù)交付能力。很多人盼著Docker來解決現(xiàn)在存在的問題。但這些問題都不需要Docker就可解決，Netflix/ Flickr等就是例子，關鍵得有持續(xù)改進的意愿和行動。松耦合的SOA/微服務架構; “you build it, you run it”的DevOps文化; 與架構和文化相適應的自動化工具和Infra。這三點都不是一朝一夕或者一個新技術可以解決的。

2.IaaS會是新常態(tài)，將成為互聯(lián)網(wǎng)和企業(yè)的基礎設施。云IT和傳統(tǒng)IT有很大的不同。 使用IaaS只是***步，企業(yè)應該利用上云這個契機，在應用架構、部署管理工具、開發(fā)運維協(xié)作方式也進行轉變，解決這三個普遍存在的問題，打通從代碼到服務的通道，提升持續(xù)交付能力。

【本文來源：fit2cloud微信公眾號】

名稱欄目：有了IaaS，你的持續(xù)交付水平為何仍落后于Flickr？
URL地址：http://www.5511xx.com/article/dhjideg.html