docker client發(fā)送容器管理請求后，由docker daemon接受并處理請求，當(dāng)docker client 接收到返回的請求相應(yīng)并簡單處理后，docker client 一次完整的生命周期就結(jié)束了，當(dāng)需要繼續(xù)發(fā)送容器管理請求時(shí)，用戶必須再次通過docker可以執(zhí)行文件創(chuàng)建docker client。

　　docker daemon 是docker架構(gòu)中一個常駐在后臺的系統(tǒng)進(jìn)程，功能是：接收處理docker client發(fā)送的請求。該守護(hù)進(jìn)程在后臺啟動一個server，server負(fù)載接受docker client發(fā)送的請求；接受請求后，server通過路由與分發(fā)調(diào)度，找到相應(yīng)的handler來執(zhí)行請求。

　　docker daemon啟動所使用的可執(zhí)行文件也為docker，與docker client啟動所使用的可執(zhí)行文件docker相同，在docker命令執(zhí)行時(shí)，通過傳入的參數(shù)來判別docker daemon與docker client。

　　docker daemon的架構(gòu)可以分為：docker server、engine、job。daemon

　　docker server在docker架構(gòu)中時(shí)專門服務(wù)于docker client的server，該server的功能時(shí)：接受并調(diào)度分發(fā)docker client發(fā)送的請求，架構(gòu)圖如下：

　　需要注意的是：Docker Server的運(yùn)行在Docker的啟動過程中，是靠一個名為”serveapi”的job的運(yùn)行來完成的。原則上，Docker Server的運(yùn)行是眾多job中的一個，但是為了強(qiáng)調(diào)Docker Server的重要性以及為后續(xù)job服務(wù)的重要特性，將該”serveapi”的job單獨(dú)抽離出來分析，理解為Docker Server。

　　Engine是Docker架構(gòu)中的運(yùn)行引擎，同時(shí)也Docker運(yùn)行的核心模塊。它扮演Docker container存儲倉庫的角色，并且通過執(zhí)行job的方式來操縱管理這些容器。

　　在Engine數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)與實(shí)現(xiàn)過程中，有一個handler對象。該handler對象存儲的都是關(guān)于眾多特定job的handler處理訪問。舉例說明，Engine的handler對象中有一項(xiàng)為：{“create”： daemon.ContainerCreate,}，則說明當(dāng)名為”create”的job在運(yùn)行時(shí)，執(zhí)行的是daemon.ContainerCreate的handler。

　　一個Job可以認(rèn)為是Docker架構(gòu)中Engine內(nèi)部最基本的工作執(zhí)行單元。Docker可以做的每一項(xiàng)工作，都可以抽象為一個job。例如：在容器內(nèi)部運(yùn)行一個進(jìn)程，這是一個job；創(chuàng)建一個新的容器，這是一個job，從Internet上下載一個文檔，這是一個job；包括之前在Docker Server部分說過的，創(chuàng)建Server服務(wù)于HTTP的API，這也是一個job，等等。

　　Job的設(shè)計(jì)者，把Job設(shè)計(jì)得與Unix進(jìn)程相仿。比如說：Job有一個名稱，有參數(shù)，有環(huán)境變量，有標(biāo)準(zhǔn)的輸入輸出，有錯誤處理，有返回狀態(tài)等。

　　Docker Registry是一個存儲容器鏡像的倉庫。而容器鏡像是在容器被創(chuàng)建時(shí)，被加載用來初始化容器的文件架構(gòu)與目錄。

　　在Docker的運(yùn)行過程中，Docker Daemon會與Docker Registry通信，并實(shí)現(xiàn)搜索鏡像、下載鏡像、上傳鏡像三個功能，這三個功能對應(yīng)的job名稱分別為”search”，”pull” 與 “push”。

　　其中，在Docker架構(gòu)中，Docker可以使用公有的Docker Registry，即大家熟知的Docker Hub，如此一來，Docker獲取容器鏡像文件時(shí)，必須通過互聯(lián)網(wǎng)訪問Docker Hub；同時(shí)Docker也允許用戶構(gòu)建本地私有的Docker Registry，這樣可以保證容器鏡像的獲取在內(nèi)網(wǎng)完成。

　　Graph在Docker架構(gòu)中扮演已下載容器鏡像的保管者，以及已下載容器鏡像之間關(guān)系的記錄者。一方面，Graph存儲著本地具有版本信息的文件系統(tǒng)鏡像，另一方面也通過GraphDB記錄著所有文件系統(tǒng)鏡像彼此之間的關(guān)系。

