100
《Docker容器：利用Kubernetes、Flannel、Cockpit和Atomic構建和部署》——第1章 使用Docker對應用進行容器化 1.1了解容器化應用的優缺點
本節書摘來自異步社區《Docker容器：利用Kubernetes、Flannel、Cockpit和Atomic構建和部署》一書中的第1章，第1.1節，作者： 【美】Christopher Negus（克裏斯托弗•尼格斯）著，更多章節內容可以訪問雲棲社區“異步社區”公眾號查看
第1章 使用Docker對應用進行容器化
Docker為應用程序的打包和運行提供了一種優雅的方式。使用喜歡的Linux係統，幾分鍾之內就能將Docker安裝好並作為服務運行起來。構建、運行、停止、啟動、調查、修改或者用其他的方式操作容器非常容易，說實話，很棒。
Docker的簡單易用使其成為當今最流行的開源項目之一。但是作為數據中心容器化核心的Docker卻引起了極大的震動，其潛力無異於重新發明了個人和公司（或大或小）創建、測試、部署和管理其最關鍵應用程序的方式。
使用容器化技術也可以讓應用程序向雲環境的部署變得更為高效。就像容器本身一樣，運行容器的操作係統也能夠被瘦身。因為容器已經持有應用程序運行所需的大部分依賴，所以這些用於容器的新型宿主機操作係統就不再需要包含所有依賴了。
本書不僅介紹什麼是Docker以及Docker的工作方式，還揭示了特定用途下擴展Docker的若幹方法。盡管一個容器的創建和部署是很簡單的，但要讓多個容器協同工作、訪問其他容器的資源，以及訪問運行容器的宿主機的資源，則需要更高的複雜性。本書給出了幾種創建和部署這些複雜容器集的不同方法。
本書並不隻停留在理論層麵，其探討的容器及容器相關工具的各個方麵都備有說明這些特性工作方式的實際例子。讀者可以自己先嚐試一下，然後按照自己使用Docker的方式修改和擴展這些實例。
然而，在開始本書的學習之前，讀者需要弄清楚關注容器的原因。
1.1 了解容器化應用的優缺點
Docker提供了一種創建和運行已經在容器中進行了配置的應用程序的方法。想要真正理解它，先了解容器化應用不是什麼是很有幫助的。
1.1.1 容器化應用不是直接在宿主機上運行的應用
運行應用程序的傳統方法會將應用程序直接安裝到宿主計算機的文件係統上並從那裏運行它。從應用程序的視角看來，其環境包含宿主機的進程表、文件係統、IPC設施、網絡接口、端口及設備。
要讓應用程序運行起來，通常需要安裝與應用程序搭配的額外軟件包。一般來說，這不是問題。但有些情況下，可能想在同一個係統上運行相同軟件包的不同版本，這就可能會引起衝突。
應用程序與應用程序之間也會以某種方式發生衝突。如果應用程序是服務，它可能會默認綁定特定的網絡端口。在服務啟動時，它可能還會讀取公共配置文件。這會導致無法在同一宿主機上運行該服務的多個實例，或者至少非常棘手；這還讓那些想要綁定到同一端口的其他服務難以運行。
直接在宿主機上運行應用程序還有一個缺點，那就是難以遷移應用程序。如果宿主機需要關機或者應用程序需要更多計算能力——超出宿主機所能提供的，那麼從宿主計算機上獲取所有依賴並將其遷移到另一台宿主機上絕非易事。
1.1.2 容器化應用不是直接在虛擬機上運行的應用
創建虛擬機來運行應用程序能夠克服直接在宿主機操作係統上運行應用程序所具有的缺點。雖然虛擬機位於宿主機上，但它作為獨立的操作係統運行，它包括自己的內核、文件係統、網絡接口等。這樣可以很容易將幾乎所有東西保存在獨立於宿主機的操作係統中。
因為虛擬機是獨立的實體，所以不會出現那種直接在硬件上運行應用程序所產生的缺乏靈活性的弊端。可以在宿主機上啟動10個不同的虛擬機來運行應用程序10次。雖然每個虛擬機上的服務監聽了同一個端口號，但是因為每個虛擬機擁有不同的IP地址，所以並不會引起衝突。
同樣地，如果需要關閉宿主計算機，可以將虛擬機遷移到其他宿主機上（如果虛擬化環境支持遷移）或者直接關閉虛擬機並在新宿主機上再次啟動它。
一個虛擬機運行一個應用程序的實例的缺點是耗費資源。你的應用程序可能隻需要幾兆字節磁盤空間來運行，但是整個虛擬機卻要耗費許多GB的空間。再者，虛擬機的啟動時間和CPU占用幾乎肯定會比應用程序自身消耗的高得多。
容器提供了另一種在宿主機上或虛擬機內直接運行應用程序的方式，這種方式能使應用程序更快、可移植性更好，並且更具可擴展性。
1.1.3 了解容器的優點
就運行應用程序而言，容器有望靈活高效地使用資源。
靈活性來自容器可以包含其所需的全部文件。如同運行於虛擬機中的應用程序，其可以擁有自己的配置文件和依賴庫，還可以擁有自己的網絡接口——這些網絡接口不同於宿主機上配置的那些網絡接口。因此，與在虛擬機上運行應用程序一樣，容器化應用比直接安裝的應用程序更容易遷移，而且因為應用程序運行所棲身的每個容器均擁有獨立的網絡接口，所以也不會爭用同一端口號。
就啟動時間、磁盤空間占用和處理能力而言，容器既沒有運行獨立的操作係統，也沒有包含運行整個操作係統所需的大量軟件。這是因為容器隻包含運行應用程序所需的軟件，以及其他想隨容器一起運行的工具和少量描述容器的元數據。
與虛擬機不同，Docker容器並不包含獨立的內核（kernel）。Docker容器中運行的命令會出現在宿主機的進程表中，多數情況下，看起來非常像係統中運行的其他進程。然而，這兩種環境中應用程序運行的差異與這兩個應用程序所看到的不同世界有著極大的關係。
文件係統：容器擁有自己的文件係統，默認情況下，它無法看到宿主機係統的文件係統。該規則的一個例外是，有些文件（如/etc/hosts和/etc/resolv.conf）可能會被自動掛載到容器中。另一個例外是，當運行容器鏡像時，可以顯式地將宿主機的目錄掛載到容器中。
進程表：Linux宿主機上可能運行著成百上千的進程。然而，默認情況下，容器內的進程無法看到宿主機的進程表，容器擁有自己的進程表。因此，你啟動容器時所運行的應用程序，其進程在容器內被分配的PID為1。從容器內，進程無法看到宿主機上運行的其他進程——如果這些進程沒有在容器內啟動的話。
網絡接口：默認情況下，Docker守護進程通過DHCP從一組私有IP地址集中確定IP地址。除了使用DHCP，Docker也支持其他網絡模式，例如，允許容器使用其他容器的網絡接口，直接使用宿主機的網絡接口，或者不使用網絡接口。依據你的選擇，你可以將容器內的端口暴露給宿主機的同一端口或不同端口。
IPC設施：容器內運行的進程不能與宿主機係統上運行的進程間通信（IPC）設施直接交互。你可以將宿主機上的IPC設施暴露給容器，但這不是默認的。每個容器都有自己的IPC設施。
設備：容器內的進程無法直接看到宿主機係統上的設備。不過，當容器啟動時可以設置一個特殊權限選項來授予該項權限。
如你所見，Docker容器可以在宿主機的視線內運行，但其運行方式限製了容器越過邊界所能看到的宿主機內容（除非明確地開放了那些視圖）。
1.1.4 了解容器化應用麵臨的挑戰
容器化應用麵臨的挑戰在於它們不同於那些不在容器中的應用程序。每個Linux係統中，用於啟動和停止服務以及查看出錯消息的設施已就位。Linux還提供了監控服務和輪換日誌文件的方法。
對於運行虛擬機而言，整個虛擬化平台（如OpenStack和Red Hat企業虛擬化）被構建來啟動、停止和使用虛擬機。雖然管理容器組的工具已在努力構建中，但大多數尚處於萌芽階段。諸如Kubernetes和OpenShift這樣的項目正在完成部署和管理容器組的框架。
Docker容器被打包為容器鏡像。為了能將容器鏡像保存在registry中並用docker命令管理它們，人們已經進行了大量的工作。然而，用於管理Docker鏡像的工具遠未像用來管理Linux軟件包（如基於Linux RPM或Deb的係統）的工具那樣成熟。
能夠驗證鏡像來自何處的工具、確定鏡像是否被篡改的工具以及查看容器中具體安裝了哪些軟件包和這些軟件包的版本的工具才剛剛開發。目前，要意識到，多數情況下很難完全保證從Docker Hub Registry上隨便獲取的鏡像可以安全使用。
使用容器的另一個挑戰來自這樣一個事實：就其本質而言，容器默認情況下無法看到其他容器。因此，要是你想讓自己的容器與其他容器緊密配合要怎麼辦呢？例如，你可能有一個Web服務器，你想讓這個服務器訪問你的數據庫服務器。
讓容器看到彼此的一些解決方案是Docker中能讓你將容器連接到一起的特性，以及讓你在pod的容器之間識別出服務的使用方和提供方的Kubernetes的特性。更多容器管理工具正被推出來解決這些問題。但切記，它們尚處於早期開發階段，而且容器管理的幾乎各個領域都有多個工具在開發，有時還相互矛盾。
最後更新：2017-05-31 16:31:23