技術選型之Docker容器引擎

最近對Docker和Kubernetes進行了一番學習，前兩天做了一次技術分享，回去聽了一遍自己演講的錄音，發(fā)現(xiàn)單單PPT做好還是遠遠不夠的，沒有提前準備好邏輯嚴謹的講稿，在講的時候出現(xiàn)了卡殼、漏掉技術點、邏輯矛盾的問題。

為了解決這個問題，我打算以后在做技術分享前，都按著PPT的內容先寫成博客，理順表達邏輯。另外，我覺得每次技術分享使用的PPT都應該盡可能的做好，因為你不知道未來會不會還要拿來再講幾遍。本文以PPT+講稿的方式編寫，權當對自己這次技術分享做個記錄，歡迎大家拍磚。

1. Docker出現(xiàn)的背景

在平常的研發(fā)和項目場景中，以下情況普遍存在：

個人開發(fā)環(huán)境

為了做大數據相關項目，需要安裝一套CDH集群，常見的做法是在自己電腦里搭建3臺與CDH版本對應的虛擬機，把CDH集群裝起來后，考慮到以后很有可能還要使用一個干凈的CDH集群，為了避免以后重復安裝環(huán)境，通常會對整套CDH集群做一個備份，這樣電腦里就有6個虛擬機鏡像了。

另外，后面在學習其他技術時，比如學習Ambari大數據集群，那么為了不破壞已有的虛擬機環(huán)境，又要重新搭建3臺虛擬機，本機磁盤很快被一大堆的虛擬機鏡像占滿。

公司內部開發(fā)環(huán)境

公司里往往會以小團隊的方式來做項目，一般由運維部門從他們管理的服務器資源中分配出虛擬機供團隊內部開發(fā)測試使用。比如做一個與機器學習相關的項目：

小明在運維部門分配的虛擬機上搭建了一套Ambari集群，拿來跑大數據相關業(yè)務

小剛用python3寫了一個機器學習算法，放到虛擬機上運行發(fā)現(xiàn)虛擬機里是python2，算法不兼容，于是把虛擬機里的python版本升級了，算法跑通了，但Ambari用到python的部分功能可能就報錯了

小李開發(fā)了應用，放到虛擬機上啟動tomcat，發(fā)現(xiàn)虛擬機里的是OpenJDK，導致tomcat起不來，于是又安裝了一個JDK，這時候可能Ambari里的Java代碼可能就報錯了

小趙想利用服務器資源做性能測試，發(fā)現(xiàn)虛擬機嚴重削減了性能，最終還是要直接找物理機來跑測試，破壞了物理機原來的環(huán)境

做完項目后，這些虛擬機上安裝的東西往往變得沒用了，下個項目組來還是得新申請?zhí)摂M機重新部署軟件

開發(fā)/測試/現(xiàn)場環(huán)境

研發(fā)人員在開發(fā)環(huán)境里寫好了代碼做好測試后，提交給測試部門，測試人員在測試環(huán)境跑起來發(fā)現(xiàn)有BUG，研發(fā)人員說在開發(fā)環(huán)境沒這個BUG，和測試人員多次扯皮解決BUG后發(fā)布版本，發(fā)到現(xiàn)場在生產環(huán)境部署后，又發(fā)現(xiàn)有BUG，這下輪到工程人員和測試人員扯皮。有時候為了兼容特殊的現(xiàn)場環(huán)境，還需要對代碼進行定制化修改，拉出分支，這樣導致了每次到現(xiàn)場升級都是一場噩夢

升級或遷移項目

在每次發(fā)版本要升級到現(xiàn)場時，如果現(xiàn)場起了多個tomcat應用，那么需要對每個tomcat都先停掉，替換war包，然后再起起來，輪流著做，不僅繁瑣而且很容易出錯，如果遇到升級后出現(xiàn)嚴重BUG，還要手工做回退。

另外，如果項目想上云，那么在云上部署后要重新進行一輪測試，如果后面考慮還云廠商，可能相同的測試還要再進行一次(比如更換了數據存儲組件)，費時費力。

總結以上列舉的所有場景，他們存在的一個共同的問題是：沒有一種既能夠屏蔽操作系統(tǒng)差異，又能夠以不降低性能的方式來運行應用的技術，來解決環(huán)境依賴的問題。Docker應運而生。

2. Docker是什么

Docker是一種應用容器引擎。

