如何遷移docker的存儲(chǔ)目錄

1Docker 遷移存儲(chǔ)目錄

默認(rèn)情況系統(tǒng)會(huì)將 Docker 容器存放在 /var/lib/docker 目錄下

[問題起因]今天通過監(jiān)控系統(tǒng)，發(fā)現(xiàn)公司其中一臺(tái)服務(wù)器的磁盤快慢，隨即上去看了下，發(fā)現(xiàn)/var/lib/docker這個(gè)目錄特別大。由上述原因，我們都知道，在/var/lib/docker中存儲(chǔ)的都是相關(guān)于容器的存儲(chǔ)，所以也不能隨便的將其刪除掉。

那就準(zhǔn)備遷移docker的存儲(chǔ)目錄吧，或者對(duì)/var設(shè)備進(jìn)行擴(kuò)容來達(dá)到相同的目的。更多關(guān)于dockerd的詳細(xì)參數(shù)，請點(diǎn)擊查看官方文檔地址。

但是需要注意的一點(diǎn)就是，盡量不要用軟鏈， 因?yàn)橐恍ヾocker容器編排系統(tǒng)不支持這樣做，比如我們所熟知的k8s就在內(nèi)。

#發(fā)現(xiàn)容器啟動(dòng)不了了
ERROR：cannot  create temporary directory!

#查看系統(tǒng)存儲(chǔ)情況
$du-h--max-depth=1

[解決方法 1] 添加軟鏈接

#1.停止docker服務(wù)
$sudosystemctlstopdocker

#2.開始遷移目錄
$sudomv/var/lib/docker/data/

#3.添加軟鏈接
$sudoln-s/data/docker/var/lib/docker

#4.啟動(dòng)docker服務(wù)
$sudosystemctlstartdocker

[解決方法 2] 改動(dòng) docker 配置文件

#[方式一]改動(dòng)docker啟動(dòng)配置文件
$sudovim/lib/systemd/system/docker.service
ExecStart=/usr/bin/dockerd--graph=/data/docker/

#[方式二]改動(dòng)docker啟動(dòng)配置文件
$sudovim/etc/docker/daemon.json
{
"live-restore":true,
"graph":["/data/docker/"]
}

[操作注意事項(xiàng)]在遷移docker目錄的時(shí)候注意使用的命令，要么使用mv命令直接移動(dòng)，要么使用cp命令復(fù)制文件，但是需要注意同時(shí)復(fù)制文件權(quán)限和對(duì)應(yīng)屬性，不然在使用的時(shí)候可能會(huì)存在權(quán)限問題。如果容器中，也是使用root用戶，則不會(huì)存在該問題，但是也是需要按照正確的操作來遷移目錄。

#使用mv命令
$sudomv/var/lib/docker/data/docker

#使用cp命令
$sudocp-arv/data/docker/data2/docker

下圖中，就是因?yàn)閱?dòng)的容器使用的是普通用戶運(yùn)行進(jìn)程的，且在運(yùn)行當(dāng)中需要使用/tmp目錄，結(jié)果提示沒有權(quán)限。在我們導(dǎo)入容器鏡像的時(shí)候，其實(shí)是會(huì)將容器啟動(dòng)時(shí)需要的各個(gè)目錄的權(quán)限和屬性都賦予了。如果我們直接是cp命令單純復(fù)制文件內(nèi)容的話，就會(huì)出現(xiàn)屬性不一致的情況，同時(shí)還會(huì)有一定的安全問題。

Docker遷移存儲(chǔ)目錄

2Docker 設(shè)備空間不足

Increase Docker container size from default 10GB on rhel7.

[問題起因一]容器在導(dǎo)入或者啟動(dòng)的時(shí)候，如果提示磁盤空間不足的，那么多半是真的因?yàn)槲锢泶疟P空間真的有問題導(dǎo)致的。如下所示，我們可以看到/分區(qū)確實(shí)滿了。

#查看物理磁盤空間
$df-Th
FilesystemSizeUsedAvailUse%Mountedon
/dev/vda140G40G0G100%/
tmpfs7.8G07.8G0%/dev/shm
/dev/vdb1493G289G179G62%/mnt

如果發(fā)現(xiàn)真的是物理磁盤空間滿了的話，就需要查看到底是什么占據(jù)了如此大的空間，導(dǎo)致因?yàn)槿萜鳑]有空間無法啟動(dòng)。其中，docker自帶的命令就是一個(gè)很好的能夠幫助我們發(fā)現(xiàn)問題的工具。

#查看基本信息
#硬件驅(qū)動(dòng)使用的是devicemapper，空間池為docker-252
#磁盤可用容量僅剩16.78MB，可用供我們使用
$dockerinfo
Containers:1
Images:28
StorageDriver:devicemapper
PoolName:docker-252:1-787932-pool
PoolBlocksize:65.54kB
BackingFilesystem:extfs
Datafile:/dev/loop0
Metadatafile:/dev/loop1
DataSpaceUsed:1.225GB
DataSpaceTotal:107.4GB
DataSpaceAvailable:16.78MB
MetadataSpaceUsed:2.073MB
MetadataSpaceTotal:2.147GB

[解決方法]通過查看信息，我們知道正是因?yàn)閐ocker可用的磁盤空間不足，所以導(dǎo)致啟動(dòng)的時(shí)候沒有足夠的空間進(jìn)行加載啟動(dòng)鏡像。解決的方法也很簡單，第一就是清理無效數(shù)據(jù)文件釋放磁盤空間(清除日志)，第二就是修改docker數(shù)據(jù)的存放路徑(大分區(qū))。

#顯示哪些容器目錄具有最大的日志文件
$du-d1-h/var/lib/docker/containers|sort-h

#清除您選擇的容器日志文件的內(nèi)容
$cat/dev/null>/var/lib/docker/containers/container_id/container_log_name

[問題起因二]顯然我遇到的不是上一種情況，而是在啟動(dòng)容器的時(shí)候，容器啟動(dòng)之后不久就顯示是unhealthy的狀態(tài)，通過如下日志發(fā)現(xiàn)，原來是復(fù)制配置文件啟動(dòng)的時(shí)候，提示磁盤空間不足。

后面發(fā)現(xiàn)是因?yàn)镃entOS7的系統(tǒng)使用的docker容器默認(rèn)的創(chuàng)建大小就是10G而已，然而我們使用的容器卻超過了這個(gè)限制，導(dǎo)致無法啟動(dòng)時(shí)提示空間不足。

2019-08-161115,816INFOspawned:'app-demo'withpid835
2019-08-161116,268INFOexited:app(exitstatus1;notexpected)
2019-08-161117,270INFOgaveup:appenteredFATALstate,toomanystartretriestooquickly
cp:cannotcreateregularfile'/etc/supervisor/conf.d/grpc-app-demo.conf':Nospaceleftondevice
cp:cannotcreateregularfile'/etc/supervisor/conf.d/grpc-app-demo.conf':Nospaceleftondevice
cp:cannotcreateregularfile'/etc/supervisor/conf.d/grpc-app-demo.conf':Nospaceleftondevice
cp:cannotcreateregularfile'/etc/supervisor/conf.d/grpc-app-demo.conf':Nospaceleftondevice

