1. 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
2.Docker 命令调用报错
在编写脚本的时候常常会执行 docker 相关的命令，但是需要注意使用细节！
[问题起因] CI 更新环境执行了一个脚本，但是脚本执行过程中报错了，如下所示。通过对应的输出信息，可以看到提示说正在执行的设备不是一个 tty。
随即，查看了脚本发现报错地方是执行了一个 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 这个参数会报错。
3.Docker 定时任务异常
在 Crontab 定时任务中也存在 Docker 命令执行异常的情况！
[问题起因] 今天发现了一个问题，就是在备份 Mysql 数据库的时候，使用 docker 容器进行备份，然后使用 Crontab 定时任务来触发备份。但是发现备份的 MySQL 数据库居然是空的，但是手动执行对应命令切是好的，很奇怪。
# Crontab定时任务
*/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 的桥梁 |
4.Docker 变量使用引号
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 类型的，这是如果希望保持原样信息的话，可以使用 '/" 引起来将其变成字符串格式的。
5.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
# 删除悬空镜像
$ docker rmi $(docker images --filter "dangling=true" -q --no-trunc)
6.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 服务启动时候需要的文件都配置到一个无权限的目录，即可解决。
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.*;
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;
}
7.Docker 绑定到 IPv6 上
Docker 服务在启动的时候，将地址绑定到 IPv6 地址上面了，提示报错信息！
[问题起因] 物理机器更新了对应补丁之后，重启了服务，导致原本可以正常启动的 docker-compose 服务提示如下报错信息。不清楚是否修改了操作系统的相关配置，还是对应 docker 进行的其他方面的配置，比如修改 /etc/docker/daemon.json 或者 docker 的 service 启动文件。
# Docker的报错信息
docker run -p 80:80 nginx:alpine succeeds. Previously, this was failing with Error \
starting userland proxy: listen tcp6 [::]:80: socket: address family not supported by protocol.
[解决方法] 通过如上所示的报错信息，可以看到服务的启动端口绑定到了 tcp6 上面了，但是对应的 socket 发现系统本身并不支持。这时，我们一看下对应的操作系统 ipv6 的设置，发现系统禁用了，所有的 ipv6 地址。
# 操作系统配置
$ cat /etc/sysctl.conf | grep ipv6
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.0:80:80/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": "2001:db8:1::/64"
}
# 重启服务
$ systemctl reload docker
[方法三] Docker 默认情况下会同时将端口映射于 IPv4 与 IPv6 两者上，而且有的时候会出现只绑定到了 IPv6，导致服务无法正常访问的情况。现在通用的始终还是 IPv4 地址，因此简单的做法就是关闭 IPv6 地址。
# 修改系统配置
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/networking restart
# 后检测是否已关闭IPv6
ip addr show | grep net6
8.Docker 容器启动超时
Docker 服务在启动的时候，提示超时，被直接终止了！
[问题起因] 使用 docker-compose 启动容器的时候，等待了很久的时候(大约 2-3 分钟左右)，之后提示如下信息。通过阅读信息内容，可以看到是因为超时导致的，提示可以通过设置环境变量，加大超时的时间。
$ docker-compose up -d
ERROR: for xxx UnixHTTPConnectionPool(host='localhost', port=None): Read timed out. (read timeout=70)
ERROR: An HTTP request took too long to complete. Retry with --verbose to obtain debug information.
If you encounter this issue regularly because of slow network conditions, consider setting COMPOSE_HTTP_TIMEOUT to a higher value (current value: 60).
[解决方法] 按照提示设置的环境变量之后，再次启动发现确实可以正常启动了，但是还是能够感觉到有些慢。
$ sudo vim /etc/profile
export COMPOSE_HTTP_TIMEOUT=500
export DOCKER_CLIENT_TIMEOUT=500
排除了下启动流程，因为容器启动有映射目录到容器里面且目录大小比较大，所以怀疑是因为 i/o 导致的。随即使用 iotop 命令查看服务器目前的 i/o 情况，发现存在很多个 rg 命令，且都处于 左右。查了下，发现是 vscode 远程服务器启动的搜索目录结构的进程，西八，有些坑呀！
$ sudo iotop
4269 be/4 escape 15.64 K/s 0.00 B/s 0.00 % 98.36 % rg --files --hidden
4270 be/4 escape 28.15 K/s 0.00 B/s 0.00 % 97.46 % rg --files --hidden
4272 be/4 escape 31.27 K/s 0.00 B/s 0.00 % 97.39 % rg --files --hidden
4276 be/4 escape 34.40 K/s 0.00 B/s 0.00 % 96.98 % rg --files --hidden
9.Docker 端口网络限制
如果发现服务都一切正常，但是无法无法访问的话，则多为网络问题！
[问题起因] 启用服务之后，登录跳转发现直接 502 报错了。排除了配置等相关原因都没有任何问题(做过相关测试)，这就非常奇怪了！
# 部署服务架构
nginx(80) -> web1(8080)
-> web2(8081)
# 报错信息如下所示
nginx connect() failed (113: No route to host) while connecting to upstream
[解决方法] 根据错误信息可知，是因为没有路由到指定的 host 导致了，随即看了下防火墙是开着的，看了日志发现被过滤掉了，西八！问题找到了，现在需要做的就是，要么添加防火墙规则，要么关闭防火墙。
# 检查开放的端口
$ sudo firewall-cmd --permanent --zone=public --list-ports
# 开启需要路由的端口
$ sudo firewall-cmd --permanent --zone=public --add-port=8080/tcp
$ sudo firewall-cmd --permanent --zone=public --add-port=8081/tcp
# 配置立即生效
firewall-cmd --reload
# 关闭防火墙
$ sudo systemctl stop firewalld.service
# 禁用自启动
$ sudo systemctl disable firewalld.service
10.Docker 无法获取镜像
新初始化的机器，无法获取私有仓库的镜像文件！
[问题起因] 机器初始化之后，使用如下命令登录私有 docker 仓库，发现提示无法获取对应镜像，但是在其他机器上面获取该镜像就可以执行成功，这就非常奇怪了！
# 登录私有仓库
$ echo '123456' | docker login -u escape --password-stdin docker.escapelife.site
# 异常信息提示
$ sudo docker pull docker.escapelife.site/app:0.10
Error response from daemon: manifest for docker.escapelife.site/app:0.10 not found: manifest unknown: manifest unknown
[解决方法] 太坑了，我还以为我发现某个隐藏的 bug 了，可劲的排查，后发现，原来是自己镜像包名字写错了，应该写成 0.0.10 的，自己却写成了 0.10。这里，纪念一下，以后碰到上述报错，那肯定是镜像不存在的。
# 登录私有仓库之后会在用户家目录下生成一个docker配置
# 其用来记录docker私有仓库的登录认证信息(是加密过的信息但不安全) => base64
$ cat .docker/config.json
{
"auths": {
"docker.escapelife.site": {
"auth": "d00u11Fu22B3355VG2xasE12w=="
}
}
}
11.Docker 使容器不退出
如何使使用 docker-compose 启动的容器服务 hang 住而不退出
[问题起因] 有时候我们启动的服务，因为某些问题(bug)导致服务无法正常启动，就会出现容器无限重启(restart: on-failure)的情况，这时就很不利于排除问题。
➜ docker ps -a
4e6xxx9a4 app:latest "/xxx/…" 26 seconds ago Restarting (1) 2 seconds ago
[解决方法] 这时我们就需要根据，服务构建使用命令来决定是用什么命令来 hang 住服务。卡住的原理，就类似于使用 /bin/bash 进入容器是一样的，这里我就不过多解释了。
# 类似原理
docker run -it --rm --entrypoint=/bin/bash xxx/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: ["while true; do sleep 30; done;"]
# command: ["sleep"]
# args: ["infinity"]
12.Docker 不使用默认网段
有些情况，内部规划的网段和可能和 Dockerd 默认的网段有冲突，导致异常出现！
[问题起因] 今天在新机器上面，部署了一整套服务(多台机器)，服务部署完毕之后，通过前置 Nginx 服务发现并不能访问，后置机器开放的端口，发现发到对应端口的请求都没有转发出去。这就比较奇怪了，因为端口控制是已经开通了的，不应该出现不通的情况。
➜ nc -v 172.16.100.12 8000
nc: connect to 172.16.100.12 port 8000 (tcp) failed: Connection refused
[解决方法] 发现服务器端口不通，我这里怀疑可能是 dockerd 服务启动导致的，所以我先将服务都停掉，直接在机器上面启动了 Python 的服务端程序(Linux 机器自带 Python2.7.x 的版本)，然后在前置 Nginx 服务发现，端口确实是通的。后来，排除发现是内部服务默认网段和 dockerd 服务启动的默认网段是冲突的，导致重写了机器的防火墙规则，导致出现上述异常的。
$ python -m SimpleHTTPServer 8000
Serving HTTP on 0.0..0 port 8000 ...
➜ nc -v 172.16.100.12 8000
Connection to 172.16.100.12 8000 port [tcp/*] succeeded!
既然问题已经知道了，现在需要做的就是非常简单了：不适用默认网段！通过 『mirantis』 里面，我们可以选择进行设置，然后重启服务 dockerd 服务，即可。
# 修改配置
$ sudo cat /etc/docker/daemon.json
{
"default-address-pools":[{"base":"192.168.100.0/20","size":24}]
}
# 重启服务
$ sudo systemctl restart docker
# 启动服务验证是否生效
$ ip a
$ docker network inspect app | grep Subnet
这时，就到了考验我们网络的子网划分的能力了：如何在给定的网段下面合理且高效的进行划分呢？咳咳，确实难倒我了，这时我们可以再这个在线网站上面 JSON 在线解析 进行划分，然后选定合理的 base 和 size 就可以了。
# 报错信息
Error response from daemon: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network
# 按照下图我们可以对 pool 进行合理划分
# 给定 10.210.200.0 + 255.255.255.0 的网段来划分子网
$ sudo cat /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 了。
13.Docker 添加私有仓库
有些情况，我们服务器上面需要使用内部私有的容器镜像地址！
[问题起因] 如果新机器上面需要使用私有仓库的话，但是又没有配置，再获取镜像的时候就会出现如下报错信息。
# 拉取/登陆私库时提示
$ docker pull 192.168.31.191:5000/nginx:latest
x509: certificate signed by unknown authority
[解决方法] 该问题的处理方式很简单，如下所示，配置一下仓库地址，重启服务并登陆私有仓库就可以了。
# 添加配置
$ sudo cat /etc/docker/daemon.json
{
"insecure-registries": ["192.168.31.191:5000"]
}
# 重启docker
$ sudo systemctl restart docker
# 重新登录即可
$ docker login 私库地址 -u 用户名 -p 密码
14.Docker 解决时间同步
解决 Docker 容器时间时区和宿主机不同步的问题！
[问题起因] 有时间我们会遇到新创建的容器，容器内部和外部时间不一致，这就导致服务的日志、定时任务等不能按照我们既定的时间触发，非常麻烦。
# 容器内部时间(CST - 东八区 - 北京时间)
[root@server ~]# date
Fri Apr 27 22:49:47 CST 2022
# 容器外部时间(UTC - 格林尼治 - 标准时间)
[root@server ~]# docker run --rm nginx date
Fri Apr 27 14:49:51 UTC 2022
[解决方法] 宿主机设置了时区，而 Docker 容器并没有设置，导致两者相差 8 小时。
# 以 docker run 方式启动
$ docker run -d --name 'app' \
-v /etc/localtime:/etc/localtime \
escape/nginx:v1
# 以 Dockerfile 构建
ENV TimeZone=Asia/Shanghai
RUN ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
# 以 docker-compose 方式启动
environment:
TZ: Asia/Shanghai
作者：escape
来源：https://www.escapelife.site/posts/43a2bb9b.html
