作者簡介: 辭七七,目前大一,正在學(xué)習(xí)C/C++,Java,Python等
作者主頁: 七七的個(gè)人主頁
文章收錄專欄: 七七的閑談
歡迎大家點(diǎn)贊 ?? 收藏 ? 加關(guān)注哦!????
簡介
Docker 是一個(gè)開源的應(yīng)用容器引擎,讓開發(fā)者可以打包他們的應(yīng)用以及依賴包到一個(gè)可移植的鏡像中,然后發(fā)布到任何流行的 Linux或Windows操作系統(tǒng)的機(jī)器上,也可以實(shí)現(xiàn)虛擬化。容器是完全使用沙箱機(jī)制,相互之間不會(huì)有任何接口。
一個(gè)完整的Docker有以下幾個(gè)部分組成:
- DockerClient客戶端
- Docker Daemon守護(hù)進(jìn)程
- Docker Image鏡像
- DockerContainer容器
Docker核心
Docker作為一個(gè)軟件集裝箱化平臺(tái),可以讓開發(fā)者構(gòu)建應(yīng)用程序時(shí),將它與其依賴環(huán)境一起打包到一個(gè)容器中,然后很容易地發(fā)布和應(yīng)用到任意平臺(tái)中
起源
Docker 是 PaaS 提供商 dotCloud 開源的一個(gè)基于 LXC 的高級(jí)容器引擎,源代碼托管在 Github 上, 基于go語言并遵從Apache2.0協(xié)議開源。
Docker自2013年以來非?;馃?,無論是從 github 上的代碼活躍度,還是Redhat在RHEL6.5中集成對(duì)Docker的支持, 就連 Google 的 Compute Engine 也支持 docker 在其之上運(yùn)行。
一款開源軟件能否在商業(yè)上成功,很大程度上依賴三件事 ——成功的 user case(用例), 活躍的社區(qū)和一個(gè)好故事。 dotCloud 之家的 PaaS 產(chǎn)品建立在docker之上,長期維護(hù)且有大量的用戶,社區(qū)也十分活躍,接下看看docker的故事。
- 環(huán)境管理復(fù)雜
- 云計(jì)算時(shí)代的到來
- 虛擬化手段的變化
- LXC的移動(dòng)性
面對(duì)上述幾個(gè)問題,docker設(shè)想是交付運(yùn)行環(huán)境如同海運(yùn),OS如同一個(gè)貨輪,每一個(gè)在OS基礎(chǔ)上的軟件都如同一個(gè)集裝箱,用戶可以通過標(biāo)準(zhǔn)化手段自由組裝運(yùn)行環(huán)境,同時(shí)集裝箱的內(nèi)容可以由用戶自定義,也可以由專業(yè)人員制造。這樣,交付一個(gè)軟件,就是一系列標(biāo)準(zhǔn)化組件的集合的交付,如同樂高積木,用戶只需要選擇合適的積木組合,并且在最頂端署上自己的名字(最后一個(gè)標(biāo)準(zhǔn)化組件是用戶的app)。這也就是基于docker的PaaS產(chǎn)品的原型。
Docker 架構(gòu)
Docker 使用客戶端-服務(wù)器 (C/S) 架構(gòu)模式,使用遠(yuǎn)程API來管理和創(chuàng)建Docker容器。Docker 容器通過 Docker 鏡像來創(chuàng)建。容器與鏡像的關(guān)系類似于面向?qū)ο缶幊讨械膶?duì)象與類。
Docker | 面向?qū)ο?/th> |
---|---|
容器 | 對(duì)象 |
鏡像 | 類 |
Docker采用 C/S架構(gòu) Docker daemon 作為服務(wù)端接受來自客戶的請(qǐng)求,并處理這些請(qǐng)求(創(chuàng)建、運(yùn)行、分發(fā)容器)。 客戶端和服務(wù)端既可以運(yùn)行在一個(gè)機(jī)器上,也可通過 socket 或者RESTful API 來進(jìn)行通信。Docker daemon 一般在宿主主機(jī)后臺(tái)運(yùn)行,等待接收來自客戶端的消息。 Docker 客戶端則為用戶提供一系列可執(zhí)行命令,用戶用這些命令實(shí)現(xiàn)跟 Docker daemon 交互。
特性
在docker的網(wǎng)站上提到了docker的典型場景:
- Automating the packaging and deployment of applications(使應(yīng)用的打包與部署自動(dòng)化)
- Creation of lightweight, private PAAS environments(創(chuàng)建輕量、私密的PAAS環(huán)境)
- Automated testing and continuous integration/deployment(實(shí)現(xiàn)自動(dòng)化測試和持續(xù)的集成/部署)
- Deploying and scaling web apps, databases and backend services(部署與擴(kuò)展webapp、數(shù)據(jù)庫和后臺(tái)服務(wù))
由于其基于LXC的輕量級(jí)虛擬化的特點(diǎn),docker相比KVM之類最明顯的特點(diǎn)就是啟動(dòng)快,資源占用小。
- 構(gòu)建標(biāo)準(zhǔn)化的運(yùn)行環(huán)境,現(xiàn)有的方案大多是在一個(gè)baseOS上運(yùn)行一套puppet/chef,或者一個(gè)image文件,其缺點(diǎn)是前者需要base OS許多前提條件,后者幾乎不可以修改(因?yàn)閏opy on write 的文件格式在運(yùn)行時(shí)rootfs是read only的)。并且后者文件體積大,環(huán)境管理和版本控制本身也是一個(gè)問題。
- PaaS環(huán)境是不言而喻的,其設(shè)計(jì)之初和dotcloud的案例都是將其作為PaaS產(chǎn)品的環(huán)境基礎(chǔ)
- 因?yàn)槠錁?biāo)準(zhǔn)化構(gòu)建方法(buildfile)和良好的REST API,自動(dòng)化測試和持續(xù)集成/部署能夠很好的集成進(jìn)來
- 因?yàn)長XC輕量級(jí)的特點(diǎn),其啟動(dòng)快,而且docker能夠只加載每個(gè)container變化的部分,這樣資源占用小,能夠在單機(jī)環(huán)境下與KVM之類的虛擬化方案相比能夠更加快速和占用更少資源
局限
- Docker并不是全能的,設(shè)計(jì)之初也不是KVM之類虛擬化手段的替代品,簡單總結(jié)幾點(diǎn):Docker是基于Linux 64bit的,無法在32bit的linux/Windows/unix環(huán)境下使用
- LXC是基于cgroup等linux kernel功能的,因此container的guest系統(tǒng)只能是linux base的
- 隔離性相比KVM之類的虛擬化方案還是有些欠缺,所有container公用一部分的運(yùn)行庫
- 網(wǎng)絡(luò)管理相對(duì)簡單,主要是基于namespace隔離
- cgroup的cpu和cpuset提供的cpu功能相比KVM的等虛擬化方案相比難以度量(所以dotcloud主要是按內(nèi)存收費(fèi))
- Docker對(duì)disk的管理比較有限
- container隨著用戶進(jìn)程的停止而銷毀,container中的log等用戶數(shù)據(jù)不便收集
原理
Docker核心解決的問題是利用LXC來實(shí)現(xiàn)類似VM的功能,從而利用更加節(jié)省的硬件資源提供給用戶更多的計(jì)算資源。同VM的方式不同, LXC 其并不是一套硬件虛擬化方法 - 無法歸屬到全虛擬化、部分虛擬化和半虛擬化中的任意一個(gè),而是一個(gè)操作系統(tǒng)級(jí)虛擬化方法, 理解起來可能并不像VM那樣直觀。所以可以從虛擬化到docker要解決的問題出發(fā),看看docker是怎么滿足用戶虛擬化需求的。
用戶需要考慮虛擬化方法,尤其是硬件虛擬化方法,需要借助其解決的主要是以下4個(gè)問題:
- 隔離性
- 可配額/可度量
- 移動(dòng)性
- 安全性
Linux Namespace
LXC所實(shí)現(xiàn)的隔離性主要是來自kernel的namespace, 其中pid, net, ipc, mnt, uts 等namespace將container的進(jìn)程, 網(wǎng)絡(luò), 消息, 文件系統(tǒng)和hostname 隔離開。
pid namespace之前提到用戶的進(jìn)程是lxc-start進(jìn)程的子進(jìn)程, 不同用戶的進(jìn)程就是通過pidnamespace隔離開的,且不同 namespace 中可以有相同PID。具有以下特征:
- 每個(gè)namespace中的pid是有自己的pid=1的進(jìn)程(類似/sbin/init進(jìn)程)
- 每個(gè)namespace中的進(jìn)程只能影響自己的同一個(gè)namespace或子namespace中的進(jìn)程
- 因?yàn)?proc包含正在運(yùn)行的進(jìn)程,因此在container中的pseudo-filesystem的/proc目錄只能看到自己namespace中的進(jìn)程
- 因?yàn)閚amespace允許嵌套,父namespace可以影響子namespace的進(jìn)程,所以子namespace的進(jìn)程可以在父namespace中看到,但是具有不同的pid
Linux 容器
借助于namespace的隔離機(jī)制和cgroup限額功能,LXC提供了一套統(tǒng)一的API和工具來建立和管理container。
LXC 旨在提供一個(gè)共享kernel的 OS 級(jí)虛擬化方法,在執(zhí)行時(shí)不用重復(fù)加載Kernel, 且container的kernel與host共享,因此可以大大加快container的 啟動(dòng)過程,并顯著減少內(nèi)存消耗。在實(shí)際測試中,基于LXC的虛擬化方法的IO和CPU性能幾乎接近 baremetal 的性能, 大多數(shù)數(shù)據(jù)有相比 Xen具有優(yōu)勢。當(dāng)然對(duì)于KVM這種也是通過Kernel進(jìn)行隔離的方式, 性能優(yōu)勢或許不是那么明顯, 主要還是內(nèi)存消耗和啟動(dòng)時(shí)間上的差異。
在參考文獻(xiàn)中提到了利用iozone進(jìn)行 Disk IO吞吐量測試KVM反而比LXC要快,而且筆者在device mapping driver下重現(xiàn)同樣case的實(shí)驗(yàn)中也確實(shí)能得到如此結(jié)論。參考文獻(xiàn)從網(wǎng)絡(luò)虛擬化中虛擬路由的場景(網(wǎng)絡(luò)IO和CPU角度)比較了KVM和LXC, 得到結(jié)論是KVM在性能和隔離性的平衡上比LXC更優(yōu)秀 - KVM在吞吐量上略差于LXC, 但CPU的隔離可管理項(xiàng)比LXC更明確。文章來源:http://www.zghlxwxcb.cn/news/detail-469309.html
關(guān)于【Docker】什么是Docker,它用來干什么,七七就先分享到這里了,如果你認(rèn)為這篇文章對(duì)你有幫助,請(qǐng)給七七點(diǎn)個(gè)贊吧,如果發(fā)現(xiàn)什么問題,歡迎評(píng)論區(qū)留言?。????文章來源地址http://www.zghlxwxcb.cn/news/detail-469309.html
到了這里,關(guān)于【Docker】什么是Docker,它用來干什么的文章就介紹完了。如果您還想了解更多內(nèi)容,請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章,希望大家以后多多支持TOY模板網(wǎng)!