Ubuntu24.04/Open WebUI+Ollama 本地部署

Ubuntu24.04/Open WebUI+Ollama 本地部署

官方文档

🏡 首页 | Open WebUI 文档

本地部署

  • 连接本地 Ollama 服务:

使用服务器测试了下:初次对话耗时较长,后续效率还不错;目前无法联网(废话)

[图片]

对话中即可选择模型:不过我的硬件不支持,所以就先不做测试了

[图片]

修改 Ollama 配置:宿主机 Ollama 服务地址:http://host.docker.internal:11434(我猜你不想一个一个字母敲,就直接大胆使用“cv大法”吧)

[图片]


[图片]

查看本地模型 ID:

[图片]

管理员面板/设置/外部连接

[图片]

运行页面:

[图片]

使用 Docker Compose 封装运行:其中镜像拉取速度比较慢

docker compose up -d 

修改配置文件:由于本地已经运行了 Ollama 服务,所以需要修改docker-compose.yaml以及.env文件中关于 Ollama 的配置

cd open-webui cp .env.example .env 
# .env # Ollama URL for the backend to connect The path '/ollama' will be redirected to the specified # backend URL OLLAMA_BASE_URL='http://host.docker.internal:11434' # AUTOMATIC1111_BASE_URL="http://localhost:7860" # For production, you should only need one host as # fastapi serves the svelte-kit built frontend and backend from the same host and port. # To test with CORS locally, you can set something like # CORS_ALLOW_ORIGIN='http://localhost:5173;http://localhost:8080' CORS_ALLOW_ORIGIN='*' # For production you should set this to match the proxy configuration (127.0.0.1) FORWARDED_ALLOW_IPS='*' # DO NOT TRACK SCARF_NO_ANALYTICS=true DO_NOT_TRACK=true ANONYMIZED_TELEMETRY=false 
# docker-compose.yml# 删除 Ollama 服务的配置以及 open-webui 的依赖,修改环境变量中的 Ollama 地址services:open-webui:build:context: . dockerfile: Dockerfile image: ghcr.io/open-webui/open-webui:${WEBUI_DOCKER_TAG-main}container_name: open-webui volumes:- open-webui:/app/backend/data ports:- ${OPEN_WEBUI_PORT-3000}:8080environment:-'OLLAMA_BASE_URL=http://host.docker.internal:11434'-'WEBUI_SECRET_KEY='extra_hosts:- host.docker.internal:host-gateway restart: unless-stopped volumes:ollama:{}open-webui:{}

Git 拉取项目:

git clone https://ghfast.top/https://github.com/open-webui/open-webui.git 

联网搜索

  • 本地部署 SearXNG(如有需要或者作者心情好,后续会详细开篇文章;不过根据 Open WebUI 官方文档,相信你也可以);优化部分参考官方文档:SearXNG | Open WebUI 文档
    注意
    • 配置 SearXNG 的搜索引擎,禁用 Brave、DuckDuckGo、Google、Wikipedia等国外搜索引擎(莫怪作者懒得“科学上网”),启用 360search、Bing、Sogou、Baidu(百度可能会触发反爬机制,抛出验证码限制搜索访问;一旦被抓,就是同一 IP 被禁 24h;作者目前还没有解禁『悲』)

开启联网搜索:由于硬件以及模型的限制,虽然进行了联网搜索,但是结果不尽人意;换了好设备和模型,效果就很好了(旧的呢,继续用呗,还能撇了?)

[图片]


[图片]


[图片]

配置 Open WebUI 的页面搜索配置:注意开启最上面的联网搜索、配置宿主机中的 SearXNG 访问地址:http://host.docker.internal:8080/search?q=<query>;否则在对话窗口中无法开启联网搜索、无法连接到 SearXNG 的服务

[图片]

配置 docker-compose.yaml 中的 Caddy 端口映射以及取消 host 网络模式,否则被 Firefox 浏览器占用端口

# docker-compose.yamlcaddy:container_name: caddy image: docker.io/library/caddy:2-alpine # network_mode: hostrestart: unless-stopped ports:-"8081:8081"volumes:- ./Caddyfile:/etc/caddy/Caddyfile:ro - caddy-data:/data:rw - caddy-config:/config:rw environment:- SEARXNG_HOSTNAME=${SEARXNG_HOSTNAME:-http://localhost}- SEARXNG_TLS=${LETSENCRYPT_EMAIL:-internal}logging:driver:"json-file"options:max-size:"1m"max-file:"1"