　　其中，GraphDB是一個構(gòu)建在SQLite之上的小型圖數(shù)據(jù)庫，實(shí)現(xiàn)了節(jié)點(diǎn)的命名以及節(jié)點(diǎn)之間關(guān)聯(lián)關(guān)系的記錄。它僅僅實(shí)現(xiàn)了大多數(shù)圖數(shù)據(jù)庫所擁有的一個小的子集，但是提供了簡單的接口表示節(jié)點(diǎn)之間的關(guān)系。

　　同時(shí)在Graph的本地目錄中，關(guān)于每一個的容器鏡像，具體存儲的信息有：該容器鏡像的元數(shù)據(jù)，容器鏡像的大小信息，以及該容器鏡像所代表的具體rootfs。

　　Driver是Docker架構(gòu)中的驅(qū)動模塊。通過Driver驅(qū)動，Docker可以實(shí)現(xiàn)對Docker容器執(zhí)行環(huán)境的定制。由于Docker運(yùn)行的生命周期中，并非用戶所有的操作都是針對Docker容器的管理，另外還有關(guān)于Docker運(yùn)行信息的獲取，Graph的存儲與記錄等。因此，為了將Docker容器的管理從Docker Daemon內(nèi)部業(yè)務(wù)邏輯中區(qū)分開來，設(shè)計(jì)了Driver層驅(qū)動來接管所有這部分請求。

　　在Docker Driver的實(shí)現(xiàn)中，可以分為以下三類驅(qū)動：graphdriver、networkdriver和execdriver。

　　graphdriver主要用于完成容器鏡像的管理，包括存儲與獲取。即當(dāng)用戶需要下載指定的容器鏡像時(shí)，graphdriver將容器鏡像存儲在本地的指定目錄；同時(shí)當(dāng)用戶需要使用指定的容器鏡像來創(chuàng)建容器的rootfs時(shí)，graphdriver從本地鏡像存儲目錄中獲取指定的容器鏡像。

　　在graphdriver的初始化過程之前，有4種文件系統(tǒng)或類文件系統(tǒng)在其內(nèi)部注冊，它們分別是aufs、btrfs、vfs和devmapper。而Docker在初始化之時(shí)，通過獲取系統(tǒng)環(huán)境變量”DOCKER_DRIVER”來提取所使用driver的指定類型。而之后所有的graph操作，都使用該driver來執(zhí)行。

　　networkdriver的用途是完成Docker容器網(wǎng)絡(luò)環(huán)境的配置，其中包括Docker啟動時(shí)為Docker環(huán)境創(chuàng)建網(wǎng)橋；Docker容器創(chuàng)建時(shí)為其創(chuàng)建專屬虛擬網(wǎng)卡設(shè)備；以及為Docker容器分配IP、端口并與宿主機(jī)做端口映射，設(shè)置容器防火墻策略等。networkdriver的架構(gòu)如下：

　　execdriver作為Docker容器的執(zhí)行驅(qū)動，負(fù)責(zé)創(chuàng)建容器運(yùn)行命名空間，負(fù)責(zé)容器資源使用的統(tǒng)計(jì)與限制，負(fù)責(zé)容器內(nèi)部進(jìn)程的真正運(yùn)行等。在execdriver的實(shí)現(xiàn)過程中，原先可以使用LXC驅(qū)動調(diào)用LXC的接口，來操縱容器的配置以及生命周期，而現(xiàn)在execdriver默認(rèn)使用native驅(qū)動，不依賴于LXC。具體體現(xiàn)在Daemon啟動過程中加載的ExecDriverflag參數(shù)，該參數(shù)在配置文件已經(jīng)被設(shè)為”native”。這可以認(rèn)為是Docker在1.2版本上一個很大的改變，或者說Docker實(shí)現(xiàn)跨平臺的一個先兆。execdriver架構(gòu)如下：

　　libcontainer是Docker架構(gòu)中一個使用Go語言設(shè)計(jì)實(shí)現(xiàn)的庫，設(shè)計(jì)初衷是希望該庫可以不依靠任何依賴，直接訪問內(nèi)核中與容器相關(guān)的API。

　　正是由于libcontainer的存在，Docker可以直接調(diào)用libcontainer，而最終操縱容器的namespace、cgroups、apparmor、網(wǎng)絡(luò)設(shè)備以及防火墻規(guī)則等。這一系列操作的完成都不需要依賴LXC或者其他包。libcontainer架構(gòu)如下：

