运维123 - Docker
type: channel
link: https://www.sddts.cn/index.php/tag/Docker/
items: next-socks5 轻量级 SOCKS5 服务器实战指南
items: Kubernetes 节点根分区磁盘占用过高排查复盘
items: next-socks5：基于 Rust 的轻量级 SOCKS5 服务器实战指南
items: 服务器集群运维文档
items: Zookeeper 容器连接超时故障复盘
items: Project N.O.M.A.D. 离线生存计算机系统
items: Folio-OCR 三栏文档 OCR 工作台
items: Axe CLI 工具指南
items: Debian 13 修复 Docker 权限与服务问题案例复盘
items: Docker 环境检查与验证

next-socks5 轻量级 SOCKS5 服务器实战指南
type: item
date: 2026-07-21T01:18:25+00:00
description: next-socks5 轻量级 SOCKS5 服务器实战指南一、概述1. 简介A. 是什么next-socks5 是一个用 Rust 语言编写的轻量级、高性能 SOCKS5 代理服务器，完全遵循 RFC 1928 和 RFC 1929 标准。它提供实时终端仪表板（TUI）和无头模式，适用于容器化部署，采用安全优先的设计理念。B. 为什么使用纯 Rust 实现，无 C 语言依赖，安全性高极低的资源占用和出色的性能表现提供实时可视化的监控仪表板原生支持容器化部署，适合云原生环境开箱即用的安全配置，默认防护 SSRF 攻击C. 使用场景搭建个人或团队的内网代理服务容器化环境中的网络代理解决方案需要实时监控的代理服务部署对安全性有较高要求的生产环境2. 前置知识A. 必备技能基本 Linux 命令行操作了解网络基础概念（TCP、UDP、IPv4/IPv6）了解 SOCKS5 代理协议基础B. 推荐知识Docker 容器基础操作systemd 服务管理TOML 配置文件格式二、环境准备1. 系统要求Linux：支持 musl libc 的 x86_64 或 aarch64 架构Docker：支持 Linux/amd64 和 Linux/arm64 架构macOS 和 Windows：可通过 Docker 运行2. 安装方式一键安装（推荐）使用官方提供的安装脚本，自动选择二进制或 Docker 部署：curl -fsSL https://raw.githubusercontent.com/ZingerLittleBee/next-socks5/main/install.sh | shDocker 安装curl -fsSL https://raw.githubusercontent.com/ZingerLittleBee/next-socks5/main/install.sh \ | sh -s -- --method docker --auth --port 1080手动下载二进制从 GitHub Releases 页面下载预编译的静态二进制文件：curl -fL -o next-socks5.tar.gz \ https://github.com/ZingerLittleBee/next-socks5/releases/latest/download/next-socks5-x86_64-unknown-linux-musl.tar.gz tar xzf next-socks5.tar.gz ./next-socks5-x86_64-unknown-linux-musl/next-socks5 serve --no-tui --listen 0.0.0.0:1080从源码编译git clone https://github.com/ZingerLittleBee/next-socks5 cd next-socks5 cargo build --release ./target/release/next-socks5 serve三、核心概念1. SOCKS5 协议基础SOCKS5 是一个代理协议，支持以下命令：CONNECT：建立 TCP 连接UDP ASSOCIATE：建立 UDP 关联BIND：已明确拒绝（设计决策）2. 认证方式无认证（No-Auth，0x00）：开放代理模式用户名密码认证（Username/Password，0x02）：RFC 1929 标准GSSAPI（0x01）：未实现（与大多数实现一致）3. 地址类型支持IPv4（ATYP 0x01）IPv6（ATYP 0x04）域名（ATYP 0x03）服务器支持服务端 DNS 解析，适用于 CONNECT 和 UDP 目标。4. 系统架构graph TD A[SOCKS5 客户端] -->|TCP 连接| B[SOCKS5 服务器] B -->|认证| C{认证模块} C -->|成功| D[请求处理] C -->|失败| E[拒绝连接] D --> F[CONNECT 中继] D --> G[UDP ASSOCIATE] F --> H[目标服务器] G --> H B --> I[TUI 仪表板] B --> J[日志输出]四、快速上手1. Hello World 示例启动无认证代理./install.sh --no-auth --port 1080启动带认证的代理./install.sh --auth --user alice --pass secret --port 10802. 测试代理测试无认证代理curl --socks5 127.0.0.1:1080 https://example.com测试带认证的代理curl --socks5 alice:secret…

