（AI知识库工具）Ragflow入门与踩坑之（1）——Docker镜像启动问题解决（常见踩坑）

本文链接：https://blog.youkuaiyun.com/RexKaggle/article/details/148195949

一、前言

   此处帮Rawflow吹牛逼的共3000字，略。（使用开源软件，哪怕只是测试也好，总要对他人劳动成果表示尊敬！！！）
   近期在启动Ragflow0.18.0版本时发现Docker中的redis和ES**服务无法启动**，以为是版本问题，顺手升级到Ragflow-0.19.0，发现问题还是没有解决。

主要问题表现如下：

Docker镜像下载正常
启动服务过程看起来似乎正常。
启动结果出现问题，显示：Error response from daemon: Ports are not available: exposing port TCP 0.0.0.0:9000 -> 127.0.0.1:0: listen tcp 0.0.0.0:9000: bind: An attempt was made to access a socket in a way forbidden by its access permissions.
如下图所示，中间启动过程忽略。

分析结果

与系统安全控制有关，在Windows系统本地一部分端口被限制使用。

问题解决
修改配置文件中的端口配置。

环境

1）WINDOWS 11
2）Docker Desktop 4.41.2 (191736) # 当作您已安装，本文不将Docker安装。只要不是太低的版本，问题应答都不大

二、github下载与运行

2.1 代码下载

下载地址：

https://github.com/infiniflow/ragflow

点击“Code”按钮，选择下载ZIP文件：
请添加图片描述

2.2 编辑.env文件（第一个小坑）

找一个你自己觉得舒服地方，解压缩
【ps】我自己觉得舒服就把凡是用docker的软件都扔到一个下图中DockerImage目录了，您随意。
找到解压缩的文件目录
解压缩后生成的目录一般叫做ragflow-main，我自己为了方便，加了-0.19.0代表我使用的版本，您加不加随意。
因为我本来有个0.18.0版本跑得好好的，结果突然不行了。这也是我写这篇文章的原因。
最重要的是下面那个docker目录。
找到docker目录，进入里面看到.env文件。
注意1：这里叫做docker的目录，只是里面的文件都和你要使用的docker有关，和实际docker镜像存储的位置没啥关系。
注意2：如果您足够谨慎的话，建议把这个目录内的配置文件干脆完全备份一份。纯属个人习惯，仅供参考。
编辑.env文件
【第1坑】修改前，默认的slim是个“瘦身”版，意味着下载的版本里面不含embedding模型，很多人没有改，就容易踩坑（会在后面发现别人有的模型，自己没有）。

# The RAGFlow Docker image to download.
# Defaults to the v0.19.0-slim edition, which is the RAGFlow Docker image without embedding models.
RAGFLOW_IMAGE=infiniflow/ragflow:v0.19.0-slim
#
# To download the RAGFlow Docker image with embedding models, uncomment the following line instead:
# RAGFLOW_IMAGE=infiniflow/ragflow:v0.19.0
#

【推荐】按照如下这样，修改后，下载的docker镜像就带了embedding模型。

# The RAGFlow Docker image to download.
# Defaults to the v0.19.0-slim edition, which is the RAGFlow Docker image without embedding models.
#RAGFLOW_IMAGE=infiniflow/ragflow:v0.19.0-slim
#
# To download the RAGFlow Docker image with embedding models, uncomment the following line instead:
RAGFLOW_IMAGE=infiniflow/ragflow:v0.19.0

2.3 拉取镜像并启动

【记住】先启动Docker Desktop
打开windows终端，进入之前提到docker目录，运行

docker compose -f docker-compose.yml up

在这里插入图片描述

如果是首次运行，会自动拉取镜像回来，时间会比较久。拉取完镜像，会启动服务。如果正常启动，可以再次执行上述命令。
【第2坑】这个时候就可能会遇到前面说的问题，看上去镜像正常启动，启动服务过程看似也正常。
但是，启动结果出现问题，显示：Error response from daemon: Ports are not available: exposing port TCP 0.0.0.0:9000 -> 127.0.0.1:0: listen tcp 0.0.0.0:9000: bind: An attempt was made to access a socket in a way forbidden by its access permissions.
如下图所示，中间启动过程忽略。
看看Docker Desktop图形界面内，注意1200、9000、9001这三个端口。
其中“1200:9200”代表在windows系统内的1200端口，对应容器内部是9200端口。双方是映射关系。

三、问题分析

3.1 简要分析

似乎是windows端口不可用问题，但我确实没有在9000端口的服务。

3.2 【尝试1】启动原来0.18.0版本镜像-问题相同

这里比较奇怪，之前好好的，没有类似问题。

3.3 【排查】端口排查

检查端口占用，在命令行执行：

netstat -ano | findstr :9000

检查结果，明确没有占用。

【问题在这里】检查端口是否被系统保留

netsh interface ipv4 show excludedportrange protocol=tcp

