在Docker實(shí)踐過程中ede，這些場(chǎng)景下需要用到容器應(yīng)用配置文件管理：

　　1.多環(huán)境之間交付應(yīng)用配置參數(shù)不同時(shí);

　　2.想增加應(yīng)用參數(shù)時(shí)；

　　3.修改應(yīng)用配置參數(shù)時(shí)不重新構(gòu)建鏡像時(shí)；

　　4.容器部署后想修好應(yīng)用配置信息時(shí)；

　　5.容器數(shù)目多修改配置文件即可一鍵下發(fā)；

　　6.應(yīng)用遷移至容器中成本低；

　　7.更加自動(dòng)化

　　等等。

　　社區(qū)最近組織活動(dòng)“實(shí)踐Docker過程中應(yīng)用配置文件管理技術(shù)討論”，由社區(qū)專家張春源整理活動(dòng)中分享的知識(shí)點(diǎn)，供大家ede了解參考。

　　張春源，擅長(zhǎng)利用Docker構(gòu)建整個(gè)DevOps自動(dòng)化平臺(tái)，專研Dockerfile及docker周邊技術(shù)，對(duì)CoreOS有深入研究。是國(guó)內(nèi)最早期的Docker實(shí)踐者，就職于希云cSpher。

　　以下內(nèi)容分享者：張春源、wanggeng、zhubingbing、bryan_sd、nexpose 等

　　一、Docker應(yīng)用配置文件的作用都有哪些？

　　觀點(diǎn)一：

　　我先來理一下問題的思路：

　　1.docker應(yīng)用應(yīng)該是指的在容器中運(yùn)行的服務(wù)（tomcat）；

　　2.應(yīng)用配置文件那就是指的在容器中運(yùn)行服務(wù)的配置文件(tomcat的配置文件)；

　　問題理清楚后，那在用docker過程中管理應(yīng)用配置文件的價(jià)值就比較大；

　　我列舉幾個(gè)：

　　1.容器鏡像是只讀的，構(gòu)建完成之后如果發(fā)現(xiàn)配置文件的中想增加環(huán)境變量此時(shí)如果沒有配置文件管理的功能就需要重新構(gòu)建build鏡像；有個(gè)配置文件以后，直接在配置文件中增加就行。

　　2.基于鏡像部署容器后，后續(xù)運(yùn)維過程中會(huì)對(duì)應(yīng)用配置的參數(shù)做一些修整，那直接可以修改配置文件的內(nèi)容即可；有的配置文件修改后是要重新啟動(dòng)服務(wù)的，但至少不需要再重新構(gòu)建打包鏡像了；有些配置文件修改后是不用重啟服務(wù)的修改后應(yīng)用即可很方便。

　　3.如果一個(gè)對(duì)Docker容器不懂或者是重心關(guān)注在應(yīng)用層的人來說，我覺得有配置文件的話使用容器就更容易一些。此時(shí)我們就可以把鏡像看成是一個(gè)程序包，基于容器的模式進(jìn)行封裝后，剩下的工作就是修改應(yīng)用的配置文件，調(diào)整容器配額，日志文件、數(shù)據(jù)文件存儲(chǔ)路徑等事宜。能將重心從系統(tǒng)底層上升到應(yīng)用層。

　　4.實(shí)踐發(fā)現(xiàn)在應(yīng)用遷移過程中調(diào)試成本會(huì)降低。

　　5.線上運(yùn)維運(yùn)營(yíng)方便。

　　觀點(diǎn)二：

　　觀點(diǎn)一回答的很好，Docker應(yīng)用配置文件的作用就是給docker的服務(wù)提供配置，我就在他的基礎(chǔ)之上，說說我的看法：

　　應(yīng)用配置文件應(yīng)該需要做到以下幾點(diǎn)：

　　1.docker應(yīng)用配置文件能夠保持能夠支持針對(duì)不同環(huán)境作出更改。

　　2.配置文件支持在線更改，重啟就生效。

　　二、基于鏡像部署容器后，應(yīng)用配置文件如何做變更？

　　觀點(diǎn)一：

　　容器部署后配置文件變更是一個(gè)強(qiáng)需求；

　　簡(jiǎn)單說一下我的分析：

　　1.使用docker自身帶的環(huán)境變量方式

　　docker自身帶的環(huán)境變量的方式如已部署完成后，再修改基本上就是重新創(chuàng)建容器了。我個(gè)人覺得比較生硬，對(duì)應(yīng)用層不夠友好。

