案例1:基于云的運維自動化
我們是小規(guī)模的公司,搭建在 AWS 上的服務(wù),主要使用 Ruby on Rails,并實現(xiàn)了應用的水平擴容。
在專案一開始的時候只有一臺 EC2 就可以跑了,后來因為專案越做越大,開始做平行擴充以及 SOA,因此我們導入了 Chef 做自動化運營,主要使用 Chef 做機器的安裝及部署,使用 Cloud Watch 做機器與 Application 的效能監(jiān)控,在每次 deploy 的時候做AMI,當資源負擔到達設(shè)定值時,Chef 會使用最新的 AMI 開一臺新的機器加入 ELB,這個過程大約是 5 分鐘,于此我們做到了 Application 面的平行擴展。
數(shù)據(jù)庫的部分,我們使用 PostgreSQL 做集群,一臺 Master + 多臺 Slave 加上 AWS 本身的 muti-AZ 機制,可以動態(tài)加開 slave 以及 load balance;Redis 的部分亦同。
現(xiàn)在我們使用 Jenkins 做 CI,每次跑完 CI 會包一個 Docker 版本來跑 staging 環(huán)境,staging 環(huán)境現(xiàn)在跑 docker,但現(xiàn)在還不敢放到 production 環(huán)境中。
案例2:關(guān)于自動化部署
我從多個方面來描述下我們廣告公司運維自動化的實施情況。
編譯:
我們這邊RTB是用linux下的C++開發(fā)的,部署的過程中需要依賴一些特定版本的linux的運行庫,而編譯本身需要的庫和頭文件會更多,所以我們是將編譯和自動部署分開的,業(yè)務(wù)需求完成編碼和測試后,會將可執(zhí)行文件放在指定的位置,用jenkins來調(diào)用之前調(diào)試好的自動部署腳本來進行推送和啟動運行,這樣能保證編譯的程序相關(guān)的功能都是測試通過,且經(jīng)過驗證的,自動化部署之后外圍還有相應的監(jiān)控系統(tǒng)會定時掃描端口開放情況以及程序運行情況。
商務(wù)平臺:
這部分是用java開發(fā)的,包管理使用maven,已經(jīng)做好了關(guān)聯(lián)的特定版本的jar包的管理,這部分功能就是開發(fā)測試完畢,將驗證沒有問題的特定版本號的svn地址提交給系統(tǒng)部,通過jenkins從SVN拉代碼,調(diào)用maven進行編譯,部署和啟動,相關(guān)功能都是在運行服務(wù)器上執(zhí)行。
數(shù)據(jù):
數(shù)據(jù)部分采用了redis和tair集群,用于存儲人群屬性和cookie映射數(shù)據(jù),redis和tair是通過jenkins進行部署的,數(shù)據(jù)導入是每天定時跑完畫像數(shù)據(jù)后自動導入的,而數(shù)據(jù)的遷移是通過人工觸發(fā)的,當部分節(jié)點數(shù)據(jù)存在問題時,外部有系統(tǒng)監(jiān)控,發(fā)現(xiàn)問題,人工觸發(fā)數(shù)據(jù)遷移。人工觸發(fā)數(shù)據(jù)遷移是一般是在發(fā)現(xiàn)數(shù)據(jù)分布不均衡,特定節(jié)點負載非常高的情況下,會在后半夜觸發(fā)遷移操作。
流程規(guī)劃:
業(yè)務(wù)相關(guān)的程序開發(fā)之后,默認是手動部署的,手動部署時會梳理相關(guān)的流程,形成腳本,后續(xù)jenkins的自動化腳本也是來源于手動部署的腳本。
Auto Scale:
集群是auto scale的,平時會有一個最基本的機器數(shù)量配置,部署相應的程序,部署完成后不存在減機器的情況,如果有流量突發(fā)高峰和廣告投放高峰,有一部分備用的機器可以快速部署,然后把流量指到新部署的機器上
規(guī)模:
目前大概用于RTB的機器有40多臺高配的服務(wù)器,每臺服務(wù)器上會有20個左右的進程,商務(wù)平臺和展現(xiàn)點擊收集以及計費系統(tǒng),服務(wù)器有20多臺機器,而后端的日志存儲和人群畫像部分用到的hadoop有50多臺機器。
精彩觀點摘錄
自動化運維的本質(zhì),個人愚見就是把人解放出來,人騰出來做更有價值的事,事不會少,但產(chǎn)生價值的事要越來越多,其實從某種程度上面來講,對運維人員是一個悲劇,如果運維人員不提升自己的核心競爭力,那就面臨著下崗,在老板心目中,機器能更快更好的做好,為什么需要人來做(慢,不能量化)。當然反過來說,運維人員就要在老板面前找到自己的價值。
自動化運維,我更關(guān)注人。
基于公司實際情況,制定完善的流程,把重復的工作工具化,有挑戰(zhàn)的工作簡單化,相應的流程及工具文檔化。總之盡可能不需要人為干預,即便需要人操作,懂點技術(shù)的員工按流程和文檔即可完成操作。
Q &A
Q1:數(shù)據(jù)集群采用Jenkins部署是否存在不妥,是否違背了編譯和部署分開的原則?
其實數(shù)據(jù)集群用jenkins部署主要是編譯的基礎(chǔ)環(huán)境是一定的,可以在使用jenkins部署之前完成機器系統(tǒng)安裝之后會將相關(guān)的編譯環(huán)境也批量安裝好,所以用jenkins部署是沒有問題的。
Q2:Jenkins在里面用得太重了,不知道會不會導致CI慢或其它問題?
其實不會,因為子系統(tǒng)劃分是將對比較輕的,不會有非常復雜和耗時的編譯。