DockOne微信分享( 九十):猎豹移动基于CoreOS在AWS上的项目实践
生活随笔
收集整理的這篇文章主要介紹了
DockOne微信分享( 九十):猎豹移动基于CoreOS在AWS上的项目实践
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
本文講的是DockOne微信分享( 九十):獵豹移動基于CoreOS在AWS上的項目實踐【編者的話】本次分享介紹基于AWS的EC2服務如何設計和搭建適合自己業務的架構方案實現全球多region部署,介紹模型案例:CoreOS的使用技巧與運維經驗,把一個集群當成一臺機器管理心得,包括:
為什么選擇AWS和Docker 為什么選擇CoreOS部署我們的應用 CoreOS在AWS平臺上如何快速構建集群并且進行管理 應用過程中遇到的問題與解決方案
首先我先介紹一下獵豹移動的一些業務,如圖, 我們在海外有著龐大的用戶群體,接近16E下載量,月活用戶4.94E,71%來自海外,戰略合作伙伴主要以阿里、百度、騰訊、小米……?
這么大的海外用戶量我們是這么做業務部署和服務的呢?
首先在選擇服務商的方面我們選擇了實力最強的亞馬遜AWS作為我們的云服務商,我們海外幾乎所有的服務都是架構在AWS的平臺上面。
這給我們帶來了什么好處呢,總結起來有3點:
便捷的全球化部署
因為我們的用戶遍布全球,所以便捷的全球化部署是我們非常看重的,我們使用了AWS全球9個地區的region,其中包括美國3個,歐洲1個,亞太地區3個,南美洲1個,遍布全球 。 彈性的擴展
對于云服務,彈性的擴展是最為便捷的,可以在幾分鐘(而不是幾小時或幾天)內增加或減少服務器。可以同時管理一個、數百個,甚至數千個服務器實例。當然,因為這全是通過Web服務或API控制。 成本的優化
而且無需前期的投資,持續的成本優惠與調整;提高了資源利用率,按需付費;無需出國,管理世界各地的服務器,節約人力成本。
介紹完我們基礎平臺的選擇后,為了更好的自動化,集群化,我們開始接觸容器技術,而且是如何在AWS平臺上實現容器化。
我們把容器的概念進行理解:給你的應用程序“打包”,能夠執行一個“進程”,同時能把你執行的內容和其他“進程隔離”開來的東西,容器化有什么好處呢??
這些好處在所有網站上看到的東西,聽完這個介紹,感覺有點空洞,還是不知道是什么,我們用到的一些package,我再所有的系統里面都可以運行這些進程,而且進程隔離開,為什么還要Docker,這也是我們團隊剛剛接觸時遇到的困惑,除了Linux系統,最早提出容器化的VMware、Microsoft都有這方面的嘗試,只不過他們的容器是虛擬機,而互聯網的發展需要一個輕量級的容器。
這個圖是借鑒了Yahoo的架構,非常的可愛形象,比普通的架構圖更加生動,我們獵豹有很多廣告業務,商業的開發同學做的ADserver,也會有很多流式數據實時處理的系統,通過data highway匯聚到大數據處理系統,Hadoop、Spark計算,后端儲存我們用的是aws-s3。如果要完成這套系統,基礎架構,需要多少人力物力呢?可想而知,單單運維方面上百人的團隊就這樣建立起來了。
以往,我們一批機器只做一件事,比如100個adserver只做廣告接口,另外100臺機器只做廣告檢索,再有100臺機器做數據傳輸處理,某個模塊出問題去擴容或者處理某個模塊,這是大家最常見的方法。這對架構的高可用設計是個很大學問,需要多機房冗余,多地部署等等。如果引入微服務的概念呢??
如左邊圖,一臺機器上面只運行各自的模塊和依賴,不同機器各司其職,出問題處理問題模塊。而右邊微服務的設計,我無所謂我的程序如何分布,每臺host都可以部署多個模塊混合復用,自定義哪些模塊可以和哪些分配到同一臺host,哪些模塊不能和哪些模塊分配到同一臺host,一旦某個模塊掛掉,調度編排工具可以幫助馬上啟動一個新的docker替代工作。擴容的時候不需要針對不通模塊去部署和發布,只需要調整一下各個docker的數量即可。
開始我們的架構很簡單,前端接收,經過各個模塊處理后存儲,然后統一進行處理分析,報表延遲很長,而且經常出問題需要手動補數據。
后來我們對架構進行了容器話的改造,而且引入了數據流式處理,每個region部署一個收集集群,frontend的數據可以buffer一周的時間,并且可以故障后續傳,通過Kafka匯總到我們的中央region的nrt系統進行準實時的數據匯總和分析,報表延遲可以控制到5分鐘以內,而且每個region的集群都可以像管理一臺機器一樣管理。?
這套系統我們團隊為他命名為Meissa,是獵戶座最亮的一顆星,他底層搭建在CoreOS上,用CoreOS只帶的etcd和Fleet進行集群的服務發現和編排管理,程序使用Docker進行打包,利用Jenkins進行發布,images保存在自建的docker-registry里面供集群使用。
這里舉個例子:
一個集群都用這個配置文件(可以根據不同用途修改metadata的名字),開機后會自動發現集群并且注冊到一起,如下圖:
這個是集群列表,標注每個host的名字方便調度
這個是units列表,看這個@符號,后面有1234,4臺機器上運行,之前服務端的同學寫個while true 腳本或者使用supervisor去判斷程序是否啟動,掛了拉起來,而且不可以跨服務器去守護進程,fleet可以幫你在符合條件的units任意一臺上面啟動這個服務,可以跨服務器。
etcd的discovery key已經把各個leader節點信息記錄到token的url里面,同步到各個節點,去個各個節點做服務注冊和發現。?
使用fleetctl可以隨需求安排程序的啟動,fleet相當于集群版systemd。
CMD ENTRYPOINT不建議使用,add和cp都一樣,ENTRYPOINT可以傳參數,還是寫到run里面ENTRYPOINT后面寫命令,“一個參數 空格 一個參數”,這樣寫的話轉義就出問題了,這是Docker的問題,用數組的方式[bash,-c];關閉進程用stop,不要直接kill進程,因為如果你寫了個shell腳本啟動你的程序,那么這個進程的pid=1為bash,kill掉的是bash,而不是你的容器程序, 或者使用exec,這樣會把子進程替換父進程;docker的stop會有一個tw時間,默認應該是60s,如果你的程序關閉比較慢,比如kafka需要落磁盤,60秒不夠怎么辦,可以手動傳入比較長的timeout時間;Docker默認的ulimit是1024,有時候發現你的Docker總是莫名重啟,可以看看是不是ulimit用盡了。
A:網絡上我們直接使用的host的方式,容器主要是看中了CI和CD的便利好沒有往高密度的場景設計的計劃,rkt是個好東西,更有開源的感覺,看后期Docker社區發展情況是否越來越封閉。 Q:registry怎么ha的,是在容器還是VM?
A:這個問題之前也是一直困擾著我們,我們用AWS的ELB做負載均衡,后端放2臺EC2,鏡像存到S3,緩存寫在Redis里,我們是使用官方的image,隨時用隨時上傳和使用,掛了就再啟動一個,不依賴長期有效的hub。 Q:最近暴漏的安全問題需要內核升級才能解決,這正是CoreOS的優勢、不必重啟系統,獵豹是否在線上有這種經驗?實際中CoreOS在升級內核時是否真那么方便?
A:這個是我們非常喜歡的一個特性,自動升級內核,做過運維的同學都知道,做一次內核升級是多么痛苦,我們最開始用的是stable766.4,現在都不用我們去升級就自動幫我們升級到8xx的stable版本了。 Q:集群中etcd節點數目是多少,奇數個etcd節點的優勢具體怎么體現的,以及etcd的代理節點在業務中的價值?
A:etcd很類似于ZooKeeper,leader節點必須是奇數個,我們一般是3個,最多5個,所有節點都會主動和leader節點通訊,leader節點可以運行在集群任何節點上,也可以通過API接口手動調整leader節點所在的底層服務器,很靈活,任何一臺都可以選舉成leader,不用部署任何額外配置,省心。 Q:編排調度都是自己開發的系統嗎,如何管理那么多的容器?
A:用的CoreOS自帶的模塊,etcd+fleet+systemd,很底層,登陸任何一臺機器做操作就可以管理整個集群,就像管理一臺機器一樣,我們把日常發布等操作基本都用Jenkins代勞了。
1、為什么選擇AWS和Docker
首先我先介紹一下獵豹移動的一些業務,如圖, 我們在海外有著龐大的用戶群體,接近16E下載量,月活用戶4.94E,71%來自海外,戰略合作伙伴主要以阿里、百度、騰訊、小米……?
這么大的海外用戶量我們是這么做業務部署和服務的呢?
首先在選擇服務商的方面我們選擇了實力最強的亞馬遜AWS作為我們的云服務商,我們海外幾乎所有的服務都是架構在AWS的平臺上面。
這給我們帶來了什么好處呢,總結起來有3點:
因為我們的用戶遍布全球,所以便捷的全球化部署是我們非常看重的,我們使用了AWS全球9個地區的region,其中包括美國3個,歐洲1個,亞太地區3個,南美洲1個,遍布全球 。
對于云服務,彈性的擴展是最為便捷的,可以在幾分鐘(而不是幾小時或幾天)內增加或減少服務器。可以同時管理一個、數百個,甚至數千個服務器實例。當然,因為這全是通過Web服務或API控制。
而且無需前期的投資,持續的成本優惠與調整;提高了資源利用率,按需付費;無需出國,管理世界各地的服務器,節約人力成本。
介紹完我們基礎平臺的選擇后,為了更好的自動化,集群化,我們開始接觸容器技術,而且是如何在AWS平臺上實現容器化。
我們把容器的概念進行理解:給你的應用程序“打包”,能夠執行一個“進程”,同時能把你執行的內容和其他“進程隔離”開來的東西,容器化有什么好處呢??
這些好處在所有網站上看到的東西,聽完這個介紹,感覺有點空洞,還是不知道是什么,我們用到的一些package,我再所有的系統里面都可以運行這些進程,而且進程隔離開,為什么還要Docker,這也是我們團隊剛剛接觸時遇到的困惑,除了Linux系統,最早提出容器化的VMware、Microsoft都有這方面的嘗試,只不過他們的容器是虛擬機,而互聯網的發展需要一個輕量級的容器。
這個圖是借鑒了Yahoo的架構,非常的可愛形象,比普通的架構圖更加生動,我們獵豹有很多廣告業務,商業的開發同學做的ADserver,也會有很多流式數據實時處理的系統,通過data highway匯聚到大數據處理系統,Hadoop、Spark計算,后端儲存我們用的是aws-s3。如果要完成這套系統,基礎架構,需要多少人力物力呢?可想而知,單單運維方面上百人的團隊就這樣建立起來了。
以往,我們一批機器只做一件事,比如100個adserver只做廣告接口,另外100臺機器只做廣告檢索,再有100臺機器做數據傳輸處理,某個模塊出問題去擴容或者處理某個模塊,這是大家最常見的方法。這對架構的高可用設計是個很大學問,需要多機房冗余,多地部署等等。如果引入微服務的概念呢??
如左邊圖,一臺機器上面只運行各自的模塊和依賴,不同機器各司其職,出問題處理問題模塊。而右邊微服務的設計,我無所謂我的程序如何分布,每臺host都可以部署多個模塊混合復用,自定義哪些模塊可以和哪些分配到同一臺host,哪些模塊不能和哪些模塊分配到同一臺host,一旦某個模塊掛掉,調度編排工具可以幫助馬上啟動一個新的docker替代工作。擴容的時候不需要針對不通模塊去部署和發布,只需要調整一下各個docker的數量即可。
2、為什么選擇CoreOS部署我們的應用
下面我介紹一下我們線上穩定運行很久的一個RCV日志處理集群的容器化改造過程,下圖是我們開始的架構圖:?開始我們的架構很簡單,前端接收,經過各個模塊處理后存儲,然后統一進行處理分析,報表延遲很長,而且經常出問題需要手動補數據。
后來我們對架構進行了容器話的改造,而且引入了數據流式處理,每個region部署一個收集集群,frontend的數據可以buffer一周的時間,并且可以故障后續傳,通過Kafka匯總到我們的中央region的nrt系統進行準實時的數據匯總和分析,報表延遲可以控制到5分鐘以內,而且每個region的集群都可以像管理一臺機器一樣管理。?
這套系統我們團隊為他命名為Meissa,是獵戶座最亮的一顆星,他底層搭建在CoreOS上,用CoreOS只帶的etcd和Fleet進行集群的服務發現和編排管理,程序使用Docker進行打包,利用Jenkins進行發布,images保存在自建的docker-registry里面供集群使用。
3、CoreOS在AWS平臺上如何快速構建集群,并且進行管理
在AWS上面開通一套CoreOS 的集群非常方便,只需要在AWS的鏡像倉庫里面 選擇合適的CoreOS版本,編寫好user-data(Linux的cloud-init)傳入正確的cloud-config即可,這個可以參考CoreOS的官網。這里說一下etcd token的使用,etcd的功能和ZooKeeper很相似,可以在私網自己通過IP定義leader的節點和數量,也可以通過官網進行token注冊,比較方便。這里舉個例子:
一個集群都用這個配置文件(可以根據不同用途修改metadata的名字),開機后會自動發現集群并且注冊到一起,如下圖:
這個是集群列表,標注每個host的名字方便調度
這個是units列表,看這個@符號,后面有1234,4臺機器上運行,之前服務端的同學寫個while true 腳本或者使用supervisor去判斷程序是否啟動,掛了拉起來,而且不可以跨服務器去守護進程,fleet可以幫你在符合條件的units任意一臺上面啟動這個服務,可以跨服務器。
etcd的discovery key已經把各個leader節點信息記錄到token的url里面,同步到各個節點,去個各個節點做服務注冊和發現。?
使用fleetctl可以隨需求安排程序的啟動,fleet相當于集群版systemd。
4、應用過程中遇到的問題與解決方案
fleet 配置文件編寫的一些技巧,如何合理編排自己的服務 。CMD ENTRYPOINT不建議使用,add和cp都一樣,ENTRYPOINT可以傳參數,還是寫到run里面ENTRYPOINT后面寫命令,“一個參數 空格 一個參數”,這樣寫的話轉義就出問題了,這是Docker的問題,用數組的方式[bash,-c];關閉進程用stop,不要直接kill進程,因為如果你寫了個shell腳本啟動你的程序,那么這個進程的pid=1為bash,kill掉的是bash,而不是你的容器程序, 或者使用exec,這樣會把子進程替換父進程;docker的stop會有一個tw時間,默認應該是60s,如果你的程序關閉比較慢,比如kafka需要落磁盤,60秒不夠怎么辦,可以手動傳入比較長的timeout時間;Docker默認的ulimit是1024,有時候發現你的Docker總是莫名重啟,可以看看是不是ulimit用盡了。
Q&A
Q:沒有用到Flannel,網絡實現是什么,未來對CoreOS的容器管理工具rkt的計劃?A:網絡上我們直接使用的host的方式,容器主要是看中了CI和CD的便利好沒有往高密度的場景設計的計劃,rkt是個好東西,更有開源的感覺,看后期Docker社區發展情況是否越來越封閉。 Q:registry怎么ha的,是在容器還是VM?
A:這個問題之前也是一直困擾著我們,我們用AWS的ELB做負載均衡,后端放2臺EC2,鏡像存到S3,緩存寫在Redis里,我們是使用官方的image,隨時用隨時上傳和使用,掛了就再啟動一個,不依賴長期有效的hub。 Q:最近暴漏的安全問題需要內核升級才能解決,這正是CoreOS的優勢、不必重啟系統,獵豹是否在線上有這種經驗?實際中CoreOS在升級內核時是否真那么方便?
A:這個是我們非常喜歡的一個特性,自動升級內核,做過運維的同學都知道,做一次內核升級是多么痛苦,我們最開始用的是stable766.4,現在都不用我們去升級就自動幫我們升級到8xx的stable版本了。 Q:集群中etcd節點數目是多少,奇數個etcd節點的優勢具體怎么體現的,以及etcd的代理節點在業務中的價值?
A:etcd很類似于ZooKeeper,leader節點必須是奇數個,我們一般是3個,最多5個,所有節點都會主動和leader節點通訊,leader節點可以運行在集群任何節點上,也可以通過API接口手動調整leader節點所在的底層服務器,很靈活,任何一臺都可以選舉成leader,不用部署任何額外配置,省心。 Q:編排調度都是自己開發的系統嗎,如何管理那么多的容器?
A:用的CoreOS自帶的模塊,etcd+fleet+systemd,很底層,登陸任何一臺機器做操作就可以管理整個集群,就像管理一臺機器一樣,我們把日常發布等操作基本都用Jenkins代勞了。
以上內容根據2016年10月25日晚微信群分享內容整理。分享人齊海澎(Kuma Qi),獵豹移動高級運維工程師。負責獵豹移動商業廣告產品與大數據相關產品的運維團隊管理,作為獵豹移動運維部的管理團隊成員,負責商業廣告業務和大數據計算在AWS服務上的穩定運行,并幫助公司開展容器技術的初步嘗試。3年AWS服務使用與運維經驗,運維全球8個region數以千計的計算服務資源,搭建并運維起跨5個地區的基于CoreOS的Docker集群。 DockOne每周都會組織定向的技術分享,歡迎感興趣的同學加微信:liyingjiesz,進群參與,您有想聽的話題或者想分享的話題都可以給我們留言。
原文發布時間為:2016-10-31
本文作者:齊海澎
本文來自云棲社區合作伙伴Dockerone.io,了解相關信息可以關注Dockerone.io。
原文標題:DockOne微信分享( 九十):獵豹移動基于CoreOS在AWS上的項目實踐
總結
以上是生活随笔為你收集整理的DockOne微信分享( 九十):猎豹移动基于CoreOS在AWS上的项目实践的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 【luogu 3811】【模板】乘法逆元
- 下一篇: 从尼古拉斯·泽卡斯开始学习