首先說一下何為容器，Linux系統(tǒng)提供了Namespace和CGroup技術實現(xiàn)環(huán)境隔離和資源控制，其中Namespace是Linux提供的一種內核級別環(huán)境隔離的方法，能使一個進程和該進程創(chuàng)建的子進程的運行空間都與Linux的超級父進程相隔離。

注意Namespace只能實現(xiàn)運行空間的隔離，物理資源還是所有進程共用的，為了實現(xiàn)資源隔離，Linux系統(tǒng)提供了CGroup技術來控制一個進程組群可使用的資源(如CPU、內存、磁盤IO等)，把這兩種技術結合起來，就能構造一個用戶空間獨立且限定了資源的對象，這樣的對象稱為容器。

Linux Container是Linux系統(tǒng)提供的容器化技術，簡稱LXC，它結合Namespace和CGroup技術為用戶提供了更易用的接口來實現(xiàn)容器化。LXC僅為一種輕量級的容器化技術，它僅能對部分資源進行限制，無法做到諸如網絡限制、磁盤空間占用限制等。dotCloud公司結合LXC和以下列出的技術實現(xiàn)了Docker容器引擎，相比于LXC，Docker具備更加全面的資源控制能力，是一種應用級別的容器引擎。

Chroot：該技術能在container里構造完整的Linux文件系統(tǒng);

Veth：該技術能夠在主機上虛擬出一張網卡與container里的eth0網卡進行橋接，實現(xiàn)容器與主機、容器之間的網絡通信;

UnionFS：聯(lián)合文件系統(tǒng)，Docker利用該技術“Copy on Write”的特點實現(xiàn)容器的快速啟動和極少的資源占用，后面會專門介紹該文件系統(tǒng);

Iptables/netfilter：通過這兩個技術實現(xiàn)控制container網絡訪問策略;

TC：該技術主要用來做流量隔離，限制帶寬;

Quota：該技術用來限制磁盤讀寫空間的大小;

Setrlimit：該技術用來限制container中打開的進程數，限制打開的文件個數等

也正是因為Docker依賴Linux內核的這些技術，至少使用3.8或更高版本的內核才能運行Docker容器，官方建議使用3.10以上的內核版本。

3. 與傳統(tǒng)虛擬化技術的區(qū)別

傳統(tǒng)的虛擬化技術在虛擬機(VM)和硬件之間加了一個軟件層Hypervisor，或者叫做虛擬機管理程序。Hypervisor的運行方式分為兩類：

直接運行在物理硬件之上。如基于內核的KVM虛擬機，這種虛擬化需要CPU支持虛擬化技術;

運行在另一個操作系統(tǒng)。如VMWare和VitrualBox等虛擬機。

因為運行在虛擬機上的操作系統(tǒng)是通過Hypervisor來最終分享硬件，所以虛擬機Guest OS發(fā)出的指令都需要被Hypervisor捕獲，然后翻譯為物理硬件或宿主機操作系統(tǒng)能夠識別的指令。

VMWare和VirtualBox等虛擬機在性能方面遠不如裸機，但基于硬件虛擬機的KVM約能發(fā)揮裸機80%的性能。這種虛擬化的優(yōu)點是不同虛擬機之間實現(xiàn)了完全隔離，安全性很高，并且能夠在一臺物理機上運行多種內核的操作系統(tǒng)(如Linux和Window)，但每個虛擬機都很笨重，占用資源多而且啟動很慢。

Docker引擎運行在操作系統(tǒng)上，是基于內核的LXC、Chroot等技術實現(xiàn)容器的環(huán)境隔離和資源控制，在容器啟動后，容器里的進程直接與內核交互，無需經過Docker引擎中轉，因此幾乎沒有性能損耗，能發(fā)揮出裸機的全部性能。

但由于Docker是基于Linux內核技術實現(xiàn)容器化的，因此使得容器內運行的應用只能運行在Linux內核的操作系統(tǒng)上。目前在Window上安裝的docker引擎其實是利用了Window自帶的Hyper-V虛擬化工具自動創(chuàng)建了一個Linux系統(tǒng)，容器內的操作實際上是間接使用這個虛擬系統(tǒng)實現(xiàn)的。

4. Docker基本概念

Docker主要有如下幾個概念：

引擎：創(chuàng)建和管理容器的工具，通過讀取鏡像來生成容器，并負責從倉庫拉取鏡像或提交鏡像到倉庫中;

