24 个 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服务
$ sudo systemctl stop docker# 2.开始迁移目录
$ sudo mv /var/lib/docker /data/# 3.添加软链接
$ sudo ln -s /data/docker /var/lib/docker# 4.启动docker服务
$ sudo systemctl start docker
[解决方法 2] 改动 docker 配置文件
# [方式一] 改动docker启动配置文件
$ sudo vim /lib/systemd/system/docker.service
ExecStart=/usr/bin/dockerd --graph=/data/docker/
# [方式二] 改动docker启动配置文件
$ sudo vim /etc/docker/daemon.json
{"live-restore": true,"graph": [ "/data/docker/" ]
}
[操作注意事项] 在迁移
docker
目录的时候注意使用的命令,要么使用mv
命令直接移动,要么使用cp
命令复制文件,但是需要注意同时复制文件权限和对应属性,不然在使用的时候可能会存在权限问题。如果容器中,也是使用root
用户,则不会存在该问题,但是也是需要按照正确的操作来迁移目录。
# 使用mv命令
$ sudo mv /var/lib/docker /data/docker# 使用cp命令
$ sudo cp -arv /data/docker /data2/docker
下图中,就是因为启动的容器使用的是普通用户运行进程的,且在运行当中需要使用
/tmp
目录,结果提示没有权限。在我们导入容器镜像的时候,其实是会将容器启动时需要的各个目录的权限和属性都赋予了。如果我们直接是cp
命令单纯复制文件内容的话,就会出现属性不一致的情况,同时还会有一定的安全问题。
Docker迁移存储目录
2Docker 设备空间不足
Increase Docker container size from default 10GB on rhel7.
[问题起因一] 容器在导入或者启动的时候,如果提示磁盘空间不足的,那么多半是真的因为物理磁盘空间真的有问题导致的。如下所示,我们可以看到
/
分区确实满了。
# 查看物理磁盘空间
$ df -Th
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 40G 40G 0G 100% /
tmpfs 7.8G 0 7.8G 0% /dev/shm
/dev/vdb1 493G 289G 179G 62% /mnt
如果发现真的是物理磁盘空间满了的话,就需要查看到底是什么占据了如此大的空间,导致因为容器没有空间无法启动。其中,
docker
自带的命令就是一个很好的能够帮助我们发现问题的工具。
# 查看基本信息
# 硬件驱动使用的是devicemapper,空间池为docker-252
# 磁盘可用容量仅剩16.78MB,可用供我们使用
$ docker info
Containers: 1
Images: 28
Storage Driver: devicemapperPool Name: docker-252:1-787932-poolPool Blocksize: 65.54 kBBacking Filesystem: extfsData file: /dev/loop0Metadata file: /dev/loop1Data Space Used: 1.225 GBData Space Total: 107.4 GBData Space Available: 16.78 MBMetadata Space Used: 2.073 MBMetadata Space Total: 2.147 GB
[解决方法] 通过查看信息,我们知道正是因为
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-16 11:11:15,816 INFO spawned: 'app-demo' with pid 835
2019-08-16 11:11:16,268 INFO exited: app (exit status 1; not expected)
2019-08-16 11:11:17,270 INFO gave up: app entered FATAL state, too many start retries too quickly
cp: cannot create regular file '/etc/supervisor/conf.d/grpc-app-demo.conf': No space left on device
cp: cannot create regular file '/etc/supervisor/conf.d/grpc-app-demo.conf': No space left on device
cp: cannot create regular file '/etc/supervisor/conf.d/grpc-app-demo.conf': No space left on device
cp: cannot create regular file '/etc/supervisor/conf.d/grpc-app-demo.conf': No space left on device
[解决方法 1] 改动 docker 启动配置文件
# /etc/docker/daemon.json
{"live-restore": true,"storage-opt": [ "dm.basesize=20G" ]
}
[解决方法 2] 改动 systemctl 的 docker 启动文件
# 1.stop the docker service
$ sudo systemctl stop docker# 2.rm exised container
$ sudo rm -rf /var/lib/docker# 2.edit your docker service file
$ sudo vim /usr/lib/systemd/system/docker.service# 3.find the execution line
ExecStart=/usr/bin/dockerd
and change it to:
ExecStart=/usr/bin/dockerd --storage-opt dm.basesize=20G# 4.start docker service again
$ sudo systemctl start docker# 5.reload daemon
$ sudo systemctl daemon-reload
[问题起因三] 还有一种情况也会让容器无法启动,并提示磁盘空间不足,但是使用命令查看发现并不是因为物理磁盘真的不足导致的。而是,因为对于分区的
inode
节点数满了导致的。
# 报错信息
No space left on device
[解决方法] 因为
ext3
文件系统使用inode table
存储inode
信息,而xfs
文件系统使用B+ tree
来进行存储。考虑到性能问题,默认情况下这个B+ tree
只会使用前1TB
空间,当这1TB
空间被写满后,就会导致无法写入inode
信息,报磁盘空间不足的错误。我们可以在mount
时,指定inode64
即可将这个B+ tree
使用的空间扩展到整个文件系统。Docker+K8s+Jenkins 主流技术全解视频资料【干货免费分享】
# 查看系统的inode节点使用情况
$ sudo df -i# 尝试重新挂载
$ sudo mount -o remount -o noatime,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
节点。
# 每个节点信息的内容
$ stat check_port_live.shFile: check_port_live.shSize: 225 Blocks: 8 IO Block: 4096 regular file
Device: 822h/2082d Inode: 99621663 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 1006/ escape) Gid: ( 1006/ escape)
Access: 2019-07-29 14:59:59.498076903 +0800
Modify: 2019-07-29 14:59:59.498076903 +0800
Change: 2019-07-29 23:20:27.834866649 +0800Birth: -# 磁盘的inode使用情况
$ df -i
Filesystem Inodes IUsed IFree IUse% Mounted on
udev 16478355 801 16477554 1% /dev
tmpfs 16487639 2521 16485118 1% /run
/dev/sdc2 244162560 4788436 239374124 2% /
tmpfs 16487639 5 16487634 1% /dev/shm
3Docker 缺共享链接库
Docker 命令需要对/tmp 目录下面有访问权限
[问题起因] 给系统安装完
compose
之后,查看版本的时候,提示缺少一个名为libz.so.1
的共享链接库。第一反应就是,是不是系统少安装那个软件包导致的。随即,搜索了一下,将相关的依赖包都给安装了,却还是提示同样的问题。
# 提示错误信息
$ docker-compose --version
error while loading shared libraries: libz.so.1: failed to map segment from shared object: Operation not permitted
[解决方法] 后来发现,是因为系统中
docker
没有对/tmp
目录的访问权限导致,需要重新将其挂载一次,就可以解决了。
# 重新挂载
$ sudo mount /tmp -o remount,exec
4Docker 容器文件损坏
对 dockerd 的配置有可能会影响到系统稳定
[问题起因] 容器文件损坏,经常会导致容器无法操作。正常的
docker
命令已经无法操控这台容器了,无法关闭、重启、删除。正巧,前天就需要这个的问题,主要的原因是因为重新对docker
的默认容器进行了重新的分配限制导致的。
# 操作容器遇到类似的错误
b'devicemapper: Error running deviceCreate (CreateSnapDeviceRaw) dm_task_run failed'
[解决方法] 可以通过以下操作将容器删除/重建。
# 1.关闭docker
$ sudo systemctl stop docker# 2.删除容器文件
$ sudo rm -rf /var/lib/docker/containers# 3.重新整理容器元数据
$ sudo thin_check /var/lib/docker/devicemapper/devicemapper/metadata
$ sudo thin_check --clear-needs-check-flag /var/lib/docker/devicemapper/devicemapper/metadata# 4.重启docker
$ sudo systemctl start docker
5Docker 容器优雅重启
不停止服务器上面运行的容器,重启 dockerd 服务是多么好的一件事
[问题起因] 默认情况下,当
Docker
守护程序终止时,它会关闭正在运行的容器。从Docker-ce 1.12
开始,可以在配置文件中添加live-restore
参数,以便在守护程序变得不可用时容器保持运行。需要注意的是Windows
平台暂时还是不支持该参数的配置。
# Keep containers alive during daemon downtime
$ sudo vim /etc/docker/daemon.yaml
{"live-restore": true
}# 在守护进程停机期间保持容器存活
$ sudo dockerd --live-restore# 只能使用reload重载
# 相当于发送SIGHUP信号量给dockerd守护进程
$ sudo systemctl reload docker# 但是对应网络的设置需要restart才能生效
$ sudo systemctl restart docker
[解决方法] 可以通过以下操作将容器删除/重建。
# /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 <container id>
无法查到对应的运行进程。哎,后来开始开始查supervisor
以及Dockerfile
中的进程,都没有。这种情况的可能原因是容器启动之后,主机因任何原因重新启动并且没有优雅地终止容器。剩下的文件现在阻止你重新生成旧名称的新容器,因为系统认为旧容器仍然存在。
# 删除容器
$ sudo docker rm -f f8e8c3..
Error response from daemon: Conflict, cannot remove the default name of the container
[解决方法] 找到
/var/lib/docker/containers/
下的对应容器的文件夹,将其删除,然后重启一下dockerd
即可。我们会发现,之前无法删除的容器没有了。
# 删除容器文件
$ sudo rm -rf /var/lib/docker/containers/f8e8c3...65720# 重启服务
$ sudo systemctl restart docker.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
不能输入中文也可用此方法解决。
# 临时解决
docker exec -it some-mysql env LANG=C.UTF-8 /bin/bash
# 永久解决
docker run --name some-mysql \-e MYSQL_ROOT_PASSWORD=my-secret-pw \-d mysql:tag --character-set-server=utf8mb4 \--collation-server=utf8mb4_unicode_ci
8Docker 容器网络互通
了解 Docker 的四种网络模型
[问题起因] 在本机部署
Nginx
容器想代理本机启动的Python
后端服务程序,但是对代码服务如下的配置,结果访问的时候一直提示502
错误。
# 启动Nginx服务
$ docker run -d -p 80:80 $PWD:/etc/nginx nginx
server {...location /api {proxy_pass http://localhost:8080}...
}
[解决方法] 后面发现是因为
nginx.conf
配置文件中的localhost
配置的有问题,由于Nginx
是在容器中运行,所以localhost
为容器中的localhost
,而非本机的localhost
,所以导致无法访问。可以将
nginx.conf
中的localhost
改为宿主机的IP
地址,就可以解决502
的错误。
# 查询宿主机IP地址 => 172.17.0.1
$ ip addr show docker0
docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group defaultlink/ether 02:42:d5:4c:f2:1e brd ff:ff:ff:ff:ff:ffinet 172.17.0.1/16 scope global docker0valid_lft forever preferred_lft foreverinet6 fe80::42:d5ff:fe4c:f21e/64 scope linkvalid_lft forever preferred_lft forever
server {...location /api {proxy_pass http://172.17.0.1:8080}...
}
当容器使用
host
网络时,容器与宿主共用网络,这样就能在容器中访问宿主机网络,那么容器的localhost
就是宿主机的localhost
了。
# 服务的启动方式有所改变(没有映射出来端口)
# 因为本身与宿主机共用了网络,宿主机暴露端口等同于容器中暴露端口
$ docker run -d -p 80:80 --network=host $PWD:/etc/nginx nginxx
9Docker 容器总线错误
总线错误看到的时候还是挺吓人了
[问题起因] 在
docker
容器中运行程序的时候,提示bus error
错误。
# 总线报错
$ inv app.user_op --name=zhangsan
Bus error (core dumped)
[解决方法] 原因是在
docker
运行的时候,shm
分区设置太小导致share memory
不够。不设置--shm-size
参数时,docker
给容器默认分配的shm
大小为64M
,导致程序启动时不足。具体原因还是因为安装pytorch
包导致了,多进程跑任务的时候,docker
容器分配的共享内存太小,导致torch
要在tmpfs
上面放模型数据用于子线程的 共享不足,就出现报错了。
# 问题原因
root@18...35:/opt/app# df -TH
Filesystem Type Size Used Avail Use% Mounted on
overlay overlay 2.0T 221G 1.4T 3% /
tmpfs tmpfs 68M 0 68M 0% /dev
shm tmpfs 68M 41k 68M 1% /dev/shm# 启动docker的时候加上--shm-size参数(单位为b,k,m或g)
$ docker run -it --rm --shm-size=200m pytorch/pytorch:latest# 在docker-compose添加对应配置
$ shm_size: '2gb'
[解决方法] 还有一种情况就是容器内的磁盘空间不足,也会导致
bus error
这样的报错,所以如果出现了,清除多余文件和目录或者分配一个大的磁盘空间,就可以解决了。
# 磁盘空间不足
$ df -Th
Filesystem Type Size Used Avail Use% Mounted on
overlay overlay 1T 1T 0G 100% /
shm tmpfs 64M 24K 64M 1% /dev/shm
10Docker NFS 挂载报错
NFS 挂载之后容器程序使用异常为内核版本太低导致的
[问题起因] 我们将服务部署到
openshift
集群中,启动服务调用资源文件的时候,报错信息如下所示。从报错信息中,得知是在Python3
程序执行read_file()
读取文件的内容,给文件加锁的时候报错了。但是奇怪的是,本地调试的时候发现服务都是可以正常运行的,文件加锁也是没问题的。后来发现,在openshift
集群中使用的是NFS
挂载的共享磁盘。
# 报错信息
Traceback (most recent call last):......File "xxx/utils/storage.py", line 34, in xxx.utils.storage.LocalStorage.read_file
OSError: [Errno 9] Bad file descriptor
# 文件加锁代码
...with open(self.mount(path), 'rb') as fileobj:fcntl.flock(fileobj, fcntl.LOCK_EX)data = fileobj.read()return data
...
[解决方法] 从下面的信息得知,要在
Linux
中使用flock()
的话,就需要升级内核版本到2.6.11+
才行。后来才发现,这实际上是由RedHat
內核中的一个错误引起的,并在kernel-3.10.0-693.18.1.el7
版本中得到修复。所以对于NFSv3
和NFSv4
服务而已,就需要升级Linux
内核版本才能够解决这个问题。
# https://t.codebug.vip/questions-930901.htm
$ In Linux kernels up to 2.6.11, flock() does not lock files over NFS (i.e.,
the scope of locks was limited to the local system). [...] Since Linux 2.6.12,
NFS clients support flock() locks by emulating them as byte-range locks on the entire file.
11Docker 使用默认网段
启动的容器网络无法相互通信,很是奇怪!
[问题起因] 我们在使用
Docker
启动服务的时候,发现有时候服务之前可以相互连通,而有时启动的多个服务之前却出现了无法访问的情况。究其原因,发现原来是因为使用的内部私有地址网段不一致导致的。有的服务启动到了172.17 - 172.31
的网段,有的服务跑到了192.169.0 - 192.168.224
的网段,这样导致服务启动之后出现无法访问的情况(默认情况下,有下面这个两个网段可供其使用)。
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服务启动串台
# 可以将目录结构调整为如下所示
A: /data/app1/docker-compose.yml
B: /data/app2/docker-compose.ymlA: /data1/app-old/docker-compose.yml
B: /data2/app-new/docker-compose.yml
或者使用
docker-compose
命令提供的参数-p
手动指定标签,来规避该问题的发生。
# 指定项目项目名称
$ docker-compose -f ./docker-compose.yml -p app1 up -d
13Docker 命令调用报错
在编写脚本的时候常常会执行 docker 相关的命令,但是需要注意使用细节!
[问题起因]
CI
更新环境执行了一个脚本,但是脚本执行过程中报错了,如下所示。通过对应的输出信息,可以看到提示说正在执行的设备不是一个tty
。
Docker命令调用报错
随即,查看了脚本发现报错地方是执行了一个
exec
的docker
命令,大致如下所示。很奇怪的是,手动执行或直接调脚本的时候,怎么都是没有问题的,但是等到CI
调用的时候怎么都是有问题。后来好好看下,下面这个命令,注意到-it
这个参数了。
# 脚本调用docker命令
docker exec -it <container_name> psql -Upostgres ......
我们可以一起看下
exec
命令的这两个参数,自然就差不多理解了。
编号 | 参数 | 解释说明 |
---|---|---|
1 |
-i /-interactive
|
即使没有附加也保持 STDIN 打开;如果你需要执行命令则需要开启这个选项 |
2 |
-t /–tty
|
分配一个伪终端进行执行;一个连接用户的终端与容器 stdin 和 stdout 的桥梁 |
[解决方法]
docker exec
的参数-t
是指Allocate a pseudo-TTY
的意思,而CI
在执行job
的时候并不是在TTY
终端中执行,所以-t
这个参数会报错。同时在 『stackoverflow』也有人给出原因,可以自行查看。
Docker命令调用报错
14Docker 定时任务异常
在 Crontab 定时任务中也存在 Docker 命令执行异常的情况!
[问题起因] 今天发现了一个问题,就是在备份
Mysql
数据库的时候,使用docker
容器进行备份,然后使用Crontab
定时任务来触发备份。但是发现备份的MySQL
数据库居然是空的,但是手动执行对应命令切是好的,很奇怪。
# Crontab定时任务
0 */6 * * * \docker exec -it <container_name> sh -c \'exec mysqldump --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本身其实已经正确地处理了引号的使用
docker run -it --rm -e TEST_VAR="test" test:latest
[解决方法] 得到的结论就是,因为
Compose
解析yaml
配置文件,发现引号也进行了解释包装。这就导致原本的TEST_VAR="test"
被解析成了'TEST_VAR="test"'
,所以我们在引用的时候就无法获取到对应的值。现在解决方法就是,不管是我们直接在配置文件添加环境变量或者使用env_file
配置文件,能不使用引号就不适用引号。需要注意的是环境变量配置的是日志格式的话(
2022-01-01
),如果使用的是Python
的yaml.load
模块的话,会被当做是date
类型的,这是如果希望保持原样信息的话,可以使用'
/"
引起来将其变成字符串格式的。
16Docker 删除镜像报错
无法删除镜像,归根到底还是有地方用到了!
[问题起因] 清理服器磁盘空间的时候,删除某个镜像的时候提示如下信息。提示需要强制删除,但是发现及时执行了强制删除依旧没有效果。
# 删除镜像
$ docker rmi 3ccxxxx2e862
Error response from daemon: conflict: unable to delete 3ccxxxx2e862 (cannot be forced) - image has dependent child images# 强制删除
$ dcoker rmi -f 3ccxxxx2e862
Error response from daemon: conflict: unable to delete 3ccxxxx2e862 (cannot be forced) - image has dependent child images
[解决方法] 后来才发现,出现这个原因主要是因为
TAG
,即存在其他镜像引用了这个镜像。这里我们可以使用如下命令查看对应镜像文件的依赖关系,然后根据对应TAG
来删除镜像。
# 查询依赖 - image_id表示镜像名称
$ docker image inspect --format='{{.RepoTags}} {{.Id}} {{.Parent}}' $(docker image ls -q --filter since=<image_id>)# 根据TAG删除镜像
$ docker rmi -f c565xxxxc87f
# 删除悬空镜像
$ docker rmi $(docker images --filter "dangling=true" -q --no-trunc)
17Docker 普通用户切换
切换 Docker 启动用户的话,还是需要注意下权限问题的!
[问题起因] 我们知道在
Docker
容器里面使用root
用户的话,是不安全的,很容易出现越权的安全问题,所以一般情况下,我们都会使用普通用户来代替root
进行服务的启动和管理的。今天给一个服务切换用户的时候,发现Nginx
服务一直无法启动,提示如下权限问题。因为对应的配置文件也没有配置var
相关的目录,无奈24 个 Docker 常见问题处理技巧相关推荐
- 收藏!24 个 Docker 疑难杂症处理技巧(全网最全)
✌ 作者简介:信年✘ ✌,大家可以叫我 ❤信年❤ ,一位精通五门语言的博主 ✌
- 求职应聘面试常见问题回答技巧
求职应聘面试常见问题回答技巧 1.请你自我介绍一下你自己? 回答提示:一般人回答这个问题过于平常,只说姓名.年龄.爱好.工作经验,这些在简历上都有.其实,企业最希望知道的是求职者能否胜任工作,包括:最 ...
- Docker常见问题处理
Docker常见问题处理 原文作者 一.Docker迁移存储目录 问题起因 [解决方法1]添加软链接 [解决方法2]改动docker配置文件 注意事项 二.Docker设备空间不足 [问题起因一] [ ...
- Docker常见问题
Docker常见问题 1.Docker 和虚拟机有啥不同? Docker 是轻量级的沙盒,在其中运行的只是应用,虚拟机里面还有额外的系统. 2.Docker 安全么? Docker 利用了 Lin ...
- docker瘦身技巧
docker瘦身技巧 一.简介 docker镜像太大,带来以下几个问题: 1. 存储开销 这块影响其实不算大,因为对服务器磁盘来说,15GB的存储空间不算大,除非用户磁盘空间很紧张. 2. 部署事件 ...
- 24 个常见的 Docker 疑难杂症处理技巧
转自:Escapelife 的博客 原文:https://tinyurl.com/2p89skum 这里主要是为了记录在使用 Docker 的时候遇到的问题及其处理解决方法. 1Docker 迁移存储 ...
- Hive 常见问题与技巧【Updating】
2019独角兽企业重金招聘Python工程师标准>>> 1Q: 是否有像类似于phpmyadmin一样的hive查询客户端,能以界面的方式查询hive语句和导出数据 A: 有的,客户 ...
- 面试常见问题回答技巧(70题)
面试过程中我们往往会遇到很多的提问,有时候容易卡壳,这里基本涵盖了绝大部分面试可能出现的提问,主要是讲针对提问我们应该从哪些方面去回答,给新人或者初入职场的童鞋一点参考指导 1.请你自我介绍一下你自己 ...
- 齐博模板直接写mysql_齐博CMS使用常见问题和技巧汇总
齐博CMS技巧:分享风格如何把标签内容也分享 除了风格配置文件/data/style/xxx.php与模板目录/template/xxx/及图片CSS目录/images/XXX/之外,大家平时最容易忽 ...
最新文章
- thinkphp分页格式的完全自定义,直接输入数字go到输入数字页
- 转 fiddler教程
- httprunner框架学习总结
- mysql 动态传入表名 存储过程_面试再问MySQL存储过程和触发器就把这篇文章给他...
- 参数php_干净的PHP代码-函数参数
- vue 保存时清空iuput_Vue 一键清空表单的实现方法
- 我的世界服务器氪金系统怎么做,[经济]PPRMB销售系统 1.3.1 —— 地图扫码自动到账,氪金系统如此简单[全版本]...
- 2022 年面试工具篇 Jmeter 接口面试题及答案
- GitLab Admin Area
- 两行Python代码调整视频的亮度
- ES7241D低功耗音频ADC芯片##小爱音响
- 读书笔记 《第二章 复盘之道》
- 759页14万字智慧大楼弱电智能化规划设计方案
- Nacos 1.1.0发布,支持灰度配置和地址服务器模式
- 「医疗行业」DevExpress助力上海一院HIS系统稳定升级
- 不要迷失在技术的海洋中
- 翻转课堂教学模式研究
- 抖音旅游号视频文案技巧
- pwm 正弦波_CC6420 低噪声,高效率,5V/12V 450mA 单相正弦波直流无刷马达驱动
- Linux麒麟系统中文乱码,ubuntu麒麟系统tomcat中文乱码怎么办?ubuntu tomcat中文显示乱码解决方法...
热门文章
- 收藏!24 个 Docker 疑难杂症处理技巧(全网最全)