如何在Docker容器内安装依赖且无需重建容器即可生效

报错的核心原因有两点：

1. 运行中容器内手动执行pip install安装的包默认存在容器的独立可写层，不会写入构建好的镜像。如果执行docker compose down（会删除运行容器）再执行up，原有容器的可写层会被直接清除，手动装的依赖自然就丢失了。单纯执行docker compose stop再start不会删除容器，可写层数据会保留，不会出现依赖丢失问题。
2. 从你贴的Dockerfile看，构建阶段会复制requirements.txt到容器内安装依赖，但你启动时挂载的bind卷把宿主机src目录覆盖到了容器的/var/www/server路径，容器内执行pip freeze > requirements.txt会直接同步覆盖宿主机上的原依赖文件，但容器重启时不会重新跑构建阶段的pip install命令，新写入requirements.txt的依赖没有被实际安装，自然会报模块不存在。你删除旧容器重建时如果触发了镜像重构建，就会读取更新后的requirements.txt装全所有依赖，所以服务恢复正常。

以下方案都不需要每次手动删容器重建，按适用场景选择即可：

• 临时调试场景：直接在运行容器内装包使用
  你进入容器执行pip install x之后，依赖在当前运行的容器里已经直接生效，不需要重启容器就能用。后续如果要重启服务，用docker compose start命令启动现有容器即可，不要执行会删除容器的docker compose down/docker compose rm操作，容器可写层里的依赖会一直保留。
  注意：这个方案的依赖没有持久化，容器被意外删除后需要重新安装。
• 开发常驻场景：修改启动命令自动安装依赖
  调整Dockerfile的启动逻辑，在服务启动前自动执行一次依赖安装，pip会自动跳过已经安装的包，不会明显拖慢启动速度，不管容器是重启还是重建，都会自动装全requirements.txt里列的所有依赖，不会缺包：

  FROM python:3.6
  RUN apt-get update && apt-get install -y --no-install-recommends gettext && rm -rf /var/lib/apt/lists/*
  
  RUN mkdir -p /var/www/server
  COPY src/requirements.txt /var/www/server/
  
  WORKDIR /var/www/server
  RUN pip install -r ./requirements.txt
  EXPOSE 8100
  # 启动前先校验安装依赖，再执行迁移和服务启动
  ENTRYPOINT sleep 3 && pip install -r ./requirements.txt && python manage.py migrate && python manage.py runserver 0.0.0.0:8100
  

  改完之后你在容器内装新包、导出依赖到requirements.txt之后，不管怎么重启、重建容器，都会自动补全新增的依赖，不会报模块找不到的错误。
• 持久化场景：用命名卷挂载python依赖目录
  如果你不想每次容器启动都校验依赖，可以在docker-compose配置里加一个独立命名卷，挂载到python容器的第三方包安装路径（python3.6默认路径为/usr/local/lib/python3.6/site-packages），手动安装的依赖会直接存在命名卷里，哪怕容器被删除重建，依赖也不会丢失：

  services:
    your_python_service:
      build: .
      volumes:
        # 原有代码挂载
        - ./src:/var/www/server
        # 新增依赖持久化卷
        - python_deps:/usr/local/lib/python3.6/site-packages
  # 声明命名卷
  volumes:
    python_deps:
  

生产环境不推荐直接在运行容器内安装依赖，最好在本地更新requirements.txt后重新构建镜像，保证多环境部署的一致性，上述方案更适合本地开发调试使用。

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