Kubernetes 节点根分区磁盘占用过高排查复盘
type: item
date: 2026-07-15T01:10:22+00:00
description: Kubernetes 节点根分区磁盘占用过高排查复盘一、事件概述1. 事件背景2026 年 7 月 15 日上午，监控发现 K8s 工作节点 zcyun-k8s-node5（IP：10.10.184.204）根分区使用率持续攀升至 89%，逼近告警阈值，存在磁盘写满导致节点上所有 Pod 业务中断的风险。该节点承载物联网（IoT）数据、规则引擎、设备管理等核心服务。2. 影响范围A. 影响资源节点根分区 /dev/vda1（总容量 40G，已用 34G，剩余 4.5G）B. 风险等级P2 级（尚未触发业务故障，但距离写满仅一步之遥）C. 潜在影响若根分区写满，将导致节点上 28 个容器无法写入日志与临时数据，引发服务大面积异常、数据库连接失败、Pod 被驱逐等连锁问题。3. 处理结果经排查定位并处置后，根分区使用率从 89% 下降至 23%，释放约 25G 空间，节点恢复正常水位。二、排查过程1. 排查思路磁盘使用率过高的问题，按「先排除 inode 耗尽，再定位大文件归属，最后定位到具体文件」的层级化思路推进，整体决策流程如下。graph TD A["df 显示根分区 89%"] --> B{"inode 使用率?"} B -->|"仅 5%"| C["排除碎文件问题 锁定大文件"] C --> D["du 逐层定位 /var 29G"] D --> E["/var/lib/docker 24G overlay2 可写层"] E --> F["docker system df Containers 22.6G"] F --> G["docker ps -s 定位容器"] G --> H["iot-data 11.4G iot-rule 10.9G"] H --> I["进入容器可写层 UpperDir"] I --> J["rocketmq_client.log 10 份 1.1G 归档"] J --> K["根因锁定"]2. 步骤一：确认磁盘与 inode 状态首先通过 df 命令确认磁盘整体情况，并检查 inode 使用率以排除「小文件过多导致 inode 耗尽」的可能。df -h # 根分区 40G，已用 34G，89% df -i # inode 仅使用 5%结论：inode 使用率仅 5%，排除碎文件问题，判定为「少数大文件」占用空间。3. 步骤二：逐层定位大目录使用 du 命令从根目录逐层向下统计，定位空间占用大头。du -hx --max-depth=1 / # /var 29G du -hx --max-depth=1 /var # /var/lib 24G du -hx --max-depth=1 /var/lib # /var/lib/docker 24G结论：/var/lib/docker 占用 24G，其中 overlay2 目录为最大头；镜像本身仅 2.8G，说明问题出在容器运行时数据。4. 步骤三：区分镜像与容器可写层通过 docker system df 区分镜像缓存与容器可写层占用。docker system df关键发现：Containers 项 SIZE 为 22.61GB，但 RECLAIMABLE 为 0。这意味着占用来自「容器运行时写入可写层」的数据，而非镜像缓存，因此常规的 docker prune 清理无效。5. 步骤四：定位到具体容器通过 docker ps -s 查看每个容器可写层大小，按体积排序。docker ps -s --format 'table {{.Size}}\t{{.Names}}\t{{.Image}}'定位到两个异常容器：容器可写层大小镜像xcloud-srv-iot-data11.4Gnew-iot/xcloud-srv-iot-dataxcloud-srv-iot-rule10.9Gnew-iot/xcloud-srv-iot-rule两者合计约 22G，与容器总占用 22.61G 完全吻合。6. 步骤五：进入可写层定位具体文件通过 docker inspect 获取容器可写层路径（UpperDir），直接查看其中写入的大文件。docker inspect <容器名> --format '{{.GraphDriver.Data.UpperDir}}' # /var/lib/docker/overlay2/<hash>/diff在两个容器的 /root/logs/rocketmqlogs/ 目录下，均发现大量 RocketMQ 客户端日志：文件大小rocketmq_client.log.1 ~ rocketmq_client.log.10每份 1.1Grocketmq_client.log（当前写入）191M ~ 653M7. 步骤六：分析日志内容确认根…

