Open Claude Proxy

发表于 2026-05-15 上层目录 Tools

OCP (Open Claude Proxy) 的开源项目，核心功能是： 将你的 Claude Pro/Max 订阅转换为一个标准的 OpenAI 兼容 API，从而让你在不需要支付额外 API 费用的情况下，在各种 IDE 和 AI 工具中使用 Claude 模型 。

它利用 已有的 Claude 订阅（Pro 或 Max），通过代理转换为 OpenAI 格式的接口，实现 0 额外 API 成本 。

多端共享 ：支持 LAN（局域网）共享，一个订阅可以供全家人、多台设备或多个 IDE 同时使用。

广泛兼容性 ：支持任何可以配置 OPENAI_BASE_URL 的工具，如 Cline、Cursor、Aider、Continue.dev 等。

局域网多用户管理 (v3.7.0+) : 支持创建多个 API Key，每个用户拥有独立的令牌和使用量统计，支持一键撤销。

一键配置工具 (ocp-connect) ：客户端只需一条命令即可自动检测并配置所有主流 IDE。

请求配额控制 (v3.8.0+) ：支持按 Key 设置日/周/月请求限制（例如限制小孩每天 20 次）。

SSE 心跳检测 (v3.12.0+) ：针对长时间推理任务发送心跳包，防止 IDE 因超时而断开连接。

高度对齐 (Alignment) ：项目严格遵循 cli.js （Claude Code 的核心）的行为，确保稳定性并防止接口漂移。

安装与部署

服务端要求

操作系统 ：macOS 或 Linux（不支持 Windows，因为涉及系统服务管理）。
运行环境 ：Node.js 22.5+，git。
核心依赖 ：必须安装并登录 Claude CLI。

服务端部署

安装 Claude 并登录

npm install -g @anthropic-ai/claude-code
claude auth login  # 按照提示完成网页授权

安装 OCP

git clone https://github.com/dtzp555-max/ocp.git
cd ocp

单机模式（默认）启动 Proxy ，此模式只能在本地使用 OCP，API URL 为 http://127.0.0.1:3456/v1
node setup.mjs

局域网模式 (LAN Mode) 。地址监听在 0.0.0.0:3456 ，允许其他设备通过网络访问

export OCP_ADMIN_KEY=$(openssl rand -base64 32)      # 设置管理员 Key，建议写入 ~/.zshrc 或 ~/.bashrc

node setup.mjs --bind 0.0.0.0 --auth-mode multi      # 局域网模式 (LAN Mode) 配置命令

OCP 状态管理

查看 Proxy 状态（usage + health）

$ ocp status
{
    "proxy": {
        "status": "ok",
        "version": "3.16.4",
        "uptime": "19h 9m",
        "auth": "ok",
        "activeSessions": 0
    },
    "requests": {
        "total": 26,
        "active": 0,
        "errors": 19,
        "timeouts": 1
    },
    "plan": "Usage API returned 401 with no rate-limit headers",
    "recentErrors": [
        {
            "time": "2026-05-15T02:55:44.482Z",
            "message": "Failed to authenticate. API Error: 401 Invalid authentication credentials\n"       # 底层的 Claude CLI 会话已经过期或被登出，重新登录 Claude Cli
        },
        {
            "time": "2026-05-15T02:55:49.181Z",
            "message": "Failed to authenticate. API Error: 401 Invalid authentication credentials\n"
        },
        {
            "time": "2026-05-15T02:55:54.932Z",
            "message": "Failed to authenticate. API Error: 401 Invalid authentication credentials\n"
        }
    ]
}

以下状态表示 Claude Cli 登录成功，可以看到 当前 Plan、Session utilizaiont/Percent、limit 等信息

$ ocp status
{
    "proxy": {
        "status": "ok",
        "version": "3.16.4",
        "uptime": "19h 14m",
        "auth": "ok",
        "activeSessions": 0
    },
    "requests": {
        "total": 26,
        "active": 0,
        "errors": 19,
        "timeouts": 1
    },
    "plan": {
        "currentSession": {
            "utilization": 0,
            "percent": "0%",
            "resetsIn": "1h 27m",
            "resetsAt": "2026-05-15T07:30:00.000Z",
            "resetsAtHuman": "Fri, May 15, 7:30 AM"
        },
        "weeklyLimits": {
            "allModels": {
                "utilization": 0.06,
                "percent": "6%",
                "resetsIn": "4d 15h",
                "resetsAt": "2026-05-19T22:00:00.000Z",
                "resetsAtHuman": "Tue, May 19, 10:00 PM"
            }
        },
        "extraUsage": {
            "status": "rejected",
            "disabledReason": "org_level_disabled"
        },
        "representativeClaim": "five_hour",
        "fallbackPercentage": 0.5
    },
    "recentErrors": [
    ]
}

查看 OCP 使用量信息

$ ocp usage
Plan Usage Limits
─────────────────────────────────────
  Current session       0% used
                      Resets in 1h 22m  (Fri, May 15, 7:30 AM)

  Weekly (all models)   6% used
                      Resets in 4d 15h  (Tue, May 19, 10:00 PM)

  Extra usage         off

Model Stats (since proxy start)
─────────────────────────────────────────────────────────────────────
  Model                      Reqs   OK  Err  Avg Time  Max Time  Avg Prompt  Max Prompt
  ─────────────────────────────────────────────────────────────────────────────────────
  claude-opus-4-6              26    7   20      185s      584s          1K          4K
  Total                        26

Proxy: up 19h 19m | 26 reqs | 0 active | 19 err | 1 timeout


$ ocp usage --by-key
No usage data yet.

浏览器访问 http://<IP>:3456/dashboard 可视化监控请求历史和计划用量。

子密钥管理

添加子密钥（子用户）

$ ./ocp keys add external-system
 
✓ Key created for "external-system"
 
  API Key: ocp_ShecmDRElEW
 
  Copy this key now — you won't see it again.
  Configure in IDE: OPENAI_API_KEY=ocp_ShecmDRElEW

查看子密钥状态

ocp usage --by-key

Chrome 浏览器自动执行方案

发表于 2026-05-14 上层目录 Tools

AI Agent 与浏览器的深度集成方案全景，以下为目前的四种主流方案

┌──────────────────────────────────────────────────────────────────────┐
│           Claude 操作浏览器的四大方案（按推荐度排序）                      │
├──────────────────────────────────────────────────────────────────────┤
│                                                                      │
│  方案 A：Claude for Chrome (官方扩展)        ⭐⭐⭐⭐⭐  推荐主选       │
│         → 官方原生方案，最稳定                                          │
│                                                                      │
│  方案 B：Playwright MCP Server                ⭐⭐⭐⭐⭐  自动化首选   │
│         → 程序化控制，适合测试与脚本                                     │
│                                                                      │
│  方案 C：Chrome DevTools MCP                  ⭐⭐⭐⭐    调试场景     │
│         → 性能分析、网络抓包                                            │
│                                                                      │
│  方案 D：Computer Use API                     ⭐⭐⭐    通用桌面控制    │
│         → 适合复杂桌面应用，非纯浏览器                                    │
│                                                                      │
└──────────────────────────────────────────────────────────────────────┘

方案 A：Claude for Chrome（官方扩展）— 强烈推荐主选

Claude Code 通过 Claude in Chrome 浏览器扩展集成，从 CLI 或 VS Code 扩展获得浏览器自动化能力。可以测试 Web 应用、用控制台日志调试、自动化表单填写，以及从网页提取数据。Claude 为浏览器任务打开新标签页并共享浏览器登录状态，可以访问所有你已登录的网站。浏览器操作在可见的 Chrome 窗口中实时运行。

┌────────────────────────────────────────────────────────────────────┐
│                Claude for Chrome 核心能力矩阵                       │
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│  📖 内容读取                                                        │
│     ├─ 当前页面 DOM 内容                                            │
│     ├─ 控制台日志（Console errors/warnings）                        │
│     ├─ 网络请求（Network requests）                                 │
│     └─ 多 Tab 内容（拖入标签组）                                     │
│                                                                    │
│  🖱️  浏览器操作                                                     │
│     ├─ 点击按钮、链接                                                │
│     ├─ 填写表单、输入文本                                            │
│     ├─ 导航跳转、刷新                                                │
│     ├─ 滚动、截图                                                    │
│     └─ 切换标签页                                                    │
│                                                                    │
│  🔐 会话继承                                                        │
│     └─ 自动复用你浏览器的登录状态（Gmail/AWS Console/Jira 等）       │
│                                                                    │
│  🎬 工作流录制                                                      │
│     ├─ 录制操作序列作为 GIF                                          │
│     └─ 保存为可重复执行的 Shortcuts                                  │
│                                                                    │
│  ⏰ 定时调度                                                        │
│     └─ 每日/每周/每月自动运行                                        │
│                                                                    │
└────────────────────────────────────────────────────────────────────┘

Claude for Chrome 完整安装流程

访问 Chrome Web Store
搜索 “Claude in Chrome”
确认发布者为 “Anthropic”（防止山寨）
点击 “Add to Chrome”
点击工具栏拼图图标 → 钉住 Claude 图标
用 Claude 账号登录

Claude for Chrome 包含了以下权限模式：

Ask before acting ： Claude 在每次操作前请求批准
Act without asking ： Claude 自主工作无需每步请求许可

┌─────────────────────────────────────────────────────────────────┐
│  权限模式选择决策                                                 │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  🟢 Ask before acting（推荐新手）                                │
│     ├─ 每步操作前询问                                            │
│     ├─ 适合：学习阶段、生产环境、敏感操作                          │
│     └─ 缺点：频繁打断                                            │
│                                                                 │
│  🟡 Act without asking（熟练后）                                 │
│     ├─ 完全自主执行                                              │
│     ├─ 适合：明确的重复性任务、低风险操作                          │
│     └─ 缺点：风险较高，需密切监督                                  │
│                                                                 │
│  🔴 Pre-approved per site（最佳实践）                            │
│     ├─ 按站点预批准 + 仍对高风险操作弹窗                          │
│     └─ 推荐：日常工作模式                                        │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Claude AI CLI

发表于 2026-05-12 上层目录 Tools

Claude 产品矩阵全景

产品形态	适用场景	适合你的工作
Claude.ai (Web/App)	通用对话、方案设计、知识问答	架构设计讨论、概念学习、文档撰写
Claude Code (CLI)	终端内代理式编程	核心推荐：代码编写、调试、远程运维
Claude API	集成到自有系统/脚本	自动化运维、自定义 Bot、CI/CD 集成
Claude in Chrome	浏览器自动化代理	AWS Console 操作、Web 控制台批量操作
Desktop App + MCP	桌面端 + 工具扩展	本地文件操作、多工具协同

Claude Code 与 IDE 集成的完整图谱

┌─────────────────────────────────────────────────────────────────────┐
│                     Claude Code 使用形态对比                          │
├──────────────────┬──────────────────┬──────────────────────────────┤
│  形态            │  适用场景          │  代表工具                     │
├──────────────────┼──────────────────┼──────────────────────────────┤
│  纯终端 CLI       │  SSH 远程服务器    │  iTerm / Windows Terminal    │
│                  │  自动化脚本任务    │  + claude 命令                │
├──────────────────┼──────────────────┼──────────────────────────────┤
│  IDE 插件深度集成  │  日常本地编码      │  VS Code / Cursor / Windsurf │
│  (推荐主战场)      │  代码 Review     │  JetBrains 系列               │
├──────────────────┼──────────────────┼──────────────────────────────┤
│  IDE 内嵌终端 CLI │  混合工作流        │  任意 IDE 的 Terminal 面板     │
└──────────────────┴──────────────────┴──────────────────────────────┘

官方支持的 IDE 一览

官方插件主要支持两大阵营： VS Code 扩展 （最完善，同样适用于 Cursor IDE，需要 VS Code 1.98.0+）和 JetBrains 插件 （IntelliJ IDEA、PyCharm、WebStorm、GoLand 等）。

编辑器/IDE	集成方式	推荐度	适合人群
VS Code	官方扩展（最完善）	⭐⭐⭐⭐⭐	DevOps 工程师首选
Cursor	官方扩展（同 VS Code）	⭐⭐⭐⭐⭐	喜欢 AI 原生体验
JetBrains 系列	官方插件	⭐⭐⭐⭐	Python/Java 开发者
Neovim / Vim	内嵌终端运行 CLI	⭐⭐⭐	服务器/极客工作流
Sublime / Emacs	内嵌终端运行 CLI	⭐⭐⭐	老牌编辑器用户

┌────────────────────────────────────────────────────────────────────┐
│              不同场景下的工具选择决策树                                │
└────────────────────────────────────────────────────────────────────┘

  你在做什么？
       │
       ├─ 本地代码开发/重构 ────────► VS Code + Claude Code 扩展 ✅
       │
       ├─ 远程服务器排障 ──────────► SSH + Claude Code CLI（终端）
       │
       ├─ 大型架构设计讨论 ─────────► claude.ai 网页版 + 多轮对话
       │
       ├─ 简单脚本快速写 ──────────► Claude Code CLI（任意目录起手）
       │
       ├─ 阅读理解大型代码库 ───────► VS Code + Claude Code（@-mention）
       │
       └─ CI/CD 中自动化运行 ──────► Claude Code Headless 模式

使用 Claude 高效编码的 10 条铁律

#	铁律	说明
1	先 Plan 后 Code	让 Claude 先输出实施计划再写代码
2	善用 @ 引用	精确传递上下文,避免泛泛而谈
3	多用选区上下文	选中代码再唤起 Claude,无需复述
4	写好 CLAUDE.md	项目 “入职文档” 是最重要的投资
5	小步快跑	一次只让 Claude 改一件事,及时 Review
6	保持 git 干净	每次 AI 改动前 commit,方便回滚
7	诊断信息驱动	让 lint/test 错误驱动 Claude 修复
8	善用 Checkpoint	改坏了用 IDE 的 checkpoint 回滚｜
9	/clear 重置上下文	长对话变慢就清空重开
10	关键命令进 deny	危险命令必须在 settings 中禁止

安装 Claude Code

# 前提：Node.js 18+ (建议用 nvm 管理)
# 检查 Node 版本
node --version

# 全局安装 Claude Code
npm install -g @anthropic-ai/claude-code

# 验证安装
claude --version

# 首次启动，按提示进行 OAuth 登录
cd ~/your-project
claude

首次运行会通过浏览器 OAuth 完成 API 鉴权，无需手动配置 API Key

Claude 相关的项目配置

强制建议在每个项目根目录创建一个 CLAUDE.md 文件，作为给 Claude 的 上下文(Context)说明书 ，用于介绍项目背景、技术栈、代码规范等。

必须建立的项目配置

your-project/
├── CLAUDE.md              # 项目级 Claude 上下文（必须），用于介绍项目背景、技术栈、代码规范等。
├── .claude/
│   ├── settings.json      # 项目级 Claude 设置
│   └── commands/          # 自定义 slash 命令，创建 Markdown 文件，就能定义你自己的命令
│       ├── deploy.md
│       └── rollback.md
├── .vscode/
│   ├── settings.json      # VS Code 工作区设置
│   └── extensions.json    # 推荐扩展列表
└── .gitignore

CLAUDE.md 示例：

CLAUDE.md

# 项目说明：生产环境 EKS 集群运维

## 技术栈
- AWS EKS 1.30, Kubernetes
- Terraform 1.9+ (后端 S3 + DynamoDB)
- Helm 3.15, ArgoCD 2.12
- 操作系统：Amazon Linux 2023 (workstation), Bottlerocket (nodes)

## 目录结构
- `terraform/` - IaC 代码，按环境分目录 (dev/staging/prod)
- `helm-charts/` - 自定义 Helm chart
- `argocd/` - ArgoCD Application 定义
- `scripts/` - Python/Bash 自动化脚本

## 编码规范
- Terraform: 使用 `terraform fmt`，模块化设计
- Python: 遵循 PEP 8，使用 type hints，必须有 docstring
- Shell: 使用 `set -euo pipefail`，避免 bashism

## 安全约束
- 禁止在代码中硬编码任何 secrets
- 所有 AWS 凭证通过 IAM Role + IRSA
- 修改 prod 环境前必须先在 staging 验证

## 常用命令
- 部署到 dev: `make deploy ENV=dev`
- 查看 EKS 集群: `aws eks update-kubeconfig --name prod-cluster --region ap-southeast-1`

.claude/settings.json 内容示例：

.claude/settings.json

{
  "model": "claude-sonnet-4-5",
  "permissions": {                   # 不在 allow 和 deny 列表中的命令，默认会请求你授权
    "allow": [                       # 列表中的命令 Claude 可以自动执行无需确认（安全的只读/格式化操作）
      "Bash(terraform fmt:*)",
      "Bash(terraform validate)",
      "Bash(terraform plan)",
      "Bash(kubectl get:*)",
      "Bash(kubectl describe:*)",
      "Bash(helm lint:*)"
    ],
    "deny": [                        # deny 列表中的命令 Claude 绝对不能执行（破坏性操作）
      "Bash(terraform apply:*)",
      "Bash(kubectl delete:*)",
      "Bash(rm -rf:*)"
    ]
  }
}

一定要注意： settings.json 是 “软约束”，不是 “硬隔离”。 settings.json 的 permissions 是 “权限提示层”，它能拦截 Claude 主动发起的危险命令，但无法防御 命令变形绕过（rm 写成 /bin/rm、用变量拼接）、通过脚本间接执行（写个 .sh 再跑）、通过已 allow 的工具造成的间接破坏

Claude 在生产环境中的配置参考

在生产环境中的服务器上使用 Claude，既要能让 Claude 充分发挥其能力，又要对其做出合理的限制，防止误操作或者权限溢出而对生产环境造成事故。

参考文件结构如下

~/projects/prod-ops/                    # 本地项目目录（VS Code 打开这里）
├── CLAUDE.md                           # 行为引导
├── .claude/
│   ├── settings.json                   # 项目级权限（提交到 git）
│   ├── settings.local.json             # 个人临时覆盖（不提交 git）
│   └── hooks/
│       └── pretooluse-guard.sh         # 执行前拦截脚本
├── ansible/
├── terraform/
└── scripts/

