摘要：本文是數(shù)人云工程師方志浩在微信群分享的實錄，與大家聊一聊應(yīng)用容器在配置管理中遇到的問題以及解決方法。數(shù)人云分測試演示生產(chǎn)三種環(huán)境進行持續(xù)集成發(fā)布，同時數(shù)人云組件通過進行應(yīng)用容器的封裝下發(fā)和管理。

本文是數(shù)人云工程師方志浩在DockOne微信群分享的實錄，與大家聊一聊應(yīng)用容器在配置管理中遇到的問題以及解決方法。

隨著Docker技術(shù)的火熱發(fā)展， Docker在代碼構(gòu)建發(fā)布中扮演著越來越重要的角色。Docker讓開發(fā)者可以打包他們的應(yīng)用以及依賴包到一個可移植的容器中，然后發(fā)布到流行的Linux機器上。Docker非常適用于如下場景：

應(yīng)用容器的自動化打包和發(fā)布；

自動化測試和持續(xù)集成、發(fā)布。

這次主要和大家聊聊應(yīng)用容器在配置管理中遇到的問題。首先是介紹現(xiàn)有容器常用的配置文件加載方式，接下來重點介紹數(shù)人云組件在自動化打包和發(fā)布遇到的問題和解決方法。

首先簡單介紹下現(xiàn)有容器的加載配置文件的方式。

掛載宿主機配置文件的方式

通過docker run -v 參數(shù)將宿主機上的配置文件掛載到容器指定目錄中如：

docker run -v /myredis/conf/redis.conf:/usr/local/etc/redis/redis.conf --name myredis redis redis-server /usr/local/etc/redis/redis.conf

這種方式對于單實例應(yīng)用比較方便。

下載配置中心文件的方式

這種方法首先需要建立配置中心，例如用Nginx等Web服務(wù)組件，提前將配置文件放在指定目錄，在Dokcerfile entrypoint中拉取配置中心文件的腳本，之后容器啟動就自動拉取配置中心的配置。

通過環(huán)境變量傳入到容器中

通過docker run -e 參數(shù)將將環(huán)境變量傳入到容器如：

docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:5.6

數(shù)人云組件采用微服務(wù)架構(gòu)，將服務(wù)拆分，分別采用相對獨立的服務(wù)對各方面進行管理，彼此之間使用統(tǒng)一的接口來進行交流，架構(gòu)變得復(fù)雜，但優(yōu)勢非常明顯。為了保證高可用，這些容器一般都運行在多個VM上，服務(wù)實例前是一層諸如HAPROXY的負載均衡器，它們負責(zé)在各個實例間分發(fā)請求。數(shù)人云分測試、演示、生產(chǎn)三種環(huán)境進行持續(xù)集成、發(fā)布，同時數(shù)人云組件通過Docker+Mesos+Marathon進行應(yīng)用容器的封裝下發(fā)和管理。首先說下我們?nèi)萜靼l(fā)布遇到的問題——配置文件多，如何進行統(tǒng)一的管理？

我們由于采用微服務(wù)架構(gòu)，就產(chǎn)生了各個模塊的配置，導(dǎo)致配置文件過多；其次數(shù)人云的三套環(huán)境，如MySQL等基礎(chǔ)組件IP、Port等配置不同，導(dǎo)致配置成倍增加；最后采用高可用架構(gòu)，也造成了配置文件的增多。 下面是數(shù)人云Mesos系統(tǒng)架構(gòu)流程圖：

Marathon、Jenkins作為Framework注冊在mesos-master上，動態(tài)調(diào)度mesos-slave資源。

Marathon負責(zé)應(yīng)用的發(fā)布

Jenkins負責(zé)代碼打包、鏡像構(gòu)建

Mesos Framework截圖如下：

若單純-v的掛載方式需提前將配置文件放在mesos-slave所在的宿主機上，新加slave時也需進行相同的操作，且當(dāng)配置文件需要更新時，需更新每臺mesos-slave宿主機上的配置文件，這顯然不夠靈活，所以我們剛開始采用應(yīng)用容器啟動下載配置中心文件的方式。

早期的配置中心，如下圖所示：

此時存在的問題有：

因為是多種環(huán)境，雖然把這些配置都在Configserver上集中配置，但是需要手動修改這些配置。手動修改容易出錯，例如Dev更新了一個服務(wù)，可能過了一周才會更新到生產(chǎn)環(huán)境。那個時候再去修改生產(chǎn)就很容易出錯，導(dǎo)致無法運行。

如果配置發(fā)生了Bug需要回滾，手動修改也是不合適的。

我們進行了改進，引進Jenkins后工作流程如下圖：

我們用Jenkins把它們整體串起來，我們的第一個工作是把所有的配置文件抽象化，各種環(huán)境的文件抽象出來一個模板，放在GitLab上。它的數(shù)據(jù)是放在數(shù)據(jù)庫里面，這樣組合起來是一個完整的配置文件。各個環(huán)境的值是不一樣的。 我們的運維平臺觸發(fā)Jenkins，Jenkins去調(diào)度我們的ConfigCenter API，它傳入兩個參數(shù)，一個是需要更新的環(huán)境，另一個是更新哪個服務(wù)。之后API去做對比，從數(shù)據(jù)庫去讀現(xiàn)有的配置文件的模板Tag，再去讀新模板的Tag進行對比。

