一篇容器的前世今生說的清楚的文章
容器的前世今生
物理機
- 部署非常慢
- 購買服務器服務,放在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內部在使用容器化。

3個虛擬機,其中一個虛擬機里面跑這3個Docker