[解決方法 1] 改動(dòng) docker 啟動(dòng)配置文件

#/etc/docker/daemon.json
{
"live-restore":true,
"storage-opt":["dm.basesize=20G"]
}

[解決方法 2] 改動(dòng) systemctl 的 docker 啟動(dòng)文件

#1.stopthedockerservice
$sudosystemctlstopdocker

#2.rmexisedcontainer
$sudorm-rf/var/lib/docker

#2.edityourdockerservicefile
$sudovim/usr/lib/systemd/system/docker.service

#3.findtheexecutionline
ExecStart=/usr/bin/dockerd
andchangeitto:
ExecStart=/usr/bin/dockerd--storage-optdm.basesize=20G

#4.startdockerserviceagain
$sudosystemctlstartdocker

#5.reloaddaemon
$sudosystemctldaemon-reload

[問題起因三]還有一種情況也會(huì)讓容器無法啟動(dòng)，并提示磁盤空間不足，但是使用命令查看發(fā)現(xiàn)并不是因?yàn)槲锢泶疟P真的不足導(dǎo)致的。而是，因?yàn)閷?duì)于分區(qū)的inode節(jié)點(diǎn)數(shù)滿了導(dǎo)致的。

#報(bào)錯(cuò)信息
Nospaceleftondevice

[解決方法]因?yàn)閑xt3文件系統(tǒng)使用inode table存儲(chǔ)inode信息，而xfs文件系統(tǒng)使用B+ tree來進(jìn)行存儲(chǔ)。考慮到性能問題，默認(rèn)情況下這個(gè)B+ tree只會(huì)使用前1TB空間，當(dāng)這1TB空間被寫滿后，就會(huì)導(dǎo)致無法寫入inode信息，報(bào)磁盤空間不足的錯(cuò)誤。我們可以在mount時(shí)，指定inode64即可將這個(gè)B+ tree使用的空間擴(kuò)展到整個(gè)文件系統(tǒng)。

Docker+K8s+Jenkins 主流技術(shù)全解視頻資料【干貨免費(fèi)分享】

#查看系統(tǒng)的inode節(jié)點(diǎn)使用情況
$sudodf-i

#嘗試重新掛載
$sudomount-oremount-onoatime,nodiratime,inode64,nobarrier/dev/vda1

[補(bǔ)充知識(shí)]文件儲(chǔ)存在硬盤上，硬盤的最小存儲(chǔ)單位叫做扇區(qū)(Sector)。每個(gè)扇區(qū)儲(chǔ)存512字節(jié)(相當(dāng)于0.5KB)。操作系統(tǒng)讀取硬盤的時(shí)候，不會(huì)一個(gè)個(gè)扇區(qū)地讀取，這樣效率太低，而是一次性連續(xù)讀取多個(gè)扇區(qū)，即一次性讀取一個(gè)塊(block)。這種由多個(gè)扇區(qū)組成的塊，是文件存取的最小單位。塊的大小，最常見的是4KB，即連續(xù)八個(gè)sector組成一個(gè)block塊。文件數(shù)據(jù)都儲(chǔ)存在塊中，那么很顯然，我們還必須找到一個(gè)地方儲(chǔ)存文件的元信息，比如文件的創(chuàng)建者、文件的創(chuàng)建日期、文件的大小等等。這種儲(chǔ)存文件元信息的區(qū)域就叫做索引節(jié)點(diǎn)(inode)。每一個(gè)文件都有對(duì)應(yīng)的inode，里面包含了除了文件名以外的所有文件信息。

inode也會(huì)消耗硬盤空間，所以硬盤格式化的時(shí)候，操作系統(tǒng)自動(dòng)將硬盤分成兩個(gè)區(qū)域。一個(gè)是數(shù)據(jù)區(qū)，存放文件數(shù)據(jù)；另一個(gè)是inode區(qū)(inode table)，存放inode所包含的信息。每個(gè)inode節(jié)點(diǎn)的大小，一般是128字節(jié)或256字節(jié)。inode節(jié)點(diǎn)的總數(shù)，在格式化時(shí)就給定，一般是每1KB或每2KB就設(shè)置一個(gè)inode節(jié)點(diǎn)。

#每個(gè)節(jié)點(diǎn)信息的內(nèi)容
$statcheck_port_live.sh
File:check_port_live.sh
Size:225Blocks:8IOBlock:4096regularfile
Device:822h/2082dInode:99621663Links:1
Access:(0755/-rwxr-xr-x)Uid:(1006/escape)Gid:(1006/escape)
Access:2019-07-291459.498076903+0800
Modify:2019-07-291459.498076903+0800
Change:2019-07-292327.834866649+0800
Birth:-

#磁盤的inode使用情況
$df-i
FilesystemInodesIUsedIFreeIUse%Mountedon
udev16478355801164775541%/dev
tmpfs164876392521164851181%/run
/dev/sdc224416256047884362393741242%/
tmpfs164876395164876341%/dev/shm

3Docker 缺共享鏈接庫

Docker 命令需要對(duì)/tmp 目錄下面有訪問權(quán)限

[問題起因]給系統(tǒng)安裝完compose之后，查看版本的時(shí)候，提示缺少一個(gè)名為libz.so.1的共享鏈接庫。第一反應(yīng)就是，是不是系統(tǒng)少安裝那個(gè)軟件包導(dǎo)致的。隨即，搜索了一下，將相關(guān)的依賴包都給安裝了，卻還是提示同樣的問題。

#提示錯(cuò)誤信息
$docker-compose--version
errorwhileloadingsharedlibraries:libz.so.1:failedtomapsegmentfromsharedobject:Operationnotpermitted

[解決方法]后來發(fā)現(xiàn)，是因?yàn)橄到y(tǒng)中docker沒有對(duì)/tmp目錄的訪問權(quán)限導(dǎo)致，需要重新將其掛載一次，就可以解決了。

#重新掛載
$sudomount/tmp-oremount,exec

4Docker 容器文件損壞

對(duì) dockerd 的配置有可能會(huì)影響到系統(tǒng)穩(wěn)定

[問題起因]容器文件損壞，經(jīng)常會(huì)導(dǎo)致容器無法操作。正常的docker命令已經(jīng)無法操控這臺(tái)容器了，無法關(guān)閉、重啟、刪除。正巧，前天就需要這個(gè)的問題，主要的原因是因?yàn)橹匦聦?duì)docker的默認(rèn)容器進(jìn)行了重新的分配限制導(dǎo)致的。

#操作容器遇到類似的錯(cuò)誤
b'devicemapper:ErrorrunningdeviceCreate(CreateSnapDeviceRaw)dm_task_runfailed'