CLAUDE.md

这是第一道防线，也是最容易被忽视的一道。它的作用是从源头降低 Claude 尝试危险操作的概率。

参考 claude_rules.md 文件获取详细的行为规范和使用指南。

.claude/settings.json

这是第二道防线，提交到 git 仓库，团队共享。

{
  "permissions": {
    "defaultMode": "default",

    "deny": [
      "Bash(rm:*)",
      "Bash(rmdir:*)",
      "Bash(mv:*)",
      "Bash(dd:*)",
      "Bash(mkfs:*)",
      "Bash(shred:*)",
      "Bash(truncate:*)",
      "Bash(sudo:*)",
      "Bash(su:*)",
      "Bash(doas:*)",
      "Bash(chmod:*)",
      "Bash(chown:*)",
      "Bash(chgrp:*)",
      "Bash(passwd:*)",
      "Bash(useradd:*)",
      "Bash(userdel:*)",
      "Bash(usermod:*)",
      "Bash(systemctl stop:*)",
      "Bash(systemctl restart:*)",
      "Bash(systemctl disable:*)",
      "Bash(systemctl mask:*)",
      "Bash(service:*)",
      "Bash(kill:*)",
      "Bash(killall:*)",
      "Bash(pkill:*)",
      "Bash(reboot:*)",
      "Bash(shutdown:*)",
      "Bash(halt:*)",
      "Bash(poweroff:*)",
      "Bash(init:*)",
      "Bash(iptables:*)",
      "Bash(nft:*)",
      "Bash(ufw:*)",
      "Bash(firewall-cmd:*)",
      "Bash(crontab:*)",
      "Bash(at:*)",
      "Bash(mount:*)",
      "Bash(umount:*)",
      "Bash(fdisk:*)",
      "Bash(parted:*)",
      "Bash(lvremove:*)",
      "Bash(vgremove:*)",
      "Bash(docker rm:*)",
      "Bash(docker rmi:*)",
      "Bash(docker stop:*)",
      "Bash(docker kill:*)",
      "Bash(docker system prune:*)",
      "Bash(docker volume rm:*)",
      "Bash(docker-compose down:*)",
      "Bash(kubectl delete:*)",
      "Bash(kubectl drain:*)",
      "Bash(kubectl cordon:*)",
      "Bash(kubectl scale:*)",
      "Bash(kubectl apply:*)",
      "Bash(kubectl edit:*)",
      "Bash(kubectl patch:*)",
      "Bash(kubectl replace:*)",
      "Bash(kubectl rollout:*)",
      "Bash(helm install:*)",
      "Bash(helm upgrade:*)",
      "Bash(helm uninstall:*)",
      "Bash(helm rollback:*)",
      "Bash(helm delete:*)",
      "Bash(terraform apply:*)",
      "Bash(terraform destroy:*)",
      "Bash(terraform import:*)",
      "Bash(terraform state rm:*)",
      "Bash(terraform state mv:*)",
      "Bash(aws ec2 terminate-instances:*)",
      "Bash(aws ec2 stop-instances:*)",
      "Bash(aws rds delete:*)",
      "Bash(aws s3 rb:*)",
      "Bash(aws s3 rm:*)",
      "Bash(mysql:*)",
      "Bash(psql:*)",
      "Bash(mongo:*)",
      "Bash(redis-cli:*)",
      "Read(**/secrets/**)",
      "Read(**/*.pem)",
      "Read(**/*.key)",
      "Read(**/id_rsa)",
      "Read(**/id_ed25519)",
      "Read(**/.aws/credentials)",
      "Read(**/.ssh/**)",
      "Read(**/kubeconfig)",
      "Write(/etc/**)",
      "Write(/usr/**)",
      "Write(/bin/**)",
      "Write(/sbin/**)",
      "Write(/var/**)",
      "Write(/boot/**)",
      "Write(/root/**)",
      "Edit(/etc/**)",
      "Edit(/usr/**)",
      "Edit(/var/**)",
      "WebFetch"
    ],

    "ask": [
      "Bash(git push:*)",
      "Bash(git reset:*)",
      "Bash(git checkout:*)",
      "Bash(git clean:*)",
      "Bash(docker exec:*)",
      "Bash(docker run:*)",
      "Bash(kubectl exec:*)",
      "Bash(kubectl cp:*)",
      "Bash(kubectl port-forward:*)",
      "Bash(scp:*)",
      "Bash(rsync:*)",
      "Bash(curl:*)",
      "Bash(wget:*)",
      "Bash(tee:*)",
      "Bash(ansible:*)",
      "Bash(ansible-playbook:*)",
      "Bash(terraform plan:*)",
      "Bash(npm install:*)",
      "Bash(pip install:*)",
      "Write(*)",
      "Edit(*)"
    ],

    "allow": [
      "Bash(ls:*)",
      "Bash(pwd)",
      "Bash(cd:*)",
      "Bash(cat:*)",
      "Bash(head:*)",
      "Bash(tail:*)",
      "Bash(less:*)",
      "Bash(more:*)",
      "Bash(grep:*)",
      "Bash(egrep:*)",
      "Bash(rg:*)",
      "Bash(find:*)",
      "Bash(awk:*)",
      "Bash(sed:-n*)",
      "Bash(wc:*)",
      "Bash(sort:*)",
      "Bash(uniq:*)",
      "Bash(diff:*)",
      "Bash(file:*)",
      "Bash(stat:*)",
      "Bash(tree:*)",
      "Bash(echo:*)",
      "Bash(date:*)",
      "Bash(whoami)",
      "Bash(hostname)",
      "Bash(uname:*)",
      "Bash(uptime)",
      "Bash(id)",
      "Bash(env)",
      "Bash(ps:*)",
      "Bash(top:-b*)",
      "Bash(htop:*)",
      "Bash(free:*)",
      "Bash(df:*)",
      "Bash(du:*)",
      "Bash(vmstat:*)",
      "Bash(iostat:*)",
      "Bash(mpstat:*)",
      "Bash(sar:*)",
      "Bash(lsof:*)",
      "Bash(ss:*)",
      "Bash(netstat:*)",
      "Bash(ip:*)",
      "Bash(ping:-c*)",
      "Bash(dig:*)",
      "Bash(nslookup:*)",
      "Bash(host:*)",
      "Bash(traceroute:*)",
      "Bash(journalctl:*)",
      "Bash(dmesg:*)",
      "Bash(systemctl status:*)",
      "Bash(systemctl list-units:*)",
      "Bash(systemctl list-unit-files:*)",
      "Bash(systemctl is-active:*)",
      "Bash(systemctl is-enabled:*)",
      "Bash(systemctl cat:*)",
      "Bash(systemctl show:*)",
      "Bash(docker ps:*)",
      "Bash(docker logs:*)",
      "Bash(docker inspect:*)",
      "Bash(docker stats:*)",
      "Bash(docker images:*)",
      "Bash(docker version)",
      "Bash(docker info)",
      "Bash(docker network ls)",
      "Bash(docker volume ls)",
      "Bash(kubectl get:*)",
      "Bash(kubectl describe:*)",
      "Bash(kubectl logs:*)",
      "Bash(kubectl top:*)",
      "Bash(kubectl version:*)",
      "Bash(kubectl config view:*)",
      "Bash(kubectl config get-contexts:*)",
      "Bash(kubectl api-resources:*)",
      "Bash(kubectl explain:*)",
      "Bash(kubectl cluster-info)",
      "Bash(helm list:*)",
      "Bash(helm status:*)",
      "Bash(helm get:*)",
      "Bash(helm history:*)",
      "Bash(helm show:*)",
      "Bash(helm lint:*)",
      "Bash(helm template:*)",
      "Bash(terraform fmt:*)",
      "Bash(terraform validate)",
      "Bash(terraform version)",
      "Bash(terraform show:*)",
      "Bash(terraform output:*)",
      "Bash(terraform state list)",
      "Bash(terraform state show:*)",
      "Bash(tflint:*)",
      "Bash(ansible --version)",
      "Bash(ansible-playbook --check:*)",
      "Bash(ansible-playbook --syntax-check:*)",
      "Bash(ansible-lint:*)",
      "Bash(ansible-inventory:*)",
      "Bash(aws sts get-caller-identity)",
      "Bash(aws ec2 describe-instances:*)",
      "Bash(aws s3 ls:*)",
      "Bash(aws eks describe-cluster:*)",
      "Bash(aws eks list-clusters:*)",
      "Bash(aws cloudwatch describe-alarms:*)",
      "Bash(git status)",
      "Bash(git log:*)",
      "Bash(git diff:*)",
      "Bash(git show:*)",
      "Bash(git branch)",
      "Bash(git remote:-v)",
      "Bash(nginx -t)",
      "Bash(nginx -T)",
      "Read(*)"
    ],

    "additionalDirectories": [],

    "disableBypassPermissionsMode": "disable"
  },

  "model": "claude-sonnet-4-5",

  "env": {
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1"
  }
}

defaultMode: "default" : 未匹配任何规则的操作 → 询问用户
deny : 硬拦截所有破坏性命令。deny 优先级最高，任何层级都无法覆盖
ask : 半危险操作（写文件、curl、git push） → 弹窗确认
allow : 所有只读、诊断类命令 → 自动执行. 充分发挥能力的关键，让 Claude 流畅排查
disableBypassPermissionsMode: "disable" : 禁止 --dangerously-skip-permissions ，禁止跳过所有权限检查的 bypass 模式
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC : 关闭非必要网络流量, 生产环境降噪

规则支持精确匹配、前缀通配符（prefix:）和模式通配符（）。ToolName 是首字母大写的工具名（如 Bash、Write、Read），括号内是可选的内容模式。

Bash(rm:*)           → 拦截所有以 rm 开头的命令
Bash(kubectl get:*)  → 允许所有 kubectl get 子命令
Read(**/.env)        → 拦截读取任意路径下的 .env 文件
Write(/etc/**)       → 拦截写入 /etc 下任意文件

.claude/settings.local.json

个人临时覆盖（不提交 git）。临时需要某个权限时，在这里加，不污染团队共享的 settings.json 。记得加进 .gitignore

{
  "permissions": {
    "ask": [
      "Bash(terraform plan:*)"
    ]
  }
}

注意： settings.json 的 deny 有个致命弱点: 命令变形可以绕过 ，比如：

# settings.json deny 了 "Bash(rm:*)"，但这些可能绕过：
/bin/rm -rf /data           # 用绝对路径
R=rm; $R -rf /data          # 用变量拼接
echo "rm -rf /data" | bash  # 通过管道执行

Hooks 让你能在 Claude 执行工具前后触发自己的 shell 脚本，实现更深的自动化和护栏。这是 真正能防住命令变形 的一层。

.claude/hooks/pretooluse-guard.sh

#!/usr/bin/env bash
# PreToolUse Hook —— 在 Claude 执行 Bash 命令前做深度安全校验
# 退出码 2 = 阻止执行；退出码 0 = 放行

set -euo pipefail

# Claude Code 通过 stdin 传入 JSON，包含工具调用信息
INPUT=$(cat)

# 提取实际要执行的命令（需要 jq）
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

# 如果不是 Bash 命令，直接放行
if [[ -z "$COMMAND" ]]; then
  exit 0
fi

# ── 危险模式黑名单（正则）──────────────────────────────
# 这里检测的是"语义"，能抓住变形后的命令
DANGEROUS_PATTERNS=(
  '\brm\s+.*-[rf]'                    # rm -rf / rm -f（任意位置）
  '/bin/rm'                           # 绝对路径调用 rm
  '\bdd\s+'                           # dd 命令
  '\bmkfs'                            # 格式化
  '>\s*/(etc|usr|var|boot|bin|sbin)'  # 重定向覆盖系统目录
  '\bsudo\b'                          # 提权
  '\bsu\s'                            # 切换用户
  ':\(\)\s*\{.*\|.*&\s*\}'            # fork bomb
  '\bchmod\s+.*777'                   # 危险权限
  '\bsystemctl\s+(stop|restart|disable|mask)'
  '\b(kill|pkill|killall)\b'
  '\b(reboot|shutdown|halt|poweroff)\b'
  '\bkubectl\s+(delete|drain|apply|patch|scale|edit)'
  '\bhelm\s+(install|upgrade|uninstall|rollback|delete)'
  '\bterraform\s+(apply|destroy|import)'
  '\bdocker\s+(rm|rmi|stop|kill|prune)'
  '\b(mysql|psql|mongo|redis-cli)\b'  # 直连数据库
  'curl.*\|\s*(bash|sh)'              # curl | bash 远程执行
  'wget.*\|\s*(bash|sh)'
  'eval\s'                            # eval 动态执行
)

for pattern in "${DANGEROUS_PATTERNS[@]}"; do
  if echo "$COMMAND" | grep -qE "$pattern"; then
    # 输出到 stderr，Claude 会看到这个原因
    echo "🚫 安全拦截：命令匹配危险模式 [$pattern]" >&2
    echo "被拦截的命令：$COMMAND" >&2
    echo "如确需执行，请人工在终端手动操作。" >&2
    exit 2   # 退出码 2 = 阻止执行
  fi
done

# ── 生产环境主机名二次确认 ──────────────────────────
# 如果命令里包含生产环境标识，记录审计日志
if echo "$COMMAND" | grep -qiE 'prod|production'; then
  echo "$(date '+%Y-%m-%d %H:%M:%S') [PROD-CMD] $COMMAND" \
    >> ~/.claude/audit-prod.log
fi

# ── 全量审计日志 ────────────────────────────────────
echo "$(date '+%Y-%m-%d %H:%M:%S') $COMMAND" >> ~/.claude/audit-all.log

exit 0

添加可执行权限

chmod +x ~/projects/prod-ops/.claude/hooks/pretooluse-guard.sh

在前面的 settings.jso n 里追加 hooks 配置块

{
  "permissions": {
    "...": "（前面的权限配置不变）"
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/pretooluse-guard.sh"
          }
        ]
      }
    ]
  }
}

Hook 的价值 ：

settings.json 的 deny 是字面匹配， hook 是语义/正则匹配
Hook 能做上下文感知判断（比如检测主机名、时间窗口）
Hook 顺便实现了全量审计日志——这在事故复盘时极其宝贵

ArgoCD 部署使用

发表于 2026-02-12 更新于 2026-05-08 上层目录 Kubernetes

ArgoCD 是目前 Kubernetes 生态中最流行的 GitOps 持续交付（CD）工具。它的核心理念是将 Git 仓库视为集群状态的 “唯一真理来源”。

ArgoCD 的核心工作原理 ：

声明式管理 ：你不在集群里手动运行 kubectl ，而是将所有的资源清单（YAML、Helm、Kustomize）存放在 Git 中管理。
同步与漂移检测 ：ArgoCD 会持续监控 Git 仓库和 EKS 集群。如果两者状态不一致（即发生 “漂移”），它会报警或自动将集群恢复到 Git 定义的状态。

Argo CD 核心概念说明

ArgoCD Application 删除时的 Propagation Policy

在 Argo CD 中，当你删除一个 Application 时，Propagation Policy（传播策略）决定了该应用下属的 Kubernetes 资源（如 Deployment, Service, ConfigMap 等）应该如何处理。本质上是调用了 Kubernetes API 的删除机制，Argo CD 利用 K8s 的 Finalizer 机制来实现这一逻辑

策略名称	行为描述	结果
Foreground Cascade(前台级联)	最常用。先删除子资源，最后删除 Application 本身。	集群资源被彻底清理，最安全。
Background Cascade(后台级联)	立即删除 Application，子资源在后台由 K8s 垃圾回收机制静默删除。	最终结果同上，但 Application 对象消失得更快。
Orphan (Non-cascading ,孤儿模式)	只删壳，不删内容。只删除 Application 对象，保留集群里的实际资源。	资源继续运行，不再受 Argo CD 管控。这通常用于迁移场景 :你只想让 Argo CD 不再管这个应用，但不想让业务停掉。

在 Kubernetes 集群中安装 ArgoCD

# kubectl create namespace argocd
namespace/argocd created

# kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml --server-side
customresourcedefinition.apiextensions.k8s.io/applications.argoproj.io serverside-applied
customresourcedefinition.apiextensions.k8s.io/applicationsets.argoproj.io serverside-applied
customresourcedefinition.apiextensions.k8s.io/appprojects.argoproj.io serverside-applied
serviceaccount/argocd-application-controller serverside-applied
...
networkpolicy.networking.k8s.io/argocd-applicationset-controller-network-policy serverside-applied
networkpolicy.networking.k8s.io/argocd-dex-server-network-policy serverside-applied
networkpolicy.networking.k8s.io/argocd-notifications-controller-network-policy serverside-applied
networkpolicy.networking.k8s.io/argocd-redis-network-policy serverside-applied
networkpolicy.networking.k8s.io/argocd-repo-server-network-policy serverside-applied
networkpolicy.networking.k8s.io/argocd-server-network-policy serverside-applied

--server-side 选项用于解决可能的报错： The CustomResourceDefinition "applicationsets.argoproj.io" is invalid: metadata.annotations: Too long: may not be more than 262144 bytes

等待 ArgoCD 相关 Pod 运行正常

# kubectl get pods -n argocd
NAME                                               READY   STATUS    RESTARTS        AGE
argocd-application-controller-0                    1/1     Running   0               6m11s
argocd-applicationset-controller-77475dfcf-qzvsf   1/1     Running   1 (3m47s ago)   6m15s
argocd-dex-server-6485c5ddf5-4ms4f                 1/1     Running   0               6m14s
argocd-notifications-controller-758f795776-4n5rb   1/1     Running   0               6m14s
argocd-redis-6cc4bb5db5-svpwm                      1/1     Running   0               6m13s
argocd-repo-server-c76cf57cd-pv8sb                 1/1     Running   0               6m12s
argocd-server-6f85b59c87-zhmqh                     1/1     Running   0               6m12s

创建 Ingress 对外开放 ArgoCD UI，本示例中 IngressClass 为 AWS alb