鏡像：類似于虛擬機鏡像，一般由一個基本操作系統(tǒng)環(huán)境和多個應用程序打包而成，是創(chuàng)建容器的模板;

容器：可看作一個簡易版的Linxu系統(tǒng)環(huán)境(包括root用戶權限、進程空間、用戶空間和網絡空間等)以及運行在其中的應用程序打包而成的盒子;

倉庫：集中存放鏡像文件的場所，分為公共倉庫和私有倉庫，目前大的公共倉庫是官方提供的Docker Hub，此外國內的阿里云、騰訊云等也提供了公共倉庫;

宿主機：運行引擎的操作系統(tǒng)所在服務器。

5. Docker與虛擬機、Git、JVM的類比

為了讓大家對Docker有更直觀的認識，下面分別進行三組類比：

上圖中Docker的鏡像倉庫類似于傳統(tǒng)虛擬機的鏡像倉庫或存放鏡像的本地文件系統(tǒng)，Docker引擎啟動容器來運行Spark集群(容器內包含基礎的Linux操作系統(tǒng)環(huán)境)，類比于虛擬機軟件啟動多個虛擬機，在虛擬機內分別運行Spark進程，兩者區(qū)別在于Docker容器內的應用在使用物理資源時，直接與內核打交道，無需經過Docker引擎。

Docker的倉庫思想與Git是相同的。

Docker的口號是“Build，Ship，and Run Any App，Anywhere”，也就是可以基于Docker構建、裝載和運行應用程序，一次構建到處運行。Java的口號是“Write Once,Run Anywhere”，即一次編寫到處運行。

Java是基于JVM適配操作系統(tǒng)的特點來屏蔽系統(tǒng)的差異，Docker則是利用內核版本兼容性的特點來實現(xiàn)一次構建導出運行，只要Linux系統(tǒng)的內核是3.8或更高的版本，就都能把容器跑起來。

當然，正如Java中如果應用代碼使用了JDK10的新特性，基于JDK8就無法運行一樣，如果容器內的應用使用了4.18版本的內核特性，那么在CentOS7(內核版本為3.10)啟動容器時，雖然容器能夠啟動，但里面應用的功能是無法正常運行的，除非把宿主機的操作系統(tǒng)內核升級到4.18版本。

6. Docker鏡像文件系統(tǒng)

Docker鏡像采用分層存儲格式，每個鏡像可依賴其他鏡像進行構建，每一層的鏡像可被多個鏡像引用，上圖的鏡像依賴關系，K8S鏡像其實是CentOS+GCC+GO+K8S這四個軟件結合的鏡像。

這種分層結構能充分共享鏡像層，能大大減少鏡像倉庫占用的空間，而對用戶而言，他們所看到的容器，其實是Docker利用UnionFS(聯(lián)合文件系統(tǒng))把相關鏡像層的目錄“聯(lián)合”到同一個掛載點呈現(xiàn)出來的一個整體，這里需要簡單介紹一個UnionFS是什么：

UnionFS可以把多個物理位置獨立的目錄(也叫分支)內容聯(lián)合掛載到同一個目錄下，UnionFS允許控制這些目錄的讀寫權限，此外對于只讀的文件和目錄，它具有“Copy on Write(寫實復制)”的特點，即如果對一個只讀的文件進行修改，在修改前會先把文件復制一份到可寫層(可能是磁盤里的一個目錄)，所有的修改操作其實都是對這個文件副本進行修改，原來的只讀文件并不會變化。

其中一個使用UnionFS的例子是：Knoppix，一個用于Linux演示、光盤教學和商業(yè)產品演示的Linux發(fā)行版，它就是把一個CD/DVD和一個存在在可讀寫設備(例如U盤)聯(lián)合掛載，這樣在演示過程中任何對CD/DVD上文件的改動都會在被應用在U盤上，不改變原來的CD/DVD上的內容。

UnionFS有很多種，其中Docker中常用的是AUFS，這是UnionFS的升級版，除此之外還有DeviceMapper、Overlay2、ZFS和 VFS等。Docker鏡像的每一層默認存放在/var/lib/docker/aufs/diff目錄中，當用戶啟動一個容器時，Docker引擎首先在/var/lib/docker/aufs/diff中新建一個可讀寫層目錄，然后使用UnionFS把該可讀寫層目錄和指定鏡像的各層目錄聯(lián)合掛載到/var/lib/docker/aufs/mnt里的一個目錄中(其中指定鏡像的各層目錄都以只讀方式掛載)，通過LXC等技術進行環(huán)境隔離和資源控制，使容器里的應用僅依賴mnt目錄中對應的掛載目錄和文件運行起來。

