电子设备知识网-中国电子设备,国内最专业电子设备平台
电子设备知识网-中国电子设备,国内最专业电子设备平台

如何迁移docker的存储目录

1Docker 迁移存储目录

默认情况系统会将 Docker 容器存放在 /var/lib/docker 目录下

[问题起因]今天通过监控系统,发现公司其中一台服务器的磁盘快慢,随即上去看了下,发现/var/lib/docker这个目录特别大。由上述原因,我们都知道,在/var/lib/docker中存储的都是相关于容器的存储,所以也不能随便的将其删除掉。

那就准备迁移docker的存储目录吧,或者对/var设备进行扩容来达到相同的目的。更多关于dockerd的详细参数,请点击查看官方文档地址。

但是需要注意的一点就是,尽量不要用软链, 因为一些docker容器编排系统不支持这样做,比如我们所熟知的k8s就在内。

 #发现容器启动不了了 ERROR:cannot  create temporary directory!  #查看系统存储情况 $du-h--max-depth=1

[解决方法 1] 添加软链接

 #1.停止docker服务 $sudosystemctlstopdocker  #2.开始迁移目录 $sudomv/var/lib/docker/data/  #3.添加软链接 $sudoln-s/data/docker/var/lib/docker  #4.启动docker服务 $sudosystemctlstartdocker 

[解决方法 2] 改动 docker 配置文件

 #[方式一]改动docker启动配置文件 $sudovim/lib/systemd/system/docker.service ExecStart=/usr/bin/dockerd--graph=/data/docker/ 
 #[方式二]改动docker启动配置文件 $sudovim/etc/docker/daemon.json { "live-restore":true, "graph":["/data/docker/"] } 

[操作注意事项]在迁移docker目录的时候注意使用的命令,要么使用mv命令直接移动,要么使用cp命令复制文件,但是需要注意同时复制文件权限和对应属性,不然在使用的时候可能会存在权限问题。如果容器中,也是使用root用户,则不会存在该问题,但是也是需要按照正确的操作来迁移目录。

 #使用mv命令 $sudomv/var/lib/docker/data/docker  #使用cp命令 $sudocp-arv/data/docker/data2/docker 

下图中,就是因为启动的容器使用的是普通用户运行进程的,且在运行当中需要使用/tmp目录,结果提示没有权限。在我们导入容器镜像的时候,其实是会将容器启动时需要的各个目录的权限和属性都赋予了。如果我们直接是cp命令单纯复制文件内容的话,就会出现属性不一致的情况,同时还会有一定的安全问题。

如何迁移docker的存储目录Docker迁移存储目录

2Docker 设备空间不足

Increase Docker container size from default 10GB on rhel7.

[问题起因一]容器在导入或者启动的时候,如果提示磁盘空间不足的,那么多半是真的因为物理磁盘空间真的有问题导致的。如下所示,我们可以看到/分区确实满了。

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

如果发现真的是物理磁盘空间满了的话,就需要查看到底是什么占据了如此大的空间,导致因为容器没有空间无法启动。其中,docker自带的命令就是一个很好的能够帮助我们发现问题的工具

 #查看基本信息 #硬件驱动使用的是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 

[解决方法]通过查看信息,我们知道正是因为docker可用的磁盘空间不足,所以导致启动的时候没有足够的空间进行加载启动镜像。解决的方法也很简单,第一就是清理无效数据文件释放磁盘空间(清除日志),第二就是修改docker数据的存放路径(大分区)。

 #显示哪些容器目录具有最大的日志文件 $du-d1-h/var/lib/docker/containers|sort-h  #清除您选择的容器日志文件的内容 $cat/dev/null>/var/lib/docker/containers/container_id/container_log_name 

[问题起因二]显然我遇到的不是上一种情况,而是在启动容器的时候,容器启动之后不久就显示是unhealthy的状态,通过如下日志发现,原来是复制配置文件启动的时候,提示磁盘空间不足。

