當前位置:首頁 » 硬件·內核·Shell·監測, 系統管理 » Docker百科

Docker百科命令

簡介

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

一個完整的Docker有以下幾個部分組成:

  1. DockerClient客戶端

  2. Docker Daemon守護進程

  3. Docker Image鏡像

  4. DockerContainer容器 

 

起源

Docker 是 PaaS 提供商 dotCloud 開源的一個基于 LXC 的高級容器引擎,源代碼托管在 Github 上, 基于go語言并遵從Apache2.0協議開源。

Docker自2013年以來非?;馃?,無論是從 github 上的代碼活躍度,還是Redhat在RHEL6.5中集成對Docker的支持, 就連 Google 的 Compute Engine 也支持 docker 在其之上運行。

一款開源軟件能否在商業上成功,很大程度上依賴三件事 - 成功的 user case(用例), 活躍的社區和一個好故事。 dotCloud 自家的 PaaS 產品建立在docker之上,長期維護且有大量的用戶,社區也十分活躍,接下來我們看看docker的故事。

  • 環境管理復雜 - 從各種OS到各種中間件到各種app, 一款產品能夠成功作為開發者需要關心的東西太多,且難于管理,這個問題幾乎在所有現代IT相關行業都需要面對。

  • 云計算時代的到來 - AWS的成功, 引導開發者將應用轉移到 cloud 上, 解決了硬件管理的問題,然而中間件相關的問題依然存在 (所以openstack HEAT和 AWS cloudformation 都著力解決這個問題)。開發者思路變化提供了可能性。

  • 虛擬化手段的變化 - cloud 時代采用標配硬件來降低成本,采用虛擬化手段來滿足用戶按需使用的需求以及保證可用性和隔離性。然而無論是KVM還是Xen在 docker 看來,都在浪費資源,因為用戶需要的是高效運行環境而非OS, GuestOS既浪費資源又難于管理, 更加輕量級的LXC更加靈活和快速

  • LXC的移動性 - LXC在 linux 2.6 的 kernel 里就已經存在了,但是其設計之初并非為云計算考慮的,缺少標準化的描述手段和容器的可遷移性,決定其構建出的環境難于遷移和標準化管理(相對于KVM之類image和snapshot的概念)。docker 就在這個問題上做出實質性的革新。這是docker最獨特的地方。

VM技術和容器技術對比VM技術和容器技術對比

面對上述幾個問題,docker設想是交付運行環境如同海運,OS如同一個貨輪,每一個在OS基礎上的軟件都如同一個集裝箱,用戶可以通過標準化手段自由組裝運行環境,同時集裝箱的內容可以由用戶自定義,也可以由專業人員制造。這樣,交付一個軟件,就是一系列標準化組件的集合的交付,如同樂高積木,用戶只需要選擇合適的積木組合,并且在最頂端署上自己的名字(最后一個標準化組件是用戶的app)。這也就是基于docker的PaaS產品的原型。

 

Docker 架構

Docker 使用客戶端-服務器 (C/S) 架構模式,使用遠程API來管理和創建Docker容器。Docker 容器通過 Docker 鏡像來創建。容器與鏡像的關系類似于面向對象編程中的對象與類。 

Docker 面向對象
容器 對象
鏡像

Docker采用 C/S架構 Docker daemon 作為服務端接受來自客戶的請求,并處理這些請求(創建、運行、分發容器)。 客戶端和服務端既可以運行在一個機器上,也可通過 socket 或者RESTful API 來進行通信。

Docker daemon 一般在宿主主機后臺運行,等待接收來自客戶端的消息。 Docker 客戶端則為用戶提供一系列可執行命令,用戶用這些命令實現跟 Docker daemon 交互。 

 

特性

在docker的網站上提到了docker的典型場景:

  • Automating the packaging and deployment of applications(使應用的打包與部署自動化)

  • Creation of lightweight, private PAAS environments(創建輕量、私密的PAAS環境)

  • Automated testing and continuous integration/deployment(實現自動化測試和持續的集成/部署)

  • Deploying and scaling web apps, databases and backend services(部署與擴展webapp、數據庫和后臺服務)

由于其基于LXC的輕量級虛擬化的特點,docker相比KVM之類最明顯的特點就是啟動快,資源占用小。因此對于構建隔離的標準化的運行環境,輕量級的PaaS(如dokku), 構建自動化測試和持續集成環境,以及一切可以橫向擴展的應用(尤其是需要快速啟停來應對峰谷的web應用)。

  1. 構建標準化的運行環境,現有的方案大多是在一個baseOS上運行一套puppet/chef,或者一個image文件,其缺點是前者需要base OS許多前提條件,后者幾乎不可以修改(因為copy on write 的文件格式在運行時rootfs是read only的)。并且后者文件體積大,環境管理和版本控制本身也是一個問題。

  2. PaaS環境是不言而喻的,其設計之初和dotcloud的案例都是將其作為PaaS產品的環境基礎

  3. 因為其標準化構建方法(buildfile)和良好的REST API,自動化測試和持續集成/部署能夠很好的集成進來

  4. 因為LXC輕量級的特點,其啟動快,而且docker能夠只加載每個container變化的部分,這樣資源占用小,能夠在單機環境下與KVM之類的虛擬化方案相比能夠更加快速和占用更少資源

 

局限

Docker并不是全能的,設計之初也不是KVM之類虛擬化手段的替代品,簡單總結幾點:

  1. Docker是基于Linux 64bit的,無法在32bit的linux/Windows/unix環境下使用

  2. LXC是基于cgroup等linux kernel功能的,因此container的guest系統只能是linux base的

  3. 隔離性相比KVM之類的虛擬化方案還是有些欠缺,所有container公用一部分的運行庫

  4. 網絡管理相對簡單,主要是基于namespace隔離

  5. cgroup的cpu和cpuset提供的cpu功能相比KVM的等虛擬化方案相比難以度量(所以dotcloud主要是按內存收費)

  6. Docker對disk的管理比較有限

  7. container隨著用戶進程的停止而銷毀,container中的log等用戶數據不便收集

針對1-2,有windows base應用的需求的基本可以pass了; 3-5主要是看用戶的需求,到底是需要一個container還是一個VM, 同時也決定了docker作為 IaaS 不太可行。

針對6,7雖然是docker本身不支持的功能,但是可以通過其他手段解決(disk quota, mount --bind)??傊?,選用container還是vm, 就是在隔離性和資源復用性上做權衡。

另外即便docker 0.7能夠支持非AUFS的文件系統,但是由于其功能還不穩定,商業應用或許會存在問題,而AUFS的穩定版需要kernel 3.8, 所以如果想復制dotcloud的成功案例,可能需要考慮升級kernel或者換用ubuntu的server版本(后者提供deb更新)。這也是為什么開源界更傾向于支持ubuntu的原因(kernel版本)

Docker并非適合所有應用場景,Docker只能虛擬基于Linux的服務。Windows Azure 服務能夠運行Docker實例,但到為止Windows服務還不能被虛擬化。

可能最大的障礙在于管理實例之間的交互。由于所有應用組件被拆分到不同的容器中,所有的服務器需要以一致的方式彼此通信。這意味著任何人如果選擇復雜的基礎設施,那么必須掌握應用編程接口管理以及集群工具,比如Swarm、Mesos或者Kubernets以確保機器按照預期運轉并支持故障切換。

