摘要：所以借鑒大家慣用的傳統運維思路，并配有一個與以前傳統對接的點，廣發銀行有如下幾個做法第一，操作系統。所以廣發使用了一個配置文件包。版本流程這是廣發銀行持續集總的框架。

數人云上海&深圳兩地“容器之Mesos/K8S/Swarm三國演義”的嘉賓精彩實錄第一彈來啦。今天是廣發銀行數據中心的運維老兵沈偉康關于傳統運維與容器適配的全方位分享，萬字長文傾情奉上~

沈偉康，廣發銀行數據中心

運維中年人，經歷傳統運維，建設自動化運維，嘗試云計算運維

大家好！我是廣發銀行的沈偉康，從傳統行業出身，現在還在傳統行業的坑里，今天分享的內容是在傳統運維會遇到的各種想做但是不一定能做，又不得不去做的事情。

無論是傳統運維還是自動化運維， CMDB是一個很重要的核心。如果Docker沒有自己的CMDB，也會有很多用起來不自在的地方。

從環境這方面來談一下CMDB對Docker的作用。如果所有事物都能標準化，那事情都會很簡單、很便利，這是一個很好的理想，但在現實里尤其傳統行業想把標準化進行推廣，實現起來有一定的難度。

它會面臨一個問題：差異化。差異化多了以后，Docker就會有各種各樣的鏡像，不同應用之間會有不同的鏡像。即便是同一個應用，不同的月度版本下都有不同的鏡像，比如升級了某一個庫，鏡像也是不一樣的，這時候應該怎么做呢？這時按正常邏輯，會給它做自定義。如果要自定義Docker的一個鏡像，可以通過DockerFile來做。

現在各大廠商的產品里面幾乎都有一個WebUI的界面讓用戶去選擇一些內容，可以自主編程一個DockerFile。如果只是單純地把里面一些FROM、ADD參數直接加到頁面上去選的話，至少要有一定的適配過程。

所以借鑒大家慣用的傳統運維思路，并配有一個與以前傳統CMDB對接的點，廣發銀行有如下幾個做法：

第一，操作系統。對著DockerFile的FROM，讓它在列表里選擇這個應用要跑在什么樣的OS里面，包括它的版本等。

第二，常用軟件。在下拉框選完之后是一個ADD，例如選了JAVA，要在Docker運行環境里面給它環境變量，容器里要找到JAVA相關的命令。Tomcat或者其它軟件，都會有一些環境變量。所以在常用軟件這塊，現在打包的大部分是Tomcat或者JAVA類軟件，把一些特定要使用的環境變量，根據這個頁面選完之后，用ADD添加軟件包的同時，用ENV把它設到環境變量中。

第三，需求包上傳，對于差異化來說很重要。例如這個項目組的應用依賴某個Python版本，另一個項目組又依賴另一個版本的Python，又如OS自帶的一些so庫，它到下個月度版本的時候又要依賴不同的版本，但是不想把這么多版本都做成不同的鏡像提供不同的服務市場，就會有一個需求包上傳，這個包里把項目組應用需求的除了常用軟件跟OS基本的套件之外的其他庫或者軟件打包，比如Python的安裝包，RPM包，還有一些應用自身的東西，如啟動的時候需要加載的證書之類都打包在這個包里。

第四，執行安裝。這個包打完之后，為它定義一個執行安裝過程的入口，即一個安裝腳本，約定的時候讓它將安裝腳本放在壓縮包的第一個目錄下。這個包就相當于有了setup.sh的一個入口，這個入口讓應用去定義安裝什么、如何安裝以及安裝順序。

第五，映射端口。對應DockerFile的EXPOSE，應用、服務或者容器啟動完之后，會對外暴露哪一些端口。

第六，存儲使用。存儲路徑選擇對應VOLUMN，如果IO要求比較高就不用容器內部的AUFS，如果要求持久化就用外掛路徑，如果宿主機之間共享就需要放到一些分布式存儲或者NAS這種共享存儲里面。

第七，啟動運行。等價于CMD，讓項目組在一個頁面設置完之后，把它放到與傳統CMDB對接的一個Docker專屬的CMDB里。

這個CMDB主要的內容總結有三部分：環境需求配置，配置文件管理，應用運行配置。應用運行配置是項目組在一個頁面做完配置后，運行和編譯的時候就不用再填參數了，所有不同的項目都在這里一次性設置好。