后面发现是因为CentOS7的系统使用的docker容器默认的创建大小就是10G而已,然而我们使用的容器却超过了这个限制,导致无法启动时提示空间不足。

 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] 改动 docker 启动配置文件

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

[解决方法 2] 改动 systemctl 的 docker 启动文件

 #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 

[问题起因三]还有一种情况也会让容器无法启动,并提示磁盘空间不足,但是使用命令查看发现并不是因为物理磁盘真的不足导致的。而是,因为对于分区的inode节点数满了导致的。

 #报错信息 Nospaceleftondevice 

[解决方法]因为ext3文件系统使用inode table存储inode信息,而xfs文件系统使用B+ tree来进行存储。考虑到性能问题,默认情况下这个B+ tree只会使用前1TB空间,当这1TB空间被写满后,就会导致无法写入inode信息,报磁盘空间不足的错误。我们可以在mount时,指定inode64即可将这个B+ tree使用的空间扩展到整个文件系统。

Docker+K8s+Jenkins 主流技术全解视频资料【干货免费分享】

 #查看系统的inode节点使用情况 $sudodf-i  #尝试重新挂载 $sudomount-oremount-onoatime,nodiratime,inode64,nobarrier/dev/vda1 

[补充知识]文件储存在硬盘上,硬盘的最小存储单位叫做扇区(Sector)。每个扇区储存512字节(相当于0.5KB)。操作系统读取硬盘的时候,不会一个个扇区地读取,这样效率太低,而是一次性连续读取多个扇区,即一次性读取一个(block)。这种由多个扇区组成的,是文件存取的最小单位。的大小,最常见的是4KB,即连续八个sector组成一个block块。文件数据都储存在中,那么很显然,我们还必须找到一个地方储存文件的元信息,比如文件的创建者、文件的创建日期、文件的大小等等。这种储存文件元信息的区域就叫做索引节点(inode)。每一个文件都有对应的inode,里面包含了除了文件名以外的所有文件信息。

inode也会消耗硬盘空间,所以硬盘格式化的时候,操作系统自动将硬盘分成两个区域。一个是数据区,存放文件数据;另一个是inode区(inode table),存放inode所包含的信息。每个inode节点的大小,一般是128字节或256字节。inode节点的总数,在格式化时就给定,一般是每1KB或每2KB就设置一个inode节点。

 #每个节点信息的内容 $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 命令需要对/tmp 目录下面有访问权限

[问题起因]给系统安装完compose之后,查看版本的时候,提示缺少一个名为libz.so.1的共享链接库。第一反应就是,是不是系统少安装那个软件包导致的。随即,搜索了一下,将相关的依赖包都给安装了,却还是提示同样的问题。

 #提示错误信息 $docker-compose--version errorwhileloadingsharedlibraries:libz.so.1:failedtomapsegmentfromsharedobject:Operationnotpermitted 

[解决方法]后来发现,是因为系统中docker没有对/tmp目录的访问权限导致,需要重新将其挂载一次,就可以解决了。

 #重新挂载 $sudomount/tmp-oremount,exec 

4Docker 容器文件损坏

对 dockerd 的配置有可能会影响到系统稳定

[问题起因]容器文件损坏,经常会导致容器无法操作。正常的docker命令已经无法操控这台容器了,无法关闭、重启、删除。正巧,前天就需要这个的问题,主要的原因是因为重新对docker的默认容器进行了重新的分配限制导致的。

 #操作容器遇到类似的错误 b'devicemapper:ErrorrunningdeviceCreate(CreateSnapDeviceRaw)dm_task_runfailed' 

[解决方法]可以通过以下操作将容器删除/重建。

 #1.关闭docker $sudosystemctlstopdocker  #2.删除容器文件 $sudorm-rf/var/lib/docker/containers  #3.重新整理容器元数据 $sudothin_check/var/lib/docker/devicemapper/devicemapper/metadata $sudothin_check--clear-needs-check-flag/var/lib/docker/devicemapper/devicemapper/metadata  #4.重启docker $sudosystemctlstartdocker 