　　2.程序自動(dòng)去獲取

　　這種模式有點(diǎn)類似springcloud微服務(wù)的實(shí)踐方式，配置文件都存放到config server中，程序配置文件有更新后config server會(huì)將更新后的配置文件下發(fā)到容器中。如果沒有config server實(shí)現(xiàn)起來比較困難一些。

　　3.容器管理平臺(tái)自動(dòng)下發(fā)

　　容器管理平臺(tái)自動(dòng)下發(fā)這種模式我覺得會(huì)比較通用，目前我接觸的企業(yè)客戶中，客戶有很多業(yè)務(wù)系統(tǒng)不是基于微服務(wù)架構(gòu)開發(fā)的但也想用容器來部署和管理。做個(gè)廣告希云cSphere平臺(tái)的配置文件管理我覺得做的挺不錯(cuò)的，哪位同事的公司有需求可以多溝通。

　　觀點(diǎn)二：

　　兩種實(shí)現(xiàn)方式

　　1. 對(duì)于需要變更的參數(shù)在啟動(dòng)容器時(shí)通過-e傳入，相當(dāng)于export 定義變量，然后在容器中讀取這個(gè)變量；

　　2. 專門制作一個(gè)config server,Spring Cloud Config可以滿足你的需求

　　觀點(diǎn)三：

　　上面的各位解答的已經(jīng)很全面了，我說一下我們的特殊做法，因?yàn)槲覀兊膱?chǎng)景比較特殊，要?jiǎng)討B(tài)修改系統(tǒng)，web，中間件，消息服務(wù)等多種情況，我們采用了在build的鏡像的時(shí)候在里面注入了agent通過它來修改容器中的各種配置文件和啟動(dòng)停止各種服務(wù)。

　　三、應(yīng)用配置文件和docker環(huán)境變量的區(qū)別是什么？

　　觀點(diǎn)一：

　　1.docker環(huán)境變量是在制作鏡像的時(shí)候就需要提前想好，有哪些參數(shù)是部署容器的時(shí)候會(huì)經(jīng)常更改，然后把這些參數(shù)抽出來做成容器的環(huán)境變量，然后在部署的容器的時(shí)候填入不同的參數(shù)即可。

　?。ㄈ绻罄m(xù)發(fā)現(xiàn)有一些參數(shù)不同場(chǎng)景下部署的時(shí)候也會(huì)修改，那就需要再重新制作鏡像了。）

　　2.應(yīng)用配置文件可以有多種管理方法，上述的管理方式不太靈活。靈活的管理方式是將配置文件和鏡像剝離開，這樣就不會(huì)被鏡像給綁定了。

　　觀點(diǎn)二：

　　應(yīng)用配置文件如果配好后寫到鏡像，那么以后啟動(dòng)的每個(gè)實(shí)例都會(huì)有相同值，但是如果使用環(huán)境變量，則啟動(dòng)容器時(shí)直接通過-e輸入，就無需在改變應(yīng)用參數(shù)配置時(shí)重新制作鏡像。

　　四、如何修改運(yùn)行中容器的配置？

　　我開啟一個(gè)docker容器：

　　容器中配置項(xiàng)目IP是：10.241.93.21?，F(xiàn)在由于網(wǎng)絡(luò)環(huán)境的問題，ip地址變化了。需要將容易的IP換成10.241.61.20。

　　ps：要求不刪除現(xiàn)有的容器，下次重啟后ip地址還是10.241.61.20。怎么配置？求方法？

　　觀點(diǎn)一：

　　你的使用方式錯(cuò)了。容器不應(yīng)該是長(zhǎng)久性的東西，要保持容器的可拋棄性，有問題就應(yīng)該rm掉，數(shù)據(jù)保存在容器外，然后直接run新的容器。參數(shù)修改是那個(gè)時(shí)候進(jìn)行的。

　　另外，你應(yīng)該使用DNS，如果是內(nèi)部的機(jī)器，則使用內(nèi)部DNS也可以，而不應(yīng)該寫死IP。

　　這兩個(gè)做法都有問題。至于說修改容器內(nèi)的配置，這是不推薦的做法，容器不是虛擬機(jī)，不應(yīng)該修改其內(nèi)的配置。

　　觀點(diǎn)二：

　　docker就是一個(gè)容器引擎，類似kvm是虛擬機(jī)引擎。docker官方最厲害的地方是提出了鏡像打包的概念，但想把容器用好還有很多問題要求解決，容器網(wǎng)絡(luò)就是其中的一塊。