Docker在本質上是一個附加系統。使用文件系統的不同層構建一個應用是有可能的。每個組件被添加到之前已經創建的組件之上,可以比作為一個文件系統更明智。分層架構帶來另一方面的效率提升,當你重建存在變化的Docker鏡像時,不需要重建整個Docker鏡像,只需要重建變化的部分。

可能更為重要的是,Docker旨在用于彈性計算。每個Docker實例的運營生命周期有限,實例數量根據需求增減。在一個管理適度的系統中,這些實例生而平等,不再需要時便各自消亡了。

針對Docker環境存在的不足,意味著在開始部署Docker前需要考慮如下幾個問題。首先,Docker實例是無狀態的。這意味著它們不應該承載任何交易數據,所有數據應該保存在數據庫服務器中。

其次,開發Docker實例并不像創建一臺虛擬機、添加應用然后克隆那樣簡單。為成功創建并使用Docker基礎設施,管理員需要對系統管理的各個方面有一個全面的理解,包括Linux管理、編排及配置工具比如Puppet、Chef以及Salt。這些工具生來就基于命令行以及腳本。 

 

原理

Docker核心解決的問題是利用LXC來實現類似VM的功能,從而利用更加節省的硬件資源提供給用戶更多的計算資源。同VM的方式不同, LXC 其并不是一套硬件虛擬化方法 - 無法歸屬到全虛擬化、部分虛擬化和半虛擬化中的任意一個,而是一個操作系統級虛擬化方法, 理解起來可能并不像VM那樣直觀。所以我們從虛擬化到docker要解決的問題出發,看看他是怎么滿足用戶虛擬化需求的。

用戶需要考慮虛擬化方法,尤其是硬件虛擬化方法,需要借助其解決的主要是以下4個問題:

  • 隔離性 - 每個用戶實例之間相互隔離, 互不影響。 硬件虛擬化方法給出的方法是VM, LXC給出的方法是container,更細一點是kernel namespace

  • 可配額/可度量 - 每個用戶實例可以按需提供其計算資源,所使用的資源可以被計量。硬件虛擬化方法因為虛擬了CPU, memory可以方便實現, LXC則主要是利用cgroups來控制資源

  • 移動性 - 用戶的實例可以很方便地復制、移動和重建。硬件虛擬化方法提供snapshot和image來實現,docker(主要)利用AUFS實現

  • 安全性 - 這個話題比較大,這里強調是host主機的角度盡量保護container。硬件虛擬化的方法因為虛擬化的水平比較高,用戶進程都是在KVM等虛擬機容器中翻譯運行的, 然而對于LXC, 用戶的進程是lxc-start進程的子進程, 只是在Kernel的namespace中隔離的, 因此需要一些kernel的patch來保證用戶的運行環境不會受到來自host主機的惡意入侵, dotcloud(主要是)利用kernel grsec patch解決的.

 

Linux Namespace

LXC所實現的隔離性主要是來自kernel的namespace, 其中pid, net, ipc, mnt, uts 等namespace將container的進程, 網絡, 消息, 文件系統和hostname 隔離開。

pid namespace

之前提到用戶的進程是lxc-start進程的子進程, 不同用戶的進程就是通過pidnamespace隔離開的,且不同 namespace 中可以有相同PID。具有以下特征:

  1. 每個namespace中的pid是有自己的pid=1的進程(類似/sbin/init進程)

  2. 每個namespace中的進程只能影響自己的同一個namespace或子namespace中的進程

  3. 因為/proc包含正在運行的進程,因此在container中的pseudo-filesystem的/proc目錄只能看到自己namespace中的進程

  4. 因為namespace允許嵌套,父namespace可以影響子namespace的進程,所以子namespace的進程可以在父namespace中看到,但是具有不同的pid

正是因為以上的特征,所有的LXC進程在docker中的父進程為docker進程,每個lxc進程具有不同的namespace。同時由于允許嵌套,因此可以很方便的實現 LXC in LXC

net namespace

有了 pid namespace, 每個namespace中的pid能夠相互隔離,但是網絡端口還是共享host的端口。網絡隔離是通過netnamespace實現的,

每個net namespace有獨立的 network devices, ip addresses, IP routing tables, /proc/net 目錄。這樣每個container的網絡就能隔離開來。

LXC在此基礎上有5種網絡類型,docker默認采用veth的方式將container中的虛擬網卡同host上的一個docker bridge連接在一起。

ipc namespace

container中進程交互還是采用linux常見的進程間交互方法(interprocess communication - IPC), 包括常見的信號量、消息隊列和共享內存。然而同VM不同,container 的進程間交互實際上還是host上具有相同pid namespace中的進程間交互,因此需要在IPC資源申請時加入namespace信息 - 每個IPC資源有一個的 32bit id。

mnt namespace

類似chroot,將一個進程放到一個特定的目錄執行。mnt namespace允許不同namespace的進程看到的文件結構不同,這樣每個 namespace 中的進程所看到的文件目錄就被隔離開了。同chroot不同,每個namespace中的container在/proc/mounts的信息只包含所在namespace的mount point。

uts namespace

UTS(“UNIX time-sharing System”) namespace允許每個container擁有獨立的hostname和domain name, 
  使其在網絡上可以被視作一個獨立的節點而非Host上的一個進程。

user namespace

每個container可以有不同的 user 和 group id, 也就是說可以以container內部的用戶在container內部執行程序而非Host上的用戶。

有了以上6種namespace從進程、網絡、IPC、文件系統、UTS和用戶角度的隔離,一個container就可以對外展現出一個獨立計算機的能力,并且不同container從OS層面實現了隔離。 
  然而不同namespace之間資源還是相互競爭的,仍然需要類似ulimit來管理每個container所能使用的資源 - LXC 采用的是cgroup。 

 

Control groups

cgroups 實現了對資源的配額和度量。 cgroups 的使用非常簡單,提供類似文件的接口,在 /cgroup目錄下新建一個文件夾即可新建一個group,在此文件夾中新建task文件,并將pid寫入該文件,即可實現對該進程的資源控制。具體的資源配置選項可以在該文件夾中新建子 subsystem ,{子系統前綴}.{資源項} 是典型的配置方法,

如memory.usage_in_bytes 就定義了該group 在subsystem memory中的一個內存限制選項。

另外,cgroups中的 subsystem可以隨意組合,一個subsystem可以在不同的group中,也可以一個group包含多個subsystem - 也就是說一個 subsystem。

關于術語定義

A *cgroup* associates a set of tasks with a set of parameters for one 
  or more subsystems. 
  A *subsystem* is a module that makes use of the task grouping 
  facilities provided by cgroups to treat groups of tasks in 
  particular ways. A subsystem is typically a "resource controller" that 
  schedules a resource or applies per-cgroup limits, but it may be 
  anything that wants to act on a group of processes, e.g. a 
  virtualization subsystem.

我們主要關心cgroups可以限制哪些資源,即有哪些subsystem是我們關心。