next-socks5：基于 Rust 的轻量级 SOCKS5 服务器实战指南
type: item
date: 2026-07-03T00:33:56+00:00
description: next-socks5：基于 Rust 的轻量级 SOCKS5 服务器实战指南一、概述1. 简介A. 是什么next-socks5 是一个用 Rust 编写的轻量级、可扩展的 SOCKS5 服务器，完整实现了 RFC 1928 与 RFC 1929 协议规范。项目由 ZingerLittleBee 开源维护，采用纯 Rust 编写，无任何 C 依赖，可生成完全静态的 musl 二进制文件以及基于 scratch 的约 3.5 MB 容器镜像。项目核心特点：自研协议栈：手写 SOCKS5 协议解析，依赖足迹刻意保持精简双模式运行：TUI 终端仪表盘与适合容器的 headless 模式安全默认：默认开启出口流量过滤，防止 SSRF 与开放中继多种部署：支持一键脚本、Docker、预编译二进制、源码编译四种方式B. 为什么学传统 SOCKS5 实现（如 Dante、3proxy）存在以下痛点：老牌服务器多为 C 语言实现，依赖复杂，编译环境要求高缺乏现代运维所需的可观测性工具UDP 中继在 NAT 与容器环境下配置繁琐安全默认不足，容易因配置疏忽变成开放中继next-socks5 通过 Rust 的内存安全特性、TUI 仪表盘的实时观测能力、以及为 NAT/Docker 场景设计的 UDP 配置选项，系统性地解决了这些问题。C. 学完能做什么在自建服务器或云主机上快速部署一个安全的 SOCKS5 代理使用 TUI 仪表盘实时观测吞吐、连接数与错误统计在 NAT、Docker bridge 等复杂网络环境下正确配置 UDP 中继根据 RFC 1928 规范理解 SOCKS5 协议的工作原理2. 前置知识A. 必备技能基本的 Linux 命令行操作能力了解 TCP/UDP 协议基础熟悉代理服务器的基本概念B. 推荐知识Rust 编程基础（仅在源码编译时需要）Docker 与 docker compose 的使用防火墙配置（iptables、ufw 或 nftables）二、核心特性1. 协议支持A. SOCKS5 命令next-socks5 支持 RFC 1928 定义的核心命令：命令支持情况说明CONNECT完整支持用于 TCP 流量代理，如 HTTP、HTTPSUDP ASSOCIATE完整支持用于 UDP 流量代理，如 DNS、QUICBIND设计拒绝按设计返回回复码 0x07，出于安全考虑不开放B. 认证机制支持两种认证方式：No-Auth（0x00）：无认证，适用于受信任网络Username/Password（0x02）：用户名密码认证，符合 RFC 1929 规范认证模式下可配置多组凭证：客户端只要匹配列表中任意一组用户名密码即可通过，无需为每个用户开放独立端口。C. 地址类型支持三种 ATYP（Address Type）：0x01：IPv4 地址0x04：IPv6 地址0x03：Domain 域名（服务器端执行 DNS 解析）无论是 CONNECT 还是 UDP ASSOCIATE 目标，服务器都会执行 DNS 解析，避免客户端泄露真实 DNS 请求。D. RFC 错误码映射完整覆盖 RFC 1928 定义的回复码 0x00 至 0x08，典型映射关系：场景回复码含义成功0x00succeeded连接数超限0x02connection not allowed by ruleset网络不可达0x03network unreachable主机不可达0x04host unreachable连接被拒0x05connection refusedTTL 过期0x06TTL expired不支持的命令0x07command not supported不支持的地址类型0x08address type not supported2. 安全设计A. 出口过滤默认开启服务器默认拒绝转发到以下地址段，作为 SSRF 与开放中继的防护：回环地址（127.0.0.0/8、::1）链路本地地址（169.254.0.0/16），包括云元数据地址 169.254.169.254私有地址段（RFC 1918：10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）如确实需要访问内部目标，可通过配置文件中的 egress 段放宽限制。B. 防 slowloris 攻击握手阶段（greeting + auth + request）设置了独立的超时时间（默认 10 秒），超过 handshake_ms 未完成握手的连接将被强制断开，防止慢速攻击占用连接资源。C. 连接数限制提供两个可选的并发上限配置：max_connections：全局并发上限，防止文件描述符耗尽max_per_ip：单 IP 并发上限，防止单客户端独占资源或暴力破解两个限…

