Docker:應用容器引擎-中文百科頻道

簡介

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

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

DockerClient客戶端

Docker Daemon守護進程

Docker Image鏡像

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最獨特的地方。

面對上述幾個問題，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

Automated testing and continuous integration/deployment

Deploying and scaling web apps, databases and backend services

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

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

PaaS環境是不言而喻的，其設計之初和dotcloud的案例都是将其作為PaaS産品的環境基礎

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

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

原理

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解決的.

LinuxNamespace(ns)

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

pid namespace

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

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

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

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

因為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。

ControlGroups(cgroups)

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容器(LXC)

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

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特性的運用。

典型的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）：

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

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

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

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

image不保存用戶狀态，可以用于模闆、重建和複制。

（圖4、5）

上層的image依賴下層的image，因此docker中把下層的image稱作父image，沒有父image的image稱作base image （圖6）

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

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

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

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

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

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

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

允許在不更改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來定義映像開發的必要步驟。一旦創建了映像，企業用戶就應将其添加至Docer Hub。

步驟5：配置、測試、部署

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

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

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

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

對比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的精緻小巧的工具。

PaaS

dotcloud、heroku以及cloudfoundry都試圖通過container來隔離提供給用戶的runtime和service，隻不過dotcloud采用docker, heroku采用LXC, cloudfoundry采用自己開發的基于cgroup的warden。基于輕量級的隔離機制提供給用戶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服務。

OpenSolution

前文也提到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的運行環境分離開獨立保存了。

部署方式

1.Docker鏡像

Docker 1.3 現在支持數字簽名來确認官方倉庫鏡像的起源和完整性。因該功能仍在開發中所以Docker将抛出警告但不會阻止鏡像的實際運行。

通常确保鏡像隻從受信庫中檢索并且不使用—insecure-registry=[]命令項。

2.網絡命名空間

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

3.日志和審核

收集和歸檔與Docker相關的安全日志來達到審核和監督的目的。從host，可以使用下面的命令來訪問容器外的日志文件：

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中介紹過。例如：

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

可以使用類似于下面的命令将SUID和GUID文件權限删除然後：

sudo chmod u-s filename sudo chmod -R g-s directory

8.設備控制組(/dev/*)

如果需要，使用内置的設備選項(不使用-v與--privileged參數)。此功能在推出1.2版本。

例如(聲卡使用)：

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不支持用戶的命名空間，但是一個開發功能。UID映射由LXC程序驅動，但在本機libcontainer庫中不被支持。該功能将允許Docker程序像一個沒有特權的用戶在主機上運行，但顯示出來的是和在容器中運行的一樣。

13.libseccomp(和seccomp-bpf 擴展)

libseccomp庫允許在基于一個白名單的方法上限制Linux内核的系統調用程序的使用。對于系統操作來說，不是很重要的系統調用程序，最好被禁用，以防止被破壞的容器被濫用或誤用。

此功能工作正在進行中(LXC驅動程序中已經有了，但是在libcontainer中海沒有完成，雖然現在是默認值)。使用LXC驅動程序來重啟Docker程序：

docker -d -e lxc

如何生成seccomp配置的說明都在“的contrib”文件夾中的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，不在主機上發布，而在容器上暴露一個端口。相互信任的容器的映像組來分離機器。

16.完全虛拟化

使用一個完整的虛拟化解決方案包含Docker,如KVM。這将阻止一個内核漏洞在Docker鏡像中被利用導緻容器擴為主系統。

Docker鏡像能夠嵌套來提供該KVM虛拟層，參考Docker-in-Docker utility 中所示。

17.安全審核

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

Sandbox

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

PaaS

dotcloud、heroku以及cloudfoundry都試圖通過container來隔離提供給用戶的runtime和service，隻不過dotcloud采用docker，heroku采用LXC，cloudfoundry采用自己開發的基于cgroup的warden。基于輕量級的隔離機制提供給用戶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。

然而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因此更好控制。

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運維。

工具實踐

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這一層的安全的隔離還有待改進，才能進一步得到企業的認可。惠普劉豔凱認為，這也是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容器部署的實時可見性，同時實施企業制定的安全策略。也有一些廠商為此推出解決方案，給運營商提供了實時可見性并幫助他們執行容器級别的虛拟基礎設施的安全策略。