利用UnionFS寫實復制的特點，在啟動一個容器時， Docker引擎實際上只是增加了一個可寫層和構造了一個Linux容器，這兩者都幾乎不消耗系統(tǒng)資源，因此Docker容器能夠做到秒級啟動，一臺服務器上能夠啟動上千個Docker容器，而傳統(tǒng)虛擬機在一臺服務器上啟動幾十個就已經非常吃力了，而且虛擬機啟動很慢，這是Docker相比于傳統(tǒng)虛擬機的兩個巨大的優(yōu)勢。

當應用只是直接調用了內核功能來運作的情況下，應用本身就能直接作為最底層的層來構建鏡像，但因為容器本身會隔絕環(huán)境，因此容器內部是無法訪問宿主機里文件的(除非指定了某些目錄或文件映射到容器內)，這種情況下應用代碼就只能使用內核的功能。

但是Linux內核僅提供了進程管理、內存管理、文件系統(tǒng)管理等一些基礎且底層的管理功能，在實際的場景中，幾乎所有軟件都是基于操作系統(tǒng)來開發(fā)的，因此往往都需要依賴操作系統(tǒng)的軟件和運行庫等，如果這些應用的下一層直接是內核，那么應用將無法運行。所以實際上應用鏡像往往底層都是基于一個操作系統(tǒng)鏡像來補足運行依賴的。

Docker中的操作系統(tǒng)鏡像，與平常安裝系統(tǒng)時用的ISO鏡像不同。ISO鏡像里包含了操作系統(tǒng)內核及該發(fā)行版系統(tǒng)包含的所有目錄和軟件，而Docker中的操作系統(tǒng)鏡像，不包含系統(tǒng)內核，僅包含系統(tǒng)必備的一些目錄(如/etc /proc等)和常用的軟件和運行庫等，可把操作系統(tǒng)鏡像看作內核之上的一個應用，一個封裝了內核功能，并為用戶編寫的應用提供運行環(huán)境的工具。

應用基于這樣的鏡像構建，就能夠利用上相應操作系統(tǒng)的各種軟件的功能和運行庫，此外，由于應用是基于操作系統(tǒng)鏡像來構建的，就算換到另外的服務器，只要操作系統(tǒng)鏡像中被應用使用到的功能能適配宿主機的內核，應用就能正常運行，這就是一次構建到處運行的原因。

下圖形象的表現(xiàn)出了鏡像和容器的關系：

上圖中Apache應用基于emacs鏡像構建，emacs基于Debian系統(tǒng)鏡像構建，在啟動為容器時，在Apache鏡像層之上構造了一個可寫層，對容器本身的修改操作都在可寫層中進行。Debian是該鏡像的基礎鏡像(Base Image)，它提供了內核Kernel的更高級的封裝。同時其他的鏡像也是基于同一個內核來構建的(以下的BusyBox是一個精簡版的操作系統(tǒng)鏡像)：

這時候就會有一個問題，應用基于操作系統(tǒng)鏡像來構建，那如果操作系統(tǒng)鏡像本身就很占空間，豈不是鏡像的分發(fā)不方便，而且鏡像倉庫占用的空間也會很大。有人已經考慮到這一點，針對不同的場景分別構造了不同的操作系統(tǒng)鏡像，下面介紹幾種最常用的系統(tǒng)鏡像。

7. Docker基礎操作系統(tǒng)

以上系統(tǒng)鏡像分別適用于不同的場景：

BusyBox：一個極簡版的Linux系統(tǒng)，集成了100多種常用Linux命令，大小不到2MB，被稱為“Linux系統(tǒng)的瑞士軍刀”，適用于簡單測試場景;

Alpine：一個面向安全的輕型Linux發(fā)行版系統(tǒng)，比BusyBox功能更完善，大小不到5MB，是官網推薦的基礎鏡像，由于其包含了足夠的基礎功能和體積較小，在生產環(huán)境中最常用;

Debian/Ubuntu：Debian系列操作系統(tǒng)，功能完善，大小約170MB，適合研發(fā)環(huán)境;

