Docker解決的問題：
由于不同的機器有不同的操作系統(tǒng)，以及不同的庫和組件牍蜂，在將一個應用部署到多臺機器上需要進行大量的環(huán)境配置操作九昧。
Docker 主要解決環(huán)境配置問題花履，它是一種虛擬化技術，對進程進行隔離，被隔離的進程獨立于宿主操作系統(tǒng)和其它隔離的進程。使用 Docker 可以不修改應用程序代碼，不需要開發(fā)人員學習特定環(huán)境下的技術反粥，就能夠?qū)F(xiàn)有的應用程序部署在其它機器上。
與虛擬機的比較:
虛擬機也是一種虛擬化技術疲迂，它與 Docker 最大的區(qū)別在于它是通過模擬硬件才顿，并在硬件上安裝操作系統(tǒng)來實現(xiàn)。
啟動速度
啟動虛擬機需要先啟動虛擬機的操作系統(tǒng)尤蒿，再啟動應用娜膘，這個過程非常慢；
而啟動 Docker 相當于啟動宿主操作系統(tǒng)上的一個進程优质。
占用資源
虛擬機是一個完整的操作系統(tǒng)竣贪，需要占用大量的磁盤、內(nèi)存和 CPU 資源巩螃，一臺機器只能開啟幾十個的虛擬機演怎。
而 Docker 只是一個進程，只需要將應用以及相關的組件打包避乏，在運行時占用很少的資源爷耀，一臺機器可以開啟成千上萬個 Docker。
鏡像與容器:
鏡像是一種靜態(tài)的結構拍皮，可以看成面向?qū)ο罄锩娴念惔醵＃萜魇晴R像的一個實例。
鏡像包含著容器運行時所需要的代碼以及其它組件铆帽，它是一種分層結構咆耿，每一層都是只讀的（read-only layers）。構建鏡像時爹橱，會一層一層構建萨螺，前一層是后一層的基礎。鏡像的這種分層存儲結構很適合鏡像的復用以及定制。
構建容器時慰技，通過在鏡像的基礎上添加一個可寫層（writable layer）椭盏，用來保存著容器運行過程中的修改。
優(yōu)缺點:
1. 部署方便
你一定還有印象吻商，在我們最開始學習編程的時候掏颊，搭建環(huán)境這一步往往會耗費我們好幾個小時的時間，而且其中一個小問題可能需要找很久才能夠解決艾帐。你還會得到關于環(huán)境搭建方面的團隊其他成員的求助蚯舱。而有了容器之后，這些都變得非常容易掩蛤，你的開發(fā)環(huán)境就只是一個或者幾個容器鏡像的地址，最多再需要一個控制部署流程的執(zhí)行腳本陈肛∽崮瘢或者進一步將你的環(huán)境鏡像以及鏡像腳本放入一個git項目，發(fā)布到云端句旱，需要的時候?qū)⑺奖镜鼐涂梢粤恕?/p>
# git clone https://github.com/my-project# sh ./my-build-boot.sh
目前我們團隊目前基本都是用這種方案搭建本地開發(fā)環(huán)境阳藻，而且整理成內(nèi)部技術文檔，慢慢沉淀成團隊的財富了谈撒。
2. 部署安全
當我們收到一個bug反饋的時候腥泥，很多時候心里面的第一反應一定是“我本地是好的啊”！這種情況的發(fā)生就在于環(huán)境的不一致啃匿，我們在開發(fā)過程中的調(diào)試往往不能保證其他環(huán)境的問題蛔外，但是我們卻要為此買單，這真是一件令人苦惱的事情溯乒。有了容器之后夹厌，這將很少發(fā)生。我們可以通過容器技術將開發(fā)環(huán)境和測試環(huán)境以及生產(chǎn)環(huán)境保持版本和依賴上的統(tǒng)一裆悄，保證代碼在一個高度統(tǒng)一的環(huán)境上執(zhí)行矛纹。而測試環(huán)境的統(tǒng)一，也同樣能解決CI流程對環(huán)境的要求光稼。
分布式技術和擴容需求日益增長的今天或南，如果運維能夠使用容器技術來進行環(huán)境的部署，不僅僅在部署時間上節(jié)省不少艾君，也能把很多因為人工配置環(huán)境產(chǎn)生的失誤降到最低采够。
3. 隔離性好
不管是開發(fā)還是生產(chǎn)，往往我們一臺機器上可能需要跑多個服務冰垄，而服務各自需要的依賴配置不盡相同吁恍，假如說兩個應用需要使用同一個依賴，或者兩個應用需要的依賴之間會有一些沖突，這個時候就很容易出現(xiàn)問題了冀瓦。所以同一臺服務器上不同應用提供的不同服務伴奥，最好還是將其隔離起來。而容器在這方面有天生的優(yōu)勢翼闽，每一個容器就是一個隔離的環(huán)境拾徙，你對容器內(nèi)部提供服務的要求，容器可以自依賴的全部提供感局。這種高內(nèi)聚的表現(xiàn)可以實現(xiàn)快速的分離有問題的服務尼啡，在一些復雜系統(tǒng)中能實現(xiàn)快速排錯和及時處理。(當然需要說明的是询微，這個隔離性只是相對于服務器比較的崖瞭，虛機技術要擁有更好的隔離性)
4. 快速回滾
容器之前的回滾機制，一般需要基于上個版本的應用重新部署撑毛，且替換掉目前的問題版本书聚。在最初的時代，可能是一套完整的開發(fā)到部署的流程藻雌，而執(zhí)行這一套流程往往需要很長的時間雌续。在基于git的環(huán)境中，可能是回退某個歷史提交胯杭，然后重新部署驯杜。這些跟容器技術相比都不夠快，而且可能會引起新的問題（因為是基于新版本的修改）做个。而容器技術天生帶有回滾屬性鸽心，因為每個歷史容器或者鏡像都會有保存，而替換一個容器或者某個歷史鏡像是非尘优快速和簡單的再悼。
5. 成本低
這可能是一個最明顯和有用的優(yōu)點了，在容器出現(xiàn)之前膝但，我們往往構筑一個應用就需要一臺新的服務器或者一臺虛機冲九。服務器的購置成本和運維成本都很高，而虛機需要占用很多不必要的資源跟束。相比之下莺奸，容器技術就小巧輕便的多，只需要給一個容器內(nèi)部構建應用需要的依賴就可以了冀宴，這也是容器技術發(fā)展迅速的最主要原因灭贷。
6. 管理成本更低
隨著容器技術的不斷普及和發(fā)展，隨之而來的容器管理和編排技術也同樣得到發(fā)展略贮。諸如Docker Swarm甚疟，Kubernetes, Mesos等編排工具也在不斷的迭代更新仗岖，這讓容器技術在生產(chǎn)環(huán)境中擁有了更多的可能性和更大的發(fā)揮空間。而隨著大環(huán)境的發(fā)展览妖，docker等容器的使用和學習的成本也是愈發(fā)降低轧拄，成為更多開發(fā)者和企業(yè)的選擇。
說了這么多的優(yōu)點讽膏，容器也有一些問題是沒有解決的檩电。上一代方案基本就是基于虛機技術的云方案，能有效增加服務器的使用效率府树，達到節(jié)省成本的目的俐末，而容器技術在此基礎上更進一步地優(yōu)化了資源的使用率。但是仍然有一些問題奄侠，是我們在選擇服務資源架構場景中需要考慮的：
1.隔離性
基于hypervisor的虛機技術卓箫，在隔離性上比容器技術要更好，它們的系統(tǒng)硬件資源完全是虛擬化的垄潮，當一臺虛機出現(xiàn)系統(tǒng)級別的問題烹卒，往往不會蔓延到同一宿主機上的其他虛機。但是容器就不一樣了魂挂，容器之間共享同一個操作系統(tǒng)內(nèi)核以及其他組件，所以在收到攻擊之類的情況發(fā)生時馁筐，更容易通過底層操作系統(tǒng)影響到其他容器涂召。當然，這個問題可以通過在虛機中部署容器來解決敏沉，可是這樣又會引出新的問題果正，比如成本的增加以及下面要提到的問題：性能。
2. 性能
不管是虛機還是容器盟迟，都是運用不同的技術秋泳，對應用本身進行了一定程度的封裝和隔離，在降低應用和應用之間以及應用和環(huán)境之間的耦合性上做了很多努力攒菠，但是隨機而來的迫皱，就會產(chǎn)生更多的網(wǎng)絡連接轉(zhuǎn)發(fā)以及數(shù)據(jù)交互，這在低并發(fā)系統(tǒng)上表現(xiàn)不會太明顯辖众，而且往往不會成為一個應用的瓶頸（可能會分散于不同的虛機或者服務器上）卓起，但是當同一虛機或者服務器下面的容器需要更高并發(fā)量支撐的時候，也就是并發(fā)問題成為應用瓶頸的時候凹炸，容器會將這個問題放大戏阅，所以，并不是所有的應用場景都是適用于容器技術的啤它。
3. 存儲方案
容器的誕生并不是為OS抽象服務的奕筐，這是它和虛機最大的區(qū)別舱痘，這樣的基因意味著容器天生是為應用環(huán)境做更多的努力，容器的伸縮也是基于容器的這一disposable特性离赫，而與之相對的芭逝，需要持久化存儲方案恰恰相反。這一點docker容器提供的解決方案是利用volume接口形成數(shù)據(jù)的映射和轉(zhuǎn)移笆怠，以實現(xiàn)數(shù)據(jù)持久化的目的铝耻。但是這樣同樣也會造成一部分資源的浪費和更多交互的發(fā)生，不管是映射到宿主機上還是到網(wǎng)絡磁盤蹬刷，都是退而求其次的解決方案瓢捉。
隨著硬件技術和網(wǎng)絡技術的迭代發(fā)展，容器技術的缺點會變得越來越不那么明顯办成，而且隨著容器技術的發(fā)展和普及泡态，對應的解決方案也會越來越多。所以總體來看迂卢，docker等容器技術會朝著更加普及的趨勢走近我們技術領域某弦。也希望每一位熱愛技術的小伙伴們能更加了解這些新技術，讓它們能夠更好的為我們服務而克。
