Container

一：什麼是Container？Container的做用？

容器是一個標準的軟件單元，它將代碼及其全部依賴關係打包，以便應用程序從一個計算環境快速可靠地運行到另外一個計算環境.container的主要做用是將軟件打包成標準化單元用於開發，裝運和部署。下面以當下比較受歡迎的Docker容器爲例說明container的做用構成以及和虛擬軟件的區別。

Container所處的位置：

Container能夠運行在不一樣的操做系統之上

容器與虛擬機的區別

容器和虛擬機具備相似的資源隔離和分配優點，但功能不一樣，由於容器虛擬化操做系統而不是硬件。容器更便攜，更高效。

 

container：

容器是應用層的抽象，它將代碼和依賴關係打包在一塊兒。多個容器能夠在同一臺機器上運行，並與其餘容器共享操做系統內核，每一個容器在用戶空間中做爲獨立進程運行。容器佔用的空間比VM少（容器映像的大小一般爲幾十MB），能夠處理更多的應用程序，而且須要更少的VM和操做系統

VM:

虛擬機（VM）是物理硬件的抽象，將一臺服務器轉變爲多臺服務器。管理程序容許多臺VM在單臺機器上運行。每一個VM都包含操做系統的完整副本，應用程序，必要的二進制文件和庫 - 佔用數十GB。虛擬機也可能很慢啓動。

 

Container的歷史：

1979年：Unix V7     

在1979年Unix V7 的開發過程當中，引入了chroot系統調用，將進程的根目錄及其子進程更改成文件系統中的新位置。這一進步是開始的進程隔離：隔離每一個進程的文件訪問。Chroot 於1982年加入BSD。 

2000：FreeBSD Jails

 

FreeBSD Jails容許管理員將FreeBSD計算機系統劃分爲幾個獨立的小型系統 - 稱爲「jails」 - 可以爲每一個系統和配置分配IP地址

2001：Linux VServer

與FreeBSD Jails同樣，Linux VServer是一種能夠對計算機系統上的資源（文件系統，網絡地址，內存）進行分區的監獄機制。

2004年：Solaris Containers

2004年，第一個公開測試版 Solaris容器  被釋放 噸ħ 在  聯合機系統的資源控制，並經過區域，這是可以利用像從ZFS快照和克隆特徵提供邊界分離

2005年：Open VZ（Open Virtuzzo）

這是Linux 的操做系統級虛擬化技術，它使用修補的Linux內核進行虛擬化，隔離，資源管理和檢查點.

2006年：流程容器

Process Containers（由Google於2006年推出）旨在限制，計算和隔離一組進程的資源使用（CPU，內存，磁盤I / O，網絡）。一年後它被重命名爲「控制組（cgroups）」，最終合併到Linux內核2.6.24。

2008年：LXC

LXC（LinuX容器）是Linux容器管理器的第一個，最完整的實現。它是在2008年使用cgroups和Linux命名空間實現的，它能夠在單個Linux內核上運行，無需任何補丁。

2013年：LMCTFY

（LMCTFY）在2013年開始做爲谷歌容器堆棧的開源版本，提供Linux應用程序容器。應用程序能夠「容器識別」，建立和管理本身的子容器。在谷歌開始向libcontainer（如今是Open Container Foundation的一部分）提供核心LMCTFY概念後，LMCTFY的積極部署於2015年中止。

2013年：Docker 

當Docker於2013年問世時，容器爆炸式增加。Docker和容器使用的增加並不是巧合，這並不是巧合  。 正如Warden所作的那樣，Docker在其初始階段也使用了LXC，後來用本身的庫libcontainer替換了該容器管理器。但毫無疑問，Docker經過爲集裝箱管理提供整個生態系統而脫穎而出

二：Injection/Dependency injection

在軟件工程中，依賴注入是一種技術，其中一個對象（或靜態方法）提供另外一個對象的依賴關係。依賴項是可使用的對象（服務）。注入是將依賴項傳遞給將使用它的依賴對象（客戶端）。該服務是客戶所在端的一部分。將服務傳遞給客戶端，而不是容許客戶端構建或找到服務，是模式的基本要求。

依賴注入的目的是將對象解耦到不須要更改客戶端代碼的程度，由於它所依賴的對象須要更改成不一樣的對象。這容許遵循開放/封閉原則。

依賴注入是更普遍的控制反轉技術的一種形式。與其餘形式的控制反轉同樣，依賴注入支持依賴性反轉原則。客戶端將其依賴關係的責任委託給外部代碼（注入器）。客戶端不容許調用注入器代碼; ^[2]它是構建服務並調用客戶端注入它們的注入代碼。這意味着客戶端代碼不須要知道注入代碼，如何構建服務，甚至不知道它正在使用哪些實際服務; 客戶端只須要知道服務的內在接口，由於它們定義了客戶端如何使用服務。這分離了使用和構造的責任。

客戶端接受依賴注入有三種經常使用方法：setter - ，interface - 和基於構造函數的注入。Setter和構造函數注入主要取決於它們什麼時候可使用。接口注入的不一樣之處在於依賴關係有機會控制其自身的注入。每一個都要求單獨的構造代碼（注入器）負責將客戶端及其依賴關係引入彼此。

爲何要使用依賴注入：

• 依賴注入容許客戶端靈活地進行配置。只修改了客戶端的行爲。客戶端能夠對支持客戶指望的內部接口的任何事情采起行動。
• 依賴注入可用於將系統的配置詳細信息外部化爲配置文件，從而容許在不從新編譯的狀況下從新配置系統。能夠針對須要不一樣組件實現的不一樣狀況編寫單獨的配置。這包括但不限於測試。
• 由於依賴注入不須要對代碼行爲進行任何更改，因此它能夠做爲重構應用於遺留代碼。結果是客戶端更加獨立，而且使用存根或模擬對象模擬其餘未測試的對象，更容易單獨進行單元測試。這種易測性一般是使用依賴注入時注意到的第一個好處。
• 依賴注入容許客戶端刪除它須要使用的具體實現的全部知識。這有助於將客戶端與設計更改和缺陷的影響隔離開來。它提升了可重用性，可測試性和可維護性。
  
• 減小應用程序對象中的樣板代碼，由於初始化或設置依賴項的全部工做都由提供程序組件處理。
  
• 依賴注入容許併發或獨立開發。兩個開發人員能夠獨立開發彼此使用的類，而只須要知道類將經過的接口。插件一般由第三方商店開發，甚至從不與建立使用插件的產品的開發人員交談。
• 依賴注入減小了類與其依賴關係之間的耦合。

參考：

https://www.cnblogs.com/yuanchao-blog/p/10502844.html