docker被挖礦

⑴ 最近docker這么熱，但docker index已經被牆了，有沒有好的解決辦法

目前國內訪問docker hub非常便秘，使用docker mirror勢在必行。現有提供服務的有三家：ustc、cloud、aliyun，下面會一一介紹。
選擇一：ustc的鏡像
ustc是老牌的linux鏡像服務提供者了，還在遙遠的ubuntu 5.04版本的時候就在用。之前在blog里有提到可以用ustc的docker倉庫鏡像，使用方法參考ustc docker 鏡像使用幫助。
ustc的docker鏡像速度不錯，一直用的挺happy。但是今天發現不好使了，可能跟這件事有關系吧，今天嘗試去pull ubuntu，非常慢，應該是直接去docker hub上去拉了，基本沒有加速效果。
ustc docker mirror的優勢之一是，不需要注冊，公共服務(這才是我熟悉的ustc嘛)。
選擇二：cloud
DaoCloud也提供了docker加速器，但是跟ustc不同，需要用戶注冊後才能使用，並且每月限制流量10GB。linux上使用比較簡單，一條命令搞定：
curl -sSL https://get.cloud.io/tools/set_mirror.sh | sh -s http://{your_id}.m.cloud.io

實際改的是/usr/lib/systemd/system/docker.service，加了個–registry-mirror參數，：
ExecStart=/usr/bin/docker-current daemon --registry-mirror=http://{your_id}.m.cloud.io\

設置後，需要重新載入配置&重啟：
systemctl enable docker; systemctl daemon-reload ; systemctl restart docker

但是！今天使用DaoCloud的docker加速器體驗非常差，加速效果基本沒感覺，果斷放棄。
選擇三：alicloud
阿里雲也提供了docker加速器，不過比ustc更麻煩：不光要注冊為阿里雲的用戶，還得加入開發者平台。不過捏著鼻子昨晚這些以後，它的服務還真是不錯，基本1MB/s的pull速度(部分原因可能是因為我也在杭州吧)。配置方法跟cloud類似，也是開通加速器以後給一個url。
我直接去改/usr/lib/systemd/system/docker.service了：
ExecStart=/usr/bin/docker-current daemon --registry-mirror=https://{your_id}.mirror.aliyuncs.com\

重新載入配置&重啟：
systemctl enable docker; systemctl daemon-reload ; systemctl restart docker

pull的時候還是顯示docker.io，但速度一點都不docker.io。

⑵ 什麼是 docker 容器技術

Docker是什麼？

簡單得來說，Docker是一個由GO語言寫的程序運行的「容器」（Linux containers， LXCs）； 目前雲服務的基石是操作系統級別的隔離，在同一台物理伺服器上虛擬出多個主機。Docker則實現了一種應用程序級別的隔離； 它改變我們基本的開發、操作單元，由直接操作虛擬主機（VM）,轉換到操作程序運行的「容器」上來。

Docker是為開發者和系統管理員設計的，用來發布和運行分布式應用程序的一個開放性平台。由兩部分組成：

Docker Engine: 一個攜帶型、輕量級的運行環境和包管理器。（注* 單OS vs 單線程，是不是跟NodeJS特別像？）

Docker Hub: 為創建自動化工作流和分享應用創建的雲服務組成。（注* 雲端鏡像/包管理 vs npm包管理，是不是跟npm特別像？）

從2013年3月20日，第一個版本的Docker正式發布到 2014年6月Docker 1.0 正式發布，經歷了15個月。 雖然發展歷程很短，但Docker正在有越來越流行的趨勢。

其實Container技術並非Docker的創新，HeroKu, NodeJitsu 等雲服務商都採用了類似這種輕量級的虛擬化技術，但Docker是第一個將這這種Container技術大規模開源並被社區廣泛接受的。

好的部分
Docker相對於VM虛擬機的優勢十分明顯，那就是輕量和高性能和便捷性， 以下部分摘自：KVM and Docker LXC Benchmarking with OpenStack

快
運行時的性能可以獲取極大提升（經典的案例是提升97%）

管理操作（啟動，停止，開始，重啟等等） 都是以秒或毫秒為單位的。

敏捷
像虛擬機一樣敏捷，而且會更便宜，在bare metal（裸機）上布署像點個按鈕一樣簡單。

靈活
將應用和系統「容器化」，不添加額外的操作系統，

輕量
你會擁有足夠的「操作系統」，僅需添加或減小鏡像即可。在一台伺服器上可以布署100~1000個Containers容器。

便宜
開源的，免費的，低成本的。由現代Linux內核支持並驅動。注* 輕量的Container必定可以在一個物理機上開啟更多「容器」，註定比VMs要便宜。

生態系統
正在越來越受歡迎，只需要看一看Google的趨勢就知道了，docker or LXC.

還有不計其數的社區和第三方應用。

雲支持
不計其數的雲服務提供創建和管理Linux容器框架。

⑶ 在IT項目建設中，如何保證資料庫安全性

#雲原生背景#

雲計算是信息技術發展和服務模式創新的集中體現，是信息化發展的重要變革和必然趨勢。隨著「新基建」加速布局，以及企業數字化轉型的逐步深入，如何深化用雲進一步提升雲計算使用效能成為現階段雲計算發展的重點。雲原生以其高效穩定、快速響應的特點極大地釋放了雲計算效能，成為企業數字業務應用創新的原動力，雲原生進入快速發展階段，就像集裝箱加速貿易全球化進程一樣，雲原生技術正在助力雲計算普及和企業數字化轉型。

雲原生計算基金會（CNCF）對雲原生的定義是：雲原生技術有利於各組織在公有雲、私有雲和混合雲等新型動態環境中，構建和運行可彈性擴展的應用。雲原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式編程API。

#雲安全時代市場發展#

雲安全幾乎是伴隨著雲計算市場而發展起來的，雲基礎設施投資的快速增長，無疑為雲安全發展提供土壤。根據 IDC 數據，2020 年全球雲安全支出占雲 IT 支出比例僅為 1.1%，說明目前雲安全支出遠遠不夠，假設這一比例提升至 5%，那麼2020 年全球雲安全市場空間可達 53.2 億美元，2023 年可達 108.9 億美元。

