容器的前世今生

###物理機

• 部署非常慢
  購買服務器服務，放在IDC機房，各種走流程，很多流程不可控制流程慢。
• 成本非常高
  物理的服務器，高額的配置成本貴。
• 資源浪費
  資源太多了，針對app的服務可能利用率不夠充分。
• 難於遷移和擴展
  遷移app端的服務器，我們要提前準備好一個新的物理服務器，環境需要重新的遷移。資源消耗比較大的話，用戶增加比較快需要擴展內存，cpu，硬盤麻煩，可能最後還是選擇購買新的物理服務器。
• 可能會被限定硬件廠家
  那些已經采用RISC架構或非x86平臺的用戶來說，要想體驗到x86平臺的高效、便捷就要進行系統遷移。但是對於絕大多數應用來說，遷移可不是一件容易的事兒，甚至有些人更是“談虎色變”。任何解釋性和編譯性語言都存在代碼的風險。
  
  

###虛擬機

物理資源的限定和調度，設置指定VM的內存，cpu，硬盤根據應用來進行控制，方便擴展，歡迎可以統一化，方便管理。可以使物理資源的最大化利用。

• 一個物理機部署多個服務
  在軟件中模擬各種操作系統，可以同時運行多個相同或者不同的操作系統方便，可掛起（暫停），可作快照，可作克隆，在運行的時候占用內存。
• 每個app在獨立的VM裏
  每個app都在一臺VM裏面，互相不幹擾不影響。
• 資源池
  一個物理機的資源分配到了不同的虛擬機裏
• 很容易擴展
  加物理機器 || 加虛擬機
• 很容易雲化
  亞馬遜AWS，阿裏雲，騰訊雲，華為雲等
  

###虛擬機的局限性
每個虛擬機就是一個操作系統，每個操作系統都要分配對應的操作系統資源，大家都用window系統，真正的生產環境一般都是用linux操作系統其中一部分原因就是因為linux系統消耗資源比較少。如果在一個物理服務器上放入10個虛擬機，每個虛擬機系統占用1g資源，等於浪費了10g的內存資源。所以當操作系統越來越多的時候消耗在系統上的資源也就越來越大。

###開發和運維面臨的問題

上邊是開發人員，下面是運維。
開發人員選擇了不同語言和環境來進行開發，運維人員為了使應用正常的跑起來需要配置盡量和開發人員開發一樣的環境來滿足應用的正常使用。

###容器解決了什麽問題

docker進行了容器的打包，打包好的容器，可以運行在任何的環境，解決了開發和運維直接的矛盾。開發和運維之間建立了橋梁，這也是時間devops的最佳解決方案。

###什麽是容器

對軟件和其依賴的標準化打包
應用之間相互隔離（肯定沒有虛擬機和物理機隔離的那麽完全）
共享同一個OS Kernel（同一個操作系統上）
可以運行在很多主流的操作系統上（unix，linux，windows等）

###虛擬機和容器的區別

###虛擬化和容器的結合

在國內很多場景都是虛擬化和容器結合來使用的，將物理機進行虛擬化出來多個VM，在VM內部在使用容器化。

容器技術的概述就講這麽多歡迎大家關註我，繼續更新，一起學習docker

往期精彩

1. docker導學（一）

『中級篇』容器的技術概述（二）