管理的緯度，配置是一個應用加一個項目標識。這個項目標識可以理解成是按月度或者是按照自己喜歡的命名的規則，如海外版本和國內版本。但對于廣發來說，用得比較多的是月度的標識，例如一個應用有ABC環境，分別對應幾月份版本。

這里把鏡像分成三類：第一類，基礎環境鏡像，上面只有OS還有一些依賴庫的安裝，一個運行的中間件。它會有一個命名規則， “應用名+項目標識”，比如“ABC_”，然后“201701”，就是2017年1月份版本，“base”表示鏡像的tag是base，表示這是它的一個基礎環境鏡像。

第二類是應用版本鏡像，在第一個基礎環境鏡像上加了編譯后的目標碼，不帶環境差異的配置文件。這時命名規則是“應用名+項目標識”，tag變成了目標碼的時間戳，在持續集成整條線下有一個唯一的標識，就是時間戳。當然，大家也會有其它各種各樣的唯一標識選擇。

第三種叫應用運行鏡像，它是上面應用版本鏡像再加上環境配置文件。開發環境有它自己的數據庫，各種不同的環境都會有自己的數據庫配置，這個配置是不一樣的。如果說抽象成配置中心的話，它可以管理，但還是用配置文件。命名規則是“應用名+項目標識”，再加“目標碼時間戳”和“環境”。環境包括DEV開發環境、TEST測試環境以及PROD生產環境。最后是“配置文件時間戳”，一個項目組在項目初始的時候定義的配置文件內容有四個配置項，過了一段時間可能變成五個配置項，所以還是一個時間戳，即配置文件的時間戳，以此去標識一個完整的運行鏡像。

與傳統的過程項目相比，廣發的過程主要是搭建一個應用的OS環境，安裝相應的中間件，然后部署相關的應用目標碼。用Jenkins去持續集成出它整個應用版本鏡像。整個過程就是應用版本鏡像，加上測試的環境配置，它就變成測試環境的應用運行鏡像，加上生產的配置就變成生產環境的應用運行鏡像。

為什么做配置文件而不做配置中心？推廣配置中心的話，應用要改很多內容。傳統應用里面很多配置都是寫在配置文件里面的。如果要把配置文件改成從一個庫里面讀出來，舉例開發環境，它的IP要有一個配套的插件從數據庫里面把配置抽取出來，取代它原本的配置文件，才能在環境里面做它的開發；或者也可以做一個類似Eclipse插件去做這個事情，但配套的東西還是要很多。如果為了上Docker要去推動這個事，它會變得很現實：第一，時間長；第二，阻力大。

另外一個方法就是環境變量。相對數據庫形式的配置中心來說，環境變量稍微簡單了一點，但是它要求項目組有一個人去抽離出配置文件里面各項的配置，然后轉變成環境變量，再告訴項目組 “原本的DBURL配置”，代碼里面需要變成System.getEnv()來獲取DBURL，而不再用getProperty讀出來。

所以廣發使用了一個配置文件包。這個配置文件包是一個tar，不會限制它有一個很嚴肅的名字，但是它的目錄格式規則有一個限制的規則，它的第一個目錄是最終訪問的子URL，也就是TOMCAT的webapps下看到的目錄。然后將所有的配置，假設最下面示例，應用有三個配置文件，要求它嚴格按照相對路徑，把最終的相對路徑打包好，打包成一個tar。

它按照war包的相對路徑將配置文件打包成一個tar。然后把這個tar上傳到不同的環境目錄，例如它有三個階段，一個是開發，一個是測試，一個是生產，那它就會有三個目錄，這三個目錄由不同的運維人員編輯，開發環境的原則上不用改，因為本來就是從開發來的；測試環境要由測試環境的運維同學，把那些DBURL、數據庫用戶等配置按實際情況修改，生產環境也類似。

之后用一個最簡單的DockerFile，即FROM應用版本鏡像，再ADD，將配置文件到指定路徑，假設是Tomcat就是webapps目錄下，因為ADD會自動解壓，自動地把它覆蓋成一個真正的相應測試環境的運行鏡像、測試環境的運行鏡像、生產環境的運行鏡像。項目組只要找一個人把這些配置文件抽出來就可以了。很久以前我們已經謝絕所有把配置硬解到代碼里面去，所以這種場景不適合。在JAVA里面直接寫一個環境的數據庫鏈接上面，但是它應該適用于把配置所有都抽離出一個文件里面或者說某個文件里面。

