Docker run命令作用于已有容器的效果及修改somaxconn的疑问

好问题！你观察到的现象其实是Docker网络命名空间共享机制带来的效果，咱们一步步拆解清楚你的疑问：

• 你的docker run命令没有重启或重建原有的redis容器
  docker run的核心作用始终是创建并启动一个新容器，这一点没有变。你执行的命令docker run --net=container:redis --sysctl net.core.somaxconn=65535 bash，实际上创建了一个全新的临时bash容器，它和你的redis容器没有任何“替换”或“重启”关系——你可以通过docker ps -a看到，redis容器的状态还是Up，创建时间也和之前一致，而新的bash容器要么已经退出（因为没有交互终端的话bash会立刻停止），要么处于运行状态（如果加了-it参数）。

• 为什么redis容器的somaxconn值被修改了？
  关键在于--net=container:redis这个参数：它让新创建的bash容器共享redis容器的网络命名空间。Linux系统中，net.core.somaxconn是网络命名空间级别的配置项——也就是说，同一个网络命名空间里的所有进程共享这个参数值。当你在新的bash容器里设置这个sysctl参数时，其实是直接修改了redis容器所在的网络命名空间的配置，因此redis容器里的进程自然会读取到更新后的值，整个过程完全不需要重启redis容器。

• 这种修改的局限性
  要注意，这种方式的修改是临时的：如果redis容器被重启，它会重新加载默认的sysctl配置，somaxconn会变回128。如果想要持久化这个设置，更合理的方式是：

  • 在启动redis容器时直接指定sysctl参数：docker run --sysctl net.core.somaxconn=65535 redis
  • 或者在Docker Compose文件中添加sysctl配置：

    services:
      redis:
        image: redis
        sysctls:
          - net.core.somaxconn=65535
    

内容的提问来源于stack exchange，提问作者Arpan Gupta