argocd_ingress.yml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: argocd
  namespace: argocd
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip

spec:
  ingressClassName: alb
  rules:
  - host: argocd.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: argocd-server
            port:
              number: 80

创建并检查 Ingress

# kubectl apply -f argocd_ingress.yml 
ingress.networking.k8s.io/argocd configured

# kubectl get ingresses -A
NAMESPACE   NAME     CLASS   HOSTS                ADDRESS                                               PORTS   AGE
argocd      argocd   alb     argocd.example.com   k8s-argocd-argocd-8e8cb.ap-east-1.elb.amazonaws.com   80      8m22s

ArgoCD Pod 强制开启了 TLS (HTTPS)，而 ALB 却在使用 HTTP 进行健康检查。会因为健康检查失败无法访问

在集群中的 Pod 中尝试请求 argocd-server Pod 的地址，可以看到默认返回了重定向到 HTTPS 的响应，ALB 会因为证书问题对 Pod 健康检查失败

# curl -Iv 172.31.68.215:8080
> HEAD / HTTP/1.1
> Host: 172.31.68.215:8080
> User-Agent: curl/8.18.0
> Accept: */*
> 

HTTP/1.1 307 Temporary Redirect
Location: https://172.31.68.215:8080/

可以配置 ArgoCD 接受 HTTP 协议请求。 修改 ArgoCD Server 启动参数 ，执行命令 kubectl edit deployment argocd-server -n argocd 编辑 argocd-server 的 Deployment，在启动命令（ command ）中添加 --insecure 参数。

containers:
- args:
  - /usr/local/bin/argocd-server
  - --insecure

修改后等待 Pod 自动重启

$ kubectl get pods -A
NAMESPACE     NAME                                               READY   STATUS    RESTARTS   AGE
argocd        argocd-server-6ff754765c-pt5z6                     0/1     Running   0          18s

再次观察 ALB 的 Target 健康检查状态

ArgeCD 可以正常访问后，执行以下命令获取初始 admin 账户的密码

kubectl get secret argocd-initial-admin-secret -n argocd -o jsonpath="{.data.password}" | base64 -d

ArgoCD UI 常用操作

创建 Project

Project 可以实现资源或者 APP 的逻辑隔离，可以通过 Project 限制 APP 对以下资源的使用：

SOURCE REPOSITORIES ：限制该 Project 下的 Application 只能从指定的 Git Reop 或者 Helm 仓库拉取配置（Manifest）。防止越权拉取。
SCOPED REPOSITORIES ：只允许属于 Project 的 APP 从指定的 Reop 拉取代码（Manifest）
DESTINATIONS / SCOPED CLUSTERS ：限制属于 Project 的 APP 只能部署到指定的 Kubernetes 集群（（Server URL/Name））和 Namespace。支持通配符。例如限制只能部署到 in-cluster 的 dev-* 命名空间。
cluster resource allow list / cluster resource deny list ： Kubernetes Cluster 范围内允许/拒绝使用的资源，针对 非命名空间资源（如 ClusterRole, CustomResourceDefinition, Namespace, StorageClass）
namespace resource allow list / namespace resource deny list ： Namespace 范围的资源限制/允许，针对 命名空间资源（如 Deployment, Service, Secret, ConfigMap） 。

多用户与权限控制

Argo CD 有两个核心组件控制权限：

argocd-server（认证）
argocd-rbac-cm（授权）

Argo CD 支持三种用户方式

本地用户（不推荐生产）
SSO（推荐生产） ，支持：
- GitHub
- GitLab
- Azure AD
- Google
- OIDC
- LDAP
- Okta
- Keycloak
Kubernetes RBAC 模式（高级） 。可以让 ServiceAccount 调用 Argo API。

使用配置文件批量管理 ArgoCD APP

在 ArgoCD 的实践中， Root App（根应用） 模式通常被称为 App of Apps（应用集应用） 模式。它是管理大规模 Kubernetes 集群和多租户环境的核心架构方案。

简单来说，与其在 ArgoCD 界面上手动一个个创建应用，不如创建一个 Root App（父应用） ，由它来自动管理和同步所有的 Application（子应用） 。

在 Kubernetes 中，ArgoCD 的一切配置都是资源（CRD）。一个 Application 资源的 YAML 定义了：

Source : 代码仓库地址、路径、分支。
Destination : 目标集群和命名空间。

Root App 的逻辑是：建立一个特殊的 Root Application ，它的 Source 指向一个存放了多个子应用（Application） YAML 文件的 Git 目录。当 Root App 同步时，它会在集群中生成这些子应用资源，随后 ArgoCD 监听到这些新生成的子应用，进而去同步具体的业务代码。

为什么需要 Root App？

声明式管理 (GitOps) ：所有的应用配置都在 Git 中。如果你想增加一个微服务，只需在 Git 里加一个 Application YAML 文件，Root App 会自动感知并创建。
灾备恢复 ：如果 ArgoCD 挂了或需要迁移，你只需要手动部署这一个 Root App，它会像树根一样带出整棵应用的 “树”。
应用权限控制 ：管理员只需要把控 Root App 的权限，普通开发人员在指定目录下提交代码即可。

创建 Root App

Linux KVM 配置说明

发表于 2026-05-07 上层目录 Linux

KVM（Kernel-based Virtual Machine） 是 Linux 内核的一个模块，它将 Linux 内核转变为一个 Type-1（裸机级） 虚拟机管理程序（Hypervisor/VMM） 。

KVM 本身并不模拟硬件，它只负责处理器虚拟化和内存虚拟化。它需要配合 QEMU 来模拟 I/O 设备（如磁盘、网卡、显卡）。

内核态 (KVM Module) ：负责将 CPU 切换到 客户模式（Guest Mode） ，处理高权限指令。
用户态 (QEMU) ：负责模拟硬件设备，并提供用户操作接口。
管理层 (Libvirt) ：一个标准的 API 库，我们常用的 virsh 命令、 virt-manager 界面都是通过 Libvirt 来调用 QEMU/KVM 的。

核心技术特性

CPU 虚拟化 (Intel VT-x / AMD-V) 。KVM 利用硬件辅助虚拟化技术。它将 CPU 分为四种模式，使得虚拟机（Guest）可以直接在物理 CPU 上执行绝大多数指令，只有在执行敏感指令时才由内核接管，性能损耗极低。
内存管理 (EPT/NPT) 。通过 扩展页表 (EPT) 技术，KVM 实现了物理内存与虚拟机内存的直接映射。
- KSM (Kernel Same-page Merging) 扫描多个 VM 的内存，如果发现相同的内存页（例如多个 VM 都运行 Ubuntu），则将其合并为一页，极大节省物理内存。
存储与网络 (VirtIO) 。传统的模拟设备（如模拟一张经典的百兆网卡）效率极低。KVM 引入了 VirtIO 准虚拟化驱动。VM 意识到自己处于虚拟化环境，通过 “共享内存” 的方式与宿主机通信。实现磁盘 IO 和网络吞吐量几乎接近物理机性能。

KVM 家族工具链

qemu-kvm ：核心包，提供底层仿真。
libvirt-daemon ：守护进程，负责管理 VM 的生命周期。
virsh ：命令行工具（运维最常用）。
virt-install ：用于创建虚拟机的命令行脚本工具。

KVM 安装

环境信息

Ubuntu 22.04.5 LTS 5.15.0-119-generic

最好不要和 Docker、K8s 等虚拟化工具同时安装。可能会因为内核参数（如 net.bridge.bridge-nf-call-iptables ）冲突导致 VM 无法获得 DHCP 地址。

首先需要确认你的物理机 CPU 是否支持虚拟化技术（VT-x 或 AMD-V）

# egrep -c '(vmx|svm)' /proc/cpuinfo
64

如果输出大于 0，说明支持虚拟化

安装 KVM 及相关工具 。参考以下命令安装 Linux 原生的虚拟化栈

sudo apt update
sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virtinst virt-manager
sudo systemctl enable --now libvirtd

KVM 中安装 Talos Linux 系统

Talos Linux OS Github 下载地址，从中下载 Talos Linux AMD64 版本的 RAW 镜像并提取 raw 文件

wget https://github.com/siderolabs/talos/releases/download/v1.14.0-alpha.0/metal-amd64.raw.zst

zstd -d metal-amd64.raw.zst

使用解压后的 metal-amd64.raw 文件创建虚拟机

创建 Talos 虚拟机 。可以使用 virt-install 命令行快速创建多个 VM。创建控制平面 (Control Plane) 虚拟机

cp metal-amd64.raw /var/lib/libvirt/images/talos-control-plane-01.raw

# 建议稍微扩容一下，20G 比较稳妥
qemu-img resize /var/lib/libvirt/images/talos-control-plane-01.raw 20G

# 导入并运行虚拟机
virt-install \
  --name talos-control-plane-01 \
  --ram 4096 \
  --vcpus 4 \
  --disk path=/var/lib/libvirt/images/talos-control-plane-01.raw,bus=virtio \
  --os-variant ubuntu22.04 \
  --network network=default,model=virtio \
  --graphics none \
  --import \
  --boot hd \
  --console pty,target_type=serial

--name talos-control-plane-01 ：虚拟机唯一名称为 talos-control-plane-01
--ram 4096 ：内存大小为 4096MB
--vcpus 4 ：虚拟 CPU 数量为 4 个
--disk path=/var/lib/libvirt/images/talos-control-plane-01.qcow2,size=20 ： path 虚拟磁盘文件存放路径, size 虚拟磁盘文件大小为 20GB
--os-variant ubuntu22.04 ： --os-variant 用于指定操作系统类型，这里指定为 Ubuntu 22.04。虽然安装的是 Talos，但指定 ubuntu22.04 会让 KVM 自动应用适合该内核版本的硬件加速参数（如 VirtIO 队列优化）
--network network=default,model=virtio ：将 VM 挂载到宿主机的 default 网桥上。这是 Libvirt 默认网桥，是 KVM 安装后自动生成的 NAT 网桥。虚拟机可以访问外网，宿主机可以访问虚拟机，但外部机房的其他服务器无法直接访问该虚拟机。
--graphics none ：不显示图形界面，禁用图形输出
--console pty,target_type=serial ：串口控制台，将虚拟机的控制台重定向到当前的 shell 终端。运行命令后，你可以直接在当前的终端窗口看到 Talos 的启动日志。
--cdrom /opt/Talos/metal-amd64.iso ：安装镜像，Talos 首次启动需要通过 ISO 引导来进入安装模式。
--boot hd ：设置启动优先级。先尝试从硬盘 (hd) 启动，如果硬盘没系统（如首次启动），则从光盘 (cdrom) 启动。

执行 VM 安装命令后，你的终端会变为 VM 的输出界面。你会看到 Talos 启动并显示以下信息：

Starting install...
Allocating 'talos-control-plane-01.qcow2'                                                                                                            | 3.1 MB  00:00:00 ... 
Creating domain...                                                                                                                                   |    0 B  00:00:00     
Running text console command: virsh --connect qemu:///system console talos-control-plane-01
Connected to domain 'talos-control-plane-01'
Escape character is ^] (Ctrl + ])

到这一步说明虚拟机已经成功创建并运行了。由于你看到了 Escape character is ^] (Ctrl + ]) 且屏幕停止滚动，这意味着你已经成功进入了虚拟机的串口终端 (Serial Console)。

Talos 启动非常快，大约 10-20 秒。如果 1 分钟后还没输出，说明内核可能还在尝试初始化硬件。

如果你想回到宿主机命令行，执行后续的 talosctl 命令，你需要先 Ctrl + ] (先按住 Ctrl 不放，再按右中括号)退出虚拟机的串口终端。

如果 VM 安装异常，可以查询 libvirtd 服务日志

# journalctl -u libvirtd -n 50 --no-pager
May 07 15:13:11 vp-jmpsvr systemd[1]: Starting Virtualization daemon...
May 07 15:13:11 vp-jmpsvr systemd[1]: Started Virtualization daemon.
May 07 15:13:12 vp-jmpsvr dnsmasq[417014]: started, version 2.90 cachesize 150
May 07 15:13:12 vp-jmpsvr dnsmasq[417014]: compile time options: IPv6 GNU-getopt DBus no-UBus i18n IDN2 DHCP DHCPv6 no-Lua TFTP conntrack ipset no-nftset auth cryptohash DNSSEC loop-detect inotify dumpfile
May 07 15:13:12 vp-jmpsvr dnsmasq-dhcp[417014]: DHCP, IP range 192.168.122.2 -- 192.168.122.254, lease time 1h
May 07 15:13:12 vp-jmpsvr dnsmasq-dhcp[417014]: DHCP, sockets bound exclusively to interface virbr0
May 07 15:13:12 vp-jmpsvr dnsmasq[417014]: reading /etc/resolv.conf
May 07 15:13:12 vp-jmpsvr dnsmasq[417014]: using nameserver 8.8.8.8#53
May 07 15:13:12 vp-jmpsvr dnsmasq[417014]: using nameserver 114.114.114.114#53
May 07 15:13:12 vp-jmpsvr dnsmasq[417014]: read /etc/hosts - 3 names
May 07 15:13:12 vp-jmpsvr dnsmasq[417014]: read /var/lib/libvirt/dnsmasq/default.addnhosts - 0 names
May 07 15:13:12 vp-jmpsvr dnsmasq-dhcp[417014]: read /var/lib/libvirt/dnsmasq/default.hostsfile
May 07 17:20:03 vp-jmpsvr libvirtd[416897]: libvirt version: 8.0.0, package: 1ubuntu7.16 (Hector Cao <hector.cao@canonical.com> Wed, 04 Feb 2026 11:49:12 +0100)
May 07 17:20:03 vp-jmpsvr libvirtd[416897]: hostname: vp-jmpsvr
May 07 17:20:03 vp-jmpsvr libvirtd[416897]: Unable to read from monitor: Connection reset by peer
May 07 17:20:03 vp-jmpsvr libvirtd[416897]: internal error: qemu unexpectedly closed the monitor: 2026-05-07T09:20:03.828580Z qemu-system-x86_64: -append only allowed with -kernel option
May 07 17:20:03 vp-jmpsvr libvirtd[416897]: internal error: process exited while connecting to monitor: 2026-05-07T09:20:03.828580Z qemu-system-x86_64: -append only allowed with -kernel option

virsh 命令行工具

虚拟机管理命令

列出所有虚拟机

# virsh list --all
 Id   Name                     State
----------------------------------------
 1    talos-control-plane-01   running

查看虚拟机分配的 IP 地址

virsh net-dhcp-leases default

彻底删除虚拟机

virsh destroy talos-control-plane-01
virsh undefine talos-control-plane-01

连接虚拟机串口终端

# virsh console 1
Connected to domain 'talos-control-plane-01'
Escape character is ^] (Ctrl + ])

Network 管理

查看所有网络

# virsh net-list
 Name      State    Autostart   Persistent
--------------------------------------------
 default   active   yes         yes

查看虚拟机分配的 IP 地址

virsh net-dhcp-leases default

Terraform 使用说明

发表于 2026-05-07 上层目录 Linux

理解 Terraform 的核心工作模型，Terraform 的三大核心要素

要素	说明	文件/位置
配置（Configuration）	你编写的期望状态描述	`*.tf` 文件
状态（State）	Terraform 记录的当前实际管理的资源	`terraform.tfstate`
真实基础设施（Real Infrastructure）	云上实际运行的资源	AWS/GCP/Azure 等

Terraform 的核心使命就是： 让三者保持一致 。所有命令本质上都是围绕这三者的同步而设计的。

Terraform 的标准工作流（Standard Workflow）

┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  编写配置   │───▶│   init     │───▶│   plan     │───▶│   apply    │
│  (.tf文件)  │    │  初始化     │    │  预演变更   │    │  执行变更   │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
                                                                │
                                                                ▼
                                                        ┌─────────────┐
                                                        │  destroy   │
                                                        │  销毁资源   │
                                                        └─────────────┘

Terraform 命令分类总览

类别	命令	使用频率
核心生命周期	`init` 、 `plan` 、 `apply` 、 `destroy`	⭐⭐⭐⭐⭐
代码质量	`fmt` 、 `validate`	⭐⭐⭐⭐⭐
状态管理	`state list` / `show` / `mv` / `rm` / `pull/push` 、 `refresh`	⭐⭐⭐⭐
资源导入与迁移	`import` 、 `taint` 、 `untaint` 、 `replace`	⭐⭐⭐
输出与调试	`output` 、 `show` 、 `console` 、 `graph`	⭐⭐⭐
工作区与模块	`workspace` 、 `get` 、 `providers`	⭐⭐⭐

Terraform 安装

Amazon Linux 2023 安装 Terraform

sudo dnf install -y yum-utils

sudo yum-config-manager --add-repo https://rpm.releases.hashicorp.com/AmazonLinux/hashicorp.repo

sudo dnf install -y terraform

安装完成后， terraform 命令即可使用。

$ terraform version
Terraform v1.15.2
on linux_amd64

Terraform 配置 AWS EKS 集群

在 Terraform 节点服务器上安装 AWS CLI 并配置 AWS 凭证。

$ aws sts get-caller-identity
{
    "UserId": "AIDA2H52UFCAOSDMJBUX6",
    "Account": "<AWS_ACCOUNT_ID>",
    "Arn": "arn:aws:iam::<AWS_ACCOUNT_ID>:user/ops"
}

AWS EKS 集群 Terraform 项目结构

$ tree 
.
├── main.tf         # Terraform 主入口，调用其他模块
├── variables.tf    # 定义变量，用于在 Terraform 中使用动态值
├── providers.tf    # 定义 AWS 提供商
├── versions.tf     # 定义 AWS 提供商的版本
├── vpc.tf          # 定义 VPC 模块，用于创建 AWS VPC
├── eks.tf          # 定义 EKS 模块，用于创建 AWS EKS 集群
├── aws-alb.tf      # 定义 ALB 模块，用于创建 AWS ALB
├── efs.tf          # 定义 EFS 模块，用于创建 AWS EFS 文件系统
└── outputs.tf      # 定义输出，用于在 Terraform 中使用资源 ID

定义变量

在 variables.tf 文件中定义变量，用于在 Terraform 中使用动态值。

模块（module）的名称必须是一个固定的字符串（静态标识符），绝对不能包含变量插值 ${...} 。

variables.tf


variable "aws_region" {
  default = "ap-east-1"
}

variable "eks_cluster_name" {
  default = "eks-6992-hk-uat"
}

variable "eks_cluster_version" {
  default = "1.35"
}

定义 AWS 提供商

在 providers.tf 文件中定义 AWS 提供商，指定 AWS 区域。

providers.tf

provider "aws" {
  region = var.aws_region
}

provider "helm" {
  kubernetes {
    host                   = module.eks-6992-hk-uat.cluster_endpoint
    cluster_ca_certificate = base64decode(module.eks-6992-hk-uat.cluster_certificate_authority_data)

    # 确保 exec 块语法正确
    exec {
      api_version = "client.authentication.k8s.io/v1beta1"
      args        = ["eks", "get-token", "--cluster-name", module.eks-6992-hk-uat.cluster_name]
      command     = "aws"
    }
  }
}

provider "kubernetes" {
  host = module.eks-6992-hk-uat.cluster_endpoint

  cluster_ca_certificate = base64decode(
    module.eks-6992-hk-uat.cluster_certificate_authority_data
  )

  exec {
    api_version = "client.authentication.k8s.io/v1beta1"

    command = "aws"

    args = [
      "eks",
      "get-token",
      "--cluster-name",
      module.eks-6992-hk-uat.cluster_name
    ]
  }
}

锁定版本

在 versions.tf 文件中定义 AWS 提供商的版本。

versions.tf


terraform {
  required_version = ">= 1.15"          # 锁定 Terraform 版本

  required_providers {             # 锁定 AWS 提供商版本
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.50"
    }
    helm = {
      source  = "hashicorp/helm"
      version = "~> 2.15"
    }
    kubernetes = {
      source  = "hashicorp/kubernetes"
      version = "~> 2.29"
    }
  }
}

定义 VPC 模块

在 vpc.tf 文件中定义 VPC 模块，用于创建 AWS VPC。

vpc.tf

module "eks-6992-hk-uat-vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.8.1"

  name = "${var.eks_cluster_name}-vpc"     # VPC 名称

  cidr = "10.0.0.0/16"

  azs = [                                  # 跨三个可用区以实现高可用
    "${var.aws_region}a",
    "${var.aws_region}b",
    "${var.aws_region}c"
  ]

  private_subnets = [                      # Private Subnets，节点实例和工作节点实例位于 Private Subnets 中的可用区
    "10.0.1.0/24",
    "10.0.2.0/24",
    "10.0.3.0/24"
  ]

  public_subnets = [                      # Public Subnets, ALB/NAT Gateway 必须位于 Public Subnets 中的可用区
    "10.0.101.0/24",
    "10.0.102.0/24",
    "10.0.103.0/24"
  ]

  enable_nat_gateway = true                # 启用 NAT Gateway, 用于节点实例和工作节点实例访问互联网

  single_nat_gateway = true                # 启用单 NAT Gateway, 用于节点实例和工作节点实例访问互联网， NAT Gateway 数量为 1，省钱模式

  enable_dns_hostnames = true              # 启用 DNS 主机名，用于节点实例和工作节点实例的 DNS 解析
  enable_dns_support = true                # 启用 DNS 支持，用于节点实例和工作节点实例的 DNS 解析
  
  # 关键：EKS 自动发现子网所需的标签。为了让 EKS 自动识别哪些子网用于存放负载均衡器，哪些用于存放 Pod，你需要确保子网拥有正确的标签（只有共有子网可忽略此配置）
  public_subnet_tags = {
    "kubernetes.io/role/elb" = 1
  }
  private_subnet_tags = {
    "kubernetes.io/role/internal-elb" = 1
  }    
}

定义 EKS 模块

在 eks.tf 文件中定义 EKS 模块，用于创建 AWS EKS 集群。

以下配置为 EKS Auto Mode 配置，建议使用。EKS Auto Mode 是 AWS 提供的 “完全代管” 体验，它将 Karpenter、EBS 驱动、CNI 等全部内置并由 AWS 直接管理。
EKS Auto Mode 无法直接通过 API 从 “普通模式” 无缝切换到 “Auto Mode”，需要在创建集群指定 “Auto Mode”。所以，建议在创建集群时指定 “Auto Mode”，而不是在后续通过 API 切换。

eks.tf

module "eks-6992-hk-uat" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.28"

  cluster_name    = var.eks_cluster_name           # EKS 集群名称
  cluster_version = var.eks_cluster_version        # 指定 K8s 版本

  vpc_id     = module.eks-6992-hk-uat-vpc.vpc_id                     # VPC ID，用于创建 EKS 集群的 VPC ID
  subnet_ids = module.eks-6992-hk-uat-vpc.private_subnets            # Private Subnets，节点实例和工作节点实例位于 Private Subnets 中的可用区   

  
  cluster_endpoint_public_access = true                # 启用集群端点访问（API Server），用于外部访问 EKS 集群

  # 托管节点组配置（Managed Node Groups）。使用 AWS Auto Scaling Group (ASG)，需要在集群中安装 Cluster Autoscaler 来自动调整节点实例数量。当发现 Pod 因为资源不足无法调度时，它会去修改 AWS ASG 的 desired_size 来增加节点实例数量。
  # 建议 切换到 EKS Auto Mode (2024年底发布的新模式)，EKS Auto Mode 是 AWS 提供的“完全代管”体验。它将 Karpenter、EBS 驱动、CNI 等全部内置并由 AWS 直接管理。
    #   eks_managed_node_groups = {
    #     default = {
    #       instance_types = ["t3.large"]
    #       min_size     = 1
    #       max_size     = 5
    #       desired_size = 2
    #       disk_size = 100                              # 节点实例和工作节点实例的 EBS 卷大小，单位为 GiB
    #     }
    #   }
  # 关键：开启 EKS Auto Mode 配置
  cluster_compute_config = {
    enabled    = true
    node_pools = ["general-purpose", "system"] 
  }

  
  # 必须：Auto Mode 下不需要手动引导插件
  bootstrap_self_managed_addons = false

  # 自动模式下，建议让模块处理节点所需的 IAM Role 权限
  # Auto Mode 节点需要能够与 EKS 控制面通信的权限  
  enable_cluster_creator_admin_permissions = true        # 启用集群创建者管理员权限，用于集群创建者对 EKS 集群进行管理

  # 关闭 CloudWatch 日志输出以节省成本
  cluster_enabled_log_types = []
}

定义 AWS ALB Controller 模块

在 aws-alb.tf 文件中定义 AWS ALB Controller 模块，用于创建 AWS ALB Controller。

aws-alb.tf

module "alb_controller_irsa_role" {
  source  = "terraform-aws-modules/iam/aws//modules/iam-role-for-service-accounts-eks"
  version = "~> 5.39"

  role_name = "${var.eks_cluster_name}-alb-controller"

  attach_load_balancer_controller_policy = true

  oidc_providers = {
    main = {
      provider_arn = module.eks-6992-hk-uat.oidc_provider_arn

      namespace_service_accounts = [
        "kube-system:aws-load-balancer-controller"
      ]
    }
  }
}

# 2. 使用 Helm 部署控制器

resource "helm_release" "aws_load_balancer_controller" {
  name       = "aws-load-balancer-controller"
  repository = "https://aws.github.io/eks-charts"
  chart      = "aws-load-balancer-controller"
  namespace  = "kube-system"
  version    = "1.14.0" # 建议检查最新版本

  set {
    name  = "clusterName"
    value = module.eks-6992-hk-uat.cluster_name
  }
  # --- 新增以下两项以解决 VPC ID 获取失败的问题 ---
  set {
    name  = "vpcId"
    value = module.eks-6992-hk-uat-vpc.vpc_id
  }

  set {
    name  = "region"
    value = var.aws_region
  }
  # ----------------------------------------------

  set {
    name  = "serviceAccount.create"
    value = "true"
  }

  set {
    name  = "serviceAccount.name"
    value = "aws-load-balancer-controller"
  }

  set {
    name  = "serviceAccount.annotations.eks\\.amazonaws\\.com/role-arn"
    value = module.alb_controller_irsa_role.iam_role_arn
  }
}

定义 EFS 模块

在 efs.tf 文件中定义 EFS 模块，用于创建 AWS EFS 文件系统。

efs.tf

resource "aws_efs_file_system" "eks_efs" {
  creation_token = "${var.eks_cluster_name}-efs"

  performance_mode = "generalPurpose"
  throughput_mode  = "bursting"

  encrypted = true

  tags = {
    Name = "${var.eks_cluster_name}-efs"
  }
}

# EFS 必须在每个 Private Subnet 创建 Mount Target。
resource "aws_efs_mount_target" "private" {
  count = length(module.eks-6992-hk-uat-vpc.private_subnets)

  file_system_id  = aws_efs_file_system.eks_efs.id
  subnet_id       = module.eks-6992-hk-uat-vpc.private_subnets[count.index]

  security_groups = [
    aws_security_group.efs.id
  ]
}

# EFS 安全组
resource "aws_security_group" "efs" {
  name_prefix = "${var.eks_cluster_name}-efs-sg"

  vpc_id = module.eks-6992-hk-uat-vpc.vpc_id

  ingress {
    from_port   = 2049
    to_port     = 2049
    protocol    = "tcp"

    cidr_blocks = ["10.0.0.0/16"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"

    cidr_blocks = ["0.0.0.0/0"]
  }
}

# 创建 IAM Role（IRSA）
module "efs_csi_irsa_role" {
  source  = "terraform-aws-modules/iam/aws//modules/iam-role-for-service-accounts-eks"
  version = "~> 5.39"

  role_name = "${var.eks_cluster_name}-efs-csi"

  attach_efs_csi_policy = true

  oidc_providers = {
    main = {
      provider_arn = module.eks-6992-hk-uat.oidc_provider_arn

      namespace_service_accounts = [
        "kube-system:efs-csi-controller-sa"
      ]
    }
  }
}

resource "helm_release" "aws_efs_csi_driver" {
  name       = "aws-efs-csi-driver"

  repository = "https://kubernetes-sigs.github.io/aws-efs-csi-driver/"
  chart      = "aws-efs-csi-driver"

  namespace  = "kube-system"


  set {
    name  = "controller.serviceAccount.create"
    value = "true"
  }

  set {
    name  = "controller.serviceAccount.name"
    value = "efs-csi-controller-sa"
  }

  set {
    name  = "controller.serviceAccount.annotations.eks\\.amazonaws\\.com/role-arn"

    value = module.efs_csi_irsa_role.iam_role_arn
  }
}

# 创建 StorageClass
resource "kubernetes_storage_class" "efs" {
  metadata {
    name = "efs-sc"
  }

  storage_provisioner = "efs.csi.aws.com"

  parameters = {
    provisioningMode = "efs-ap"

    fileSystemId = aws_efs_file_system.eks_efs.id

    directoryPerms = "700"

    gidRangeStart = "1000"
    gidRangeEnd   = "2000"

    basePath = "/dynamic_provisioning"
  }

  reclaim_policy      = "Retain"

  volume_binding_mode = "Immediate"
}

初始化并应用 Terraform 项目

执行以下命令初始化 Terraform 项目

$ terraform init
Initializing modules...
Downloading registry.terraform.io/terraform-aws-modules/vpc/aws 5.8.1 for eks-6992-hk-uat-vpc...
- eks-6992-hk-uat-vpc in .terraform/modules/eks-6992-hk-uat-vpc
...
Initializing the backend...


Terraform has created a lock file .terraform.lock.hcl to record the provider
selections it made above. Include this file in your version control repository
so that Terraform can guarantee to make the same selections by default when
you run "terraform init" in the future.

Terraform has been successfully initialized!

使用命令 terraform plan 查看 Terraform 计划，可以检查是否有报错，并确认是否符合预期。

$ terraform plan
╷
│ Error: Reference to undeclared module
│ 
│   on eks.tf line 8, in module "eks-6992-hk-uat":
│    8:   vpc_id     = module.vpc.vpc_id                     # VPC ID，用于创建 EKS 集群的 VPC ID
│ 
│ No module call named "vpc" is declared in the root module.
╵
╷
│ Error: Reference to undeclared module
│ 
│   on eks.tf line 9, in module "eks-6992-hk-uat":
│    9:   subnet_ids = module.vpc.private_subnets            # Private Subnets，节点实例和工作节点实例位于 Private Subnets 中的可用区   
│ 
│ No module call named "vpc" is declared in the root module.
╵

阅读全文 »

kubernetes 安装配置

发表于 2022-09-12 更新于 2026-05-07 上层目录 Kubernetes

Kubernetes 官网文档

环境信息

Centos 7 5.4.212-1
Docker 20.10.18
containerd.io-1.6.8
kubectl-1.24.7
kubeadm-1.24.7
kubelet-1.24.7

kubernetes 环境安装前配置

升级内核版本

Centos 7 默认的内核版本 3.10 在运行 kubernetes 时存在不稳定性，建议升级内核版本到新版本

Centos 7 默认的内核版本 3.10 使用的 cgroup 版本为 v1，Kubernetes 的部分功能必须使用 cgroup v2 来进行增强的资源管理和隔离 ^[13]

使用以下命令检查系统使用的 cgroup 版本

stat -fc %T /sys/fs/cgroup/

如果输出是 cgroup2fs ， 表示使用 cgroup v2

如果输出是 tmpfs ， 表示使用 cgroup v1

User Namespaces 功能需要 Linux 6.3 以上版本， tmpfs 才能支持 idmap 挂载。并且其他功能（如 ServiceAccount 的挂载）也需要此功能的支持 ^[14]

Kubernetes v1.32 需要 Linux Kernel >= 4.19, 建议 5.8+ 以更好的支持 cgroups v2

Rocky Linux 8 或者 Centos 8 默认使用 cgroup v1 ，需要升级到 cgroup v2 ，执行命令 grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=1" 后重启即可升级到 cgroup v2 。使用以下命令检查：

# stat -fc %T /sys/fs/cgroup/
cgroup2fs

若 CRI 使用 Containerd，需要配置启用 CRI 以及配置其使用 cgroup v2 版本。

关闭 SELinux

kubernetes 目前未实现对 SELinux 的支持，因此必须要关闭 SELinux

sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=disabled/' /etc/selinux/config

集群中所有计算机之间具有完全的网络连接

配置集群所有节点的防火墙，确保所有集群节点之间具有完全的网络连接。

放通节点之间的通信
确保防火墙允许 FORWARD 链的流量

*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4:368]

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT

# kubernetes nodes
-A INPUT -m comment --comment "kubernetes nodes" -s 172.31.5.58 -j ACCEPT
-A INPUT -m comment --comment "kubernetes nodes" -s 172.31.5.68 -j ACCEPT
-A INPUT -m comment --comment "kubernetes nodes" -s 172.31.0.230 -j ACCEPT

-A INPUT -p tcp -m multiport --dports 80,443 -j ACCEPT -m comment --comment "k8s ingress http,https"


...

-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT

阅读全文 »

Pixie 安装配置

发表于 2026-05-07 上层目录 Kubernetes

Pixie 是一款专为 Kubernetes 设计的 开源全栈可观测性工具 。它最大的特色是利用 eBPF（extended Berkeley Packet Filter）技术，在不修改业务代码、不重启 Pod、不注入 Sidecar 的情况下，自动采集集群内的所有监控数据。Pixie 被称为 K8s 的分布式调试器

Pixie 的核心优势

无侵入性 (Auto-telemetry) ：部署后，自动获取 HTTP/gRPC 请求、SQL 查询、系统调用和火焰图。
边缘计算架构 ：数据存储在集群节点的内存中，查询时才进行分布式计算。这意味着：
极速：查询结果近乎实时。
省钱：不会有海量日志传输到云端产生的高额带宽和存储费。
动态可编程 ：使用 PxL（基于 Python 的查询语言）编写脚本，可以像写脚本一样实时分析系统性能。

Pixie 核心组件

Vizier ：运行在 K8s 集群中的控制器，负责管理各个节点的边缘收集器。
PEM (Pixie Edge Module) ：以 DaemonSet 形式运行在每个节点，利用 eBPF 采集数据并存储在本地内存。
Cloud Add-on ：提供用户界面 (UI) 和 API 访问。

快速安装
Pixie 的安装非常简单，通常通过 CLI 完成。

确保 Linux 内核版本在 4.16+（推荐 5.10+，2026 年的主流系统如 Ubuntu 22.04+、AlmaLinux 9 等都完美支持）。如果在过旧的内核上强行运行 eBPF 程序，极少数情况下可能导致内核态的不稳定。

下载 Pixie CLI
bash -c "$(curl -fsSL https://withpixie.ai/install.sh)"
脚本会从 Pixie 的官方 GitHub Release 页面或 CDN 下载最新版本的 px 命令行工具，并将其安装到 /usr/local/bin 目录。
px 是你后续与 Kubernetes 集群交互的唯一入口，所有的部署（deploy）、查询（collect）和脚本运行都通过它完成。 。
它会检查你本地的 ~/.kube/config 文件，确保你当前有权限连接到一个 Kubernetes 集群。
当你执行完这个脚本后，Pixie 还没有安装到你的 Kubernetes 集群里。它只是在你的跳板机或开发机上装好了 “遥控器”。要真正让 Pixie 开始监控集群，你通常需要继续执行 px deploy 命令。
部署到 K8s 集群。这将自动安装 Vizier 和 PEM 到集群中
px deploy
这个命令会将 Vizier 和 PEM 部署到你的 Kubernetes 集群中。

gitlab 安装配置及 git 命令使用

发表于 2020-01-20 更新于 2026-05-07 上层目录 Linux ，常用服务

安装

安装步骤

安装完成之后使用 gitlab-ctl reconfigure 启动服务

访问页面，默认使用 root 登录

每次重新更改配置，都需要使用 reconfigure 重新启动

使用 Docker Compose 部署

参考配置如下：

docker-compose.yml

services:
  web:
    image: 'gitlab/gitlab-ce:latest'
    restart: always
    hostname: 'gitlab.example.com:8090'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        # 这里的域名/IP 决定了 Git 克隆地址
        external_url 'http://gitlab.example.com:8090' 
        nginx['listen_port'] = 8090
        puma['port'] = 8001
        gitlab_rails['gitlab_shell_ssh_port'] = 22222
        prometheus_monitoring['enable'] = false
        # --- 内存优化配置开始 ---
        # 1. 限制 Puma Worker 数量。每个 Worker 至少占 1GB+ 内存。核心数+1 是默认值，私有环境建议设为 2，最少设为 2。
        puma['worker_processes'] = 2
        # 2. 限制单 Worker 内存占用，超过则自动重启。
        puma['per_worker_max_memory_mb'] = 1024

        # 3. 减少后台任务并发数。
        sidekiq['concurrency'] = 10
        # 4. 彻底关闭不必要的内置监控组件以节省内存（如果你已经有外置 Prometheus）。
        alertmanager['enable'] = false
        node_exporter['enable'] = false
        redis_exporter['enable'] = false
        postgres_exporter['enable'] = false
        gitlab_exporter['enable'] = false
        # --- 内存优化配置结束 ---
    ports:
      - '8090:8090'
      - '443:443'
      - '22222:22'
    volumes:    
      - './config:/etc/gitlab'       # 需要创建持久化目录 ./config、./logs、./data
      - './logs:/var/log/gitlab'
      - './data:/var/opt/gitlab'
    shm_size: '256m'
    # --- 增加 Docker 容器级别的硬限制 ---
    deploy:
      resources:
        limits:
          memory: 8G   # 强制限制容器总内存为 8GB

阅读全文 »

Kasm Workspaces

发表于 2026-04-10 更新于 2026-05-04 上层目录 Tools

Kasm Workspaces 是在浏览器里运行完整应用/桌面/浏览器的云工作空间平台

你会看到：

浏览器里再打开一个 Chrome / Linux 桌面
像用本地电脑一样操作
所有计算都在服务器

Kasm 的核心能力

浏览器里跑浏览器（最常用 Chrome / Chromium / Firefox）、OS 桌面（Ubuntu / XFCE、Kali Linux 等）、应用（GUI 软件、Terminal 等） 。
多用户（账号）登录且完全隔离（每个用户一个容器）
支持自动销毁
WebRTC 显示协议提供低延迟画面流

Docker Compose 部署步骤

docker-compose.yaml

services:
  kasm:
    image: lscr.io/linuxserver/kasm:latest
    container_name: kasm
    privileged: true
    environment:
      - KASM_PORT=443
    volumes:
      - ./data:/opt
      - ./profiles:/profiles
    ports:
      - 3000:3000
      - 443:443
    restart: unless-stopped

启动后，首先使用 https://<IP>:3000 进行初始化，初始化时需要设置管理员账号密码信息。初始化成功后，通过 https://<IP>:443 连接 Workspaces。

Kasm 强依赖 Docker，目前还无法在 Kubernetes 环境中部署。

在初始化页面（Install Wizard https://<IP>:3000 ）中，确保 Kasm 的所有组件都处于 healthy 状态，表示 Kasm 已能正常提供服务

常用配置

在 Workspaces 中使用中文输入法

默认大多数的 Workspace 容器启动时都是没有中文输入的。如果要提供中文输入，可以使用系统提供的 IME Input Mode 。它可以将本地电脑的输入映射到 Kasm Workspaces 中。只需在对应的 Workspace 中开启 IME 配置即可。

使用管理员登录 Kasm。定位到 Workspaces ，编辑对应的 Workspace（如 Kali Linux），找到 Docker Run Configuration Override (JSON)

填入以下内容(如果有其他内容，插入以下内容)，开启 IME
{
"environment": {
"KASM_IME": "1"
}
}
销毁之前的 Workspace Session，运行新的 Workspace Session，打开左侧的配置菜单，找到 Advanced Settings ，将 IME Input Mode 配置为 On

即可在 Workspace 中使用中文

用户数据持久化方案

在 Kasm 中，实现 Workspace 用户数据（如 Chrome 书签、桌面配置、文档等）持久化的标准方案是使用 Persistent Profiles（持久化配置层） 。

核心原理

Kasm 会将容器内的用户目录（通常是 /home/kasm ）映射到宿主机的特定路径（即 docker-compose.yaml 中定义的 /profiles 目录）。当用户结束会话时，Kasm 会将该目录打包；下次启动时，再自动解压回容器。

开启 Persistent Profiles

确认宿主机存储路径，在 docker-compose.yaml 中，已经配置了持久化卷 /opt/kasm-workspaces/profiles:/profiles ，这表示所有持久化数据将保存在宿主机的 /opt/kasm-workspaces/profiles 目录下。
在 Kasm 管理后台开启功能（Web UI 操作）
1. 登录管理后台 ：使用 admin@kasm.local （管理员账户）登录。
2. 导航到 Settings -> Storage Providers ，点击 Add Storage Provider 添加存储，本示例使用本地存储（Local）
  - Name : local-storage
  - Provider Type : 保持为 Custom 。
  - Default Target : /profiles
  - Volume Configuration (JSON) :
    {
    "driver": "local",
    "driver_opts": {
    "o": "bind",
    "type": "none",
    "device": "/profiles"
    }
    }
  - Mount Configuration (JSON) : 保持默认或确保它是空的 JSON 对象
点击左侧菜单 Workspaces -> Workspaces 。找到 Chrome 或 Ubuntu ，点击 Edit 。
导航到 Storage Mapping 页面， Add Storage Mapping ，选择之前创建的 local-storage 并添加
在 Details 页面中，下翻页面找到 Persistent Profile Path ，在其中填入 /profiles/{user_id} ，启用 Enforce Workspace Persistent Profile

Kasm 会自动将 {user_id} 替换为登录用户的 ID（例如 admin ）。这样即便有多个用户，他们的数据也会分开放，互不干扰。
删除并开启新的 Session，如 Chrome 浏览器，在其中保存书签，删除 Session，重新启动 Session，看看之前保存的书签是否存在。或者检查宿主机的目录 /opt/kasm-workspaces/profiles/ 中是否有文件存在。配置了 Persistent Profile 后，在 Kasm Workspaces 中启动 Session 也会显示已经启用了 Persistent Profile

用户自定义配置

用户登录 Kasm 后，可以导航到 Profiles 进行自定义配置：

对个人信息进行修改
配置登录后默认打开 Workspace（Auto Launch Session）
Kasm UI Language
Kasm Session Timezone
配置 Two Factor

Kubernetes 上部署 MinIO

发表于 2026-05-02 上层目录 Tools

以下示例在 1 Mster + 2 Worker 的 Kubernetes 集群上快速部署使用 MinIO 存储

values.yaml

mode: distributed

replicas: 4
drivesPerNode: 1

rootUser: admin
rootPassword: gLsSbu7dv4zXSjYUeQrVOFq6

persistence:
  enabled: true
  size: 200Gi
  storageClass: ""   # 用默认的 StorageClass，要确保已存在

resources:
  requests:
    memory: 512Mi
    cpu: 500m

# 🔥 关键：强制分散调度
affinity:
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchLabels:
              app: minio
          topologyKey: kubernetes.io/hostname

# 🔥 防止驱逐
tolerations: []

# 🔥 确保分布
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels:
        app: minio

# 👇 新增 ingress（API + Console 分开）
ingress:
  enabled: true
  ingressClassName: nginx
  hosts:
    - minio-api.example.click

新增以下 Ingress 配置用于提供 Console 访问

console-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minio-console
  namespace: minio
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "0"
spec:
  ingressClassName: nginx
  rules:
  - host: minio.example.click
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: minio-console
            port:
              number: 9001

执行以下命令部署 MinIO

helm upgrade minio minio/minio   -n minio   -f values.yaml

kubectl apply -f console-ingress.yaml

部署成功后通过 minio.example.click 登录 Console，管理员用户密码为 values.yaml 中配置的账户密码。

nacos 使用 NFS 持久化安装部署

部署 NFS

在 NFS Server 上执行以下命令：

sudo apt update 
sudo apt install nfs-kernel-server -y

创建用于存放 Nacos 数据的目录

sudo mkdir -p /data/nfs/nacos

调整权限，生产环境建议更精细的权限控制

sudo chown nobody:nogroup /data/nfs/nacos 
sudo chmod 777 /data/nfs/nacos

配置 NFS 服务

sudo nano /etc/exports

/data/nfs/nacos  192.168.1.0/24(rw,sync,no_subtree_check,no_root_squash)

启动服务：

sudo exportfs -a 
sudo systemctl restart nfs-kernel-server

在 Kubernetes 中配置 NFS 客户端

为了让 K8S 节点能挂载 NFS，所有 Worker 节点都必须安装客户端工具：

sudo apt install nfs-common -y

部署 NFS 动态存储类 (StorageClass)

手动创建 PV 非常麻烦，在 K8S 中我们通常使用 nfs-subdir-external-provisioner 来实现自动创建 PV。

使用 Helm 快速部署 (推荐)

这是目前最简单、最标准的方式，添加仓库

helm repo add nfs-subdir-external-provisioner https://kubernetes-sigs.github.io/nfs-subdir-external-provisioner/

安装 nfs-provisioner 作为 存储 Provisioner

helm install nfs-provisioner nfs-subdir-external-provisioner/nfs-subdir-external-provisioner \
     --set nfs.server=192.168.1.100 \
     --set nfs.path=/data/nfs/nacos \
     --set storageClass.name=nfs-storage \
     --set storageClass.defaultClass=true

kubectl get sc 验证 StorageClass

Nacos 关联 NFS 存储

现在可以在 Nacos 的部署配置中使用这个 nfs-storage 的 StorageClass 了。参考以下资源清单部署单节点的 Nacos 完整服务，包括 Nginx Ingress 以及鉴权

nacos-single-node.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: nacos
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nacos-pvc
  namespace: nacos
spec:
  accessModes:
    - ReadWriteMany   # ⚠️ NFS 必须用这个
  storageClassName: nfs-storage
  resources:
    requests:
      storage: 5Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nacos
  namespace: nacos
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nacos
  template:
    metadata:
      labels:
        app: nacos
    spec:
      containers:
      - name: nacos
        image: nacos/nacos-server:v2.2.3
        ports:
        - containerPort: 8848
        env:
        - name: MODE
          value: "standalone"
        - name: NACOS_AUTH_ENABLE
          value: "true"            
        - name: NACOS_AUTH_TOKEN
          value: "XDoArVHBA1o8DDsyBchWLGXNfWYibjvEOa7qfroNmZ4="
        - name: NACOS_AUTH_IDENTITY_KEY
          value: "admin"
        - name: NACOS_AUTH_IDENTITY_VALUE
          value: "admin"
        - name: JVM_XMS
          value: "512m"
        - name: JVM_XMX
          value: "512m"
        volumeMounts:
        - name: nacos-storage
          mountPath: /home/nacos/data
        - name: nacos-storage
          mountPath: /home/nacos/logs
      volumes:
      - name: nacos-storage
        persistentVolumeClaim:
          claimName: nacos-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: nacos
  namespace: nacos
spec:
  selector:
    app: nacos
  ports:
  - name: http
    port: 8848
    targetPort: 8848
  type: ClusterIP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nacos
  namespace: nacos
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/whitelist-source-range: "54.251.236.229/24,206.119.115.76/24"
spec:
  ingressClassName: nginx
  rules:
  - host: nacos.example.click
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nacos
            port:
              number: 8848

部署完成后通过 nacos.example.click 登录后台，初始默认密码为 nacos/nacos

nacos 使用 Mysql 持久化安装部署

要使用 Mysql 存储数据，只需修改资源清单为以下内容即可：

apiVersion: v1
kind: Namespace
metadata:
  name: nacos
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nacos-pvc
  namespace: nacos
spec:
  accessModes:
    - ReadWriteMany   # ⚠️ NFS 必须用这个
  storageClassName: nfs-storage
  resources:
    requests:
      storage: 5Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nacos
  namespace: nacos
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nacos
  template:
    metadata:
      labels:
        app: nacos
    spec:
      containers:
      - name: nacos
        image: nacos/nacos-server:v2.2.3
        ports:
        - containerPort: 8848
        env:
        - name: MODE
          value: "standalone"          

        - name: SPRING_DATASOURCE_PLATFORM
          value: "mysql"

        - name: MYSQL_SERVICE_HOST
          value: "<MYSQL_SERVICE_HOST>"
        - name: MYSQL_SERVICE_PORT
          value: "3306"
        - name: MYSQL_SERVICE_DB_NAME
          value: "<MYSQL_SERVICE_DB_NAME>"
        - name: MYSQL_SERVICE_USER
          value: "<MYSQL_SERVICE_USER>"
        - name: MYSQL_SERVICE_PASSWORD
          value: "<MYSQL_SERVICE_PASSWORD>"

        - name: MYSQL_SERVICE_DB_PARAM
          value: "characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true"

        - name: NACOS_AUTH_ENABLE
          value: "true"
        - name: NACOS_AUTH_TOKEN
          value: "XDoArVHBA1o8DDsyBchWLGXNfWYibjvEOa7qfroNmZ4="
        - name: NACOS_AUTH_IDENTITY_KEY
          value: "admin"
        - name: NACOS_AUTH_IDENTITY_VALUE
          value: "admin"
        - name: JVM_XMS
          value: "512m"
        - name: JVM_XMX
          value: "512m"
        
        volumeMounts:
        - name: nacos-storage
          mountPath: /home/nacos/data
        - name: nacos-storage
          mountPath: /home/nacos/logs
      volumes:
      - name: nacos-storage
        persistentVolumeClaim:
          claimName: nacos-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: nacos
  namespace: nacos
spec:
  selector:
    app: nacos
  ports:
  - name: http
    port: 8848
    targetPort: 8848
  - name: rpc
    port: 9848
    targetPort: 9848      
  type: ClusterIP
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: nacos
  namespace: nacos
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    # nginx.ingress.kubernetes.io/whitelist-source-range: "54.251.236.2/24,206.119.115.7/24"
spec:
  ingressClassName: nginx
  rules:
  - host: nacos.example.click
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nacos
            port:
              number: 8848

xray 部署使用

发表于 2026-03-03 更新于 2026-04-30 上层目录 Tools ， VPN

Docker 部署步骤

创建配置文件 config.json

config.json

{
  "log": {
    "loglevel": "debug",    /* 为了观察运行情况或者定位问题，可以开启debug 日志 */
    "access": "/dev/stdout",
    "error": "/dev/stdout"
  },    
  "inbounds": [{
    "port": 443,
    "protocol": "vless",
    "settings": {
      "clients": [
         {
           "id": "c4187394-5865-446d-9d8d-3f6c179416b0(UID 替换为实际值)", 
           "flow": "xtls-rprx-vision"
         }
        ],
      "decryption": "none"
    },
    "streamSettings": {
      "network": "tcp",
      "security": "reality",
      "realitySettings": {
        "show": false,
        "dest": "www.microsoft.com:443",   
        "xver": 0,
        "serverNames": ["www.microsoft.com"],
        "privateKey": "mD0OUR8tFvOypHQre6yGgsZs2w-JecH4zkXB9_TY-k8（私钥）",
        "shortIds": ["a1b2c3d4"]
      }
    }
  }],
  "outbounds": [{"protocol": "freedom"}]
}

