docker
作者：DevOps旭
來自：DevOps探路者
我們是一群軟件開發者，也是一群DevOps探路者，致力於學習和打造開源DevOps工具，解決企業內部的軟件開發過程中遇到的問題，如果你也和我們一樣，歡迎加入我們，或者你所在的企業遇到了軟件開發過程中的問題，也請告訴我們，我們和你一起解決！
一、初識docker debug模式
作為運維工程師，大家都十分熟悉，當服務運行出問題時，可以通過docker logs 或者是docker attach 來查看應用的日誌，這個給了管理員以很大的便利，但是，當docker引擎出問題時，如何去查看docker 引擎的日誌呢？
1、查看docker 引擎的日誌
docker引擎日誌查看還是比較方便的，特別是在linux引入了systemd後，可以通過journalctl -u docker.service來進行查看
<code>[root@VM-0-13-centos ~]# journalctl -u docker.service
-- Logs begin at Thu 2020-08-20 10:39:51 CST, end at Wed 2020-09-09 21:20:01 CST. --
Sep 09 20:52:42 VM-0-13-centos systemd[1]: Starting Docker Application Container Engine...
Sep 09 20:52:42 VM-0-13-centos dockerd[2892]: time="2020-09-09T20:52:42.628747216+08:00" level=info msg="Starting up"
Sep 09 20:52:42 VM-0-13-centos dockerd[2892]: time="2020-09-09T20:52:42.629590473+08:00" level=info msg="parsed scheme: "unix"" module=grpc
Sep 09 20:52:42 VM-0-13-centos dockerd[2892]: time="2020-09-09T20:52:42.629606252+08:00" level=info msg="scheme "unix" not registered, fallback to default scheme" module
Sep 09 20:52:42 VM-0-13-centos dockerd[2892]: time="2020-09-09T20:52:42.629625959+08:00" level=info msg="ccResolverWrapper: sending update to cc: {[{unix:///run/containerd
Sep 09 20:52:42 VM-0-13-centos dockerd[2892]: time="2020-09-09T20:52:42.629646468+08:00" level=info msg="ClientConn switching balancer to "pick_first"" module=grpc
Sep 09 20:52:42 VM-0-13-centos dockerd[2892]: time="2020-09-09T20:52:42.657116313+08:00" level=info msg="parsed scheme: "unix"" module=grpc
Sep 09 20:52:42 VM-0-13-centos dockerd[2892]: time="2020-09-09T20:52:42.657133475+08:00" level=info msg="scheme "unix" not registered, fallback to default scheme" module
Sep 09 20:52:42 VM-0-13-centos dockerd[2892]: time="2020-09-09T20:52:42.657154884+08:00" level=info msg="ccResolverWrapper: sending update to cc: {[{unix:///run/containerd
Sep 09 20:52:42 VM-0-13-centos dockerd[2892]: time="2020-09-09T20:52:42.657164342+08:00" level=info msg="ClientConn switching balancer to "pick_first"" module=grpc
Sep 09 20:52:42 VM-0-13-centos dockerd[2892]: time="2020-09-09T20:52:42.732941928+08:00" level=info msg="Loading containers: start."
Sep 09 20:52:43 VM-0-13-centos dockerd[2892]: time="2020-09-09T20:52:43.188311195+08:00" level=info msg="Default bridge (docker0) is assigned with an IP address 172.17.0.0
Sep 09 20:52:43 VM-0-13-centos dockerd[2892]: time="2020-09-09T20:52:43.272636641+08:00" level=info msg="Loading containers: done."
Sep 09 20:52:43 VM-0-13-centos dockerd[2892]: time="2020-09-09T20:52:43.302885191+08:00" level=info msg="Docker daemon" commit=48a66213fe graphdriver(s)=overlay2 version=1
Sep 09 20:52:43 VM-0-13-centos dockerd[2892]: time="2020-09-09T20:52:43.302965921+08:00" level=info msg="Daemon has completed initialization"
Sep 09 20:52:43 VM-0-13-centos dockerd[2892]: time="2020-09-09T20:52:43.351340496+08:00" level=info msg="API listen on /var/run/docker.sock"
Sep 09 20:52:43 VM-0-13-centos systemd[1]: Started Docker Application Container Engine.
Sep 09 21:07:00 VM-0-13-centos dockerd[2892]: time="2020-09-09T21:07:00.395367002+08:00" level=info msg="Processing signal 'terminated'"
Sep 09 21:07:00 VM-0-13-centos dockerd[2892]: time="2020-09-09T21:07:00.396811522+08:00" level=info msg="Daemon shutdown complete"/<code>可以看到docker啟動後所進行的一些行為
2、dockerd的日誌
當然了，除了docker引擎外，docker的守護進程dockerd的日誌也是很重要的，這個日誌可以在/var/log/message下看到
<code>[root@VM-0-13-centos ~]# cat /var/log/messages | grep docker
Aug 31 11:37:59 VM-0-13-centos java: #033[2m2020-08-31 11:37:59.147#033[0;39m #033[31mERROR#033[0;39m #033[35m15222#033[0;39m #033[2m---#033[0;39m #033[2m[ XNIO-1 task-9]#033[0;39m #033[36mio.undertow.request #033[0;39m #033[2m:#033[0;39m UT005023: Exception handling request to /docker/.env
Sep 5 23:14:52 VM-0-13-centos java: #033[2m2020-09-05 23:14:52.814#033[0;39m #033[32m INFO#033[0;39m #033[35m15222#033[0;39m #033[2m---#033[0;39m #033[2m[ XNIO-1 task-12]#033[0;39m #033[36mr.h.app.handler.file.LocalFileHandler #033[0;39m #033[2m:#033[0;39m Uploading file: [docker.jpg]to directory: [/root/.halo/upload/2020/09/docker-dfacc9d2b0444275b22298504b7f87b0.jpg]
Sep 5 23:14:52 VM-0-13-centos java: #033[2m2020-09-05 23:14:52.906#033[0;39m #033[32m INFO#033[0;39m #033[35m15222#033[0;39m #033[2m---#033[0;39m #033[2m[ XNIO-1 task-12]#033[0;39m #033[36mr.h.app.handler.file.LocalFileHandler #033[0;39m #033[2m:#033[0;39m Uploaded file: [docker.jpg] to directory: [/root/.halo/upload/2020/09/docker-dfacc9d2b0444275b22298504b7f87b0.jpg] successfully
Sep 9 20:51:36 VM-0-13-centos yum[2561]: Installed: 1:docker-ce-cli-19.03.12-3.el7.x86_64
Sep 9 20:51:55 VM-0-13-centos yum[2561]: Installed: 3:docker-ce-19.03.12-3.el7.x86_64
Sep 9 20:52:42 VM-0-13-centos dockerd: time="2020-09-09T20:52:42.628747216+08:00" level=info msg="Starting up"
Sep 9 20:52:42 VM-0-13-centos dockerd: time="2020-09-09T20:52:42.629590473+08:00" level=info msg="parsed scheme: "unix"" module=grpc
Sep 9 20:52:42 VM-0-13-centos dockerd: time="2020-09-09T20:52:42.629606252+08:00" level=info msg="scheme "unix" not registered, fallback to default scheme" module=grpc
Sep 9 20:52:42 VM-0-13-centos dockerd: time="2020-09-09T20:52:42.629625959+08:00" level=info msg="ccResolverWrapper: sending update to cc: {[{unix:///run/containerd/containerd.sock 0 }] }" module=grpc
Sep 9 20:52:42 VM-0-13-centos dockerd: time="2020-09-09T20:52:42.629646468+08:00" level=info msg="ClientConn switching balancer to "pick_first"" module=grpc
Sep 9 20:52:42 VM-0-13-centos dockerd: time="2020-09-09T20:52:42.657116313+08:00" level=info msg="parsed scheme: "unix"" module=grpc
Sep 9 20:52:42 VM-0-13-centos dockerd: time="2020-09-09T20:52:42.657133475+08:00" level=info msg="scheme "unix" not registered, fallback to default scheme" module=grpc
Sep 9 20:52:42 VM-0-13-centos dockerd: time="2020-09-09T20:52:42.657154884+08:00" level=info msg="ccResolverWrapper: sending update to cc: {[{unix:///run/containerd/containerd.sock 0 }] }" module=grpc
Sep 9 20:52:42 VM-0-13-centos dockerd: time="2020-09-09T20:52:42.657164342+08:00" level=info msg="ClientConn switching balancer to "pick_first"" module=grpc
Sep 9 20:52:42 VM-0-13-centos dockerd: time="2020-09-09T20:52:42.732941928+08:00" level=info msg="Loading containers: start."
Sep 9 20:52:43 VM-0-13-centos dockerd: time="2020-09-09T20:52:43.188311195+08:00" level=info msg="Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address"
Sep 9 20:52:43 VM-0-13-centos kernel: IPv6: ADDRCONF(NETDEV_UP): docker0: link is not ready
Sep 9 20:52:43 VM-0-13-centos dockerd: time="2020-09-09T20:52:43.272636641+08:00" level=info msg="Loading containers: done."
Sep 9 20:52:43 VM-0-13-centos dockerd: time="2020-09-09T20:52:43.302885191+08:00" level=info msg="Docker daemon" commit=48a66213fe graphdriver(s)=overlay2 version=19.03.12/<code>但是這裡的日誌僅有info級別的日誌，那麼當出現故障時，info日誌所能提供的信息不足以定位問題，那麼我們還有什麼方案嗎？
3、開啟debug模式
所幸docker提供了debug模式，我們可以通過以下方案開啟docker debug'模式
<code>[root@VM-0-13-centos ~]# vim /etc/docker/daemon.json
{
"debug": true
}
[root@VM-0-13-centos ~]# systemctl restart docker
[root@VM-0-13-centos ~]# cat /var/log/messages | grep docker
...
Sep 9 21:07:00 VM-0-13-centos dockerd: time="2020-09-09T21:07:00.601081289+08:00" level=debug msg="/usr/sbin/iptables, [--wait -t nat -C DOCKER -i docker0 -j RETURN]"
Sep 9 21:07:00 VM-0-13-centos dockerd: time="2020-09-09T21:07:00.601999104+08:00" level=debug msg="/usr/sbin/iptables, [--wait -t nat -I DOCKER -i docker0 -j RETURN]"
Sep 9 21:07:00 VM-0-13-centos dockerd: time="2020-09-09T21:07:00.603158551+08:00" level=debug msg="/usr/sbin/iptables, [--wait -D FORWARD -i docker0 -o docker0 -j DROP]"
Sep 9 21:07:00 VM-0-13-centos dockerd: time="2020-09-09T21:07:00.604079844+08:00" level=debug msg="/usr/sbin/iptables, [--wait -t filter -C FORWARD -i docker0 -o docker0 -j ACCEPT]"
Sep 9 21:07:00 VM-0-13-centos dockerd: time="2020-09-09T21:07:00.604982732+08:00" level=debug msg="/usr/sbin/iptables, [--wait -I FORWARD -i docker0 -o docker0 -j ACCEPT]"
Sep 9 21:07:00 VM-0-13-centos dockerd: time="2020-09-09T21:07:00.606151257+08:00" level=debug msg="/usr/sbin/iptables, [--wait -t filter -C FORWARD -i docker0 ! -o docker0 -j ACCEPT]"
Sep 9 21:07:00 VM-0-13-centos dockerd: time="2020-09-09T21:07:00.607341592+08:00" level=debug msg="/usr/sbin/iptables, [--wait -I FORWARD -i docker0 ! -o docker0 -j ACCEPT]"
Sep 9 21:07:00 VM-0-13-centos dockerd: time="2020-09-09T21:07:00.608580297+08:00" level=debug msg="/usr/sbin/iptables, [--wait -t nat -C PREROUTING -m addrtype --dst-type LOCAL -j DOCKER]"
Sep 9 21:07:00 VM-0-13-centos dockerd: time="2020-09-09T21:07:00.609383619+08:00" level=debug msg="/usr/sbin/iptables, [--wait -t nat -C PREROUTING -m addrtype --dst-type LOCAL -j DOCKER]"
Sep 9 21:07:00 VM-0-13-centos dockerd: time="2020-09-09T21:07:00.610942203+08:00" level=debug msg="/usr/sbin/iptables, [--wait -t nat -C OUTPUT -m addrtype --dst-type LOCAL -j DOCKER ! --dst 127.0.0.0/8]"
Sep 9 21:07:00 VM-0-13-centos dockerd: time="2020-09-09T21:07:00.612121918+08:00" level=debug msg="/usr/sbin/iptables, [--wait -t nat -C OUTPUT -m addrtype --dst-type LOCAL -j DOCKER ! --dst 127.0.0.0/8]"
Sep 9 21:07:00 VM-0-13-centos dockerd: time="2020-09-09T21:07:00.613059021+08:00" level=debug msg="/usr/sbin/iptables, [--wait -t filter -C FORWARD -o docker0 -j DOCKER]"
Sep 9 21:07:00 VM-0-13-centos dockerd: time="2020-09-09T21:07:00.613950006+08:00" level=debug msg="/usr/sbin/iptables, [--wait -I FORWARD -o docker0 -j DOCKER]"
Sep 9 21:07:00 VM-0-13-centos dockerd: time="2020-09-09T21:07:00.614886437+08:00" level=debug msg="/usr/sbin/iptables, [--wait -t filter -C FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT]"
Sep 9 21:07:00 VM-0-13-centos dockerd: time="2020-09-09T21:07:00.615944175+08:00" level=debug msg="/usr/sbin/iptables, [--wait -I FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT]"
Sep 9 21:07:00 VM-0-13-centos dockerd: time="2020-09-09T21:07:00.617012611+08:00" level=debug msg="/usr/sbin/iptables, [--wait -t filter -C FORWARD -j DOCKER-ISOLATION-STAGE-1]"
.../<code>可以看到debug模式下，iptables規則創建是非常清晰的，當然了，開啟debug的方式還是有很多的
<code>1、修改日誌級別為debug，這個方式不可以和開啟debug模式並存，會導致啟動失敗
vim /etc/docker/daemon.json
{
"log-level": "debug"
}
2、先停止docker，再執行如下命令
dockerd --log-level debug
dockerd -l debug /<code>可以說這是一個處理docker異常的利器，也幫助過我解決了很多的棘手問題。
二、docker一些高級命令的使用
1、docker系統狀態
1.1、docker system df
在上一篇章裡，我們認識了image，同時也認識了UnionFS這一文件系統，這也帶來一個問題，通過docker images無法真正認識到image使用了多少存儲空間
<code>[root@VM-0-13-centos ~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE nginx test b2ead77fc9af 16 seconds ago 141MB nginx latest 4bb46517cac3 3 weeks ago 133MB/<code>
通過nginx:latest鏡像創建nginx:test鏡像，通過docker images查看到的鏡像所佔空間總和為141+133 也就是274M，但事實真的如此嗎？我們可以看一下文件系統overlay2的空間，可以認為這個空間使用量近乎為images實際使用空間大小
<code>[root@VM-0-13-centos docker]# du -sh overlay2/ 149M overlay2//<code>
可以看到，僅有149M。而docker提供了docker system df命令可以看到docker的磁盤佔用
<code>[root@VM-0-13-centos docker]# docker system df TYPE TOTAL ACTIVE SIZE RECLAIMABLE Images 2 1 141MB 141MB (100%) Containers 1 0 1.114kB 1.114kB (100%) Local Volumes 0 0 0B 0B Build Cache 0 0 0B 0B/<code>
這裡清晰地展示了，空間使用為141M，這也為清理空間提供了度量的標準。
1.2、docker system events
除此之外，docker system還可以獲得docker的實時事件，我們打開兩個終端，並在一個終端內操作，而另一個終端內查看實時事件
<code>[root@VM-0-13-centos docker]# docker run -d nginx 7042ffd3c291150a0180e3879d9632ee82145d50662d581891ae21e2fcc67bf9 [root@VM-0-13-centos docker]# docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 7042ffd3c291 nginx "/docker-entrypoint.…" 37 seconds ago Up 36 seconds 80/tcp serene_villani 14476a7ee535 nginx "/docker-entrypoint.…" 49 minutes ago Exited (0) 31 minutes ago relaxed_bohr [root@VM-0-13-centos docker]# docker rm 14476a7ee535 14476a7ee535 [root@VM-0-13-centos docker]# docker stop 7042ffd3c291 7042ffd3c291 [root@VM-0-13-centos docker]# docker rm 7042ffd3c291 7042ffd3c291/<code>
<code>[root@VM-0-13-centos ~]# docker system events 2020-09-09T22:03:33.971697001+08:00 container create 7042ffd3c291150a0180e3879d9632ee82145d50662d581891ae21e2fcc67bf9 (image=nginx, maintainer=NGINX Docker Maintainers , name=serene_villani) 2020-09-09T22:03:34.000975395+08:00 network connect 1ac84996ba0384fba699dda0592047fcb66c1c2ca595fce3c21bc770e6bb50ef (container=7042ffd3c291150a0180e3879d9632ee82145d50662d581891ae21e2fcc67bf9, name=bridge, type=bridge) 2020-09-09T22:03:34.201250017+08:00 container start 7042ffd3c291150a0180e3879d9632ee82145d50662d581891ae21e2fcc67bf9 (image=nginx, maintainer=NGINX Docker Maintainers , name=serene_villani) 2020-09-09T22:04:28.694443162+08:00 container destroy 14476a7ee53502db003352d92acad1ba6646d2d8bbadd0651d8bc32e4421f687 (image=nginx, maintainer=NGINX Docker Maintainers , name=relaxed_bohr) 2020-09-09T22:06:03.281628948+08:00 container kill 7042ffd3c291150a0180e3879d9632ee82145d50662d581891ae21e2fcc67bf9 (image=nginx, maintainer=NGINX Docker Maintainers , name=serene_villani, signal=15) 2020-09-09T22:06:03.333752851+08:00 container die 7042ffd3c291150a0180e3879d9632ee82145d50662d581891ae21e2fcc67bf9 (exitCode=0, image=nginx, maintainer=NGINX Docker Maintainers , name=serene_villani) 2020-09-09T22:06:03.364630265+08:00 network disconnect 1ac84996ba0384fba699dda0592047fcb66c1c2ca595fce3c21bc770e6bb50ef (container=7042ffd3c291150a0180e3879d9632ee82145d50662d581891ae21e2fcc67bf9, name=bridge, type=bridge) 2020-09-09T22:06:03.404858530+08:00 container stop 7042ffd3c291150a0180e3879d9632ee82145d50662d581891ae21e2fcc67bf9 (image=nginx, maintainer=NGINX Docker Maintainers , name=serene_villani) 2020-09-09T22:06:09.933835238+08:00 container destroy 7042ffd3c291150a0180e3879d9632ee82145d50662d581891ae21e2fcc67bf9 (image=nginx, maintainer=NGINX Docker Maintainers , name=serene_villani)/<code>
當創建容器時，第一個事件為創建容器7042ffd3c291150a，第二個事件為鏈接網絡到容器7042ffd3c291150a，第三個事件為啟動容器7042ffd3c291150a，第四個事件為刪除容器14476a7ee53502db00，第五個事件為停止容器7042ffd3c291150a，第七個事件為容器死亡（用的die來描述），第八個事件為斷開7042ffd3c291150a的網絡連接，第九個事件為停止容器7042ffd3c291150a，第十個事件為刪除容器7042ffd3c291150a，這個命令可以獲取每一個，對於學習容器的業務邏輯，以及定位問題也是有著巨大的幫助的。
1.3、docker system prune
在上一篇章，我們通過docker images -f "dangling=true" 或者docker images prune -a來清理無用的鏡像，docker 還提供了docker system prune命令，我們可以看一下效果
<code>[root@VM-0-13-centos docker]# docker system prune WARNING! This will remove: - all stopped containers - all networks not used by at least one container - all dangling images - all dangling build cache /<code>
可以看到清理的十分徹底，包括停止的容器，未使用的網絡，dangling鏡像，還有dangling鏡像的緩存。不過這也代表命令很危險，特別是對於容器，謹慎使用，避免誤刪誤停止的容器。
1.4 、docker system info
這個和docker info相同，展示docker配置的信息
2、關於內核參數
在使用linux時，調優內核參數是我們經常做的事情，但是容器適合宿主機共享內核參數，這個就導致無法在容器內修改內核參數,針對這一問題，只能是通過啟動參數來進行修改
<code>[root@VM-0-13-centos ~]# docker run --help ... --sysctl map Sysctl options (default map[]) --ulimit ulimit Ulimit options (default []) .../<code>
之前就遇到過nginx的鏡像句柄數不夠，導致的訪問異常的慢，最終通過修改nginx啟動參數，優化句柄數後解決了此問題。
3、關於資源限值
容器在使用中有一個很重要的點，就是cgroup實現的資源隔離，將資源進行限制，實現資源利用最大化，docker在這個方面提供了豐富的參數供管理員使用
<code>[root@VM-0-13-centos ~]# docker run --help ... --cpu-period int Limit CPU CFS (Completely Fair Scheduler) period --cpu-quota int Limit CPU CFS (Completely Fair Scheduler) quota --cpu-rt-period int Limit CPU real-time period in microseconds --cpu-rt-runtime int Limit CPU real-time runtime in microseconds --device-read-bps list Limit read rate (bytes per second) from a device (default []) --device-read-iops list Limit read rate (IO per second) from a device (default []) --device-write-bps list Limit write rate (bytes per second) to a device (default []) --device-write-iops list Limit write rate (IO per second) to a device (default []) --memory bytes Memory limit --memory-reservation bytes Memory soft limit --memory-swap bytes Swap limit equal to memory plus swap: '-1' to enable unlimited swap .../<code>
資源限制在容器化內是十分重要的，首先避免某個容器因為死循環或其他原因導致資源使用率飆高，導致資源血崩，而使整個節點掛掉，使服務中斷。
4、關於鏡像倉庫
鏡像作為docker的部署包，給用戶帶來了便利，我們可以從docker hub或者是各大雲廠商的鏡像倉庫拉取我們需要的鏡像，但是出於項目的保密性，私有倉庫成為了各個公司所需求的一個工具，那麼私有倉庫又有哪些呢？
4.1、Docker Registry
Docker Registry是docker提供的一個鏡像倉庫，這個鏡像倉庫也是通過docker run的方式啟動。這一倉庫作為docker原生的Registry，繼承了容器這一輕量級的理念，整個鏡像僅有26.2MB，同時作為原生倉庫，將數據目錄打包後，可以在任何環境下部署此倉庫，為項目遷移帶來了極大的便利。但與此同時，Registry也犧牲了很多功能，存在巨大的劣勢，那就是，沒有ui，僅可以通過調用接口來進行操作，導致Registry在使用上存在巨大的門檻。
4.2、harbor
harbor 是vmware公司開源出來的鏡像倉庫，也是當前最為流行的私有倉庫，並且在2018年加入了CNCF成為孵化項目。harbor自身集成Core Service 、Job Service 、Admin Service 可以實現認證，倉庫管理，鏡像管理，項目管理，定時任務配置等等功能，還集成了鏡像掃描，鏡像同步，開源版高可用等諸多優勢，藉助於mysql，redis，公共存儲等，也可以實現harbor無狀態應用化，從而增強harbor集群的高併發能力。
4.3、nexus
nexus作為一個製品管理工具，支持docker鏡像管理，但是由於開源版不支持高可用，同時nexus又會集成maven私服，node私服等，導致nexus服務壓力過大，所以不太推薦。
4.4、jfrog
jfrog也是一個專門管理製品的工具，這一工具的優勢是支持全語言製品管理，但是不足在於需要購買商業版，開源版所能使用的功能太少，所以也不太推薦。
4.5、harbor高可用架構
4.5.1、方案一
架構圖如下
當鏡像構建完畢推送到harbor 的master節點後，可通過事件，將tag為SIT環境的鏡像同步到harbor的SIT節點上，實現為sit環境供給鏡像，當通過測試後，可觸發事件，調用API將tag為UAT的鏡像推送到harbor的UAT節點上，為UAT節點供給鏡像，當通過UAT測試後，可通過調用API將tag為production的鏡像推送到harbor的PRODUCTION節點（此節點最好為集群，以應對大規模集群）上，為生產環境供給鏡像。
2.5.2、方案二
架構圖如下
原理是通過本地倉庫的API獲取鏡像的元數據mainfest，拿到分層hash，之後校驗鏡像分層是否已經上傳到遠端倉庫，如果不存在，則推送到到遠端倉庫進行保存。
分享到:
