容器的普及，帶來了微服務(wù)架構(gòu)和DevOps的高速發(fā)展。
1 微服務(wù)的弊端
1.1 測試、發(fā)布工作量劇增
單體應(yīng)用拆分成多個微服務(wù)后，雖能實現(xiàn)快速開發(fā)迭代，但帶來更大測試和運維部署的成本。
- 很多業(yè)務(wù)早期就是一個大的單體Web應(yīng)用，測試和運維時，只需把Web應(yīng)用打WAR包，部署到Tomcat完事
- 拆成微服務(wù)后，很多業(yè)務(wù)需求就需同時修改多個服務(wù)的代碼，那么這些服務(wù)都要打包、測試和發(fā)布上線，還要測試這些服務(wù)接口的功能，最后發(fā)布上線多個系統(tǒng)，測試和運維工作量增都劇增。這個時候就需要有辦法能夠減輕測試和運維的負(fù)擔(dān)，我在上一講給出的解決方案是DevOps。
DevOps可理解為開發(fā)和運維的結(jié)合，服務(wù)的開發(fā)者不再只負(fù)責(zé)服務(wù)的代碼開發(fā)，還要負(fù)責(zé)服務(wù)的測試、上線發(fā)布甚至故障處理等全生命周期過程，就能把測試和運維從微服務(wù)拆分后所帶來的復(fù)雜工作中解放。
DevOps要求開發(fā)、測試和發(fā)布流程自動化，這就需保證開發(fā)人員將自己本地部署測試通過的代碼和運行環(huán)境，能夠復(fù)制到測試環(huán)境，測試通過后再復(fù)制到線上環(huán)境發(fā)布。雖然看上去就是復(fù)制代碼，但實際上本地環(huán)境、測試環(huán)境及線上環(huán)境往往是隔離，軟件配置環(huán)境差異很大，導(dǎo)致開發(fā)、測試和發(fā)布流程割裂。
1.2 機器初始化復(fù)雜度劇增
彈性擴(kuò)縮容時不同微服務(wù)所要求軟件運行環(huán)境差異帶來的機器初始化復(fù)雜度的提升。拆分后的微服務(wù)相比原來大單體應(yīng)用更靈活，經(jīng)常要根據(jù)實際訪問量做在線擴(kuò)縮容，而且通常會采用在公有云上創(chuàng)建的ECS擴(kuò)縮容。
這又給運維帶來挑戰(zhàn)，因為公有云上創(chuàng)建的ECS通常只包含基本os環(huán)境，微服務(wù)運行依賴的軟件配置等需運維單獨初始化，因不同微服務(wù)的軟件配置依賴不同，比如Java服務(wù)依賴JDK，就需在ECS安裝JDK，而且可能不同微服務(wù)JDK版本也不同，服務(wù)部署的初始化工作十分繁瑣。
2 還好有你:容器
容器技術(shù)解決了本地、測試、線上環(huán)境的隔離，解決部署服務(wù)初始化繁瑣的問題。
容器，即Container可翻譯成集裝箱，在港口把貨物用集裝箱封裝起來，然后經(jīng)過貨輪從海上運輸?shù)搅硪粋€港口，再在港口卸載后通過大貨車運送到目的地。如此貨物便可在任何地方流轉(zhuǎn)時，都封裝在集裝箱，無需根據(jù)是在貨輪還是大貨車而對貨物重新裝配。
軟件的容器也就這么個作用，它封裝的是軟件的運行環(huán)境。容器本質(zhì)是Linux里的進(jìn)程，但容器通過Namespace和Cgroups，可有自己的root文件系統(tǒng)、網(wǎng)絡(luò)配置、進(jìn)程空間，甚至自己的用戶ID空間，如此容器里的進(jìn)程就像運行在宿主機上的另外一個單獨的os內(nèi)，從而實現(xiàn)與宿主機os里運行的其他進(jìn)程隔離。
Docker即是基于Linux內(nèi)核的Cgroups、Namespace實現(xiàn)進(jìn)程的封裝和隔離。
雖然容器解決了應(yīng)用程序運行時隔離問題，但要想實現(xiàn)應(yīng)用能從一臺機器遷移到另外一臺機器上還能正常運行，就必須保證另外一臺機器上的os一致，而且應(yīng)用程序依賴的各種環(huán)境也必須一致。Docker鏡像就解決了這個痛點。
即Docker鏡像不僅可打包應(yīng)用程序本身，而且還可打包應(yīng)用程序的所有依賴，甚至包含整個os。這樣在本機上運行通過的應(yīng)用程序，就可使用Docker鏡像把應(yīng)用程序文件、所有依賴的軟件以及os都打包成一個鏡像，可在任何一個安裝了Docker的地方運行。
Docker鏡像解決了DevOps中微服務(wù)運行的環(huán)境難以在本地環(huán)境、測試環(huán)境以及線上環(huán)境保持一致的難題。如此一來，開發(fā)就可以把在本地環(huán)境中運行測試通過的代碼，以及依賴的軟件和操作系統(tǒng)本身打包成一個鏡像，然后自動部署在測試環(huán)境中進(jìn)行測試，測試通過后再自動發(fā)布到線上環(huán)境上去，整個開發(fā)、測試和發(fā)布的流程就打通了。
無論使用內(nèi)部物理機還是公有云的機器部署服務(wù)，都可利用Docker鏡像封裝微服務(wù)運行環(huán)境，從而屏蔽機器內(nèi)部物理機和公有云機器運行環(huán)境的差異，實現(xiàn)同等對待，降低運維復(fù)雜度。
3 微服務(wù)容器化實踐
Docker解決了服務(wù)運行環(huán)境遷移問題，因為在使用Docker鏡像時并非把業(yè)務(wù)代碼、依賴的軟件環(huán)境以及os直接打包鏡像，而是利用Docker鏡像的分層機制，在每層編寫Dockerfile逐層打包鏡像。
因為雖然不同微服務(wù)依賴的軟件環(huán)境不同，但還是存在相同，因此打包Docker鏡像時，可以分層設(shè)計、逐層復(fù)用，減少每層鏡像文件大小。
4 業(yè)務(wù)案例
看看生產(chǎn)環(huán)境如何使用Docker鏡像。某Docker鏡像分為四層。
- 基礎(chǔ)環(huán)境層
定義操作系統(tǒng)運行的版本、時區(qū)、語言、yum源、TERM等
- 運行時環(huán)境層
定義了業(yè)務(wù)代碼的運行時環(huán)境，比如Java代碼的運行時環(huán)境JDK的版本。
- Web容器層
定義了業(yè)務(wù)代碼運行的容器的配置，比如Tomcat容器的JVM參數(shù)
- 業(yè)務(wù)代碼層
定義了實際的業(yè)務(wù)代碼的版本，比如是V4業(yè)務(wù)還是blossom業(yè)務(wù)。
如此每層鏡像都基于上層添加新內(nèi)容，比如V4業(yè)務(wù)的Dockerfile
FROM registry.intra.xxx.com/xxx_rd_content/tomcat_feed:jdk8.0.40_tomcat7.0.81_g1_dns
ADD confs /data1/confs/
ADD node_pool /data1/node_pool/
ADD authconfs /data1/authconfs/
ADD authkey.properties /data1/
ADD watchman.properties /data1/
ADD 200.sh /data1/xxx/bin/200.sh
ADD 503.sh /data1/xxx/bin/503.sh
ADD catalina.sh /data1/xxx/bin/catalina.sh
ADD server.xml /data1/xxx/conf/server.xml
ADD logging.properties /data1/xxx/conf/logging.properties
ADD ROOT /data1/xxx/webapps/ROOT/
RUN chmod +x /data1/xxx/bin/200.sh /data1/xxx/bin/503.sh /data1/xxx/bin/catalina.sh
WORKDIR /data1/xxx/bin
- FROM代表上層鏡像文件為tomcat_feed:jdk8.0.40_tomcat7.0.81_g1_dns”，可見該層包含了Java運行時環(huán)境JDK和Web容器Tomcat及Tomcat版本和JVM參數(shù)等
- ADD，即要在該層鏡像添加的文件，主要包含業(yè)務(wù)的代碼和配置
- RUN，該層鏡像啟動時需要執(zhí)行的命令
- WORKDIR，該層鏡像啟動后的工作目錄。如此便可通過Dockerfile基于上層鏡像完成該層鏡像制作
5 總結(jié)
正是因為Docker可做到一處通過、到處運行，對業(yè)務(wù)價值極大，解決了以前應(yīng)用程序在開發(fā)環(huán)境、測試環(huán)境及生產(chǎn)環(huán)境間移植難，提高了運維自動化水平，也為DevOps理念的流行和業(yè)務(wù)上云提供了基礎(chǔ)。
當(dāng)然Docker也會帶來新問題，如舊的針對物理機的運維模式就無法適應(yīng)了，需要一種新的針對容器的運維模式。
原文地址:https://mp.weixin.qq.com/s/o4DG5WcYUlhzN70Kn94zXA