[解決方法]可以通過以下操作將容器刪除/重建。

#1.關(guān)閉docker
$sudosystemctlstopdocker

#2.刪除容器文件
$sudorm-rf/var/lib/docker/containers

#3.重新整理容器元數(shù)據(jù)
$sudothin_check/var/lib/docker/devicemapper/devicemapper/metadata
$sudothin_check--clear-needs-check-flag/var/lib/docker/devicemapper/devicemapper/metadata

#4.重啟docker
$sudosystemctlstartdocker

5Docker 容器優(yōu)雅重啟

不停止服務(wù)器上面運(yùn)行的容器，重啟 dockerd 服務(wù)是多么好的一件事

[問題起因]默認(rèn)情況下，當(dāng)Docker守護(hù)程序終止時(shí)，它會(huì)關(guān)閉正在運(yùn)行的容器。從Docker-ce 1.12開始，可以在配置文件中添加live-restore參數(shù)，以便在守護(hù)程序變得不可用時(shí)容器保持運(yùn)行。需要注意的是Windows平臺(tái)暫時(shí)還是不支持該參數(shù)的配置。

#Keepcontainersaliveduringdaemondowntime
$sudovim/etc/docker/daemon.yaml
{
"live-restore":true
}

#在守護(hù)進(jìn)程停機(jī)期間保持容器存活
$sudodockerd--live-restore

#只能使用reload重載
#相當(dāng)于發(fā)送SIGHUP信號(hào)量給dockerd守護(hù)進(jìn)程
$sudosystemctlreloaddocker

#但是對(duì)應(yīng)網(wǎng)絡(luò)的設(shè)置需要restart才能生效
$sudosystemctlrestartdocker

[解決方法]可以通過以下操作將容器刪除/重建。

#/etc/docker/daemon.yaml
{
"registry-mirrors":["https://vec0xydj.mirror.aliyuncs.com"],#配置獲取官方鏡像的倉庫地址
"experimental":true,#啟用實(shí)驗(yàn)功能
"default-runtime":"nvidia",#容器的默認(rèn)OCI運(yùn)行時(shí)(默認(rèn)為runc)
"live-restore":true,#重啟dockerd服務(wù)的時(shí)候容易不終止
"runtimes":{#配置容器運(yùn)行時(shí)
"nvidia":{
"path":"/usr/bin/nvidia-container-runtime",
"runtimeArgs":[]
}
},
"default-address-pools":[#配置容器使用的子網(wǎng)地址池
{
"scope":"local",
"base":"172.17.0.0/12",
"size":24
}
]
}

$vim/etc/docker/daemon.json
{
"default-address-pools":[
{
"base":"172.240.0.0/16",
"size":24
}
]
}

6Docker 容器無法刪除

找不到對(duì)應(yīng)容器進(jìn)程是最嚇人的

[問題起因]今天遇到docker容器無法停止/終止/刪除，以為這個(gè)容器可能又出現(xiàn)了dockerd守護(hù)進(jìn)程托管的情況，但是通過ps -ef 無法查到對(duì)應(yīng)的運(yùn)行進(jìn)程。哎，后來開始開始查supervisor以及Dockerfile中的進(jìn)程，都沒有。這種情況的可能原因是容器啟動(dòng)之后，主機(jī)因任何原因重新啟動(dòng)并且沒有優(yōu)雅地終止容器。剩下的文件現(xiàn)在阻止你重新生成舊名稱的新容器，因?yàn)橄到y(tǒng)認(rèn)為舊容器仍然存在。

#刪除容器
$sudodockerrm-ff8e8c3..
Errorresponsefromdaemon:Conflict,cannotremovethedefaultnameofthecontainer

[解決方法]找到/var/lib/docker/containers/下的對(duì)應(yīng)容器的文件夾，將其刪除，然后重啟一下dockerd即可。我們會(huì)發(fā)現(xiàn)，之前無法刪除的容器沒有了。

#刪除容器文件
$sudorm-rf/var/lib/docker/containers/f8e8c3...65720

#重啟服務(wù)
$sudosystemctlrestartdocker.service

7Docker 容器中文異常

容器存在問題話，記得優(yōu)先在官網(wǎng)查詢

[問題起因]今天登陸之前部署的MySQL數(shù)據(jù)庫查詢，發(fā)現(xiàn)使用SQL語句無法查詢中文字段，即使直接輸入中文都沒有辦法顯示。

#查看容器支持的字符集
root@b18f56aa1e15:#locale-a
C
C.UTF-8
POSIX

[解決方法]Docker部署的MySQL系統(tǒng)使用的是POSIX字符集。然而POSIX字符集是不支持中文的，而C.UTF-8是支持中文的只要把系統(tǒng)中的環(huán)境LANG改為"C.UTF-8"格式即可解決問題。同理，在K8S進(jìn)入pod不能輸入中文也可用此方法解決。

#臨時(shí)解決
dockerexec-itsome-mysqlenvLANG=C.UTF-8/bin/bash

#永久解決
dockerrun--namesome-mysql
-eMYSQL_ROOT_PASSWORD=my-secret-pw
-dmysql:tag--character-set-server=utf8mb4
--collation-server=utf8mb4_unicode_ci

8Docker 容器網(wǎng)絡(luò)互通

了解 Docker 的四種網(wǎng)絡(luò)模型

[問題起因]在本機(jī)部署Nginx容器想代理本機(jī)啟動(dòng)的Python后端服務(wù)程序，但是對(duì)代碼服務(wù)如下的配置，結(jié)果訪問的時(shí)候一直提示502錯(cuò)誤。

#啟動(dòng)Nginx服務(wù)
$dockerrun-d-p80:80$PWD:/etc/nginxnginx

server{
...
location/api{
proxy_passhttp://localhost:8080
}
...
}

[解決方法]后面發(fā)現(xiàn)是因?yàn)閚ginx.conf配置文件中的localhost配置的有問題，由于Nginx是在容器中運(yùn)行，所以localhost為容器中的localhost，而非本機(jī)的localhost，所以導(dǎo)致無法訪問。

可以將nginx.conf中的localhost改為宿主機(jī)的IP地址，就可以解決502的錯(cuò)誤。

#查詢宿主機(jī)IP地址=>172.17.0.1
$ipaddrshowdocker0
docker0:mtu1500qdiscnoqueuestateUPgroupdefault
link/ether02d5f2:1ebrdffffff:ff
inet172.17.0.1/16scopeglobaldocker0
valid_lftforeverpreferred_lftforever
inet6fe80:d5fff21e/64scopelink
valid_lftforeverpreferred_lftforever

server{
...
location/api{
proxy_passhttp://172.17.0.1:8080
}
...
}

當(dāng)容器使用host網(wǎng)絡(luò)時(shí)，容器與宿主共用網(wǎng)絡(luò)，這樣就能在容器中訪問宿主機(jī)網(wǎng)絡(luò)，那么容器的localhost就是宿主機(jī)的localhost了。

