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

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

沈偉康，廣發(fā)銀行數(shù)據(jù)中心

運(yùn)維中年人，經(jīng)歷傳統(tǒng)運(yùn)維，建設(shè)自動化運(yùn)維，嘗試云計(jì)算運(yùn)維

大家好！我是廣發(fā)銀行的沈偉康，從傳統(tǒng)行業(yè)出身，現(xiàn)在還在傳統(tǒng)行業(yè)的坑里，今天分享的內(nèi)容是在傳統(tǒng)運(yùn)維會遇到的各種想做但是不一定能做，又不得不去做的事情。

無論是傳統(tǒng)運(yùn)維還是自動化運(yùn)維， CMDB是一個(gè)很重要的核心。如果Docker沒有自己的CMDB，也會有很多用起來不自在的地方。

從環(huán)境這方面來談一下CMDB對Docker的作用。如果所有事物都能標(biāo)準(zhǔn)化，那事情都會很簡單、很便利，這是一個(gè)很好的理想，但在現(xiàn)實(shí)里尤其傳統(tǒng)行業(yè)想把標(biāo)準(zhǔn)化進(jìn)行推廣，實(shí)現(xiàn)起來有一定的難度。

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

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

所以借鑒大家慣用的傳統(tǒng)運(yùn)維思路，并配有一個(gè)與以前傳統(tǒng)CMDB對接的點(diǎn)，廣發(fā)銀行有如下幾個(gè)做法：

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

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

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

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

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

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

第七，啟動運(yùn)行。等價(jià)于CMD，讓項(xiàng)目組在一個(gè)頁面設(shè)置完之后，把它放到與傳統(tǒng)CMDB對接的一個(gè)Docker專屬的CMDB里。

這個(gè)CMDB主要的內(nèi)容總結(jié)有三部分：環(huán)境需求配置，配置文件管理，應(yīng)用運(yùn)行配置。應(yīng)用運(yùn)行配置是項(xiàng)目組在一個(gè)頁面做完配置后，運(yùn)行和編譯的時(shí)候就不用再填參數(shù)了，所有不同的項(xiàng)目都在這里一次性設(shè)置好。

管理的緯度，配置是一個(gè)應(yīng)用加一個(gè)項(xiàng)目標(biāo)識。這個(gè)項(xiàng)目標(biāo)識可以理解成是按月度或者是按照自己喜歡的命名的規(guī)則，如海外版本和國內(nèi)版本。但對于廣發(fā)來說，用得比較多的是月度的標(biāo)識，例如一個(gè)應(yīng)用有ABC環(huán)境，分別對應(yīng)幾月份版本。

這里把鏡像分成三類：第一類，基礎(chǔ)環(huán)境鏡像，上面只有OS還有一些依賴庫的安裝，一個(gè)運(yùn)行的中間件。它會有一個(gè)命名規(guī)則， “應(yīng)用名+項(xiàng)目標(biāo)識”，比如“ABC_”，然后“201701”，就是2017年1月份版本，“base”表示鏡像的tag是base，表示這是它的一個(gè)基礎(chǔ)環(huán)境鏡像。

第二類是應(yīng)用版本鏡像，在第一個(gè)基礎(chǔ)環(huán)境鏡像上加了編譯后的目標(biāo)碼，不帶環(huán)境差異的配置文件。這時(shí)命名規(guī)則是“應(yīng)用名+項(xiàng)目標(biāo)識”，tag變成了目標(biāo)碼的時(shí)間戳，在持續(xù)集成整條線下有一個(gè)唯一的標(biāo)識，就是時(shí)間戳。當(dāng)然，大家也會有其它各種各樣的唯一標(biāo)識選擇。

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

與傳統(tǒng)的過程項(xiàng)目相比，廣發(fā)的過程主要是搭建一個(gè)應(yīng)用的OS環(huán)境，安裝相應(yīng)的中間件，然后部署相關(guān)的應(yīng)用目標(biāo)碼。用Jenkins去持續(xù)集成出它整個(gè)應(yīng)用版本鏡像。整個(gè)過程就是應(yīng)用版本鏡像，加上測試的環(huán)境配置，它就變成測試環(huán)境的應(yīng)用運(yùn)行鏡像，加上生產(chǎn)的配置就變成生產(chǎn)環(huán)境的應(yīng)用運(yùn)行鏡像。

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

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

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

它按照war包的相對路徑將配置文件打包成一個(gè)tar。然后把這個(gè)tar上傳到不同的環(huán)境目錄，例如它有三個(gè)階段，一個(gè)是開發(fā)，一個(gè)是測試，一個(gè)是生產(chǎn)，那它就會有三個(gè)目錄，這三個(gè)目錄由不同的運(yùn)維人員編輯，開發(fā)環(huán)境的原則上不用改，因?yàn)楸緛砭褪菑拈_發(fā)來的；測試環(huán)境要由測試環(huán)境的運(yùn)維同學(xué)，把那些DBURL、數(shù)據(jù)庫用戶等配置按實(shí)際情況修改，生產(chǎn)環(huán)境也類似。

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

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

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

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