服务器集群运维文档
type: item
date: 2026-04-02T01:01:40+00:00
description: 服务器集群运维文档一、集群概览1. 集群信息A. 节点列表主机名IP 地址角色操作系统内核版本xlab-ecs-node2192.168.86.152Kubernetes 节点Ubuntu 22.04.5 LTS5.15.0-173-genericxlab-ecs-node3192.168.86.153Docker 容器节点Ubuntu 22.04.5 LTS5.15.0-173-genericB. 集群用途xlab-ecs-node2：Kubernetes 集群工作节点xlab-ecs-node3：Docker 容器部署节点二、硬件配置1. CPU 配置A. 处理器规格型号：Intel Xeon E5-2697 v2 @ 2.70GHz核心数：24 核（12 核/单线程 × 2 线程）频率范围：1200 MHz - 3500 MHz架构：x86_64B. 虚拟化支持VT-x：已启用VT-d：已启用2. 内存配置节点总内存可用内存Swapxlab-ecs-node262 GB约 58 GB8 GBxlab-ecs-node347 GB约 40 GB8 GB3. 存储配置A. 磁盘列表节点设备容量类型挂载点用途xlab-ecs-node2sda931.8 GBSSD/系统盘xlab-ecs-node3sda931.8 GBSSD/系统盘xlab-ecs-node3sdb238.5 GB未挂载-预留扩展B. 文件系统类型：ext4主分区：/dev/sda2 挂载于 /4. 网络配置A. 网卡信息网卡 1：enp11s0（Broadcom BCM57762 千兆以太网）网卡 2：enp12s0（Broadcom BCM57762 千兆以太网）无线网卡：wlp13s0（Broadcom BCM4360 802.11ac）B. 网络绑定绑定模式：bond0（Active-Backup）状态：双网卡绑定，高可用C. 网络接口对比节点bond0 MAC 地址容器网络xlab-ecs-node296:fd:b9:44:54:6bflannel.1 + cni0xlab-ecs-node3d2:4f:29:66:e9:dfdocker0 + 多个 bridge5. 显卡配置A. GPU 规格型号：AMD Radeon R7 370 / R9 270X/370X（双卡）芯片：Curacao XT / Trinidad XT数量：每台服务器 2 张三、系统环境1. 操作系统A. 基本信息发行版：Ubuntu 22.04.5 LTS（Jammy Jellyfish）版本 ID：22.04架构：x86_642. 内核配置A. 当前内核版本：5.15.0-173-generic编译时间：2026 年 3 月 6 日B. 启动参数BOOT_IMAGE=/boot/vmlinuz-5.15.0-173-generic root=UUID=<分区-UUID> ro intel_idle.max_cstate=1 mce=offC. 参数说明参数值作用intel_idle.max_cstate1限制 CPU C-State 到 C1，降低延迟mceoff禁用 Machine Check ExceptionD. GRUB 配置默认启动项：0等待时间：5 秒内核参数：intel_idle.max_cstate=1 mce=off3. 时区配置节点时区UTC 偏移xlab-ecs-node2Asia/ShanghaiUTC+8xlab-ecs-node3Etc/UTCUTC+0注意：两台节点时区不一致，建议统一为 Asia/Shanghai。4. 已安装内核当前版本：5.15.0-173-generic旧版本：5.15.0-119-generic（备用）四、容器运行时1. 运行时对比节点容器运行时网络插件xlab-ecs-node2Containerd + KubernetesFlannel + CNIxlab-ecs-node3DockerBridge 模式2. Kubernetes 节点（node2）A. 网络组件flannel.1：Overlay 网络cni0：CNI 网桥veth*：容器虚拟网卡B. Pod 网络MTU：1450网段：由 Flannel 自动分配3. Docker 节点（node3）A. 网络组件docker0：Docker 默认网桥br-*：用户自定义网桥veth*：容器虚拟网卡B. 容器网络MTU：1500模式：Bridge五、监控指标1. 系统资源A. CPU 监控使用率阈值：> 80% 告警负载阈值：1 分钟 > 核心数 × 0.8B. 内存监控使用率阈值：> 85% 告警Swap 使用：> 1 GB 告警C. 磁盘监控使用率阈值：> …

Zookeeper 容器连接超时故障复盘
type: item
date: 2026-04-01T11:59:37+00:00
description: Zookeeper 容器连接超时故障复盘一、事件概述1. 事件背景生产环境 Zookeeper 容器每天需要手动重启一次，否则会出现端口通但无法连接的问题。容器已运行 20 个月，问题近期频繁出现。2. 影响范围A. 影响用户数依赖 Zookeeper 的所有业务系统B. 影响时长问题累积约 24 小时后必须重启C. 影响功能服务注册发现、分布式协调、配置管理3. 严重程度P2 级故障（影响业务可用性，需每日人工干预）二、事件时间线1. 问题发现A. 现象描述端口 2181 可以 telnet 通客户端连接超时或失败重启容器后恢复正常B. 问题特征容器运行时间越长，问题越严重每天需要手动重启一次服务器：192.168.124.48（已脱敏）容器：confluentinc/cp-zookeeper:7.3.22. 问题诊断A. 日志分析通过日志分析发现配置问题：tickTime=3000 minSessionTimeout=6000 maxSessionTimeout=60000 (只有 60 秒) clientPortListenBacklog=-1B. 根因定位maxSessionTimeout 只有 60 秒，长连接客户端被断开clientPortListenBacklog 使用系统默认值，高负载时连接队列问题无自动重启策略，异常时无法自动恢复3. 解决方案实施sequenceDiagram participant O as 运维人员 participant S as 服务器 participant Z as Zookeeper O->>S: 创建配置文件 O->>Z: 停止旧容器 Note over Z: 容器卡住需强制删除 O->>S: kill 僵死进程 O->>Z: 强制删除容器 O->>Z: 创建新容器 Z-->>O: 启动成功 O->>Z: 验证配置三、问题分析1. 直接原因A. Session Timeout 配置过小maxSessionTimeout 只有 60 秒（20 × tickTime），对于需要长连接的客户端来说太短。B. 连接队列配置不当clientPortListenBacklog=-1，使用系统默认值，在高负载或连接累积情况下可能导致连接队列问题。C. 无自动重启机制RestartPolicy=no，容器异常时不会自动重启。2. 根本原因（5 Whys 分析）A. 为什么出现连接问题？Session 超时时间过短，客户端长连接被服务端主动断开。B. 为什么超时时间过短？使用默认配置，未根据业务场景调整参数。C. 为什么没有自动恢复？容器未配置自动重启策略。D. 为什么配置不当？缺乏容器化中间件的配置规范和最佳实践。3. 配置影响分析graph TB A[配置不当] --> B[maxSessionTimeout=60s] A --> C[clientPortListenBacklog=-1] A --> D[RestartPolicy=no] B --> E[长连接断开] C --> F[连接队列溢出] D --> G[异常无法自愈] E --> H[客户端连接失败] F --> H G --> I[需人工重启] H --> J[业务受影响] I --> J四、解决方案1. 临时方案A. 实施措施每天手动重启容器B. 效果评估临时恢复服务需持续人工干预治标不治本2. 永久方案A. 配置优化创建自定义配置文件 zookeeper.properties：tickTime=2000 dataDir=/var/lib/zookeeper/data dataLogDir=/var/lib/zookeeper/log clientPort=2181 initLimit=10 syncLimit=5 maxSessionTimeout=300000 minSessionTimeout=4000 clientPortListenBacklog=1024 server.1=zookeeper:2888:3888B. 容器重新创建docker run -d \ --name zookeeper \ --restart=unless-stopped \ --network root_yewu-network \ -p 2181:2181 \ -p 1812:2181 \ -v /root/data/zookeeper/data:/var/lib/zookeeper/data \ -v /root/data/zookeeper/log:/var/lib/zookeeper/log \ -v /root/data/zookeeper/secrets:/etc/zookeeper/secrets \ -v /root/…