#服務(wù)的啟動(dòng)方式有所改變(沒有映射出來端口)
#因?yàn)楸旧砼c宿主機(jī)共用了網(wǎng)絡(luò)，宿主機(jī)暴露端口等同于容器中暴露端口
$dockerrun-d-p80:80--network=host$PWD:/etc/nginxnginxx

9Docker 容器總線錯(cuò)誤

總線錯(cuò)誤看到的時(shí)候還是挺嚇人了

[問題起因]在docker容器中運(yùn)行程序的時(shí)候，提示bus error錯(cuò)誤。

#總線報(bào)錯(cuò)
$invapp.user_op--name=zhangsan
Buserror(coredumped)

[解決方法]原因是在docker運(yùn)行的時(shí)候，shm分區(qū)設(shè)置太小導(dǎo)致share memory不夠。不設(shè)置--shm-size參數(shù)時(shí)，docker給容器默認(rèn)分配的shm大小為64M，導(dǎo)致程序啟動(dòng)時(shí)不足。具體原因還是因?yàn)榘惭bpytorch包導(dǎo)致了，多進(jìn)程跑任務(wù)的時(shí)候，docker容器分配的共享內(nèi)存太小，導(dǎo)致torch要在tmpfs上面放模型數(shù)據(jù)用于子線程的 共享不足，就出現(xiàn)報(bào)錯(cuò)了。

#問題原因
root@18...35:/opt/app#df-TH
FilesystemTypeSizeUsedAvailUse%Mountedon
overlayoverlay2.0T221G1.4T3%/
tmpfstmpfs68M068M0%/dev
shmtmpfs68M41k68M1%/dev/shm

#啟動(dòng)docker的時(shí)候加上--shm-size參數(shù)(單位為b,k,m或g)
$dockerrun-it--rm--shm-size=200mpytorch/pytorch:latest

#在docker-compose添加對(duì)應(yīng)配置
$shm_size:'2gb'

[解決方法]還有一種情況就是容器內(nèi)的磁盤空間不足，也會(huì)導(dǎo)致bus error這樣的報(bào)錯(cuò)，所以如果出現(xiàn)了，清除多余文件和目錄或者分配一個(gè)大的磁盤空間，就可以解決了。

#磁盤空間不足
$df-Th
FilesystemTypeSizeUsedAvailUse%Mountedon
overlayoverlay1T1T0G100%/
shmtmpfs64M24K64M1%/dev/shm

10Docker NFS 掛載報(bào)錯(cuò)

NFS 掛載之后容器程序使用異常為內(nèi)核版本太低導(dǎo)致的

[問題起因]我們將服務(wù)部署到openshift集群中，啟動(dòng)服務(wù)調(diào)用資源文件的時(shí)候，報(bào)錯(cuò)信息如下所示。從報(bào)錯(cuò)信息中，得知是在Python3程序執(zhí)行read_file()讀取文件的內(nèi)容，給文件加鎖的時(shí)候報(bào)錯(cuò)了。但是奇怪的是，本地調(diào)試的時(shí)候發(fā)現(xiàn)服務(wù)都是可以正常運(yùn)行的，文件加鎖也是沒問題的。后來發(fā)現(xiàn)，在openshift集群中使用的是NFS掛載的共享磁盤。

#報(bào)錯(cuò)信息
Traceback(mostrecentcalllast):
......
File"xxx/utils/storage.py",line34,inxxx.utils.storage.LocalStorage.read_file
OSError:[Errno9]Badfiledescriptor

#文件加鎖代碼
...
withopen(self.mount(path),'rb')asfileobj:
fcntl.flock(fileobj,fcntl.LOCK_EX)
data=fileobj.read()
returndata
...

[解決方法]從下面的信息得知，要在Linux中使用flock()的話，就需要升級(jí)內(nèi)核版本到2.6.11+才行。后來才發(fā)現(xiàn)，這實(shí)際上是由RedHat內(nèi)核中的一個(gè)錯(cuò)誤引起的，并在kernel-3.10.0-693.18.1.el7版本中得到修復(fù)。所以對(duì)于NFSv3和NFSv4服務(wù)而已，就需要升級(jí)Linux內(nèi)核版本才能夠解決這個(gè)問題。

#https://t.codebug.vip/questions-930901.htm
$InLinuxkernelsupto2.6.11,flock()doesnotlockfilesoverNFS(i.e.,
thescopeoflockswaslimitedtothelocalsystem).[...]SinceLinux2.6.12,
NFSclientssupportflock()locksbyemulatingthemasbyte-rangelocksontheentirefile.

11Docker 使用默認(rèn)網(wǎng)段

啟動(dòng)的容器網(wǎng)絡(luò)無法相互通信，很是奇怪！

[問題起因]我們在使用Docker啟動(dòng)服務(wù)的時(shí)候，發(fā)現(xiàn)有時(shí)候服務(wù)之前可以相互連通，而有時(shí)啟動(dòng)的多個(gè)服務(wù)之前卻出現(xiàn)了無法訪問的情況。究其原因，發(fā)現(xiàn)原來是因?yàn)槭褂玫膬?nèi)部私有地址網(wǎng)段不一致導(dǎo)致的。有的服務(wù)啟動(dòng)到了172.17 - 172.31的網(wǎng)段，有的服務(wù)跑到了192.169.0 - 192.168.224的網(wǎng)段，這樣導(dǎo)致服務(wù)啟動(dòng)之后出現(xiàn)無法訪問的情況(默認(rèn)情況下，有下面這個(gè)兩個(gè)網(wǎng)段可供其使用)。

Docker默認(rèn)使用網(wǎng)段

[解決方法]上述問題的處理方式，就是手動(dòng)指定Docker服務(wù)的啟動(dòng)網(wǎng)段，二選一就可以了。

#查看docker容器配置
$cat/etc/docker/daemon.json
{
"registry-mirrors":["https://vec0xydj.mirror.aliyuncs.com"],
"default-address-pools":[{"base":"172.17.0.0/12","size":24}],
"experimental":true,
"default-runtime":"nvidia",
"live-restore":true,
"runtimes":{
"nvidia":{
"path":"/usr/bin/nvidia-container-runtime",
"runtimeArgs":[]
}
}
}

12Docker 服務(wù)啟動(dòng)串臺(tái)

使用 docker-compose 命令各自啟動(dòng)兩組服務(wù)，發(fā)現(xiàn)服務(wù)會(huì)串臺(tái)！

