docker守护进程停止期间保持容器运行 需求背景 默认情况下，当docker守护进程终止时，它将关闭正在运行的容器。比如修改daemon.json的配置、服务异常终止等，这些都会导致docker进程终止或者重启，同时导致所有容器停止或重启，这显然不是我们需要的运维方式和异常处理情况 知道了以上问题的缺陷，那是否有解决方法呢？答案是有的，我们可以配置docker守护进程，使得守护进程不可用时保持容器继续运行。这种功能称为实时恢复，有助于减少由于守护进程崩溃、计划中断或升级而导致的容器停机时间 如何配置 官方参考文档：https://docs.docker.com/engine/daemon/live-restore/ 具体配置方法： 修改配置文件 /etc/docker/daemon.json 增加内容: { "live-restore": true } 重载 docker 使得配置生效 systemctl reload docker 检查配置是否成功 docker info ｜ grep -i live 此时可以重启docker进程而容器不再跟随重启 service docker restart 群晖7.1.1 仅针对群晖7.1.1的配置方法，未在其它版本配置不能确定是否有效 群晖的配置文件不是在 /etc/docker/daemon.json 所以配置这里是不生效的 实际有效的配置文件是 /var/packages/Docker/etc/dockerd.json 修改的内容是一致的，然后重载生效 systemctl reload pkg-Docker-dockerd

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网络 docker集群网络理解 根据容器运行中显示的网卡，使用 docker network ls 查看了对应的docker网络： 10.255/16 ingress overlay swarn 172.21/16 mynets overlay swarn 172.18/16 docker_gwbridge bridge local 其中1、3是默认的，2是手动创建的，当然类型也是有所不同，1、2是overlay，3是bridge 这里来讲解下他们的异同、用处： 首先是1、2 它们的类型都是一样的，就只有默认、自定义的区别，那究竟有什么分别呢？ 默认的 ingress 承担了堆外暴露和负载均衡功能，我们 publish 后即可通过宿主机 ip 端口访问此服务并且负载均衡，而自定义 overlay 是不提供堆外暴露的，及时 publish 也无法通过宿主机 ip 端口访问，需要再增加一个 nginx + ingress 来提供堆外服务 自定义的 overlay 主要是承担服务之间的通信，当然 ingress 网络类型一样，也是有此功能的，但不侧重，再就是 自定义的可以提供更加细粒度的控制，比如不同服务之间分配不同的 overlay 来隔离 docker_gwbridge 主要提供了在不同宿主机上容器与容器、同一宿主机上容器与宿主机、容器与外部的访问，也就是除了同一宿主机下容器互访之外的其他网络需求，同一宿主机容器之间可以通过 overlay 直接互访 网络走向 请求是如何通过任意节点最终到达目的服务器的呢？ 包括 docker 自带的负载均衡如何转发？大概是如下流程： 请求先到宿主机nat表，DNAT请求到本地172.18.0.2网络 通过本地路由到地址为172.18.0.1的网络docker_gwbridge，每个宿主机本地都有一个172.18.0.1地址 docker_gwbridge网关找到172.18.0.2为ingress-sbox ingress-sbox接受请求后在mangle表的PREROUTING链打标记 mangle表的INPUT链根据标记转发到服务（service）的虚拟ip地址（实际上所有服务的虚拟ip地址都在ingress-sbox上配置） 请求准备发送到此虚拟ip，当到达nat表POSTROUTING链的时候被拦截，执行源地址转换，规则是所有目的地址是集群网段都转发到本机的ipvs虚拟地址 ingress-sbox的ipvs根据mangle的标记，再把请求发送到集群内指定服务容器的ip 参考文档 https://blog.csdn.net/weixin_36171533/article/details/81842036 https://www.jianshu.com/p/c83a9173459f https://www.cnblogs.com/www1707/p/10872748.html libnetwork 是 docker 容器网络库，最核心的内容是其定义的 Container Network Model (CNM)，这个模型对容器网络进行了抽象，由以下三类组件组成： Sandbox：Sandbox 是容器的网络栈，包含容器的 interface、路由表和 DNS 设置。 Linux Network Namespace 是 Sandbox 的标准实现。Sandbox 可以包含来自不同 Network 的 Endpoint Endpoint：Endpoint 的作用是将 Sandbox 接入 Network。Endpoint 的典型实现是 veth pair，后面我们会举例。一个 Endpoint 只能属于一个网络，也只能属于一个 Sandbox Network：Network 包含一组 Endpoint，同一 Network 的 Endpoint 可以直接通信。Network 的实现可以是 Linux Bridge、VLAN 等