CentOS/Fedora：都是基于Redhat的Linux發(fā)行版，企業(yè)級服務器常用操作系統(tǒng)，穩(wěn)定性高，大小約200MB，適合生產環(huán)境使用。

8. Docker持久化存儲

根據前面介紹的容器UnionFS寫實復制的特點，可知在容器里增加、刪除或修改文件，其實都是對可寫層里的文件副本進行了操作。在容器關閉后，該可寫層也會被刪除，對容器的所有修改都會失效，因此需要解決容器內文件持久化的問題。Docker提供了兩種方案來實現(xiàn)：

把宿主機文件系統(tǒng)里的目錄映射到容器內的目錄，如下圖所示。如此一來，容器內在該目錄里創(chuàng)建的所有文件，都存儲到宿主機的對應目錄中，在關閉容器后，宿主機的目錄依然存在，再次啟動容器時還能讀取到之前創(chuàng)建的文件，因此實現(xiàn)了容器的文件持久化。

當然同時要明白，如果是對鏡像自帶文件進行了修改，由于鏡像是只讀的，該修改操作無法在關閉容器時保存下來，除非在修改了文件后構建一個新的鏡像。

把多臺宿主機的磁盤目錄通過網絡聯(lián)合為共享存儲，然后把共享存儲中的特定目錄映射給特定的容器，如下圖所示。這樣容器在重啟時，還是能讀取到關閉前創(chuàng)建的文件。生產環(huán)境中常用NFS作為共享存儲方案。

9. Docker鏡像制作方法

鏡像制作方法有兩種：

（1）通過正在運行的容器生成新鏡像

當一個容器在運行時，在里面所有的修改都會體現(xiàn)在容器的可寫層，Docker提供了commit命令，可以把正在運行的容器，疊加上可寫層的修改內容，生成一個新鏡像。

如上圖所示，在容器里新安裝Spark組件的，如果關閉容器，Spark組件會隨著可寫層的消失而消失，如果在關閉容器之前使用commit命令生成新鏡像，那么使用新鏡像啟動為容器時，容器里就會包含Spark組件。

這種方式比較簡單，但無法直觀的設置環(huán)境變量、監(jiān)聽端口等內容，適合在簡單使用的場景運用。

（2）通過Dockerfile文件來生成新鏡像

Dockerfile是一個定義了鏡像創(chuàng)建步驟的文件，Docker引擎通過build命令讀取Dockerfile，按定義的步驟來一步步構造鏡像。在研發(fā)和實施環(huán)境中，通過Dockerfile 創(chuàng)建容器是主流做法。

下面是一個Dockerfile的例子：

Docker引擎可以根據以上Dockerfile定義的步驟，構造出一個帶有ssh服務的Ubuntu鏡像。

10. Docker的使用場景

Docker作為一種輕量級的虛擬化方案，應用場景十分豐富，下面收集了一些常見的場景：

作為輕量級虛擬機使用

可以使用Ubuntu等系統(tǒng)鏡像創(chuàng)建容器，當作虛擬機來使用，相比于傳統(tǒng)虛擬機，啟動速度更快，資源占用更少，單機可以啟動大量的操作系統(tǒng)容器，方便進行各種測試;

作為云主機使用

結合Kubernetes這樣的容器管理系統(tǒng)，可以在大量服務器上動態(tài)分配和管理容器，在公司內部，甚至可以取代VMWare這樣的虛擬機管理平臺，使用Docker容器作為云主機使用;

應用服務打包

在Web應用服務開發(fā)場景，可以把Java運行環(huán)境、Tomcat服務器打包為一個基礎鏡像，在修改了代碼包后加入到基礎鏡像來構建一個新的鏡像，能很方便的升級服務和控制版本;

容器云平臺CaaS

Docker的出現(xiàn)，使得很多云平臺供應商開始提供容器云的服務，簡稱容器即服務CaaS，以下對比一下IaaS、PaaS和SaaS：

IaaS(基礎設施即服務)：提供虛擬機或者其他基礎資源作為服務提供給用戶。用戶可以從供應商那里獲得虛擬機或者存儲等資源來裝載相關的應用，同時這些基礎設施的繁瑣的管理工作將由IaaS供應商來處理。其主要的用戶是企業(yè)的系統(tǒng)管理員和運維人員;