【真相在这里】我的系统保留端口如下：
在Ragflow中要在windows系统内使用端口包括1200、9000、9001，都被纳入了系统保留端口。所以容器启动之后，没法绑定相应的windows系统端口。
在这里插入图片描述
【注意】这个问题一定是操作系统的原因导致的。我在之前使用0.18.0版本时，而现在是0.18.0和0.19.0的镜像都没法启动。
极度怀疑是近期Windows有个大版本补丁升级，提高了安全控制导致的。

四、问题解决第一阶段——解决服务端口无法启动

4.1 修改.env文件

ES的对外服务端口修改

【修改前】端口是1200
在这里插入图片描述
【修改后】端口是1600（这个可以根据自己需要设定，只要设置的端口不落在系统保留端口范围内就可以)

2. MINIO的服务端口修改

【修改前】控制台端口9001，服务端口9000

在这里插入图片描述
**

【修改后】控制台端口9091，服务端口9090

**
在这里插入图片描述

4.2 启动服务

启动

#正常情况，运行如下指令，启动服务
docker compose -f docker-compose.yml up

检查
没有报错，看上去很不错。
Docker服务也都起来了，很好。

五、问题解决第二阶段——解决GPU不启用问题

5.1 【第3坑】如果启动时注意一下，会发现GPU没启用。

  **【注意】后面很可能在使用时发现GPU不跑。**

5.2 问题分析

1.Ragflow启动时没有载入GPU运行的相关配置。
2.是否还记得前面在一张图中提到的还有个docker-compose-gpu.yml文件。
在这里插入图片描述

**3.【注意，要点来了】.env、docker-compose.yml、docker-compose-base.yml、docker-compose-gpu.yml三个文件什么关系？？**他们的关系相互依赖。
参考官方文件说法，系统配置涉及以下三个核心文件：

1）.env：存放一些基本的系统环境变量，比如 SVR_HTTP_PORT、MYSQL_PASSWORD、MINIO_PASSWORD 等，它是一个核心配置，它在其他yml运行是把核心配置注入进去。
2）service_conf.yaml.template：配置各类后台服务。
3）docker-compose.yml: 系统依赖该文件完成启动。
2）docker-compose.yml是运行启动配置。
3）.env
4）docker-compose-base.yml是基本配置，在ragflow的配置文件设计中，是在docker-compose.yml、docker-compose-gpu.yml以及上图中所示docker-compose-CN-oc9.yml、docker-compose-gpu-CN-oc9.yml、docker-compose-macos.yml文件中引用docker-compose-base.yml。
这种引用相当于把docker-compose-base.yml配置复制到了其他文件中。
5）我们看下docker-compose-gpu.yml的配置，这里使用include引用的docker-compose-base.yml配置。
注：这是一个在Docker Compose 2.20.3及之后的版本支持的指令，用include来引用和分割yaml配置文件。类似递归的关系。
在这里插入图片描述

5.3 对比不同文件启动效果

1.用docker-compose.yml启动

#
docker compose -f docker-compose-gpu.yml up

结果如下：
在这里插入图片描述
2.用docker-compose-base.yml启动

#
docker compose -f docker-compose-base.yml up

结果如下（服务无法正常启动）：
在这里插入图片描述

3.用docker-compose-gpu.yml启动

#
docker compose -f docker-compose-gpu.yml up

结果如下：
【注意】这里可以清晰的发现与deepdoc相关的det.onnx和rec.onnx使用GPU加载的了。
在这里插入图片描述
4.用docker-compose-gpu-CN-oc9.yml启动

#
docker compose -f docker-compose-gpu-CN-oc9.yml up

结果如下：docker需要下载新的镜像，oc9的具体用途不是很清楚。
在这里插入图片描述

#然后还是报错，虽然看到容器服务都启动了。

5.用docker-compose-CN-oc9.yml启动

#
docker compose -f docker-compose-CN-oc9.yml up

问题同上。（略）

5.4 注意，

1、docker-compose-gpu.yml、docker-compose-CN-oc9.yml、docker-compose-gpu-CN-oc9.yml、docker-compose-macos.yml文件的开头，都说明了，开发团队不会始终维护这几个配置文件。所以要自行考虑风险。

#例如：
# The RAGFlow team do not actively maintain docker-compose-gpu.yml, so use them at your own risk.

2、docker-compose-CN-oc9.yml、docker-compose-gpu-CN-oc9.yml的实际用途官方文件中没有找到。暂时先不考虑它的错误问题。

5.5 问题最终解决

1.【想用CPU】直接使用一般配置文件启动

#
docker compose -f docker-compose.yml up

2.【想用GPU】直接使用gpu配置文件启动

#
docker compose -f docker-compose-gpu.yml up

3.也可以考虑：使用多配置启动方式

#
docker compose -f docker-compose-base.yml -f docker-compose-gpu.yml up

#但是，我这样做遇到了如下报错。
在这里插入图片描述
#【解决办法】把include内容注释掉，重新运行多文件启动，例如：
```bash
#再次运行，可正常启动
docker compose -f docker-compose-base.yml -f docker-compose-gpu.yml up