关于docker:彻夜怒肝Docker-常见疑难杂症解决方案已撸完快要裂开了

74次阅读

共计 15876 个字符,预计需要花费 40 分钟才能阅读完成。

这里次要是为了记录在应用 Docker 的时候遇到的问题及其解决解决办法。

1.Docker 迁徙存储目录


默认状况零碎会将 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 配置文件

# 3. 改变 docker 启动配置文件
$ sudo vim /lib/systemd/system/docker.service
ExecStart=/usr/bin/dockerd --graph=/data/docker/
# 4. 改变 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 命令单纯复制文件内容的话,就会呈现属性不统一的状况,同时还会有肯定的平安问题。

2.Docker 设施空间有余

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: devicemapper
 Pool Name: docker-252:1-787932-pool
 Pool Blocksize: 65.54 kB
 Backing Filesystem: extfs
 Data file: /dev/loop0
 Metadata file: /dev/loop1
 Data Space Used: 1.225 GB
 Data Space Total: 107.4 GB
 Data Space Available: 16.78 MB
 Metadata Space Used: 2.073 MB
 Metadata 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 应用的空间扩大到整个文件系统。

# 查看零碎的 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.sh
  File: check_port_live.sh
  Size: 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 +0800
 Birth: -
# 磁盘的 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

3.Docker 缺共享链接库

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

4.Docker 容器文件损坏

对 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

5.Docker 容器优雅重启

不进行服务器下面运行的容器,重启 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
        }
    ]
}

6.Docker 容器无奈删除

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

问题起因:明天遇到 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

7.Docker 容器中文异样

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

问题起因:明天登陆之前部署的 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

8.Docker 容器网络互通

理解 Docker 的四种网络模型

问题起因:在本机部署 Nginx 容器想代理本机启动的 Python 后端服务程序,然而对代码服务如下的配置,后果拜访的时候始终提醒 502 谬误。

# 启动 Nginx 服务
$ docker run -d -p 80:80 $PWD:/etc/nginx 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 default
    link/ether 02:42:d5:4c:f2:1e brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::42:d5ff:fe4c:f21e/64 scope link
       valid_lft forever preferred_lft forever
nginx
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

9.Docker 容器总线谬误

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

问题起因:在 docker 容器中运行程序的时候,提醒 bus error 谬误。

# 总线报错
$ inv app.user_op --name=zhangsan
Bus error (core dumped)

解决办法:起因是在 docker 运行的时候,shm 分区设置太小导致 share memory 不够。不设置 –shm-size 参数时,docker 给容器默认调配的 shm 大小为 64M,导致程序启动时有余。

# 启动 docker 的时候加上 --shm-size 参数(单位为 b,k,m 或 g)
$ docker run -it --rm --shm-size=200m pytorch/pytorch:latest

解决办法:还有一种状况就是容器内的磁盘空间有余,也会导致 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

10.Docker 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.

11.Docker 默认应用网段

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

问题起因:咱们在应用 Docker 启动服务的时候,发现有时候服务之前能够互相连通,而有工夫启动的多个服务之前却呈现了无法访问的状况。究其原因,发现原来是因为应用的外部公有地址网段不统一导致的。有点服务启动到了 172.17 – 172.31 的网段,有的服务跑到了 192.169.0 – 192.168.224 的网段,这样导致服务启动之后呈现无法访问的状况。

解决办法:上述问题的解决形式,就是手动指定 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": []}
    }
}

12.Docker 服务启动串台

应用 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,所以启动的时候被认为是同一个,这就呈现了上述的问题。如果须要深刻理解的话,能够去看对应源代码。

# 能够将目录结构调整为如下所示
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 -p app1 up -d

13.Docker 命令调用报错

在编写脚本的时候经常会执行 docker 相干的命令,然而须要留神应用细节!

问题起因:CI 更新环境执行了一个脚本,然而脚本执行过程中报错了,如下所示。通过对应的输入信息,能够看到提醒说正在执行的设施不是一个 tty。

随即,查看了脚本发现报错中央是执行了一个 exec 的 docker 命令,大抵如下所示。很奇怪的是,手动执行或间接调脚本的时候,怎么都是没有问题的,然而等到 CI 调用的时候怎么都是有问题。起初好好看下上面这个命令,留神到 -it 这个参数了。

