Dify docker内网部署常见问题记录

Container docker-db-1 Error dependency failed to start: container docker-db-1 is unhealthy

这个是极高频会遇到的问题，也比较容易搜索到解决方案。问题原因大概率是windows hyper-v 模式部署的docker，volumes挂载问题

解决方法

docker\docker-compose.yaml文件修改volumes挂载

原因剖析

首先查看官方的说明文档，明确说明Windows with WSL 2 enabled，理论上使用WSL2运行不会出现该问题，我电脑使用WSL2运行Docker一直报错，就没法做验证了。

参考资料
Docker Compose 部署
 issues5731

如何离线部署

项目上使用，服务器往往无法直连互联网，无法直接拉取镜像。可以在个人PC或者其他服务器上先导出镜像，然后再导入到目标服务器。

导出

以1.4.0版本为例，使用save命令，导出的镜像会带有tag
docker save -o dify.tar langgenius/dify-web:1.4.0 langgenius/dify-api:1.4.0 langgenius/dify-plugin-daemon:0.0.10-local postgres:15-alpine langgenius/dify-sandbox:0.2.12 redis:6-alpine nginx:latest ubuntu/squid:latest semitechnologies/weaviate:1.19.0
导入
docker load -i dify.tar

ARM架构部署问题

ARM架构需要拉取对应的镜像，但是如果从AMD架构服务器导出的镜像，则需要指定拉取ARM镜像导出，否则导入到目标服务器后架构不匹配。

复制docker\docker-compose.yaml文件，改名为docker-compose-arm.yaml，在需要的service节点下添加platform: arm64标识，明确指定目标平台。

配置好后，执行拉取命令docker compose -f .\docker-compose-arm.yaml pull

参考资料
Dify离线部署方案-以华为昇腾Arm架构服务器为例
 ARM 环境中部署 Dify

ARM环境sandbox容器持续重启问题

观察docker-sandbox-1容器持续重启，查看容器日志发现有如下报错：
runtime/cgo pthread_create failled operation not permitted

根据错误说明提示，是权限问题。为了快速定位解决问题，直接给全部权限（生产环境不建议！！！）

yaml 复制代码

# 赋予所有权限
cap_add:
  - ALL
# 禁用安全增强模式（Seccomp）
security_opt:
  - seccomp:unconfined

配置后重新启动，恢复正常

sh 复制代码

docker compose down
docker compose up -d

虽然容器运行恢复正常了，但是按照最小权限原则，并未精准找到所需的权限，这样直接赋予所有权限，也失去了使用沙盒的意义。生产环境使用还需要进一步排查问题根源。

纯内网环境插件无法正常安装问题

安装插件页面提示已安装完成，但是实际却无法获取到插件。插件签名校验也已关闭。

sh 复制代码

# 关闭插件签名校验
FORCE_VERIFYING_SIGNATURE=false

跟踪了前端页面控制台和接口请求，无任何报错；应该是网络原因无法拉取依赖的包。

插件是运行在langgenius/dify-plugin-daemon这个容器。既然无法直接在线拉取，有2个思路解决。1、直接在有网络的环境装好插件，然后将container打包为image；2、在插件里面添加依赖包，直接使用本地依赖。

以下2种解决思路仅为理论推测，暂未实际验证效果。

容器打包方案（未验证通过）

在有网环境安装好插件，注意环境必须和内网服务器架构一致。

sh 复制代码

# 将当前的container打包为image
docker commit <容器ID> langgenius/dify-plugin-daemon:0.1.1-local-offline
# 将image导出
docker save -o dify-plugin-daemon.tar langgenius/dify-plugin-daemon:0.1.1-local-offline

在内网服务器导入镜像，修改docker_compose.yml配置，使用最新打包镜像。然后重新运行Dify。

sh 复制代码

# 导入image
docker load -i dify-plugin-daemon.tar

在内网环境安装后，有报错信息。查看日志，发现还是会请求pypi源，具体错误原因未进一步排查。

有一个解决思路，通过后台手动添加插件，比如上传指定插件目录，解压插件包，插件表中添加插件记录等，理论上可行，但实际操作会比较麻烦，可行性待验证。

插件打包方案（未验证通过）

参考这位大佬的方案 dify-plugin-repackaging ，将在线包打包为离线包。

注意需要修改.env配置文件，离线打包后包会比较大，放宽相应大小限制。重新打包后签名不匹配，关闭插件签名校验。

sh 复制代码

# 插件大小限制，单位为字节，放大10倍 为 500MB。
PLUGIN_MAX_PACKAGE_SIZE=524288000
# 放宽默认的客户端最大请求体大小限制，与插件大小500M保持一致
NGINX_CLIENT_MAX_BODY_SIZE=500M
# 关闭插件签名校验
FORCE_VERIFYING_SIGNATURE=false

以langgenius-openai_api_compatible_0.0.16插件为例，做了验证。离线打包脚本正常运行，生成的离线包15M左右，但是在内网环境安装后，有报错信息。查看日志，发现还是会请求pypi源，具体错误原因未进一步排查。

参考文档 Dify 实战：纯内网1.0+版本，攻克模型工具插件离线安装难题

容器克隆

上述2种方案均未验证通过，只能是祭出终极武器，将volumes目录与dify-plugin-daemon容器打包，替换到指定内网服务器，可以正常启动。方法虽然粗暴，但是有用。

搭建局域网pypi源

这个应该是终极解决方案，如果客户网络没有相应pypi源，只能是自己搭建。目前设想一个方案，待后续有条件后验证。根据安装的插件获取所依赖的包，然后将必要的包打包作为pypi源，关键点是如何获取必要的包，打包成源。