這是廣發銀行持續集總的框架。代碼用Git，有一個目標碼庫，以及配置庫。雖然上了Docker，但是沒有舍去傳統的環境。WAR包是持續集成編譯一次后的war包，存起來并開放給傳統部署的同事下載使用。配置庫是剛才提到的存配置文件的地方。測試鏡像庫是獨立的，它們之間的同步是通過腳本去自動同步的，即export出來的鏡像，一個pull，一個push。

開發人員寫代碼，寫完代碼之后提交，提交完會由Jenkins自動下載回來編譯。在這個過程中有一個FindBugs來做的代碼審查。然后編譯生成一個war包，這個war包到這一階段理論上與正常持續集成過程或者是人工編譯后的war包一樣。這時如果需要傳統部署，可以通過FTP把war包下載回來，投產直接使用。

如果要用Docker，這個war包會加上它的第一個鏡像：應用基礎環境鏡像，生成它的一個應用版本鏡像；應用版本鏡像生成完之后，加上測試環境的配置文件，它就會變成測試環境的運行鏡像；這個測試環境的鏡像只要運行起來，就會變成一個測試環境；測試環境是由測試員測試的，或者由一個自動化的工具做自動化測試。

測試環境的運行到生產上來說也是同樣一個過程，廣發還有一個準生產環境，整個過程也都是類似的，準生產環境是與測試環境共用的。生產環境也是由版本鏡像加上配置文件。所有從應用版本鏡像生成運行鏡像的過程都是可以不斷迭代自動化的，運行的時候就會在環境里面跑起來。

在傳統運維里如果拿到一個虛擬機，它有固定的IP或者DNS域名，想對它做什么就可以進去做，可以查看數據或者性能，尤其是在查性能問題的時候要看OS里面的資源使用情況，還有一些應用的狀態，包括OS的狀態。而這些東西到了Docker里面，就會變得有很多的阻力。

如果Docker容器里出了性能問題的話，要如何查？如果按照傳統的觀念，要SSH到容器里面去做，例如說有一個應用，Tomcat到了90%，那是否一定要在生產環境要保留這個環境，讓應用開發的人去查？還是直接毀掉它，重新起一個或者兩個，業務量就不受任何影響，這種事情因人而異。

另一個方法，可以把這些簡單的交互分成兩類，一是查看類型的需求，嘗試通過外掛目錄，因為假設要查看生成的javacore、heapdump文件等，以前做法是在OS里面使用kill-3生成heapdump文件，但如果把這些生成heapdump的動作歸結為第三點操作類的話，是不是可以直接在宿主機上放一個agent，要對哪個容器做heapdump相當于讓用戶在頁面上直接選一個生成heapdump或者一個動作，然后由agent通過EXEC命令跑到容器里面去做，盡量禁止用戶直接跟容器進行交互。當然也有比較粗暴的，比如WebSSH。

應用更新的概念是服務沒有中斷。人們常說的滾動升級，在很多產品里面都實現了。但是實現的層面或許是這樣的：假設有五個容器，滾動升級是按批的，第一批升級兩個，升級完之后毀掉舊容器，用新的兩個容器去換掉舊的兩個容器，隔一段時間再升級后面的三個。這種按批升級會有一個需要關注的地方——容器銷毀的時機。

常見的云平臺調度算法里，容器狀態OK的時候，調度平臺會把原本的容器替換掉，但這個時候容器狀態OK并不等于服務可用，因為容器里的Tomcat端口起來之后，它就會說這個容器是已經OK了，但是Tomcat起來之后的服務加載這個過程，快的話可以幾秒，慢的話例如一個很龐大沒有做任何微服務化改造的應用，就會是一分鐘。但這一分鐘之間，新的容器已經替換掉舊容器，那么這一分鐘就悲劇了。所以服務加載的時間不能夠忽略。容器銷毀的時機是要大于容器狀態OK的時間加上應用自啟動的時間，在容器的調度上至少要用戶每個項目組加上服務要起的時間，要十秒就填十秒，十秒鐘之后再按照按批滾動升級的過程去做。

現在傳統運維里面一個應用可不可用，尤其是在銀行里可不可用影響是很大的，所以廣發銀行在運維體系里有很多應用對外暴露的一些服務接口，然后通過自動化的監控工具去監控它的可用性。從這個角度來說，調度器可以與傳統監控對接，通過調用傳統運維的內容獲取到一個服務狀態可用的時候才去執行五個升級兩個，再升級三個這個動作。

