热度 1 |||
Dify官网提供2种部署方式：Docker Compose和本地源码启动。我们已经成功安装了Docker，接下来就采用Docker compose方式本地部署Dify。
Docker compose部署主要是两个步骤：
步骤一、克隆Dify 代码仓库
克隆 Dify 源代码至本地。执行如下Git命令：
git clone https://github.com/langgenius/dify.git
步骤二、启动 Dify
进入 Dify 源代码的 docker目录，执行一键启动命令：
cd dify/docker
cp .env.example .env
docker compose up -d
安装只需上述两个步骤即可，但在尝试安装Dify的过程中，遇到了不少棘手的问题，搞得整个安装过程变得颇为艰难。原本以为这将是一个简单的任务，但随着安装的继续，发现远没有想象中那么顺利。
在尝试拉取镜像清单时，Docker总是镜像拉取失败。尝试手动指定镜像源，每次修改一批，每次运行docker pull命令时，总是出现新的报错，最终以失败告终。这种反反复复的失败挺让人感到挫败的。
过程中遇到的问题和挑战，为了找解决方案，我查阅了大量的文档和论坛帖子，通过AI助手等，希望得到一些专业的帮助。一次一次的尝试和调整，一次一次的添加和试错，最终才有了一个稳定的镜像源清单，成功拉取了所需的镜像，那一刻，所付出的努力终于看到了回报。
当然，在技术领域，遇到问题是常有的事，关键是要保持耐心和毅力，不断寻找解决方案，面对任何问题时都能够从容不迫的应对。
好了，为了朋友们不再重蹈覆辙，我将安装过程及避坑情况整理了出来；
1、Git克隆Dify代码
git clone https://github.com/langgenius/dify.git
成功完成Git克隆：
2、启动 Dify
进入 Dify 源代码的 docker目录，执行一键启动命令：
cd dify/docker
cp .env.example .env
docker compose up -d
如果您的系统安装了 Docker Compose V2 而不是 V1，请使用 docker compose 而不是 docker-compose。通过命令$ docker compose version检查是否为此情况。
避坑一：
以管理员身份运行PowerShell，执行命令出现如下报错：
报错信息：“unexpected character "." in variable name near "TLSv1.2 TLSv1.3"；”
这个错误通常出现在使用某些编程语言或脚本语言中，可能在代码中使用了不正确的变量名。在这个特定例子中，错误信息指出在变量名中出现了意外的字符 “.”，这通常意味着在某些上下文中点是不被允许的。解决这个问题需要检查代码，找到导致错误的变量名，并将其修改为合法的变量名。变量名通常只能包含字母、数字和下划线，并且不能以数字开头。
找到文件的路径如下：
Visual Studio Code直接打开docker-compose.yaml进行修改；
我是将TLSv1.1 TLSv1.2 TLSv1.3这三个名称之间的空格替换为逗号，这样就可以避免使用非法字符作为变量名的一部分。如下图所示：
保存后再次运行，可以正常执行了：
避坑二：
由于无法链接到服务器，也无法拉取镜像清单，所以会出现如下报错：
对于这种情况，我们可以采取两种方法：
1、 通过修改daemon.json文件添加镜像地址，具体步骤如下：
解决的步骤如下：
1）. 打开daemon.json文件
vim /etc/docker/daemon.json2）. 将其镜像地址进行替换
"registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.com", "https://registry.docker-cn.com", "https://docker.mirrors.ustc.edu.cn", "https://hub-mirror.c.163.com", "https://hub.uuuadc.top", "https://docker.anyhub.us.kg", "https://dockerhub.jobcher.com", "https://dockerhub.icu", "https://docker.ckyl.me", "https://docker.awsl9527.cn", "https://mirror.baidubce.com" ]3）.重启docker服务
systemctl daemon-reloadsystemctl restart docker2、 通过在docker的设置中直接添加镜像地址，具体如下：
在”registry-mirrors”:[ ]的中括号里填写如下的镜像地址，这些是我测试后可用的，如果有新的添加，每次最好添加一条测试没问题，再添加下一条，避免docker出问题；
"https://docker.m.daocloud.io",
"https://dockerproxy.com",
"https://registry.docker-cn.com",
"https://docker.mirrors.ustc.edu.cn",
"https://hub-mirror.c.163.com",
"https://hub.uuuadc.top",
"https://docker.anyhub.us.kg",
"https://dockerhub.jobcher.com",
"https://dockerhub.icu",
"https://docker.ckyl.me",
"https://docker.awsl9527.cn",
"https://mirror.baidubce.com",
"https://nrbewqda.mirror.aliyuncs.com",
"https://dmmxhzvq.mirror.aliyuncs.com",
"https://docker.chenby.cn",
"https://docker.hpcloud.cloud",
"https://atomhub.openatom.cn"
再次执行后，成功运行：
正如前文所讲到的，上述镜像地址的服务器清单我也不是一次收集齐的，所以中间拉取的时候也是出现各类问题，期间重复多次执行命令，并陆续添加镜像地址才最终完成。
期间一些报错问题如下：
当出现：“Error response from daemon: Head "https://registry-1.docker.io/v2/langgenius/dify-web/manifests/0.7.2": EOF”这类报错时，查看Docker情况，可以发现陆续有Images拉取成功，如下图：
所以，出现此类报错，继续执行如下命令：
cd dify/docker
cp .env.example .env
docker compose up -d
但由于我们修改了docker-compose.yaml，所以cp .env.example .env并不需要再次执行，如下图两条命令即可：
可以看到进度：
期间由于网络稳定性或者服务器访问等各类特殊情况，耗时比较久一点，直到如下才最终完成：
查看Docker可以看到拉取结果，全部成功：
避坑三：
再次执行命令：
docker compose up -d
出现报错信息：“Error response from daemon: mkdir C:\Windows\system32\dify\docker\volumes\db: Access is denied.”
经查，需要以管理员权限运行 Docker才能解决。我是 Windows 用户，通过右键点击 Docker 图标选择“以管理员身份运行”来启动 Docker Desktop。再次执行后如下图正常：
可以查看到Docker中Images的运行情况：
避坑四：
在浏览器中输入 http://localhost 访问 Dify：
在Dify设置管理员账号时，一直在如下这个界面，没有跳到正常界面；
这个问题需要在 docker-compose.yaml 文件中添加：privileged: true代码，执行如下命令：
docker compose down
然后修改文件：
再次执行：docker compose up -d
重新登录Dify，这样就可以用刚才设置的管理员账号成功登录了；
避坑五：
在经历了重重困难后，终于完成了Dify的安装，可以正常使用。然而，在Docker中查看container时，我发现 docker-sandbox-1 容器一直在 running 和 restarting 状态之间快速切换，最终停留在了 restarting 状态。这个问题显得非常奇怪，一时还难以解决。
我首先尝试使用 docker attach和docker exec 命令进入容器内部，希望能够找出一些线索。当我进入容器后，执行一些诊断命令来进一步排查问题。检查了容器的日志文件，希望从中找到一些有用的提示，但是日志文件中的信息也非常有限，除了显示容器立即停止后再启动外，并没有太好的有效手段。
考虑到可能是端口冲突导致的问题，我还尝试使用 netstat 命令检查本机上的端口占用情况。我逐一检查了所有相关的端口，确保没有其他进程占用这些端口。但是，即便如此地毯式搜索，也没有排查由于端口导致的问题。
在技术论坛的文档中，提到可能是配置文件中的某些参数设置不当导致的，于是我仔细检查了所有相关的配置文件，包括 docker-compose.yml 和 Dockerfile，但并没有发现明显的错误或异常配置。
在多次尝试未果后，我开始怀疑可能是某些深层次的系统问题。检查了系统的日志文件，包括 syslog 和 journalctl 输出的信息，希望能够找到一些线索。
此外，我还尝试了以下几种方法：
清理缓存：我清理了 Docker 的缓存，并重新启动了容器。
修改权限：我检查了容器的文件权限，并确保有正确的权限设置。
环境变量：我检查了容器启动时使用的环境变量，并确认它们都是正确的。
尽管前前后后采取了多种措施，但问题依旧没有得到解决。这个容器就像一个谜一样，始终无法恢复到稳定正常运行，一度很沮丧。
再次打开Docker中该容器的log分析；
出现的报错信息是：runtime/cgo: pthread_create failed: Operation not permitted
SIGABRT:abort
PC=0x7faa594183acm=0 sigcode=18446744073709551610
由于之前对：PostgreSQL 启动容器出错 – mkdir: 权限被拒绝进行过修改操作；
当时是在 docker-compose. yaml 文件中，使用以下语法设置用户和组的权限：
services:
postgres:
image: postgres
user: postgres:postgres
只是没有起到作用，又恢复回去了。
想到既然又是权限相关问题，于是我干脆在 docker-compose.yaml 文件中余下几处都添加上：privileged: true代码；
以及其他几处：
保存后再次执行；
同时在Docker中查看，如下图所示：
由此，已没有之前的问题，全部运行成功。
到这里，恭喜朋友们，现在，可以愉快地玩耍了。朋友们如果还遇到问题，请在SAP亦橙网（SAPeclub.com）的AI人工智能论坛留言，我们一起解决。
造船过河不如借船过河，这也正是我们SAP顾问所擅长的专注于应用。Dify 这个强大的智能体开发和搭建平台，我们可以自由搭建工作流和 Agent 的实操，通过利用 Dify 的强大功能和丰富资源，可以参与到 AI 应用的定义和数据运营中，逐步深入了解 AI 领域。
