1：為什么需要 DevOps ？
在當今，軟件開發公司在軟件新版本發布方面，多嘗試通過發布一系列以小的特性改變集為目標的新軟件版本，代替發布一個大特性改變集的新軟件版本的方式。這種方式有許多優點，諸如，快速的客戶反饋，軟件質量的保證等。也會獲得較高的客戶滿意度評價。完成這樣的軟件發布模式，開發公司需要做到：
- 增加軟件布署的頻率
- 降低新發布版本的失敗率
- 縮短修復缺陷的交付時間
- 加快解決版本沖突的問題
DevOps 滿足所有這些需求且幫助公司高質完成軟件無縫交付的目標
2： Docker 是什么？
Docker 是一個容器化平台，它包裝你所有開發環境依賴成一個整體，像一個容器。保證項目開發，如開發、測試、發布等各生產環節都可以無縫工作在不同的平台
Docker 容器：將一個軟件包裝在一個完整的文件系統中，該文件系統包含運行所需的一切：代碼，運行時，系統工具，系統庫等。可以安裝在服務器上的任何東西。
這保證軟件總是運行在相同的運行環境，無需考慮基礎環境配置的改變。
3: DevOps 有哪些優勢？
技術優勢:
- 持續的軟件交付能力
- 修復問題變得簡單
- 更快得解決問題
商業優勢:
- 更快交付的特性
- 更穩定的操作系統環境
- 更多時間可用於創造價值 (而不是修復 / 維護)
4：CI 服務有什么用途？
CI （Continuous Integration）-- 持續集成服務 -- 主要用於整合團隊開發中不同開發者提交到開發倉庫中的項目代碼變化，並即時整合編譯，檢查整合編譯錯誤的服務。它需要一天中多次整合編譯代碼的能力，若出現整合錯誤，可以優異地准確定位提交錯誤源。
5：如何使用 Docker 技術創建與環境無關的容器系統？
Docker 技術有三中主要的技術途徑輔助完成此需求：
- 存儲卷（Volumes）
- 環境變量（Environment variable）注入
- 只讀（Read-only）文件系統
6：Dockerfile 配置文件中的 COPY 和 ADD 指令有什么不同？
雖然 ADD 和 COPY 功能相似，推薦 COPY 。
那是因為 COPY 比 ADD 更直觀易懂。 COPY 只是將本地文件拷入容器這么簡單，而 ADD 有一些其它特性功能（諸如，本地歸檔解壓和支持遠程網址訪問等），這些特性在指令本身體現並不明顯。因此，有必要使用 ADD 指令的最好例子是需要在本地自動解壓歸檔文件到容器中的情況，如 ADD rootfs.tar.xz 。
7： Docker 映像（image）是什么？
Docker image 是 Docker 容器的源。換言之，Docker images 用於創建 Docker 容器（containers）。映像（Images）通過 Docker build 命令創建，當 run 映像時，它啟動成一個 容器（container）進程。 做好的映像由於可能非常龐大，常注冊存儲在諸如 registry.hub.docker.com 這樣的公共平台上。映像常被分層設計，每層可單獨成為一個小映像，由多層小映像再構成大映像，這樣碎片化的設計為了使映像在互聯網上共享時，最小化傳輸數據需求。
8： Docker 容器（container）是什么？
Docker containers -- Docker 容器 -- 是包含其所有運行依賴環境，但與其它容器共享操作系統內核的應用，它運行在獨立的主機操作系統用戶空間進程中。Docker 容器並不緊密依賴特定的基礎平台：可運行在任何配置的計算機，任何平台以及任何雲平台上。
9： Docker 中心（hub）什么概念？
Docker hub 是雲基礎的 Docker 注冊服務平台，它允許用戶進行訪問 Docker 中心資源庫，創建自己的 Docker 映像並測試，推送並存儲創建好的 Docker 映像，連接 Docker 雲平台將已創建好的指定 Docker 映像布署到本地主機等任務。它提供了一個查找發現 Docker 映像，發布 Docker 映像及控制變化升級的資源中心，成為用戶組或團隊協作開發中保證自動化開發流程的有效技術途徑。
10： 在任意給定時間點指出一個 Docker 容器可能存在的運行階段？
在任意時間點，一個 Docker 容器可能存在以下運行階段：
- 運行中（Running）
- 已暫停（Paused）
- 重啟中（Restarting）
- 已退出（Exited）
11： 有什么方法確定一個 Docker 容器運行狀態？
docker ps –a
這將列表形式輸出運行在主機上的所有 Docker 容器及其運行狀態。從這個列表中很容易找到想要的容器及其運行狀態。
12 ：在 Dockerfile 配置文件中最常用的指令有哪些？
一些最常用的指令如下：
FROM ：使用 FROM 為后續的指令建立基礎映像。在所有有效的 Dockerfile 中， FROM 是第一條指令。
LABEL： LABEL 指令用於組織項目映像，模塊，許可等。在自動化布署方面 LABEL 也有很大用途。在 LABEL 中指定一組鍵值對，可用於程序化配置或布署 Docker 。
RUN： RUN 指令可在映像當前層執行任何命令並創建一個新層，用於在映像層中添加功能層，也許最來的層會依賴它。
CMD： 使用 CMD 指令為執行的容器提供默認值。在 Dockerfile 文件中，若添加多個 CMD 指令，只有最后的 CMD 指令運行。
13： 什么類型的應用 - 無狀態性 或 有狀態性 - 的應用更適合 Docker 容器技術？
對於 Docker 容器創建無狀態性（Stateless）的應用更可取。通過從應用項目中將與狀態相關的信息及配置提取掉，我們可以在項目環境外建立不依賴項目環境的 Docker 容器。這樣，我們可以在任意產品中運行同一容器，只需根據產品需要像問 & 答（QA）一樣給其配置環境即可。 這幫助我們在不同場景重用相同的 Docker 映像。另外，使用 無狀態性（Stateless）容器應用相比有狀態性（Stateful）容器應用更具伸縮性，也容易創建。
14： 解釋基本 Docker 應用流程
初始，所有都有賴於 Dockerfile 配置文件。Dockerfile 配置文件就是創建 Docker image (映像) 的源代碼。
一旦 Dockerfile 配置好了，就可以創建（build）並生成 'image（映像）' ，'image' 就是 Dockerfile 配置文件中 「源代碼」的「編譯」版本。
一旦有了 'image' ，就可以在 registry（注冊中心） 發布它。 'registry' 類似 git 的資源庫 -- 你可以推送你的映像（image），也可取回庫中的映像（image）。
之后，你就可以使用 image 去啟動運行 'containers（容器）'。運行中的容器在許多方面，與虛擬機非常相似，但容器的運行不需要虛擬管理軟件的運行。
15： Docker Image 和 Docker Layer (層) 有什么不同？
Image ：一個 Docker Image 是由一系列 Docker 只讀層（read-only Layer） 創建出來的。
Layer： 在 Dockerfile 配置文件中完成的一條配置指令，即表示一個 Docker 層（Layer）。
如下 Dockerfile 文件包含 4 條指令，每條指令創建一個層（Layer）。
FROM ubuntu:15.04 COPY . /app RUN make /app CMD python /app/app.py
16：虛擬化技術是什么？
最初的構想，virtualisation（虛擬化） 被認為是邏輯划分大型主機使得多個應用可以並行運行的一種技術方案。然而，隨着技術公司及開源社區的推進，現實發生了戲劇性的轉變，以致產生了以一種或某種方式操作特權指令可以在單台基於 x86 硬件的系統上同時運行多個（種）操作系統的技術。
實質的效果是，虛擬化技術允許你在一個硬件平台下運行 2 個完全不同的操作系統。每個客戶操作系統可完成像系統自檢、啟動、載入系統內核等像在獨立硬件上的一切動作。同時也具備堅實的安全基礎，例如，客戶操作系統不能獲取完全訪問主機或其它客戶系統的權限，及其它涉及安全，可能把系統搞壞的操作。
基於對客戶操作系統虛擬硬件、運行環境模擬方法的不同，對虛擬化技術進行分類，主要的有如下 3 種虛擬化技術種類：
全模擬（Emulation）
半虛擬（Paravirtualization）
基於容器的虛擬化（Container-based virtualization）
17： 虛擬管理層（程序）是什么？
hypervisor -- 虛擬管理層（程序）-- 負責創建客戶虛擬機系統運行所需虛擬硬件環境。它監管客戶虛擬操作系統的運行，並為客戶系統提供必要的運行資源，保證客戶虛擬系統的運行。虛擬管理層（程序）駐留在物理主機系統和虛擬客戶系統之間，為虛擬客戶系統提供必要的虛擬服務。如何理解它，它偵聽運行在虛擬機中的客戶操作系統的操作並在主機操作系統中模擬客戶操作系統所需硬件資源請求。滿足客戶機的運行需求。
虛擬化技術的快速發展，主要在雲平台，由於在虛擬管理程序的幫助下，可允許在單台物理服務器上生成多個虛擬服務器，驅動着虛擬化技術快速發展及廣泛應用。諸如，Xen，VMware，KVM 等，以及商業化的處理器硬件生產廠商也加入在硬件層面支持虛擬化技術的支持。諸如，Intel 的 VT 和 AMD-V 。
18： Docker 群（Swarm）是什么？
Docker Swarm -- Docker 群 -- 是原生的 Docker 集群服務工具。它將一群 Docker 主機集成為單一一個虛擬 Docker 主機。利用一個 Docker 守護進程，通過標准的 Docker API 和任何完善的通訊工具，Docker Swarm 提供透明地將 Docker 主機擴散到多台主機上的服務。
19： 在使用 Docker 技術的產品中如何監控其運行？
Docker 在產品中提供如 運行統計和 Docker 事件的工具。可以通過這些工具命令獲取 Docker 運行狀況的統計信息或報告。
Docker stats ： 通過指定的容器 id 獲取其運行統計信息，可獲得容器對 CPU，內存使用情況等的統計信息，類似 Linux 系統中的 top 命令。
Docker events ：Docker 事件是一個命令，用於觀察顯示運行中的 Docker 一系列的行為活動。
一般的 Docker 事件有：attach（關聯），commit（提交），die（僵死），detach（取消關聯），rename（改名），destory（銷毀）等。也可使用多個選項對事件記錄篩選找到想要的事件信息。
20 ： 什么是孤兒卷及如何刪除它？
孤兒卷是未與任何容器關聯的卷。在 Docker v。1.9 之前的版本中，刪除這些孤兒卷存在很大問題。
21：什么是半虛擬化（Paravirtualization）？
Paravirtualization，也稱為第 1 類虛擬機管理（層）程序，其直接在硬件或 裸機（bare-metal）上運行，提供虛擬機直接使用物理硬件的服務，它幫助主機操作系統，虛擬化硬件和實際硬件進行協作以實現最佳性能。這種虛擬層管理技術的程序一般占用系統資源較小，其本身並不需要占用大量系統資源。
這種虛擬層管理程序有 Xen, KVM 等。
22：Docker 技術與虛擬機技術有何不同？
Docker 不是嚴格意義上的虛擬化硬件的技術。它依賴 container-based virtualization（基於容器的虛擬化） 的技術實現工具，或可以認為它是操作系統用戶運行級別的虛擬化。因此， Docker 最初使用 LXC 驅動它，后來移至由 libcontainer 基礎庫驅動它，現已更名為 runc 。 Docker 主要致力於應用容器內的應用程序的自動化部署。應用容器設計用於包裝和運行單一服務，而操作系統設計用於運行多進程任務，提供多種運算服務的能力。如虛擬機中等同完全操作系統的能力。因此，Docker 被認為是容器化系統上管理容器及應用容器化的布署工具。
與虛擬機不同，容器無需啟動操作系統內核，因此，容器可在不到 1 秒鍾時間內運行起來。這個特性，使得容器化技術比其它虛擬化技術更具有獨特性及可取性。
由於容器化技術很少或幾乎不給主機系統增加負載，因此，基於容器的虛擬化技術具有近乎原生的性能表現。
基於容器的虛擬化，與其他硬件虛擬化不同，運行時不需要其他額外的虛擬管理層軟件。
主機上的所有容器共享主機操作系統上的進程調度，從而節省了額外的資源的需求。
與虛擬機 image 相比，容器（Docker 或 LXC images）映像較小， 因此，容器映像易於分發。
容器中的資源分配由 Cgroups 實現。 Cgroup 不會讓容器占用比給它們分配的更多的資源。但是，現在其它的虛擬化技術，對於虛擬機，主機的所有資源都可見，但無法使用。這可以通過在容器和主機上同時運行 top 或 htop 來觀察到。在兩個環境中的輸出看起來相同。
23： 請解釋一下 docerfile 配置文件中的 ONBUILD 指令的用途含義？
配置文件中的 ONBUILD 指令為創建的 Docker image （映像）加入在將來執行的指令（譯注：在當前配置文件生成的映像中並不執行）， 用於在以這個創建的映像為基礎的創建的子映像（image） 中執行或定制。 舉例， 以基映像創建自己的映像時，可定制創建特有的用戶化的配置環境。
24： 有否在創建有狀態性的 Docker 應用的較好實踐？ 最適合的場景有什么？
有狀態性 Docker 應用的問題關鍵在於狀態數據保存在哪兒的問題。 若所有數據保存在容器內， 當更新軟件版本或想將 Docker 容器移到其它機器上時， 找回這些在運行中產生的狀態數據將非常困難。
您需要做的是將這些表達運行狀態的數據保存在永久卷中。參考如下 3 種模式。
譯注：
1 圖中文字： 數據保存在容器中，當容器停止運行時，運行狀態數據丟失！
2 圖中文字： 數據保存在主機卷（Host Volume）中，當主機停機時，運行狀態數據將無法訪問
3 圖中文字： 數據保存在網絡文件系統卷中，數據訪問不依賴容器的運行與主機的運行
若您使用：docker run -v hostFolder:/containerfolder 命令運行您的容器， 容器運行中任何對 /containerfolder 目錄下數據的改變， 將永久保存在主機的 hostfolder 目錄下。 使用網絡文件系統（nfs）與此類似。 那樣您就可以運行您的容器在任何主機上且其運行狀態數據被保存在網絡文件系統上。
25： 在 Windows 系統上可以運行原生的 Docker 容器嗎？
在 'Windows Server 2016' 系統上， 你可以運行 Windows 的原生容器， 微軟推出其映像是 'Windows Nano Server' ， 一個輕量級的運行在容器中的 Windows 原生系統。 您可以在其中布署基於 .NET 的應用。
問題 26： 在 非 Linux 操作系統平台上如何運行 Docker ?
容器化虛擬技術概念可能來源於，在 Linux 內核版本 2.6.24 上加入的對 命名空間（ namespace） 的技術支持特性。 容器化進程加入其進程 ID 到其創建的每個進程上並且對每個進程中的系統級調用進行訪問控制及審查。 其本身是由系統級調用 clone () 克隆出來的進程， 允許其創建屬於自己命名空間的進程實例，而區別於之前的，歸屬與整個本機系統的進程實例。
如果上述在 Linux 系統內核上的技術實現成為可能， 那么明顯的問題是如何在 非 Linux 系統上運行容器化的 Docker 。過去， Mac 和 Windows 系統上運行 Docker 容器都使用 Linux 虛擬機（VMs） 技術， Docker 工具箱使用的容器運行在 Virtual Box 虛擬機上。 現在，最新的情況是， Windows 平台上使用的是 Hyper-V 產品技術，Mac 平台上使用的是 Hypervisor.framework （框架）產品技術。
27： 容器化技術在底層的運行原理？
2006 年前后， 人們，包括一些谷歌的雇員， 在 Linux 內核級別上實現了一種新的名為 命名空間（namespace） 的技術（實際上這種概念在 FreeBSD 系統上由來已久）。我們知道，操作系統的一個功能就是進程共享公共資源， 諸如，網絡和硬盤空間等。 但是，如果一些公共資源被包裝在一個命名空間中， 只允許屬於這個命名空間中的進程訪問又如何呢？ 也就是說，可以分配一大塊硬盤空間給命名空間 X 供其使用，但是，命名空間 Y 中的進程無法看到或訪問這部分資源。 同樣地， 命名空間 Y 中分配的資源，命名空間 X 中的進程也無法訪問。當然， X 中的進程無法與 Y 中的進程進行交互。這提供了某種對公共資源的虛擬化和隔離的技術。
這就是 Docker 技術的底層工作原理： 每個容器運行在它自己的命名空間中，但是，確實與其它運行中的容器共用相同的系統內核。 隔離的產生是由於系統內核清楚地知道命名空間及其中的進程，且這些進程調用系統 API 時，內核保證進程只能訪問屬於其命名空間中的資源。
圖上文字說明： 運行中的容器是隔離的。准確地說， 各容器共享操作系統內核及操作系統 API
28： 說說容器化技術與虛擬化技術的優缺點
不能像虛擬機那樣在容器上運行與主機完全不同的操作系統。 然而， 可以在容器上運行不同的 Linux 發布版，由於容器共享系統內核的緣故。容器的隔離性沒有虛擬機那么健壯。事實上， 在早期容器化技術實現上，存在某種方法使客戶容器可接管整個主機系統。
也可看到，載入新容器並運行，並不會像虛擬機那樣裝載一個新的操作系統進來。
所有的容器共享同一系統內核， 這也就是容器被認為非常輕量化的原因。
同樣的原因，不像虛擬機， 你不須為容器預分配大量的內存空間， 因為它不是運行新的整個的操作系統。 這使得在一個操作系統主機上，可以同時運行成百上千個容器應用， 在運行完整操作系統的虛擬機上，進行這么多的並行沙箱實驗是不可能的。
29： 如何使 Docker 適應多種運行環境？
您必然想改變您的 Docker 應用配置以更適應現實運行環境的變化。下面包含一些修改建議：
移除應用代碼中對任何固定存儲卷的綁定，由於代碼駐留在容器內部，而不能從外部進行修正。
綁定應用端口到主機上的不同端口
差異化設置環境變量 （例如： 減少日志冗余或者使能發電子郵件）
設定重啟策略（例如： restart: always ）， 避免長時間宕機
加入額外的服務（例如： log aggregator）
由於以上原因， 您更需要一個 Compose 配置文件，大概叫 production.yml ，它配置了恰當的產品整合服務。 這個配置文件只需包含您選擇的合適的原始 Compose 配置文件中，你改動的部分。
docker-compose -f docker-com
30： 為什么 Docker compose 采取的是並不等待前面依賴服務項的容器啟動就緒后再啟動的組合容器啟動策略？
Docker 的 Compose 配置總是以依賴啟動序列來啟動或停止 Compose 中的服務容器， 依賴啟動序列是由 Compose 配置文件中的 depends_on ， links ， volumes_from 和 network_mode: "service : ..." 等這些配置指令所確定的。
然而， Compose 啟動中， 各容器的啟動並不等待其依賴容器（這必定是你整個應用中的某個依賴的服務或應用）啟動就緒后才啟動。使用這種策略較好的理由如下：
等待一個數據庫服務（舉例）就緒這樣的問題， 在大型分布式系統中僅是相比其它大問題的某些小問題。 在實際發布產品運維中， 您的數據庫服務會由於各種原因，或者遷移宿主機導致其不可訪問。 您發布的產品需要有應對這樣狀況的彈性。
掌控這些， 開發設計您的應用， 使其在訪問數據庫失效的情況下， 能夠試圖重連數據庫， 直至其連接到數據庫為止。
最佳的解決方案是在您的應用代碼中檢查是否有應對意外的發生，無論是任何原因導致的啟動或連接失效都應考慮在內。