五分鐘認識docker 什麼是docker? 把他想象成一個用了一種新穎方式實現的超輕量虛擬機,在大概效果上也是正確的。當然在實現的原理和應用上還是和VM有巨大差別的,並且專業的叫法是應用容器(Application Container)。 為啥要用docker? 那麼應用容器長什麼樣子呢,一個做好 ...
五分鐘認識docker
什麼是docker?
把他想象成一個用了一種新穎方式實現的超輕量虛擬機,在大概效果上也是正確的。當然在實現的原理和應用上還是和VM有巨大差別的,並且專業的叫法是應用容器(Application Container)。
為啥要用docker?
那麼應用容器長什麼樣子呢,一個做好的應用容器長得就好像一個裝好了一組特定應用的虛擬機一樣。比如我現在想用MySQL那我就找個裝好MySQL的容器,運行起來,那麼我就可以使用 MySQL了。
那麼我直接裝個 MySQL不就好了,何必還需要這個容器這麼詭異的概念?話是這麼說,可是你要真裝MySQL的話可能要再裝一堆依賴庫,根據你的操作系統平臺和版本進行設置,有時候還要從源代碼編譯報出一堆莫名其妙的錯誤,可不是這麼好裝。而且萬一你機器掛了,所有的東西都要重新來,可能還要把配置在重新弄一遍。但是有了容器,你就相當於有了一個可以運行起來的虛擬機,只要你能運行容器,MySQL的配置就全省了。而且一旦你想換台機器,直接把這個容器端起來,再放到另一個機器就好了。硬體,操作系統,運行環境什麼的都不需要考慮了。
在公司中的一個很大的用途就是可以保證線下的開發環境、測試環境和線上的生產環境一致。當年在***經常碰到這樣的事情,開發把東西做好了給測試去測,一般會給一坨代碼和一個介紹上線步驟的上線單。結果代碼在測試機跑不起來,開發就跑來跑去看問題,一會兒啊這個配置文件忘了提交了,一會兒啊這個上線命令寫錯了。找到了一個 bug 提上去,開發一看,啊我怎麼又忘了把這個命令寫在上線單上了。類似的事情在上線的時候還會發生,變成啊你這個軟體的版本和我機器上的不一樣……在 ***的時候,由於一個開發直接擔任上述三個職位,而且有一套自動化部署的機制所以問題會少一點,但是上線的時候大家還是膽戰心驚。
若果利用容器的話,那麼開發直接在容器里開發,提測的時候把整個容器給測試,測好了把改動改在容器里再上線就好了。通過容器,整個開發、測試和生產環境可以保持高度的一致。
此外容器也和VM一樣具有著一定的隔離性,各個容器之間的數據和記憶體空間相互隔離,可以保證一定的安全性。
docker在很大程度上可以解決的問題
- 軟體更新發佈低效
- 業務無法敏捷
- 環境一致性,難於保證
- 不同環境之間遷移成本太高
- 軟體開發商,交付實施周期長—-成本高
那為啥不用VM?
那麼既然容器和 VM 這麼類似為啥不直接用 VM 還要整齣個容器這麼個概念來呢?Docker 容器相對於 VM 有以下幾個優點:
- 啟動速度快,容器通常在一秒內可以啟動,而 VM 通常要更久
- 資源利用率高,一臺普通 PC 可以跑上千個容器,你跑上千個 VM 試試
- 性能開銷小, VM 通常需要額外的 CPU 和記憶體來完成 OS 的功能,這一部分占據了額外的資源
為啥相似的功能在性能上會有如此巨大的差距呢,其實這和他們的設計的理念是相關的。 VM 的設計圖如下:
VM 的 Hypervisor 需要實現對硬體的虛擬化,並且還要搭載自己的操作系統,自然在啟動速度和資源利用率以及性能上有比較大的開銷。而 Docker 的設計圖是這樣的:
Docker 幾乎就沒有什麼虛擬化的東西,並且直接復用了 Host 主機的 OS,在 Docker Engine 層面實現了調度和隔離重量一下子就降低了好幾個檔次。 Docker 的容器利用了 lxc,管理利用了 namespaces 來做許可權的控制和隔離, cgroups 來進行資源的配置,並且還通過 aufs 來進一步提高文件系統的資源利用率。
其中的 aufs 是個很有意思的東西,是 UnionFS 的一種。他的思想和 git 有些類似,可以把對文件系統的改動當成一次 commit 一層層的疊加。這樣的話多個容器之間就可以共用他們的文件系統層次,每個容器下麵都是共用的文件系統層次,上面再是各自對文件系統改動的層次,這樣的話極大的節省了對存儲的需求,並且也能加速容器的啟動。
2016.10.27 00:20