[問題起因]在兩個(gè)不同名稱的目錄目錄下面，使用docker-compose來啟動(dòng)服務(wù)，發(fā)現(xiàn)當(dāng)A組服務(wù)啟動(dòng)完畢之后，再啟動(dòng)B組服務(wù)的時(shí)候，發(fā)現(xiàn)A組當(dāng)中對(duì)應(yīng)的一部分服務(wù)又重新啟動(dòng)了一次，這就非常奇怪了！因?yàn)檫@個(gè)問題的存在會(huì)導(dǎo)致，A組服務(wù)和B組服務(wù)無法同時(shí)啟動(dòng)。之前還以為是工具的Bug，后來請教了“上峰”，才知道了原因，恍然大悟。

#服務(wù)目錄結(jié)構(gòu)如下所示
A:/data1/app/docker-compose.yml
B:/data2/app/docker-compose.yml

[解決方法]發(fā)現(xiàn)A和B兩組服務(wù)會(huì)串臺(tái)的原因，原來是docker-compose會(huì)給啟動(dòng)的容器加label標(biāo)簽，然后根據(jù)這些label標(biāo)簽來識(shí)別和判斷對(duì)應(yīng)的容器服務(wù)是由誰啟動(dòng)的、誰來管理的，等等。而這里，我們需要關(guān)注的label變量是com.docker.compose.project，其對(duì)應(yīng)的值是使用啟動(dòng)配置文件的目錄的最底層子目錄名稱，即上面的app就是對(duì)應(yīng)的值。我們可以發(fā)現(xiàn)，A和B兩組服務(wù)對(duì)應(yīng)的值都是app，所以啟動(dòng)的時(shí)候被認(rèn)為是同一個(gè)，這就出現(xiàn)了上述的問題。如果需要深入了解的話，可以去看對(duì)應(yīng)源代碼。

Docker服務(wù)啟動(dòng)串臺(tái)

#可以將目錄結(jié)構(gòu)調(diào)整為如下所示
A:/data/app1/docker-compose.yml
B:/data/app2/docker-compose.yml

A:/data1/app-old/docker-compose.yml
B:/data2/app-new/docker-compose.yml

或者使用docker-compose命令提供的參數(shù)-p手動(dòng)指定標(biāo)簽，來規(guī)避該問題的發(fā)生。

#指定項(xiàng)目項(xiàng)目名稱
$docker-compose-f./docker-compose.yml-papp1up-d

13Docker 命令調(diào)用報(bào)錯(cuò)

在編寫腳本的時(shí)候常常會(huì)執(zhí)行 docker 相關(guān)的命令，但是需要注意使用細(xì)節(jié)！

[問題起因]CI更新環(huán)境執(zhí)行了一個(gè)腳本，但是腳本執(zhí)行過程中報(bào)錯(cuò)了，如下所示。通過對(duì)應(yīng)的輸出信息，可以看到提示說正在執(zhí)行的設(shè)備不是一個(gè)tty。

Docker命令調(diào)用報(bào)錯(cuò)

隨即，查看了腳本發(fā)現(xiàn)報(bào)錯(cuò)地方是執(zhí)行了一個(gè)exec的docker命令，大致如下所示。很奇怪的是，手動(dòng)執(zhí)行或直接調(diào)腳本的時(shí)候，怎么都是沒有問題的，但是等到CI調(diào)用的時(shí)候怎么都是有問題。后來好好看下，下面這個(gè)命令，注意到-it這個(gè)參數(shù)了。

#腳本調(diào)用docker命令
dockerexec-itpsql-Upostgres......

我們可以一起看下exec命令的這兩個(gè)參數(shù)，自然就差不多理解了。

編號(hào)	參數(shù)	解釋說明
1	-i/-interactive	即使沒有附加也保持 STDIN 打開；如果你需要執(zhí)行命令則需要開啟這個(gè)選項(xiàng)
2	-t/–tty	分配一個(gè)偽終端進(jìn)行執(zhí)行；一個(gè)連接用戶的終端與容器 stdin 和 stdout 的橋梁

[解決方法]docker exec的參數(shù)-t是指Allocate a pseudo-TTY的意思，而CI在執(zhí)行job的時(shí)候并不是在TTY終端中執(zhí)行，所以-t這個(gè)參數(shù)會(huì)報(bào)錯(cuò)。同時(shí)在 『stackoverflow』也有人給出原因，可以自行查看。

Docker命令調(diào)用報(bào)錯(cuò)

14Docker 定時(shí)任務(wù)異常

在 Crontab 定時(shí)任務(wù)中也存在 Docker 命令執(zhí)行異常的情況！

[問題起因]今天發(fā)現(xiàn)了一個(gè)問題，就是在備份Mysql數(shù)據(jù)庫的時(shí)候，使用docker容器進(jìn)行備份，然后使用Crontab定時(shí)任務(wù)來觸發(fā)備份。但是發(fā)現(xiàn)備份的MySQL數(shù)據(jù)庫居然是空的，但是手動(dòng)執(zhí)行對(duì)應(yīng)命令切是好的，很奇怪。

#Crontab定時(shí)任務(wù)
0*/6***
dockerexec-itsh-c
'execmysqldump--all-databases-uroot-ppassword......'

[解決方法]后來發(fā)現(xiàn)是因?yàn)閳?zhí)行的docker命令多個(gè)-i導(dǎo)致的。因?yàn)镃rontab命令執(zhí)行的時(shí)候，并不是交互式的，所以需要把這個(gè)去掉才可以。總結(jié)就是，如果你需要回顯的話則需要-t選項(xiàng)，如果需要交互式會(huì)話則需要-i選項(xiàng)。

編號(hào)	參數(shù)	解釋說明
1	-i/-interactive	即使沒有附加也保持 STDIN 打開；如果你需要執(zhí)行命令則需要開啟這個(gè)選項(xiàng)
2	-t/–tty	分配一個(gè)偽終端進(jìn)行執(zhí)行；一個(gè)連接用戶的終端與容器 stdin 和 stdout 的橋梁

15Docker 變量使用引號(hào)

compose 里邊環(huán)境變量帶不帶引號(hào)的問題！

[問題起因]使用過compose的朋友可能都遇到過，在編寫啟服務(wù)啟動(dòng)配置文件的時(shí)候，添加環(huán)境變量時(shí)到底是使用單引號(hào)、雙引號(hào)還是不使用引號(hào)的問題？時(shí)間長了，我們可能會(huì)將三者混用，認(rèn)為其效果是一樣的。但是后來，發(fā)現(xiàn)的坑越來越多，才發(fā)現(xiàn)其越來越隱晦。

反正我是遇到過很多問題，都是因?yàn)樘砑右?hào)導(dǎo)致的服務(wù)啟動(dòng)異常的，后來得出的結(jié)論就是一律不使引號(hào)。裸奔，體驗(yàn)前所未有的爽快！直到現(xiàn)在看到了Github中對(duì)應(yīng)的 issus 之后，才終于破案了。

#在Compose中進(jìn)行引用TEST_VAR變量，無法找到
TEST_VAR="test"

#在Compose中進(jìn)行引用TEST_VAR變量，可以找到
TEST_VAR=test