"id": "c4187394-5865-446d-9d8d-3f6c179416b0(UID 替换为实际值)" 可以自行生成
"dest": "www.microsoft.com:443" 伪装的网站地址

"privateKey": "mD0OUR8tFvOypHQre6yGgsZs2w-JecH4zkXB9_TY-k8（私钥）" 私钥，公司钥对可以使用如下命令生成

# docker run --rm teddysun/xray xray x25519
PrivateKey: iBKDmvNMfFOAzNPOLRlnJLzoaYbHKs9RFatpW1ELeks
Password: OV_SMIonfy1cEzxnDGZff9x0HeuhuqLyrIj0dLqAaHw
Hash32: 1fEp1041YBnLfSvQYVsRfvGJEA8ZV_LjqFGtQKwaWG0

PrivateKey 对应私钥（ privateKey ）
Password 对应公钥（ Public Key ），要发送给客户端使用

docker-compose.yaml 配置如下：

services:
  xray:
    image: teddysun/xray:latest
    container_name: xray
    restart: always
    network_mode: "host" # 使用 host 模式性能更佳，且直接映射 443 端口
    volumes:
      - ./config/config.json:/etc/xray/config.json
    logging:
      driver: "json-file"
      options:
        max-size: "10m"
        max-file: "3"

正常启动后，在客户端如下配置：