海外雲安全市場：技術創新與兼並整合活躍。整體來看，海外雲安全市場正處於快速發展階段，技術創新活躍，兼並整合頻繁。一方面，雲安全技術創新活躍，並呈現融合發展趨勢。例如，綜合型安全公司 PaloAlto 的 Prisma 產品線將 CWPP、CSPM 和 CASB 三個雲安全技術產品統一融合，提供綜合解決方案及 SASE、容器安全、微隔離等一系列雲上安全能力。另一方面，新興的雲安全企業快速發展，同時，傳統安全供應商也通過自研+兼並的方式加強雲安全布局。

國內雲安全市場：市場空間廣闊，尚處於技術追隨階段。市場規模上，根據中國信通院數據，2019 年我國雲計算整體市場規模達 1334.5億元，增速 38.6%。預計 2020-2022 年仍將處於快速增長階段，到 2023 年市場規模將超過 3754.2 億元。中性假設下，安全投入占雲計算市場規模的 3%-5%，那麼 2023 年中國雲安全市場規模有望達到 112.6 億-187.7 億元。技術發展上，中國在雲計算的發展階段和雲原生技術的程度上與海外市場還有一定差距。國內 CWPP 技術應用較為廣泛，對於 CASB、CSPM 一些新興的雲安全技術應用較少。但隨著國內公有雲市場的加速發展，雲原生技術的應用越來越廣泛，我們認為CASB、SCPM、SASE 等新興技術在國內的應用也將越來越廣泛。

#雲上安全呈原生化發展趨勢#

雲原生技術逐漸成為雲計算市場新趨勢，所帶來的安全問題更為復雜。以容器、服務網格、微服務等為代表的雲原生技術，正在影響各行各業的 IT 基礎設施、平台和應用系統，也在滲透到如 IT/OT 融合的工業互聯網、IT/CT 融合的 5G、邊緣計算等新型基礎設施中。隨著雲原生越來越多的落地應用，其相關的安全風險與威脅也不斷的顯現出來。Docker/Kubernetes 等服務暴露問題、特斯拉 Kubernetes 集群挖礦事件、Docker Hub 中的容器鏡像被「投毒」注入挖礦程序、微軟 Azure 安全中心檢測到大規模 Kubernetes 挖礦事件、Graboid 蠕蟲挖礦傳播事件等一系列針對雲原生的安全攻擊事件層出不窮。

從各種各樣的安全風險中可以一窺雲原生技術的安全態勢，雲原生環境仍然存在許多安全問題亟待解決。在雲原生技術的落地過程中，安全是必須要考慮的重要因素。

#雲原生安全的定義#

國內外各組織、企業對雲原生安全理念的解釋略有差異，結合我國產業現狀與痛點，雲原生與雲計算安全相似，雲原生安全也包含兩層含義：「面向雲原生環境的安全」和「具有雲原生特徵的安全」。

面向雲原生環境的安全，其目標是防護雲原生環境中的基礎設施、編排系統和微服務的安全。這類安全機制，不一定具備雲原生的特性（比如容器化、可編排），它們可以是傳統模式部署的，甚至是硬體設備，但其作用是保護日益普及的雲原生環境。

具有雲原生特徵的安全，是指具有雲原生的彈性敏捷、輕量級、可編排等特性的各類安全機制。雲原生是一種理念上的創新，通過容器化、資源編排和微服務重構了傳統的開發運營體系，加速業務上線和變更的速度，因而，雲原生系統的種種優良特性同樣會給安全廠商帶來很大的啟發，重構安全產品、平台，改變其交付、更新模式。

#雲原生安全理念構建#

為緩解傳統安全防護建設中存在的痛點，促進雲計算成為更加安全可信的信息基礎設施，助力雲客戶更加安全的使用雲計算，雲原生安全理念興起，國內外第三方組織、服務商紛紛提出以原生為核心構建和發展雲安全。

Gartner提倡以雲原生思維建設雲安全體系

基於雲原生思維，Gartner提出的雲安全體系覆蓋八方面。其中，基礎設施配置、身份和訪問管理兩部分由雲服務商作為基礎能力提供，其它六部分，包括持續的雲安全態勢管理，全方位的可視化、日誌、審計和評估，工作負載安全，應用、PaaS 和 API 安全，擴展的數據保護，雲威脅檢測，客戶需基於安全產品實現。

Forrester評估公有雲平台原生安全能力

Forrester認為公有雲平台原生安全（Public cloud platform native security, PCPNS）應從三大類、37 個方面去衡量。從已提供的產品和功能，以及未來戰略規劃可以看出，一是考察雲服務商自身的安全能力和建設情況，如數據中心安全、內部人員等，二是雲平台具備的基礎安全功能，如幫助和文檔、授權和認證等，三是為用戶提供的原生安全產品，如容器安全、數據安全等。

安全狗以4項工作防護體系建設雲原生安全

（1）結合雲原生技術的具體落地情況開展並落實最小許可權、縱深防禦工作，對於雲原生環境中的各種組成部分，均可貫徹落實「安全左移」的原則，進行安全基線配置，防範於未然。而對於微服務架構Web應用以及Serverless應用的防護而言，其重點是應用安全問題。

（2）圍繞雲原生應用的生命周期來進行DevSecOps建設，以當前的雲原生環境的關鍵技術棧「K8S + Docker」舉例進行分析。應該在容器的全生命周期注重「配置安全」，在項目構建時注重「鏡像安全」，在項目部署時注重「容器准入」，在容器的運行環境注重雲計算的三要素「計算」「網路」以及「存儲」等方面的安全問題。

（3）圍繞攻擊前、中、後的安全實施准則進行構建，可依據安全實施准則對攻擊前、中、後這三個階段開展檢測與防禦工作。

（4）改造並綜合運用現有雲安全技術，不應將「雲原生安全」視為一個獨立的命題，為雲原生環境提供更多支持的主機安全、微隔離等技術可賦能於雲原生安全。

#雲原生安全新型風險#

雲原生架構的安全風險包含雲原生基礎設施自身的安全風險，以及上層應用雲原生化改造後新增和擴大的安全風險。雲原生環境面臨著嚴峻的安全風險問題。攻擊者可能利用的重要攻擊麵包括但不限於：容器安全、編排系統、軟體供應鏈等。下面對重要的攻擊面安全風險問題進行梳理。

#雲原生安全問題梳理#

問題1：容器安全問題

在雲原生應用和服務平台的構建過程中，容器技術憑借高彈性、敏捷的特性，成為雲原生應用場景下的重要技術支撐，因而容器安全也是雲原生安全的重要基石。

（1）容器鏡像不安全