PaaS(平臺即服務)：把開發(fā)平臺作為服務提供給用戶。用戶可以在一個包括SDK，文檔和測試環(huán)境等在內的開發(fā)平臺上非常方便地編寫應用，而且不論是在部署，或者在運行的時候，用戶都無需為服務器、操作系統(tǒng)、網絡和存儲等資源的管理操心，這些繁瑣的工作都由PaaS供應商負責處理。其主要的用戶是企業(yè)開發(fā)人員。

SaaS(軟件即服務)：將應用作為服務提供給客戶。用戶只要接上網絡，并通過瀏覽器，就能直接使用在云端上運行的應用，而不需要顧慮類似安裝等瑣事，并且免去初期高昂的軟硬件投入。SaaS主要面對的是普通的用戶。

CaaS(容器即服務)：完成IaaS和PaaS兩個層級的功能。相對于傳統(tǒng)的IaaS和PaaS服務，CaaS對底層的支持比PaaS更靈活，而對上層應用的操控又比IaaS更容易。同時因為Docker是比VM更細粒度的虛擬化服務，所以能夠對計算資源做到更高效的利用。CaaS可以部署在任何物理機，虛擬機或IaaS云之上。

持續(xù)集成和持續(xù)部署

互聯(lián)網行業(yè)提倡敏捷開發(fā)，持續(xù)集成部署CI/CD便是最典型的開發(fā)模式。使用Docker容器云平臺，就能實現(xiàn)從代碼編寫完成推送到Git/SVN后，自動觸發(fā)后端CaaS平臺將代碼下載、編譯并構建成測試Docker鏡像，再替換測試環(huán)境容器服務，自動在Jenkins或者Hudson中運行單元/集成測試，測試通過后，馬上就能自動將新版本鏡像更新到線上，完成服務升級。整個過程全自動化，一氣呵成，大程度地簡化了運維，而且保證線上、線下環(huán)境完全一致，而且線上服務版本與Git/SVN發(fā)布分支也實現(xiàn)統(tǒng)一。

解決微服務架構的實施難題

基于Spring Cloud這樣的微服務框架，能夠實現(xiàn)微服務的管理，但微服務本身還是需要運行在操作系統(tǒng)上。一個采用微服務架構開發(fā)的應用中，微服務的個數往往很多，這就導致了一臺服務器上往往需要啟動多個微服務來提高資源的利用率，而微服務本身可能就只能兼容部分操作系統(tǒng)。

這就導致了就算有大量的服務器資源(操作系統(tǒng)可能不一樣)，但由于微服務本身與操作系統(tǒng)可能相關，就不能做到讓微服務在任意服務器上運行，這就帶來了資源的浪費和運維的困難。利用Docker容器的環(huán)境隔離能力，讓微服務運行在容器內，就能夠解決以上所說的問題。

執(zhí)行臨時任務

有時候用戶只是想執(zhí)行一次性的任務，但如果用傳統(tǒng)虛擬機的方式就要搭建環(huán)境，執(zhí)行完任務后還要釋放資源，比較麻煩。使用Docker容器就可以構建臨時的運行環(huán)境，執(zhí)行完任務后關閉容器即可，方便快捷。

多租戶環(huán)境

利用Docker的環(huán)境隔離能力，可以為不同的租戶提供獨占的容器，實現(xiàn)簡單而且成本較低。

11. 總結

Docker的技術并不神秘，只是整合了前人積累的各種成果實現(xiàn)的應用級的容器化技術，它利用各種Linux發(fā)行版中使用了版本兼容的內核容器化技術，來實現(xiàn)鏡像一次構建到處運行的效果，并且利用了容器內的基礎操作系統(tǒng)鏡像層，屏蔽了實際運行環(huán)境的操作系統(tǒng)差異，使用戶在開發(fā)應用程序時，只需確保在選定的操作系統(tǒng)和內核版本上能正確運行即可，幾乎不需要關心實際的運行環(huán)境的系統(tǒng)差異，大大提高效率和兼容性。

但隨著容器運行得越來越多，容器管理將會稱為另一個運維的難題，這時候就需要引入Kubernetes、Mesos或Swarm這些容器管理系統(tǒng)，后面有機會再介紹這些技術。

文章標題：技術選型之Docker容器引擎
本文URL：http://www.bm7419.com/news21/202471.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供微信公眾號、小程序開發(fā)、動態(tài)網站、網站內鏈、用戶體驗、做網站

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)