天天看點

雲計算(1)——docker的前世今生

docker是什麼?

Docker 是一個開源的應用容器引擎,讓開發者可以打包他們的應用以及依賴包到一個可移植的容器中,然後釋出到任何流行的Linux機器上,也可以實作虛拟化,容器是完全使用沙箱機制,互相之間不會有任何接口。

了解虛拟機

使用虛拟機運作多個互相隔離的應用時,如下圖:

雲計算(1)——docker的前世今生

從下到上了解上圖:

•基礎設施(Infrastructure)。它可以是你的個人電腦,資料中心的伺服器,或者是雲主機。•主作業系統(Host Operating System)。你的個人電腦之上,運作的可能是MacOS,Windows或者某個Linux發行版。•虛拟機管理系統(Hypervisor)。利用Hypervisor,可以在主作業系統之上運作多個不同的從作業系統。類型1的Hypervisor有支援MacOS的HyperKit,支援Windows的Hyper-V以及支援Linux的KVM。類型2的Hypervisor有VirtualBox和VMWare。•從作業系統(Guest Operating System)。假設你需要運作3個互相隔離的應用,則需要使用Hypervisor啟動3個從作業系統,也就是3個虛拟機。這些虛拟機都非常大,也許有700MB,這就意味着它們将占用2.1GB的磁盤空間。更糟糕的是,它們還會消耗很多CPU和記憶體。•各種依賴。每一個從作業系統都需要安裝許多依賴。如果你的的應用需要連接配接PostgreSQL的話,則需要安裝libpq-dev;如果你使用Ruby的話,應該需要安裝gems;如果使用其他程式設計語言,比如Python或者Node.js,都會需要安裝對應的依賴庫。•應用。安裝依賴之後,就可以在各個從作業系統分别運作應用了,這樣各個應用就是互相隔離的。

了解Docker容器

使用Docker容器運作多個互相隔離的應用時,如下圖:

雲計算(1)——docker的前世今生

不難發現,相比于虛拟機,Docker要簡潔很多。因為我們不需要運作一個臃腫的從作業系統了。

從下到上了解上圖:

•基礎設施(Infrastructure)。•主作業系統(Host Operating System)。所有主流的Linux發行版都可以運作Docker。對于MacOS和Windows,也有一些辦法”運作”Docker。•Docker守護程序(Docker Daemon)。Docker守護程序取代了Hypervisor,它是運作在作業系統之上的背景程序,負責管理Docker容器。•各種依賴。對于Docker,應用的所有依賴都打包在Docker鏡像中,Docker容器是基于Docker鏡像建立的。•應用。應用的源代碼與它的依賴都打包在Docker鏡像中,不同的應用需要不同的Docker鏡像。不同的應用運作在不同的Docker容器中,它們是互相隔離的。

對比虛拟機與Docker

Docker守護程序可以直接與主作業系統進行通信,為各個Docker容器配置設定資源;它還可以将容器與主作業系統隔離,并将各個容器互相隔離。虛拟機啟動需要數分鐘,而Docker容器可以在數毫秒内啟動。由于沒有臃腫的從作業系統,Docker可以節省大量的磁盤空間以及其他系統資源。

說了這麼多Docker的優勢,大家也沒有必要完全否定虛拟機技術,因為兩者有不同的使用場景。虛拟機更擅長于徹底隔離整個運作環境。例如,雲服務提供商通常采用虛拟機技術隔離不同的使用者。而Docker通常用于隔離不同的應用,例如前端,後端以及資料庫。

雲計算(1)——docker的前世今生

容器發展之路

業務是運作在應用之上的,而應用一開始隻能運作在實體伺服器上。為了保障應用的平穩運作,我們采購的伺服器通常性能都大于業務需求的性能。甚至我們通常在一個伺服器上隻運作一個應用,目的是應用之間不會互相影響。這無疑對伺服器資源是個極大的浪費。

  後來,出現了虛拟機,虛拟機把伺服器的資源給虛拟化了,可以在一台伺服器上安裝部署多個虛拟機。每個虛拟機的環境完全獨立,大大提高了伺服器的資源使用率,最終為公司節約了大量的資金支出。

  虛拟機很美好,但是有一個明顯的缺點,就是依賴其OS。每個虛拟機都要安裝一個OS,OS會占用額外的CPU、RAM和存儲,此外OS還需要定期打更新檔和監控,這些都需要資源。接下來就出現了容器技術,容器模型和虛拟機模型相似,其主要的差別在于,容器的運作不會獨占作業系統。實際上,運作在相同主控端上的容器是共享一個作業系統的,這樣就能節約了大量的資源。虛拟機是虛拟化了硬體資源,而容器則是對系統做了虛拟化。這樣帶來的好處就是,資源使用率提高了,節省了資金成本。

  此外,容器技術還具有快速啟動、便于遷移的特點,可以輕松把容器從筆記本遷移到伺服器上。這就解決了一個運作環境的痛點了,不會再有人說為什麼在我的電腦上能正常運作的,在伺服器上就出錯了,肯定是環境不一樣造成的糾紛。

  說到容器技術,當然要提到其中的扛把子——Docker。容器技術不等于Docker,但是提到容器多數人都第一時間想到的是Docker。對容器發展影響比較大的技術包括核心命名空間(kernel Namespace)、控制組(Control Group)、聯合檔案系統(Union File System)以及Docker。事實上,容器化技術很早就出現了,曆史甚至可以追溯到大型機的時代。

為什麼對容器的資源進行可視化隔離?

容器技術提供了不同于傳統虛拟機技術的環境隔離方式。通常的Linux容器對容器打包和啟動進行了加速,但也降低了容器的隔離強度。其中Linux容器最為知名的問題就是資源視圖隔離問題。

容器可以通過cgroup的方式對資源的使用情況進行限制,包括:記憶體,CPU等。但是需要注意的是,如果容器内的一個程序使用一些常用的監控指令,如:free,top等指令其實看到還是實體機的資料,而非容器的資料。這是由于容器并沒有做到對/proc/sys等檔案系統的隔離。

容器資源視圖隔離有哪些應用場景?

在容器生産環境,通常有一些業務已經習慣了在傳統的實體機,虛拟機上使用top,free等指令來檢視系統的資源使用情況,但是容器沒有做到資源視圖隔離,那麼在容器裡面看到的資料還是實體機的資料。

在應用程式的視角來看,在容器裡面運作程序和在實體機虛拟機上運作程序的運作環境是不同的。并且有些應用在容器裡面運作程序會存在一些安全隐患:

•對于很多基于JVM的Java程式,應用啟動時會根據系統的資源上限來配置設定JVM的堆和棧的大小。而在容器裡面運作運作JAVA應用由于JVM擷取的記憶體資料還是實體機的資料,而容器配置設定的資源配額又小于JVM啟動時需要的資源大小,就會導緻程式啟動不成功。并且在Java應用裡,一些Java庫也會根據資源視圖配置設定堆和棧的大小,這同樣會存在安全隐患。•在CPU上也會存在問題,大多數的應用程式,比如Nginx或者一些其它的中間件服務會根據其視圖的cpuinfo檔案資訊設定預設的啟動線程數。但是在容器内的程序總會從/proc/cpuinfo中擷取到CPU的核數,而容器裡面的/proc檔案系統還是實體機的,進而會影響到運作在容器裡面服務的性能。

消息中間件Rabbitmq(01)

消息中間件Rabbitmq(02)

消息中間件Rabbitmq(03)

消息中間件Rabbitmq(04)

消息中間件Rabbitmq(05)

消息中間件Rabbitmq(06)

消息中間件Rabbitmq(07)

繼續閱讀