Docker基礎概念與操作
基礎概念：
o 鏡像就像是一個可執行文件。
o 鏡像在倉庫註冊中心內被分門別類的存起來。
o 鏡像最終被放在每一個機器上，啓動爲一個個的容器。
鏡像：
因爲鏡像就像是一個可執行程序，所以，就會有一種約定的打包方式。Docker的守護程序就能按照這種格式，將程序啓動起來，變成一個個的容器。
既然鏡像是運行前的程序，它存在的地方和形式也有多種形式。我們可以知道，大概鏡像有如下的地方進行存在：
1、 倉庫內
2、 Docker管理的地方
3、 單獨的包，可以被複制和傳遞
鏡像存在的形式也是有不同：
1、 在倉庫內，和Docker管理的地方：鏡像是分層存儲的，以便進行管理；
2、 單獨的包，它被打成了一個tar包。
我們看看單獨的包，長的是什麼樣子：
google_containers-pause-2.0.tar.gz是一個k8s的基礎鏡像包，我們打開看看，
裏面是兩個目錄，每個目錄是一個層，這些層疊在一起就構成了一個目錄結構，也就是分層文件系統。我們看看每個層的內容。
每個層裏面有一個json文件，描述該層的信息：
另兩個就是真正的層數據文件，和版本文件。
我們再看看鏡像在Docker守護進程管理的目錄下，長什麼樣子：
cat /var/lib/docker/image/overlay/repositories.json
{
"Repositories": {
"quay.io/coreos/etcd": {
"quay.io/coreos/etcd:v3.0.15":"sha256:2bdf33352107013ee45d76ad4dd4bb6929b121688084b9a56be536706085f832",
"quay.io/coreos/etcd@sha256:aed90a29fbe7ad0e6629b2ea5a290f5b6efb9b719cec97c756df13f1db3760bf":"sha256:2bdf33352107013ee45d76ad4dd4bb6929b121688084b9a56be536706085f832"
}
}
}
可以看出，在Docker守護進程管理的目錄下，有一個詳細的Repository描述文件，每一個Repository都有一個名字，下面有具體的每一個版本的（tag）的信息。原來，無論是Docker鏡像倉庫，還是Docker的守護進程，都是以Repository爲單位，管理程序的。這裏的Repository，算是一個“倉庫”吧。
鏡像包內容本來是一個文件，導入到Docker守護進程內部後，就被放入倉庫描述文件中，打上標籤後，就可以用於啓動容器了。
單獨的鏡像文件沒有什麼直接的用途，必須納入Docker守護進程的管理體系才能進行後繼的操作，鏡像既可以直接連接遠程的註冊表，通過網絡下載到本地；也可以直接裝載進Docker的管理目錄內。一旦納入管理後，就可以使用如下的命令查看了：
容器：
容器是運行態的鏡像，所以運行的容器，本地一定有一個對應的鏡像存在，並額外疊加容器的一些數據。
一個鏡像可以啓動多個容器，所以，每次啓動都會建一個新的容器目錄。
啓動完容器後，可以使用如下命令查看：
停止容器：
停止後的容器，也可以查看到：
倉庫註冊中心：
倉庫註冊中心就是存儲鏡像的地方。爲了優化存儲效率，理論上倉庫註冊中心內也是按照分層存儲的。相同的層，互相引用就行了，不需要反覆存儲。
Docker在公網上運行了一個統一的倉庫註冊中心，叫做docerhub。全世界的開發者都可以使用這個中心來分發應用。
如果在內網上，不便於連接外部的docerhub來下載應用，可以使用docker公司提供的倉庫註冊中心的程序來自建一個倉庫註冊中心。
由於國內外的網速差別，還可以構建一些鏡像的倉庫註冊中心，這些鏡像的註冊中心定期的和dockerhub同步，然後大家就近的使用這些本地的倉庫註冊中心就能順利的下鏡像了。docker國內官方的合作伙伴是阿里，他也會提供類似的服務。
docker的守護進程負責通過合適的協議，將本地的鏡像分層的上傳到鏡像註冊中心，或者下載到本地。由於它能判斷本地是否已經有相同的層，所以從傳輸的角度來看，也是十分高效的。
倉庫註冊中心支持查詢操作，可以查詢是否存在需要的鏡像：
倉庫註冊中心好像並沒有提供類似網頁等上傳的能力，估計有如下原因：
1. 通信協議不高效，docker守護進程可以進行分層判斷，而web上傳只能一次性上傳所有的包，上傳完畢後再進行剃重，明顯效率不高。
2. 通常鏡像中都只有分層的數據，上傳上去後，倉庫的一些信息不完善，所以仍然需要告訴倉庫註冊中心。這兩個過程不太協調。
估計如果能開發一個web的插件，還能實現docker守護進程和倉庫註冊中心的通訊協議，應該能解決一些PaaS應用部署的易用性問題。