5Docker 容器优雅重启

不停止服务器上面运行的容器,重启 dockerd 服务是多么好的一件事

[问题起因]默认情况下,当Docker守护程序终止时,它会关闭正在运行的容器。从Docker-ce 1.12开始,可以在配置文件中添加live-restore参数,以便在守护程序变得不可用时容器保持运行。需要注意的是Windows平台暂时还是不支持该参数的配置。

 #Keepcontainersaliveduringdaemondowntime $sudovim/etc/docker/daemon.yaml { "live-restore":true }  #在守护进程停机期间保持容器存活 $sudodockerd--live-restore  #只能使用reload重载 #相当于发送SIGHUP信号量给dockerd守护进程 $sudosystemctlreloaddocker  #但是对应网络的设置需要restart才能生效 $sudosystemctlrestartdocker 

[解决方法]可以通过以下操作将容器删除/重建。

 #/etc/docker/daemon.yaml { "registry-mirrors":["https://vec0xydj.mirror.aliyuncs.com"],#配置获取官方镜像的仓库地址 "experimental":true,#启用实验功能 "default-runtime":"nvidia",#容器的默认OCI运行时(默认为runc) "live-restore":true,#重启dockerd服务的时候容易不终止 "runtimes":{#配置容器运行时 "nvidia":{ "path":"/usr/bin/nvidia-container-runtime", "runtimeArgs":[] } }, "default-address-pools":[#配置容器使用的子网地址池 { "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 容器无法删除

找不到对应容器进程是最吓人的

[问题起因]今天遇到docker容器无法停止/终止/删除,以为这个容器可能又出现了dockerd守护进程托管的情况,但是通过ps -ef 无法查到对应的运行进程。哎,后来开始开始查supervisor以及Dockerfile中的进程,都没有。这种情况的可能原因是容器启动之后,主机因任何原因重新启动并且没有优雅地终止容器。剩下的文件现在阻止你重新生成旧名称的新容器,因为系统认为旧容器仍然存在。

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

[解决方法]找到/var/lib/docker/containers/下的对应容器的文件夹,将其删除,然后重启一下dockerd即可。我们会发现,之前无法删除的容器没有了。

 #删除容器文件 $sudorm-rf/var/lib/docker/containers/f8e8c3...65720  #重启服务 $sudosystemctlrestartdocker.service 

7Docker 容器中文异常

容器存在问题话,记得优先在官网查询

[问题起因]今天登陆之前部署的MySQL数据库查询,发现使用SQL语句无法查询中文字段,即使直接输入中文都没有办法显示。

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

[解决方法]Docker部署的MySQL系统使用的是POSIX字符集。然而POSIX字符集是不支持中文的,而C.UTF-8是支持中文的只要把系统中的环境LANG改为”C.UTF-8″格式即可解决问题。同理,在K8S进入pod不能输入中文也可用此方法解决。

 #临时解决 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 容器网络互通

了解 Docker 的四种网络模型