第二要關注流量轉移，在服務啟動完之后，通過負載均衡自動去設置權重把新的流量轉移到新的容器里面。因為有一個容器銷毀的時機，所以這個容器也不會銷毀，但是不要把新請求轉給它。在傳統行業，如果新容器或者服務好了、舊容器就馬上關掉的話，應用的架構不一定能夠支持。在生產上尤其是在銀行，例如在轉賬的時候有一個交易流程，在一個容器里面規定要1、2、3、4、5步發生，并不是第一步做完放到一個地方，然后由其他任何一個人去調第二步都可以。如果把1、2、3、4、5都串到一個容器里面，做到第三步的時候舊容器服務被停了，又沒有對外的轉賬接口去把錢轉到別人那里去，后果就很嚴重，所以流量轉移工作包括銷毀的時間是要慎重的。

在很多廠商那里都會聽到灰度發布，但是大部分都只是說沒有中斷。這個中斷是不是真的沒有中斷，有待考究。廣發會強調另外一個A/B TEST。如果通過負載均衡去設置，舉一個簡單的例子，通過F5或者其它LVS負載均衡去設置來源IP來選擇新版本還是舊版本是沒問題的。但是來源IP是可以欺騙的，像以前Pokemon go出來的時候，人不在國外，但是搞一個國外的IP也可以上。所以在應用可以接受的情況下，灰度發布應該由應用的人去做，例如每一個賬號生成了唯一的ID，由ID決定他們是用新版本還是用舊版本。盡量不要用負載均衡來做灰度發布。

現在彈性擴容至少會講到兩點：一個是業務時間點，比如九點到十點這個業務時間點，可以把容器從十個變成二十個；另一個是通過監控策略來自動化彈性擴容。擴其實很簡單，從十個變成二十個沒什么問題。但是擴完之后要縮回來，比如要應對某一個節日“雙11”，找一個特定的時間點給它加OS，但是加完OS之后縮回來需要一個停機時間窗口，或者先從F5上Disable然后回收。

但是到了容器，如果放任調度器自動回收、自動縮容，是否真的可取？和剛才提到的銷毀時間一樣，是否要與傳統的監控、服務可用的平臺做一個對接后再縮？如果可以做到才是真正能夠縮的，而不是現在頁面上選擇五個縮成三個，它就真的縮了兩個，至少我們在生產當中是不敢這樣做的。

均衡資源。假設傳統運維里，把Docker的宿主機交給傳統運維的監控平臺去監控，但這時監控平臺判斷這臺宿主機已經CPU使用率90%了， Docker調度器與傳統運維的監控平臺做對接的時候，為了不影響應用服務是否需要把容器給遷走，是全部遷走還是把CPU消耗高的遷走，或者把啟動時間最長的遷走？作為一個程序員永遠都不敢說自己寫的程序跑了一段時間之后會不會比剛剛跑起來的時候更穩定。這種策略在生產實踐是很關鍵的，需要一個博弈的過程。現在很多廠商自身支持各種各樣的彈性，但是彈性縮是否真的能夠支持而不會有業務影響，是有待考究的。

目前來說，沒有任何一個廠商說“只要用我的平臺，包括把我的平臺堆積到傳統運維之后，可以做到想縮就縮，不會讓用戶賬戶丟了錢”，不用讓業務員去做一個回滾的操作。在傳統運維里面，如果應用開發的項目組可以按照各種各樣優雅關閉的特性去寫應用，沒問題。但畢竟業務程序是由人寫的，人是不可控的。

在傳統的應用容器化運行后，會有一個歸檔和查看日志的問題。目前項目組把它改成標準輸出，再由自動的一個收集平臺，例如廣發銀行現在是用數人云的一個logagent去自動收logstash的，然后存儲到ES里面，由Kibana去展示。如果要對接傳統運維，也可以讓項目組把應用的目錄放到一個外掛的文件。傳統的監控里面有一個外掛支持在某一個路徑下監測所有的配置文件，所以只要把它放到一個外掛的共享存儲或者分布式存儲，然后再把這個外掛路徑作為一個對接的入口到傳統的日志管理平臺里面就可以了。