　　一個(gè)企業(yè)想把容器用起來或者說是能基于容器來支持業(yè)務(wù)系統(tǒng)網(wǎng)絡(luò)方面一般都要達(dá)到幾個(gè)要求：

　　1.容器網(wǎng)絡(luò)性能（我接觸過的公司對(duì)網(wǎng)絡(luò)要求都比較嚴(yán)格的）

　　2.容器固定ip地址（這個(gè)已經(jīng)有很多種實(shí)現(xiàn)方式了）

　　3.容器跨主機(jī)之間通信（有很多中網(wǎng)絡(luò)模式）

　　4.不同容器之間通信，這個(gè)場(chǎng)景中使用容器和vm是不一樣的地方。容器對(duì)底層資源環(huán)境是解耦的，所以不要把容器的ip給固定死，不同環(huán)境的網(wǎng)絡(luò)也不同，所以應(yīng)用層要通過dns來解決。

　　五、修改無法啟動(dòng)的容器中的內(nèi)容（如配置文件信息），應(yīng)該如何處理？

　　方案一：創(chuàng)建新鏡像

　　把這個(gè)問題容器用docker commit提交到一個(gè)新的鏡像，然后用docker run -it 基于新鏡像運(yùn)行一個(gè)新的容器進(jìn)去改變（修復(fù)）配置文件。

　　再通過新的容器再提交一個(gè)新的鏡像，然后在基于新的鏡像重新啟動(dòng)容器（同最初的容器）。

　　這個(gè)方法是可行的，但問題是步驟多，而且提交了新的鏡像，對(duì)于后續(xù)維護(hù)增加了復(fù)雜性。

　　方案二：

　　直接修改容器的文件

　　所有的容器數(shù)據(jù)都存在/var/lib/docker/aufs/diff/路徑下。比如：

　　root@ubuntu:~# ls /var/lib/docker/aufs/diff/ -l

　　total 176

　　drwxr-xr-x 2 root root 4096 Mar 6 05:13 040bf8e0842564e26e62f3e3a30785bd9651c82c52ed99115cd5360ce979e680

　　drwxr-xr-x 6 root root 4096 Mar 6 05:13 04f7e78a2c8ac9664503f4ea5a1d94bf27b94620987f241cfb9fd6631f761113

　　drwxr-xr-x 2 root root 4096 Mar 11 01:07 0c666375883f81ba0fc3962368766e93710f59c072a4b80cdf5640323018ccdb

　　drwxr-xr-x 4 root root 4096 Mar 11 07:53 0d7fc1722e459b242140ec45faec754d4967d72ea2ddf321f8606c837f8e8d4f

　　drwxr-xr-x 6 root root 4096 Mar 11 07:53 0d7fc1722e459b242140ec45faec754d4967d72ea2ddf321f8606c837f8e8d4f-init

　　drwxr-xr-x 3 root root 4096 Mar 6 05:13 0dc5e226a795507723362cc16046cf16650f8f70dc7bb721b799a5f2a40512ce

　　drwxr-xr-x 2 root root 4096 Mar 6 05:13 0fd3b6e125673affc1f348cdb0c071782bde7d7ab4748bea3e30bc2d1d7ea7ab

　　......................

　　一個(gè)容器的數(shù)據(jù)對(duì)應(yīng)這其中的一個(gè)或多個(gè)目錄 。其中目錄名的前幾位就是容器的ID，通過這知道容器和目錄的對(duì)應(yīng)關(guān)系。

　　注意這個(gè)目錄需要用root用戶執(zhí)行。

　　具體的操作步驟如下：

　　1、設(shè)置當(dāng)前目錄 cd /var/lib/docker/aufs/diff

　　2、查找要修改的配置文件所在容器中的位置

　　find ./ -name 'nginx.conf'

　　假設(shè)我們要修改的是 nginx.conf文件，可能的結(jié)果如：

　　./eb531927ba243b59f0db78848809423f7debe148a9ef972088ea41be73c2aa81/etc/nginx/nginx.conf

　　./4975acfb30f3f729ac08a9c1bd642f735298a47057fc7c414c7479696b80f36a/etc/nginx/nginx.conf

　　./6fce3cb01e3c9b8cc4e1fc270c012b1d0b666fe49ad8b6bededb99e295c5da4c/etc/nginx/nginx.conf