測試環(huán)境的運(yùn)行到生產(chǎn)上來說也是同樣一個(gè)過程，廣發(fā)還有一個(gè)準(zhǔn)生產(chǎn)環(huán)境，整個(gè)過程也都是類似的，準(zhǔn)生產(chǎn)環(huán)境是與測試環(huán)境共用的。生產(chǎn)環(huán)境也是由版本鏡像加上配置文件。所有從應(yīng)用版本鏡像生成運(yùn)行鏡像的過程都是可以不斷迭代自動化的，運(yùn)行的時(shí)候就會在環(huán)境里面跑起來。

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

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

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

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

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

現(xiàn)在傳統(tǒng)運(yùn)維里面一個(gè)應(yīng)用可不可用，尤其是在銀行里可不可用影響是很大的，所以廣發(fā)銀行在運(yùn)維體系里有很多應(yīng)用對外暴露的一些服務(wù)接口，然后通過自動化的監(jiān)控工具去監(jiān)控它的可用性。從這個(gè)角度來說，調(diào)度器可以與傳統(tǒng)監(jiān)控對接，通過調(diào)用傳統(tǒng)運(yùn)維的內(nèi)容獲取到一個(gè)服務(wù)狀態(tài)可用的時(shí)候才去執(zhí)行五個(gè)升級兩個(gè)，再升級三個(gè)這個(gè)動作。

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

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

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

但是到了容器，如果放任調(diào)度器自動回收、自動縮容，是否真的可取？和剛才提到的銷毀時(shí)間一樣，是否要與傳統(tǒng)的監(jiān)控、服務(wù)可用的平臺做一個(gè)對接后再縮？如果可以做到才是真正能夠縮的，而不是現(xiàn)在頁面上選擇五個(gè)縮成三個(gè)，它就真的縮了兩個(gè)，至少我們在生產(chǎn)當(dāng)中是不敢這樣做的。

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

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

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

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

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

在傳統(tǒng)行業(yè)里面要對接傳統(tǒng)監(jiān)控一定是必然的。對接的過程可以分成幾個(gè)緯度，一是Docker與平臺自身的監(jiān)控，可以通過接口去對接、上送數(shù)據(jù)。另一個(gè)是宿主機(jī)的監(jiān)控，宿主機(jī)是一個(gè)物理OS，傳統(tǒng)監(jiān)控里面如何折騰這個(gè)OS已經(jīng)是很標(biāo)準(zhǔn)或者很自然的動作。

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

在容器化的網(wǎng)絡(luò)里，除了一些對外暴露的端口， Docker DB就不用說了。但是在應(yīng)用的端口里面，假設(shè)是HaProxy， HAProxy的端口可用不表示相應(yīng)容器的服務(wù)是可用的，可以嘗試直接在監(jiān)控HaProxy這些端口服務(wù)的同時(shí)直接讓應(yīng)用暴露服務(wù)可用性的一個(gè)接口，直接監(jiān)個(gè)應(yīng)用接口的返回碼究竟是200或是非200就可以了。

應(yīng)用改造只列了四點(diǎn)，并不表示應(yīng)用改造只有四點(diǎn)，而是努力讓應(yīng)用只做這四點(diǎn)，只關(guān)注這四點(diǎn)就可以了。

第一是節(jié)點(diǎn)差異化，在環(huán)境里假設(shè)有三臺應(yīng)用服務(wù)器，其中一臺應(yīng)用服務(wù)器做了一些其它兩臺應(yīng)用服務(wù)器沒有的事情。這種情況在廣發(fā)或者金融行業(yè)里都是比較多的。到了Docker之后，就盡量不要做這種事情。

第二是持久化，在廣發(fā)的環(huán)境里面，舉一個(gè)數(shù)據(jù)，OS里面的外掛存儲很少少于500G的。一個(gè)OS如果要做動態(tài)擴(kuò)縮，里面的存儲越少越好，因?yàn)椴恍枰屗銎渌虑?。如果要把一個(gè)文件持久化，是因?yàn)镮O的性能問題需要把它外掛，還是日志不屬于容器銷毀而持久化？或是這個(gè)容器在A宿主機(jī)跑起來，下一次在B宿主機(jī)跑起來，都要讀寫同樣一份東西，那么就搬到NFSDATA的一個(gè)文件里面，選NAS data作為一個(gè)volume，配置文件配上那個(gè)路徑。

在內(nèi)存數(shù)據(jù)里面，建議做一個(gè)剝離，比如剝離到REDIS，但是如果在有統(tǒng)一的應(yīng)用開發(fā)框架情況下要把一些東西剝離出來，只要有框架內(nèi)的應(yīng)用去改造就可以。如果不是的話，可以采用一些天然比較支持這種轉(zhuǎn)換的，例如把數(shù)據(jù)放到Redis，有一些框架直接支持改一下配置就可以，另一些框架則是不行的。

第三是可變性。以前傳統(tǒng)運(yùn)維會把上游IP抓下來，下發(fā)到下游。但容器的OS環(huán)境變量是可變的， IP地址獲取方式，變成從環(huán)境變量獲取。Hostname是不建議使用的，以前看到把Hostname作為一個(gè)標(biāo)準(zhǔn)傳到日志里面或者直接用來起日志共享目錄的一個(gè)名字，到云里面跑得久越讀不懂，至少IP的名字都讀不懂，因?yàn)闆]有一個(gè)人去干預(yù)它的Hostname。

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

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