如果這個文件需要更新，把它從數(shù)據(jù)庫拉過來，數(shù)據(jù)做匹配，渲染成我們最終的配置文件，再傳到Gitlab上。剩下的通過Jenkins 觸發(fā) Configserver去調(diào)Gitlab下載最新的配置文件到Configserver服務(wù)器，Jenkins再去調(diào)用Marathon去重啟服務(wù)，服務(wù)就會成功更新配置文件。 這很好解決了配置文件對應(yīng)文件，但還是存在以下一些問題：

配置格式不統(tǒng)一，配置有env 、congfig.js 、.yaml 、.xml 等配置文件，各種配置文件需要在應(yīng)用容器發(fā)布前進行替換，當(dāng)新增配置文件項時，需重新編寫模版，替換匹配內(nèi)容較為繁瑣。

Marathon發(fā)布應(yīng)用采用了配置文件的方式，在Marathon界面看不到配置文件的內(nèi)容，需后臺查看，增加了運維復(fù)雜度。

后來我們對應(yīng)用進行env化改造，統(tǒng)一配置文件格式，且配置通過變量傳遞給Marathon，使得所有配置在Marathon界面上可見 。

以下是具體的工作，我們對開發(fā)進行了規(guī)約。

除了代碼和產(chǎn)品開發(fā)的一些文件外，還需要規(guī)約一下目錄結(jié)構(gòu)：

module_name -
          |
           -deploy -
                    |
                    -env  
                    |
                    -deploy-marathon.sh
                    |
                    -compile.sh
           |
            -dockerfiles -
                         |
                         -Dockerfile_compile_env
                         |
                         -Dockerfile_runtime
                     

在GitHub中更新env文件，這個由開發(fā)提供維護，里面有對應(yīng)env文件如下圖：

改進后具體的流程圖如下：

以上主要對配置文件進行env化，減少配置替換復(fù)雜度，將配置存在于Marathon發(fā)布腳本中。

更新后產(chǎn)生的marathon applist：

單個應(yīng)用容器配置：

采用env化有助于配置文件的統(tǒng)一維護和管理，新版Marathon很好的支持了應(yīng)用的更新和回滾，除去了容器啟動對靜態(tài)配置文件的依賴，使應(yīng)用容器更新發(fā)布、回滾更加方便。從界面上可以看到所有容器配置信息，使排錯管理也變得方便。

線下數(shù)人云企業(yè)版組件采用和線上相同的鏡像和env變量，通過API獲取對應(yīng)版本的envfile和Docker鏡像，之后將所有配置文件抽離到一個配置文件中，實施的同事只需修改這張配置文件，從而省去修改其他配置文件的步驟，使得實施過程更加簡單。

以上就是數(shù)人云組件配置管理碰到的問題，以及env化解決方式，歡迎大家提出寶貴意見。

Q：請問MySQL數(shù)據(jù)庫怎么隨Docker遷移？備份和恢復(fù)有什么好的建議嗎？

A：MySQL現(xiàn)在是固定主機主從同步，沒有對MySQL做遷移，我們的數(shù)據(jù)現(xiàn)在備份是定時全備份，正在嘗試使用MariaDB集群Galera Cluster ，但還沒有上生產(chǎn)，當(dāng)然有共享存儲的話就最好不過啦。

Q：請問配置文件的話生產(chǎn)環(huán)境和開發(fā)環(huán)境怎么區(qū)分？

A：生產(chǎn)環(huán)境和測試環(huán)境都是隔離的，配置文件配置不同的參數(shù)即可。

Q：請問對類似Java應(yīng)用jdbc、spring.xml等配置文件如何管理？

A：XML配置通過sed替換傳入的環(huán)境變量。

Q：生產(chǎn)上配置項變更怎么操作？

A：生產(chǎn)配置的值需要修改時 ，在configcenter頁面中修改，再觸發(fā)Jenkins更新配置文件的job， 生產(chǎn)新的配置文件 ，再調(diào)用marathon API 更新task進行更新。

Q：業(yè)務(wù)的配置是和環(huán)境配置放在一起的么？

A：是的，都是通過envfile進行統(tǒng)一的。

Q：請問你們對環(huán)境變量是采用什么樣的管理方法？有相應(yīng)的命名規(guī)范嗎？環(huán)境變量多了，會出現(xiàn)管理方面的問題吧。

A：環(huán)境變量鍵值由開發(fā)維護，運維需要提前了解新增環(huán)境變量，目前在配置中心里維護，容器環(huán)境變量變量命名規(guī)范很重要，我們目前采用服務(wù)名＋需連接的組件名＋屬性 進行命名的，且環(huán)境變量全部大寫。