　　這時(shí)我們通過比較要修改容器的ID 與上面幾個(gè)目錄的前綴，就知道是要修改哪個(gè)配置文件了。

　　如果我們進(jìn)入類似4975acfb30f3f729ac08a9c1bd642f735298a47057fc7c414c7479696b80f36a 目錄，會(huì)發(fā)現(xiàn)這個(gè)目錄下的內(nèi)容和linux跟目錄下的目錄結(jié)構(gòu)非常類似。我們可以找到相關(guān)的配置文件直接修改。

　　說明：因?yàn)橐粋€(gè)容器的文件系統(tǒng)包括不可修改的鏡像層和可修改的讀寫層，這個(gè)目錄下其實(shí)就是讀寫層的內(nèi)容。

　　3、修改完畢后用 docker start 容器名/ID 即可重新啟動(dòng)容器。

　　六、基礎(chǔ)鏡像的繼承管理和如何處理多個(gè)技術(shù)棧的應(yīng)用版本？

　　有兩個(gè)問題，基礎(chǔ)鏡像的繼承管理和如何處理多個(gè)技術(shù)棧的應(yīng)用版本。舉個(gè)例子，我們對(duì)于CentOS 7，做了公司級(jí)別的基礎(chǔ)OS鏡像A，基于這個(gè)鏡像加入了JDK成為鏡像B，基于B加入了JBOSS成為C，在C的基礎(chǔ)上再構(gòu)建項(xiàng)目的APP鏡像D。

　　問題來了：1，有沒有辦法針對(duì)A鏡像修改了，B，C和D去級(jí)連更新。2，由于是繼承關(guān)系，各層軟件的版本不同，導(dǎo)致鏡像種類就特別多，例如JDK有3種，jboss有三種，那么鏡像C就有九種，技術(shù)棧深了，命名又成為了問題。

　　求指導(dǎo)解決思路？

　　觀點(diǎn)一：

　　由于鏡像是分層管理，層級(jí)越深，IO性能會(huì)降低，因此最好的辦法就是各種環(huán)境分別制作不同image，如果有一些類似需求的，比如所有環(huán)境都使用java7，那么在base先構(gòu)建java7，再在此基礎(chǔ)上建構(gòu)更上層的技術(shù)，一個(gè)原則：越通用的東西越先構(gòu)建

　　1.盡量將Dockerfile放在空目錄中，如果目錄中必須有其他文件，則使用.dockerignore文件。

　　2.避免安裝不必須的包

　　3.每個(gè)容器盡量只關(guān)注一個(gè)功能點(diǎn)。

　　4.盡量減少最小化鏡像層數(shù)

　　觀點(diǎn)二：

　　你的提的這個(gè)問題非常好，這個(gè)問題是每個(gè)企業(yè)中大量使用容器的時(shí)候都會(huì)遇到的。

　　第一個(gè)問題：針對(duì)A鏡像修改了，B，C和D去級(jí)連更新。

　　提到容器大家都在提持續(xù)集成持續(xù)部署CI/CD,每個(gè)鏡像都是由Dockerfile來定義，最終執(zhí)行docker build命令來鏡像構(gòu)建。推薦選擇1-2臺(tái)服務(wù)器專門用來做應(yīng)用鏡像的構(gòu)建，避免在運(yùn)行業(yè)務(wù)容器的服務(wù)器上構(gòu)建鏡像影響業(yè)務(wù)。

　　系統(tǒng)架構(gòu)：gitlab存放dockerfile--jenkins job1（A鏡像）---jenkins job2（等A構(gòu)建完成后構(gòu)建B）--- jenkins job3（等B構(gòu)建完成后構(gòu)建C）依次類推......

　　第二個(gè)問題：由于是繼承關(guān)系，各層軟件的版本不同，導(dǎo)致鏡像種類就特別多，例如JDK有3種，jboss有三種，那么鏡像C就有九種，技術(shù)棧深了，命名又成為了問題。

　　鏡像樹是這樣：baseos--jdk--jbosstomcatweblogic---applications，因?yàn)閐ockerfile在gitlab中進(jìn)行管理，所以不妨你在增加一個(gè)文件IMAGE_VERSION=xx，docker build時(shí)可以取這個(gè)文件中的值，版本號(hào)你可以取jboss的版本號(hào)（在dockerfile中增加一個(gè)EVN jboss-version=xxx就行）。這樣即使后面有再多的鏡像命名都很好管理了，提前規(guī)劃好是非常有必要的。