Sysdig的報告中提到，在用戶的生產環境中，會將公開的鏡像倉庫作為軟體源，如最大的容器鏡像倉庫Docker Hub。一方面，很多開源軟體會在Docker Hub上發布容器鏡像。另一方面，開發者通常會直接下載公開倉庫中的容器鏡像，或者基於這些基礎鏡像定製自己的鏡像，整個過程非常方便、高效。然而，Docker Hub上的鏡像安全並不理想，有大量的官方鏡像存在高危漏洞，如果使用了這些帶高危漏洞的鏡像，就會極大的增加容器和主機的入侵風險。目前容器鏡像的安全問題主要有以下三點：

1.不安全的第三方組件
在實際的容器化應用開發過程當中，很少從零開始構建鏡像，而是在基礎鏡像之上增加自己的程序和代碼，然後統一打包最終的業務鏡像並上線運行，這導致許多開發者根本不知道基礎鏡像中包含多少組件，以及包含哪些組件，包含的組件越多，可能存在的漏洞就越多。

2.惡意鏡像
公共鏡像倉庫中可能存在第三方上傳的惡意鏡像，如果使用了這些惡意鏡像來創建容器後，將會影響容器和應用程序的安全

3.敏感信息泄露
為了開發和調試的方便，開發者將敏感信息存在配置文件中，例如資料庫密碼、證書和密鑰等內容，在構建鏡像時，這些敏感信息跟隨配置文件一並打包進鏡像，從而造成敏感信息泄露

（2）容器生命周期的時間短

雲原生技術以其敏捷、可靠的特點驅動引領企業的業務發展，成為企業數字業務應用創新的原動力。在容器環境下，一部分容器是以docker的命令啟動和管理的，還有大量的容器是通過Kubernetes容器編排系統啟動和管理，帶來了容器在構建、部署、運行，快速敏捷的特點，大量容器生命周期短於1小時，這樣一來容器的生命周期防護較傳統虛擬化環境發生了巨大的變化，容器的全生命周期防護存在很大變數。對防守者而言，需要採用傳統異常檢測和行為分析相結合的方式，來適應短容器生命周期的場景。

傳統的異常檢測採用WAF、IDS等設備，其規則庫已經很完善，通過這種檢測方法能夠直觀的展示出存在的威脅，在容器環境下，這種方法仍然適用。

傳統的異常檢測能夠快速、精確地發現已知威脅，但大多數未知威脅是無法通過規則庫匹配到的，因而需要通過行為分析機制來從大量模式中將異常模式分析出來。一般來說，一段生產運營時間內的業務模式是相對固定的，這意味著，業務行為是可以預測的，無論啟動多少個容器，容器內部的行為總是相似的。通過機器學習、採集進程行為，自動構建出合理的基線，利用這些基線對容器內的未知威脅進行檢測。

（3）容器運行時安全

容器技術帶來便利的同時，往往會忽略容器運行時的安全加固，由於容器的生命周期短、輕量級的特性，傳統在宿主機或虛擬機上安裝殺毒軟體來對一個運行一兩個進程的容器進行防護，顯示費時費力且消耗資源，但在黑客眼裡容器和裸奔沒有什麼區別。容器運行時安全主要關注點：

1.不安全的容器應用
與傳統的Web安全類似，容器環境下也會存在SQL注入、XSS、RCE、XXE等漏洞，容器在對外提供服務的同時，就有可能被攻擊者利用，從而導致容器被入侵

2.容器DDOS攻擊
默認情況下，docker並不會對容器的資源使用進行限制，默認情況下可以無限使用CPU、內存、硬碟資源，造成不同層面的DDOS攻擊

（4）容器微隔離

在容器環境中，與傳統網路相比，容器的生命周期變得短了很多，其變化頻率也快很多。容器之間有著復雜的訪問關系，尤其是當容器數量達到一定規模以後，這種訪問關系帶來的東西向流量，將會變得異常的龐大和復雜。因此，在容器環境中，網路的隔離需求已經不僅僅是物理網路的隔離，而是變成了容器與容器之間、容器組與宿主機之間、宿主機與宿主機之間的隔離。

問題2：雲原生等保合規問題

等級保護2.0中，針對雲計算等新技術、新應用領域的個性安全保護需求提出安全擴展要求，形成新的網路安全等級保護基本要求標准。雖然編寫了雲計算的安全擴展要求，但是由於編寫周期很長，編寫時主流還是虛擬化場景，而沒有考慮到容器化、微服務、無服務等雲原生場景，等級保護2.0中的所有標准不能完全保證適用於目前雲原生環境；

通過安全狗在雲安全領域的經驗和具體實踐，對於雲計算安全擴展要求中訪問控制的控制點，需要檢測主機賬號安全，設置不同賬號對不同容器的訪問許可權，保證容器在構建、部署、運行時訪問控制策略隨其遷移；

對於入侵防範制的控制點，需要可視化管理，繪制業務拓撲圖，對主機入侵進行全方位的防範，控制業務流量訪問，檢測惡意代碼感染及蔓延的情況；

鏡像和快照保護的控制的，需要對鏡像和快照進行保護，保障容器鏡像的完整性、可用性和保密性，防止敏感信息泄露。

問題3：宿主機安全

容器與宿主機共享操作系統內核，因此宿主機的配置對容器運行的安全有著重要的影響，比如宿主機安裝了有漏洞的軟體可能會導致任意代碼執行風險，埠無限制開放可能會導致任意用戶訪問的風險。通過部署主機入侵監測及安全防護系統，提供主機資產管理、主機安全加固、風險漏洞識別、防範入侵行為、問題主機隔離等功能，各個功能之間進行聯動，建立採集、檢測、監測、防禦、捕獲一體化的安全閉環管理系統，對主機進行全方位的安全防護，協助用戶及時定位已經失陷的主機，響應已知、未知威脅風險，避免內部大面積主機安全事件的發生。

問題4：編排系統問題

編排系統支撐著諸多雲原生應用，如無服務、服務網格等，這些新型的微服務體系也同樣存在著安全問題。例如攻擊者編寫一段代碼獲得容器的shell許可權，進而對容器網路進行滲透橫移，造成巨大損失。

Kubernetes架構設計的復雜性，啟動一個Pod資源需要涉及API Server、Controller、Manager、Scheler等組件，因而每個組件自身的安全能力顯的尤為重要。API Server組件提供的認證授權、准入控制，進行細粒度訪問控制、Secret資源提供密鑰管理及Pod自身提供安全策略和網路策略，合理使用這些機制可以有效實現Kubernetes的安全加固。

