Docker(應用服務引擎)

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

類    別     操做系統層虛擬化
提供商       Docker,Inc.
發行日期     2013年
許可協議     Apache License 2.0
編程語言     Go


點：
1 起源
2 Docker 架構
3 特性
4 侷限
5 原理
5.1 Linux Namespace (ns)
5.2 Control Groups (cgroups)
5.3 Linux 容器 (LXC)
5.4 AUFS
5.5 GRSEC
6 方法
6.1 步驟1：分解
6.2 步驟2：選擇一個基礎映像
6.3 步驟3：解決安全性和管理問題
6.4 步驟4：增長代碼
6.5 步驟5：配置、測試、部署
7 安全
7.1 確保Docker環境安全
7.2 確保容器部署安全性
7.3 硬件上的Docker安全中心
8 對比 LXC
9 應用
9.1 Sandbox（沙盒）
9.2 PaaS
9.3 Open Solution
9.4 Docker Datacenter
10 部署
11 保護
11.1 確保Docker容器安全性的工具與最佳實踐
12 使用案例
13 Docker技術的發展與應用
13.1 Docker解決的問題
13.2 Docker將來發展
13.3 惠普幫助Docker實現企業價值
13.4 與阿里雲合做，在中國提供 Docker Hub 服務
14 Docker技術的侷限
15 Docker安全性
15.1 Docker環境安全
15.2 Docker確保容器部署安全性


起源
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技術 和 容器技術對比
面對上述幾個問題，
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應用)。
構建標準化的運行環境，現有的方案大可能是在一個baseOS上運行一套puppet/chef，或者一個image文件，
其缺點是前者須要base OS許多前提條件，後者幾乎不能夠修改(由於copy on write 的文件格式在運行時rootfs是read only的)。而且後者文件體積大，環境管理和版本控制自己也是一個問題。
PaaS環境是不言而喻的，其設計之初和dotcloud的案例都是將其做爲PaaS產品的環境基礎
由於其標準化構建方法(buildfile)和良好的REST API，自動化測試和持續集成/部署可以很好的集成進來
由於LXC輕量級的特色，其啓動快，並且docker可以只加載每一個container變化的部分，這樣資源佔用小，
可以在單機環境下與KVM之類的虛擬化方案相比可以更加快速和佔用更少資源

侷限
Docker並非全能的，設計之初也不是KVM之類虛擬化手段的替代品，
簡單總結幾點：
Docker是基於Linux 64bit的，沒法在32bit的linux/Windows/unix環境下使用

LXC是基於cgroup等linux kernel功能的，所以container的guest系統只能是linux base的
隔離性相比KVM之類的虛擬化方案仍是有些欠缺，全部container公用一部分的運行庫
網絡管理相對簡單，主要是基於namespace隔離