另一種是以前做CloudFoundry時，他們會強調應用要把所有的日志作為流寫入到這個平臺里面，例如FLUME。如果只是簡單粗暴地把應用的日志寫進去，會有時間亂序的問題，當然這個問題是可以解決的，但如果A容器實例跟B容器實例都是屬于同一個應用，就會有這里來了一句之后，那里下一句話又來了的情況。要截取某一個加密的日志，需要開發人員配合在日志里面加各種各樣的標識，例如現在要查詢某一個業務量的日志，要根據業務量的代碼去查，查完之后它能夠抽取出來在同一個容器里面的那一段日志，那如何做到在同一個容器？無疑在寫日志的時候，也需要把容器的標識放在日志里面。

如果做實時，用syslog就可以。如果只是日志收集，ELK也是可以滿足的。為了減少應用改造，單應用日志時就重定向到標準輸出。如果是多個日志，現在考慮的方案是把它放到一個外掛目錄，再由專門的容器去收上送，而不會通過其它的agent。外掛目錄也是可以對接傳統的應用日志監控平臺，傳統運維里面可以有一個監控平臺去監控這個日志的增量更新里面有沒有應用關注的關鍵字，如果有這個關鍵字的話，就會發短信提醒說應用出現了什么異常。

在傳統行業里面要對接傳統監控一定是必然的。對接的過程可以分成幾個緯度，一是Docker與平臺自身的監控，可以通過接口去對接、上送數據。另一個是宿主機的監控，宿主機是一個物理OS，傳統監控里面如何折騰這個OS已經是很標準或者很自然的動作。

容器監控，可以嘗試cadvisor或者其它在業界應用比較多的東西。應用監控比較難，傳統運維會關注應用CPU和內存使用率，以及數據源的連接詞，或者一些線程數，當達到某一個值后，就進行告警。而到了容器里面，要把它抽離出來。舉一個例子，它可以把Tomcat里面的Apache公布的那一堆指標通過Tomcat的接口給暴露出來。暴露到哪里，是需要額外去定制化、去收集容器里面的Tomcat，所以對不同的工具要做一個對接的過程。

在容器化的網絡里，除了一些對外暴露的端口， Docker DB就不用說了。但是在應用的端口里面，假設是HaProxy， HAProxy的端口可用不表示相應容器的服務是可用的，可以嘗試直接在監控HaProxy這些端口服務的同時直接讓應用暴露服務可用性的一個接口，直接監個應用接口的返回碼究竟是200或是非200就可以了。

應用改造只列了四點，并不表示應用改造只有四點，而是努力讓應用只做這四點，只關注這四點就可以了。

第一是節點差異化，在環境里假設有三臺應用服務器，其中一臺應用服務器做了一些其它兩臺應用服務器沒有的事情。這種情況在廣發或者金融行業里都是比較多的。到了Docker之后，就盡量不要做這種事情。

第二是持久化，在廣發的環境里面，舉一個數據，OS里面的外掛存儲很少少于500G的。一個OS如果要做動態擴縮，里面的存儲越少越好，因為不需要讓它做其它事情。如果要把一個文件持久化，是因為IO的性能問題需要把它外掛，還是日志不屬于容器銷毀而持久化？或是這個容器在A宿主機跑起來，下一次在B宿主機跑起來，都要讀寫同樣一份東西，那么就搬到NFSDATA的一個文件里面，選NAS data作為一個volume，配置文件配上那個路徑。

在內存數據里面，建議做一個剝離，比如剝離到REDIS，但是如果在有統一的應用開發框架情況下要把一些東西剝離出來，只要有框架內的應用去改造就可以。如果不是的話，可以采用一些天然比較支持這種轉換的，例如把數據放到Redis，有一些框架直接支持改一下配置就可以，另一些框架則是不行的。

第三是可變性。以前傳統運維會把上游IP抓下來，下發到下游。但容器的OS環境變量是可變的， IP地址獲取方式，變成從環境變量獲取。Hostname是不建議使用的，以前看到把Hostname作為一個標準傳到日志里面或者直接用來起日志共享目錄的一個名字，到云里面跑得久越讀不懂，至少IP的名字都讀不懂，因為沒有一個人去干預它的Hostname。

第四是易處理，快速啟動，優雅關閉。以微服務化改造來說，能夠做到易處理，即隨時啟動的時間不會超過幾秒，隨時都可以關閉，如果應用上Docker并且要跑得很好的話，那一定要去考慮這方面的事情。

分享就到這里，謝謝大家。