問題5：軟體供應鏈安全問題

通常一個項目中會使用大量的開源軟體，根據Gartner統計至少有95%的企業會在關鍵IT產品中使用開源軟體，這些來自互聯網的開源軟體可能本身就帶有病毒、這些開源軟體中使用了哪些組件也不了解，導致當開源軟體中存在0day或Nday漏洞，我們根本無法獲悉。

開源軟體漏洞無法根治，容器自身的安全問題可能會給開發階段帶的各個過程帶來風險，我們能做的是根據SDL原則，從開發階段就開始對軟體安全性進行合理的評估和控制，來提升整個供應鏈的質量。

問題6：安全運營成本問題

雖然容器的生命周期很短，但是包羅萬象。對容器的全生命周期防護時，會對容器構建、部署、運行時進行異常檢測和安全防護，隨之而來的就是高成本的投入，對成千上萬容器中的進程行為進程檢測和分析，會消耗宿主機處理器和內存資源，日誌傳輸會佔用網路帶寬，行為檢測會消耗計算資源，當環境中容器數量巨大時，對應的安全運營成本就會急劇增加。

問題7：如何提升安全防護效果

關於安全運營成本問題中，我們了解到容器安全運營成本較高，我們該如何降低安全運營成本的同時，提升安全防護效果呢？這就引入一個業界比較流行的詞「安全左移」，將軟體生命周期從左到右展開，即開發、測試、集成、部署、運行，安全左移的含義就是將安全防護從傳統運營轉向開發側，開發側主要設計開發軟體、軟體供應鏈安全和鏡像安全。

因此，想要降低雲原生場景下的安全運營成本，提升運營效率，那麼首先就要進行「安全左移」，也就是從運營安全轉向開發安全，主要考慮開發安全、軟體供應鏈安全、鏡像安全和配置核查：

開發安全
需要團隊關注代碼漏洞，比如使用進行代碼審計，找到因缺少安全意識造成的漏洞和因邏輯問題造成的代碼邏輯漏洞。
供應鏈安全
可以使用代碼檢查工具進行持續性的安全評估。
鏡像安全
使用鏡像漏洞掃描工具持續對自由倉庫中的鏡像進行持續評估，對存在風險的鏡像進行及時更新。
配置核查
核查包括暴露面、宿主機加固、資產管理等，來提升攻擊者利用漏洞的難度。

問題8：安全配置和密鑰憑證管理問題

安全配置不規范、密鑰憑證不理想也是雲原生的一大風險點。雲原生應用會存在大量與中間件、後端服務的交互，為了簡便，很多開發者將訪問憑證、密鑰文件直接存放在代碼中，或者將一些線上資源的訪問憑證設置為弱口令，導致攻擊者很容易獲得訪問敏感數據的許可權。

#雲原生安全未來展望#

從日益新增的新型攻擊威脅來看，雲原生的安全將成為今後網路安全防護的關鍵。伴隨著ATT&CK的不斷積累和相關技術的日益完善，ATT&CK也已增加了容器矩陣的內容。ATT&CK是對抗戰術、技術和常識（Adversarial Tactics, Techniques, and Common Knowledge）的縮寫，是一個攻擊行為知識庫和威脅建模模型，它包含眾多威脅組織及其使用的工具和攻擊技術。這一開源的對抗戰術和技術的知識庫已經對安全行業產生了廣泛而深刻的影響。

雲原生安全的備受關注，使ATTACK Matrix for Container on Cloud的出現恰合時宜。ATT&CK讓我們從行為的視角來看待攻擊者和防禦措施，讓相對抽象的容器攻擊技術和工具變得有跡可循。結合ATT&CK框架進行模擬紅藍對抗，評估企業目前的安全能力，對提升企業安全防護能力是很好的參考。

⑷ docker和虛擬機的區別 知乎

Docker
Docker是一個集開發、打包、運行應用於一體的開放式平台。Docker可以用來快速交付應用。使用Docker，你可以將應用程序從你的基礎設施中分離出來，並將基礎設施當做一個管理平台。Docker可以加快打包時間，加快測試，加快發布，縮短開發及運行代碼之間的周期。Docker通過結合內核容器化特點和工作流，並使之工具化來實現這一切，幫助管理和發布你的應用。
虛擬機
虛擬機在本質上就是在模擬一台真實的計算機設備，同時遵循同樣的程序執行方式。虛擬機能夠利用虛擬機管理程序運行在物理設備之上。反過來，虛擬機管理程序則可運行在主機設備或者裸機之上。
傳統的虛擬機需要模擬數台機器包括硬體，每台虛擬機都需要有自己的操作系統，虛擬機一旦被開啟，預分配給他的資源將全部被佔用。每一個虛擬機包含應用，必要的二進制和庫，以及一個完整的用戶操作系統。
Docker和虛擬機有什麼區別?
虛擬機
1、資源佔用多，虛擬機會獨佔一部分內存和硬碟空間。它運行的時候，其他程序就不能使用這些資源，哪怕虛擬機裡面的應用程序，真正使用的內存只有1MB，虛擬機依然需要幾百MB的內存才能運行。
2、冗餘步驟多，虛擬機是完整的操作系統，一些系統級別的操作步驟，往往無法跳過，比如用戶登錄。
3、啟動慢，啟動操作系統需要多久，啟動虛擬機就需要多久，可能需要等幾分鍾，應用程序才能真正運行。
Docker
1、啟動快，容器裡面的應用，直接就是底層系統的一個進程，而不是虛擬機內部的進程。所以啟動容器相當於啟動本機的一個進程，而不是啟動一個操作系統，速度就快很多。
2、資源佔用少，容器只佔用需要的資源，不佔用那些沒有用到的資源;虛擬機由於是完整的操作系統，不可避免要佔用所有資源;另外，多個容器可以共享資源，虛擬機都是獨享資源。
3、體積小，容器只要包含用到的組件即可，而虛擬機是整個操作系統的打包，所以容器文件比虛擬機文件要小很多。

⑸ 常見的容器安全威脅有哪些

以Docker 容器的安全問題為例

(1) Docker 自身安全

Docker 作為一款容器引擎，本身也會存在一些安全漏洞，CVE 目前已經記錄了多項與 Docker 相關的安全漏洞，主要有許可權提升、信息泄露等幾類安全問題。

(2) 鏡像安全

由於Docker 容器是基於鏡像創建並啟動，因此鏡像的安全直接影響到容器的安全。具體影響鏡像安全的總結如下。