[问题起因]在本机部署Nginx容器想代理本机启动的Python后端服务程序,但是对代码服务如下的配置,结果访问的时候一直提示502错误。

 #启动Nginx服务 $dockerrun-d-p80:80$PWD:/etc/nginxnginx 
 server{ ... location/api{ proxy_passhttp://localhost:8080 } ... } 

[解决方法]后面发现是因为nginx.conf配置文件中的localhost配置的有问题,由于Nginx是在容器中运行,所以localhost为容器中的localhost,而非本机的localhost,所以导致无法访问。

可以将nginx.conf中的localhost改为宿主机的IP地址,就可以解决502的错误。

 #查询宿主机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 } ... } 

当容器使用host网络时,容器与宿主共用网络,这样就能在容器中访问宿主机网络,那么容器的localhost就是宿主机的localhost了。

 #服务的启动方式有所改变(没有映射出来端口) #因为本身与宿主机共用了网络,宿主机暴露端口等同于容器中暴露端口 $dockerrun-d-p80:80--network=host$PWD:/etc/nginxnginxx 

9Docker 容器总线错误

总线错误看到的时候还是挺吓人了

[问题起因]在docker容器中运行程序的时候,提示bus error错误。

 #总线报错 $invapp.user_op--name=zhangsan Buserror(coredumped) 

[解决方法]原因是在docker运行的时候,shm分区设置太小导致share memory不够。不设置–shm-size参数时,docker给容器默认分配的shm大小为64M,导致程序启动时不足。具体原因还是因为安装pytorch包导致了,多进程跑任务的时候,docker容器分配的共享内存太小,导致torch要在tmpfs上面放模型数据用于子线程的 共享不足,就出现报错了。

 #问题原因 root@18...35:/opt/app#df-TH FilesystemTypeSizeUsedAvailUse%Mountedon overlayoverlay2.0T221G1.4T3%/ tmpfstmpfs68M068M0%/dev shmtmpfs68M41k68M1%/dev/shm  #启动docker的时候加上--shm-size参数(单位为b,k,m或g) $dockerrun-it--rm--shm-size=200mpytorch/pytorch:latest  #在docker-compose添加对应配置 $shm_size:'2gb' 

[解决方法]还有一种情况就是容器内的磁盘空间不足,也会导致bus error这样的报错,所以如果出现了,清除多余文件和目录或者分配一个大的磁盘空间,就可以解决了。

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

10Docker NFS 挂载报错

NFS 挂载之后容器程序使用异常为内核版本太低导致的

[问题起因]我们将服务部署到openshift集群中,启动服务调用资源文件的时候,报错信息如下所示。从报错信息中,得知是在Python3程序执行read_file()读取文件的内容,给文件加锁的时候报错了。但是奇怪的是,本地调试的时候发现服务都是可以正常运行的,文件加锁也是没问题的。后来发现,在openshift集群中使用的是NFS挂载的共享磁盘。

 #报错信息 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()的话,就需要升级内核版本到2.6.11+才行。后来才发现,这实际上是由RedHat內核中的一个错误引起的,并在kernel-3.10.0-693.18.1.el7版本中得到修复。所以对于NFSv3和NFSv4服务而已,就需要升级Linux内核版本才能够解决这个问题。

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

11Docker 使用默认网段

启动的容器网络无法相互通信,很是奇怪!

[问题起因]我们在使用Docker启动服务的时候,发现有时候服务之前可以相互连通,而有时启动的多个服务之前却出现了无法访问的情况。究其原因,发现原来是因为使用的内部私有地址网段不一致导致的。有的服务启动到了172.17 – 172.31的网段,有的服务跑到了192.169.0 – 192.168.224的网段,这样导致服务启动之后出现无法访问的情况(默认情况下,有下面这个两个网段可供其使用)。

如何迁移docker的存储目录Docker默认使用网段

[解决方法]上述问题的处理方式,就是手动指定Docker服务的启动网段,二选一就可以了。

 #查看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 服务启动串台

使用 docker-compose 命令各自启动两组服务,发现服务会串台!

[问题起因]在两个不同名称的目录目录下面,使用docker-compose来启动服务,发现当A组服务启动完毕之后,再启动B组服务的时候,发现A组当中对应的一部分服务又重新启动了一次,这就非常奇怪了!因为这个问题的存在会导致,A组服务和B组服务无法同时启动。之前还以为是工具的Bug,后来请教了“上峰”,才知道了原因,恍然大悟。

 #服务目录结构如下所示 A:/data1/app/docker-compose.yml B:/data2/app/docker-compose.yml 

[解决方法]发现A和B两组服务会串台的原因,原来是docker-compose会给启动的容器加label标签,然后根据这些label标签来识别和判断对应的容器服务是由谁启动的、谁来管理的,等等。而这里,我们需要关注的label变量是com.docker.compose.project,其对应的值是使用启动配置文件的目录的最底层子目录名称,即上面的app就是对应的值。我们可以发现,A和B两组服务对应的值都是app,所以启动的时候被认为是同一个,这就出现了上述的问题。如果需要深入了解的话,可以去看对应源代码。

如何迁移docker的存储目录Docker服务启动串台

 #可以将目录结构调整为如下所示 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命令提供的参数-p手动指定标签,来规避该问题的发生。

 #指定项目项目名称 $docker-compose-f./docker-compose.yml-papp1up-d 

13Docker 命令调用报错

在编写脚本的时候常常会执行 docker 相关的命令,但是需要注意使用细节!

[问题起因]CI更新环境执行了一个脚本,但是脚本执行过程中报错了,如下所示。通过对应的输出信息,可以看到提示说正在执行的设备不是一个tty。

如何迁移docker的存储目录Docker命令调用报错

随即,查看了脚本发现报错地方是执行了一个exec的docker命令,大致如下所示。很奇怪的是,手动执行或直接调脚本的时候,怎么都是没有问题的,但是等到CI调用的时候怎么都是有问题。后来好好看下,下面这个命令,注意到-it这个参数了。

 #脚本调用docker命令 dockerexec-itpsql-Upostgres...... 

我们可以一起看下exec命令的这两个参数,自然就差不多理解了。

编号 参数 解释说明
1 -i/-interactive 即使没有附加也保持 STDIN 打开;如果你需要执行命令则需要开启这个选项
2 -t/–tty 分配一个伪终端进行执行;一个连接用户的终端与容器 stdin 和 stdout 的桥梁

[解决方法]docker exec的参数-t是指Allocate a pseudo-TTY的意思,而CI在执行job的时候并不是在TTY终端中执行,所以-t这个参数会报错。同时在 『stackoverflow』也有人给出原因,可以自行查看。

如何迁移docker的存储目录Docker命令调用报错

14Docker 定时任务异常

在 Crontab 定时任务中也存在 Docker 命令执行异常的情况!

[问题起因]今天发现了一个问题,就是在备份Mysql数据库的时候,使用docker容器进行备份,然后使用Crontab定时任务来触发备份。但是发现备份的MySQL数据库居然是空的,但是手动执行对应命令切是好的,很奇怪。

 #Crontab定时任务 0*/6*** dockerexec-itsh-c 'execmysqldump--all-databases-uroot-ppassword......' 

[解决方法]后来发现是因为执行的docker命令多个-i导致的。因为Crontab命令执行的时候,并不是交互式的,所以需要把这个去掉才可以。总结就是,如果你需要回显的话则需要-t选项,如果需要交互式会话则需要-i选项。

编号 参数 解释说明
1 -i/-interactive 即使没有附加也保持 STDIN 打开;如果你需要执行命令则需要开启这个选项
2 -t/–tty 分配一个伪终端进行执行;一个连接用户的终端与容器 stdin 和 stdout 的桥梁

15Docker 变量使用引号

compose 里边环境变量带不带引号的问题!

[问题起因]使用过compose的朋友可能都遇到过,在编写启服务启动配置文件的时候,添加环境变量时到底是使用单引号、双引号还是不使用引号的问题?时间长了,我们可能会将三者混用,认为其效果是一样的。但是后来,发现的坑越来越多,才发现其越来越隐晦。

反正我是遇到过很多问题,都是因为添加引号导致的服务启动异常的,后来得出的结论就是一律不使引号。裸奔,体验前所未有的爽快!直到现在看到了Github中对应的 issus 之后,才终于破案了。

 #在Compose中进行引用TEST_VAR变量,无法找到 TEST_VAR="test"  #在Compose中进行引用TEST_VAR变量,可以找到 TEST_VAR=test  #后来发现docker本身其实已经正确地处理了引号的使用 dockerrun-it--rm-eTEST_VAR="test"test:latest 

[解决方法]得到的结论就是,因为Compose解析yaml配置文件,发现引号也进行了解释包装。这就导致原本的TEST_VAR=”test”被解析成了’TEST_VAR=”test”‘,所以我们在引用的时候就无法获取到对应的值。现在解决方法就是,不管是我们直接在配置文件添加环境变量或者使用env_file配置文件,能不使用引号就不适用引号。

需要注意的是环境变量配置的是日志格式的话(2022-01-01),如果使用的是Python的yaml.load模块的话,会被当做是date类型的,这是如果希望保持原样信息的话,可以使用’/”引起来将其变成字符串格式的。

16Docker 删除镜像报错

无法删除镜像,归根到底还是有地方用到了!

[问题起因]清理服器磁盘空间的时候,删除某个镜像的时候提示如下信息。提示需要强制删除,但是发现及时执行了强制删除依旧没有效果。

 #删除镜像 $dockerrmi3ccxxxx2e862 Errorresponsefromdaemon:conflict:unabletodelete3ccxxxx2e862(cannotbeforced)-imagehasdependentchildimages  #强制删除 $dcokerrmi-f3ccxxxx2e862 Errorresponsefromdaemon:conflict:unabletodelete3ccxxxx2e862(cannotbeforced)-imagehasdependentchildimages 

[解决方法]后来才发现,出现这个原因主要是因为TAG,即存在其他镜像引用了这个镜像。这里我们可以使用如下命令查看对应镜像文件的依赖关系,然后根据对应TAG来删除镜像。

 #查询依赖-image_id表示镜像名称 $dockerimageinspect--format='{{.RepoTags}}{{.Id}}{{.Parent}}'$(dockerimagels-q--filtersince=)  #根据TAG删除镜像 $dockerrmi-fc565xxxxc87f 
 #删除悬空镜像 $dockerrmi$(dockerimages--filter"dangling=true"-q--no-trunc) 

17Docker 普通用户切换

切换 Docker 启动用户的话,还是需要注意下权限问题的!

[问题起因]我们知道在Docker容器里面使用root用户的话,是不安全的,很容易出现越权的安全问题,所以一般情况下,我们都会使用普通用户来代替root进行服务的启动和管理的。今天给一个服务切换用户的时候,发现Nginx服务一直无法启动,提示如下权限问题。因为对应的配置文件也没有配置var相关的目录,无奈 ‍ !

 #Nginx报错信息 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) 

[解决方法]后来发现还是nginx.conf配置文件,配置的有问题,需要将Nginx服务启动时候需要的文件都配置到一个无权限的目录,即可解决。

 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 服务在启动的时候,将地址绑定到 IPv6 地址上面了,提示报错信息!

[问题起因]物理机器更新了对应补丁之后,重启了服务,导致原本可以正常启动的docker-compose服务提示如下报错信息。不清楚是否修改了操作系统的相关配置,还是对应docker进行的其他方面的配置,比如修改/etc/docker/daemon.json或者docker的service启动文件。

 #Docker的报错信息 dockerrun-p80:80nginx:alpinesucceeds.Previously,thiswasfailingwithError startinguserlandproxy:listentcp6[::]socket:addressfamilynotsupportedbyprotocol. 

[解决方法]通过如上所示的报错信息,可以看到服务的启动端口绑定到了tcp6上面了,但是对应的socket发现系统本身并不支持。这时,我们一看下对应的操作系统ipv6的设置,发现系统禁用了,所有的ipv6地址。需要了解的朋友,可以参考 fix port forwarding with ipv6.disable=1 和 cannot start if ipv6 is disabled on host 这两个issus来获取更多信息。

 #操作系统配置 $cat/etc/sysctl.conf|grepipv6 net.ipv6.conf.all.disable_ipv6=1 

[方法一]最为简单的解决方法,就是在docker-compose.yml文件中,手动指定将对应服务的端口绑定到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错误的将端口映射到IPv6上,即可达到同样的效果,且不用再次修改多个服务的启动配置文件了。

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

[方法三]Docker默认情况下会同时将端口映射于IPv4与IPv6两者上,而且有的时候会出现只绑定到了IPv6,导致服务无法正常访问的情况。现在通用的始终还是IPv4地址,因此最简单的做法就是关闭IPv6地址。详细的配置,可以参考 Port redirecting binding to IPv6 but not IPv4 interfaces 这个issus地址。

 #修改系统配置 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  #重启网络 $/etc/init.d/networkingrestart  #最后检测是否已关闭IPv6 ipaddrshow|grepnet6 

1919. Docker 容器启动超时

Docker 服务在启动的时候,提示超时,被直接终止了!

[问题起因]使用docker-compose启动容器的时候,等待了很久的时候(大约2-3分钟左右),之后提示如下信息。通过阅读信息内容,可以看到是因为超时导致的,提示可以通过设置环境变量,加大超时的时间。

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

[解决方法]按照提示设置的环境变量之后,再次启动发现确实可以正常启动了,但是还是能够感觉到有些慢。

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

排除了下启动流程,因为容器启动有映射目录到容器里面且目录大小比较大,所以怀疑是因为i/o导致的。随即使用iotop命令查看服务器目前的i/o情况,发现存在很多个rg命令,且都处于100%左右。查了下,发现是vscode远程服务器启动的搜索目录结构的进程,西八,有些坑呀!

 $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 端口网络限制

如果发现服务都一切正常,但是无法无法访问的话,则多为网络问题!

[问题起因]启用服务之后,登录跳转发现直接502报错了。排除了配置等相关原因都没有任何问题(做过相关测试),这就非常奇怪了!

 #部署服务架构 nginx(80)->web1(8080) ->web2(8081)  #报错信息如下所示 nginxconnect()failed(113:Noroutetohost)whileconnectingtoupstream 

[解决方法]根据错误信息可知,是因为没有路由到指定的host导致了,随即看了下防火墙是开着的,看了日志发现被过滤掉了,西八!问题找到了,现在需要做的就是,要么添加防火墙规则,要么关闭防火墙。

 #检查开放的端口 $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 
 #关闭防火墙 $sudosystemctlstopfirewalld.service  #禁用自启动 $sudosystemctldisablefirewalld.service 

21Docker 无法获取镜像

新初始化的机器,无法获取私有仓库的镜像文件!

[问题起因]机器初始化之后,使用如下命令登录私有docker仓库,发现提示无法获取对应镜像,但是在其他机器上面获取该镜像就可以执行成功,这就非常奇怪了!

 #登录私有仓库 $echo'123456'|dockerlogin-uescape--password-stdindocker.escapelife.site  #异常信息提示 $sudodockerpulldocker.escapelife.site/app:0.10 Errorresponsefromdaemon:manifestfordocker.escapelife.site/app:0.10notfound:manifestunknown:manifestunknown 

[解决方法]太坑了,我还以为我发现某个隐藏的bug了,可劲的排查,最后发现,原来是自己镜像包名字写错了,应该写成0.0.10的,自己却写成了0.10。这里,纪念一下,以后碰到上述报错,那肯定是镜像不存在的。

 #登录私有仓库之后会在用户家目录下生成一个docker配置 #其用来记录docker私有仓库的登录认证信息(是加密过的信息但不安全)=>base64 $cat.docker/config.json { "auths":{ "docker.escapelife.site":{ "auth":"d00u11Fu22B3355VG2xasE12w==" } } } 

22Docker 使容器不退出

如何使使用 docker-compose 启动的容器服务 hang 住而不退出

[问题起因]有时候我们启动的服务,因为某些问题(bug)导致服务无法正常启动,就会出现容器无限重启(restart: on-failure)的情况,这时就很不利于排除问题。

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

[解决方法]这时我们就需要根据,服务构建使用命令来决定是用什么命令来hang住服务。卡住的原理,就类似于使用/bin/bash进入容器是一样的,这里我就不过多解释了。

 #类似原理 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平台部署服务的时候,也有时会因为启动问题需要,使启动的服务不直接退出,来手动调试和排查问题原因。所以,我这里记录下其不同部署方式的,暂停方式。

 #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 不使用默认网段

有些情况,内部规划的网段和可能和 Dockerd 默认的网段有冲突,导致异常出现!

[问题起因]今天在新机器上面,部署了一整套服务(多台机器),服务部署完毕之后,通过前置Nginx服务发现并不能访问,后置机器开放的端口,发现发到对应端口的请求都没有转发出去。这就比较奇怪了,因为端口控制是已经开通了的,不应该出现不通的情况。

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

[解决方法]发现服务器端口不通,我这里怀疑可能是dockerd服务启动导致的,所以我先将服务都停掉,直接在机器上面启动了Python的服务端程序(Linux机器自带Python2.7.x的版本),然后在前置Nginx服务发现,端口确实是通的。后来,排除发现是内部服务默认网段和dockerd服务启动的默认网段是冲突的,导致重写了机器的防火墙规则,导致出现上述异常的。

 $python-mSimpleHTTPServer8000 ServingHTTPon0.0.0.0port8000...  ➜nc-v172.16.100.128000 Connectionto172.16.100.128000port[tcp/*]succeeded! 

既然问题已经知道了,现在需要做的就是非常简单了:不适用默认网段!通过 『mirantis』 里面,我们可以选择进行设置,然后重启服务dockerd服务,即可。

 #修改配置 $sudocat/etc/docker/daemon.json { "default-address-pools":[{"base":"192.168.100.0/20","size":24}] }  #重启服务 $sudosystemctlrestartdocker  #启动服务验证是否生效 $ipa $dockernetworkinspectapp|grepSubnet 

如何迁移docker的存储目录

这时,就到了考验我们网络的子网划分的能力了:如何在给定的网段下面合理且高效的进行划分呢?咳咳,确实难倒我了,这时我们可以再这个在线网站上面 JSON 在线解析 进行划分,然后选定合理的base和size就可以了。

 #报错信息 Errorresponsefromdaemon:couldnotfindanavailable,non-overlappingIPv4addresspoolamongthedefaultstoassigntothenetwork  #按照下图我们可以对pool进行合理划分 #给定10.210.200.0+255.255.255.0的网段来划分子网 $sudocat/etc/docker/daemon.json { "default-address-pools":[{"base":"10.210.200.0/24","size":28}] } 

其中,base告诉我们划分子网的网段是什么(从来开始),是从前两位(/16)开始,还是第三位开始(/24)呢?而size则告诉我们划分的每个子网有多少IP地址可以使用呢?从”10.210.200.0/24″我们可以知道,该网络下面只有254个可用的IP地址(直接使用肯定不够),然后我们需要给docker使用,划分每个子网可用16个IP地址,所以子网就应该写成28了。

如何迁移docker的存储目录 Docker 不使用默认网段

24Docker 添加私有仓库

有些情况,我们服务器上面需要使用内部私有的容器镜像地址!

[问题起因]如果新机器上面需要使用私有仓库的话,但是又没有配置,再获取镜像的时候就会出现如下报错信息。

 #拉取/登陆私库时提示 $dockerpull192.168.31.191:5000/nginx:latest x509:certificatesignedbyunknownauthority 

[解决方法]该问题的处理方式很简单,如下所示,配置一下仓库地址,重启服务并登陆私有仓库就可以了。

 #添加配置 $sudocat/etc/docker/daemon.json { "insecure-registries":["192.168.31.191:5000"] }  #重启docker $sudosystemctlrestartdocker  #重新登录即可 $dockerlogin私库地址-u用户名-p密码

原文标题:24 个 Docker 常见问题处理技巧

文章出处:【微信公众号:马哥Linux运维】欢迎添加关注!文章转载请注明出处。

审核编辑:彭静

未经允许不得转载:电子设备知识网 » 如何迁移docker的存储目录

分享到: 生成海报