Project N.O.M.A.D. 离线生存计算机系统
type: item
date: 2026-03-22T10:59:41+00:00
description: Project N.O.M.A.D. 离线生存计算机系统一、概述1. 项目简介A. 是什么Project N.O.M.A.D.（Node for Offline Media, Archives, and Data）是一个自包含的离线优先知识和教育服务器。它通过 Docker 容器化技术整合了关键工具、知识库和本地 AI，能够在任何时间、任何地点保持信息获取和赋能能力。B. 为什么需要网络基础设施可能因自然灾害、战争或其他突发事件而中断某些环境下互联网访问受限或不可用需要保证数据隐私和完全的本地控制教育资源在偏远地区的可用性问题C. 能做什么离线访问完整的维基百科、医学参考资料和电子书本地 AI 聊天助手，支持文档上传和语义搜索Khan Academy 课程学习平台，支持进度跟踪离线地图下载和导航数据加密、编码和分析工具本地笔记系统2. 核心特性A. 完全离线运行系统仅在初始安装时需要网络连接，之后可完全脱机运行，无内置遥测功能。B. 容器化架构基于 Docker 的容器编排，所有工具和服务以容器形式运行，便于管理和更新。C. 统一管理界面提供 Web 界面（Command Center）统一管理所有服务和资源。D. 本地 AI 能力通过 Ollama 和 Qdrant 实现本地大语言模型和向量数据库，支持 RAG（检索增强生成）。3. 项目背景A. 开发团队由 Crosstalk Solutions 开发和维护，采用 Apache 2.0 开源许可证。B. 社区支持拥有活跃的 Discord 社区和社区排行榜，用户可以分享硬件配置和性能数据。二、系统架构1. 整体架构Project N.O.M.A.D. 采用分层架构设计，通过 Docker 容器化技术整合多个独立服务。graph TB subgraph 用户层 Browser[Web 浏览器] end subgraph 管理层 CC[Command Center 管理界面] API[REST API] end subgraph 服务层 Kiwix[Kiwix 离线知识库] Kolibri[Kolibri 教育平台] Ollama[Ollama AI 服务] Qdrant[Qdrant 向量数据库] CyberChef[CyberChef 数据工具] FlatNotes[FlatNotes 笔记服务] Maps[ProtoMaps 离线地图] end subgraph 数据层 MySQL[(MySQL 数据库)] ZIM[ZIM 文件存储] Content[用户内容存储] end subgraph 基础设施层 Docker[Docker 容器引擎] Linux[Linux 操作系统] end Browser --> CC CC --> API API --> Kiwix API --> Kolibri API --> Ollama API --> Qdrant API --> CyberChef API --> FlatNotes API --> Maps Ollama --> Qdrant CC --> MySQL Kiwix --> ZIM FlatNotes --> Content API --> Docker Kiwix --> Docker Kolibri --> Docker Docker --> Linux2. 组件说明A. Command Center核心管理界面，提供统一的服务管理、配置和用户交互入口。B. 服务层组件Kiwix：离线知识库服务，支持 ZIM 格式内容Kolibri：离线教育平台，支持课程管理和进度跟踪Ollama：本地大语言模型运行时Qdrant：向量数据库，用于语义搜索和 RAGCyberChef：多功能数据处理工具FlatNotes：Markdown 笔记应用ProtoMaps：离线地图瓦片服务C. 数据存储MySQL：存储元数据、配置和用户数据ZIM 文件：存储离线知识库内容本地文件系统：用户上传内容和笔记3. 交互流程A. AI 对话流程sequenceDiagram participant U as 用户 participant CC as Command Center participant O as Ollama participant Q as Qdrant participant KB as 知识库 U->>CC: 发送问题 CC->>Q: 向量搜索 Q-->>CC: 返回相关文档 CC->>O: 构建提示词 O-->>CC: 返回响应 CC-->>U: 显示答案 Note over U,KB: 用户可上传文档 U->>CC: 上传文档 CC->>KB: 存储文档 CC->>Q: 建立向量索引B. 内容获取流程初始安装时从互…