鏡像軟體存在安全漏洞：由於容器需要安裝基礎的軟體包，如果軟體包存在漏洞，則可能會被不法分子利用並且侵入容器，影響其他容器或主機安全。

倉庫漏洞：無論是Docker 官方的鏡像倉庫還是我們私有的鏡像倉庫，都有可能被攻擊，然後篡改鏡像，當我們使用鏡像時，就可能成為攻擊者的目標對象。

用戶程序漏洞：用戶自己構建的軟體包可能存在漏洞或者被植入惡意腳本，這樣會導致運行時提權影響其他容器或主機安全。

(3) Linux 內核隔離性不夠

盡管目前Namespace 已經提供了非常多的資源隔離類型，但是仍有部分關鍵內容沒有被完全隔離，其中包括一些系統的關鍵性目錄（如 /sys、/proc 等），這些關鍵性的目錄可能會泄露主機上一些關鍵性的信息，讓攻擊者利用這些信息對整個主機甚至雲計算中心發起攻擊。

而且僅僅依靠Namespace 的隔離是遠遠不夠的，因為一旦內核的 Namespace 被突破，使用者就有可能直接提權獲取到主機的超級許可權，從而影響主機安全。

(4) 所有容器共享主機內核

由於同一宿主機上所有容器共享主機內核，所以攻擊者可以利用一些特殊手段導致內核崩潰，進而導致主機宕機影響主機上其他服務。

既然容器有這么多安全上的問題，那麼我們應該如何做才能夠既享受到容器的便利性同時也可以保障容器安全呢？下面我帶你來逐步了解下如何解決容器的安全問題。

如何解決容器的安全問題？

(1) Docker 自身安全性改進

事實上，Docker 從 2013 年誕生到現在，在安全性上面已經做了非常多的努力。目前 Docker 在默認配置和默認行為下是足夠安全的。

Docker 自身是基於 Linux 的多種 Namespace 實現的，其中有一個很重要的 Namespace 叫作 User Namespace，User Namespace 主要是用來做容器內用戶和主機的用戶隔離的。在過去容器里的 root 用戶就是主機上的 root 用戶，如果容器受到攻擊，或者容器本身含有惡意程序，在容器內就可以直接獲取到主機 root 許可權。Docker 從 1.10 版本開始，使用 User Namespace 做用戶隔離，實現了容器中的 root 用戶映射到主機上的非 root 用戶，從而大大減輕了容器被突破的風險。

因此，我們盡可能地使用Docker 最新版本就可以得到更好的安全保障。

(2) 保障鏡像安全

為保障鏡像安全，我們可以在私有鏡像倉庫安裝鏡像安全掃描組件，對上傳的鏡像進行檢查，通過與CVE 資料庫對比，一旦發現有漏洞的鏡像及時通知用戶或阻止非安全鏡像繼續構建和分發。同時為了確保我們使用的鏡像足夠安全，在拉取鏡像時，要確保只從受信任的鏡像倉庫拉取，並且與鏡像倉庫通信一定要使用 HTTPS 協議。

(3) 加強內核安全和管理

由於僅僅依賴內核的隔離可能會引發安全問題，因此我們對於內核的安全應該更加重視。可以從以下幾個方面進行加強。

宿主機及時升級內核漏洞

宿主機內核應該盡量安裝最新補丁，因為更新的內核補丁往往有著更好的安全性和穩定性。

使用Capabilities 劃分許可權

Capabilities 是 Linux 內核的概念，Linux 將系統許可權分為了多個 Capabilities，它們都可以單獨地開啟或關閉，Capabilities 實現了系統更細粒度的訪問控制。

容器和虛擬機在許可權控制上還是有一些區別的，在虛擬機內我們可以賦予用戶所有的許可權，例如設置cron 定時任務、操作內核模塊、配置網路等許可權。而容器則需要針對每一項 Capabilities 更細粒度的去控制許可權，例如：

cron 定時任務可以在容器內運行，設置定時任務的許可權也僅限於容器內部；

由於容器是共享主機內核的，因此在容器內部一般不允許直接操作主機內核；

容器的網路管理在容器外部，這就意味著一般情況下，我們在容器內部是不需要執行ifconfig、route等命令的 。

由於容器可以按照需求逐項添加Capabilities 許可權，因此在大多數情況下，容器並不需要主機的 root 許可權，Docker 默認情況下也是不開啟額外特權的。

最後，在執行docker run命令啟動容器時，如非特殊可控情況，–privileged 參數不允許設置為 true，其他特殊許可權可以使用 --cap-add 參數，根據使用場景適當添加相應的許可權。

使用安全加固組件

Linux 的 SELinux、AppArmor、GRSecurity 組件都是 Docker 官方推薦的安全加固組件。下面我對這三個組件做簡單介紹。

SELinux (Secure Enhanced Linux): 是 Linux 的一個內核安全模塊，提供了安全訪問的策略機制，通過設置 SELinux 策略可以實現某些進程允許訪問某些文件。

AppArmor: 類似於 SELinux，也是一個 Linux 的內核安全模塊，普通的訪問控制僅能控制到用戶的訪問許可權，而 AppArmor 可以控制到用戶程序的訪問許可權。

GRSecurity: 是一個對內核的安全擴展，可通過智能訪問控制，提供內存破壞防禦，文件系統增強等多種防禦形式。

這三個組件可以限制一個容器對主機的內核或其他資源的訪問控制。目前，容器報告的一些安全漏洞中，很多都是通過對內核進行加強訪問和隔離來實現的。

資源限制

在生產環境中，建議每個容器都添加相應的資源限制。下面給出一些執行docker run命令啟動容器時可以傳遞的資源限制參數：

1--cpus 限制 CPU 配額

2-m, --memory 限制內存配額

3--pids-limit 限制容器的 PID 個數

例如我想要啟動一個1 核 2G 的容器，並且限制在容器內最多隻能創建 1000 個 PID，啟動命令如下：

1 $ docker run -it --cpus=1 -m=2048m --pids-limit=1000 busybox sh

推薦在生產環境中限制CPU、內存、PID 等資源，這樣即便應用程序有漏洞，也不會導致主機的資源完全耗盡，最大限度降低安全風險。

(4) 使用安全容器

容器有著輕便快速啟動的優點，虛擬機有著安全隔離的優點，有沒有一種技術可以兼顧兩者的優點，做到既輕量又安全呢？