cgroup的cpu和cpuset提供的cpu功能相比KVM的等虛擬化方案相比難以度量(因此dotcloud主要是按內存收費)
docker對disk的管理比較有限
container隨着用戶進程的中止而銷燬，container中的log等用戶數據不便收集

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 (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。

Control Groups (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 (從功能角度而非文件系統角度)
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
 
典型的Linux在啓動後，首先將 rootfs 置爲 readonly, 進行一系列檢查, 而後將其切換爲 「readwrite」 供用戶使用。
在docker中，起初也是將 rootfs 以readonly方式加載並檢查，然而接下來利用 union mount 的將一個 readwrite 文件系統掛載在 readonly 的rootfs之上，而且容許再次將下層的 file system設定爲readonly 而且向上疊加, 這樣一組readonly和一個writeable的結構構成一個container的運行目錄, 每個被稱做一個Layer。以下：
得益於AUFS的特性, 每個對readonly層文件/目錄的修改都

只會存在於上層的writeable層中。這樣因爲不存在競爭, 多個container能夠共享readonly的layer。
因此docker將readonly的層稱做 「image」 - 對於container而言整個rootfs都是read-write的，
但事實上全部的修改都寫入最上層的writeable層中,image不保存用戶狀態，能夠用於模板、重建和複製。
 
上層的image依賴下層的image，所以docker中把下層的image稱做父image，沒有父image的image稱做base image
 
所以想要從一個image啓動一個container，docker會先加載其父image直到base image，
用戶的進程運行在writeable的layer中。全部parent image中的數據信息以及 ID、網絡和lxc管理的資源限制等具體container的配置，
構成一個docker概念上的container。

因而可知，採用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的人都知道，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的創始人，出於備忘目的原文摘錄以下。
應用
有了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。
基於輕量級的隔離機制提供給用戶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機制，確實是一個了不得的嘗試。
　　

這裏介紹下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，可使用下面的命令來訪問容器外的日誌文件：
　　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參數）。
　　例如（聲卡使用）：
　　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，不在主機上發佈，而在容器上暴露一個端口。
相互信任的容器的映像組來分離機器[17]。
16.徹底虛擬化
使用一個完整的虛擬化解決方案包含Docker,如KVM。
這將阻止一個內核漏洞在Docker鏡像中被利用致使容器擴爲主系統。
Docker鏡像可以嵌套來提供該KVM虛擬層，參考Docker-in-Docker utility中所示。
17.安全審覈
對你的主系統和容器按期進行安全審覈以查明錯誤配置或漏洞，這些能使你的系統損壞。

保護
確保Docker容器安全性的工具與最佳實踐
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解決的問題
雲計算、大數據，移動技術的快速發展，加之企業業務需求的不斷變化，致使企業架構要隨時更改以適合業務需求，
跟上技術更新的步伐。毫無疑問，這些重擔都將壓在企業開發人員身上；
團隊之間如何高效協調，快速交付產品，快速部署應用，以及知足企業業務需求，是開發人員亟需解決的問題。
Docker技術剛好能夠幫助開發人員解決這些問題。
爲了解決開發人員和運維人員之間的協做關係，加快應用交付速度，愈來愈多的企業引入了DevOps這一律念。
可是，傳統的開發過程當中，開發、測試、運維是三個獨立運做的團隊，團隊之間溝通不順暢，開發運維之間衝突時有發生，
致使協做效率低下，產品交付延遲， 影響了企業的業務運行。
Docker技術將應用以集裝箱的方式打包交付，使應用在不一樣的團隊中共享，經過鏡像的方式應用能夠部署於任何環境中。
這樣避免了各團隊之間的協做問題的出現，成爲企業實現DevOps目標的重要工具。
以容器方式交付的Docker技術支持不斷地開發迭代，大大提高了產品開發和交付速度。
此外，與經過Hypervisor把底層設備虛擬化的虛擬機不一樣，Docker直接移植於Linux內核之上，
經過運行Linux進程將底層設備虛擬隔離，這樣系統性能的損耗也要比虛擬機低的多，幾乎能夠忽略。
同時，Docker應用容器的啓停很是高效，能夠支持大規模的分佈系統的水平擴展，真正給企業開發帶來福音。
正如中國惠普雲計算集成雲技術首席專家劉豔凱所說的那樣：「任何一項技術的發展和它受到的追捧，
都是由於它可以解決困擾人們的問題，」Docker正是這樣的一種技術。
Docker的解決問題能力雖然很強，但在企業中的實際應用卻並很少，那麼是什麼問題阻礙了Docker在企業中的實踐？


Docker將來發展
任何一項新技術的出現，都須要一個發展過程，好比雲計算爲企業所接受用了將近五年左右時間，
OpenStack技術也經歷了兩、三年才受到人們的承認。
所以，雖然Docker技術發展很快，但技術還不夠成熟，對存儲的靈活的支持、網絡的開銷和兼容性方面還存在限制，
這是Docker沒有被企業大範圍使用的一個主要緣由。另一個緣由是企業文化是否與DevOps運動一致，只有企業支持DevOps，
才能更大地發揮Docker的價值。
最後一個緣由就是安全性問題，Docker對於Linux這一層的安全的隔離還有待改進，才能進一步獲得企業的承認。
惠普劉豔凱認爲，這也是Docker須要在下一步中改進的一方面。
惠普幫助Docker實現企業價值
目前，雖然Docker還未在企業中大規模採用，但已有很多企業進入了嘗試階段；
而Docker做爲工具，如何讓它快速幫助開發人員達到他們指望的目標，纔是最重要的，惠普在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技術的侷限
網絡限制：容器網絡（Docker Network ）讓你能夠方便地在同一主機下對容器進行網絡鏈接。加上一些其餘的工做，你就能夠跨主機使用疊加網絡功能。
然而，也就到此爲止了。網絡配置操做是受限的，並且到目前爲止能夠說這些手段都是人工的。
儘管容器腳本化能夠規模化，由於你必須給網絡定義增長預分配實例，每次提供容器時還須要額外步驟，這容易引發錯誤。
庫控制受限：庫已經成爲任何容器會話的中心議題。公共庫是最有價值的，由於他貢獻了大量的預置容器，
節省了許多的配置時間。然而，在沙盒裏使用它是有風險的。
在不知道誰以及如何建立鏡像的狀況下，可能會存在任意數量的有意或無心的穩定性和安全性風險。
對於企業來講，有必要創建和維護一個私有庫，這個庫的創建挑戰不大，但管理是個問題。
Docker爲大型庫的鏡像管理提供了一個有限的元數據模型，確保將來實例如預期的能力受限，也沒有疊加功能。
沒有清晰的審計跟蹤：提供容器是很簡單的，但知道提供容器的時間、緣由、方式以及提供方卻不容易。
所以，在提供以後，你並不掌握多少出於審計目的的歷史。
運行實例的低可見性：若是沒有通過深思熟慮的行動，實例提供後很難接觸到運行容器的對象，也很難知道哪些應該出如今那裏，哪些不該該出如今那裏。
 
Docker安全性
Docker環境安全
Docker的勢頭在過去的12個月裏十分火熱，不少人表示不多見如此可以吸引行業興趣的新興技術。
然而，當興奮轉化爲實際部署時，企業須要注意Docker的安全性。
瞭解Docker的人都知道，Docker利用容器將資源進行有效隔離。
所以容器至關於與Linux OS和hypervisor有着幾乎相同的安全運行管理和配置管理級別。
但當Docker涉及到安全運營與管理，以及具備保密性、完整性和可用性的通用控件的支持時，Docker可能會讓你失望。
當Docker運行在雲提供商平臺上時，Docker安全性變得更加複雜。
你須要知道雲提供商正在作什麼，或許你正在於別人共享一臺機器。
Docker雖然容器沒有內置的安全因素，並且像Docker這樣的新興技術很難有比較全面的安全措施，但這並不意味着之後也不會出現。
Docker確保容器部署安全性
也有專家將Docker安全問題的實質定位於配置安全，認爲Docker目前的問題是很難配置一個安全的容器。
雖然如今Docker的開發人員經過建立很是小的容器來下降攻擊面，
但問題在於大型企業內部在生產環境中運行Docker容器的員工須要有更多的可見性和可控性。
企業在部署數千或數萬臺Docker容器時，可以確保這些Docker容器都遵照企業安全策略進行配置是相當重要的事情。
Docker爲解決這個問題，就須要增長Docker容器部署的實時可見性，同時實施企業制定的安全策略。
也有一些廠商爲此推出解決方案，給運營商提供了實時可見性並幫助他們執行容器級別的虛擬基礎設施的安全策略。

備註：隨筆中內容來源於網上資料整理,僅供參考。