　　另外，libcontainer提供了一整套標(biāo)準(zhǔn)的接口來滿足上層對容器管理的需求�；蛘哒f，libcontainer屏蔽了Docker上層對容器的直接管理。又由于libcontainer使用Go這種跨平臺的語言開發(fā)實(shí)現(xiàn)，且本身又可以被上層多種不同的編程語言訪問，因此很難說，未來的Docker就一定會緊緊地和Linux捆綁在一起。而于此同時(shí)，Microsoft在其著名云計(jì)算平臺Azure中，也添加了對Docker的支持，可見Docker的開放程度與業(yè)界的火熱度。

　　暫不談Docker，由于libcontainer的功能以及其本身與系統(tǒng)的松耦合特性，很有可能會在其他以容器為原型的平臺出現(xiàn)，同時(shí)也很有可能催生出云計(jì)算領(lǐng)域全新的項(xiàng)目。

　　Docker container（Docker容器）是Docker架構(gòu)中服務(wù)交付的最終體現(xiàn)形式。

　　vim /usr/lib/systemd/system/docker.service

　　[root@web1 ~]# vim /usr/lib/systemd/system/docker.service

　　[Unit]

　　Description=Docker Application Container Engine

　　Documentation=http://docs.docker.com

　　After=network.target

　　Wants=docker-storage-setup.service

　　Requires=docker-cleanup.timer

　　[Service]

　　Type=notify

　　NotifyAccess=main

　　EnvironmentFile=-/run/containers/registries.conf

　　EnvironmentFile=-/etc/sysconfig/docker

　　EnvironmentFile=-/etc/sysconfig/docker-storage

　　EnvironmentFile=-/etc/sysconfig/docker-network

　　Environment=GOTRACEBACK=crash

　　Environment=DOCKER_HTTP_HOST_COMPAT=1

　　Environment=PATH=/usr/libexec/docker:/usr/bin:/usr/sbin

　　ExecStart=/usr/bin/dockerd-current --registry-mirror=https://rfcod7oz.mirror.aliyuncs.com  #這個值可以登陸阿里云賬號請參考下圖

　　--add-runtime docker-runc=/usr/libexec/docker/docker-runc-current

　　--default-runtime=docker-runc

　　--exec-opt native.cgroupdriver=systemd

　　--userland-proxy-path=/usr/libexec/docker/docker-proxy-current

　　--init-path=/usr/libexec/docker/docker-init-current

　　--seccomp-profile=/etc/docker/seccomp.json

　　$OPTIONS

　　$DOCKER_STORAGE_OPTIONS

　　$DOCKER_NETWORK_OPTIONS

　　$ADD_REGISTRY

　　$BLOCK_REGISTRY

　　$INSECURE_REGISTRY

　　$REGISTRIES

　　ExecReload=/bin/kill -s HUP $MAINPID

　　LimitNOFILE=1048576

　　LimitNPROC=1048576

　　LimitCORE=infinity

　　TimeoutStartSec=0

　　Restart=on-abnormal

　　KillMode=process

　　[Install]

　　WantedBy=multi-user.target

　　[root@web1 ~]# docker version

　　Client:

　　Version:         1.13.1

　　API version:     1.26

　　Package version: docker-1.13.1-96.gitb2f74b2.el7.centos.x86_64

　　Go version:      go1.10.3

　　Git commit:      b2f74b2/1.13.1

　　Built:           Wed May  1 14:55:20 2019

　　OS/Arch:         linux/amd64

　　Server:

　　Version:         1.13.1

　　API version:     1.26 （minimum version 1.12）

　　Package version: docker-1.13.1-96.gitb2f74b2.el7.centos.x86_64

　　Go version:      go1.10.3

　　Git commit:      b2f74b2/1.13.1

　　Built:           Wed May  1 14:55:20 2019

　　OS/Arch:         linux/amd64

　　Experimental:    false

　　docker pull alpine　　　　　　　　　　#下載鏡像

　　docker search nginx　　　　　　　　　 #查看鏡像

　　docker pull nginx

　　[root@web1 ~]# docker images

　　REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE

　　zxg/my_nginx        v1                  b164f4c07c64        8 days ago          126 MB

　　zxg/my_nginx        latest              f07837869dfc        8 days ago          126 MB

　　docker.io/nginx     latest              e445ab08b2be        2 weeks ago         126 MB

　　docker.io/alpine    latest              b7b28af77ffe        3 weeks ago         5.58 MB

　　docker.io/centos    latest              9f38484d220f        4 months ago        202 MB

　　[root@web1 ~]#

　　docker  save nginx >/tmp/nginx.tar.gz

　　docker rmi -f nginx

　　docker load

　　

　　

　　

　　

　　

　　

　　

Welcome to nginx on Fedora!