答案是有，那就是安全容器。安全容器是相較於普通容器的，安全容器與普通容器的主要區別在於，安全容器中的每個容器都運行在一個單獨的微型虛擬機中，擁有獨立的操作系統和內核，並且有虛擬化層的安全隔離。

安全容器目前推薦的技術方案是Kata Containers，Kata Container 並不包含一個完整的操作系統，只有一個精簡版的 Guest Kernel 運行著容器本身的應用，並且通過減少不必要的內存，盡量共享可以共享的內存來進一步減少內存的開銷。另外，Kata Container 實現了 OCI 規范，可以直接使用 Docker 的鏡像啟動 Kata 容器，具有開銷更小、秒級啟動、安全隔離等許多優點。

⑹ 如何看待docker容器與虛擬機之間的比較

目前來看，Docker至少有以下應用場景：1）測試：Docker 很適合用於測試發布，將 Docker 封裝後可以直接提供給測試人員進行運行，不再需要測試人員與運維、開發進行配合，進行環境搭建與部署。2）測試數據分離：在測試中，經常由於測試場景變換，需要修改依賴的資料庫數據或者清空變動 memcache、Redis 中的緩存數據。Docker 相較於傳統的虛擬機，更輕量與方便。可以很容易的將這些數據分離到不同的鏡像中，根據不同需要隨時進行切換。3）開發：開發人員共同使用同一個 Docker 鏡像，同時修改的源代碼都被掛載到本地磁碟。不再因為環境的不同而造成的不同程序行為而傷透腦筋，同時新人到崗時也能迅速建立開發、編譯環境。4）PaaS 雲服務：Docker 可以支持命令行封裝與編程，通過自動載入與服務自發現，可以很方便的將封裝於 Docker 鏡像中的服務擴展成雲服務。類似像 Doc 轉換預覽這樣的服務封裝於鏡像中，根據業務請求的情況隨時增加和減少容器的運行數量，隨需應變。具體到Docker技術在測試領域的應用，可以體現在：1）快速搭建兼容性測試環境從Docker的鏡像與容器技術特點可以預見，當被測應用要求在各類Web伺服器、中間件、資料庫的組合環境中得到充分驗證時，可以快速地利用基礎Docker鏡像創建各類容器，裝載相應的技術組件並快速啟動運行，測試人員省去了大量花在測試環境搭建上的時間。2）快速搭建復雜分布式測試環境Docker的輕量虛擬化特點決定了它可以在一台機器上（甚至是測試人員的一台筆記本電腦上）輕松搭建出成百上千個分布式節點的容器環境，從而模擬以前需要耗費大量時間和機器資源才能搭建出來的分布式復雜測試環境。3）持續集成Docker可以快速創建和撤銷容器，在持續集成的環境中，可以頻繁和快速地進行部署和驗證工作。

⑺ 什麼是docker容器技術

docker容器技術指Docker是一個由GO語言寫的程序運行的「容器」（Linux containers， LXCs）

⑻ 最近docker 方面有爆漏洞么

建議騰訊電腦管家修復，系統漏洞經常被黑客利用傳播惡意程序（如網頁掛馬），必須及時修復系統漏洞才能有效防止計算機在上網時被黑客入侵，不過如果安裝了安全軟體，並且漏洞介紹看起來不是那麼嚴重的話，可以選擇不修復。
Windows系統漏洞是指操作系統在開發過程中存在的技術缺陷，這些缺陷可能導致其他用戶在未被授權的情況下非法訪問或攻擊計算機系統。因此，系統開發商一般每月都會發布最新的補丁用以修復新發現的漏洞。目前，騰訊電腦管家支持修復Windows操作系統漏洞和部分第三方軟體漏洞。

⑼ docker 是做運行環境嗎

Docker的安裝和構成
Docker官方本身提供了非常具體的安裝教程，這里不說具體的安裝過程，請參考Docker安裝（Mac系統），重要的是描述下原理和安裝完成後的結構，好對Docker更好的了解。 由於LXC本身不支持Mac內核，因此需要跑一個VirtualBox虛擬機（TinyCoreLinux）來安裝，幸好Docker社區提供了一個非常方便的工具boot2docker（其實就是一個VBoxManage的包裝shell腳本），用於安裝Mac下的整個Docker環境。具體的結構如下：

如圖所示，安裝完成後，具體情況如下：
在Mac的home目錄~/.boot2docker下創建了虛擬機所需要的文件，其中boot2docker.iso是虛擬機映像，這是一個由CD-ROM引導的TinyCoreLinux系統；而boot2docker-vm.vmdk文件則是你的虛擬機磁碟，你所有的持久化數據都存放在這里，包括docker創建的lxc容器等文件。
在Mac下，docker被分為客戶端docker-client和服務端docker-daemon兩部分，如果是在linux（比如ubuntu），實際上則是同一個可執行文件同時充當客戶端和服務端。docker-daemon可以監聽unix scoket，也可以在tcp socket（默認埠為4234），docker-client會通過一個叫DOCKER_HOST的環境變數讀取服務地址和埠，因此你應該在你的bash_profile文件裡面添加這么一行：

1
2

export DOCKER_HOST=tcp://127.0.0.1:4243

docker-daemon跑在虛擬機上，這個程序實際上就是接收docker-client發送過來的消息命令，創建、啟動和銷毀lxc容器，以及docker本身的版本管理、映像存儲等等 運行你的第一個docker容器 安裝完成後，就差不多可以開始創建和運行docker容器了，在這之前，你首先得下載一個Image，什麼是Image？我們先來了解docker的2個基礎概念：Image和Container。
Container和Image 在Docker的世界裡，Image是指一個只讀的層（Layer），這里的層是AUFS里的概念，最直觀的方式就是看一下docker官方給出的圖：

Docker使用了一種叫AUFS的文件系統，這種文件系統可以讓你一層一層地疊加修改你的文件，最底下的文件系統是只讀的，如果需要修改文件，AUFS會增加一個可寫的層（Layer），這樣有很多好處，例如不同的Container可以共享底層的只讀文件系統（同一個Kernel），使得你可以跑N多個Container而不至於你的硬碟被擠爆了！這個只讀的層就是Image！而如你所看到的，一個可寫的層就是Container。
那Image和Container的區別是什麼？很簡單，他們的區別僅僅是一個是只讀的層，一個是可寫的層，你可以使用docker commit 命令，將你的Container變成一個Image，也就是提交你所運行的Container的修改內容，變成一個新的只讀的Image，這非常類似於git commit命令，感覺真棒！
實際上這就是Docker對Container映像的版本管理基石，AUFS文件系統實在是太美妙了，更多細節可以參考DotCloud的這篇文章。
運行和退出
在了解了Image和Container的概念後，我們可以開始下載一個Image，Docker的好處就是提供了一個類似github的Image倉庫管理，你可以非常方便pull別人的Image下來運行，例如，我們可以下載一個ubuntu Image：