cpu : 在cgroup中,并不能像硬件虛擬化方案一樣能夠定義CPU能力,但是能夠定義CPU輪轉的優先級,因此具有較高CPU優先級的進程會更可能得到CPU運算。 
  通過將參數寫入cpu.shares,即可定義改cgroup的CPU優先級 - 這里是一個相對權重,而非絕對值。當然在cpu這個subsystem中還有其他可配置項,手冊中有詳細說明。

cpusets : cpusets 定義了有幾個CPU可以被這個group使用,或者哪幾個CPU可以供這個group使用。在某些場景下,單CPU綁定可以防止多核間緩存切換,從而提高效率

memory : 內存相關的限制

blkio : block IO相關的統計和限制,byte/operation統計和限制(IOPS等),讀寫速度限制等,但是這里主要統計的都是同步IO

net_cls, cpuacct , devices , freezer 等其他可管理項。

 

Linux 容器

借助于namespace的隔離機制和cgroup限額功能,LXC提供了一套統一的API和工具來建立和管理container, LXC利用了如下 kernel 的features: [8]

  • Kernel namespaces (ipc, uts, mount, pid, network and user)

  • Apparmor and SELinux profiles

  • Seccomp policies

  • Chroots (using pivot_root)

  • Kernel capabilities

  • Control groups (cgroups)

LXC 向用戶屏蔽了以上 kernel 接口的細節, 提供了如下的組件大大簡化了用戶的開發和使用工作:

  • The liblxc library

  • Several language bindings (python3, lua and Go)

  • A set of standard tools to control the containers

  • Container templates

LXC 旨在提供一個共享kernel的 OS 級虛擬化方法,在執行時不用重復加載Kernel, 且container的kernel與host共享,因此可以大大加快container的 啟動過程,并顯著減少內存消耗。在實際測試中,基于LXC的虛擬化方法的IO和CPU性能幾乎接近 baremetal 的性能  , 大多數數據有相比 Xen具有優勢。當然對于KVM這種也是通過Kernel進行隔離的方式, 性能優勢或許不是那么明顯, 主要還是內存消耗和啟動時間上的差異。在參考文獻 中提到了利用iozone進行 Disk IO吞吐量測試KVM反而比LXC要快,而且筆者在device mapping driver下重現同樣case的實驗中也確實能得到如此結論。參考文獻從網絡虛擬化中虛擬路由的場景(網絡IO和CPU角度)比較了KVM和LXC, 得到結論是KVM在性能和隔離性的平衡上比LXC更優秀 - KVM在吞吐量上略差于LXC, 但CPU的隔離可管理項比LXC更明確。

關于CPU, DiskIO, network IO 和 memory 在KVM和LXC中的比較還是需要更多的實驗才能得出可信服的結論。

 

AUFS

Docker對container的使用基本是建立在LXC基礎之上的,然而LXC存在的問題是難以移動 - 難以通過標準化的模板制作、重建、復制和移動 container。

在以VM為基礎的虛擬化手段中,有image和snapshot可以用于VM的復制、重建以及移動的功能。想要通過container來實現快速的大規模部署和更新, 這些功能不可或缺。

Docker 正是利用AUFS來實現對container的快速更新 - 在docker0.7中引入了storage driver, 支持AUFS, VFS, device mapper, 也為BTRFS以及ZFS引入提供了可能。 但除了AUFS都未經過dotcloud的線上使用,因此我們還是從AUFS的角度介紹。

AUFS (AnotherUnionFS) 是一種 Union FS, 簡單來說就是支持將不同目錄掛載到同一個虛擬文件系統下(unite several directories into a single virtual filesystem)的文件系統, 更進一步地, AUFS支持為每一個成員目錄(AKA branch)設定'readonly', 'readwrite' 和 'whiteout-able' 權限, 同時AUFS里有一個類似

分層的概念, 對 readonly 權限的branch可以邏輯上進行修改(增量地, 不影響readonly部分的)。通常 Union FS有兩個用途, 一方面可以實現不借助 LVM, RAID 將多個disk和掛在到一個目錄下, 另一個更常用的就是將一個readonly的branch和一個writeable的branch聯合在一起,Live cd正是基于此可以允許在 OS image 不變的基礎上允許用戶在其上進行一些寫操作。Docker在AUFS上構建的container image也正是如此,接下來我們從啟動container中的linux為例介紹docker在AUFS特性的運用。

圖1圖1

典型的Linux啟動到運行需要兩個FS - bootfs + rootfs (從功能角度而非文件系統角度)(圖1)

bootfs (boot file system) 主要包含 bootloader 和 kernel, bootloader主要是引導加載kernel, 當boot成功后 kernel 被加載到內存中后 bootfs就被umount了.

rootfs (root file system) 包含的就是典型 Linux 系統中的 /dev, /proc, /bin, /etc 等標準目錄和文件。

由此可見對于不同的linux發行版, bootfs基本是一致的, rootfs會有差別, 因此不同的發行版可以公用bootfs 如下(圖2):

圖2圖2

典型的Linux在啟動后,首先將 rootfs 置為 readonly, 進行一系列檢查, 然后將其切換為 “readwrite” 供用戶使用。在docker中,起初也是將 rootfs 以readonly方式加載并檢查,然而接下來利用 union mount 的將一個 readwrite 文件系統掛載在 readonly 的rootfs之上,并且允許再次將下層的 file system設定為readonly 并且向上疊加, 這樣一組readonly和一個writeable的結構構成一個container的運行目錄, 每一個被稱作一個Layer。如下(圖3):

得益于AUFS的特性, 每一個對readonly層文件/目錄的修改都

圖3圖3

只會存在于上層的writeable層中。這樣由于不存在競爭, 多個container可以共享readonly的layer。

所以docker將readonly的層稱作 “image” - 對于container而言整個rootfs都是read-write的,但事實上所有的修改都寫入最上層的writeable層中,

image不保存用戶狀態,可以用于模板、重建和復制。

(圖4、5)

圖4圖4

圖5圖5

上層的image依賴下層的image,因此docker中把下層的image稱作父image,沒有父image的image稱作base image (圖6)

圖6圖6

因此想要從一個image啟動一個container,docker會先加載其父image直到base image,用戶的進程運行在writeable的layer中。所有parent image中的數據信息以及 

圖7圖7


  ID、網絡和lxc管理的資源限制等具體container的配置,構成一個docker概念上的container。如下(圖7):

由此可見,采用AUFS作為docker的container的文件系統,能夠提供如下好處:

  1. 節省存儲空間 - 多個container可以共享base image存儲

  2. 快速部署 - 如果要部署多個container,base image可以避免多次拷貝

  3. 內存更省 - 因為多個container共享base image, 以及OS的disk緩存機制,多個container中的進程命中緩存內容的幾率大大增加

  4. 升級更方便 - 相比于 copy-on-write 類型的FS,base-image也是可以掛載為可writeable的,可以通過更新base image而一次性更新其之上的container

  5. 允許在不更改base-image的同時修改其目錄中的文件 - 所有寫操作都發生在最上層的writeable層中,這樣可以大大增加base image能共享的文件內容。

以上5條 1-3 條可以通過 copy-on-write 的FS實現, 4可以利用其他的union mount方式實現, 5只有AUFS實現的很好。這也是為什么Docker一開始就建立在AUFS之上。

