搜索到
22
篇与
的结果
-
docker报错之 archive/tar: invalid tar header 导入镜像报错 正常安装docker服务后发现导入镜像出现如下错误: Error processing tar file(exit status 1): archive/tar: invalid tar header 解决方法 经过排查，是因为导入的镜像的 docker 版本与当前机器的 docker 版本不符合，但尝试升级docker 版本之后发现仍然是此错误，继续排查发现 docker info 存在 client version 和 server version，使用yum默认只升级了 client version， server version需要重启服务才能使用最新版 -
docker nginx的真实ip地址问题 需求背景 使用 docker swarm 集群来安装 nginx 有一个问题，nginx获取到的客户端地址是内网ip，通过初步排查，发现这几个ip都是 nginx 启动在 docker 节点上的 bridge 网络网关地址 影响 这样nginx仍然有办法获取到真实ip的，但是需要多层nginx，然后通过上一层添加到请求头 X-Forwarded-For 中 但是对于其他应用，不能主动获取 http 头部的程序，甚至是 tcp 应用，就没有那么容易修改、获取真实的客户端 ip 地址了，那此时应该如何处理呢？ 方案 解决方案一共有两个： 启动服务的时候端口设置为 host 模式，那么监听就会绑定在对应物理机的接口上，从而可以实现获取客户端真实的 ip 地址。但这个方法也是有缺点的，一旦使用 host 模式，那么就无法实现负载均衡（无法访问其他docker节点端口来访问到此服务），之前很早就使用的这个办法，为了让其他节点都能提供服务，于是在每个节点都启动了一份 nginx docker 官方到今天仍然没有给出很好的解决方案，这是一个长达8年的讨论（2016~2024） # 超长时间的讨论 https://github.com/moby/moby/issues/25526 但是根据帖子的内容，第三方开发者给出了以下解决方案： https://github.com/newsnowlabs/docker-ingress-routing-daemon 后续尝试使用，但是有几个点需要注意，是否影响性能、是否在已有docker swarm集群中能够使用、在使用后能否在docker swarm集群中移除、添加节点扩展、提权、降级节点等
-
docker挂载文件修改不同步、未同步 背景 某次修改宿主机挂载到 docker 容器上的文件内容后，在容器内查看文件内容出现错误 英文环境：stale file headle 中文环境：文件句柄失效 后面经过测试，还可能出现文件内容不一致，容器内的没有同步修改 原因 经过检索后，确定了问题：docker 挂载文件时，并不是挂载了某个文件的路径，而是挂载了文件的inode 某些编辑器(vi)在编辑保存文件时，采用了备份、替换的策略，即编辑过程中，将变更写入新文件，保存时，再将备份文件替换原文件，此时会导致文件的inode发生变化。原inode对应的文件其实并没有发生修改。 解决办法 避免使用 vim ，它会执行这种策略，或者设置 backupcopy=yes 文件权限修改为 666 或者 777， vim 则会保持 inode 不变 经过测试，及时没有使用上面的方法， vim 不是都会修改 inode 号，目前还没有发现规律（什么时候才会更换 inode），但为了保险，建议后续修改文件的时候都按照要求
-
docker网络的疑难问题之三 前提背景 20240701 继之前的docker网络的dns解析问题 疑难问题如鲠在喉，如果不能解决，始终是一个风险，这里记录下来，尽快找到办法解决 关于 dns 解析的问题，现象为：如果本机宿主机上同时配置了VIP+BIND容器，这也是我们需要的模式，并且本机/etc/resolv.conf配置了VIP作为nameserver，那么其他容器则无法解析外网地址，容器内默认的/etc/resolv.conf配置为127.0.0.11。其他机器容器可以正常解析。这个情况在之前的帖子已经追踪过，经过排查后发现可能是NAT有问题，所以BIND服务不能使用与其他容器相同的overlay网络，而是改成host模式，当然目前来看，为了保证必定不出问题，最好是把bind服务隔离到单独的一台机器上，这样就完全避免了本机的nat转换错误问题 关于容器内访问 nginx 错误问题 从其他容器访问nginx，发现必定出现两次拒绝，一次可以访问。发现正好对应了 nginx 有三个副本，便使用 curl -v 查看了访问的ip地址，都是一样的。 [root@253258ad95d3 /]# curl http://nginx curl: (7) Failed connect to nginx:80; 拒绝连接 [root@253258ad95d3 /]# curl http://nginx curl: (7) Failed connect to nginx:80; 拒绝连接 [root@253258ad95d3 /]# curl http://nginx <html> <head><title>301 Moved Permanently</title></head> <body> <center><h1>301 Moved Permanently</h1></center> <hr><center>nginx</center> </body> </html> 查询三个 nginx 容器的ip地址，可以看到其实容器内部访问过程中还是有负载均衡的，如果是多个副本，并不会直接访问到某一个节点上，而是访问到了另外一个ip 172.21.1.185 # 其他容器curl http://nginx 解析的ip 172.21.0.200 # 节点一ip 172.21.11.227 # 节点二ip 172.21.23.214 # 节点三ip 第一个IP是容器内dns解析到的VIP（docker swarm VIP策略），另外三个则是 nginx 服务器的 3 副本实际ip 可以猜测是到了overlay网络的负载均衡地址，而overlay网络的VIP模式负载均衡是用ipvs实现的。那么如何证明呢？ 我们可以进入 /var/run/docker/netns 目录下，这里包括了本机的容器、网络配置的命名空间。其中有几个特殊的是网络的，可以看到其中有一个是 lb_1jo63pzkt，这个前缀 lb + 后面的 id 刚好是我们需要的overlay id，所以基本上确定是这个 使用命令进入 nsenter --net=lb_1jo63pzkt sh 接着可以使用命令查询防火墙规则和ipvs规则，需要注意的是，这里的命令是调用的宿主机操作系统命令，所以宿主机需要提前安装ipvs，yum -y install ipvsadm 查看防火墙mangle规则： iptables -L -t mangle -n MARK all -- 0.0.0.0/0 172.21.1.185 MARK set 0x11e 第一行是 nginx 的VIP规则，其中最后的MARK打标值为 0x11e，转换为10进制为286 接着查看 ipvs 规则: ipvsadm -l FWM 286 rr -> 172.21.0.200:0 Masq 1 0 0 -> 172.21.11.227:0 Masq 1 0 0 -> 172.21.23.214:0 Masq 1 0 0 根据MARK值286可以找到对应的三个转发条目。那么172.21.1.185是怎么回事呢？如何解释呢？ 既然打标和转发都有了，可以确定172.21.1.185 ip应该是在本机的，否则怎么转发呢？ 所以通过 ifconfig命令查看，发现此ip在接口上，同时可以看到此接口还有非常多的额外ip，应该都是其他容器的VIP地址，附加到这里做ipvs转发 最终方案 选择解藕服务，前面增加4层nginx，高可用放到此处，VIP也不再放到docker集群中，docker集群只需要保证自身的集群高可用即可，docker中再运行7层nginx，接受4层的请求。至此VIP所在机器上的容器无法解析dns的问题解决 20240702 nginx启动 docker service create --name nginx \ --mount type=bind,src=/docker/others/nginx/conf,dst=/usr/local/nginx/conf \ --mount type=bind,src=/docker/others/nginx/conf.d,dst=/usr/local/nginx/conf.d \ --mount type=bind,src=/docker/others/nginx/logs,dst=/usr/local/nginx/logs \ --network mynets \ -p target=80,published=80 \ -p target=443,published=443 \ -p target=8080,published=8080 \ --constraint node.role==manager \ --replicas 1 \ harbor.succez.com/sz/nginx-v20220701v1
-
docker镜像id、摘要digests 简单说明 一般我们使用 docker images 显示的 ID 是镜像 ID，也可以通过 docker images --no-trunc 来显示完整的 ID，它是可以用来启动容器的 其一 [root@localhost ~]# docker images REPOSITORY TAG IMAGE ID CREATED SIZE python3-rpa-crm 2024070501 6cda696a98ad 3 weeks ago 2.48GB harbor.succez.com/sz/python3-rpa-crm 2024070501 6cda696a98ad 3 weeks ago 2.48GB python3-rpa-os-common 2024070501 e4f1cbc709c9 3 weeks ago 2.48GB 其二 [root@localhost ~]# docker images --no-trunc REPOSITORY TAG IMAGE ID CREATED SIZE python3-rpa-crm 2024070501 sha256:6cda696a98ad4fefa3c429550341cd3cc9ad94573a3712fb15223cdcfe7a4d56 3 weeks ago 2.48GB harbor.succez.com/sz/python3-rpa-crm 2024070501 sha256:6cda696a98ad4fefa3c429550341cd3cc9ad94573a3712fb15223cdcfe7a4d56 3 weeks ago 2.48GB python3-rpa-os-common 2024070501 sha256:e4f1cbc709c9a4f2cbe8ab329ef5fa32a37745b938883bbd27555b7d003fc471 3 weeks ago 2.48GB 但如果用 docker inspect CONTAINER_ID 查看容器的详细信息，发现启动的镜像通常与 IMAGE ID 不一致，需要这样看是因为经常指定镜像的 latest 标签，会出现此镜像本地存在但启动容器报错无此镜像，所以需要通过查看容器明细来确定使用的哪个镜像。 而 docker inspect CONTAINER_ID 实际上显示的镜像的摘要，所以不管使用 docker images 还是 docker images --no-trunc 都会找不到此镜像，需要使用 --digtests 参数来显示镜像的摘要信息 其三 [root@localhost ~]# docker images --digests REPOSITORY TAG DIGEST IMAGE ID CREATED SIZE python3-rpa-crm 2024070501 <none> 6cda696a98ad 3 weeks ago 2.48GB harbor.succez.com/sz/python3-rpa-crm 2024070501 sha256:c7e46b2080146cfc5870f6b1580faa2a3c67e235537e988921ba2c7348a11f9b 6cda696a98ad 3 weeks ago 2.48GB python3-rpa-os-common 2024070501 <none> e4f1cbc709c9 3 weeks ago 2.48GB 此时镜像ID仍然是有的，前面多了一列 DIGEST，此摘要也是可以用来启动容器的。 有一种情况是如果使用 latest 标签，即使本地存在符合名称的镜像，仍然可能会去拉取最新的 latest 镜像，所以如果我们想启动此镜像，可以指定镜像名+摘要的方式即可
