部署运维
本文是一份可发布版部署记录。真实 IP、域名、账号、密码、下载链接、业务目录名、机器唯一标识等敏感信息已经替换为占位符。命令中的 <...> 需要按自己的环境替换。 目标与拓扑 这次目标是用三台数据节点部署一套 ClickHouse 高可用集群，拓扑采用： 1 shard x 3 replicas 含义是：集群只有一个逻辑分片，三台机器都保存同一份数据的完整副本。任意一台数据节点宕机时，只要 ClickHouse Keeper 仍然有多数派，剩余节点仍可继续提供读写服务。 规划节点如下： 主机名示例地址角色ch-01<ch-01-ip>ClickHouse Server + ClickHouse Keeperch-02<ch-02-ip>ClickHouse Server + ClickHouse Keeperch-03<ch-03-ip&
部署运维
上一篇聊完普通解析、泛域名解析、A 记录、TXT 记录、普通证书和通配证书之后，我对 DNS 的理解已经比以前清楚很多了。 以前我对 DNS 的理解基本停留在： 域名 -> IP 也就是： A 记录 后来才发现，DNS 不只是“把域名解析成 IP”。 它还承担了： 命名 寻址 验证 策略 委派 缓存 排障 这些角色。 这篇算是 DNS 的扩展篇，整理一下接下来还值得补的内容。 目标不是背概念，而是让自己以后遇到 DNS、证书、域名、Caddy、Cloudflare、阿里云解析这些问题时，能知道从哪里下手排查。 一、DNS 不只是
部署运维
最近在折腾 frp、Caddy、内网穿透和域名分流的时候，我突然发现一个问题： 我以前对 DNS 的理解其实挺片面的。 以前我理解 DNS，大概就是： 域名 -> IP 比如： weini.xin -> 服务器 IP www.weini.xin -> 服务器 IP 也就是说，我过去主要只知道 A 记录。 A 记录确实是 DNS 里最常见、最直观的一种记录，但这次深入折腾之后，我发现 DNS 远不只是“域名转 IP”这么简单。 它其实同时参与了： 域名寻址 服务入口命名 泛域名管理 证书验证
部署运维
这次踩了一个挺经典的坑：我在云服务器上折腾 frp 的时候，顺手开了 UFW 防火墙，结果把自己 SSH 入口给挡住了。 服务器没死，服务也没坏，但我就是连不上。 最后发现：不是服务器出问题，是我自己把自己关在了门外。 事情背景 我有一台云服务器，上面跑了一些服务： Caddy / Nginx Docker frp 一些 Go / Python / Node / Bun 服务 最近在折腾 frp，用来做内网穿透和服务分流。 因为涉及端口暴露，我当时想着：“要不顺手把 UFW 开起来，做一层本机防火墙？” 这个想法本身没错，但问题是：我这是一台云服务器。 云服务器本来就有一层安全组，比如阿里云安全组、腾讯云安全组、AWS Security Group 之类的。公网入口本来就可以在云后台控制。 结果我在云安全组之外，
Linux
最近我在折腾一个很实际的问题： 我有一台内网机器，上面跑着很多服务，每个服务都有自己的端口。现在我想把其中某些服务暴露到公网，让外部可以访问。 这个需求很常见。 比如我家里或者局域网里有一台 Ubuntu 机器，上面跑着： MCP 服务：8120 API 服务：8122 测试后台：8080 某个 Go 服务：9000 某个 Python 服务：7860 这些服务本身都在内网里，外部是访问不到的。 如果机器没有公网 IP，或者路由器不方便做端口映射，那传统方式就很麻烦。于是我用了 frp。 一开始我对 frp 的理解还比较简单： 它就是一个内网穿透工具，可以把内网端口暴露到公网服务器上。 但真正跑通之后，我对它的理解一步一步升级了。 一、frp 的核心逻辑：公网服务器帮内网机器“代收连接” frp 的结构其实很清晰： 外部用户
部署运维
记录一次从零开始部署 frp 的完整过程，包括原理理解、架构设计、踩坑排查，以及最终跑通的全流程。 背景 我有一台内网服务器，上面跑着一些本地服务（监听在 8900 端口）。同时我有一台云服务器，有公网 IP，上面已经用 Caddy 跑了一堆服务。 需求很简单：让公网能访问到我内网服务器上的服务。 方案：frp（Fast Reverse Proxy）—— 一个专注于内网穿透的反向代理工具。 frp 是什么 frp 由两个组件构成： * frps（server）：部署在有公网 IP 的服务器上 * frpc（client）：部署在内网机器上 它的工作原理： 1. frps 在公网服务器上启动，监听一个"控制端口"（默认 7000），等待客户端连接
AI
最近把一套 Embedding 服务完整落地了一遍：4 张显卡分别启动 vLLM 实例，用 Nginx 做统一入口和故障切换，再在上层挂一个 FastAPI 网关，把原始向量统一裁剪成 256 维并归一化，最终形成一套比较完整、可直接对外提供服务的 Embedding 架构。 这篇文章把整个过程完整整理一下，包含环境准备、离线模型部署、多卡启动、Nginx 配置、systemd 开机自启，以及业务网关设计。 整套架构的目标很明确： * 提供标准 HTTP Embeddings API * 支持四卡并行 * 支持统一入口与负载均衡 * 单实例故障时自动 failover * 支持开机自启 * 保留日志，便于运维与统计 一、整体架构 先看整体结构： Client │ ▼ FastAPI Gateway（8681） ← 推荐对外入口 │ ▼ Nginx（
AI
先把结论放前面：LTX-2.3（22B）这条 pipeline 在 4×RTX 3090（24GB）这套硬件上，按官方默认推理方式基本跑不起来。我最终得到的不是“没跑通”，而是一个更有价值的结果：把它为什么跑不起来、卡在哪、该怎么判断“物理不可行”，完整验证了一遍。 这篇文章是一次本地部署的工程复盘：从模型文件下载、依赖链补齐、环境和代码层踩坑，到显存拆分、多卡 device 规划，再到最终 OOM 的边界判断。希望你在遇到类似“看起来只要把权重放进去就能跑”的大模型工程时，可以少走很多弯路。 TL;DR（1 分钟读完） * LTX-2.3 不是单模型，而是一个多组件 pipeline：文本编码器（Gemma）+ 视频 diffusion 主模型（
AI
这篇记录的是我在一台 Mac mini（中国大陆网络环境）上安装并跑通 OpenClaw 的全过程：从一键安装开始，接入阿里 DashScope 的 OpenAI 兼容接口（Qwen），一路踩到 Node TLS 证书链问题，最后用 nvm 彻底解决，并成功进入 openclaw tui。 背景与目标 我想在本机快速体验 OpenClaw（一个可执行工具调用的 AI Agent 框架）。目标很明确： * 在 macOS 上装起来 * 不依赖海外大模型（尽量不需要外网） * 用 Qwen（DashScope 的 OpenAI-compatible 接口）作为模型后端 * 最终能启动到交互界面（TUI） 环境 * 设备：Mac mini
部署运维
背景：一次从 SQLite 到 PostgreSQL 的 Open WebUI 搬迁 Open WebUI 默认用的是 SQLite，部署起来很省心。但当你开始把它跑在更“正式”的环境里（多用户、长期保留聊天记录、附件和标签等），SQLite 往往就会成为瓶颈：备份、迁移、并发、运维手段都不如 PostgreSQL 顺手。 这篇文章记录我把一套旧版 Open WebUI（SQLite）迁移到新版 Open WebUI v0.8.11（PostgreSQL 16）的完整过程。核心目标很明确： * 保留多用户登录信息 * 保留历史聊天、消息、标签、文件等业务数据 * 新环境使用 Docker Compose，
陕公网安备61011302002223号