容器启停
启动
docker compose -f docker-compose.yml up -d
停止
docker compose -f docker-compose.yml down
如果使用的 yml 文件是通用的 docker-compose.yml ，可以不用 -f 显式指定配置文件。
docker compose up -d
docker 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_URL=http://knowflow-gotenberg:3000以 ragflow 开源项目接入 cas 认证为例
- .env
- docker-compose.yml 通过 environment 将环境变量传递到容器内部（或者 env_file: .env）
- entrypoint.sh 通过内部环境变量替换 service_conf.yaml.template 模板文件生成具体配置文件
- config_util.py 读取 service_conf.yaml 文件生成内存变量 CONFIGS
- user_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_URL=http://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