Folio-OCR 三栏文档 OCR 工作台
type: item
date: 2026-03-16T22:01:43+00:00
description: Folio-OCR 三栏文档 OCR 工作台一、概述1. 简介A. 是什么Folio-OCR 是一款基于 GLM-OCR 和 Ollama 的三栏文档 OCR 工作台，专为书籍和文档的日常批量识别设计。它提供了一个现代化的 Web 界面，支持图片和 PDF 文件的批量光学字符识别，并具备智能版面分析、实时编辑和多种格式导出功能。B. 为什么学解决文档数字化过程中的人工识别效率问题利用本地化 OCR 方案保护数据隐私学习 FastAPI 前后端分离架构和版面分析技术了解如何将大型语言模型集成到实际应用中C. 学完能做什么搭建本地化的 OCR 识别服务批量处理 PDF 和图片文档使用版面分析技术提高识别准确率将识别结果导出为 Markdown、TXT 或 Word 文档2. 前置知识A. 必备技能基础的 Linux 命令行操作了解 Docker 基础概念B. 推荐知识Python 基础编程知识Web 开发基础概念OCR 和版面分析基础二、环境准备1. 系统要求操作系统：Linux、macOS、Windows 10/11Docker：20.10+（推荐使用 Docker 部署）Python：3.10+（本地部署）Ollama：已安装（本地部署）硬件：建议 8GB+ 内存，有 NVIDIA 显卡可获得更好性能2. 安装步骤Docker 部署（推荐）# 1. 克隆项目 git clone https://github.com/vorojar/Folio-OCR.git cd Folio-OCR # 2. 启动服务 docker compose up -d # 3. 下载 OCR 模型（约 2GB，只需执行一次） docker compose exec ollama ollama pull glm-ocr本地部署# 安装依赖 pip install -r requirements.txt # 拉取模型 ollama pull glm-ocr # 启动服务 python server.py # Windows 一键启动 start.bat3. 验证安装打开浏览器访问 http://localhost:3000，若能看到界面则表示安装成功。# 检查 Ollama 状态 curl http://localhost:11434/api/tags # 检查服务状态 curl http://localhost:3000/api/status三、核心概念1. 基本术语GLM-OCR：智谱 AI 开发的 OCR 模型，用于图像文字识别Ollama：本地化大模型运行平台，提供 GLM-OCR 的推理服务FastAPI：Python Web 框架，用于构建后端 APIPP-DocLayoutV3：PaddlePaddle 的文档版面分析模型SQLite：轻量级数据库，用于持久化存储文档和 OCR 结果版面分析：自动检测文档中的标题、正文、表格、图片等区域2. 工作原理graph LR User[用户] --> FE[前端界面] FE --> API[FastAPI 后端] API --> DB[(SQLite 数据库)] API --> Layout[版面分析模型] API --> Ollama[Ollama OCR 服务] Layout --> API Ollama --> API API --> FE API --> Storage[文件存储]系统采用三层架构设计：前端层：提供三栏式用户界面，负责文件上传、结果显示和用户交互后端层：FastAPI 提供 RESTful API，处理版面分析、OCR 调用和数据持久化服务层：Ollama 提供 OCR 推理服务，PP-DocLayoutV3 提供版面分析能力四、快速上手1. 基本使用流程graph TD A[启动服务] --> B[上传文档] B --> C[自动拆页处理] C --> D[版面分析] D --> E[OCR 识别] E --> F[编辑校对] F --> G[导出文档]2. 上传文档支持以下文件格式：图片：PNG、JPG、GIF、BMP文档：PDF支持多文件混合上传，系统会自动将所有文件合并为一个文档，并按页码顺序排列。3. OCR 识别系统提供两种 OCR 模式：单页识别：对选中的页面进行 OCR批量识别：点击 OCR All Pages 一键处理全部页面识别过程中会显示实时进度条和 ETA 时间估算，用户可以随时点击 Stop 按钮中断处理。4. 编辑与导出识别结果支持：Edit 模式：纯文本编辑，便于手动修正Preview 模式：实时渲染 HTML 表格和 Markdown 格式段落重排：自动合并因换行断开的段落导出格式：Markdown（.md）纯文本（.txt）Word 文档（.…

