ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

dify-1.3.1 纯国内镜像一键部署:内网离线安装与避坑指南

dify-1.3.1 纯国内镜像一键部署:内网离线安装与避坑指南 简介本资源为 Dify 1.3.1 版本的纯国内镜像一键部署包面向需要在 Linux 服务器上快速搭建大模型应用开发平台的开发者与运维人员解决官方镜像拉取缓慢、环境配置繁琐的问题。压缩包共约 2000 个文件以 1410 个 Python 源码、370 个 JSON 配置、103 个 CSS 样式及 26 个 JS 脚本为主另含 23 个 YAML、12 个 Shell 脚本与少量 HTML、SQL、XML 等整体约 20.31MB覆盖后端服务、前端界面与容器编排所需模块。包内已预置 .env 环境文件与 dify.yaml 编排文件Nginx 端口、S3 插件等参数均已写好解压至 /usr/local 后进入 docker 目录执行 docker-compose 命令即可拉起全部服务浏览器访问对应 IP 的 17880 端口完成注册即可使用。目前已有 1882 人学习下载适合希望跳过镜像下载与配置调试、直接体验 Dify 1.3.1 的读者参考使用。1. dify-1.3.1 部署包纯国内镜像一键安装到底省掉了哪些事公司内网机器不能直连外网但团队想用 Dify 搭一套知识库问答这个场景我遇到过不止一次。dify-1.3.1 部署包配纯国内镜像一键安装解决的正是这件事把 Docker 镜像、npm 依赖、Python 包全部换成国内可访问的源让一台干净的内网服务器在半小时内跑起 Dify。它适合三类人没有外网出口的企业内网运维、被镜像拉取超时折磨过的后端、以及想快速验证 Dify 工作流和知识库流水线是否值得投入的技术负责人。这篇不聊概念只讲部署包怎么拆、参数怎么改、哪几个地方最容易翻车。2. 部署包拆开看国内镜像替换了哪些层2.1 镜像层、依赖层、运行时层的替换逻辑Dify 的部署本质是 Docker Compose 拉起一组容器api、worker、web、db、redis、weaviate 或 qdrant、nginx。官方 compose 文件里每个服务的 image 字段指向 Docker Hub构建阶段还会从 npm registry 和 PyPI 拉包。纯国内镜像部署包做的事情是在三个层面做替换。第一层是容器镜像。把langgenius/dify-api:1.3.1、langgenius/dify-web:1.3.1这类镜像地址换成国内镜像仓库的对应路径。常见做法是使用阿里云容器镜像服务的公开镜像加速或者企业自建的 Harbor 仓库做一次代理缓存。第二层是构建依赖。web 前端构建时 npm install 会访问 registry.npmjs.org部署包里会把.npmrc的 registry 指向 npmmirror。第三层是 Python 包。api 服务安装依赖时 pip 默认走 pypi.org部署包会写入 pip.conf 指向清华或阿里云 PyPI 镜像。这三层缺一层一键安装就会在某个环节卡住。我见过只换了 Docker 镜像但没换 pip 源的部署包容器能起来api 服务启动时装依赖直接超时日志里全是Read timed out。2.2 一键安装脚本的执行流程与关键参数部署包通常包含一个install.sh和一份.env模板。脚本做四件事检查 Docker 和 Docker Compose 是否就绪、导入离线镜像或配置镜像加速、生成.env文件、执行docker compose up -d。#!/bin/bash # install.sh 核心逻辑节选 set -e # 1. 检查 Docker 环境 if ! command -v docker /dev/null; then echo Docker 未安装请先安装 Docker 20.10 exit 1 fi # 2. 配置 Docker 镜像加速写入 daemon.json MIRROR_URLhttps://your-mirror.example.com mkdir -p /etc/docker cat /etc/docker/daemon.json EOF { registry-mirrors: [${MIRROR_URL}], insecure-registries: [] } EOF systemctl daemon-reload systemctl restart docker # 3. 生成 .env if [ ! -f .env ]; then cp .env.example .env # 替换关键参数 sed -i s|^DIFY_API_BASE_URL.*|DIFY_API_BASE_URLhttp://$(hostname -I | awk {print $1})| .env fi # 4. 启动 docker compose -f docker-compose.yaml up -d脚本里registry-mirrors填的是国内镜像加速地址DIFY_API_BASE_URL必须改成服务器实际 IP否则 web 前端调 api 会跨域失败。.env里还有几个参数值得注意DB_PASSWORD和REDIS_PASSWORD不要用默认值SECRET_KEY必须重新生成MIGRATION_ENABLED在首次启动时设为 true后续升级再关掉。2.3 离线镜像导入与在线加速的选型差异部署包分两种形态离线 tar 包和在线加速脚本。离线包把docker save出来的镜像打成 tar安装时docker load导入适合完全断网的环境。在线加速脚本只配镜像源镜像还是从国内仓库拉适合有外网但直连 Docker Hub 慢的机器。选哪种看两个指标内网是否有 DNS 能解析国内镜像仓库、磁盘剩余空间是否大于 20GB。离线包体积通常在 3 到 5GB导入后镜像层占用的空间会翻倍。在线加速对磁盘友好但首次拉取仍受网络波动影响。我一般建议能通外网就用在线加速完全隔离才用离线包因为离线包的镜像更新需要重新制作维护成本高。3. 从零跑通dify-1.3.1 一键安装的完整步骤3.1 环境预检Docker、Compose、端口、磁盘在跑安装脚本之前先确认四件事。Docker 版本不低于 20.10Docker Compose 版本不低于 v2.080 和 443 端口没有被 nginx 或其他服务占用根分区剩余空间大于 20GB。# 环境预检命令 docker --version docker compose version ss -tlnp | grep -E :80|:443 df -h / | tail -1如果 80 端口被占用改.env里的EXPOSE_NGINX_PORT为 8080 或其他端口。磁盘不够的话Docker 的默认数据目录在/var/lib/docker可以通过daemon.json的># 生成 SECRET_KEY openssl rand -base64 42 # 生成数据库密码 openssl rand -hex 16SECRET_KEY一旦设定就不要改改了之后已登录用户的会话全部失效。MIGRATION_ENABLED只在首次启动或版本升级时设为 true日常运行设为 false 可以加快启动速度。3.3 执行安装并验证容器健康状态配置完成后执行安装脚本然后观察容器状态。# 执行安装 bash install.sh # 查看容器状态 docker compose ps # 查看 api 服务日志 docker compose logs -f api --tail100正常情况下docker compose ps里所有服务状态应该是running或healthy。api 服务启动较慢因为要等数据库迁移完成通常需要 1 到 3 分钟。如果 api 反复重启看日志里有没有Connection refused指向 db 或 redis那说明密码不匹配或服务没起来。验证 web 是否可用# 检查 nginx 响应 curl -I http://localhost:80 # 检查 api 健康端点 curl http://localhost:80/console/api/health返回 200 就说明基础服务通了。接下来浏览器访问服务器 IP应该能看到 Dify 的初始化页面设置管理员账号密码即可进入。3.4 接入本地大模型与知识库流水线初验Dify 跑起来之后第一件事是接入模型。进入「设置」→「模型供应商」如果用的是本地 Ollama填http://宿主机IP:11434模型名称填 Ollama 里已拉取的模型。如果用的是国内大模型 API填对应的 Base URL 和 API Key。知识库流水线验证新建一个知识库上传一份 PDF观察索引状态。如果卡在「索引中」看 worker 容器日志常见原因是 embedding 模型没配好或向量数据库连接失败。dify-1.3.1 默认用 weaviate如果换成 qdrant需要改.env里的VECTOR_STORE参数并重启。4. 避坑排查一键安装最容易翻车的五个地方4.1 现象docker compose up 卡在 pulling 不动原因Docker 镜像加速没生效或者加速地址本身不可达。daemon.json写完后没有重启 Docker配置不会加载。解决systemctl restart docker后执行docker info查看Registry Mirrors是否包含配置的地址。如果加速地址不通换一个可用的国内镜像源。离线包场景下检查docker load是否成功docker images里有没有对应 tag。4.2 现象api 容器启动后立即退出日志显示数据库连接失败原因.env里DB_PASSWORD和docker-compose.yaml里 db 服务的POSTGRES_PASSWORD不一致或者 db 容器还没初始化完 api 就启动了。解决确认.env和 compose 文件里的密码变量引用一致。如果是首次启动给 api 加depends_on的condition: service_healthy等 db 健康检查通过再启动。手动排查可以docker compose exec db psql -U postgres看能否登录。4.3 现象web 页面打开空白控制台报跨域错误原因DIFY_API_BASE_URL填的是localhost或127.0.0.1浏览器从其他机器访问时前端请求发到了用户自己的机器上。解决把DIFY_API_BASE_URL改成服务器实际 IP 或域名重启 web 和 nginx 容器。如果用了反向代理确认CONSOLE_API_URL和APP_API_URL也指向正确地址。4.4 现象知识库上传文件后一直显示索引中原因worker 容器没有正常运行或者 embedding 模型配置有误。dify-1.3.1 的索引任务由 worker 消费队列执行worker 挂了任务就堆积。解决docker compose logs worker --tail200查看报错。常见的是 embedding 模型 API Key 无效或额度耗尽。如果是本地模型确认 Ollama 服务可达且模型已拉取。4.5 现象升级或迁移后数据丢失原因直接删除了 db 容器或 volume或者迁移时只备份了.env没备份数据库 volume。解决升级前执行docker compose exec db pg_dump -U postgres dify backup.sql。迁移时把volumes目录整体打包包括db、redis、weaviate的数据卷。恢复时先起 db导入 sql再起其他服务。5. 进阶技巧让 dify-1.3.1 在内网长期稳定跑5.1 用反向代理加 HTTPS 并保留国内镜像加速内网长期运行建议在前面加一层 nginx 做 HTTPS 终止。证书可以用内部 CA 签发重点是proxy_pass指向 Dify 的 nginx 容器端口并设置client_max_body_size至少 100M否则知识库上传大文件会 413。server { listen 443 ssl; server_name dify.internal; ssl_certificate /etc/nginx/certs/dify.crt; ssl_certificate_key /etc/nginx/certs/dify.key; client_max_body_size 100M; location / { proxy_pass http://127.0.0.1:80; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_read_timeout 300s; } }proxy_read_timeout设大是因为工作流执行和知识库索引可能耗时较长默认 60 秒会断。5.2 定期备份数据库与向量库的脚本化我习惯写一个 cron 脚本每天凌晨备份 db 和 weaviate 的数据卷。#!/bin/bash # backup_dify.sh BACKUP_DIR/data/backup/dify/$(date %Y%m%d) mkdir -p ${BACKUP_DIR} # 备份 PostgreSQL docker compose exec -T db pg_dump -U postgres dify ${BACKUP_DIR}/dify.sql # 备份 weaviate 数据卷 docker run --rm -v dify_weaviate_data:/data -v ${BACKUP_DIR}:/backup \ alpine tar czf /backup/weaviate_data.tar.gz -C /data . # 保留最近 7 天 find /data/backup/dify -maxdepth 1 -type d -mtime 7 -exec rm -rf {} \;这个脚本的关键是docker compose exec -T的-T参数不加的话 cron 环境下会报 TTY 错误。向量库备份用临时容器挂载 volume 打包比直接 cp 安全。5.3 监控容器资源与日志轮转Dify 跑久了日志会撑满磁盘。在docker-compose.yaml里给每个服务加日志轮转配置services: api: logging: driver: json-file options: max-size: 50m max-file: 3max-size控制单个日志文件大小max-file控制保留数量。加上之后单服务日志最多占 150MB。监控方面docker stats可以快速看 CPU 和内存占用api 和 worker 是内存大户建议给宿主机至少 8GB 内存。我自己的习惯是每次部署完先跑一遍知识库上传和对话测试确认索引和推理链路都通再把地址交给团队。这套 dify-1.3.1 纯国内镜像部署方案在内网环境跑了几个月最深的教训是.env里的SECRET_KEY和数据库密码一定要在首次启动前就设好启动后再改要么会话失效要么数据库连不上后悔药没地方买。希望帮到你。本文还有配套的精品资源点击获取
返回列表