注意事项

  • 使用 SearXNG 联网时,注意按照官方文档配置搜索引擎以及添加 json 格式
  • 所有系统级配置均在管理员面板/设置中管理
  • 连 1.7B 的大模型都运行乏力,哈基机你这家伙,这就燃尽了么

每次启用 Docker 容器时,需要一些加载时间,当出现下图最后几段日志的时候就是加载完成了:

[图片]

Read more

[开源] 纯前端实现楼盘采光模拟工具:从2D规划图到3D日照分析

[开源] 纯前端实现楼盘采光模拟工具:从2D规划图到3D日照分析

前言 买房是人生大事,不仅要看户型,更要看采光。尤其是现在高层住宅密集,低楼层的日照时长往往是购房者的心病。虽然市面上有专业的日照分析软件,但对于普通开发者或购房者来说门槛太高。 最近利用周末时间,我开发了一套纯前端、零依赖的楼盘规划与采光模拟工具。它包含两个部分: 1. 配置器 (Editor):基于 Canvas,在普通的楼盘规划图(JPG/PNG)上绘制楼栋轮廓、标定比例尺。 2. 可视化 (Viewer):基于 Three.js,将配置好的数据生成 3D 模型,模拟冬至/夏至不同时间段的日照阴影。 本文将分享这个项目的核心技术实现思路。 开源地址:[https://github.com/SeanWong17/building-sunlight-simulator] 欢迎 Star ⭐ 和 Fork! 🚀 功能演示 1. 2D 规划图配置器 这是数据生产的入口。用户上传一张总平图,

LVS+Keepalived+DNS+Web+NFS 高可用集群项目完整部署流程

LVS+Keepalived+DNS+Web+NFS 高可用集群项目完整部署流程

一、集群架构规划(共 8 台虚拟机) ip段用自己的 当然完成这个案例并不是一定要8台虚拟机,集群是可以合并在一起或者一个功能集群少开一点虚拟机 节点角色主机名IP 地址核心职责Web 节点 1web01192.168.72.201挂载 NFS 共享,提供 Web 服务Web 节点 2web02192.168.72.202挂载 NFS 共享,提供 Web 服务Web 节点 3web03192.168.72.203挂载 NFS 共享,提供 Web 服务DNS 主节点dns-master192.168.72.107解析www.chengke.com到 Web VIPDNS 从节点dns-slave192.168.

不仅是记忆:设计前端侧的AI对话历史存储与上下文回溯方案

不仅是记忆:设计前端侧的AI对话历史存储与上下文回溯方案 在当前的大模型应用浪潮中,很多前端开发者切入AI领域的第一步往往是封装一个ChatGPT般的对话界面。起初,我们可能只是简单地将用户输入和AI回复Push到一个数组中,并在页面上渲染。然而,随着应用场景的深入,这种“玩具级”的架构很快就会面临严峻挑战。 背景:被忽视的“记忆”成本 很多前端同学在开发AI应用时,最容易踩的坑就是“只顾眼前交互,忽视持久化与上下文管理”。 痛点主要体现在三个方面: 1. 数据脆弱性:用户不小心刷新页面,长达几十轮的深度对话瞬间灰飞烟灭。这种体验在Web端是致命的,用户无法接受自己的“思考过程”因误操作而丢失。 2. 上下文窗口限制:大模型都有Token限制(如GPT-3.5的4k,GPT-4的8k/32k)。如果前端只是无脑累加历史记录发给后端,很快就会报错context_length_exceeded。前端必须具备“上下文回溯”与“裁剪”的能力。 3. 多会话管理:现代AI应用往往是多会话并行的(类似ChatGPT左侧列表)。如何高效索引、

纯前端 PNG/JPG 转 PDF 工具(无需服务器,源码分享)

纯前端 PNG/JPG 转 PDF 工具(无需服务器,源码分享)

纯前端 PNG/JPG 转 PDF 工具(无需服务器,源码分享) ✨ 一个完全运行在浏览器中的图片转 PDF 工具,不依赖后端、不上传文件、保护隐私,支持拖拽、排序、预览、批量导出,代码开源,一键部署! 🌐 在线演示 👉 https://longsongline.github.io/png-to-pdf/ 打开即可使用,无需注册、无需登录,所有处理都在你的浏览器中完成! 📦 功能特性 * ✅ 纯前端实现:基于 jsPDF + FileReader,无任何服务端依赖 * ✅ 隐私安全:图片不会上传到任何服务器,全程本地处理 * ✅ 多格式支持:PNG、JPG、BMP、TIFF、SVG(自动转 PNG) * ✅ 灵活输出: * 合并为单个 PDF(