#后來發(fā)現(xiàn)docker本身其實(shí)已經(jīng)正確地處理了引號(hào)的使用
dockerrun-it--rm-eTEST_VAR="test"test:latest

[解決方法]得到的結(jié)論就是，因?yàn)镃ompose解析yaml配置文件，發(fā)現(xiàn)引號(hào)也進(jìn)行了解釋包裝。這就導(dǎo)致原本的TEST_VAR="test"被解析成了'TEST_VAR="test"'，所以我們在引用的時(shí)候就無法獲取到對(duì)應(yīng)的值?，F(xiàn)在解決方法就是，不管是我們直接在配置文件添加環(huán)境變量或者使用env_file配置文件，能不使用引號(hào)就不適用引號(hào)。

需要注意的是環(huán)境變量配置的是日志格式的話(2022-01-01)，如果使用的是Python的yaml.load模塊的話，會(huì)被當(dāng)做是date類型的，這是如果希望保持原樣信息的話，可以使用'/"引起來將其變成字符串格式的。

16Docker 刪除鏡像報(bào)錯(cuò)

無法刪除鏡像，歸根到底還是有地方用到了！

[問題起因]清理服器磁盤空間的時(shí)候，刪除某個(gè)鏡像的時(shí)候提示如下信息。提示需要強(qiáng)制刪除，但是發(fā)現(xiàn)及時(shí)執(zhí)行了強(qiáng)制刪除依舊沒有效果。

#刪除鏡像
$dockerrmi3ccxxxx2e862
Errorresponsefromdaemon:conflict:unabletodelete3ccxxxx2e862(cannotbeforced)-imagehasdependentchildimages

#強(qiáng)制刪除
$dcokerrmi-f3ccxxxx2e862
Errorresponsefromdaemon:conflict:unabletodelete3ccxxxx2e862(cannotbeforced)-imagehasdependentchildimages

[解決方法]后來才發(fā)現(xiàn)，出現(xiàn)這個(gè)原因主要是因?yàn)門AG，即存在其他鏡像引用了這個(gè)鏡像。這里我們可以使用如下命令查看對(duì)應(yīng)鏡像文件的依賴關(guān)系，然后根據(jù)對(duì)應(yīng)TAG來刪除鏡像。

#查詢依賴-image_id表示鏡像名稱
$dockerimageinspect--format='{{.RepoTags}}{{.Id}}{{.Parent}}'$(dockerimagels-q--filtersince=)

#根據(jù)TAG刪除鏡像
$dockerrmi-fc565xxxxc87f

#刪除懸空鏡像
$dockerrmi$(dockerimages--filter"dangling=true"-q--no-trunc)

17Docker 普通用戶切換

切換 Docker 啟動(dòng)用戶的話，還是需要注意下權(quán)限問題的！

[問題起因]我們知道在Docker容器里面使用root用戶的話，是不安全的，很容易出現(xiàn)越權(quán)的安全問題，所以一般情況下，我們都會(huì)使用普通用戶來代替root進(jìn)行服務(wù)的啟動(dòng)和管理的。今天給一個(gè)服務(wù)切換用戶的時(shí)候，發(fā)現(xiàn)Nginx服務(wù)一直無法啟動(dòng)，提示如下權(quán)限問題。因?yàn)閷?duì)應(yīng)的配置文件也沒有配置var相關(guān)的目錄，無奈 ? ！

#Nginx報(bào)錯(cuò)信息
nginx:[alert]couldnotopenerrorlogfile:open()"/var/log/nginx/error.log"failed(13:Permissiondenied)
2020/11/121547[emerg]23#23:mkdir()"/var/cache/nginx/client_temp"failed(13:Permissiondenied)

[解決方法]后來發(fā)現(xiàn)還是nginx.conf配置文件，配置的有問題，需要將Nginx服務(wù)啟動(dòng)時(shí)候需要的文件都配置到一個(gè)無權(quán)限的目錄，即可解決。

userwww-data;
worker_processes1;

error_log/data/logs/master_error.logwarn;
pid/dev/shm/nginx.pid;

events{
worker_connections1024;
}