由于AUFS并不會進入linux主干 (According to Christoph Hellwig, linux rejects all union-type filesystems but UnionMount.), 
  同時要求kernel版本3.0以上(docker推薦3.8及以上),因此在RedHat工程師的幫助下在docker0.7版本中實現了driver機制, AUFS只是其中的一個driver, 在RHEL中采用的則是Device Mapper的方式實現的container文件系統。

 

GRSEC

grsec是linux kernel安全相關的patch, 用于保護host防止非法入侵。由于其并不是docker的一部分,我們只進行簡單的介紹。

grsec可以主要從4個方面保護進程不被非法入侵:

  • 隨機地址空間 - 進程的堆區地址是隨機的

  • 用只讀的memory management unit來管理進程流程, 堆區和棧區內存只包含數據結構/函數/返回地址和數據, 是non-executeable

  • 審計和Log可疑活動

  • 編譯期的防護

安全永遠是相對的,這些方法只是告訴我們可以從這些角度考慮container類型的安全問題可以關注的方面。

 

方法

隨著Docker在云計算市場中領先地位的日益穩固,容器技術也成為了一種主流技術。為了對用戶的應用程序使用容器技術,可遵循以下五個步驟。

Docker容器技術已在云計算市場中風靡一時了,而眾多主流供應商則面臨著技術落后的窘境。那么,是什么讓Docker容器技術變得如此受歡迎呢?對于剛入門的新手來說,容器技術可實現不同云計算之間應用程序的可移植性,以及提供了一個把應用程序拆分為分布式組件的方法。此外,用戶還可以管理和擴展這些容器成為集群。

在企業用戶準備把應用程序遷往容器之前,理解應用程序的遷移過程是非常重要的。這里將介紹把用戶應用程序遷往Docker容器的五個基本步驟。

 

步驟1:

分解。一般來說,應用程序都是復雜的,它們都有很多的組件。例如,大多數應用程序都需要數據庫或中間件服務的支持以實現對數據的存儲、檢索和集成。所以,需要通過設計和部署把這些服務拆分成為它們自己的容器。如果一個應用程序能夠被拆分成為越多的分布式組件,那么應用程序擴展的選擇則越多。但是,分布式組件越多也意味著管理的復雜性越高。

 

步驟2:

選擇基礎映像。當執行應用程序遷移時,應盡量避免推倒重來的做法。搜索Docker注冊庫找到一個基本的Docker映像并將其作為應用程序的基礎來使用。

隨著時間的推移,企業將會發現這些Docker注冊庫中基本映像的價值所在。請記住,Docker支持著一個Docker開發人員社區,所以項目的成功與否很大程度上取決于用戶對于映像管理和改良的參與度。

 

步驟3:

安全管理問題。安全性和管理應當是一個高優先級的考慮因素;企業用戶不應再把它們當作應用程序遷移至容器的最后一步。反之,企業必須從一開始就做好安全性和管理的規劃,把它們的功能納入應用程序的開發過程中,并在應用程序運行過程中積極主動地關注這些方面。這就是企業應當花大功夫的地方。

基于容器的應用程序是分布式應用程序。企業應當更新較老的應用程序以支持聯合身份管理方法,這將非常有利于確保分布式應用程序的安全性。為了做到這一點,應為每一個應用程序組件和數據提供一個的標識符,這個標識符可允許企業在一個細粒度的級別上進行安全性管理。企業用戶還應當增加一個日志記錄的方法。

 

步驟4:

增加代碼。為了創建鏡像,企業用戶需要使用一個Dockerfile來定義映像開發的必要步驟。一旦創建了映像,企業用戶就應將其添加至Docker Hub。

 

步驟5:

配置測試部署。應對在容器中運行的應用程序進行配置,以便于讓應用程序知道可以在哪里連接外部資源或者應用程序集群中的其他容器。企業用戶可以把這些配置部署在容器中或使用環境變量。

對基于容器的應用程序進行測試類似于對其他分布式應用程序的測試。企業可以對每個容器進行組件測試,并將容器集群作為一個整體進行測試。 確定應用程序應如何能夠在負載增加的情況下進行擴展。如果用戶正在使用一個集群管理器(例如Swarm),則可測試其性能。

最后,把容器部署到實際生產環境中。為了積極主動地關注基于容器的應用程序的運行狀況,可考慮實施必要的監控和管理機制 。確保打開日志記錄功能。

很多應用程序遷移至云計算都是采用容器技術的。雖然遷移有一點復雜,但是容器可以保護應用程序投資并賦予了它一個更長的使用壽命。

 

安全

 

確保環境安全


  Docker十分火熱,很多人表示很少見如此能夠吸引行業興趣的新興技術。然而,當興奮轉化為實際部署時,企業需要注意Docker的安全性。
  了解Docker的人都知道,Docker利用容器將資源進行有效隔離。因此容器相當于與Linux OS和hypervisor有著幾乎相同的安全運行管理和配置管理級別。但當涉及到安全運營與管理,以及具有保密性、完整性和可用性的通用控件的支持時,Docker可能會讓你失望。
  當容器運行在本地系統上時,企業可以通過其安全規則確保安全性。但一旦容器運行在云端,事實就不會如此簡單了。
  當Docker運行在云提供商平臺上時,安全性變得更加復雜。你需要知道云提供商正在做什么,或許你正在與別人共享一臺機器。
  雖然容器沒有內置的安全因素,而且像Docker這樣的新興技術很難有比較全面的安全措施,但這并不意味著以后也不會出現。

 

部署安全性


  也有專家將Docker安全問題的實質定位于配置安全,認為Docker的問題是很難配置一個安全的容器。雖然Docker的開發人員通過創建非常小的容器來降低攻擊面,但問題在于大型企業內部在生產環境中運行Docker容器的員工需要有更多的可見性和可控性。
  專家認為,大約90%的外部網絡攻擊并不是超級復雜的,攻擊者多是利用了管理員的行為漏洞,比如配置錯誤或者未及時安裝補丁。
  因此,企業在部署數千或數萬臺容器時,能夠確保這些容器都遵守企業安全策略進行配置是至關重要的事情。
  為解決這個問題,就需要增加Docker容器部署的實時可見性,同時實施企業制定的安全策略。 

 

Docker安全中心

在新的功能中有硬件的部分,可以 跨任何基礎架構,允許開發和隨后的升級中的數字編碼簽名。構建在Docker Trust框架之上用來進行鏡像發布者認證,同時進行新的鏡像掃描和官方漏洞檢測,以便能夠更好地理解容器內部是什么。

命名空間是本周發布的另外一個Docker安全升級。允許IT運用來為基于用戶群組的容器指派授權,約束了主機的訪問根源,并指定了系統管理員,限制了群組對于指定服務的訪問。

鏡像掃描對于Docker Hub上的所有官方版本都可用,同時命名空間和硬件簽名則在Docker的實驗渠道提供。

安全問題仍舊是容器采納要解決的最大問題,尤其是如果大量容器是便攜的,IDC研究經理Larry Carvalho說道。通過硬件解決這個問題很明智,因為這樣更難以介入,并且提供了未來可能被使用的大量容器的效率。

Carvhalho說:“他們還應該解決的一個問題是容量,你沒有辦法在軟件層面做大量的安全,因為要有很多開支。” 

 

對比 LXC

看似docker主要的OS級虛擬化操作是借助LXC, AUFS只是錦上添花。那么肯定會有人好奇docker到底比LXC多了些什么。無意中發現 stackoverflow 上正好有人問這個問題,

回答者是Dotcloud的創始人,出于備忘目的原文摘錄如下  。

On top of this low-level foundation of kernel features, Docker offers a high-level tool with several powerful functionalities:

  • Portable deployment across machines. Docker defines a format for bundling an application and all its dependencies into a single object which can be transferred to any docker-enabled machine, and executed there with the guarantee that the execution environment exposed to the application will be the same. Lxc implements process sandboxing, which is an important pre-requisite for portable deployment, but that alone is not enough for portable deployment. If you sent me a copy of your application installed in a custom lxc configuration, it would almost certainly not run on my machine the way it does on yours, because it is tied to your machine's specific configuration: networking, storage, logging, distro, etc. Docker defines an abstraction for these machine-specific settings, so that the exact same docker container can run - unchanged - on many different machines, with many different configurations.

  • Application-centric. Docker is optimized for the deployment of applications, as opposed to machines. This is reflected in its API, user interface, design philosophy and documentation. By contrast, the lxc helper scripts focus on containers as lightweight machines - basically servers that boot faster and need less ram. We think there's more to containers than just that.

  • Automatic build. Docker includes a tool for developers to automatically assemble a container from their source code, with full control over application dependencies, build tools, packaging etc. They are free to use make, maven, chef, puppet, salt, debian packages, rpms, source tarballs, or any combination of the above, regardless of the configuration of the machines.

  • Versioning. Docker includes git-like capabilities for tracking successive versions of a container, inspecting the diff between versions, committing new versions, rolling back etc. The history also includes how a container was assembled and by whom, so you get full traceability from the production server all the way back to the upstream developer. Docker also implements incremental uploads and downloads, similar to “git pull”, so new versions of a container can be transferred by only sending diffs.

  • Component re-use. Any container can be used as an “base image” to create more specialized components. This can be done manually or as part of an automated build. For example you can prepare the ideal python environment, and use it as a base for 10 different applications. Your ideal postgresql setup can be re-used for all your future projects. And so on.

  • Sharing. Docker has access to a public registry (http://index.docker.io) where thousands of people have uploaded useful containers: anything from redis, couchdb, postgres to irc bouncers to rails app servers to hadoop to base images for various distros. The registry also includes an official “standard library” of useful containers maintained by the docker team. The registry itself is open-source, so anyone can deploy their own registry to store and transfer private containers, for internal server deployments for example.

  • Tool ecosystem. Docker defines an API for automating and customizing the creation and deployment of containers. There are a huge number of tools integrating with docker to extend its capabilities. PaaS-like deployment (Dokku, Deis, Flynn), multi-node orchestration (maestro, salt, mesos, openstack nova), management dashboards (docker-ui, openstack horizon, shipyard), configuration management (chef, puppet), continuous integration (jenkins, strider, travis), etc. Docker is rapidly establishing itself as the standard for container-based tooling.

 

應用

有了docker這么個強有力的工具,更多的玩家希望了解圍繞docker能做什么

 

Sandbox

作為sandbox大概是container的最基本想法了 - 輕量級的隔離機制, 快速重建和銷毀, 占用資源少。用docker在開發者的單機環境下模擬分布式軟件部署和調試,可謂又快又好。

同時docker提供的版本控制和image機制以及遠程image管理,可以構建類似git的分布式開發環境??梢钥吹接糜跇嫿ǘ嗥脚_image的packer以及同一作者的vagrant已經在這方面有所嘗試了,筆者會后續的blog中介紹這兩款來自同一geek的精致小巧的工具。

Docker已經不僅僅是DevOps人員手中的神器了,每一個開發者都應該學會如何使用Docker。 

 

PaaS

dotcloud、heroku以及cloudfoundry都試圖通過container來隔離提供給用戶的runtime和service,只不過dotcloud采用docker,heroku采用LXC,cloudfoundry采用自己開發的基于cgroup的warden?;谳p量級的隔離機制提供給用戶PaaS服務是比較常見的做法 - PaaS 提供給用戶的并不是OS而是runtime+service,因此OS級別的隔離機制向用戶屏蔽的細節已經足夠。而docker的很多分析文章提到『能夠運行任何應用的“PaaS”云』只是從image的角度說明docker可以從通過構建 image實現用戶app的打包以及標準服務service image的復用,而非常見的buildpack的方式。

由于對Cloud Foundry和docker的了解,接下來談談筆者對PaaS的認識。PaaS號稱的platform一直以來都被當做一組多語言的runtime和一組常用的middleware,提供這兩樣東西 
  即可被認為是一個滿足需求的PaaS。然而PaaS對能部署在其上的應用要求很高:

  • 運行環境要簡單 - buildpack雖然用于解決類似問題,但仍然不是很理想

  • 要盡可能的使用service - 常用的mysql, apache倒能理解,但是類似log之類的如果也要用service就讓用戶接入PaaS平臺,讓用戶難以維護

  • 要盡可能的使用"平臺” - 單機環境構建出目標PaaS上運行的實際環境比較困難,開發測試工作都離不開"平臺”

  • 缺少可定制性 - 可選的中間件有限,難于調優和debug。

綜上所述部署在PaaS上的應用幾乎不具有從老平臺遷移到之上的可能,新應用也難以進入參數調優這種深入的工作。個人理解還是適合快速原型的展現,和短期應用的嘗試。

然而docker確實從另一個角度(類似IaaS+orchestration tools)實現了用戶運行環境的控制和管理,然而又基于輕量級的LXC機制,確實是一個了不起的嘗試。 
  筆者也認為IaaS + 靈活的orchestration tools(深入到app層面的管理 如bosh)是交付用戶環境最好的方式。

國內也已經開始出現基于Docker的PaaS。2015年3月11日,云雀Alauda云平臺正式開啟內測,對外提供基于Docker的PaaS服務。

 

Open Solution

前文也提到docker存在disk/network不便限額和在較低版本kernel中(如RHEL的2.6.32)AUFS不支持的問題。

disk/network quota

雖然cgroup提供IOPS之類的限制機制,但是從限制用戶能使用的磁盤大小和網絡帶寬上還是非常有限的。

Disk/network的quota有兩種思路:

  • 通過docker run -v命令將外部存儲mount到container的目錄下,quota從Host方向限制,在device mapper driver中更采用實際的device因此更好控制。 

  • 通過使用disk quota來限制AUFS的可操作文件大小。類似cloud foundry warden的方法, 維護一個UID池,每次創建container都從中取一個user name, 在container里和Host上用這個username創建用戶,在Host上用setquota限制該username的UID的disk. 網絡上由于docker采用veth的方式,可以采用tc來控制host上的veth的設備。 

RHEL 6.5

這里簡單介紹下device mapper driver的思路:

docker的dirver要利用snapshot機制,起初的fs是一個空的ext4的目錄,然后寫入每個layer。每次創建image其實就是對其父image/base image進行snapshot,

然后在此snapshot上的操作都會被記錄在fs的metadata中和AUFS layer,docker commit將 diff信息在parent image上執行一遍.

這樣創建出來的image就可以同當前container的運行環境分離開獨立保存了。 

 

Docker Datacenter

Docker Datacenter將五個之前獨立的產品組合在一起,使用統一的Docker管理接口:管理用的Universal Control Plane;安全方面的Content Trust;編排用的Swarm;容器運行時的Engine;以及Trusted Registry。目標是填補兩處空白,一處是使用Docker在開發、測試、質量保證和生產環境間打包應用,另一處是容器管理還不直接的傳統IT運維。 

 

部署

1.Docker鏡像 
  

  Docker 1.3 支持數字簽名來確認官方倉庫鏡像的起源和完整性。因該功能仍在開發中所以Docker將拋出警告但不會阻止鏡像的實際運行。 
  通常確保鏡像只從受信庫中檢索并且不使用—insecure-registry=[]命令項。 
  2.網絡命名空間
  

  在默認情況下,Docker REST API用來控制容器通過系統Docker守護進程是能夠通過Unix域套接字的方式暴露出來。在Docker上開啟一個TCP端口(即 當引導Docker守護進程時必須使用 -H 選項綁定地址)將允許任何人通過該端口訪問容器,有可能獲得主機上的root訪問權限以及在某些場景下本地用戶所屬的Docker組。 
  3.日志和審核 
  

  收集和歸檔與Docker相關的安全日志來達到審核和監督的目的。從host[8],可以使用下面的命令來訪問容器外的日志文件: 
  docker run -v /dev/log:/dev/log/bin/sh 
  使用Docker命令內置: 
  docker logs ... (-f to follow log output) 
  日志文件也可以從持續存儲導出到一個使用壓縮包里面: 
  docker export ...


  4.SELinux 或 AppArmor 
  

  Linux的內部安全模塊,例如通過訪問控制的安全策略來配置安全增強型Linux(SELinux)和AppArmor,從而實現強制性的訪問控制(MAC)一套有限的系統資源的限制進程,如果先前已經安裝和配置過SELinux,那么它可以使用setenforce 1在容器中被激活。Docker程序的SELinux支持是默認無效的,并且需要使用—selinux功能來被激活。通過使用新增的—security-opt來加載SELinux或者AppArmor的策略對容器的標簽限制進行配置。該功能已經在Docker版本1.3[9]中介紹過。例如: 
  docker run --security-opt=secdriver:name:value -i -t centos bash 
  5.守護特權 
  

  不要使用--privileged命令行選項。這本來允許容器來訪問主機上的所有設備,并為容器提供一個特定的LSM配置(例如SELinux或AppArmor),而這將給予如主機上運行的程序同樣水平的訪問。避免使用--privileged有助于減少主機泄露的攻擊面和潛力。然而,這并不意味著程序將沒有優先權的運行,當然這些優先權在最新的版本中還是必須的。發布新程序和容器的能力只能被賦予到值得信任的用戶上。通過利用-u選項盡量減少容器內強制執行的權限。例如: 
  docker run -u-it/bin/bash 
  Docker組的任何用戶部分可能最終從容器中的主機上獲得根源。 
  6.cgroups 
  

  為了防止通過系統資源耗盡的DDoS攻擊,可以使用特定的命令行參數被來進行一些資源限制。 
  CPU使用率: 
  docker run -it --rm --cpuset=0,1 -c 2 ... 
  內存使用: 
  docker run -it --rm -m 128m ... 
  存儲使用: 
  docker -d --storage-opt dm.basesize=5G 
  磁盤I/O: 
  不支持Docker。BlockIO*屬性可以通過systemd暴露,并且在支持操作系統中被用來控制磁盤的使用配額。 
  7.二進制SUID/GUID 
  

  SUID和GUID二進制文件不穩定的時候容易受到攻擊,而這個時候是很危險的,,導致任意代碼執行(如緩沖區溢出),因為它們會進程的文件所有者或組的上下文中運行。如果可能的話,禁止SUID和SGID使用特定的命令行參數來降低容器的功能。 
  docker run -it --rm --cap-drop SETUID --cap-drop SETGID ... 
  另一選擇,可以考慮運用通過安裝有nosuid屬性的文件系統來移除掉SUID能力。 
  最后一個選擇是從系統中徹底刪除不需要的SUID和GUID二進制文件。這些類型的二進制文件可以在Linux系統中運行以下命令而找到: 
  find / -perm -4000 -exec ls -l {} \; 2>/dev/null 
  find / -perm -2000 -exec ls -l {} \; 2>/dev/null 
  可以使用類似于下面的[11]命令將SUID和GUID文件權限刪除然后: 
  sudo chmod u-s filename sudo chmod -R g-s directory 
  8.設備控制組(/dev/*) 
  

  如果需要,使用內置的設備選項(不使用-v與--privileged參數)。此功能在推出1.2版本[12]。 
  例如(聲卡使用): 
  docker run --device=/dev/snd:/dev/snd … 
  9.服務和應用 
  

  如果一個Docker容器有可能被泄露,為了減少橫向運動的潛力,考慮隔離極易受影響的服務(如在主機或虛擬機上運行ssh服務)。此外,不要運行容器內不受信任的操作的應用程序。 
  10.安裝項 
  

  當使用本機容器庫時(即libcontainer)Docker就會自動處理這個。 
  但是,使用LXC容器庫時,敏感的安裝點最好通過運用只讀權限來手動安裝,其中包括: 
  /sys 
  /proc/sys 
  /proc/sysrq-trigger 
  /proc/irq 
  /proc/bus 
  安裝權限應在以后刪除,以防止重新掛載。 
  11.Linux內核 
  

  使用系統提供的更新工具來確保內核是實最新的(如apt-get,yum,等)。過時的內核可能更脆弱,并且被暴露一些漏洞。使用GRSEC或PAX來加強內核,即例如對內存破壞的漏洞來提供更高的安全性。 
  12.用戶命名空間 
  

  Docker不支持用戶的命名空間,但是的一個開發[13]功能。UID映射由LXC程序驅動,但在本機libcontainer庫中不被支持。該功能將允許Docker程序像一個沒有特權的用戶在主機上運行,但顯示出來的是和在容器中運行的一樣。 
  13.libseccomp(和seccomp-bpf 擴展) 
  

  libseccomp庫允許在基于一個白名單的方法上限制Linux內核的系統調用程序的使用。對于系統操作來說,不是很重要的系統調用程序,最好被禁用,以防止被破壞的容器被濫用或誤用。 
  此功能工作正在進行中(LXC驅動程序中已經有了,但是在libcontainer中還沒有完成,雖然是默認值)。使用LXC驅動程序[14]來重啟Docker程序: 
  docker -d -e lxc 
  如何生成seccomp配置的說明都在“的contrib”[15]文件夾中的Docker GitHub的資源庫。以后可以用下面的命令來創建一個基于Docker容器的LXC: 
  docker run --lxc-conf="lxc.seccomp=$file"
  14.性能 
  

  只要可能,就將Linux性能降低到最小。Docker默認的功能包括:chown, dac_override, fowner, kill, setgid, setuid, setpcap, net_bind_service, net_raw, sys_chroot, mknod, setfcap, and audit_write. 
  從控制行來啟動容器時,可以通過下述來進行控制: 
  --cap-add=[] 或者--cap-drop=[]. 
  例如: 
  docker run --cap-drop setuid --cap-drop setgid -ti/bin/sh 
  15.多租環境 
  

  由于Docker容器內核的共享性質,責任分離在多租戶環境中不能安全地實現。建議容器在那些沒有其它的目的,也不用于敏感操作的主機上運行??梢钥紤]通過Docker控制來將所有服務移動到容器中。如果可能的話,通過使用--icc= false將跨容器通信降到最低,并必要時指定-link與Docker運行,或通過—export=port,不在主機上發布,而在容器上暴露一個端口。相互信任的容器的映像組來分離機器[17]。 
  16.完全虛擬化 
  

  使用一個完整的虛擬化解決方案包含Docker,如KVM。這將阻止一個內核漏洞在Docker鏡像中被利用導致容器擴為主系統。 
  Docker鏡像能夠嵌套來提供該KVM虛擬層,參考Docker-in-Docker utility [18]中所示。 
  17.安全審核 
  

  對你的主系統和容器定期進行安全審核以查明錯誤配置或漏洞,這些能使你的系統損壞。

 

工具實踐

 

Docker推出的一個名為Docker Content Trust(DCT)的新功能,它可幫助IT專業人士確保Docker的安全性。DCT使用了一個公共密鑰基礎設施(PKI)的方法,它提供了兩個不同的密鑰:一個離線(root)密鑰和一個標記(每次入庫)密鑰,當第一次發布者推出鏡像時它可創建和存儲客戶端。

此舉有助于彌補正在使用惡意容器這一最大的漏洞。DCT還生成了一個時間戳密鑰,它可保護系統免受重放攻擊,即運行過期的標記內容。這解決了上面提及容器具有不同安全補丁等級的問題。

為了解決針對容器安全性的問題,包括Docker在內的眾多公司都為Docker發布了安全基準。這套標準為確保Docker容器的安全性提供了指導。全篇118頁的文檔囊括了部署Docker容器的84個最佳實踐以及一個涉及所有內容的檢查清單。

那么,如果你決定自行負責確保Docker容器的安全性,但又不知道從何入手,我們在這里為你提供了一些建議:

閱讀上面提及的Docker安全基準文件。重點關注與如何部署基于容器的應用程序相關的建議和最佳實踐。這真的是有助于緩解你的財務壓力,認真考慮大部分因糟糕設計而導致的Docker安全性問題。

考慮你的特定安全性需求。這將促使你選擇正確的工具和方法。很多使用容器技術的企業對于他們基于容器的應用程序要么安全措施不足,要么安全措施過足。

盡可能多地進行測試。容器技術是新技術,因此我們需要搞清楚哪些是能夠發揮作用,哪些是無用的,而要做到這一點的方法就是進行安全性方面的測試,例如滲透測試。

容器安全性的發展趨勢可能會與虛擬化安全性一樣。雖然安全性從第一臺虛擬機部署開始就是一個問題,但是多年以來積累下來的良好安全性實踐、架構和工具都證明了其有效性。我們相信,Docker容器安全性的問題也同樣能夠得到較好解決。 

 

使用案例

 

Docker是一個命令行工具,它提供了中央“docker”執行過程中所需的所有工具。這使得Docker的操作非常簡單。一些例子可以檢查運行中的容器的狀態:

或檢查可用的鏡像及其版本的列表:

另一個例子是顯示一個鏡像的歷史:

上面的命令顯示了命令行界面操作的方便快捷。你只需要指定鏡像ID的前幾個字符就可以。你可以看到只需要“d95”就能顯示d95238078ab0鏡像的所有歷史。

你可能會注意到該鏡像非常小。這是因為Docker從父鏡像建立增量鏡像,只存儲每個容器的更改。因此,如果你有一個300MB的父鏡像,如果你在容器中安裝了50MB的額外應用或服務,你的容器和生成鏡像可能只有50MB。

你可以用Dockerfiles自動化Docker容器的創建過程。Dockerfiles是含有單個容器性能規范的文件。例如,你可以創建一個Dockerfiles來建立一個Ubuntu容器,在新容器內運行一些命令、安裝軟件或執行其他任務,然后啟動容器。

容器網絡

Docker早期版本中的網絡基于主機橋接,但是Docker 1.0包含了一種新形式的網絡,允許容器直接連接到主機以太網接口。默認情況下,一個容器有一個回路以及一個連接到默認內部橋接的接口,但是如果需要的話也可以配制成直接訪問。通常,直接訪問比橋接的速度更快。

然而,橋接方法在許多情況下是非常有用的。橋接是通過主機自動創建一個內部網絡適配器并為其分配一個主機本身尚未使用的子網。然后,當新的容器連接到這座橋,它們的地址進行自動分配。容器啟動時你可以將其連接到主機接口或端口,因此運行Apache的容器可能啟動并連接到主機上的TCP端口8080(或隨機端口)。通過使用腳本和管理控制,你可以在任何地方啟動Docker,連接端口并將其傳達到需要使用該服務的應用或服務堆棧的其他部分。 

在Hyper-V服務器上Docker主機備份方法

要在Hyper-V服務器上創建Docker主機,您需要下載并且安裝OpenSSH以及Windows版本的Docker Machine。您還應該將OpenSSH二進制文件添加到您的Hyper-V服務器路徑以便Docker Machine可以找到它們。

一旦所需的組件就緒,創建Docker主機如同運行一條命令行一樣輕而易舉。打開命令提示符窗口,定位到包含Docker Machine的文件夾,然后輸入可執行文件名稱(Docker-machine_windows-amd64.exe),其后輸入-d開關、驅動程序的名稱(在本例中是Hyper-V)以及您想分配給您正在創建的虛擬機(VM)的名稱。例如,該命令可能如下所示:

Docker-machine_windows-amd64.exe -d hyper-v Docker

當運行這個命令的時候,Docker Machine完成幾個不同的任務。其中一些更重要的任務(從備份的角度來看)包括:
  使用命令行中指定的名稱創建虛擬硬盤(virtual hard disk,VHD);
  下載名為Boot2Docker.ISO的DVD映像;
  創建虛擬機;
  把Boot2Docker.ISO 文件與新創建的VM關聯,作為虛擬DVD光驅;
  把VHD與VM關聯;
  啟動VM;
  向VM分配IP地址和端口號。 

 

技術發展

 

Docker解決的問題

云計算、大數據,移動技術的快速發展,加之企業業務需求的不斷變化,導致企業架構要隨時更改以適合業務需求,跟上技術更新的步伐。毫無疑問,這些重擔都將壓在企業開發人員身上;團隊之間如何高效協調,快速交付產品,快速部署應用,以及滿足企業業務需求,是開發人員亟需解決的問題。Docker技術恰好可以幫助開發人員解決這些問題。

為了解決開發人員和運維人員之間的協作關系,加快應用交付速度,越來越多的企業引入了DevOps這一概念。但是,傳統的開發過程中,開發、測試、運維是三個獨立運作的團隊,團隊之間溝通不暢,開發運維之間沖突時有發生,導致協作效率低下,產品交付延遲, 影響了企業的業務運行。Docker技術將應用以集裝箱的方式打包交付,使應用在不同的團隊中共享,通過鏡像的方式應用可以部署于任何環境中。這樣避免了各團隊之間的協作問題的出現,成為企業實現DevOps目標的重要工具。以容器方式交付的Docker技術支持不斷地開發迭代,大大提升了產品開發和交付速度。

此外,與通過Hypervisor把底層設備虛擬化的虛擬機不同,Docker直接移植于Linux內核之上,通過運行Linux進程將底層設備虛擬隔離,這樣系統性能的損耗也要比虛擬機低的多,幾乎可以忽略。同時,Docker應用容器的啟停非常高效,可以支持大規模的分布系統的水平擴展,真正給企業開發帶來福音。

正如中國惠普云計算集成云技術首席專家劉艷凱所說的那樣:“任何一項技術的發展和它受到的追捧,都是因為它能夠解決困擾人們的問題,”Docker正是這樣的一種技術。Docker的解決問題能力雖然很強,但在企業中的實際應用卻并不多,那么是什么問題阻礙了Docker在企業中的實踐?

 

Docker未來發展

任何一項新技術的出現,都需要一個發展過程,比如云計算為企業所接受用了將近五年左右時間,OpenStack技術也經歷了兩、三年才受到人們的認可。因此,雖然Docker技術發展很快,但技術還不夠成熟,對存儲的靈活的支持、網絡的開銷和兼容性方面還存在限制,這是Docker沒有被企業大范圍使用的一個主要原因。另外一個原因是企業文化是否與DevOps運動一致,只有企業支持DevOps,才能更大地發揮Docker的價值。最后一個原因就是安全性問題,Docker對于Linux這一層的安全的隔離還有待改進,才能進一步得到企業的認可?;萜談⑵G凱認為,這也是Docker需要在下一步中改進的一方面。

Docker價值的最大體于對企業DevOps的支持,對原生云應用大規模水平擴展的支持。在惠普Helion云戰略中包括了對DevOps服務和原生云應用的支持,而這一戰略的具體落地,與Docker技術有著緊密的聯系。因此,惠普團隊一直積極地參與OpenStack社區中和Docker項目相關的開發活動中,努力改進Docker技術中存在的不足。同時,惠普產品中也集成了Docker,例如,惠普開發平臺產品集成了Docker,使用Docker作為應用的容器;以及惠普最新發布的CloudSystem 9.0也增加對Docker的支持,用戶可以像使用其它的虛擬化資源一樣,選擇Docker作為應用的承載容器。劉艷凱認為,惠普非常認可Docker給用戶帶來的一些價值,那也希望通過自己努力,使更多的用戶使用到Docker這樣的先進的技術。 

 

Docker Hub 服務

雙方在開源容器技術以及發展方向上共同努力,并提供本地化的 Docker 服務。Docker 公司選擇阿里云平臺作為其DockerHub 在中國運營的基礎服務。阿里云也獲得 DockerEngine 商用版以及 DockerDataCenter 運營權,并為 Docker 客戶提供企業級支持和咨詢服務。同時,阿里云將成為 Docker 官方支持的云服務提供商。

阿里云總裁胡曉明表示,通過和 Docker 的戰略合作,阿里云將更好地為企業級客戶提供完善的云服務,使能客戶,并實現時代轉型。 

 

技術局限

網絡限制:容器網絡(Docker Network )讓你可以方便地在同一主機下對容器進行網絡連接。加上一些其他的工作,你就可以跨主機使用疊加網絡功能。然而,也就到此為止了。網絡配置操作是受限的,而且到為止可以說這些手段都是人工的。盡管容器腳本化可以規?;?,因為你必須給網絡定義增加預分配實例,每次提供容器時還需要額外步驟,這容易引起錯誤。

庫控制受限:庫已經成為任何容器會話的中心議題。公共庫是最有價值的,因為他貢獻了大量的預置容器,節省了許多的配置時間。然而,在沙盒里使用它是有風險的。在不知道誰以及如何創建鏡像的情況下,可能會存在任意數量的有意或無意的穩定性和安全性風險。對于企業來說,有必要建立和維護一個私有庫,這個庫的建立挑戰不大,但管理是個問題。Docker為大型庫的鏡像管理提供了一個有限的元數據模型,確保未來實例如預期的能力受限,也沒有疊加功能。

沒有清晰的審計跟蹤:提供容器是很簡單的,但知道提供容器的時間、原因、方式以及提供方卻不容易。因此,在提供之后,你并不掌握多少出于審計目的的歷史。

運行實例的低可見性:如果沒有經過深思熟慮的行動,實例提供后很難接觸到運行容器的對象,也很難知道哪些應該出那里,哪些不應該出那里。 

 

Docker環境安全

Docker的勢頭在過去的12個月里十分火熱,很多人表示很少見如此能夠吸引行業興趣的新興技術。然而,當興奮轉化為實際部署時,企業需要注意Docker的安全性。

了解Docker的人都知道,Docker利用容器將資源進行有效隔離。因此容器相當于與Linux OS和hypervisor有著幾乎相同的安全運行管理和配置管理級別。但當Docker涉及到安全運營與管理,以及具有保密性、完整性和可用性的通用控件的支持時,Docker可能會讓你失望。

當Docker運行在云提供商平臺上時,Docker安全性變得更加復雜。你需要知道云提供商正在做什么,或許你正在于別人共享一臺機器。

Docker雖然容器沒有內置的安全因素,而且像Docker這樣的新興技術很難有比較全面的安全措施,但這并不意味著以后也不會出現。

 

容器部署安全

也有專家將Docker安全問題的實質定位于配置安全,認為Docker的問題是很難配置一個安全的容器。雖然Docker的開發人員通過創建非常小的容器來降低攻擊面,但問題在于大型企業內部在生產環境中運行Docker容器的員工需要有更多的可見性和可控性。

企業在部署數千或數萬臺Docker容器時,能夠確保這些Docker容器都遵守企業安全策略進行配置是至關重要的事情。

Docker為解決這個問題,就需要增加Docker容器部署的實時可見性,同時實施企業制定的安全策略。也有一些廠商為此推出解決方案,給運營商提供了實時可見性并幫助他們執行容器級別的虛擬基礎設施的安全策略。

? 快三上海 dpn| t0j| n0b| brz| 8px| zp8| fvh| z8t| ndj| 8zb| zp9| rpv| r9r| lzf| 9zp| 9vn| xz7| vvh| f7p| fnj| 8db| ntb| 8vt| xf8| bvh| j8r| vdj| 8nr| 6vb| bb7| llf| d7p| hzx| 7vj| zh7| plh| z7z| fnh| 7nb| zz6| dv6| lbv| r6h| pfl| 6jp| nf6| bpr| n6z| jdr| 77v| nlf| 7pd| tj5| zp5| nft| f5j| jjf| 5hd| xx6| bjp| f6v| xxd| 6th| xn4| vxd| x4j| rrx| jxh| 5tj| tj5| tlh| b5z| rrf| 5dp| nd5| xnt| p3f| fft| d4t| fxd| hjp| 4fv| nv4| vvl| l4z| flr| 4jf| fx3| tlx| f3z|