类型： VLESS
地址（Address）： <SERVER IP>
端口（Port）： 443 # 对应配置文件中的 inbounds.port
UUID： <UID> # 对应配置文件中的 inbounds.settings.clients.id
流（Flow）： xtls-rprx-vision # 对应配置文件中的 inbounds.settings.clients.flow
传输协议(Transport protocol(network))： TCP # 对应配置文件中的 inbounds.streamSettings.network
TLS/安全： Reality # 对应配置文件中的 inbounds.streamSettings.security
加密(Encryption): none # 对应配置文件中的 inbounds.settings.decryption
SNI： www.microsoft.com # 对应配置文件中的 inbounds.streamSettings.realitySettings.dest
短 ID（Short ID）： a1b2c3d4 # 对应配置文件中的 inbounds.streamSettings.realitySettings.shortIds
公钥（Public key、密码、Password）： <公钥> # docker run --rm teddysun/xray xray x25519 命令生成的 Password

为了方便客户端导入，可以为配置生成以下链接，其中包含了客户端链接所需的参数：

vless://<UID>@<SERVER IP>:<Port>?encryption=none&flow=xtls-rprx-vision&security=reality&sni=www.microsoft.com&fp=chrome&pbk=<Public Key or Password>&sid=a1b2c3d4#Shanghai_MS_Reality

大多数客户端都支持从粘贴板复制以上内容自动导入配置。