1
2

docker pull ubuntu:13.10

這里的13.10是一個Tag，類似於git的tag，這里的tag可以為你制定一個ubuntu的版本。下載完成後，執行docker images命令可以列出你已經下載或者自己構建的image：（請允許我使用可愛的馬賽克 :) ）

你可以看到ubuntu:13.10的大小為178MB，以及它的IMAGE ID。 現在我們開始運行一個Container，命令很簡單，例如我們想運行一個執行Shell終端的Container：

如你看到的，你已經進入到一個Shell裡面，可以執行你想執行的任何命令，就和在ubuntu裡面一樣，進去後默認是在根目錄/下，可以看到經典的unix/linux目錄結構，以及你所運行的bash版本等信息。你可以給你的Container定一個名字，通過–name選項，例如這里命名了shell，日後你就可以直接用這個名字引用Contanier。
退出一個Container也很簡單，你直接exit就好了。 其他更多的命令這里不做贅述，因為官方的文檔已經非常全面，這里只是給一個直觀的初步印象。下面進入主題。
利用Docker搭建開發環境
我們先看看程序員在搭建開發環境時遇到的一些問題：
軟體安裝麻煩，比如很多公司都使用redhat，一般開發人員又不給root，安裝一個nginx或者是mysql都得自己下載編譯安裝 許可權問題，沒有root，一些軟體無法運行，例如dnsmasq；
沒有root，無法修改hosts，無法netstat -nptl，無法tcpmp，無法iptable
隔離性差，例如不同的開發人員如果在同一台主機環境下共享開發，雖然是用戶隔離，但埠如果不規范可能會沖突；同一個Mysql如果許可權管理不好很有可能誤刪別人的數據
可移植性差，例如和生產環境不一致，開發人員之間也無法共享；更嚴重的情況是當有新人入職時，通常需要又折騰一遍開發環境，無法快速搭建
這些問題可以通過在本地搭建虛擬機來解決，但虛擬機是一個很笨重的解決方案，Docker是一個非常輕量級的方案，而且還擁有虛擬機沒有的一些功能，例如標准化Image，Image共享等，更重要的是，利用Docker，你可以運行非常多的容器，在你的Mac下搭建一個分布式的開發環境根本不是什麼大的問題，而且對內存、磁碟和cpu的消耗相比傳統的虛擬機要低許多，這些都要歸功於AUFS和LXC這兩大神奇的技術。
構建基礎Image
想要搭建一個節省磁碟空間和擴展性良好的開發環境，最重要的第一步就是構建一個基礎性的Image，比如你的主要開發語言是Ruby，那麼你肯定需要一個已經安裝好以下工具的基礎Image：
ruby
bundler
gem
然後在此基礎上，你可以擴展這個基礎的Image（下面叫base）為不同的開發環境，例如rails，或者是nats。當然，你的這個base也可以從別人的Image擴展而來，還記得我們剛剛pull下來的ubuntu:13.10這個Image嗎？你可以從這個Image擴展開始構建你的base，如何做呢？Docker提供了一種標准化的DSL方式，你只需要編寫一個Dockerfile，運行docker build指令，就可以構建你自己的Image，這有點像Makefile和make命令一樣，只是大家要構建的內容和構建語言不同。
Dockerfile的語法請參考Dockerfile Reference，這里給出上面提到的Ruby開發的base Dockerfile示例：

1
2
3
4
5

FROM ubuntu:13.10
RUN apt-get update
RUN apt-get install -y ruby ruby-dev gem
RUN gem install bundler

這里只用到了很簡單的2個指令：FROM和RUN，FROM指定了我們要擴展的Image，RUN指定我們要運行的命令，這里是安裝ruby，gem、bundler等軟體。寫好Dockerfile後，運行以下指令就可以創建你的base image了：

1
2

docker build --rm -t dev:base .

-t 選項是你要構建的base image的tag，就好比ubuntu:13.10一樣 –rm 選項是告訴Docker在構建完成後刪除臨時的Container，Dockerfile的每一行指令都會創建一個臨時的Container，一般你是不需要這些臨時生成的Container的 如你所想，我們可以像運行ubuntu:13.10那樣運行我們的base了：

1
2

docker run -i -t --name ruby dev:base irb

這里我們使用dev:base這個Image運行了一個irb解釋器（Ruby的互動式解釋器）。 在構建完base之後，你可以依樣畫葫蘆構建你的rails環境，很簡單，只需要FROM dev:base，然後RUN安裝你的rails組件就可以了，不再贅述。最終你可能構建的開發環境是這樣的：

如上圖所示，base和service都是從ubutnu:13.10繼承而來，他們作為不同的基礎開發環境，base是ruby開發環境（也許命名為dev:ruby更為合適？），而service是一些基礎數據服務，例如mysql，memcache，我建議將這些第三方組件集中在一個Container中，因為他們的環境不經常修改，可以作為一種底層服務Container運行，除非你需要構建分布式的服務，例如memcache集群，那可以繼續拆分。
指定Image入口
當你構建完你的base Image和其他應用的Image之後，你就可以啟動這些Image了，還記得前面我們給出的運行命令嗎？

1
2

docker run -i -t --name shell dev:base /bin/bash

這里我們運行了一個bash，這樣你就可以在shell裡面執行你所想要執行的任何命令了，但是我們有時候並不想每次都啟動一個shell，接著再在shell裡面啟動我們的程序，比如一個mysql，而是想一啟動一個容器，mysql服務就自動運行了，這很簡單，Dockerfile提供了CMD和ENTRYPOINT這2個指令，允許你指定一個Image啟動時的默認命令。CMD和ENTRYPOINT的區別是CMD的參數可以由docker run指令指定的參數覆蓋，而ENTRYPOINT則不可以。例如我們想運行一個memcached服務，可以這么寫Dockerfile：

1
2
3

FROM ubuntu:13.10
RUN apt-get install -y memcached CMD memcached -u root -p 40000

或者可以這么寫：

1
2
3

FROM ubuntu:13.10
RUN apt-get install -y memcached ENTRYPOINT ["memcached", "-u", "root", "-p", "40000"]