# 脚本调用 docker 命令
docker exec -it <container_name> psql -Upostgres ......
咱们能够一起看下 exec 命令的这两个参数,天然就差不多了解了。-i/-interactive #即便没有附加也放弃 STDIN 关上;如果你须要执行命令则须要开启这个选项
-t/–tty #调配一个伪终端进行执行;一个连贯用户的终端与容器 stdin 和 stdout 的桥梁

解决办法:docker exec 的参数 -t 是指 Allocate a pseudo-TTY 的意思,而 CI 在执行 job 的时候并不是在 TTY 终端中执行,所以 -t 这个参数会报错。

14.Docker 定时工作异样

在 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 选项。

-i/-interactive #即便没有附加也放弃 STDIN 关上;如果你须要执行命令则须要开启这个选项
-t/–tty  #调配一个伪终端进行执行;一个连贯用户的终端与容器 stdin 和 stdout 的桥梁

15.Docker 变量应用引号

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

问题起因:应用过 compose 的同学可能都遇到过,咱们在编写启动配置文件的时候,增加环境变量的时候到底是应用单引号、双引号还是不应用引号。工夫长了,可能咱们总是三者是一样的,能够互相应用。然而,直到最初咱们发现坑越来越多,越来越费解。

反正我是遇到过很多是因为增加引号导致的服务启动问题,起初得出的论断就是一律不实用引号。裸奔,体验前所未有的痛快!直到现在看到了 Github 中对应的 issus 之后,才终于破案了。

# TESTVAR="test"
在 Compose 中进行援用 TESTVAR 变量,无奈找到
# TESTVAR=test
在 Compose 中进行援用 TESTVAR 变量,能够找到
# docker run -it --rm -e TESTVAR="test" test:latest
起初发现 docker 自身其实曾经正确地解决了引号的应用

解决办法:失去的论断就是,因为 Compose 解析 yaml 配置文件,发现引号也进行了解释包装。这就导致本来的 TESTVAR=”test” 被解析成了 ‘TESTVAR=”test”‘,所以咱们在援用的时候就无奈获取到对应的值。当初解决办法就是,不论是咱们间接在配置文件增加环境变量或者应用 env_file 配置文件,能不应用引号就不实用引号。

  1. Docker 删除镜像报错

无奈删除镜像,归根到底还是有中央用到了!

问题起因:清理服器磁盘空间的时候,删除某个镜像的时候提醒如下信息。提醒须要强制删除,然而发现及时执行了强制删除仍旧没有成果。

# 删除镜像
$ 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
bash
# 删除悬空镜像
$ docker rmi $(docker images --filter "dangling=true" -q --no-trunc)

17.Docker 普通用户切换

切换 Docker 启动用户的话,还是须要留神下权限问题的!

问题起因:咱们都晓得在 Docker 容器外面应用 root 用户的话,是不平安的,很容易呈现越权的平安问题,所以个别状况下,咱们都会应用普通用户来代替 root 进行服务的启动和治理的。明天给一个服务切换用户的时候,发现 Nginx 服务始终无奈启动,提醒如下权限问题。因为对应的配置文件也没有配置 var 相干的目录,无奈 ????‍♀!️

# Nginx 报错信息
nginx: [alert] could not open error log file: open() "/var/log/nginx/error.log" failed (13: Permission denied)
2020/11/12 15:25:47 [emerg] 23#23: mkdir() "/var/cache/nginx/client_temp" failed (13: Permission denied)

解决办法:起初发现还是 nginx.conf 配置文件,配置的有问题,须要将 Nginx 服务启动时候须要的文件都配置到一个无权限的目录,即可解决。

nginx
user  www-data;
worker_processes  1;
error_log  /data/logs/master_error.log warn;
pid        /dev/shm/nginx.pid;
events {worker_connections  1024;}
http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;
    gzip               on;
    sendfile           on;
    tcp_nopush         on;
    keepalive_timeout  65;
    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;
}

史上最全、最具体的 Docker 学习材料  举荐给你看一看。

作者: Escape
链接: https://escapelife.github.io/…

正文完
 0