Windows 中使用 v2rayN 连接 xray server

v2rayN 版本： v7.18.0

Windows 下载 v2rayN ，将其解压后，运行程序 v2rayN.exe 即可打开程序。复制配置链接（ vless://<UID>@<SERVER IP>:<Port>?encryption=none&flow=xtls-rprx-vision&security=reality&sni=www.microsoft.com&fp=chrome&pbk=<Public Key or Password>&sid=a1b2c3d4#Shanghai_MS_Reality ），在 v2rayN 主界面点击 Configuration -> Import Share Links from clipboard 即可自动导入配置

默认情况下， v2rayN 会测试到 google.com 的连接来验证服务端是否正常，国内服务器此测试必定失败，因此可以修改此测试目标。参考以下步骤：

导航到 Settings -> v2rayN settings: Speed Ping Test URL ，此处默认值为 google.com ，将其改为国内服务器可以访问的地址如 https://www.baidu.com

要验证 xray server 工作正常，可以在 v2rayN 客户端进行 延迟检测（Test real delay） 。右键要检测的 xray server 选择 Test real delay

如果能够获取到延迟数据，说明 xray 工作正常，如果未获取到延迟数据，可以登陆服务器，通过命令 docker logs 检查服务端日志

Linux TCP 网络重传问题定位步骤

发表于 2026-04-29 上层目录 Linux ，性能分析

Prometnehs 告警规则如下：

- alert: HostTCPRetransmitsHigh
  expr: increase(node_netstat_Tcp_RetransSegs[5m]) > 20000

Prometheus 监控数据显示： retrans=21736/5m

检查系统上的 网络内核协议栈状态 ，使用工具 nstat ，它能显示网络栈的统计信息，还能通过差值计数快速定位当前发生的异常。默认显示自系统启动以来的所有统计项。

# nstat
#kernel
IpInReceives                    741632185          0.0
IpInHdrErrors                   1454               0.0
IpInAddrErrors                  24848              0.0
IpForwDatagrams                 6281793            0.0
IpInUnknownProtos               173793             0.0
IpInDelivers                    585081400          0.0
IpOutRequests                   633335747          0.0
IpOutDiscards                   39                 0.0
IpOutNoRoutes                   6912               0.0
IpReasmTimeout                  104832             0.0
IpReasmReqds                    40046807           0.0
IpReasmOKs                      19711639           0.0
IpReasmFails                    268659             0.0
IpFragOKs                       2920               0.0
IpFragCreates                   5840               0.0
IcmpInMsgs                      28451709           0.0
IcmpInErrors                    50710              0.0
IcmpInCsumErrors                4                  0.0
IcmpInDestUnreachs              116906             0.0
IcmpInTimeExcds                 12355              0.0
IcmpInRedirects                 1137               0.0
IcmpInEchos                     28320718           0.0
IcmpInEchoReps                  47                 0.0
IcmpInTimestamps                542                0.0
IcmpOutMsgs                     34766477           0.0
IcmpOutDestUnreachs             6455420            0.0
IcmpOutTimeExcds                22793              0.0
IcmpOutRedirects                32                 0.0
IcmpOutEchos                    16                 0.0
...

使用 bpftrace 跟踪重传发生的端口统计数据

# bpftrace -e '
tracepoint:tcp:tcp_retransmit_skb
{
    @[args->sport, args->dport] = count();
}'

Attaching 1 probe...


^C

@[10050, 43344]: 4
@[22, 6890]: 5
@[22, 33828]: 5
@[22, 16254]: 5
@[22, 32874]: 5
@[22, 59454]: 6
@[22, 50852]: 6
@[22, 56096]: 7
@[9100, 51150]: 10
@[443, 49917]: 21
@[443, 50447]: 21

使用 bpftrace 实时跟踪指定端口的重传数据

# bpftrace -e '
tracepoint:tcp:tcp_retransmit_skb
/args->sport == 80 || args->sport == 443 || args->sport == 22/
{
    printf("%d -> %d retrans\n", args->sport, args->dport);
}'
Attaching 1 probe...
22 -> 44184 retrans
22 -> 45636 retrans
22 -> 49526 retrans
22 -> 46220 retrans
22 -> 50296 retrans
22 -> 45636 retrans
22 -> 45636 retrans
22 -> 45636 retrans
22 -> 35922 retrans
22 -> 44184 retrans
22 -> 49526 retrans
22 -> 45636 retrans
22 -> 45256 retrans
22 -> 45256 retrans
22 -> 45256 retrans
22 -> 46886 retrans
22 -> 45256 retrans
443 -> 42035 retrans
443 -> 42035 retrans
443 -> 12169 retrans
443 -> 42035 retrans
443 -> 42035 retrans
443 -> 12169 retrans
443 -> 12169 retrans
443 -> 42035 retrans

Linux BPF

发表于 2024-11-18 更新于 2026-04-28 上层目录 Linux ，性能分析

BPF(Berkeley Packet Filter) 是由 Berkeley 学院于 1992 年开发的一款，主要用于提高抓包工具的性能。并于 2014 年被重写进 Linux 内核中，可以用于 内核观测、网络诊断、性能观测、安全、Kubernetes 网络治理等方面 。 ^[1]

BPF 是一种灵活且高效的技术实现，主要由 指令集（Instruction Set） 、 存储对象（Storage Objects maps） 和 帮助函数（Helper Functions） 构成。因为其 虚拟指令集规范（Virtual Instruction Set Specification） ，可以认为 BPF 是一个虚拟机，BPF 运行于 内核模式（Kernel Mode） 。BPF 基于事件（Events）运行： Socket Events 、 Tracepoints 、 USDT Probes 、 kprobes 、 uprobes 、 perf_events .

eBPF 允许 ：

在运行中的内核里插入自己的逻辑

比如：

捕获 TCP 连接
统计进程系统调用
跟踪磁盘 IO
分析网络延迟
拦截数据包

而且：

无需修改内核源码，只在内核事件点插入逻辑，无需重启系统，是 Linux 内核的动态扩展机制

这是 eBPF 最核心的价值。

eBPF 基础原理

eBPF 本质 运行在 Linux 内核中的事件驱动程序 。关键点：

运行在 内核空间（Kernel Space）
事件驱动（Event），不会一直运行，只有在 某个事件（Event）发生时，才会运行

eBPF = Hook + Event + Action

eBPF 的完整执行流程

eBPF 的执行流程分六步

编写 eBPF 程序 。例如把程序挂到 tcp_connect 函数上

SEC("kprobe/tcp_connect")
int trace_tcp() {
    return 0;
}

编译为 BPF Bytecode(eBPF 虚拟机字节码) 。eBPF 运行的不是机器码，而是 BPF 字节码
clang -> BPF bytecode
加载到内核 。用户态程序通过 bpf() 系统调用，把字节码加载进内核。
Verifier 验证程序安全 ，这是 eBPF 最重要的机制，用户把程序加载到内核，是极其危险的，它会检查
- 是否有非法内存访问
- 是否有无限循环
- 是否可能访问非法指针
- 其他危险操作
Attach：把程序挂到事件点 。程序通过 verifier 后，要挂到某个 Hook 点 (Event)，比如
- kprobe:tcp_connect ，每次调用 tcp_connect ，就执行 eBPF 程序
- tracepoint:sys_enter_execve ，每次进程执行时触发
- XDP ，挂到网卡驱动层
本质是： Attach = 指定 “什么时候执行 eBPF” 。这是 eBPF 的事件驱动核心。
事件发生时，程序运行

Map

Map 是内核（Kernel）与用户态（User Space）之间的通信机制 。eBPF 程序运行在内核，但它不能直接：

print 到终端
写文件

所以必须通过 BPF Map 与用户态交换数据。其本质是内核中的 Key-Value 存储。eBPF 程序更新 Map，用户态读取 Map。 Map 是用户态和内核态共享数据桥梁

Hook 点

Hook 点是在内核执行路径中插入的一个触发点或者说在内核某个位置插入 eBPF 程序 。正常内核流程：

事件发生 -> 内核函数执行

加上 eBPF 后:

事件发生 -> Hook 点 -> eBPF 程序执行 -> 原逻辑继续

不同 Hook 点，看到的数据不同，性能不同，用途不同

Hook 在系统调用入口，可以观察哪个进程调用了 open() 、 execve() 等函数，适合 进程行为观测
Hook 在网络包入口，可以观察：收到哪个数据包、包头是什么，适合 网络过滤 / DDoS 防护
Hook 在用户程序函数，可以观察：应用函数调用、函数耗时，适合 应用性能分析

所以： Hook 点 = eBPF 能看到什么、能做什么

eBPF 最重要的五类 Hook 点

kprobe ，挂到内核函数，把 eBPF 程序挂到任意的某个内核函数入口，比如 tcp_connect 。因为挂在函数入口，所以常用于：
- 获取函数参数，比如 tcp_connect(sock, addr) 拿到: socket 信息、目标地址
- 统计调用次数
- 统计执行耗时
kprobe 用于跟踪内核函数行为 。优点是非常灵活，能挂任意内核函数；缺点是依赖内核函数名，不稳定（不同内核版本可能变），内核升级可能导致 kprobe 失效
tracepoint ，挂到内核预定义的稳定事件点。 因为 tracepoint 是 Linux 官方定义接口，相比 kprobe 不会轻易变，跨内核版本更稳定
uprobes ，把 eBPF 程序挂到用户态程序函数，如 Nginx、Mysql 等。主要用于 应用程序性能分析
XDP ，挂到网卡驱动（收包入口）层。XDP 在最早的网络入口处理包，是 Linux 网络性能天花板，Cilium 就是基于 XDP 实现。
TC ，Linux 流量控制（Traffic Control）层。XDP 是网卡驱动层，性能更高。TC 是 Linux 内核网络层，功能更多，更适合复杂网络策略。

bpftrace

bpftrace 是一个基于 BPF 的追踪工具（Trace Tools），提供了高级别的编程能力，同时包含了命令行和脚本使用方式

bpftrace 命令行

bpftrace 命令详细帮助文档请查看 man bpftrace ，下表列出常用选项和参数

选项	说明	示例
`-l [SEARCH]`	列出匹配的事件（Event/Probe），没有 `SEARCH` 表达式则列出所有的 Event。 `SEARCH` 支持通配符
`-e 'program'`	跟踪脚本

筛选指定的事件

# bpftrace -l "tracepoint:*exec*"
tracepoint:libata:ata_exec_command
tracepoint:sched:sched_kthread_work_execute_end
tracepoint:sched:sched_kthread_work_execute_start
tracepoint:sched:sched_process_exec
tracepoint:syscalls:sys_enter_execve
tracepoint:syscalls:sys_enter_execveat
tracepoint:syscalls:sys_enter_kexec_file_load
tracepoint:syscalls:sys_enter_kexec_load
tracepoint:syscalls:sys_exit_execve
tracepoint:syscalls:sys_exit_execveat
tracepoint:syscalls:sys_exit_kexec_file_load
tracepoint:syscalls:sys_exit_kexec_load
tracepoint:workqueue:workqueue_execute_end
tracepoint:workqueue:workqueue_execute_start
tracepoint:writeback:writeback_exec

跟踪新启动的进程

执行以下命令，可以追踪系统中新启动的进程及其参数

# bpftrace -e 'tracepoint:syscalls:sys_enter_execve { join(args->argv); }'
Attaching 1 probe...
/home/oneuser/cwrsync_6.2.4_x64_free/data/ops/rsync2Server.sh
/usr/bin/rsync --progress -a -c -u --timeout=300 -z --password-file /home/oneuser/cwrsync_6.2.4_x64_free/rsync.client.pswd --exclude .idea --exclude rsync2Server.sh /home/oneuser/cwrsync_6.2.4_x64_free/data/ops/ rsync@66.6.9.25::backup
/home/oneuser/cwrsync_6.2.4_x64_free/data/ops/rsync2Server.sh
/usr/bin/rsync --progress -a -c -u --timeout=300 -z --password-file /home/oneuser/cwrsync_6.2.4_x64_free/rsync.client.pswd --exclude .idea --exclude rsync2Server.sh /home/oneuser/cwrsync_6.2.4_x64_free/data/ops/ rsync@66.6.9.25::backup
runc --root /var/run/docker/runtime-runc/moby --log /run/containerd/io.containerd.runtime.v2.task/moby/53daccf2e93fcf83831ce6773a495361afe9bb9694881269d1902f399f5c621c/log.json --log-format json --systemd-cgroup exec --process /tmp/runc-process3178774999 --detach --pid-file /run/containerd/io.containerd.runtime.v2.task/moby/53daccf2e93fcf83831ce6773a495361afe9bb9694881269d1902f399f5c621c/c73d8d4d46ac3995bdc1d7648a3562ddb4715a549a509f6125a7cfc4e88abe50.pid 53daccf2e93fcf83831ce6773a495361afe9bb9694881269d1902f399f5c621c
runc init
/watchtower --health-check
/home/oneuser/cwrsync_6.2.4_x64_free/data/ops/rsync2Server.sh
/usr/bin/rsync --progress -a -c -u --timeout=300 -z --password-file /home/oneuser/cwrsync_6.2.4_x64_free/rsync.client.pswd --exclude .idea --exclude rsync2Server.sh /home/oneuser/cwrsync_6.2.4_x64_free/data/ops/ rsync@66.6.9.25::backup
/usr/lib/x86_64-linux-gnu/dcv/dcvpamhelper --stdout -s dcv
/usr/libexec/sssd/krb5_child --debug-microseconds=0 --debug-timestamps=1 --debug-fd=28 --debug-level=0x0070 --chain-id=7187 --sss-creds-password --canonicalize --realm=OPSDEV666.COM --fast-ccache-gid=0 --fast-ccache-uid=0
/home/oneuser/cwrsync_6.2.4_x64_free/data/ops/rsync2Server.sh
/usr/bin/rsync --progress -a -c -u --timeout=300 -z --password-file /home/oneuser/cwrsync_6.2.4_x64_free/rsync.client.pswd --exclude .idea --exclude rsync2Server.sh /home/oneuser/cwrsync_6.2.4_x64_free/data/ops/ rsync@66.6.9.25::backup

参考链接

Systems Performance: Enterprise and the Cloud v2

脚注

1.Systems Performance: Enterprise and the Cloud v2 #3.4.4 Extended BPF ↩

AI 本地大模型 Ollama 部署

发表于 2026-04-28 上层目录 Tools ， AI

服务器配置如下（32CPU 32G RAM, 无 GPU）：

# lscpu  | grep NUMA
NUMA node(s):                         2
NUMA node0 CPU(s):                    0-7,16-23
NUMA node1 CPU(s):                    8-15,24-31

# free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        10Gi       583Mi       145Mi        19Gi        19Gi
Swap:             0B          0B          0B

# cat /etc/os-release 
PRETTY_NAME="Ubuntu 22.04.5 LTS"
NAME="Ubuntu"
VERSION_ID="22.04"
VERSION="22.04.5 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=jammy

root@vp-jmpsvr:~# uname -a
Linux vp-jmpsvr 5.15.0-119-generic #129-Ubuntu SMP Fri Aug 2 19:25:20 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

模型推荐清单 (纯 CPU 环境)

模型名称	推荐版本	理由	内存占用	速度预期
DeepSeek-V3 / R1 (Distill)	deepseek-r1:7b 或 14b	目前最强的推理模型，逻辑能力极佳。	~5GB / 9GB,	极快 / 流畅
Llama 3.1	llama3.1:8b	综合素质平衡，适合通用的英文/开发任务。	~5.5GB	极快
Qwen 2.5 (通义千问)	qwen2.5:7b 或 14b	中文语境支持最好，适合文档处理、后端开发辅助。	~5GB / 9GB	极快 / 流畅
Command R	command-r:35b	内存极限挑战。适合需要长上下文（RAG）的任务。	~20GB	较慢

安装 Ollama

curl -fsSL https://ollama.com/install.sh | sh

查看 Ollama Service 状态