Axe CLI 工具指南
type: item
date: 2026-03-13T02:05:02+00:00
description: Axe CLI 工具指南一、概述1. 简介A. 是什么Axe 是一个轻量级的命令行工具，用于运行单用途的 AI 代理。它使用 TOML 配置文件定义代理行为，支持多个 AI 提供商，包括 Anthropic、OpenAI 和 Ollama（本地模型）。B. 为什么学简化 AI 代理的创建和部署流程支持代码版本控制和团队协作提供持久化内存和技能系统支持 MCP（Model Context Protocol）工具扩展C. 学完能做什么使用 TOML 文件定义和管理 AI 代理配置多提供商支持实现代理间的委托调用使用 Docker 容器化部署集成外部 MCP 工具2. 前置知识A. 必备技能基本 Linux 命令行操作了解 TOML 配置文件格式熟悉 Git 版本控制B. 推荐知识Docker 容器基础概念AI API 使用经验MCP 协议基础二、环境准备1. 系统要求Linux、macOS 或 WindowsGo 1.21+（源码编译）Docker（可选，用于容器化部署）2. 安装步骤使用 Homebrew 安装（推荐）：brew install jrswab/tap/axe使用 Go 安装：go install github.com/jrswab/axe@latestDocker 方式：docker pull ghcr.io/jrswab/axe:latest3. 验证安装axe --version axe --help三、核心概念1. 基本术语Agent（代理）：AI 实体，执行特定任务Skill（技能）：可复用的指令集Memory（内存）：持久化的对话历史MCP：Model Context Protocol，工具扩展协议Provider（提供商）：AI 模型服务提供商2. 工作原理graph TB subgraph "配置层" A[agents/*.toml 代理定义] B[skills/SKILL.md 技能指令] C[config.toml 凭证配置] end subgraph "执行层 - Axe CLI" D[运行命令解析] E[上下文构建] F[工具调用] end subgraph "提供商层" G[Anthropic API] H[OpenAI API] I[Ollama 本地模型] end subgraph "存储层" J[持久化内存 timestamped logs] K[工作目录 sandboxed] end A --> D B --> E C --> D D --> E E --> F F --> G F --> H F --> I F --> K J --> E L[stdin 管道输入] --> D M[cron/git hooks] --> D3. 配置目录结构默认配置目录为 $XDG_CONFIG_HOME/axe/，通常为：Linux：~/.config/axe/macOS：~/Library/Application Support/axe/目录结构：~/.config/axe/ ├── agents/ │ └── *.toml # 代理定义文件 ├── skills/ │ └── SKILL.md # 技能指令文件 ├── config.toml # 凭证配置 └── memory/ # 持久化内存日志四、快速上手1. Hello World 示例首先创建配置文件 ~/.config/axe/config.toml：[anthropic] api_key = "your_anthropic_api_key"创建代理定义 ~/.config/axe/agents/greeting.toml：name = "greeting" model = "claude-3-haiku-20240307" provider = "anthropic" [system] prompt = "你是一个友好的助手，用中文回答问题。" [max_tokens] input = 10000 output = 4096运行代理：axe run greeting "你好，请介绍一下自己"2. 核心功能演示管道输入支持：echo "解释这个代码的作用" | axe run coder < main.pyGit hook 集成：axe hook install pre-commit axe hook list axe hook remove pre-commit列出可用代理：axe list3. 代码讲解代理定义说明：name：代理标识符，用于 axe run 命令model：使用的基础模型名称provider：AI 提供商（anthropic、openai、ollama）system.prompt：系统提示词max_toke…

Debian 13 修复 Docker 权限与服务问题案例复盘
type: item
date: 2026-03-10T22:01:14+00:00
description: Debian 13 修复 Docker 权限与服务问题案例复盘一、事件概述1. 事件背景在 Debian 13（trixie）系统上，Docker 容器化平台出现功能异常，主要表现为权限拒绝和服务单元缺失问题。用户在尝试执行 docker 命令时遇到阻碍，影响正常的容器化开发和部署工作。2. 影响范围A. 影响功能docker ps、docker run 等命令无法正常执行Docker 守护进程无法启动无法进行容器镜像拉取和容器管理B. 影响用户系统管理员 lab 用户，需要使用 Docker 进行应用开发和部署工作3. 严重程度P2 级故障（开发工具功能受阻，不影响生产环境）二、问题分析1. 直接原因通过系统诊断发现三个直接问题：docker-ce 包处于 rc 状态（已删除但配置文件残留）用户 lab 不在 docker 用户组中Docker 守护进程的 systemd 服务单元缺失graph TB A[用户执行 docker ps] --> B{权限检查} B -->|不在 docker 组| C[权限拒绝] B -->|在 docker 组| D{服务检查} D -->|服务未启动| E[连接失败] D -->|服务运行中| F[正常执行] subgraph 根本原因 G[docker-ce 包缺失] H[用户未在 docker 组] I[systemd 服务单元缺失] end G -.导致.-> I H -.导致.-> C I -.导致.-> E2. 根本原因A. docker-ce 包被删除系统中 docker-ce 包的状态为 rc（removed but configuration files remain），这意味着：Docker 守护进程已被卸载只保留了客户端组件 docker-clisystemd 服务单元随之被删除已安装的残留组件：docker-cli（26.1.5+dfsg1）- Docker 客户端docker-buildx-plugin - Buildx 插件docker-compose-plugin - Compose 插件docker-ce-rootless-extras - Rootless 支持包B. 用户权限配置缺失用户 lab 不在 docker 用户组中，导致无法访问 Docker 守护进程的 Unix socket（/var/run/docker.sock）。C. 服务单元缺失由于 docker-ce 包被删除，systemd 服务单元文件 /usr/lib/systemd/system/docker.service 不存在，systemctl 无法找到 docker.service 单元。3. 深层分析问题的深层原因在于系统维护过程中可能发生了以下情况：误操作或自动清理工具移除了 docker-ce 包但未重新安装系统升级或包管理操作导致依赖关系异常用户配置未随环境变化同步更新Docker 架构中的关键依赖关系：docker-ce：包含 Docker 守护进程（dockerd）和 CLIcontainerd：底层容器运行时（系统中已正确安装）docker 用户组：控制 socket 访问权限systemd：服务管理和进程启动graph LR A[用户命令] --> B[docker CLI] B --> C[Docker Socket] C --> D[dockerd 守护进程] D --> E[containerd] E --> F[容器] subgraph 权限控制 G[docker 用户组] -.访问控制.-> C end subgraph 服务管理 H[systemd] -.管理.-> D end三、解决方案1. 重新安装 docker-ce 包# 更新 apt 软件包缓存 sudo apt update # 重新安装 docker-ce sudo apt install docker-ce安装过程中会自动：安装 Docker 守护进程 dockerd安装 systemd 服务单元到 /usr/lib/systemd/system/docker.service替换旧的 docker-cli 为官方的 docker-ce-cli安装完成后验证：dpkg -l | grep docker # 应显示 docker-ce 和 docker-ce-cli 为 ii（已安装）状态2. 启动并启用 Docker 服务# 启动 Docker 服务 sudo systemctl start docker # 设置 Docker 开机自启 sudo systemctl enable docker # 验证服务状态 sudo systemctl status docker预期输出应显示：Lo…

Docker 环境检查与验证
type: item
date: 2026-03-10T09:09:48+00:00
description: Docker 环境检查与验证一、系统环境1. 系统信息A. 发行版信息PRETTY_NAME="Debian GNU/Linux 13 (trixie)"NAME="Debian GNU/Linux"VERSION_ID="13"VERSION="13 (trixie)"VERSION_CODENAME=trixieDEBIAN_VERSION_FULL=13.3ID=debianB. 内核版本6.12.63+deb13-amd642. Docker 环境状态Docker version 29.3.0, build 5927d803. Docker Compose 版本Docker Compose version v5.1.0二、Docker 服务状态服务状态：active（运行中）三、功能验证1. Hello World 测试A. 测试过程使用 docker run hello-world 命令进行验证。该命令会从 Docker Hub 拉取 hello-world 镜像并运行容器。B. 测试结果测试成功完成。Docker 客户端成功连接到守护进程，拉取镜像并输出欢迎信息，验证了 Docker 环境的完整性和功能正常。四、可用命令参考1. Docker 基础命令docker version：查看 Docker 版本信息docker info：显示系统级信息docker images：列出本地镜像docker ps：列出运行中的容器docker ps -a：列出所有容器docker run：运行容器docker stop：停止容器docker rm：删除容器docker rmi：删除镜像docker logs：查看容器日志2. Docker Compose 命令docker compose version：查看 Docker Compose 版本docker compose up：创建并启动服务docker compose down：停止并移除容器docker compose ps：列出容器docker compose logs：查看服务日志docker compose exec：在服务中执行命令参考资料