Docker簡介:
簡單來說，Docker鏡像是一個配置好了所需環境的操作系統，我們在自己的電腦上運行一個docker容器，相當於開啓了一個新的操作系統。比如說，如果我們在一臺windows系統的電腦上運行一個安裝了ubuntu系統的docker鏡像，就意味着我們可以進入一臺ubuntu系統的電腦進行操作。
Docker組成
一個完整的Docker有以下幾個部分組成：
- DockerClient客戶端
- Docker Daemon守護進程
- Docker Image鏡像
- DockerContainer容器
Docker架構：
Docker 使用客戶端-服務器 (C/S) 架構模式，使用遠程API來管理和創建Docker容器。Docker 容器通過 Docker 鏡像來創建。容器與鏡像的關係類似於面向對象編程中的對象與類。
| Docker | 面向對象 |
|---|---|
| 容器 | 對象 |
| 鏡像 | 類 |
- Docker採用 C/S架構 Docker daemon 作爲服務端接受來自客戶的請求，並處理這些請求（創建、運行、分發容器）。 客戶端和服務端既可以運行在一個機器上，也可通過 socket 或者RESTful API 來進行通信。
- Docker daemon 一般在宿主主機後臺運行，等待接收來自客戶端的消息。 Docker 客戶端則爲用戶提供一系列可執行命令，用戶用這些命令實現跟 Docker daemon 交互。
Docker典型場景
在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的好處:
環境隔離：Docker鏡像就像一個個的集裝箱，我們每一個“集裝箱”裏面運行的“系統環境”都是不一樣的，而且也是互不干擾的。舉個例子，其中一個“集裝箱”內運行的是基於“UBUNTU”系統內核的開發環境，另一個“集裝箱”內運行的是基於“CENTOS”系統內核的生產環境，然而這兩個“集裝箱”都可以運行在同一個“平臺”上，無論這個“平臺”是WINDOWS 還是 LINUX。
遷移方便： Docker將應用所需內容全部打包到一個容器中，然後在虛擬機、服務器或雲之間遷移該容器，而無需重構應用。
Docker侷限性：
-
Docker是基於Linux 64bit的，無法在32bit的linux/Windows/unix環境下使用
-
LXC是基於cgroup等linux kernel功能的，因此container的guest系統只能是linux base的
-
隔離性相比KVM之類的虛擬化方案還是有些欠缺，所有container公用一部分的運行庫
-
網絡管理相對簡單，主要是基於namespace隔離
-
container隨着用戶進程的停止而銷燬，container中的log等用戶數據不便收集
Docker對disk的管理比較有限
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 Hub(Docker 公共倉庫):
- Docker用Registry來保存用戶構建的鏡像。
- Registry分爲公有和私有。
- Docker公司運營的公共Registry叫做Docker Hub。用戶可以在Docker Hub註冊賬號，分享並保存自己的鏡像。
- Ucloud提供了一個免費的公共鏡像庫服務：Uhub
- UHub可以讓用戶自由創建和管理鏡像庫
Docker鏡像的命名規則:
- Docker鏡像是按照hub/registry/name:tag的規則進行命名的
- 其中hub即爲我們存儲docker鏡像使用的docker hub
- Registry是我們在docker hub中建立的倉庫
- Name是鏡像名稱
- Tag是鏡像的標籤
在Ucloud的Uhub中，hub內網地址爲uhub.service.ucloud.cn | 公網地址爲uhub.ucloud.cn
你可以在uhub中建立自己的鏡像倉庫，併爲其命名
Docker的存儲:
-
Docker 鏡像實際上由一層一層的文件系統組成，每一個layer都有其大小和ID，我們可以來看一個Ubuntu系統的鏡像。
-
由4個layer組成，是隻讀的
![在這裏插入圖片描述]()
鏡像可以通過分層來進行繼承，基於基礎鏡像，可以製作各種具體的應用鏡像。如果我們要基於這個ubuntu鏡像生成新的鏡像，也就是在這個ubuntu鏡像上面添加新的層。 -
多個鏡像可以共享低層layer
例：本機有一個ubuntu:15.04的鏡像，用戶基於該鏡像做了修改，如下圖，新的鏡像的低層會直接引用ubuntu15.04的鏡像。通過鏡像共享的方式，可以減少本機存儲空間，加快pull和push的速度。
![在這裏插入圖片描述]()
Docker鏡像與容器:
Docker鏡像是用於創建容器的模板，基於一個Docker鏡像可以創建許多個容器，每個容器之間相互獨立。在容器中進行的修改不會對鏡像產生影響。容器可以運行、停止和退出。
Docker容器的使用(映射外部端口)
使用 docker -p 就可以實現本服務器與容器之間的映射，從而實現外部網絡對容器的訪問
Docker的網絡模式：
使用docker run啓動容器時，可以通過 -p 參數設置本機端口與容器端口的映射。例如: docker run -p 3306:3306 mysql、
建立自己的Docker鏡像，使用Dockerfile文件進行打包
- 每一個命令都會在鏡像上創建一個新的層，每一個指令的前綴都必須是大寫
- FROM 指定使用的基礎鏡像
- EXPOSE 用來指定容器端口，使容器內的應用可以通過端口和外界交互
- RUN 接受命令作爲參數並用於創建鏡像
- ADD 將本地的./test/文件內容(相對路徑)添加到鏡像/data/下
- ENV 定義鏡像的環境變量
- CMD 用於執行特定的命令，在鏡像構建容器後被調用