Docker 常用相关知识点备忘 📅 2026/8/7 12:19:58 容器启停启动docker compose -f docker-compose.yml up -d停止docker compose -f docker-compose.yml down如果使用的 yml 文件是通用的 docker-compose.yml 可以不用 -f 显式指定配置文件。docker compose up -ddocker compose down文件同步docker-compose.yml中可以使用 volumes: 设置热挂载。这样在代码调试时修改容器外部的代码重启容器后就将外部的代码同步到容器内部了。格式类似于下面这种volumes: - ./ragflow-logs:/ragflow/logs - ./nginx/ragflow.conf:/etc/nginx/conf.d/ragflow.conf - ./nginx/proxy.conf:/etc/nginx/proxy.conf - ./nginx/nginx.conf:/etc/nginx/nginx.conf - ../history_data_agent:/ragflow/history_data_agent - ./service_conf.yaml.template:/ragflow/conf/service_conf.yaml.template - ./entrypoint.sh:/ragflow/entrypoint.sh环境变量docker-compose.yml启动容器时会自动将 .env 环境变量文件加载到内存。外部环境变量文件生效到容器内部还需要使用 environment 或 env_file: .env 进行设置变量有重复时environment 设置的环境变量优先级更高。env_file: .env environment: - TZ${TIMEZONE} - HF_ENDPOINT${HF_ENDPOINT} - MACOS${MACOS} - KNOWFLOW_API_URL${KNOWFLOW_API_URL:-http://knowflow-backend:5000} - GOTENBERG_URLhttp://knowflow-gotenberg:3000以 ragflow 开源项目接入 cas 认证为例.envdocker-compose.yml 通过 environment 将环境变量传递到容器内部或者 env_file: .enventrypoint.sh 通过内部环境变量替换 service_conf.yaml.template 模板文件生成具体配置文件config_util.py 读取 service_conf.yaml 文件生成内存变量 CONFIGSuser_api.py 使用 get_base_config 从 CONFIGS 读取 cas 变量内容容器交互多个容器之间可以通过 api 的形式进行交互但是需要他们同属于共同的一个网络。在docker-compose.yml文件中定义服务后Compose 会自动创建一个默认网络并将服务名注册为 DNS 名称。# docker-compose.yml 示例 services: ragflow: image: your-ragflow-image # ... 其他配置 knowflow: image: your-knowflow-image # ... 其他配置 environment: # 关键在 KnowFlow 中通过服务名 ragflow 访问 API - RAGFLOW_BASE_URLhttp://ragflow:9380之后在knowflow容器内部http://ragflow:9380就能正确解析到ragflow服务。如果容器没有在同一个 docker-compose.yml 中定义则需要引用同一个网络使得他们可以相互通信。容器网络容器网络常用操作命令docker network create ragflow 创建网络docker network remove ragflow 移除网络docker network inspect ragflow 检查网络COPY命令镜像文件拷贝Dockerfile 中的 COPY 命令# 将 config/ 目录下的所有内容复制到容器内的 /app/config/ 目录下 COPY config/ /app/config/注意当源路径是目录时COPY复制的是目录下的内容而不是目录本身。因此目标路径带/能更清晰地表明意图。容器文件拷贝容器目录与宿主机之间的文件相互拷贝docker cp ragflow-server:/ragflow/.venv/lib/python3.10/site-backages/boto3 . docker cp boto3 knowflow-backend:/usr/local/lib/python3.10镜像DIY有时候现有镜像的环境可能缺少部分依赖或者说我们对镜像里的服务做了有些优化。我们希望将这些改动固化下来而不是每次启动的时候都去热挂载同步到容器内部。这个时候我们可以基于已有的基础镜像将我们的改动更新到镜像内部然后重新生成新的 Dockerfile用新的 Dockerfile 构建生成新的镜像。这样后续我们就可以基于这个新生成的镜像来启动容器了。以 zxwei/knowflow-server:v2.1.8 的基础镜像为例我们做一些 bug 修复以及引入 s3 存储。# 后端构建 FROM zxwei/knowflow-server:v2.1.8 AS backend WORKDIR /app # 将 packages 下的所有 s3 相关依赖拷贝到 lib 目录 # boto3, botocore, s3transfer, jmespath # 这些依赖可以先从 ragflow 镜像启动的容器里边拷贝出来临时存储 COPY packages/ /usr/local/lib/python3.10 # 其他源码优化改动覆盖 COPY s3_conn.py /app/ COPY database.py /app/ COPY services/users/service.py /app/services/users/ COPY services/files/service.py /app/services/files/ COPY routes/files/routers.py /app/routes/files/ # 设置tiktoken缓存目录环境变量 ENV TIKTOKEN_CACHE_DIR/opt/tiktoken_cache # 暴露后端 EXPOSE 5000 CMD [python3.10, app.py] # 构建新镜像 # docker build -t zxwei/knowflow-server:v2.1.8beta -f Dockerfile .镜像导出和导入镜像导出docker save -o my_nginx.tar nginx:latest导出并压缩可以极大压缩生成的镜像文件的大小docker save myapp:latest | gzip myapp_latest.tar镜像加载docker load -i my_nginx.tar镜像清除如果频繁构建镜像的话会导致镜像所占用的空间很大磁盘空间很容易爆满溢出。删除镜像docker rmi knowflow:v2.1.8清理悬空镜像如果多次构建且没有修改镜像名称和 TAG 的话会导致重复名称的旧镜像变成悬空镜像可以用下面命令清空悬空镜像。docker image prune清理构建缓存分步构建过程会产生大量缓存层镜像删除后这些缓存可能还在。docker builder prune docker builder prune -a清理悬空资源悬空资源包含悬空镜像主要有所有已经停止的容器所有悬空镜像所有构建缓存所有未被使用的网络docker system prune