# systemctl status ollama --no-pager
● ollama.service - Ollama Service
     Loaded: loaded (/etc/systemd/system/ollama.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2026-04-28 16:53:27 CST; 3min 46s ago
   Main PID: 3683510 (ollama)
      Tasks: 15 (limit: 38371)
     Memory: 28.1M
        CPU: 251ms
     CGroup: /system.slice/ollama.service
             └─3683510 /usr/local/bin/ollama serve

运行推荐模型 (以 DeepSeek R1 7B 为例)

ollama run deepseek-r1:7b

(Optional)部署 Open WebUI（原 Ollama WebUI） ，它支持 Docker 部署

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    restart: always
    network_mode: host
    environment:
      # 关键点：访问宿主机的 Ollama
      - OLLAMA_BASE_URL=http://127.0.0.1:11434
      # 可选：设置 WebUI 的语言
      - WEBUI_NAME=My AI Server
      # UI 监听端口
      - PORT=9000

    volumes:
      - ./open-webui:/app/data

AI 工具常用提示词

发表于 2026-04-26 上层目录 Tools ， AI

ansible server rules

# rules
每次运行任务之前，你都必须先读取此文件内容，并严格遵守：
1. 本机(ansible server)仅作为 Ansible 控制节点使用。
   - 允许在本机执行只读操作：查看文件、查看 inventory、查看 playbook、查看日志、语法检查、版本检查。
   - 禁止在本机执行任何业务变更操作，包括但不限于：安装/卸载软件、修改配置、启动/停止/重启服务、修改系统环境、删除文件。
   
2. 对远程主机，所有“变更类操作”都必须先得到我的明确确认后才能执行。
   变更类操作包括但不限于：
   - 安装、升级、卸载软件
   - 修改配置文件
   - 创建、删除、覆盖文件或目录
   - 启动、停止、重启、重载服务
   - 执行会改变系统状态的命令
   - 变更 systemd、网络、防火墙、用户权限、计划任务、SSH 配置
   - 执行 playbook 或 ad-hoc 命令造成远程状态变化
   
3. 对远程主机的只读检查操作，默认也需要先向我说明检查计划，再等待我确认；
   除非我明确说“可以先检查后汇报”，否则不得自行执行。
   只读检查包括但不限于：
   - 查看系统版本、磁盘、内存、CPU、进程、端口、服务状态、日志、配置内容
   - 执行不会修改系统状态的 Ansible ad-hoc 命令
   
4. 每次收到任务后，必须先给出 Plan，未经我确认不得执行。
   Plan 至少包含：
   - 任务目标
   - 涉及的目标主机
   - 需要执行的检查步骤
   - 计划执行的 Ansible 命令、playbook 或 shell 命令
   - 是否为只读操作或变更操作
   - 风险点与影响范围
   
5. 在我确认前，你不得：
   - 自行 SSH 登录远程主机执行命令
   - 自行运行任何 Ansible playbook
   - 自行运行任何会影响远程主机状态的 ad-hoc 命令
   - 将一次确认扩展理解为对其他主机、其他命令或后续步骤的授权
   
6. 你的执行授权必须按“单次、明确、最小范围”理解。
   每次执行前都必须明确说明：
   - 目标主机
   - 执行内容
   - 执行方式
   - 预期结果
   未被明确确认的内容一律不得执行。
   
7. 涉及高风险操作时，必须单独再次确认。
   高风险操作包括但不限于：
   - 删除文件/目录
   - 批量修改多台主机
   - 重启主机
   - 修改网络、防火墙、路由、SSH
   - 修改数据库数据
   - 覆盖证书、密钥、权限
   - 停止生产服务
   
8. 优先使用安全方式：
   - 能只读检查时，先只读检查
   - 能使用 `--check` / `--diff` / `--syntax-check` 时，优先先展示结果再申请正式执行
   - 不得跳过验证直接执行正式变更
   
9. 若执行失败、结果异常或存在不确定性：
   - 立即停止后续操作
   - 汇报实际执行内容、报错信息、影响范围
   - 给出修复建议
   - 未经我再次确认，不得继续尝试其他方案
   
10. 回复格式固定为：
   - Plan
   - 待确认的检查操作
   - 待确认的变更操作
   - 风险说明
   - 等待我的确认            
   
11. 未经我明确允许，不得使用 shell/command 直接在远程主机执行命令；
    优先使用 Ansible 模块化方式执行，并说明原因。
    
12. 未经我明确允许，不得对超过 1 台主机同时执行变更；
    批量操作必须逐台或分批确认。
           
# 当前任务

阅读全文 »

Ansible 使用介绍

发表于 2023-08-31 更新于 2026-04-24 上层目录 Linux

环境信息

Centos 7
ansible-core 2.16
Docker image python:3.12.3

安装

ansible-core 版本及 Python 版本支持对应关系

ansible-core Version	Control Node Python	Target Python / PowerShell
2.16	Python 3.10 - 3.12	Python 2.7 Python 3.6 - 3.12 Powershell 3 - 5.1

为了环境部署方便灵活，可以选择使用 python:3.12.3 的 Docker 镜像，以其为基础环境安装 ansible-core 2.16 或者直接使用 ansible 镜像启动。

# docker run --rm -it python:3.12.3 bash

# cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"

# python --version
Python 3.12.3

# pip install ansible

# pip list
Package      Version
------------ -------
ansible      9.5.1
ansible-core 2.16.6
cffi         1.16.0
cryptography 42.0.7
Jinja2       3.1.4
MarkupSafe   2.1.5
packaging    24.0
pip          24.0
pycparser    2.22
PyYAML       6.0.1
resolvelib   1.0.1
setuptools   69.5.1
wheel        0.43.0

# ansible --version
ansible [core 2.16.6]
  config file = None
  configured module search path = ['/root/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/local/lib/python3.12/site-packages/ansible
  ansible collection location = /root/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/local/bin/ansible
  python version = 3.12.3 (main, May 14 2024, 07:23:41) [GCC 12.2.0] (/usr/local/bin/python)
  jinja version = 3.1.4
  libyaml = True

在服务器本地环境部署，如果想要灵活管理配置，也可以使用 pip3 命令安装 ansible

$ pip3 install ansible

$ ansible --version
ansible [core 2.15.13]
  config file = None
  configured module search path = ['/home/ops/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/ops/.local/lib/python3.9/site-packages/ansible
  ansible collection location = /home/ops/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/ops/.local/bin/ansible
  python version = 3.9.25 (main, Dec 10 2025, 00:00:00) [GCC 11.5.0 20240719 (Red Hat 11.5.0-5)] (/usr/bin/python3)
  jinja version = 3.1.6
  libyaml = True

如此安装的 ansible 默认不加载任何配置文件，此时只需在 ~/.ansible/ 下手动创建 ansible.cfg 即可

~/.ansible/ansible.cfg

[defaults]
inventory = inventory

host_key_checking = False

forks = 20

timeout = 60

gathering = smart

[ssh_connection]


ssh_args = -o ControlMaster=auto -o ControlPersist=60s -o ControlPath=/tmp/ansible-control-%r-%h:%p

切换到 ~/.ansible/ 目录，再次查看 Ansible 加载的配置，其已经加载了 ~/.ansible/ansible.cfg

$ ansible --version
ansible [core 2.15.13]
  config file = /home/ops/.ansible/ansible.cfg
  configured module search path = ['/home/ops/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/ops/.local/lib/python3.9/site-packages/ansible
  ansible collection location = /home/ops/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/ops/.local/bin/ansible
  python version = 3.9.25 (main, Dec 10 2025, 00:00:00) [GCC 11.5.0 20240719 (Red Hat 11.5.0-5)] (/usr/bin/python3)
  jinja version = 3.1.6
  libyaml = True

Ansible 配置说明

Ansible 主配置文件为 /etc/ansible/ansible.cfg ， 其中的配置都可以被 ansible-playbook 或者命令行参数覆盖 。

ansible 默认会读取环境变量 ANSIBLE_CONFIG 指定的配置文件，当前路径下的 ansible.cfg ，以及用户家目录下的 .ansible.cfg ，以及 /etc/ansible/ansible.cfg 作为配置文件，已第一个找到的为准

常用配置说明

配置项	说明	示例
`inventory`	指定 inventory （主机列表）文件的路径，默认为 `/etc/ansible/hosts`
`remote_user`	（未指定用户时）连接远程主机时使用的用户
`remote_port`	连接远程主机时使用的(默认)端口
`host_key_checking`	默认启用。检查主机密钥可以防止服务器欺骗和中间人攻击。如果主机重新安装并且在 `know_hosts` 中拥有不同的密钥，ansible 会提示确认密钥。如果要禁用此行为，可以配置为 `False`
`ask_pass`	默认为 False。当设置为 True 时，ansible 要求输入远端服务器的密码，即使配置了免密登录
`log_path`	日志文件，默认 `/var/log/ansible.log`
`pattern`	当没有给出 `pattern` 时的默认 `pattern` ，默认值是 `*` 即所有主机

配置示例

/etc/ansible/ansible.cfg

[defaults]
# 设置默认的 inventory 文件路径
inventory = /etc/ansible/hosts

# 关闭主机密钥检查，方便新主机的快速添加
host_key_checking = False

# 设置默认的远程用户
remote_user = ansible

Inventory 配置说明

默认的 inventory 配置文件路径为 /etc/ansible/hosts ，主要用来配置 Managed Hosts 列表 ^[3]

在命令行中，可以使用选项 -i <path> 指定不同的 inventory 或者可以在 ansible 配置文件 ansible.cfg 中使用指令 inventory 指定 inventory 文件位置。

命令行中可以使用 -i <path1> -i <path2> ... 指定多个 inventory

inventory 文件支持多种格式，最常见的是 INI 和 YAML 格式。

Ansible 默认创建了 2 个组：
- all : 包含所有主机
- ungrouped : 包含所有不在其他组（ all 除外）中的所有主机。
任何一个主机都会至少在 2 个组中，要么 在 all 和某个组中 ，要么 在 all 和 ungrouped 组 。
一个主机可以包含在多个组中
parent/child 组 ， child 组被包含在 parent 组中。
- INI 配置格式中，使用 :children 后缀配置 parent
- YAML 配置格式中，使用 children: 配置 parent
- 任何在 child 组中的主机自动成为 parent 组中的一员
- 一个组可以包括多个 parent 和 child 组， 但是不能形成循环关系
- 一个主机可以在多个组中，但是在运行时，只能有一个实例存在，Ansible 会自动将属于多个组的主机合并。

主机范围匹配 。如果有格式相似的主机，可以通过 范围格式 使用一条指令来添加多台主机。

INI 配置格式中，使用以下格式

[webservers]
www[01:50].example.com

## 指定步长增长
www[01:50:2].example.com
      
db-[a:f].example.com

YAML 配置格式中，使用以下格式

# ...
  webservers:
    hosts:
      www[01:50].example.com:
      
      ## 指定步长增长
      www[01:50:2].example.com:
      db-[a:f].example.com:

范围格式 的第一项和最后一项也包括在内。即匹配 www01 和 www50

Inventory 多配置文件支持

在主机数量较多，或者组织结构较复杂的情况下，使用单个 Inventory 配置文件会导致主机管理较为复杂。将单个 Inventory 配置文件按照项目或者组织或其他规则进行分割会显著降低维护复杂度。

Inventory 多配置文件支持，可以使用以下方法之一

按照项目或者组织或其他规则将主机分割到多个配置中，命令行中可以使用 -i <path1> -i <path2> ... 指定多个 inventory
按照项目或者组织或其他规则将主机分割放置在多个文件中，并将所有文件统一放置在一个单独的目录中（如 /etc/ansible/inventory/ ），在命令行中使用选项 -i /etc/ansible/inventory/ 或者在 Ansible 配置文件( ansible.cfg )中使用指令 inventory 配置目录。

注意事项 ： Ansible 使用字典顺序加载配置文件，如果在不同的配置文件中配置了 parent groups 和 child groups ，那么定义 child groups 的配置要先用定义 parent groups 的文件加载，否则 Ansible 加载配置会报错： Unable to parse /path/to/source_of_parent_groups as an inventory source ^[4]
使用 group_vars 和 host_vars 目录分别存储组变量和主机变量 ^[7]

注意事项 ：组变量和主机变量必须使用 YAML 格式，合法的文件扩展名包括： .yaml 、 yml 、 .json 或者无文件扩展名

INI 格式的 Inventory

主机列表中的主机可以单独出现，也可以位于某个或者多个 组( [] 开头的行)中

/etc/ansible/hosts

ansible-demo1.local
ansible-demo2.local

[webserver]
webserver1.local
webserver2.local

[nginxserver]
# 匹配多个主机：nginx1.local， nginx2.local， nginx3.local， nginx4.local
nginx[1:4].local variable1=value1 variable2=value2
nginx-bak.local ansible_ssh_host=10.10.0.1 ansible_ssh_port=22 ansible_ssh_user=root ansible_ssh_pass=PASSWORD
127.0.0.1 http_port=80 maxRequestPerChild=808

连接主机使用的常用配置说明 ^[6]

配置项	说明	示例
`ansible_host`	远程主机地址
`ansible_port`	远程主机端口
`ansible_user`	连接远程主机的 ssh 用户 Ansible 默认使用 control node 上执行 `ansible` 的用户名来连接远程主机 ^[9]
`ansible_password`	连接远程主机的 ssh 用户密码，建议使用 key 连接
`ansible_ssh_private_key_file`	连接远程主机的 ssh 私钥文件路径
`ansible_become` `ansible_sudo` `ansible_su`	用户权限提升
`ansible_become_method`	用户权限提升(escalation)的方式
`ansible_become_user` `ansible_sudo_user` `ansible_su_user`	用户权限提升(escalation)后的用户
`ansible_become_password` `ansible_sudo_password` `ansible_su_password`	`sudo` 密码(这种方式并不安全,强烈建议使用 `--ask-sudo-pass` )
`ansible_become_exe` `ansible_sudo_exe` `ansible_su_exe`	设置用户权限提升(escalation)后的可执行文件
`ansible_connection`	与主机的连接类型.比如: `local` , `ssh` 或者 `paramiko` Ansible 1.2 以前默认使用 `paramiko` 。1.2 以后默认使用 `smart` , `smart` 方式会根据是否支持 `ControlPersist` , 来判断 `ssh` 方式是否可行.
`ansible_shell_type`	目标系统的 shell 类型.默认情况下,命令的执行使用 `sh` 语法,可设置为 `csh` 或 `fish` .
`ansible_python_interpreter`	目标主机的 python 路径系统中有多个 Python, 或者命令路径不是 `/usr/bin/python`

阅读全文 »

Docker compose 部署 Confluence 和 Jira

发表于 2026-01-22 更新于 2026-04-18 上层目录 Tools

环境信息

Docker 26.1.1
Confluence Image： atlassian/confluence:8.5.15
Jira Image： atlassian/jira-software:9.12.11
postgresql 13

配置流程

创建项目所需新目录，用于存储持久化数据

# mkdir -p /opt/devops/{confluence,jira,postgresql}

下载 atlassian-agent.jar 文件，将其分别放置在 ./confluence/atlassian-agent.jar 和 ./jira/atlassian-agent.jar ，用于之后为 Confluence 和 Jira 生成 License

docker-compose.yaml 文件内容如下

docker-compose.yaml

services:
  # --- 数据库服务 ---
  postgres-db:
    image: postgres:13
    container_name: devops-postgres-db
    volumes:
      - ./postgresql:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=<PG_PASSWORD>
      - POSTGRES_DB=confluence
    healthcheck:
      test: ["CMD-SHELL", "pg_isready"]
      interval: 10s
      timeout: 5s
      retries: 5     
    networks:
      - devops-net


  # --- Confluence ---
  confluence:
    image: atlassian/confluence:8.5.15
    container_name: confluence
    depends_on:
      postgres-db:
        condition: service_healthy
    ports:
      - "8090:8090"
      - "8091:8091" # 同步端口（可选）
    environment:
      - ATL_JDBC_USER=postgres
      - ATL_JDBC_PASSWORD=74ni4ikEHVot8IJf
      - ATL_JDBC_URL=jdbc:postgresql://postgres-db:5432/confluence
      - ATL_DB_TYPE=postgresql
      - JVM_MINIMUM_MEMORY=2048m
      - JVM_MAXIMUM_MEMORY=4096m
      - TZ='Asia/Shanghai'
      - JVM_SUPPORT_RECOMMENDED_ARGS=-javaagent:/var/atlassian/application-data/confluence/atlassian-agent.jar
    volumes:
      - ./confluence:/var/atlassian/application-data/confluence
    networks:
      - devops-net
  
  # --- Jira ---
  jira:
    image: atlassian/jira-software:9.12.11
    container_name: jira
    depends_on:
      postgres-db:
        condition: service_healthy
    ports:
      - "8080:8080" # Jira 默认端口
    environment:
      - ATL_JDBC_USER=postgres
      - ATL_JDBC_PASSWORD=<PG_PASSWORD>
      - ATL_JDBC_URL=jdbc:postgresql://postgres-db:5432/jira  # 注意这里是指向新创建的 jira 库
      - ATL_DB_TYPE=postgresql
      - JVM_MINIMUM_MEMORY=2048m
      - JVM_MAXIMUM_MEMORY=4096m
      - TZ='Asia/Shanghai'
      - JVM_SUPPORT_RECOMMENDED_ARGS=-javaagent:/var/atlassian/application-data/jira/atlassian-agent.jar
    volumes:
      - ./jira:/var/atlassian/application-data/jira
    networks:
      - devops-net

networks:
  devops-net:
    driver: bridge

启动容器

# docker compose up -d

postgres 数据库启动正常后，执行以下命令为 Jira 创建数据库，Confluece 数据库在容器启动是会自动创建。

docker compose exec -it postgres-db psql -U postgres -c "CREATE DATABASE jira WITH ENCODING='UTF8' LC_COLLATE='en_US.utf8' LC_CTYPE='en_US.utf8' CONNECTION LIMIT=-1;"

Confluence 初始化部署

浏览器访问 http://<IP>:8090 在 Confluence 初始化页面拿到 Server ID

# docker compose exec -it confluence bash
root@81d2f5a8f7e5:/var/atlassian/application-data/confluence# java -jar atlassian-agent.jar -d -p conf -m Hello@world.com -n Hello@world.com  -o your-org -s B66H-ET1W-2LYR-Q7R2

====================================================
=======     Atlassian Crack Agent v1.3.1     =======
=======           https://zhile.io           =======
=======          QQ Group: 30347511          =======
====================================================

Your license code(Don't copy this line!!!): 

AAABmA0ODAoPeJxtUVuPojAUfu+vINlnFKoLaNJkHWBWZwEZxbk8FjxII7akFBz21y8ik00mk/Sl5
7Tf9UdSNNoT5RrGmuEsZ3g5m2u/w0TDBraQK4EqJrhHFZDbRDdMHWPkt7Rshg3JaVkD8qDOJKuGy
YGX7MIUHLWSZcBr0NJOK5Sq6uV0+rdgJUyYQFt5opzVd5BONFIX8oQywfMJzRRrgSjZAHIFV/3dD
ykryRrKUvy6ClkeJ5m4oBF/TeuChO7VfXxczdPjayzCPG9e/NxN8dP845x4cbxeFc/VWwPTFrfRG
zarNGni0+HP+WotwmhFyJ16r6hUIEdXwyi4kyRdBRG9AHG3Yejv3M0qQL0oroBTnoH/UTHZjTk5C
92w+4PGvxuPBBtv70d6YNrWwrAN++fcdhy0B9mC7NcPlrXW/cR81XHwvtOf7R2+s/eI1AV+0zTkc
YbuBWR9C820jB7Jmc3MT57vRcSNzApaw9cSx/Q+4TDaN+n/Fge2QULUXFKQ2/xQ9y+JbqLeCPnGz
FjVENKXpv4BHKbJjjAtAhRlC24D9XOs3Z9LZwzE3PehVo5lhgIVAIaOykfNKCdhuAZn7PZsJR+qr
edbX02jn

命令参数说明：

-d 调试模式必选，用于输出生成的许可证信息。

-m 电子邮箱 随便填 ，如 devops@example.com 。

-n 用户名 随便填 ，如 Organization_Admin。

-p 产品标识 不可乱填 。Confluence 是 conf ，Jira 是 jira ，Bitbucket 是 bitbucket 。

-o 组织/URL 建议填你的访问地址，如 https://wiki.mysite.com 。

-s Server ID 核心参数。必须填 Web 页面上显示的那个 16 位代码 。

License 验证成功后，填写数据库连接信息并测试连接成功

Jira 初始化部署

浏览器访问 http://<IP>：8080 打开 Jira 初始化页面，在 Jira setup 中选择 I'll set it up myself 。因为后面要指定数据库信息，因此要选择自定义。

根据提示填入数据库连接信息，测试无误后，到 Specify your license key 页面，复制 Server ID

登入 jira 容器，使用以下命令为 Jira 生成 License

root@69487899ebea:/var/atlassian/application-data/jira# java -jar atlassian-agent.jar -d -p jira -m Hello@world.com -n Hello@world.com  -o your-org -s BYTU-X57R-U6U3-LSIB

====================================================
=======     Atlassian Crack Agent v1.3.1     =======
=======           https://zhile.io           =======
=======          QQ Group: 30347511          =======
====================================================

Your license code(Don't copy this line!!!): 

AAAB5Q0ODAoPeJyNU9GSmjAUfecrmOkzboKuqDOZ6YpYmQW0onb7GPEK2SKhSdDFry8K2+6q43QmL
8ncc+455958+QEbfQxrHWMddQcmGpgd/Zu/0E1kdrVYAGQJz3MQLY9FkElYlDkEdAfEnvq+M7fdJ
0+zBVDFeDaiCsgJaCDTwFi7AxmBjATLTyiyzFK2Y6oSktYAfV3qiVK5HDw8HBOWQotxzacsU5DRL
ALnLWeibLr1+gayqqO9MkHfVTobVlMHnuu7C2ekBcVuDWK6XUoQkhh/xd3hygXfFJFqnS6G5Ft1o
AJaV0R3ammk2B6IEgV8yvLj+x14pYraULkWdWkTz6pqfDJnamGx/hfjucTZ07Q4D4NsaSob+kuiq
YhpxmRdV/JCGFzEms0zVSlzqqRTMoE05V8PXKSbVsR3Nc+V90bRhMqE+PbBHk/i+W8c8mdIO8fiu
UBHvJj23KHnhqun5DvDc0f1VsfZMB6/vqDH/jHocJaUMxQTUrf4z2hCRcXJTm2ymaU7Ip47Cp3A8
LBlIauPeman38GfVuPWNoYg9iAq+PDnYmm8PFpzY9ldtg0vdIfaLyjfE8ddhCzUa7fxra9xvXSzQ
kQJlXD5MT6Cz2PJBZON6Uo+uWGhGc5Z+cVs/gCvg0phMC0CFBCTfaevRY4wQYedPfgvyTwghlJmA
hUAlodnLvDqtFh/z+wXjAncJwqlqNc=X02n3

注意其中的参数 -p jira

根据提示完成其他配置即可开始使用 Jira。

Confluence 迁移

部署好相同版本的 Confluence 和 PostgreSQL 环境，

在开始之前，请确保：

停止旧环境和新环境的 Confluence 容器，以保证数据一致性。
确认新环境的 PostgreSQL 13 已经启动，并创建了一个空的数据库（例如名为 confluence ）。

迁移 PostgreSQL 数据库

由于版本一致，直接使用 pg_dump 是最稳妥的方案。

docker exec -t <旧数据库容器名> pg_dump -U <用户名> <数据库名> > confluence_db.sql

先删除新环境中的数据库 confluence ，再新建

# psql -h <HOST> -U postgres -d postgres

postgres=> \l
                                  List of databases
    Name    |  Owner   | Encoding |   Collate   |    Ctype    |   Access privileges   
------------+----------+----------+-------------+-------------+-----------------------
 confluence | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
 jira       | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
 postgres   | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
 rdsadmin   | rdsadmin | UTF8     | en_US.UTF-8 | en_US.UTF-8 | rdsadmin=CTc/rdsadmin
 template0  | rdsadmin | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/rdsadmin          +
            |          |          |             |             | rdsadmin=CTc/rdsadmin
 template1  | postgres | UTF8     | en_US.UTF-8 | en_US.UTF-8 | =c/postgres          +
            |          |          |             |             | postgres=CTc/postgres
(6 rows)

postgres=> DROP DATABASE confluence;
DROP DATABASE
postgres=> 

postgres=> CREATE DATABASE confluence;
CREATE DATABASE

然后导入备份数据，将 confluence_db.sql 拷贝到新服务器，然后执行：

cat confluence_db.sql | docker exec -i <新数据库容器名> psql -U <用户名> -d <数据库名>

迁移 Confluence Home 目录

Confluence 的用户附件、索引、插件配置等都存储在 Home 目录下。进入旧服务器的映射目录，执行
tar -zcvf confluence_home_backup.tar.gz /path/to/old/confluence_home
将备份文件传输到新 Confluence 环境 Home 目录并解压
修改配置文件（如果数据库连接变了）

如果新环境的数据库 IP、端口或密码与旧环境不同，你需要修改新环境 Home 目录下的配置文件：

文件路径： <confluence-home>/confluence.cfg.xml

迁移完成后，重启 Confluence，即可加载到旧环境中的数据。

常见问题

迁移后文档无法编辑

迁移完成后，Confluence 打开正常，数据已经恢复，但是编辑文档保存时报错： Something went wrong after loading the editor. Copy your unsaved changes and refresh the page to keep editing.

这个错误通常意味着 Confluence 协作编辑（Collaborative Editing） 服务出现了通讯故障。在 Confluence 9.0.2 中，这通常与 Synchrony（负责实时协作的组件）的配置或网络环境有关。

可以 刷新 Synchrony 状态 解决

以管理员身份登录 Confluence。
前往 管理 (Confluence administration) > 协作编辑 (Collaborative editing) 。
点击 Change mode ，将其切换为 Disabled 。
等待几秒钟后，重新切换回 Enabled 。

这会重启 Synchrony 进程并清理过时的锁定状态。

Loki 部署使用

发表于 2026-04-16 上层目录 Tools

Loki 是 Grafana 体系里的日志聚合系统，设计思路和 Prometheus 很像，但处理对象是日志。它和传统全文检索型日志系统的最大区别是： 默认只索引标签（labels），不索引整条日志正文 ，所以存储成本通常更低，扩展性也更好，特别适合 Kubernetes、Docker、主机系统日志、应用日志统一汇聚场景。

截至 2026-04-16，Promtail 已经 EOL，新的采集端优先建议使用 Grafana Alloy ；另外，Loki 本身不内置认证层，生产环境应放在 Nginx 等反向代理或网关之后。

它的典型链路是：

日志源 → 采集器（Alloy） → Loki → Grafana 查询与展示

其中：

Loki 负责接收、压缩、存储、查询日志。
Alloy 负责在主机或 K8s 节点上收集日志、打标签、做预处理，再推送到 Loki。
Grafana 负责可视化、检索、告警。

Loki 核心架构逻辑上常见有这些组件：

Distributor ：接收写入请求
Ingester ：缓存并写入日志块
Querier ：执行查询
Query Frontend ：查询拆分与缓存
Compactor ：压缩、整理、保留策略
Index / Storage ：索引和日志对象存储

标签设计建议

Loki 的性能很大程度取决于标签设计，因此标签设计非常关键。

建议保留低基数标签 ：

job
host
env
app
namespace
pod
container

不要把高基数内容做成标签 ：

user_id
request_id
trace_id
URL 全路径
错误详情
SQL 文本

官方文档强调 labels 是 Loki 的核心组织方式，但标签过多、基数过高会带来性能和成本问题。

Docker Compose 部署示例

Loki version 3.7.1
alloy, version v1.15.1

docker-compose.yaml

services:
  loki:
    image: grafana/loki:latest
    command:
      - '-config.file=/etc/loki/config.yaml'    
    ports:
      - "3100:3100"
    volumes:
      - "./config/loki/:/etc/loki/:ro"
      - "./data/loki/:/data/loki"

  grafana:
    image: grafana/grafana
    ports:
      - "3000:3000"
    volumes:
      - "./config/grafana/:/etc/grafana/"
      - "./data/grafana/:/var/lib/grafana/"


  alloy:
    image: grafana/alloy
    container_name: alloy
    restart: unless-stopped
    ports:
      - "12345:12345"
    command:
      - run
      - --server.http.listen-addr=0.0.0.0:12345
      - --storage.path=/var/lib/alloy/data
      - /etc/alloy/config.alloy
    volumes:
      - ./config/alloy/:/etc/alloy/:ro
      - ./data/alloy/:/var/lib/alloy/data
      - /var/run/docker.sock:/var/run/docker.sock

主配置文件 /etc/loki/config.yaml 内容参考：

/etc/loki/config.yaml

auth_enabled: false

server:
  http_listen_port: 3100

common:
  path_prefix: /loki
  replication_factor: 1
  ring:
    kvstore:
      store: inmemory

schema_config:
  configs:
    - from: "2024-01-01"
      store: tsdb
      object_store: filesystem
      schema: v13
      index:
        prefix: index_
        period: 24h

storage_config:
  filesystem:
    directory: /loki/chunks

limits_config:
  allow_structured_metadata: true
  retention_period: 168h

compactor:
  working_directory: /loki/compactor
  retention_enabled: true
  delete_request_store: filesystem

Alloy 配置文件参考：

config/alloy/config.alloy

logging {
  level  = "info"
  format = "logfmt"
}

discovery.docker "containers" {
  host = "unix:///var/run/docker.sock"
}

discovery.relabel "docker_logs" {
  targets = discovery.docker.containers.targets

  rule {
    source_labels = ["__meta_docker_container_name"]
    target_label  = "container"
    regex         = "/(.*)"
    replacement   = "$1"
  }

  rule {
    source_labels = ["__meta_docker_container_log_stream"]
    target_label  = "stream"
  }

  rule {
    source_labels = ["__meta_docker_container_label_com_docker_compose_service"]
    target_label  = "service"
  }
}

loki.source.docker "containers" {
  host       = "unix:///var/run/docker.sock"
  targets    = discovery.relabel.docker_logs.output
  forward_to = [loki.write.local.receiver]
}

loki.write "local" {
  endpoint {
    url = "http://loki:3100/loki/api/v1/push"
  }

  external_labels = {
    host = "prometheus-jumpserver",
    env  = "prod",
  }
}

启动成功后，在 Grafana 中添加新的 Data Source。即可在 Grafana 中查看到日志。

配置文件详解

Loki 配置文件

Loki version 3.7.1

以下配置适用于单机、单副本、本地文件系统、保留 7 天数据的 Liki

/etc/loki/config.yaml

auth_enabled: false

server:
  http_listen_port: 3100      # Loki 的 HTTP 服务监听端口。Grafana、Alloy 或自己用 curl 查询 Loki API 时，默认都会连这个端口。官方配置文档把 server 作为 Loki 进程网络与服务行为的基础配置入口。

common:                      # Loki 多组件共用的基础参数（通用运行参数）。
  path_prefix: /loki         # Loki 的本地工作目录前缀。很多组件的临时文件、索引缓存、压缩过程中的文件、规则文件等，都可能基于这个路径展开。官方示例中常见把它设成 /loki。在 Docker 部署中需要持久化
  replication_factor: 1      # 只保留 1 份副本。这适合单机或非高可用测试环境。官方示例中单机 / 简化部署也常用 1。想要高可用，通常需要 >1，并配套 ring/多节点/对象存储
  ring:                      # ring 是分布式 Loki 用来协调实例状态、分片、接收写入等的关键机制。
    kvstore:
      store: inmemory        # 表示 Loki 的 ring 元数据存储在内存里。好处是简单，坏处是进程重启后状态不持久，也不适合多实例生产。

schema_config:               # 存储 schema 定义。这部分是 Loki 最关键的配置之一。schema 是按时间段生效的，Loki 会根据日志时间决定使用哪套 schema 来存储和查询数据。
  configs:
    - from: "2024-01-01"     # 表示从 2024-01-01 开始写入的数据，使用下面这一整套 schema。from 是时间分界点；如果后面再新增一条新 schema，比如 from: "2026-05-01"，那么之后的数据就会按新 schema 存。
      store: tsdb            # 使用 TSDB 索引。从 Loki 2.8 起，TSDB 是推荐的索引方式，更高效、更快、可扩展性更好。
      object_store: filesystem     # 日志块和相关对象数据存到本地文件系统，而不是 S3、GCS、Azure Blob 之类的对象存储。正式环境应该优先使用 S3 / MinIO / GCS 等对象存储
      schema: v13                  # 这是 schema 版本。官方升级文档明确说，Structured Metadata 要求 active schema 同时使用 tsdb 和 v13；迁移文档也把 v13 作为推荐版本。
      index:
        prefix: index_             # 索引前缀名。 Loki 会按自己的规则生成索引对象名或目录名，这个前缀就是命名的开头。
        period: 24h                # 这是非常关键的参数，表示索引按 24 小时切分。官方 retention 文档明确说明，retention 仅支持 24h index period。

storage_config:                    # 底层存储配置
  filesystem:                      # schema 配置了 object_store: filesystem，就需要给 filesystem 指定目录。
    directory: /loki/chunks        # 这个目录用于保存 Loki 的日志块数据。简单说，日志正文压缩后的 chunk 文件会在这里。你容器删除或这个目录丢失，就会失去本地日志数据。

limits_config:                     # 限制与功能开关。控制 Loki 的一些行为限制和特性。官方升级文档、structured metadata 文档以及 retention 相关文档都涉及这里的配置项。
  allow_structured_metadata: true  # 允许 Loki 使用 Structured Metadata（某些字段可以作为结构化元数据随日志返回）。官方说明，Structured Metadata 在 Loki 3.0 默认已启用，但前提是你的 active schema 必须是 TSDB + v13；如果不是，就需要关闭或迁移。
  retention_period: 168h           # 全局日志保留 168 小时，也就是 7 天。这个只是“希望保留多久”，真正执行删除还依赖 compactor 配置正确，并且索引周期满足要求

compactor:                                 # 压缩与保留删除执行者，Compactor 不只是做压缩，也负责 retention 相关处理。
  working_directory: /loki/compactor       # compactor 的工作目录，用来存放压缩、保留、删除流程中的临时文件或处理中间状态。
  retention_enabled: true                  # 表示打开 retention 机制。没有这个，即使你写了 retention_period，compactor 也只会做压缩，不会执行基于保留期的删除。
  delete_request_store: filesystem         # 若启用 retention，必须配置 delete_request_store；它决定删除请求存在哪种后端里。

Alloy 配置文件详解

alloy, version v1.15.1

Alloy 配置文件本质上是在描述一条 数据流水线

发现目标 → 读取数据 → 处理/加标签 → 写到 Loki / Prometheus / OTLP 等后端

Alloy 的配置语法由两类基础元素组成： attributes（属性）和 blocks（块） 。属性用 key = value 赋值，块用来定义组件实例和嵌套配置。

Alloy 官方把一些顶层块称为 configuration blocks ，它们用于配置 Alloy 进程本身，不是在采集业务日志或者输出日志。比如：

logging
tracing
http
livedebugging
import.*

Linux 下 Alloy 默认配置文件路径是 /etc/alloy/config.alloy

logging {                      # 配置 Alloy 自己的日志
  level  = "info"              # Alloy 自己输出 info 级别日志
  format = "logfmt"            # 输出为 logfmt 格式
}

discovery.docker "containers" {             # 发现 Docker 容器，discovery.docker 会把每个容器映射成 target。
  host = "unix:///var/run/docker.sock"      # 连接 Docker daemon、从 Docker 中发现容器目标、暴露出一组可供下游使用的 targets。要生效，你的容器通常要挂载 /var/run/docker.sock
}

discovery.relabel "docker_logs" {                   # 重写或补充标签。把 Docker 自动发现到的元标签，转成在 Loki/Grafana 里更好用的业务标签。labels 是 Loki 的核心组织方式，必须谨慎设计，避免高基数标签。
  targets = discovery.docker.containers.targets     # 

  rule {
    source_labels = ["__meta_docker_container_name"]
    target_label  = "container"
    regex         = "/(.*)"
    replacement   = "$1"
  }

  rule {
    source_labels = ["__meta_docker_container_label_com_docker_compose_service"]
    target_label  = "service"
  }
}

loki.source.docker "containers" {                      # 读取 Docker 日志，这是日志采集核心。
  host       = "unix:///var/run/docker.sock"           # 连接哪个 Docker daemon
  targets    = discovery.docker.containers.targets     # 从哪里拿目标列表，从 discovery.docker "containers" 获取目标容器列表
  forward_to = [loki.write.local.receiver]             # 日志下一步发给谁。把当前读到的日志，发给 loki.write "local" 这个组件的 receiver。
}

loki.write "local" {                                   # 接收来自其他 Loki 组件的日志，把日志发到 Loki，这是输出端。
  endpoint {                                           # 定义目标 Loki 地址
    url = "http://loki:3100/loki/api/v1/push"
  }
  external_labels = {                                  # 给所有发出去的日志统一追加静态标签。
    host = "prometheus-jumpserver",                    # 所有日志自动打上 host=prometheus-jumpserver，env=prod 标签
    env  = "prod",
  }  
}

可以把 Alloy 理解成 组件图 。比如上面的配置链路：

discovery.docker (用于 Docker 目标发现)去发现 Docker 容器
loki.source.docker 读取这些容器的日志，并转发给其他 loki.* 组件
loki.write 把日志发给 Loki，用于接收日志并通过 Loki logproto 发往远端 Loki

如果不是采集 Docker，而是采集文件日志，这时通常会用：

loki.source.file
local.file_match

loki.source.file "files" {
  file_match {
    path_targets = [
      {"__path__" = "/var/log/*.log", "job" = "system"},
      {"__path__" = "/var/log/nginx/*.log", "job" = "nginx"},
    ]
  }

  forward_to = [loki.write.local.receiver]
}