注意不要把memcached啟動為後台進程，即加上-d選項，否則docker啟動的container會馬上stop掉，這點我也覺得比較意外。 接著我們build這個Image：

1
2

docker build -t dev:memcache .

這樣，當你build完你的Image後，你可以直接將該Image運行為一個容器，它會自動啟動mysql服務：

1
2

docker run --name memcache_service -d dev:memcache

注意使用-d (detach) 選項，這樣這個container就會作為後台進程運行了，接著你可以使用docker ps命令查看是否有在運行。
磁碟映射
大部分時候你會需要把你host主機（宿主）上的目錄映射到Container裡面，這樣你就非常方便地在host主機上編輯代碼，然後直接就可以在Container裡面運行它們，而不用手動到Container裡面再重啟Container。按理將host的目錄映射到guest（指Container）上應該是一件很容易的事情，就好像VMWare那樣，但可惜的是，由於Mac上的Docker多了一層虛擬機，因此多了一層周折，你必須先VM上的目錄通過sshfs mount到host（指Mac）上，然後再將你的目錄或文件到這個mount的目錄，再將VM上的這個目錄映射到Container里，聽起來比較拗口，畫個圖會清晰很多。

如上圖所示，VM裡面的/mnt/sda1/dev/目錄（你需要自己創建）通過sshfs命令mount到了host主機（Mac）的~/workspace/dev/目錄 ，而VM里的/mnt/sda1/dev/目錄又被映射到了Container的/src/目錄下，這樣你就可以在Container裡面的/src/目錄下訪問你的host文件了。具體如何做呢？首先你需要安裝sshfs命令，然後將VM的password寫到一個文件中，例如~/.boot2docker/b2d-passwd，在用sshfs命令mount起VM的/mnt/sda1/dev目錄：

1
2
3
4

brew install sshfs
cat tcuser > ~/.boot2docker/b2d-passwd
sshfs docker@localhost:/mnt/sda1/dev ~/workspace/dev -p 2022 -o reconnect -o password_stdin < ~/.boot2docker/b2d-passwd

接著你在run一個Container的時候需要通過-v選項來將/mnt/sda1/dev/映射到/src目錄：

1
2

docker run -i -t dev:base -v /mnt/sda1/dev:/src /bin/bash

這樣你就可以在你的Container的/src目錄下看到你host里的文件了。 磁碟映射還有2個地方需要注意：
你的文件實際上是存儲在VM裡面的，也就是說你需要將你的目錄或者文件到VM裡面，你sshfs之後，就是到~/workspace/dev目錄下
千萬不要sshfs mount非/mnt/sda1下的目錄，因為VM裡面跑的是TinyCoreLinux，這個OS的rootfs是臨時性的（放在內存的，實際上就是boot2docker.iso文件裡面的一個rootfs），因此其根目錄/下的東西（包括/home）根本不會持久化，只有/mnt/sda1這個目錄下的才能持久化。如果你放在/home目錄下，只要VM一重啟，就會丟失的，/mnt/sda1則不會，實際上就是那個~/.boot2docker-vm.vmdk文件掛載到了/mnt/sda1目錄下
埠映射
和磁碟映射一樣，你有時候會需要將Container的埠映射到host主機上，同樣蛋疼的是，由於多了一層VM，埠映射也顯得比較麻煩。首先你需要設置VirtualBox的埠映射，然後再將Container的埠映射到你的VM裡面：

具體是這么做的，通過2條命令：

1
2
3

boot2docker ssh -L 8000:localhost:8000
docker run -i -t -p 8000:8000

也就是說在docker run的時候通過-p選項指定要映射的埠到VM，而boot2docker ssh命令則是將VM的8000埠映射到了host(Mac)的8000埠，這樣你就可以通過Mac的localhost:8000訪問Container的8000埠了。 其實，有另一種解決方案就是你不用映射到host（Mac），而是直接登錄到VM裡面進行訪問就好了，boot2docker ssh就可以登錄到VM，這樣就類似於你的host是ubuntu，但這種解決方案的問題是這個ubuntu太弱了（TinyCoreLinux），如果你在這個ubuntu裡面開發代碼，或者是運行瀏覽器，是非常蛋疼的事情，關鍵還是這個ubuntu是每次重啟都會復原的！所以我建議還是做多一層映射好了。 最後，實際上在VM裡面，你是可以直接訪問所有的Container的埠的，因為VM到Container的網路都是橋接的。

⑽ Docker的主要作用是什麼

目前來看，Docker至少有以下應用場景：

1）測試：Docker 很適合用於測試發布，將 Docker 封裝後可以直接提供給測試人員進行運行，不再需要測試人員與運維、開發進行配合，進行環境搭建與部署。

2）測試數據分離：在測試中，經常由於測試場景變換，需要修改依賴的資料庫數據或者清空變動 memcache、Redis 中的緩存數據。Docker 相較於傳統的虛擬機，更輕量與方便。可以很容易的將這些數據分離到不同的鏡像中，根據不同需要隨時進行切換。

3）開發：開發人員共同使用同一個 Docker 鏡像，同時修改的源代碼都被掛載到本地磁碟。不再因為環境的不同而造成的不同程序行為而傷透腦筋，同時新人到崗時也能迅速建立開發、編譯環境。

4）PaaS 雲服務：Docker 可以支持命令行封裝與編程，通過自動載入與服務自發現，可以很方便的將封裝於 Docker 鏡像中的服務擴展成雲服務。類似像 Doc 轉換預覽這樣的服務封裝於鏡像中，根據業務請求的情況隨時增加和減少容器的運行數量，隨需應變。

具體到Docker技術在測試領域的應用，可以體現在：

1）快速搭建兼容性測試環境

從Docker的鏡像與容器技術特點可以預見，當被測應用要求在各類Web伺服器、中間件、資料庫的組合環境中得到充分驗證時，可以快速地利用基礎Docker鏡像創建各類容器，裝載相應的技術組件並快速啟動運行，測試人員省去了大量花在測試環境搭建上的時間。

2）快速搭建復雜分布式測試環境

Docker的輕量虛擬化特點決定了它可以在一台機器上（甚至是測試人員的一台筆記本電腦上）輕松搭建出成百上千個分布式節點的容器環境，從而模擬以前需要耗費大量時間和機器資源才能搭建出來的分布式復雜測試環境。

3）持續集成

Docker可以快速創建和撤銷容器，在持續集成的環境中，可以頻繁和快速地進行部署和驗證工作。