http{
include/etc/nginx/mime.types;
default_typeapplication/octet-stream;

gzipon;
sendfileon;
tcp_nopushon;
keepalive_timeout65;

client_body_temp_path/tmp/client_body;
fastcgi_temp_path/tmp/fastcgi_temp;
proxy_temp_path/tmp/proxy_temp;
scgi_temp_path/tmp/scgi_temp;
uwsgi_temp_path/tmp/uwsgi_temp;

include/etc/nginx/conf.d/*.conf;
}

18Docker 綁定到 IPv6 上

Docker 服務(wù)在啟動(dòng)的時(shí)候，將地址綁定到 IPv6 地址上面了，提示報(bào)錯(cuò)信息！

[問題起因]物理機(jī)器更新了對(duì)應(yīng)補(bǔ)丁之后，重啟了服務(wù)，導(dǎo)致原本可以正常啟動(dòng)的docker-compose服務(wù)提示如下報(bào)錯(cuò)信息。不清楚是否修改了操作系統(tǒng)的相關(guān)配置，還是對(duì)應(yīng)docker進(jìn)行的其他方面的配置，比如修改/etc/docker/daemon.json或者docker的service啟動(dòng)文件。

#Docker的報(bào)錯(cuò)信息
dockerrun-p80:80nginx:alpinesucceeds.Previously,thiswasfailingwithError
startinguserlandproxy:listentcp6[::]socket:addressfamilynotsupportedbyprotocol.

[解決方法]通過如上所示的報(bào)錯(cuò)信息，可以看到服務(wù)的啟動(dòng)端口綁定到了tcp6上面了，但是對(duì)應(yīng)的socket發(fā)現(xiàn)系統(tǒng)本身并不支持。這時(shí)，我們一看下對(duì)應(yīng)的操作系統(tǒng)ipv6的設(shè)置，發(fā)現(xiàn)系統(tǒng)禁用了，所有的ipv6地址。需要了解的朋友，可以參考 fix port forwarding with ipv6.disable=1 和 cannot start if ipv6 is disabled on host 這兩個(gè)issus來獲取更多信息。

#操作系統(tǒng)配置
$cat/etc/sysctl.conf|grepipv6
net.ipv6.conf.all.disable_ipv6=1

[方法一]最為簡單的解決方法，就是在docker-compose.yml文件中，手動(dòng)指定將對(duì)應(yīng)服務(wù)的端口綁定到ipv4上面，如下所示。

version:"3"

services:
app:
restart:on-failure
container_name:app_web
image:app:latest
ports:
-"0.0.0.080/tcp"
volumes:
-"./app_web:/data"
networks:
-app_network

networks:
app_network:

[方法二]或者修改/etc/docker/daemon.json文件，在配置中，阻止Docker錯(cuò)誤的將端口映射到IPv6上，即可達(dá)到同樣的效果，且不用再次修改多個(gè)服務(wù)的啟動(dòng)配置文件了。

#修改配置
$vim/etc/docker/daemon.json
{
"ipv6":false,
"fixed-cidr-v6":"20011::/64"
}

#重啟服務(wù)
$systemctlreloaddocker

[方法三]Docker默認(rèn)情況下會(huì)同時(shí)將端口映射于IPv4與IPv6兩者上，而且有的時(shí)候會(huì)出現(xiàn)只綁定到了IPv6，導(dǎo)致服務(wù)無法正常訪問的情況?，F(xiàn)在通用的始終還是IPv4地址，因此最簡單的做法就是關(guān)閉IPv6地址。詳細(xì)的配置，可以參考 Port redirecting binding to IPv6 but not IPv4 interfaces 這個(gè)issus地址。

#修改系統(tǒng)配置
echo'1'>/proc/sys/net/ipv6/conf/lo/disable_ipv6
echo'1'>/proc/sys/net/ipv6/conf/lo/disable_ipv6
echo'1'>/proc/sys/net/ipv6/conf/all/disable_ipv6
echo'1'>/proc/sys/net/ipv6/conf/default/disable_ipv6

#重啟網(wǎng)絡(luò)
$/etc/init.d/networkingrestart

#最后檢測是否已關(guān)閉IPv6
ipaddrshow|grepnet6

1919. Docker 容器啟動(dòng)超時(shí)

Docker 服務(wù)在啟動(dòng)的時(shí)候，提示超時(shí)，被直接終止了！

[問題起因]使用docker-compose啟動(dòng)容器的時(shí)候，等待了很久的時(shí)候(大約2-3分鐘左右)，之后提示如下信息。通過閱讀信息內(nèi)容，可以看到是因?yàn)槌瑫r(shí)導(dǎo)致的，提示可以通過設(shè)置環(huán)境變量，加大超時(shí)的時(shí)間。

$docker-composeup-d
ERROR:forxxxUnixHTTPConnectionPool(host='localhost',port=None):Readtimedout.(readtimeout=70)
ERROR:AnHTTPrequesttooktoolongtocomplete.Retrywith--verbosetoobtaindebuginformation.
Ifyouencounterthisissueregularlybecauseofslownetworkconditions,considersettingCOMPOSE_HTTP_TIMEOUTtoahighervalue(currentvalue:60).

[解決方法]按照提示設(shè)置的環(huán)境變量之后，再次啟動(dòng)發(fā)現(xiàn)確實(shí)可以正常啟動(dòng)了，但是還是能夠感覺到有些慢。

$sudovim/etc/profile
exportCOMPOSE_HTTP_TIMEOUT=500
exportDOCKER_CLIENT_TIMEOUT=500

排除了下啟動(dòng)流程，因?yàn)槿萜鲉?dòng)有映射目錄到容器里面且目錄大小比較大，所以懷疑是因?yàn)閕/o導(dǎo)致的。隨即使用iotop命令查看服務(wù)器目前的i/o情況，發(fā)現(xiàn)存在很多個(gè)rg命令，且都處于100%左右。查了下，發(fā)現(xiàn)是vscode遠(yuǎn)程服務(wù)器啟動(dòng)的搜索目錄結(jié)構(gòu)的進(jìn)程，西八，有些坑呀！

$sudoiotop
4269be/4escape15.64K/s0.00B/s0.00%98.36%rg--files--hidden
4270be/4escape28.15K/s0.00B/s0.00%97.46%rg--files--hidden
4272be/4escape31.27K/s0.00B/s0.00%97.39%rg--files--hidden
4276be/4escape34.40K/s0.00B/s0.00%96.98%rg--files--hidden

20Docker 端口網(wǎng)絡(luò)限制

如果發(fā)現(xiàn)服務(wù)都一切正常，但是無法無法訪問的話，則多為網(wǎng)絡(luò)問題！

[問題起因]啟用服務(wù)之后，登錄跳轉(zhuǎn)發(fā)現(xiàn)直接502報(bào)錯(cuò)了。排除了配置等相關(guān)原因都沒有任何問題(做過相關(guān)測試)，這就非常奇怪了！

#部署服務(wù)架構(gòu)
nginx(80)->web1(8080)
->web2(8081)

#報(bào)錯(cuò)信息如下所示
nginxconnect()failed(113:Noroutetohost)whileconnectingtoupstream

[解決方法]根據(jù)錯(cuò)誤信息可知，是因?yàn)闆]有路由到指定的host導(dǎo)致了，隨即看了下防火墻是開著的，看了日志發(fā)現(xiàn)被過濾掉了，西八！問題找到了，現(xiàn)在需要做的就是，要么添加防火墻規(guī)則，要么關(guān)閉防火墻。

#檢查開放的端口
$sudofirewall-cmd--permanent--zone=public--list-ports

#開啟需要路由的端口
$sudofirewall-cmd--permanent--zone=public--add-port=8080/tcp
$sudofirewall-cmd--permanent--zone=public--add-port=8081/tcp

#配置立即生效
firewall-cmd--reload

#關(guān)閉防火墻
$sudosystemctlstopfirewalld.service

#禁用自啟動(dòng)
$sudosystemctldisablefirewalld.service

21Docker 無法獲取鏡像

新初始化的機(jī)器，無法獲取私有倉庫的鏡像文件！

[問題起因]機(jī)器初始化之后，使用如下命令登錄私有docker倉庫，發(fā)現(xiàn)提示無法獲取對(duì)應(yīng)鏡像，但是在其他機(jī)器上面獲取該鏡像就可以執(zhí)行成功，這就非常奇怪了！

#登錄私有倉庫
$echo'123456'|dockerlogin-uescape--password-stdindocker.escapelife.site

#異常信息提示
$sudodockerpulldocker.escapelife.site/app:0.10
Errorresponsefromdaemon:manifestfordocker.escapelife.site/app:0.10notfound:manifestunknown:manifestunknown

[解決方法]太坑了，我還以為我發(fā)現(xiàn)某個(gè)隱藏的bug了，可勁的排查，最后發(fā)現(xiàn)，原來是自己鏡像包名字寫錯(cuò)了，應(yīng)該寫成0.0.10的，自己卻寫成了0.10。這里，紀(jì)念一下，以后碰到上述報(bào)錯(cuò)，那肯定是鏡像不存在的。

#登錄私有倉庫之后會(huì)在用戶家目錄下生成一個(gè)docker配置
#其用來記錄docker私有倉庫的登錄認(rèn)證信息(是加密過的信息但不安全)=>base64
$cat.docker/config.json
{
"auths":{
"docker.escapelife.site":{
"auth":"d00u11Fu22B3355VG2xasE12w=="
}
}
}

22Docker 使容器不退出

如何使使用 docker-compose 啟動(dòng)的容器服務(wù) hang 住而不退出

[問題起因]有時(shí)候我們啟動(dòng)的服務(wù)，因?yàn)槟承﹩栴}(bug)導(dǎo)致服務(wù)無法正常啟動(dòng)，就會(huì)出現(xiàn)容器無限重啟(restart: on-failure)的情況，這時(shí)就很不利于排除問題。

?dockerps-a
4e6xxx9a4app:latest"/xxx/…"26secondsagoRestarting(1)2secondsago

[解決方法]這時(shí)我們就需要根據(jù)，服務(wù)構(gòu)建使用命令來決定是用什么命令來hang住服務(wù)?？ㄗ〉脑?，就類似于使用/bin/bash進(jìn)入容器是一樣的，這里我就不過多解釋了。

#類似原理
dockerrun-it--rm--entrypoint=/bin/bashxxx/app:latest

#使用Command命令
tty:true
command:tail-f/dev/null

#使用Entrypoint命令
tty:true
entrypoint:tail-f/dev/null

同理，我們在使用docker-compose或者k8s平臺(tái)部署服務(wù)的時(shí)候，也有時(shí)會(huì)因?yàn)閱?dòng)問題需要，使啟動(dòng)的服務(wù)不直接退出，來手動(dòng)調(diào)試和排查問題原因。所以，我這里記錄下其不同部署方式的，暫停方式。

#Compose

version:"3"
services:
app:
image:ubuntu:latest
tty:true
entrypoint:/usr/bin/tail
command:"-f/dev/null"

#K8S

apiVersion:v1
kind:Pod
metadata:
name:ubuntu
spec:
containers:
-name:ubuntu
image:ubuntu:latest
command:["/bin/bash","-c","--"]
args:["whiletrue;dosleep30;done;"]
#command:["sleep"]
#args:["infinity"]

23Docker 不使用默認(rèn)網(wǎng)段

有些情況，內(nèi)部規(guī)劃的網(wǎng)段和可能和 Dockerd 默認(rèn)的網(wǎng)段有沖突，導(dǎo)致異常出現(xiàn)！

[問題起因]今天在新機(jī)器上面，部署了一整套服務(wù)(多臺(tái)機(jī)器)，服務(wù)部署完畢之后，通過前置Nginx服務(wù)發(fā)現(xiàn)并不能訪問，后置機(jī)器開放的端口，發(fā)現(xiàn)發(fā)到對(duì)應(yīng)端口的請求都沒有轉(zhuǎn)發(fā)出去。這就比較奇怪了，因?yàn)槎丝诳刂剖且呀?jīng)開通了的，不應(yīng)該出現(xiàn)不通的情況。

?nc-v172.16.100.128000
nc:connectto172.16.100.12port8000(tcp)failed:Connectionrefused

[解決方法]發(fā)現(xiàn)服務(wù)器端口不通，我這里懷疑可能是dockerd服務(wù)啟動(dòng)導(dǎo)致的，所以我先將服務(wù)都停掉，直接在機(jī)器上面啟動(dòng)了Python的服務(wù)端程序(Linux機(jī)器自帶Python2.7.x的版本)，然后在前置Nginx服務(wù)發(fā)現(xiàn)，端口確實(shí)是通的。后來，排除發(fā)現(xiàn)是內(nèi)部服務(wù)默認(rèn)網(wǎng)段和dockerd服務(wù)啟動(dòng)的默認(rèn)網(wǎng)段是沖突的，導(dǎo)致重寫了機(jī)器的防火墻規(guī)則，導(dǎo)致出現(xiàn)上述異常的。

$python-mSimpleHTTPServer8000
ServingHTTPon0.0.0.0port8000...

?nc-v172.16.100.128000
Connectionto172.16.100.128000port[tcp/*]succeeded!

既然問題已經(jīng)知道了，現(xiàn)在需要做的就是非常簡單了：不適用默認(rèn)網(wǎng)段！通過 『mirantis』 里面，我們可以選擇進(jìn)行設(shè)置，然后重啟服務(wù)dockerd服務(wù)，即可。

#修改配置
$sudocat/etc/docker/daemon.json
{
"default-address-pools":[{"base":"192.168.100.0/20","size":24}]
}

#重啟服務(wù)
$sudosystemctlrestartdocker

#啟動(dòng)服務(wù)驗(yàn)證是否生效
$ipa
$dockernetworkinspectapp|grepSubnet

這時(shí)，就到了考驗(yàn)我們網(wǎng)絡(luò)的子網(wǎng)劃分的能力了：如何在給定的網(wǎng)段下面合理且高效的進(jìn)行劃分呢？咳咳，確實(shí)難倒我了，這時(shí)我們可以再這個(gè)在線網(wǎng)站上面 JSON 在線解析 進(jìn)行劃分，然后選定合理的base和size就可以了。

#報(bào)錯(cuò)信息
Errorresponsefromdaemon:couldnotfindanavailable,non-overlappingIPv4addresspoolamongthedefaultstoassigntothenetwork

#按照下圖我們可以對(duì)pool進(jìn)行合理劃分
#給定10.210.200.0+255.255.255.0的網(wǎng)段來劃分子網(wǎng)
$sudocat/etc/docker/daemon.json
{
"default-address-pools":[{"base":"10.210.200.0/24","size":28}]
}

其中，base告訴我們劃分子網(wǎng)的網(wǎng)段是什么(從來開始)，是從前兩位(/16)開始，還是第三位開始(/24)呢？而size則告訴我們劃分的每個(gè)子網(wǎng)有多少IP地址可以使用呢？從"10.210.200.0/24"我們可以知道，該網(wǎng)絡(luò)下面只有254個(gè)可用的IP地址(直接使用肯定不夠)，然后我們需要給docker使用，劃分每個(gè)子網(wǎng)可用16個(gè)IP地址，所以子網(wǎng)就應(yīng)該寫成28了。

Docker 不使用默認(rèn)網(wǎng)段

24Docker 添加私有倉庫

有些情況，我們服務(wù)器上面需要使用內(nèi)部私有的容器鏡像地址！

[問題起因]如果新機(jī)器上面需要使用私有倉庫的話，但是又沒有配置，再獲取鏡像的時(shí)候就會(huì)出現(xiàn)如下報(bào)錯(cuò)信息。

#拉取/登陸私庫時(shí)提示
$dockerpull192.168.31.191:5000/nginx:latest
x509:certificatesignedbyunknownauthority

[解決方法]該問題的處理方式很簡單，如下所示，配置一下倉庫地址，重啟服務(wù)并登陸私有倉庫就可以了。

#添加配置
$sudocat/etc/docker/daemon.json
{
"insecure-registries":["192.168.31.191:5000"]
}

#重啟docker
$sudosystemctlrestartdocker

#重新登錄即可
$dockerlogin私庫地址-u用戶名-p密碼

原文標(biāo)題：24 個(gè) Docker 常見問題處理技巧

文章出處：【微信公眾號(hào)：馬哥Linux運(yùn)維】歡迎添加關(guān)注！文章轉(zhuǎn)載請注明出處。