chore: sync local project changes
This commit is contained in:
Shen Wei
@@ -1,47 +1,47 @@
|
||||
---
|
||||
title: "3X-UI Xray on BandwagonVPS"
|
||||
type: source
|
||||
tags: [vps, xray, 3x-ui, 科学上网, 网络配置]
|
||||
date: 2026-02-10
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/3X-UI Xray on BandwagonVPS]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 BandwagonVPS 上部署 3X-UI 可视化面板管理 Xray 代理服务
|
||||
- 问题域：家庭网络的科学上网解决方案 —— VPS 服务端部署与配置
|
||||
- 方法/机制：通过官方一键安装脚本部署 3X-UI 面板（基于 mhsanaei/3x-ui 项目），使用 VLESS+Reality 协议配置入站规则，启用 BBR 加速，客户端使用 v2rayN（Windows/Linux）和 v2rayNG（Android）连接
|
||||
- 结论/价值：构建稳定、低维护成本的境外网络访问通道，配合 RAX50 路由器 MerlinClash 插件实现全屋透明代理
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- BandwagonVPS（AS 104.194.92.x）作为家庭网络科学上网的 VPS 服务端，提供境外流量出口
|
||||
- 3X-UI 面板通过 Web UI 简化 Xray/V2Ray 的配置管理，支持 SSL 证书、BBR、Geo 文件更新等运维操作
|
||||
- VLESS+Reality 是当前抗封锁能力较强的代理协议方案，需要生成公钥/私钥对
|
||||
- Panel 与 xray 服务双进程均需保持 Running 状态才能正常代理
|
||||
- 启用 BBR 拥塞控制算法可提升跨境网络吞吐量和稳定性
|
||||
|
||||
## Key Quotes
|
||||
> "Panel state: Running ✅, xray state: Running ✅, Autostart: Enabled ✅" — 3X-UI 正常运行时三要素状态
|
||||
> "bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)" — 官方一键安装命令
|
||||
|
||||
## Key Concepts
|
||||
- [[3X-UI]]：基于 Go 的 Xray/V2Ray 可视化管理面板，提供 Web UI 和命令行两种管理方式，支持 SSL 证书、BBR、Geo 文件更新等
|
||||
- [[VLESS+Reality]]：一种抗封锁的代理协议方案，需要生成公钥和私钥，是当前较为推荐的配置方式
|
||||
- [[BBR]]：Google 开发的 TCP 拥塞控制算法，通过 `x-ui` → 输入 `23` 启用，可提升跨境网络吞吐量
|
||||
- [[Geo文件]]：Xray 的国家/地区 IP 规则数据库，通过 `x-ui` → 输入 `24` 更新，用于分流和过滤
|
||||
|
||||
## Key Entities
|
||||
- [[BandwagonHost]]：BandwagonHost（又称搬瓦工），美国 VPS 提供商，提供高性价比 KVM VPS
|
||||
- [[VPS2]]：BandwagonVPS 实例，IP 104.194.92.188，域名 kiwi.ishenwei.online，SSH 端口 22
|
||||
- [[3X-UI]]：mhsanaei/3x-ui 开源项目，提供 Xray 可视化管理界面
|
||||
- [[v2rayN]]：Windows/Linux 平台的 Xray/V2Ray 客户端
|
||||
- [[v2rayNG]]：Android 平台的 Xray/V2Ray 客户端
|
||||
|
||||
## Connections
|
||||
- [[3x-ui-xray-on-bandwagonvps]] ← depends_on ← [[群晖NAS科学上网方法]]
|
||||
- [[3x-ui-xray-on-bandwagonvps]] ← extends ← [[ubuntu-server科学上网]]
|
||||
- [[3x-ui-xray-on-bandwagonvps]] ← related_to ← [[网件RAX50路由器刷梅林固件与科学上网插件安装教程]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知内容冲突
|
||||
---
|
||||
title: "3X-UI Xray on BandwagonVPS"
|
||||
type: source
|
||||
tags: [vps, xray, 3x-ui, 科学上网, 网络配置]
|
||||
date: 2026-02-10
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/3X-UI Xray on BandwagonVPS]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 BandwagonVPS 上部署 3X-UI 可视化面板管理 Xray 代理服务
|
||||
- 问题域：家庭网络的科学上网解决方案 —— VPS 服务端部署与配置
|
||||
- 方法/机制：通过官方一键安装脚本部署 3X-UI 面板（基于 mhsanaei/3x-ui 项目），使用 VLESS+Reality 协议配置入站规则，启用 BBR 加速，客户端使用 v2rayN（Windows/Linux）和 v2rayNG（Android）连接
|
||||
- 结论/价值：构建稳定、低维护成本的境外网络访问通道，配合 RAX50 路由器 MerlinClash 插件实现全屋透明代理
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- BandwagonVPS（AS 104.194.92.x）作为家庭网络科学上网的 VPS 服务端，提供境外流量出口
|
||||
- 3X-UI 面板通过 Web UI 简化 Xray/V2Ray 的配置管理，支持 SSL 证书、BBR、Geo 文件更新等运维操作
|
||||
- VLESS+Reality 是当前抗封锁能力较强的代理协议方案，需要生成公钥/私钥对
|
||||
- Panel 与 xray 服务双进程均需保持 Running 状态才能正常代理
|
||||
- 启用 BBR 拥塞控制算法可提升跨境网络吞吐量和稳定性
|
||||
|
||||
## Key Quotes
|
||||
> "Panel state: Running ✅, xray state: Running ✅, Autostart: Enabled ✅" — 3X-UI 正常运行时三要素状态
|
||||
> "bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)" — 官方一键安装命令
|
||||
|
||||
## Key Concepts
|
||||
- [[3X-UI]]：基于 Go 的 Xray/V2Ray 可视化管理面板，提供 Web UI 和命令行两种管理方式，支持 SSL 证书、BBR、Geo 文件更新等
|
||||
- [[VLESS+Reality]]：一种抗封锁的代理协议方案，需要生成公钥和私钥，是当前较为推荐的配置方式
|
||||
- [[BBR]]：Google 开发的 TCP 拥塞控制算法，通过 `x-ui` → 输入 `23` 启用，可提升跨境网络吞吐量
|
||||
- [[Geo文件]]：Xray 的国家/地区 IP 规则数据库，通过 `x-ui` → 输入 `24` 更新，用于分流和过滤
|
||||
|
||||
## Key Entities
|
||||
- [[BandwagonHost]]：BandwagonHost（又称搬瓦工），美国 VPS 提供商，提供高性价比 KVM VPS
|
||||
- [[VPS2]]：BandwagonVPS 实例，IP 104.194.92.188，域名 kiwi.ishenwei.online，SSH 端口 22
|
||||
- [[3X-UI]]：mhsanaei/3x-ui 开源项目，提供 Xray 可视化管理界面
|
||||
- [[v2rayN]]：Windows/Linux 平台的 Xray/V2Ray 客户端
|
||||
- [[v2rayNG]]：Android 平台的 Xray/V2Ray 客户端
|
||||
|
||||
## Connections
|
||||
- [[3x-ui-xray-on-bandwagonvps]] ← depends_on ← [[群晖NAS科学上网方法]]
|
||||
- [[3x-ui-xray-on-bandwagonvps]] ← extends ← [[ubuntu-server科学上网]]
|
||||
- [[3x-ui-xray-on-bandwagonvps]] ← related_to ← [[网件RAX50路由器刷梅林固件与科学上网插件安装教程]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知内容冲突
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: "Clonezilla对Ubuntu Server进行全盘镜像备份"
|
||||
type: source
|
||||
tags: [backup, clonezilla, nas, rufus, ubuntu]
|
||||
date: 2026-05-06
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/Clonezilla对Ubuntu Server进行全盘镜像备份]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：使用 Clonezilla（再生龙）对 Ubuntu Server 进行全盘镜像备份到 NAS，灾难时可完整还原系统
|
||||
- 问题域：Linux 服务器数据保护、灾难恢复（DR）、NAS 存储集成
|
||||
- 方法/机制：Clonezilla live USB 启动 → device-image 模式 → NFS 网络存储挂载 → savedisk 全盘镜像 → restordisk 还原
|
||||
- 结论/价值：Clonezilla 提供类似 Ghost 的磁盘级镜像能力，是 rsync 增量备份之外的全量快照方案，两者互补构成完整备份策略
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Rufus 写入 Clonezilla ISO 时必须选择"ISO 镜像模式"，否则可能导致 U 盘启动失败
|
||||
- 针对较新笔记本，分区方案应选 GPT + UEFI（非 CSM）；老旧笔记本选 MBR + BIOS
|
||||
- NFS 是 NAS 备份场景下兼容性最好的网络协议，相比 SMB 更适合 Linux 环境
|
||||
- Clonezilla 备份完成后，新硬盘可通过 restoredisk 完整还原，系统即刻复活，无需重装
|
||||
|
||||
## Key Quotes
|
||||
> "Clonezilla live (Default settings, VGA 800x600)" — Clonezilla 启动菜单推荐选项，英文界面更稳定
|
||||
> "以 ISO 镜像模式写入 (推荐)" — Rufus 写入 ISOHybrid 镜像时的关键选择，DD 模式仅作备选
|
||||
|
||||
## Key Concepts
|
||||
- [[全盘镜像备份]]：将整个磁盘（所有分区 + 数据）打包为单个镜像文件，支持完整灾难恢复
|
||||
- [[NFS 网络存储]]：Network File System，Linux 原生网络文件系统，NAS 共享的标准协议
|
||||
- [[ISOHybrid 镜像]]：同时支持 ISO 和 DD 两种写入模式的混合镜像，Rufus 写入时需注意模式选择
|
||||
- [[GPT vs MBR]]：新一代分区表格式（GPT） vs 传统格式，UEFI 启动需要 GPT 分区
|
||||
|
||||
## Key Entities
|
||||
- [[Clonezilla]]：开源磁盘镜像工具（再生龙），支持保存和还原整块磁盘镜像
|
||||
- [[Rufus]]：Windows U 盘启动盘制作工具，用于将 Clonezilla ISO 写入 U 盘
|
||||
- [[Ubuntu Server]]：目标备份操作系统，HP ZBook 工作站上运行的服务器版本
|
||||
- [[NFS]]：Network File System，用于将 NAS 存储挂载到 Clonezilla 进行镜像存储
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu服务器通过rsync实现日常增量备份]] ← 互补方案 ← [[Clonezilla全盘镜像备份]]
|
||||
- Clonezilla 提供全量快照（低频），rsync 提供增量同步（高频），两者构成完整备份策略
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] ← 依赖 ← [[Ubuntu Server]]
|
||||
- Ubuntu Server 是家庭监控系统的运行平台，其备份直接关系到监控系统可用性
|
||||
- [[NFS]] ← 存储后端 ← [[Clonezilla全盘镜像备份]]
|
||||
- NAS 通过 NFS 协议提供镜像存储空间
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Ubuntu服务器通过rsync实现日常增量备份]] 方法层面：
|
||||
- 冲突点：rsync 是文件级增量备份，Clonezilla 是磁盘级全量镜像
|
||||
- 当前观点：两者互补而非互斥——Clonezilla 做周期性全量快照（如每月），rsync 做每日增量同步
|
||||
- 对方观点：rsync 更适合不停机的日常备份场景，Clonezilla 更适合系统迁移或重大变更前的快照
|
||||
---
|
||||
title: "Clonezilla对Ubuntu Server进行全盘镜像备份"
|
||||
type: source
|
||||
tags: [backup, clonezilla, nas, rufus, ubuntu]
|
||||
date: 2026-05-06
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/Clonezilla对Ubuntu Server进行全盘镜像备份]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：使用 Clonezilla（再生龙）对 Ubuntu Server 进行全盘镜像备份到 NAS，灾难时可完整还原系统
|
||||
- 问题域：Linux 服务器数据保护、灾难恢复（DR）、NAS 存储集成
|
||||
- 方法/机制：Clonezilla live USB 启动 → device-image 模式 → NFS 网络存储挂载 → savedisk 全盘镜像 → restordisk 还原
|
||||
- 结论/价值：Clonezilla 提供类似 Ghost 的磁盘级镜像能力，是 rsync 增量备份之外的全量快照方案，两者互补构成完整备份策略
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Rufus 写入 Clonezilla ISO 时必须选择"ISO 镜像模式"，否则可能导致 U 盘启动失败
|
||||
- 针对较新笔记本，分区方案应选 GPT + UEFI（非 CSM）；老旧笔记本选 MBR + BIOS
|
||||
- NFS 是 NAS 备份场景下兼容性最好的网络协议，相比 SMB 更适合 Linux 环境
|
||||
- Clonezilla 备份完成后，新硬盘可通过 restoredisk 完整还原，系统即刻复活，无需重装
|
||||
|
||||
## Key Quotes
|
||||
> "Clonezilla live (Default settings, VGA 800x600)" — Clonezilla 启动菜单推荐选项，英文界面更稳定
|
||||
> "以 ISO 镜像模式写入 (推荐)" — Rufus 写入 ISOHybrid 镜像时的关键选择，DD 模式仅作备选
|
||||
|
||||
## Key Concepts
|
||||
- [[全盘镜像备份]]：将整个磁盘（所有分区 + 数据）打包为单个镜像文件，支持完整灾难恢复
|
||||
- [[NFS 网络存储]]：Network File System，Linux 原生网络文件系统，NAS 共享的标准协议
|
||||
- [[ISOHybrid 镜像]]：同时支持 ISO 和 DD 两种写入模式的混合镜像，Rufus 写入时需注意模式选择
|
||||
- [[GPT vs MBR]]：新一代分区表格式（GPT） vs 传统格式，UEFI 启动需要 GPT 分区
|
||||
|
||||
## Key Entities
|
||||
- [[Clonezilla]]：开源磁盘镜像工具（再生龙），支持保存和还原整块磁盘镜像
|
||||
- [[Rufus]]：Windows U 盘启动盘制作工具，用于将 Clonezilla ISO 写入 U 盘
|
||||
- [[Ubuntu Server]]：目标备份操作系统，HP ZBook 工作站上运行的服务器版本
|
||||
- [[NFS]]：Network File System，用于将 NAS 存储挂载到 Clonezilla 进行镜像存储
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu服务器通过rsync实现日常增量备份]] ← 互补方案 ← [[Clonezilla全盘镜像备份]]
|
||||
- Clonezilla 提供全量快照（低频），rsync 提供增量同步（高频），两者构成完整备份策略
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] ← 依赖 ← [[Ubuntu Server]]
|
||||
- Ubuntu Server 是家庭监控系统的运行平台，其备份直接关系到监控系统可用性
|
||||
- [[NFS]] ← 存储后端 ← [[Clonezilla全盘镜像备份]]
|
||||
- NAS 通过 NFS 协议提供镜像存储空间
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Ubuntu服务器通过rsync实现日常增量备份]] 方法层面：
|
||||
- 冲突点：rsync 是文件级增量备份，Clonezilla 是磁盘级全量镜像
|
||||
- 当前观点：两者互补而非互斥——Clonezilla 做周期性全量快照（如每月），rsync 做每日增量同步
|
||||
- 对方观点：rsync 更适合不停机的日常备份场景，Clonezilla 更适合系统迁移或重大变更前的快照
|
||||
|
||||
@@ -1,49 +1,49 @@
|
||||
---
|
||||
title: "Cloud DevOp Maturity - Guideline"
|
||||
type: source
|
||||
tags: [cloud, devops, maturity, enterprise, saas]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Cloud DevOp Maturity - Guideline.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：企业级 SaaS 公司的云 DevOps 成熟度评估框架与提升路径
|
||||
- 问题域：如何定义、衡量和提升云端 DevOps 实践的成熟度
|
||||
- 方法/机制：基于 DORA 四大指标（部署频率、变更前置时间、变更失败率、平均恢复时间）和 CMMI 成熟度模型，从自动化、协作文化、监控可观测性、安全集成四大支柱进行评估
|
||||
- 结论/价值：DevOps 成熟度提升是持续迭代过程，需分阶段实施，从 CI/CD 和自动化入手，逐步建立 DevOps 卓越中心
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 企业通过评估 DevOps 成熟度，可缩短上市时间、提升运营效率并增强产品可靠性
|
||||
- DORA 四项核心指标（部署频率、变更前置时间、变更失败率、MTTR）是衡量 DevOps 绩效的行业标准
|
||||
- 成熟的 DevOps 组织需在自动化（CI/CD、IaC、测试自动化）、跨团队协作与文化、监控可观测性、安全集成（DevSecOps）四大支柱上均衡发展
|
||||
- 云原生架构（微服务、容器化、无服务器技术）可加速 DevOps 成熟度提升
|
||||
- DevOps 成熟度提升路径包括：进行成熟度评估 → 建立 DevOps 卓越中心 → 分阶段实施改进（从 CI/CD 和自动化开始）→ 持续迭代
|
||||
|
||||
## Key Quotes
|
||||
> "Focus on CI/CD pipelines, infrastructure as code (IaC), and test automation. Emphasize the importance of repeatable and reliable deployments." — 自动化是成熟 DevOps 的基石
|
||||
> "DevOps is a continuous improvement process, and even mature companies need to adapt to evolving technologies and practices." — DevOps 成熟度提升是持续迭代过程
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOpsMaturityModel]]：CMMI 和 DORA 模型定义的组织 DevOps 能力成熟度等级体系
|
||||
- [[DORAMetrics]]：DevOps Research & Assessment 的四大核心指标——部署频率、变更前置时间、变更失败率、平均恢复时间（MTTR）
|
||||
- [[CI/CDPipeline]]：持续集成/持续交付流水线，DevOps 自动化的核心机制
|
||||
- [[InfrastructureAsCode]]：通过代码管理基础设施，实现环境一致性和可重复部署
|
||||
- [[DevSecOps]]：将安全集成到 DevOps 全生命周期，实现持续安全合规
|
||||
- [[MicroservicesArchitecture]]：云原生微服务架构，支持独立部署和快速迭代
|
||||
- [[Observability]]：可观测性，通过持续监控、日志和追踪快速发现和解决生产问题
|
||||
|
||||
## Key Entities
|
||||
- [[CMMI]]：Capability Maturity Model Integration，能力成熟度模型集成，用于定义组织过程改进的成熟度等级
|
||||
- [[DORA]]：DevOps Research & Assessment，DevOps 研究与评估组织，提供行业标准的 DevOps 绩效指标
|
||||
|
||||
## Connections
|
||||
- [[DevOpsMaturityModel]] ← based_on ← [[DORAMetrics]]
|
||||
- [[CI/CDPipeline]] ← core_enabler ← [[DevOpsMaturityModel]]
|
||||
- [[InfrastructureAsCode]] ← supports ← [[CI/CDPipeline]]
|
||||
- [[DevSecOps]] ← extends ← [[DevOpsMaturityModel]]
|
||||
- [[MicroservicesArchitecture]] ← architectural_pattern ← [[CloudNativePractices]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无已知的 Wiki 内冲突内容
|
||||
---
|
||||
title: "Cloud DevOp Maturity - Guideline"
|
||||
type: source
|
||||
tags: [cloud, devops, maturity, enterprise, saas]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Cloud DevOp Maturity - Guideline.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：企业级 SaaS 公司的云 DevOps 成熟度评估框架与提升路径
|
||||
- 问题域：如何定义、衡量和提升云端 DevOps 实践的成熟度
|
||||
- 方法/机制：基于 DORA 四大指标（部署频率、变更前置时间、变更失败率、平均恢复时间）和 CMMI 成熟度模型，从自动化、协作文化、监控可观测性、安全集成四大支柱进行评估
|
||||
- 结论/价值：DevOps 成熟度提升是持续迭代过程，需分阶段实施，从 CI/CD 和自动化入手，逐步建立 DevOps 卓越中心
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 企业通过评估 DevOps 成熟度，可缩短上市时间、提升运营效率并增强产品可靠性
|
||||
- DORA 四项核心指标（部署频率、变更前置时间、变更失败率、MTTR）是衡量 DevOps 绩效的行业标准
|
||||
- 成熟的 DevOps 组织需在自动化（CI/CD、IaC、测试自动化）、跨团队协作与文化、监控可观测性、安全集成（DevSecOps）四大支柱上均衡发展
|
||||
- 云原生架构（微服务、容器化、无服务器技术）可加速 DevOps 成熟度提升
|
||||
- DevOps 成熟度提升路径包括：进行成熟度评估 → 建立 DevOps 卓越中心 → 分阶段实施改进（从 CI/CD 和自动化开始）→ 持续迭代
|
||||
|
||||
## Key Quotes
|
||||
> "Focus on CI/CD pipelines, infrastructure as code (IaC), and test automation. Emphasize the importance of repeatable and reliable deployments." — 自动化是成熟 DevOps 的基石
|
||||
> "DevOps is a continuous improvement process, and even mature companies need to adapt to evolving technologies and practices." — DevOps 成熟度提升是持续迭代过程
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOpsMaturityModel]]：CMMI 和 DORA 模型定义的组织 DevOps 能力成熟度等级体系
|
||||
- [[DORAMetrics]]：DevOps Research & Assessment 的四大核心指标——部署频率、变更前置时间、变更失败率、平均恢复时间（MTTR）
|
||||
- [[CI/CDPipeline]]：持续集成/持续交付流水线，DevOps 自动化的核心机制
|
||||
- [[InfrastructureAsCode]]：通过代码管理基础设施，实现环境一致性和可重复部署
|
||||
- [[DevSecOps]]：将安全集成到 DevOps 全生命周期，实现持续安全合规
|
||||
- [[MicroservicesArchitecture]]：云原生微服务架构，支持独立部署和快速迭代
|
||||
- [[Observability]]：可观测性，通过持续监控、日志和追踪快速发现和解决生产问题
|
||||
|
||||
## Key Entities
|
||||
- [[CMMI]]：Capability Maturity Model Integration，能力成熟度模型集成，用于定义组织过程改进的成熟度等级
|
||||
- [[DORA]]：DevOps Research & Assessment，DevOps 研究与评估组织，提供行业标准的 DevOps 绩效指标
|
||||
|
||||
## Connections
|
||||
- [[DevOpsMaturityModel]] ← based_on ← [[DORAMetrics]]
|
||||
- [[CI/CDPipeline]] ← core_enabler ← [[DevOpsMaturityModel]]
|
||||
- [[InfrastructureAsCode]] ← supports ← [[CI/CDPipeline]]
|
||||
- [[DevSecOps]] ← extends ← [[DevOpsMaturityModel]]
|
||||
- [[MicroservicesArchitecture]] ← architectural_pattern ← [[CloudNativePractices]]
|
||||
|
||||
## Contradictions
|
||||
- 暂无已知的 Wiki 内冲突内容
|
||||
|
||||
@@ -1,84 +1,84 @@
|
||||
---
|
||||
title: "Cloud Maturity Model - A Detailed Guide For Cloud Adoption"
|
||||
type: source
|
||||
tags: [Cloud, Cloud Adoption, Maturity Model, CMM, Cloud Native, CSMM, SAMM, AWS CAF, Azure CAF, GCP CAF]
|
||||
date: 2024-07-08
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Cloud Maturity Model A Detailed Guide For Cloud Adoption.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
|
||||
- **核心主题**：Cloud Maturity Model（CMM）云成熟度模型——系统性评估企业云采用成熟度并指导其向更高阶段演进的结构化框架
|
||||
- **问题域**：企业云转型过程中，如何评估当前状态、识别差距、制定演进路线
|
||||
- **方法/机制**：5级成熟度模型（Level 0–5）从业务维度（财务/战略/组织/文化/治理/合规/采购）和技术维度（架构/应用/DevOps/安全/IaaS/PaaS/SaaS/AI/IoT）进行三维评估（People/Processes/Technology）；7大收益；最佳实践；7种主流成熟度模型对比
|
||||
- **结论/价值**：CMM 是云转型成功的导航仪，帮助企业找到适合自身需求的平衡点，避免盲目追高或止步不前
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
|
||||
- Forrester 预测全球云成熟度模型行业到 2025 年将达 15 亿美元，反映企业云成熟度管理的巨大市场需求
|
||||
- Gartner 指出超过 60% 的组织正在积极实施云成熟度模型，说明其已成为云转型主流实践
|
||||
- Open Alliance for Cloud Adoption（OACA）定义的 CMM 帮助组织识别云采用痛点、评估当前状态、设定未来目标并执行 GAP 分析
|
||||
- 云成熟度模型不是追求完全上云，而是找到适合组织需求的平衡点
|
||||
- Level 5 是目标但往往更具理想性，建议选择性采纳带来明确业务价值的要素，避免跨越低级别导致后续挑战
|
||||
- 跨越低级别（如管理和流程定义）可能导致后续成熟度旅程中的挑战和不必要的成本
|
||||
|
||||
## Key Quotes
|
||||
|
||||
> "CMMs are crucial because they offer a structured approach to assessing your current cloud adoption strategy. They help you avoid common pitfalls and identify areas of improvement." — CMM 的核心价值定位
|
||||
|
||||
> "It is common for organizations only partially to reach level 4. Some parts of their cloud capabilities may still be at levels 2 or 3." — Level 4 部分成熟现象
|
||||
|
||||
> "Achieving this fifth level is often more aspirational than real for many." — Level 5 的理想与现实差距
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[Cloud Adoption]]：云采用——组织将工作负载和服务迁移至云平台并持续优化的过程
|
||||
- [[Cloud Migration]]：云迁移——将应用/数据/工作负载从本地迁移至云端的具体行动
|
||||
- [[Cloud Governance]]：云治理——建立云环境中的策略、角色、风险管理框架
|
||||
- [[Cloud Security]]：云安全——云环境中的数据保护、访问控制、合规遵循
|
||||
- [[FinOps]]：云财务管理——云资源使用的成本优化与财务可见性管理
|
||||
- [[Cloud-Native]]：云原生——充分利用云平台弹性、可扩展、自动化特性的架构方法
|
||||
- [[Cloud Cost Optimization]]：云成本优化——通过右置资源、自动化、监控实现云支出效率最大化
|
||||
- [[Multi-Cloud Strategy]]：多云策略——同时使用多个云服务商以避免供应商锁定
|
||||
- [[Hybrid Cloud]]：混合云——结合公有云弹性与私有云合规/安全的混合部署模式
|
||||
- [[People-Process-Technology]]：人-流程-技术三维评估框架——评估组织云成熟度的三个核心维度
|
||||
- [[Cloud Center of Excellence]]（CCoE）：云卓越中心——推动组织云能力的跨职能专家团队
|
||||
- [[GAP Analysis]]：差距分析——评估当前状态与目标状态之间差距的系统性方法
|
||||
- [[Cloud Compliance]]：云合规——确保云操作符合 HIPAA/PCI-DSS 等行业法规
|
||||
- [[CAPEX vs OPEX]]：资本支出 vs 运营支出——云迁移带来的财务模式转变
|
||||
- [[TCO (Total Cost of Ownership)]]：总拥有成本——包含直接成本、间接成本、隐性成本的全成本视角
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[Cloud Maturity Model]]：主体框架——5级成熟度评估模型
|
||||
- [[Cloud Native Maturity Model]]：CNCF 云原生成熟度模型——指导云原生技术采用的专项模型
|
||||
- [[Cloud Security Maturity Model]]（CSMM）：云安全成熟度模型——IANS/Securosis 的云安全评估框架
|
||||
- [[Software Assurance Maturity Model]]（SAMM）：软件保障成熟度模型——覆盖完整软件生命周期的技术/流程中立框架
|
||||
- [[AWS Cloud Adoption Framework]]（AWS CAF）：AWS 云采用框架——AWS 提供的云转型指导
|
||||
- [[Azure Cloud Adoption Framework]]（Azure CAF）：Azure 云采用框架——Microsoft Azure 提供的云转型最佳实践
|
||||
- [[Google Cloud Adoption Framework]]（GCP CAF）：Google Cloud 云采用框架——Google Cloud 的云转型路线
|
||||
- [[Open Alliance for Cloud Adoption]]（OACA）：云采用联盟——定义 CMM 的行业组织
|
||||
- [[Cloud Maturity Levels]]：成熟度5级——Level 0（Legacy）→ Level 5（Optimized）
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Cloud Maturity Model]] ← evaluates ← [[Cloud Adoption Strategy]]
|
||||
- [[Cloud Maturity Model]] ← defined_by ← [[Open Alliance for Cloud Adoption]]
|
||||
- [[Cloud Maturity Levels]] ← part_of ← [[Cloud Maturity Model]]
|
||||
- [[Cloud Native Maturity Model]] ← extends ← [[Cloud Maturity Model]]（专项领域扩展）
|
||||
- [[Cloud Security Maturity Model]] ← extends ← [[Cloud Maturity Model]]（安全专项）
|
||||
- [[AWS Cloud Adoption Framework]] ← competes_with ← [[Azure Cloud Adoption Framework]]
|
||||
- [[AWS Cloud Adoption Framework]] ← competes_with ← [[Google Cloud Adoption Framework]]
|
||||
- [[Cloud Cost Optimization]] ← enables ← [[FinOps]]
|
||||
- [[Cloud Governance]] ← depends_on ← [[Cloud Compliance]]
|
||||
- [[DevOps Maturity Model]] ← related_to ← [[Cloud Maturity Model]]（两者均评估组织技术能力成熟度）
|
||||
|
||||
## Contradictions
|
||||
|
||||
- 与 [[DevOps Maturity Model]] 在"成熟度框架"上的视角差异：
|
||||
- 冲突点：DevOps 成熟度聚焦研发交付能力，CMM 聚焦云采用整体成熟度
|
||||
- 当前观点（本文）：CMM 是云转型的全面导航，覆盖人员/流程/技术全维度
|
||||
- 对方观点（DevOps）：DevOps 成熟度更聚焦软件交付速度和稳定性
|
||||
- 说明：两者为互补关系而非互斥，组织可同时评估和提升两个维度的成熟度
|
||||
---
|
||||
title: "Cloud Maturity Model - A Detailed Guide For Cloud Adoption"
|
||||
type: source
|
||||
tags: [Cloud, Cloud Adoption, Maturity Model, CMM, Cloud Native, CSMM, SAMM, AWS CAF, Azure CAF, GCP CAF]
|
||||
date: 2024-07-08
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Cloud Maturity Model A Detailed Guide For Cloud Adoption.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
|
||||
- **核心主题**：Cloud Maturity Model（CMM）云成熟度模型——系统性评估企业云采用成熟度并指导其向更高阶段演进的结构化框架
|
||||
- **问题域**：企业云转型过程中，如何评估当前状态、识别差距、制定演进路线
|
||||
- **方法/机制**：5级成熟度模型（Level 0–5）从业务维度（财务/战略/组织/文化/治理/合规/采购）和技术维度（架构/应用/DevOps/安全/IaaS/PaaS/SaaS/AI/IoT）进行三维评估（People/Processes/Technology）；7大收益；最佳实践；7种主流成熟度模型对比
|
||||
- **结论/价值**：CMM 是云转型成功的导航仪，帮助企业找到适合自身需求的平衡点，避免盲目追高或止步不前
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
|
||||
- Forrester 预测全球云成熟度模型行业到 2025 年将达 15 亿美元，反映企业云成熟度管理的巨大市场需求
|
||||
- Gartner 指出超过 60% 的组织正在积极实施云成熟度模型，说明其已成为云转型主流实践
|
||||
- Open Alliance for Cloud Adoption（OACA）定义的 CMM 帮助组织识别云采用痛点、评估当前状态、设定未来目标并执行 GAP 分析
|
||||
- 云成熟度模型不是追求完全上云，而是找到适合组织需求的平衡点
|
||||
- Level 5 是目标但往往更具理想性，建议选择性采纳带来明确业务价值的要素，避免跨越低级别导致后续挑战
|
||||
- 跨越低级别（如管理和流程定义）可能导致后续成熟度旅程中的挑战和不必要的成本
|
||||
|
||||
## Key Quotes
|
||||
|
||||
> "CMMs are crucial because they offer a structured approach to assessing your current cloud adoption strategy. They help you avoid common pitfalls and identify areas of improvement." — CMM 的核心价值定位
|
||||
|
||||
> "It is common for organizations only partially to reach level 4. Some parts of their cloud capabilities may still be at levels 2 or 3." — Level 4 部分成熟现象
|
||||
|
||||
> "Achieving this fifth level is often more aspirational than real for many." — Level 5 的理想与现实差距
|
||||
|
||||
## Key Concepts
|
||||
|
||||
- [[Cloud Adoption]]：云采用——组织将工作负载和服务迁移至云平台并持续优化的过程
|
||||
- [[Cloud Migration]]：云迁移——将应用/数据/工作负载从本地迁移至云端的具体行动
|
||||
- [[Cloud Governance]]：云治理——建立云环境中的策略、角色、风险管理框架
|
||||
- [[Cloud Security]]：云安全——云环境中的数据保护、访问控制、合规遵循
|
||||
- [[FinOps]]：云财务管理——云资源使用的成本优化与财务可见性管理
|
||||
- [[Cloud-Native]]：云原生——充分利用云平台弹性、可扩展、自动化特性的架构方法
|
||||
- [[Cloud Cost Optimization]]：云成本优化——通过右置资源、自动化、监控实现云支出效率最大化
|
||||
- [[Multi-Cloud Strategy]]：多云策略——同时使用多个云服务商以避免供应商锁定
|
||||
- [[Hybrid Cloud]]：混合云——结合公有云弹性与私有云合规/安全的混合部署模式
|
||||
- [[People-Process-Technology]]：人-流程-技术三维评估框架——评估组织云成熟度的三个核心维度
|
||||
- [[Cloud Center of Excellence]]（CCoE）：云卓越中心——推动组织云能力的跨职能专家团队
|
||||
- [[GAP Analysis]]：差距分析——评估当前状态与目标状态之间差距的系统性方法
|
||||
- [[Cloud Compliance]]：云合规——确保云操作符合 HIPAA/PCI-DSS 等行业法规
|
||||
- [[CAPEX vs OPEX]]：资本支出 vs 运营支出——云迁移带来的财务模式转变
|
||||
- [[TCO (Total Cost of Ownership)]]：总拥有成本——包含直接成本、间接成本、隐性成本的全成本视角
|
||||
|
||||
## Key Entities
|
||||
|
||||
- [[Cloud Maturity Model]]：主体框架——5级成熟度评估模型
|
||||
- [[Cloud Native Maturity Model]]：CNCF 云原生成熟度模型——指导云原生技术采用的专项模型
|
||||
- [[Cloud Security Maturity Model]]（CSMM）：云安全成熟度模型——IANS/Securosis 的云安全评估框架
|
||||
- [[Software Assurance Maturity Model]]（SAMM）：软件保障成熟度模型——覆盖完整软件生命周期的技术/流程中立框架
|
||||
- [[AWS Cloud Adoption Framework]]（AWS CAF）：AWS 云采用框架——AWS 提供的云转型指导
|
||||
- [[Azure Cloud Adoption Framework]]（Azure CAF）：Azure 云采用框架——Microsoft Azure 提供的云转型最佳实践
|
||||
- [[Google Cloud Adoption Framework]]（GCP CAF）：Google Cloud 云采用框架——Google Cloud 的云转型路线
|
||||
- [[Open Alliance for Cloud Adoption]]（OACA）：云采用联盟——定义 CMM 的行业组织
|
||||
- [[Cloud Maturity Levels]]：成熟度5级——Level 0（Legacy）→ Level 5（Optimized）
|
||||
|
||||
## Connections
|
||||
|
||||
- [[Cloud Maturity Model]] ← evaluates ← [[Cloud Adoption Strategy]]
|
||||
- [[Cloud Maturity Model]] ← defined_by ← [[Open Alliance for Cloud Adoption]]
|
||||
- [[Cloud Maturity Levels]] ← part_of ← [[Cloud Maturity Model]]
|
||||
- [[Cloud Native Maturity Model]] ← extends ← [[Cloud Maturity Model]]（专项领域扩展）
|
||||
- [[Cloud Security Maturity Model]] ← extends ← [[Cloud Maturity Model]]（安全专项）
|
||||
- [[AWS Cloud Adoption Framework]] ← competes_with ← [[Azure Cloud Adoption Framework]]
|
||||
- [[AWS Cloud Adoption Framework]] ← competes_with ← [[Google Cloud Adoption Framework]]
|
||||
- [[Cloud Cost Optimization]] ← enables ← [[FinOps]]
|
||||
- [[Cloud Governance]] ← depends_on ← [[Cloud Compliance]]
|
||||
- [[DevOps Maturity Model]] ← related_to ← [[Cloud Maturity Model]]（两者均评估组织技术能力成熟度）
|
||||
|
||||
## Contradictions
|
||||
|
||||
- 与 [[DevOps Maturity Model]] 在"成熟度框架"上的视角差异：
|
||||
- 冲突点：DevOps 成熟度聚焦研发交付能力，CMM 聚焦云采用整体成熟度
|
||||
- 当前观点（本文）：CMM 是云转型的全面导航，覆盖人员/流程/技术全维度
|
||||
- 对方观点（DevOps）：DevOps 成熟度更聚焦软件交付速度和稳定性
|
||||
- 说明：两者为互补关系而非互斥，组织可同时评估和提升两个维度的成熟度
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: "Cursor 2.0初学者使用指南"
|
||||
type: source
|
||||
tags: [ai, cursor, ide, mcp]
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/Cursor 2.0初学者使用指南]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Cursor 2.0 AI代码编辑器的初学者完整使用教程，涵盖安装、界面、多代理操作、代码生成、审查与版本控制流程。
|
||||
- 问题域：AI辅助编程工具的入门学习，聚焦于如何高效使用Cursor的AI代理功能进行项目开发。
|
||||
- 方法/机制：通过Plan模式规划任务 → Agent模式执行代码生成 → Diff审查改动 → Git版本控制回滚的完整工作流。
|
||||
- 结论/价值：Cursor 2.0为开发者提供了一条从想法到实现的AI智能化路径，是现代AI辅助编程的重要工具。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Cursor基于VS Code构建，可免费使用，支持付费升级获取更多生成额度。
|
||||
- Cursor新增自有AI模型Composer，强调其速度优势（比同类模型快4倍）。
|
||||
- 多代理功能可以同时运行不同任务，互不干扰，提升代码生成效率。
|
||||
- AI代理支持三种模式：Plan（规划）、Agent（执行，会修改文件）、Ask（咨询，不改代码）。
|
||||
- 代码生成后进入待审查状态，可使用Diff功能逐个审查或整体接收改动。
|
||||
- MCP（Model Context Protocol）支持将外部工具和服务集成到AI代理，扩展功能范围。
|
||||
- 可设定项目规则（如强制为函数生成文档注释），实现代码规范自动化。
|
||||
|
||||
## Key Quotes
|
||||
> "Cursor是基于VS Code的AI代码编辑器，可免费使用，支持付费升级以获取更多生成额度。" — Cursor基本特性介绍
|
||||
> "启动构建任务时生成新代理，执行计划步骤。多代理功能可以同时运行不同任务，互不干扰。" — 多代理并行操作
|
||||
> "生成代码后进入待审查状态，可使用Diff功能查看具体改动，支持文件逐个审查或整体接收。" — 代码审查流程
|
||||
> "MCP（Model Context Protocol）支持将外部工具和服务集成到AI代理，扩展功能范围。" — MCP扩展能力
|
||||
|
||||
## Key Concepts
|
||||
- [[多代理并行]]：可同时运行不同AI代理任务，互不干扰，适合多线程项目开发。
|
||||
- [[Diff审查]]：通过Diff视图查看AI生成的代码改动，逐个文件或整体接收变更。
|
||||
- [[项目规则]]：自定义项目规则文件（如强制生成文档注释），实现代码规范自动化。
|
||||
- [[MCP服务器]]：Model Context Protocol，支持将外部API和工具集成到AI代理。
|
||||
|
||||
## Key Entities
|
||||
- [[Cursor]]：基于VS Code的AI增强代码编辑器，支持多代理并行操作和Composer自研模型。
|
||||
- [[VS Code]]：Cursor构建的基础编辑器，Cursor继承其完整功能。
|
||||
- [[Composer]]：Cursor自研AI模型，主打生成速度优势（比同类快4倍）。
|
||||
|
||||
## Connections
|
||||
- [[Cursor]] ← extends ← [[VS Code]]
|
||||
- [[Cursor]] ← uses ← [[Composer]]
|
||||
- [[Cursor]] ← supports ← [[MCP（Model Context Protocol）]]
|
||||
- [[Cursor]] ← enables ← [[Vibe Coding]]
|
||||
- [[Cursor]] ← similar_to ← [[Claude Code]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突。本文档聚焦Cursor入门操作，与 [[MCP在Cursor中的集成与应用详解]] 互补（后者侧重MCP集成深度应用）。
|
||||
---
|
||||
title: "Cursor 2.0初学者使用指南"
|
||||
type: source
|
||||
tags: [ai, cursor, ide, mcp]
|
||||
date: 2026-04-22
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/Cursor 2.0初学者使用指南]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Cursor 2.0 AI代码编辑器的初学者完整使用教程，涵盖安装、界面、多代理操作、代码生成、审查与版本控制流程。
|
||||
- 问题域：AI辅助编程工具的入门学习，聚焦于如何高效使用Cursor的AI代理功能进行项目开发。
|
||||
- 方法/机制：通过Plan模式规划任务 → Agent模式执行代码生成 → Diff审查改动 → Git版本控制回滚的完整工作流。
|
||||
- 结论/价值：Cursor 2.0为开发者提供了一条从想法到实现的AI智能化路径，是现代AI辅助编程的重要工具。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Cursor基于VS Code构建，可免费使用，支持付费升级获取更多生成额度。
|
||||
- Cursor新增自有AI模型Composer，强调其速度优势（比同类模型快4倍）。
|
||||
- 多代理功能可以同时运行不同任务，互不干扰，提升代码生成效率。
|
||||
- AI代理支持三种模式：Plan（规划）、Agent（执行，会修改文件）、Ask（咨询，不改代码）。
|
||||
- 代码生成后进入待审查状态，可使用Diff功能逐个审查或整体接收改动。
|
||||
- MCP（Model Context Protocol）支持将外部工具和服务集成到AI代理，扩展功能范围。
|
||||
- 可设定项目规则（如强制为函数生成文档注释），实现代码规范自动化。
|
||||
|
||||
## Key Quotes
|
||||
> "Cursor是基于VS Code的AI代码编辑器，可免费使用，支持付费升级以获取更多生成额度。" — Cursor基本特性介绍
|
||||
> "启动构建任务时生成新代理，执行计划步骤。多代理功能可以同时运行不同任务，互不干扰。" — 多代理并行操作
|
||||
> "生成代码后进入待审查状态，可使用Diff功能查看具体改动，支持文件逐个审查或整体接收。" — 代码审查流程
|
||||
> "MCP（Model Context Protocol）支持将外部工具和服务集成到AI代理，扩展功能范围。" — MCP扩展能力
|
||||
|
||||
## Key Concepts
|
||||
- [[多代理并行]]：可同时运行不同AI代理任务，互不干扰，适合多线程项目开发。
|
||||
- [[Diff审查]]：通过Diff视图查看AI生成的代码改动，逐个文件或整体接收变更。
|
||||
- [[项目规则]]：自定义项目规则文件（如强制生成文档注释），实现代码规范自动化。
|
||||
- [[MCP服务器]]：Model Context Protocol，支持将外部API和工具集成到AI代理。
|
||||
|
||||
## Key Entities
|
||||
- [[Cursor]]：基于VS Code的AI增强代码编辑器，支持多代理并行操作和Composer自研模型。
|
||||
- [[VS Code]]：Cursor构建的基础编辑器，Cursor继承其完整功能。
|
||||
- [[Composer]]：Cursor自研AI模型，主打生成速度优势（比同类快4倍）。
|
||||
|
||||
## Connections
|
||||
- [[Cursor]] ← extends ← [[VS Code]]
|
||||
- [[Cursor]] ← uses ← [[Composer]]
|
||||
- [[Cursor]] ← supports ← [[MCP（Model Context Protocol）]]
|
||||
- [[Cursor]] ← enables ← [[Vibe Coding]]
|
||||
- [[Cursor]] ← similar_to ← [[Claude Code]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突。本文档聚焦Cursor入门操作，与 [[MCP在Cursor中的集成与应用详解]] 互补（后者侧重MCP集成深度应用）。
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: "DevOps Culture and Transformation: Fostering Collaboration, Agile Practices, and Innovation"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-03-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/DevOps Culture and Transformation Fostering Collaboration, Agile Practices, and Innovation LinkedIn]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：DevOps 文化转型 —— 如何通过打破开发与运维之间的壁垒，推动组织实现更快、更可靠的软件交付与持续创新。
|
||||
- 问题域：传统 IT 组织中开发团队与运维团队的目标冲突（开发追求快速交付，运维追求稳定），以及组织文化变革的挑战。
|
||||
- 方法/机制：四大 DevOps 文化支柱（协作、自动化、持续改进、客户导向）；Agile 与 DevOps 的融合实践；战略转型 playbook（领导层支持、团队赋能、小步试点、克服阻力）。
|
||||
- 结论/价值：DevOps 不仅是工具和自动化，而是一场文化变革；拥抱 DevOps 文化 tenets、赋能团队、整合 Agile 实践的组织将在数字时代获得竞争优势。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- DevOps 通过建立跨职能团队，使开发和运维共同承担整个软件生命周期的责任，从而打破传统 IT 组织中的孤岛现象。
|
||||
- 自动化（CI/CD 流水线、基础设施即代码、可观测性工具）是 DevOps 的核心驱动力，能消除人工重复劳动、减少错误、加速反馈循环。
|
||||
- DevOps 强调持续改进（Kaizen），通过无责事后分析（blameless post-mortems）、数据指标和混沌工程驱动团队迭代学习。
|
||||
- Agile 与 DevOps 具有共生关系 —— Agile 关注迭代开发，DevOps 将敏捷延伸到运维，两者共同实现端到端的速度与质量。
|
||||
- DevOps 转型需要领导层支持、小步试点快速验证、用成功案例建立势能，而非一次性大爆炸式推行。
|
||||
- DevOps 的未来趋势包括：AI/ML 赋能智能自动化、GitOps、Serverless DevOps、边缘计算与 IoT DevOps、以及 DevSecOps 的深化。
|
||||
|
||||
## Key Quotes
|
||||
> "DevOps isn't just about tools or automation; it's a mindset shift that prioritizes collaboration, continuous learning, and customer-centricity." — 核心论点：DevOps 本质是文化与思维转变
|
||||
> "Blameless post-mortems to dissect failures without finger-pointing." — DevOps 文化的关键实践：无惧失败、聚焦改进
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps Culture]]：一种打破开发与运维壁垒、以协作、自动化、持续学习和客户导向为核心的文化与运营模式
|
||||
- [[CI/CD Pipeline]]：自动化测试、集成和部署流水线，是 DevOps 自动化能力的关键实现
|
||||
- [[Infrastructure as Code (IaC)]]：通过代码管理基础设施，实现一致性和版本控制的实践
|
||||
- [[Kaizen (Continuous Improvement)]]：持续改进理念，通过无责复盘、数据驱动决策和混沌工程推动迭代优化
|
||||
- [[Shift-Left]]：将安全、性能等运维关注点前移至开发阶段，DevSecOps 是其典型实践
|
||||
- [[Value Stream Mapping]]：价值流图析，通过可视化工作流识别等待、审批和测试环节的延迟，消除浪费
|
||||
- [[GitOps]]：使用 Git 作为唯一真实来源来管理基础设施和部署的运维模式，是 DevOps 的进化方向之一
|
||||
- [[Serverless DevOps]]：利用函数即服务（FaaS）等无服务器技术减少运维负担的 DevOps 实践
|
||||
- [[Agile-DevOps Integration]]：Agile 与 DevOps 的协同机制，Scrum/Kanban 提供方法论框架，CI/CD 提供工程加速能力
|
||||
|
||||
## Key Entities
|
||||
- [[Hemant Sawant]]：LinkedIn 文章原作者，DevOps 文化与转型领域的分享者
|
||||
- [[Shenwei]]：本文档的保存整理者
|
||||
|
||||
## Connections
|
||||
- [[DevOps Maturity Model]] ← extends ← [[DevOps Culture]]：本文聚焦 DevOps 文化转型，与成熟度模型互为补充（文化层 vs 能力层级）
|
||||
- [[DevSecOps Best Practices]] ← depends_on ← [[DevOps Culture]]：DevSecOps 是 DevOps 文化中"安全性嵌入"支柱的具体实现
|
||||
- [[Agile-DevOps Integration]] ← extends ← [[DevOps Culture]]：Agile 与 DevOps 的融合是本文第二大主题
|
||||
- [[How Agentic AI Can Help Cloud DevOps]] ← relates_to ← [[DevOps Culture]]：AI/ML 赋能 DevOps 是本文未来趋势之一
|
||||
|
||||
## Contradictions
|
||||
- （本文档为新摄入来源，暂无已知冲突点）
|
||||
---
|
||||
title: "DevOps Culture and Transformation: Fostering Collaboration, Agile Practices, and Innovation"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-03-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/DevOps Culture and Transformation Fostering Collaboration, Agile Practices, and Innovation LinkedIn]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：DevOps 文化转型 —— 如何通过打破开发与运维之间的壁垒，推动组织实现更快、更可靠的软件交付与持续创新。
|
||||
- 问题域：传统 IT 组织中开发团队与运维团队的目标冲突（开发追求快速交付，运维追求稳定），以及组织文化变革的挑战。
|
||||
- 方法/机制：四大 DevOps 文化支柱（协作、自动化、持续改进、客户导向）；Agile 与 DevOps 的融合实践；战略转型 playbook（领导层支持、团队赋能、小步试点、克服阻力）。
|
||||
- 结论/价值：DevOps 不仅是工具和自动化，而是一场文化变革；拥抱 DevOps 文化 tenets、赋能团队、整合 Agile 实践的组织将在数字时代获得竞争优势。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- DevOps 通过建立跨职能团队，使开发和运维共同承担整个软件生命周期的责任，从而打破传统 IT 组织中的孤岛现象。
|
||||
- 自动化（CI/CD 流水线、基础设施即代码、可观测性工具）是 DevOps 的核心驱动力，能消除人工重复劳动、减少错误、加速反馈循环。
|
||||
- DevOps 强调持续改进（Kaizen），通过无责事后分析（blameless post-mortems）、数据指标和混沌工程驱动团队迭代学习。
|
||||
- Agile 与 DevOps 具有共生关系 —— Agile 关注迭代开发，DevOps 将敏捷延伸到运维，两者共同实现端到端的速度与质量。
|
||||
- DevOps 转型需要领导层支持、小步试点快速验证、用成功案例建立势能，而非一次性大爆炸式推行。
|
||||
- DevOps 的未来趋势包括：AI/ML 赋能智能自动化、GitOps、Serverless DevOps、边缘计算与 IoT DevOps、以及 DevSecOps 的深化。
|
||||
|
||||
## Key Quotes
|
||||
> "DevOps isn't just about tools or automation; it's a mindset shift that prioritizes collaboration, continuous learning, and customer-centricity." — 核心论点：DevOps 本质是文化与思维转变
|
||||
> "Blameless post-mortems to dissect failures without finger-pointing." — DevOps 文化的关键实践：无惧失败、聚焦改进
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps Culture]]：一种打破开发与运维壁垒、以协作、自动化、持续学习和客户导向为核心的文化与运营模式
|
||||
- [[CI/CD Pipeline]]：自动化测试、集成和部署流水线，是 DevOps 自动化能力的关键实现
|
||||
- [[Infrastructure as Code (IaC)]]：通过代码管理基础设施，实现一致性和版本控制的实践
|
||||
- [[Kaizen (Continuous Improvement)]]：持续改进理念，通过无责复盘、数据驱动决策和混沌工程推动迭代优化
|
||||
- [[Shift-Left]]：将安全、性能等运维关注点前移至开发阶段，DevSecOps 是其典型实践
|
||||
- [[Value Stream Mapping]]：价值流图析，通过可视化工作流识别等待、审批和测试环节的延迟，消除浪费
|
||||
- [[GitOps]]：使用 Git 作为唯一真实来源来管理基础设施和部署的运维模式，是 DevOps 的进化方向之一
|
||||
- [[Serverless DevOps]]：利用函数即服务（FaaS）等无服务器技术减少运维负担的 DevOps 实践
|
||||
- [[Agile-DevOps Integration]]：Agile 与 DevOps 的协同机制，Scrum/Kanban 提供方法论框架，CI/CD 提供工程加速能力
|
||||
|
||||
## Key Entities
|
||||
- [[Hemant Sawant]]：LinkedIn 文章原作者，DevOps 文化与转型领域的分享者
|
||||
- [[Shenwei]]：本文档的保存整理者
|
||||
|
||||
## Connections
|
||||
- [[DevOps Maturity Model]] ← extends ← [[DevOps Culture]]：本文聚焦 DevOps 文化转型，与成熟度模型互为补充（文化层 vs 能力层级）
|
||||
- [[DevSecOps Best Practices]] ← depends_on ← [[DevOps Culture]]：DevSecOps 是 DevOps 文化中"安全性嵌入"支柱的具体实现
|
||||
- [[Agile-DevOps Integration]] ← extends ← [[DevOps Culture]]：Agile 与 DevOps 的融合是本文第二大主题
|
||||
- [[How Agentic AI Can Help Cloud DevOps]] ← relates_to ← [[DevOps Culture]]：AI/ML 赋能 DevOps 是本文未来趋势之一
|
||||
|
||||
## Contradictions
|
||||
- （本文档为新摄入来源，暂无已知冲突点）
|
||||
|
||||
@@ -1,68 +1,68 @@
|
||||
---
|
||||
title: "DevOps Maturity Model From Traditional IT to Advanced DevOps"
|
||||
type: source
|
||||
tags: [DevOps, DevOps Maturity, CI/CD, Automation, DevSecOps]
|
||||
date: 2024-08-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/DevOps Maturity Model From Traditional IT to Advanced DevOps]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：DevOps 成熟度模型的五阶段演进框架，从传统 IT 到完全成熟的 DevOps
|
||||
- 问题域：组织如何评估当前 DevOps 实践水平，识别改进领域，制定升级路线图
|
||||
- 方法/机制：通过四个核心关注领域（文化与战略、自动化、结构与流程、协作与共享、技术）评估组织 DevOps 成熟度，分为五个递进阶段
|
||||
- 结论/价值：DevOps 成熟度模型是组织规划 DevOps 转型路径的结构化工具，涵盖从初始/临时阶段到完全成熟连续部署的全过程，并提供衡量指标和常见障碍识别
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- DevOps 成熟度模型通过四个关键领域评估组织能力：文化与战略、自动化、结构与流程、协作与共享、技术
|
||||
- 五阶段成熟度模型依次为：Phase 1 初始/临时阶段 → Phase 2 局部试点 → Phase 3 自动化与定义 → Phase 4 高度优化 → Phase 5 完全成熟
|
||||
- 完全成熟的 DevOps 实践实现零人工干预的流水线、每日多次部署、高确定性低风险发布
|
||||
- DevOps 成熟度关键衡量指标包括：部署频率、变更前置时间（Lead Time）、平均恢复时间（MTTR）、变更失败率、错误预算（Error Budget）
|
||||
- DevSecOps 将安全集成到 DevOps 每个阶段，是高级成熟度阶段的核心要求
|
||||
- 团队协作是 DevOps 的基石，也是衡量团队效能和生产力的关键指标
|
||||
|
||||
## Key Quotes
|
||||
> "The DevOps Maturity Model is a powerful tool for guiding organizations through the evolution of their DevOps practices, from initial adoption to achieving full maturity." — DevOps 成熟度模型的核心定位
|
||||
> "DevOps automation or AutoDevOps is crucial for continuous delivery and deployment. It simplifies development, testing, and production by automating repetitive tasks, which saves time and improves resource efficiency in the CI/CD process." — 自动化在 DevOps 中的核心价值
|
||||
> "The core of DevOps security is merging development, operations, and security into a unified process." — DevSecOps 的核心理念
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps]]：一种融合开发与运维的文化、实践和技术组合，强调协作、自动化和持续改进
|
||||
- [[DevSecOps]]：将安全实践集成到 DevOps 流程的每个阶段（通过 DevOps Maturity Model Phase 4-5 实现）
|
||||
- [[Continuous Delivery]]：持续交付，使代码变更可随时安全部署到生产环境
|
||||
- [[Agile]]：敏捷方法，从 Phase 2 开始引入，强调业务和用户价值而非仅项目规划
|
||||
- [[MVP]]：最小可行产品，在 Phase 4 高度优化阶段用于加速发布
|
||||
- [[Technical Debt]]：技术债务，在 Phase 3-4 阶段开始被优先管理和处理
|
||||
- [[Infrastructure as Code]]（IaC）：基础设施即代码，在 Phase 4 实现不可变基础设施替换旧服务器
|
||||
- [[MTTR]]（Mean Time to Recovery）：平均恢复时间，DevOps 成熟度关键衡量指标
|
||||
- [[Change Failure Rate]]：变更失败率，DevOps 关键绩效指标之一
|
||||
- [[Deployment Frequency]]：部署频率，完全成熟阶段实现每日多次部署
|
||||
- [[Lead Time]]：前置时间，从代码提交到部署的时间周期
|
||||
- [[concepts/Error-Budget]]：错误预算，允许的生产错误和失败率
|
||||
- [[concepts/Immutable-Infrastructure]]：不可变基础设施，在 Phase 4 替换旧服务器而非更新
|
||||
- [[Version Control]]：版本控制，从 Phase 2 开始用于管理环境和配置
|
||||
|
||||
## Key Entities
|
||||
- [[entities/DevOps-Maturity-Model]]：本文核心——评估和指导 DevOps 转型的五阶段成熟度模型
|
||||
- [[DevOps Culture and Transformation]]：DevOps 文化转型相关主题，与本文 Phase 1-2 的文化演进强相关
|
||||
- [[Release Management]]：发布管理，涵盖部署频率、变更失败率等关键指标，与本文衡量指标重叠
|
||||
|
||||
## Connections
|
||||
- [[DevOps Culture and Transformation]] ← foundational ← [[entities/DevOps-Maturity-Model]]
|
||||
- [[DevOps]] ← encompasses ← [[entities/DevOps-Maturity-Model]]
|
||||
- [[DevSecOps]] ← integrates ← [[DevOps]] + Security（本文 Phase 4-5 体现）
|
||||
- [[Continuous Delivery]] ← supports ← [[entities/DevOps-Maturity-Model]]
|
||||
- [[Release Management]] ← measures ← DevOps Maturity（共享 Deployment Frequency, Lead Time, MTTR 等指标）
|
||||
- [[concepts/Error-Budget]] ← part of ← DORA Metrics
|
||||
- [[concepts/Immutable-Infrastructure]] ← enables ← Phase 4 高度优化
|
||||
|
||||
## Contradictions
|
||||
- 与 [[DevOps Culture and Transformation]] 的潜在视角差异：
|
||||
- 冲突点：文化转型是 DevOps 成功的前提还是结果？
|
||||
- 当前观点（本文）：文化是成熟度的一个评估维度，从 Phase 1（孤立文化）到 Phase 5（自足全栈团队）
|
||||
- 对方观点：文化转型应该是最先启动的变革，需先改变团队协作方式才能推进其他实践
|
||||
- 与 [[Waterfall]] 的对比冲突：
|
||||
- 冲突点：传统瀑布式方法是否完全无法满足现代软件交付需求？
|
||||
- 当前观点（本文）：瀑布式是 Phase 1 的典型特征，以里程碑而非用户反馈驱动，是需要淘汰的落后模式
|
||||
- 对方观点：瀑布式在稳定需求、长周期硬件项目或合规要求严格的场景中仍有价值
|
||||
---
|
||||
title: "DevOps Maturity Model From Traditional IT to Advanced DevOps"
|
||||
type: source
|
||||
tags: [DevOps, DevOps Maturity, CI/CD, Automation, DevSecOps]
|
||||
date: 2024-08-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/DevOps Maturity Model From Traditional IT to Advanced DevOps]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：DevOps 成熟度模型的五阶段演进框架，从传统 IT 到完全成熟的 DevOps
|
||||
- 问题域：组织如何评估当前 DevOps 实践水平，识别改进领域，制定升级路线图
|
||||
- 方法/机制：通过四个核心关注领域（文化与战略、自动化、结构与流程、协作与共享、技术）评估组织 DevOps 成熟度，分为五个递进阶段
|
||||
- 结论/价值：DevOps 成熟度模型是组织规划 DevOps 转型路径的结构化工具，涵盖从初始/临时阶段到完全成熟连续部署的全过程，并提供衡量指标和常见障碍识别
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- DevOps 成熟度模型通过四个关键领域评估组织能力：文化与战略、自动化、结构与流程、协作与共享、技术
|
||||
- 五阶段成熟度模型依次为：Phase 1 初始/临时阶段 → Phase 2 局部试点 → Phase 3 自动化与定义 → Phase 4 高度优化 → Phase 5 完全成熟
|
||||
- 完全成熟的 DevOps 实践实现零人工干预的流水线、每日多次部署、高确定性低风险发布
|
||||
- DevOps 成熟度关键衡量指标包括：部署频率、变更前置时间（Lead Time）、平均恢复时间（MTTR）、变更失败率、错误预算（Error Budget）
|
||||
- DevSecOps 将安全集成到 DevOps 每个阶段，是高级成熟度阶段的核心要求
|
||||
- 团队协作是 DevOps 的基石，也是衡量团队效能和生产力的关键指标
|
||||
|
||||
## Key Quotes
|
||||
> "The DevOps Maturity Model is a powerful tool for guiding organizations through the evolution of their DevOps practices, from initial adoption to achieving full maturity." — DevOps 成熟度模型的核心定位
|
||||
> "DevOps automation or AutoDevOps is crucial for continuous delivery and deployment. It simplifies development, testing, and production by automating repetitive tasks, which saves time and improves resource efficiency in the CI/CD process." — 自动化在 DevOps 中的核心价值
|
||||
> "The core of DevOps security is merging development, operations, and security into a unified process." — DevSecOps 的核心理念
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps]]：一种融合开发与运维的文化、实践和技术组合，强调协作、自动化和持续改进
|
||||
- [[DevSecOps]]：将安全实践集成到 DevOps 流程的每个阶段（通过 DevOps Maturity Model Phase 4-5 实现）
|
||||
- [[Continuous Delivery]]：持续交付，使代码变更可随时安全部署到生产环境
|
||||
- [[Agile]]：敏捷方法，从 Phase 2 开始引入，强调业务和用户价值而非仅项目规划
|
||||
- [[MVP]]：最小可行产品，在 Phase 4 高度优化阶段用于加速发布
|
||||
- [[Technical Debt]]：技术债务，在 Phase 3-4 阶段开始被优先管理和处理
|
||||
- [[Infrastructure as Code]]（IaC）：基础设施即代码，在 Phase 4 实现不可变基础设施替换旧服务器
|
||||
- [[MTTR]]（Mean Time to Recovery）：平均恢复时间，DevOps 成熟度关键衡量指标
|
||||
- [[Change Failure Rate]]：变更失败率，DevOps 关键绩效指标之一
|
||||
- [[Deployment Frequency]]：部署频率，完全成熟阶段实现每日多次部署
|
||||
- [[Lead Time]]：前置时间，从代码提交到部署的时间周期
|
||||
- [[concepts/Error-Budget]]：错误预算，允许的生产错误和失败率
|
||||
- [[concepts/Immutable-Infrastructure]]：不可变基础设施，在 Phase 4 替换旧服务器而非更新
|
||||
- [[Version Control]]：版本控制，从 Phase 2 开始用于管理环境和配置
|
||||
|
||||
## Key Entities
|
||||
- [[entities/DevOps-Maturity-Model]]：本文核心——评估和指导 DevOps 转型的五阶段成熟度模型
|
||||
- [[DevOps Culture and Transformation]]：DevOps 文化转型相关主题，与本文 Phase 1-2 的文化演进强相关
|
||||
- [[Release Management]]：发布管理，涵盖部署频率、变更失败率等关键指标，与本文衡量指标重叠
|
||||
|
||||
## Connections
|
||||
- [[DevOps Culture and Transformation]] ← foundational ← [[entities/DevOps-Maturity-Model]]
|
||||
- [[DevOps]] ← encompasses ← [[entities/DevOps-Maturity-Model]]
|
||||
- [[DevSecOps]] ← integrates ← [[DevOps]] + Security（本文 Phase 4-5 体现）
|
||||
- [[Continuous Delivery]] ← supports ← [[entities/DevOps-Maturity-Model]]
|
||||
- [[Release Management]] ← measures ← DevOps Maturity（共享 Deployment Frequency, Lead Time, MTTR 等指标）
|
||||
- [[concepts/Error-Budget]] ← part of ← DORA Metrics
|
||||
- [[concepts/Immutable-Infrastructure]] ← enables ← Phase 4 高度优化
|
||||
|
||||
## Contradictions
|
||||
- 与 [[DevOps Culture and Transformation]] 的潜在视角差异：
|
||||
- 冲突点：文化转型是 DevOps 成功的前提还是结果？
|
||||
- 当前观点（本文）：文化是成熟度的一个评估维度，从 Phase 1（孤立文化）到 Phase 5（自足全栈团队）
|
||||
- 对方观点：文化转型应该是最先启动的变革，需先改变团队协作方式才能推进其他实践
|
||||
- 与 [[Waterfall]] 的对比冲突：
|
||||
- 冲突点：传统瀑布式方法是否完全无法满足现代软件交付需求？
|
||||
- 当前观点（本文）：瀑布式是 Phase 1 的典型特征，以里程碑而非用户反馈驱动，是需要淘汰的落后模式
|
||||
- 对方观点：瀑布式在稳定需求、长周期硬件项目或合规要求严格的场景中仍有价值
|
||||
|
||||
@@ -1,52 +1,52 @@
|
||||
---
|
||||
title: "Autonomous Optimization Architect"
|
||||
type: source
|
||||
tags: ["ai-finetuning", "llm-routing", "ai-fintech", "autonomous-agents", "cost-optimization"]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-autonomous-optimization-architect.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：LLM 驱动的自主优化与智能路由系统，通过影子测试持续评估和切换 AI 模型
|
||||
- 问题域：AI 系统运营成本失控、模型选择缺乏数据驱动、缺少金融级安全保障
|
||||
- 方法/机制：LLM-as-a-Judge 评分、影子流量测试、暗启动（Dark Launching）、熔断器（Circuit Breaker）、AI FinOps
|
||||
- 结论/价值：在保证 99.99% 稳定性的前提下，通过自动路由至更便宜/更快的模型实现 >40% 成本降低
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 影子流量（Shadow Traffic）异步测试新模型，不影响生产环境稳定性的同时收集真实对比数据
|
||||
- 自主流量路由（Autonomous Traffic Routing）：实验模型达到基准精度（如 98%）且成本更低（如 1/10）时，自动切换至该模型
|
||||
- 金融与安全护栏（Financial & Security Guardrails）：每个外部请求必须配置超时、重试上限和廉价兜底方案，防止无限循环
|
||||
- 异常熔断（Halt on Anomaly）：流量突增 500% 或出现 HTTP 402/429 错误时，立即触发熔断器并告警人工
|
||||
- 成本优先原则：提出 LLM 架构时必须同时给出每百万 Token 的主路径和兜底路径成本估算
|
||||
|
||||
## Key Quotes
|
||||
> "I have evaluated 1,000 shadow executions. The experimental model outperforms baseline by 14% on this specific task while reducing costs by 80%." — Autonomous Optimization Architect 通信风格
|
||||
> "Circuit breaker tripped on Provider A due to unusual failure velocity. Automating failover to Provider B to prevent token drain. Admin alerted." — 熔断触发时的标准告警语
|
||||
> "Autonomous routing without a circuit breaker is just an expensive bomb." — 该 Agent 的核心理念
|
||||
|
||||
## Key Concepts
|
||||
- [[CircuitBreaker]]：熔断器模式，当 Provider 失败频率超过阈值时自动切断并切换到廉价兜底方案
|
||||
- [[LLMasJudge]]：用 LLM 自动评估实验模型输出的质量，作为客观评分替代人工评审
|
||||
- [[ShadowTraffic]]：影子流量，将一小部分请求异步转发至实验模型，与生产结果对比评分
|
||||
- [[SemanticRouting]]：语义路由，根据任务类型和历史性能选择最优 Provider
|
||||
- [[DarkLaunching]]：暗启动/灰度发布，新模型在不影响用户的前提下逐步引入
|
||||
- [[AIFinOps]]：AI 云财务管理，跟踪每个 LLM 的 token 消耗、成本和延迟，建立历史性能排名
|
||||
|
||||
## Key Entities
|
||||
- [[OpenAI]]：主要 LLM Provider 之一，提供 GPT 系列模型
|
||||
- [[Anthropic]]：主要 LLM Provider，提供 Claude 系列模型
|
||||
- [[GoogleGemini]]：主要 LLM Provider，提供 Gemini Flash 等高性价比模型
|
||||
- [[Firecrawl]]：网页抓取 API，当 LLM Provider 不可用时的备选数据获取方案
|
||||
|
||||
## Connections
|
||||
- [[testing-workflow-optimizer]] ← uses ← [[AutonomousOptimizationArchitect]]（工作流优化依赖路由决策）
|
||||
- [[backend-architect-with-memory]] ← depends_on ← [[AutonomousOptimizationArchitect]]（后端架构依赖成本追踪记忆）
|
||||
- [[automation-governance-architect]] ← shares_guardrails ← [[AutonomousOptimizationArchitect]]（自动化治理与本 Agent 均涉及安全护栏设计）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[testing-performance-benchmarker]] 冲突：
|
||||
- 冲突点：性能基准测试强调人工驱动的静态评估，本 Agent 强调机器驱动的动态 A/B 测试
|
||||
- 当前观点：持续自动的影子测试比定期人工测试更能反映生产环境真实性能
|
||||
- 对方观点：性能基准测试提供可控、可复现的实验室数据，而非真实流量噪声
|
||||
---
|
||||
title: "Autonomous Optimization Architect"
|
||||
type: source
|
||||
tags: ["ai-finetuning", "llm-routing", "ai-fintech", "autonomous-agents", "cost-optimization"]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-autonomous-optimization-architect.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：LLM 驱动的自主优化与智能路由系统，通过影子测试持续评估和切换 AI 模型
|
||||
- 问题域：AI 系统运营成本失控、模型选择缺乏数据驱动、缺少金融级安全保障
|
||||
- 方法/机制：LLM-as-a-Judge 评分、影子流量测试、暗启动（Dark Launching）、熔断器（Circuit Breaker）、AI FinOps
|
||||
- 结论/价值：在保证 99.99% 稳定性的前提下，通过自动路由至更便宜/更快的模型实现 >40% 成本降低
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 影子流量（Shadow Traffic）异步测试新模型，不影响生产环境稳定性的同时收集真实对比数据
|
||||
- 自主流量路由（Autonomous Traffic Routing）：实验模型达到基准精度（如 98%）且成本更低（如 1/10）时，自动切换至该模型
|
||||
- 金融与安全护栏（Financial & Security Guardrails）：每个外部请求必须配置超时、重试上限和廉价兜底方案，防止无限循环
|
||||
- 异常熔断（Halt on Anomaly）：流量突增 500% 或出现 HTTP 402/429 错误时，立即触发熔断器并告警人工
|
||||
- 成本优先原则：提出 LLM 架构时必须同时给出每百万 Token 的主路径和兜底路径成本估算
|
||||
|
||||
## Key Quotes
|
||||
> "I have evaluated 1,000 shadow executions. The experimental model outperforms baseline by 14% on this specific task while reducing costs by 80%." — Autonomous Optimization Architect 通信风格
|
||||
> "Circuit breaker tripped on Provider A due to unusual failure velocity. Automating failover to Provider B to prevent token drain. Admin alerted." — 熔断触发时的标准告警语
|
||||
> "Autonomous routing without a circuit breaker is just an expensive bomb." — 该 Agent 的核心理念
|
||||
|
||||
## Key Concepts
|
||||
- [[CircuitBreaker]]：熔断器模式，当 Provider 失败频率超过阈值时自动切断并切换到廉价兜底方案
|
||||
- [[LLMasJudge]]：用 LLM 自动评估实验模型输出的质量，作为客观评分替代人工评审
|
||||
- [[ShadowTraffic]]：影子流量，将一小部分请求异步转发至实验模型，与生产结果对比评分
|
||||
- [[SemanticRouting]]：语义路由，根据任务类型和历史性能选择最优 Provider
|
||||
- [[DarkLaunching]]：暗启动/灰度发布，新模型在不影响用户的前提下逐步引入
|
||||
- [[AIFinOps]]：AI 云财务管理，跟踪每个 LLM 的 token 消耗、成本和延迟，建立历史性能排名
|
||||
|
||||
## Key Entities
|
||||
- [[OpenAI]]：主要 LLM Provider 之一，提供 GPT 系列模型
|
||||
- [[Anthropic]]：主要 LLM Provider，提供 Claude 系列模型
|
||||
- [[GoogleGemini]]：主要 LLM Provider，提供 Gemini Flash 等高性价比模型
|
||||
- [[Firecrawl]]：网页抓取 API，当 LLM Provider 不可用时的备选数据获取方案
|
||||
|
||||
## Connections
|
||||
- [[testing-workflow-optimizer]] ← uses ← [[AutonomousOptimizationArchitect]]（工作流优化依赖路由决策）
|
||||
- [[backend-architect-with-memory]] ← depends_on ← [[AutonomousOptimizationArchitect]]（后端架构依赖成本追踪记忆）
|
||||
- [[automation-governance-architect]] ← shares_guardrails ← [[AutonomousOptimizationArchitect]]（自动化治理与本 Agent 均涉及安全护栏设计）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[testing-performance-benchmarker]] 冲突：
|
||||
- 冲突点：性能基准测试强调人工驱动的静态评估，本 Agent 强调机器驱动的动态 A/B 测试
|
||||
- 当前观点：持续自动的影子测试比定期人工测试更能反映生产环境真实性能
|
||||
- 对方观点：性能基准测试提供可控、可复现的实验室数据，而非真实流量噪声
|
||||
|
||||
@@ -1,56 +1,56 @@
|
||||
---
|
||||
title: "Mobile App Builder Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-mobile-app-builder.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Mobile App Builder — 专注于原生 iOS/Android 开发和跨平台框架的移动应用开发 AI Agent 人格规范
|
||||
- 问题域：如何在移动端构建高性能、平台原生体验的应用；原生开发与跨平台开发的选型决策；移动端特有的性能、续航、离线场景约束
|
||||
- 方法/机制：Swift/SwiftUI（iOS）、Kotlin/Jetpack Compose（Android）、React Native/Flutter（跨平台）；MVVM 模式；Offline-First 架构；平台原生设计规范（Material Design / Human Interface Guidelines）
|
||||
- 结论/价值：移动开发 Agent 需要具备平台意识、性能优先、用户体验驱动的特质，同时保持跨平台的技术多样性
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 原生 iOS/Android 开发必须遵循平台设计指南（Material Design、Human Interface Guidelines）
|
||||
- 移动应用必须实现离线优先架构和智能数据同步
|
||||
- 跨平台开发需在代码复用与平台原生体验之间找到平衡
|
||||
- 移动性能优化目标：冷启动 < 3 秒，内存占用 < 100MB，续航损耗 < 5%/小时
|
||||
|
||||
## Key Quotes
|
||||
> "Implemented iOS-native navigation with SwiftUI while maintaining Material Design patterns on Android" — 平台感知型开发示例
|
||||
> "Built offline-first architecture to handle poor network conditions gracefully" — 移动约束优先的设计理念
|
||||
> "Optimized app startup time to 2.1 seconds and reduced memory usage by 40%" — 性能优化的典型目标
|
||||
|
||||
## Key Concepts
|
||||
- [[Offline-First Architecture]]：离线优先架构 — 构建应用时默认以离线为基准，网络连接时进行数据同步，确保弱网环境下的用户体验
|
||||
- [[MVVM Pattern]]：Model-View-ViewModel — SwiftUI 和 Jetpack Compose 推荐的状态管理模式，ViewModel 持有 UI 状态和业务逻辑，View 负责渲染
|
||||
- [[Cross-Platform Mobile Development]]：跨平台移动开发 — 使用 React Native 或 Flutter 等框架在 iOS 和 Android 上共享代码，同时保持平台原生特性
|
||||
- [[Platform-Native UI]]：平台原生 UI — 遵循各平台设计规范（Material Design / HIG）实现符合用户预期的界面和交互
|
||||
- [[Biometric Authentication]]：生物特征认证 — 在移动应用中集成 Face ID、Touch ID 或指纹识别实现安全身份验证
|
||||
- [[Push Notification System]]：推送通知系统 — 针对不同平台（APNs/Firebase）实现精准推送，提升用户留存
|
||||
|
||||
## Key Entities
|
||||
- [[SwiftUI]]：Apple 声明式 UI 框架，用于构建现代 iOS/macOS 应用界面
|
||||
- [[Jetpack Compose]]：Google Jetpack 声明式 UI 工具包，Android 原生现代化 UI 开发
|
||||
- [[React Native]]：Facebook/Meta 开源跨平台框架，使用 JavaScript/TypeScript 构建原生移动应用
|
||||
- [[Flutter]]：Google 开源跨平台 UI 工具包，使用 Dart 语言，可编译为原生 ARM 代码
|
||||
- [[Swift]]：Apple iOS/macOS 开发语言，配合 SwiftUI 使用
|
||||
- [[Kotlin]]：Google 官方 Android 开发语言，配合 Jetpack Compose 使用
|
||||
|
||||
## Connections
|
||||
- [[agents-orchestrator]] ← orchestrates ← [[engineering-mobile-app-builder]]
|
||||
- [[engineering-mobile-app-builder]] ← shares_workflow ← [[unity-architect]]（平台策略和架构决策方法论）
|
||||
- [[engineering-mobile-app-builder]] ← extends ← [[software-architect]]（系统架构原则应用于移动端）
|
||||
- [[visionos-spatial-engineer]] ← related_to ← [[engineering-mobile-app-builder]]（Apple 生态移动开发扩展）
|
||||
- [[xr-immersive-developer]] ← related_to ← [[engineering-mobile-app-builder]]（XR 与移动平台的跨设备体验）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[unity-architect]] 跨平台理念存在框架差异：
|
||||
- 冲突点：原生开发 vs 跨平台框架的优先级
|
||||
- 当前观点：Mobile App Builder 默认支持多种框架（SwiftUI、Jetpack Compose、React Native、Flutter），按需选型
|
||||
- 对方观点：Unity Architect 专注于 Unity 引擎内的跨平台方案
|
||||
- 说明：两者解决的问题域不同，Mobile App Builder 面向通用移动应用，Unity Architect 面向游戏开发，属合理分工而非矛盾
|
||||
---
|
||||
title: "Mobile App Builder Agent Personality"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Agent/agency-agents/engineering/engineering-mobile-app-builder.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Mobile App Builder — 专注于原生 iOS/Android 开发和跨平台框架的移动应用开发 AI Agent 人格规范
|
||||
- 问题域：如何在移动端构建高性能、平台原生体验的应用；原生开发与跨平台开发的选型决策；移动端特有的性能、续航、离线场景约束
|
||||
- 方法/机制：Swift/SwiftUI（iOS）、Kotlin/Jetpack Compose（Android）、React Native/Flutter（跨平台）；MVVM 模式；Offline-First 架构；平台原生设计规范（Material Design / Human Interface Guidelines）
|
||||
- 结论/价值：移动开发 Agent 需要具备平台意识、性能优先、用户体验驱动的特质，同时保持跨平台的技术多样性
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 原生 iOS/Android 开发必须遵循平台设计指南（Material Design、Human Interface Guidelines）
|
||||
- 移动应用必须实现离线优先架构和智能数据同步
|
||||
- 跨平台开发需在代码复用与平台原生体验之间找到平衡
|
||||
- 移动性能优化目标：冷启动 < 3 秒，内存占用 < 100MB，续航损耗 < 5%/小时
|
||||
|
||||
## Key Quotes
|
||||
> "Implemented iOS-native navigation with SwiftUI while maintaining Material Design patterns on Android" — 平台感知型开发示例
|
||||
> "Built offline-first architecture to handle poor network conditions gracefully" — 移动约束优先的设计理念
|
||||
> "Optimized app startup time to 2.1 seconds and reduced memory usage by 40%" — 性能优化的典型目标
|
||||
|
||||
## Key Concepts
|
||||
- [[Offline-First Architecture]]：离线优先架构 — 构建应用时默认以离线为基准，网络连接时进行数据同步，确保弱网环境下的用户体验
|
||||
- [[MVVM Pattern]]：Model-View-ViewModel — SwiftUI 和 Jetpack Compose 推荐的状态管理模式，ViewModel 持有 UI 状态和业务逻辑，View 负责渲染
|
||||
- [[Cross-Platform Mobile Development]]：跨平台移动开发 — 使用 React Native 或 Flutter 等框架在 iOS 和 Android 上共享代码，同时保持平台原生特性
|
||||
- [[Platform-Native UI]]：平台原生 UI — 遵循各平台设计规范（Material Design / HIG）实现符合用户预期的界面和交互
|
||||
- [[Biometric Authentication]]：生物特征认证 — 在移动应用中集成 Face ID、Touch ID 或指纹识别实现安全身份验证
|
||||
- [[Push Notification System]]：推送通知系统 — 针对不同平台（APNs/Firebase）实现精准推送，提升用户留存
|
||||
|
||||
## Key Entities
|
||||
- [[SwiftUI]]：Apple 声明式 UI 框架，用于构建现代 iOS/macOS 应用界面
|
||||
- [[Jetpack Compose]]：Google Jetpack 声明式 UI 工具包，Android 原生现代化 UI 开发
|
||||
- [[React Native]]：Facebook/Meta 开源跨平台框架，使用 JavaScript/TypeScript 构建原生移动应用
|
||||
- [[Flutter]]：Google 开源跨平台 UI 工具包，使用 Dart 语言，可编译为原生 ARM 代码
|
||||
- [[Swift]]：Apple iOS/macOS 开发语言，配合 SwiftUI 使用
|
||||
- [[Kotlin]]：Google 官方 Android 开发语言，配合 Jetpack Compose 使用
|
||||
|
||||
## Connections
|
||||
- [[agents-orchestrator]] ← orchestrates ← [[engineering-mobile-app-builder]]
|
||||
- [[engineering-mobile-app-builder]] ← shares_workflow ← [[unity-architect]]（平台策略和架构决策方法论）
|
||||
- [[engineering-mobile-app-builder]] ← extends ← [[software-architect]]（系统架构原则应用于移动端）
|
||||
- [[visionos-spatial-engineer]] ← related_to ← [[engineering-mobile-app-builder]]（Apple 生态移动开发扩展）
|
||||
- [[xr-immersive-developer]] ← related_to ← [[engineering-mobile-app-builder]]（XR 与移动平台的跨设备体验）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[unity-architect]] 跨平台理念存在框架差异：
|
||||
- 冲突点：原生开发 vs 跨平台框架的优先级
|
||||
- 当前观点：Mobile App Builder 默认支持多种框架（SwiftUI、Jetpack Compose、React Native、Flutter），按需选型
|
||||
- 对方观点：Unity Architect 专注于 Unity 引擎内的跨平台方案
|
||||
- 说明：两者解决的问题域不同，Mobile App Builder 面向通用移动应用，Unity Architect 面向游戏开发，属合理分工而非矛盾
|
||||
|
||||
@@ -1,69 +1,69 @@
|
||||
---
|
||||
title: "How Can a Multi Cloud Strategy Transform Your Business ROI?"
|
||||
type: source
|
||||
tags: [Cloud, Multi-Cloud, ROI, DevOps]
|
||||
date: 2024-12-24
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/How Can a Multi Cloud Strategy Transform Your Business ROI.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：多云策略（Multi-Cloud Strategy）的商业价值——如何通过多云架构提升业务 ROI、降低风险、增强弹性
|
||||
- 问题域：企业在云迁移和云运营中面临的供应商锁定、成本失控、合规复杂、可用性不足等挑战
|
||||
- 方法/机制：跨多个云服务提供商（AWS/Azure/GCP）分配工作负载，利用各提供商优势实现成本优化、弹性扩展和安全增强
|
||||
- 结论/价值：78% 企业使用 3+ 公有云；86% 企业计划 2024 年底采用多云；优化后可实现 30% 运营成本降低；多云策略是企业在数字化竞争中保持敏捷的关键
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 78% 采用多云策略的企业使用 3+ 公有云以提升敏捷性和成本节约（Virtana）
|
||||
- 86% 企业计划 2024 年底采用多云策略以满足持续业务需求（New Horizons）
|
||||
- 优化资源和与不同云服务商谈判后，多数企业享受 30% 运营成本降低（Forrester）
|
||||
- 78% 企业已采用多云策略；平均使用 2-5 个云服务商；多云是主流趋势
|
||||
|
||||
## Key Quotes
|
||||
> "The multi cloud strategy is a distinctive approach in which we have instances of services on multiple clouds, i.e., Azure, GCP, and Amazon, instead of one cloud vendor." — Bacancy Technology，核心定义
|
||||
|
||||
> "A multi-cloud approach will provide businesses with more innovation and ensure they are always at the forefront of this rapidly evolving digital landscape." — Bacancy Technology，多云创新的价值
|
||||
|
||||
> "After optimizing resources and negotiating favorable prices with different cloud service providers, most companies enjoy a 30% reduction in operations costs." — Forrester，成本优化数据来源
|
||||
|
||||
## Key Concepts
|
||||
- [[Multi-Cloud-Strategy]]：使用多个云服务提供商来避免锁定、增强弹性、优化成本，是本文核心主题
|
||||
- [[Vendor-Lock-In]]：多云策略的首要动因——企业通过多云摆脱对单一供应商的依赖
|
||||
- [[Data-Sovereignty]]：多云策略满足数据主权合规——不同地区选择符合当地法规的云服务商
|
||||
- [[High Availability]]：多云跨平台冗余实现 99.99%+ 可用性目标
|
||||
- [[Scalability]]：多云弹性扩展能力——跨提供商动态分配资源，应对流量高峰
|
||||
- [[Cost Optimization]]：多云实现 30% 运营成本降低——跨提供商比价、优化资源配置
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]] — 主要云提供商之一，可用于基础设施和通用计算
|
||||
- [[Azure]] — Microsoft Azure，多云策略中用于 AI 工具集成
|
||||
- [[Google-Cloud]] — GCP，ML/AI 工作负载的首选提供商
|
||||
- Bacancy Technology — 文章原始发布方，提供云托管服务
|
||||
|
||||
## Connections
|
||||
- [[Multi-Cloud-Strategy]] ← is_about ← 本文核心主题
|
||||
- [[Vendor-Lock-In]] ← solves ← [[Multi-Cloud-Strategy]] 的首要动机
|
||||
- [[Data-Sovereignty]] ← enables ← [[Multi-Cloud-Strategy]] 的合规能力
|
||||
- [[High Availability]] ← achieved_by ← [[Multi-Cloud-Strategy]] 跨云冗余
|
||||
- [[Cloud-Operating-Model]] ← includes ← [[Multi-Cloud-Strategy]] 作为核心组件
|
||||
- [[Cloud-Governance]] ← governs ← [[Multi-Cloud-Strategy]] 的实施
|
||||
- [[FinOps]] ← optimizes ← [[Multi-Cloud-Strategy]] 的成本管理
|
||||
|
||||
## Real-World Use Cases（原文关键案例）
|
||||
- **电商**：黑色星期五/网络星期一等高峰期跨多云弹性扩展，保障高可用和快速加载
|
||||
- **医疗**：符合 HIPAA 保护患者数据，符合区域数据主权要求，降低单一云依赖成本
|
||||
- **金融**：利用不同云最佳安全功能，满足严格监管要求，减少供应商锁定，获得更好 SLA
|
||||
|
||||
## Implementation Framework（原文实施路径）
|
||||
1. **评估需求**：明确目标（弹性/成本/规模）、预算分析、资源评估
|
||||
2. **选择提供商**：对齐服务与需求（如 AWS 基础设施、GCP 分析、Azure AI）
|
||||
3. **集成管理**：采用 Kubernetes/Terraform 等多云管理工具，确保数据互操作性
|
||||
4. **监控优化**：使用 CloudHealth/Datadog 持续监控性能和成本
|
||||
|
||||
## Contradictions
|
||||
- 与 [[cloud-operating-model-key-strategies-and-best-practices]] 中的"统一云治理"观点存在潜在张力：
|
||||
- 冲突点：多云策略天然带来管理复杂性
|
||||
- 当前观点（本文）：多云管理工具（Kubernetes/Terraform）可简化复杂性
|
||||
- 对方观点：需要统一的 Cloud Operating Model 治理框架来协调多云环境
|
||||
- 协调方向：两者互补——多云策略是选择层，Cloud Operating Model 是治理层
|
||||
---
|
||||
title: "How Can a Multi Cloud Strategy Transform Your Business ROI?"
|
||||
type: source
|
||||
tags: [Cloud, Multi-Cloud, ROI, DevOps]
|
||||
date: 2024-12-24
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/How Can a Multi Cloud Strategy Transform Your Business ROI.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：多云策略（Multi-Cloud Strategy）的商业价值——如何通过多云架构提升业务 ROI、降低风险、增强弹性
|
||||
- 问题域：企业在云迁移和云运营中面临的供应商锁定、成本失控、合规复杂、可用性不足等挑战
|
||||
- 方法/机制：跨多个云服务提供商（AWS/Azure/GCP）分配工作负载，利用各提供商优势实现成本优化、弹性扩展和安全增强
|
||||
- 结论/价值：78% 企业使用 3+ 公有云；86% 企业计划 2024 年底采用多云；优化后可实现 30% 运营成本降低；多云策略是企业在数字化竞争中保持敏捷的关键
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 78% 采用多云策略的企业使用 3+ 公有云以提升敏捷性和成本节约（Virtana）
|
||||
- 86% 企业计划 2024 年底采用多云策略以满足持续业务需求（New Horizons）
|
||||
- 优化资源和与不同云服务商谈判后，多数企业享受 30% 运营成本降低（Forrester）
|
||||
- 78% 企业已采用多云策略；平均使用 2-5 个云服务商；多云是主流趋势
|
||||
|
||||
## Key Quotes
|
||||
> "The multi cloud strategy is a distinctive approach in which we have instances of services on multiple clouds, i.e., Azure, GCP, and Amazon, instead of one cloud vendor." — Bacancy Technology，核心定义
|
||||
|
||||
> "A multi-cloud approach will provide businesses with more innovation and ensure they are always at the forefront of this rapidly evolving digital landscape." — Bacancy Technology，多云创新的价值
|
||||
|
||||
> "After optimizing resources and negotiating favorable prices with different cloud service providers, most companies enjoy a 30% reduction in operations costs." — Forrester，成本优化数据来源
|
||||
|
||||
## Key Concepts
|
||||
- [[Multi-Cloud-Strategy]]：使用多个云服务提供商来避免锁定、增强弹性、优化成本，是本文核心主题
|
||||
- [[Vendor-Lock-In]]：多云策略的首要动因——企业通过多云摆脱对单一供应商的依赖
|
||||
- [[Data-Sovereignty]]：多云策略满足数据主权合规——不同地区选择符合当地法规的云服务商
|
||||
- [[High Availability]]：多云跨平台冗余实现 99.99%+ 可用性目标
|
||||
- [[Scalability]]：多云弹性扩展能力——跨提供商动态分配资源，应对流量高峰
|
||||
- [[Cost Optimization]]：多云实现 30% 运营成本降低——跨提供商比价、优化资源配置
|
||||
|
||||
## Key Entities
|
||||
- [[AWS]] — 主要云提供商之一，可用于基础设施和通用计算
|
||||
- [[Azure]] — Microsoft Azure，多云策略中用于 AI 工具集成
|
||||
- [[Google-Cloud]] — GCP，ML/AI 工作负载的首选提供商
|
||||
- Bacancy Technology — 文章原始发布方，提供云托管服务
|
||||
|
||||
## Connections
|
||||
- [[Multi-Cloud-Strategy]] ← is_about ← 本文核心主题
|
||||
- [[Vendor-Lock-In]] ← solves ← [[Multi-Cloud-Strategy]] 的首要动机
|
||||
- [[Data-Sovereignty]] ← enables ← [[Multi-Cloud-Strategy]] 的合规能力
|
||||
- [[High Availability]] ← achieved_by ← [[Multi-Cloud-Strategy]] 跨云冗余
|
||||
- [[Cloud-Operating-Model]] ← includes ← [[Multi-Cloud-Strategy]] 作为核心组件
|
||||
- [[Cloud-Governance]] ← governs ← [[Multi-Cloud-Strategy]] 的实施
|
||||
- [[FinOps]] ← optimizes ← [[Multi-Cloud-Strategy]] 的成本管理
|
||||
|
||||
## Real-World Use Cases（原文关键案例）
|
||||
- **电商**：黑色星期五/网络星期一等高峰期跨多云弹性扩展，保障高可用和快速加载
|
||||
- **医疗**：符合 HIPAA 保护患者数据，符合区域数据主权要求，降低单一云依赖成本
|
||||
- **金融**：利用不同云最佳安全功能，满足严格监管要求，减少供应商锁定，获得更好 SLA
|
||||
|
||||
## Implementation Framework（原文实施路径）
|
||||
1. **评估需求**：明确目标（弹性/成本/规模）、预算分析、资源评估
|
||||
2. **选择提供商**：对齐服务与需求（如 AWS 基础设施、GCP 分析、Azure AI）
|
||||
3. **集成管理**：采用 Kubernetes/Terraform 等多云管理工具，确保数据互操作性
|
||||
4. **监控优化**：使用 CloudHealth/Datadog 持续监控性能和成本
|
||||
|
||||
## Contradictions
|
||||
- 与 [[cloud-operating-model-key-strategies-and-best-practices]] 中的"统一云治理"观点存在潜在张力：
|
||||
- 冲突点：多云策略天然带来管理复杂性
|
||||
- 当前观点（本文）：多云管理工具（Kubernetes/Terraform）可简化复杂性
|
||||
- 对方观点：需要统一的 Cloud Operating Model 治理框架来协调多云环境
|
||||
- 协调方向：两者互补——多云策略是选择层，Cloud Operating Model 是治理层
|
||||
|
||||
@@ -1,135 +1,135 @@
|
||||
---
|
||||
title: "Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记"
|
||||
type: source
|
||||
tags: [frp, frpc, gatekeeper, mac-mini, macos, arm64]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记.md]]
|
||||
|
||||
## Summary (用中文描述)
|
||||
- **核心主题**：在 Apple Silicon（ARM64）Mac Mini M4 上安装配置 FRP 0.65.0 内网穿透客户端，实现通过公网 VPS 远程访问本地服务
|
||||
- **问题域**：macOS 服务器化运维、内网穿透、远程访问、SSH 安全隧道
|
||||
- **方法/机制**：通过 FRP（frpc）客户端连接远程 VPS（frps）建立反向隧道，结合 tmux/nohup/launchd 三种方式实现后台持久运行；通过 SSH 客户端配置简化远程访问
|
||||
- **结论/价值**：提供完整的 Mac Mini 服务器化运维指南，包含 macOS 特有障碍（Gatekeeper）的解决方案和 SSH 客户端优化配置
|
||||
|
||||
## Key Claims (用中文描述)
|
||||
- macOS 默认 `/opt` 目录需要手动创建并授权才能使用
|
||||
- macOS Gatekeeper 会阻止未签名程序运行，必须通过 `xattr -rd com.apple.quarantine .` 解除限制
|
||||
- launchd 是 macOS 推荐的开机自启服务管理方式，可通过 `launchctl` 管理生命周期
|
||||
- 软链接（symlink）策略可实现 FRP 版本无缝切换
|
||||
- SSH 客户端配置（`~/.ssh/config`）可简化远程访问命令，只需 `ssh macmini` 即可登录
|
||||
|
||||
## Key Quotes
|
||||
> "macOS 默认 `/opt` 需要手动创建" — 说明了 macOS 与 Linux 目录结构的差异，需手动初始化系统目录
|
||||
> "xattr -rd com.apple.quarantine ." — macOS 特有的安全限制解除命令，针对整个目录递归执行
|
||||
> "launchd（推荐开机自启）" — macOS 原生服务管理器，是进程持久化的推荐方案
|
||||
> "ssh macmini" — SSH 客户端配置后的简化登录命令，通过 `~/.ssh/config` 定义 Host 别名
|
||||
|
||||
## Key Concepts
|
||||
- [[内网穿透]]：通过反向隧道技术，使公网用户能够访问处于 NAT 或防火墙后的内网服务
|
||||
- [[frp]]：Fast Reverse Proxy，开源内网穿透工具，包含 frps（服务端）和 frpc（客户端）
|
||||
- [[TCP隧道]]：基于 TCP 协议的端口转发机制，将本地端口映射到远程服务器
|
||||
- [[launchd]]：macOS 原生服务管理器，用于管理系统级和用户级守护进程
|
||||
- [[SSH隧道]]：通过 SSH 协议建立的加密隧道，实现安全的远程端口转发
|
||||
|
||||
## Key Entities
|
||||
- [[Mac Mini M4]]：Apple Silicon Mac Mini，作为家庭服务器运行 FRP 客户端
|
||||
- [[VPS]]：公网虚拟专用服务器，运行 frps 作为内网穿透的中转站（IP: 192.227.222.142）
|
||||
- [[frpc]]：FRP 客户端程序，运行在 Mac Mini 上，建立与 frps 的连接
|
||||
- [[frps]]：FRP 服务端程序，运行在 VPS 上，接收公网请求并转发到 frpc
|
||||
- [[Gatekeeper]]：macOS 安全机制，阻止未签名应用运行
|
||||
- [[UFW防火墙]]：VPS 上的防火墙，需开放 FRP 映射端口
|
||||
|
||||
## Connections
|
||||
- [[Mac Mini M4]] ← runs_on ← [[frpc]]
|
||||
- [[VPS]] ← runs_on ← [[frps]]
|
||||
- [[frpc]] ← creates_tunnel ← [[frps]]
|
||||
- [[内网穿透]] ← enables ← [[远程SSH访问]]
|
||||
- [[launchd]] ← manages ← [[frpc]] 进程生命周期
|
||||
- [[Gatekeeper]] ← blocks ← [[frpc]] (需解除)
|
||||
- [[UFW防火墙]] ← controls_access ← [[SSH隧道]]（需开放 remotePort 60026）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
## Environment Details
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 系统 | macOS（Mac Mini M4）|
|
||||
| 架构 | Apple Silicon (ARM64) |
|
||||
| 软件 | FRP 0.65.0 |
|
||||
| 安装目录 | `/opt/frp/frp_0.65.0_darwin_arm64` |
|
||||
| 客户端程序 | `frpc` |
|
||||
| 配置文件 | `frpc.toml` |
|
||||
| frps服务器 | 192.227.222.142:7000 |
|
||||
| frps映射端口 | 6000（SSH），60026（实际案例端口）|
|
||||
|
||||
## Installation Steps
|
||||
1. 创建安装目录：`sudo mkdir -p /opt/frp && sudo chown -R $(whoami) /opt/frp`
|
||||
2. 下载 ARM64 版本：`wget https://github.com/fatedier/frp/releases/download/v0.65.0/frp_0.65.0_darwin_arm64.tar.gz`
|
||||
3. 解压：`tar -xzf frp_0.65.0_darwin_arm64.tar.gz`
|
||||
4. 解除 Gatekeeper：`xattr -rd com.apple.quarantine .`
|
||||
5. 配置 frpc.toml：设置 serverAddr、serverPort、auth.token 和 proxies
|
||||
6. 启动 frpc：`./frpc -c frpc.toml`
|
||||
|
||||
## Background Running Methods
|
||||
1. **tmux**（推荐开发环境）：创建持久会话，断开 SSH 后仍保持运行
|
||||
2. **nohup**（简单后台）：重定向输出到日志文件，适合简单部署
|
||||
3. **launchd**（生产环境）：系统级服务，开机自启，推荐使用 plist 配置
|
||||
|
||||
## Best Practices
|
||||
- 统一安装路径：`/opt/frp/<version>` 便于版本管理
|
||||
- 创建软链接：`ln -sfn /opt/frp/frp_0.65.0_darwin_arm64 /opt/frp/current` 简化启动命令
|
||||
- 日志独立存储：配置 StandardOutPath 和 StandardErrorPath 分离日志
|
||||
- 进程守护：使用 launchd KeepAlive=true 确保服务持续运行
|
||||
|
||||
## SSH 远程访问案例（完整配置）
|
||||
|
||||
### 网络架构
|
||||
```
|
||||
本地 Mac Mini
|
||||
│ SSH 22
|
||||
│
|
||||
frpc 客户端
|
||||
│ FRP 隧道
|
||||
│
|
||||
远端 VPS (frps)
|
||||
│ 60026
|
||||
│
|
||||
公网 SSH 访问：ssh username@VPS_IP -p 60026
|
||||
```
|
||||
|
||||
### VPS 防火墙配置（UFW）
|
||||
```bash
|
||||
sudo ufw allow 60026
|
||||
sudo ufw status
|
||||
# 输出：60026/tcp ALLOW Anywhere
|
||||
```
|
||||
|
||||
### frpc.toml SSH 代理配置
|
||||
```toml
|
||||
serverAddr = "VPS_IP"
|
||||
serverPort = 7000
|
||||
|
||||
auth.method = "token"
|
||||
auth.token = "your_token"
|
||||
|
||||
[[proxies]]
|
||||
name = "macmini-ssh"
|
||||
type = "tcp"
|
||||
localIP = "127.0.0.1"
|
||||
localPort = 22
|
||||
remotePort = 60026
|
||||
```
|
||||
|
||||
### SSH 客户端配置（~/.ssh/config）
|
||||
```ssh-config
|
||||
Host macmini
|
||||
HostName VPS_IP
|
||||
Port 60026
|
||||
User billy
|
||||
```
|
||||
|
||||
配置后可直接使用 `ssh macmini` 登录 Mac Mini，无需记忆 IP 和端口。
|
||||
---
|
||||
title: "Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记"
|
||||
type: source
|
||||
tags: [frp, frpc, gatekeeper, mac-mini, macos, arm64]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Mac Mini 安装 FRP 0.65.0（ARM64）操作笔记.md]]
|
||||
|
||||
## Summary (用中文描述)
|
||||
- **核心主题**：在 Apple Silicon（ARM64）Mac Mini M4 上安装配置 FRP 0.65.0 内网穿透客户端，实现通过公网 VPS 远程访问本地服务
|
||||
- **问题域**：macOS 服务器化运维、内网穿透、远程访问、SSH 安全隧道
|
||||
- **方法/机制**：通过 FRP（frpc）客户端连接远程 VPS（frps）建立反向隧道，结合 tmux/nohup/launchd 三种方式实现后台持久运行；通过 SSH 客户端配置简化远程访问
|
||||
- **结论/价值**：提供完整的 Mac Mini 服务器化运维指南，包含 macOS 特有障碍（Gatekeeper）的解决方案和 SSH 客户端优化配置
|
||||
|
||||
## Key Claims (用中文描述)
|
||||
- macOS 默认 `/opt` 目录需要手动创建并授权才能使用
|
||||
- macOS Gatekeeper 会阻止未签名程序运行，必须通过 `xattr -rd com.apple.quarantine .` 解除限制
|
||||
- launchd 是 macOS 推荐的开机自启服务管理方式，可通过 `launchctl` 管理生命周期
|
||||
- 软链接（symlink）策略可实现 FRP 版本无缝切换
|
||||
- SSH 客户端配置（`~/.ssh/config`）可简化远程访问命令，只需 `ssh macmini` 即可登录
|
||||
|
||||
## Key Quotes
|
||||
> "macOS 默认 `/opt` 需要手动创建" — 说明了 macOS 与 Linux 目录结构的差异，需手动初始化系统目录
|
||||
> "xattr -rd com.apple.quarantine ." — macOS 特有的安全限制解除命令，针对整个目录递归执行
|
||||
> "launchd（推荐开机自启）" — macOS 原生服务管理器，是进程持久化的推荐方案
|
||||
> "ssh macmini" — SSH 客户端配置后的简化登录命令，通过 `~/.ssh/config` 定义 Host 别名
|
||||
|
||||
## Key Concepts
|
||||
- [[内网穿透]]：通过反向隧道技术，使公网用户能够访问处于 NAT 或防火墙后的内网服务
|
||||
- [[frp]]：Fast Reverse Proxy，开源内网穿透工具，包含 frps（服务端）和 frpc（客户端）
|
||||
- [[TCP隧道]]：基于 TCP 协议的端口转发机制，将本地端口映射到远程服务器
|
||||
- [[launchd]]：macOS 原生服务管理器，用于管理系统级和用户级守护进程
|
||||
- [[SSH隧道]]：通过 SSH 协议建立的加密隧道，实现安全的远程端口转发
|
||||
|
||||
## Key Entities
|
||||
- [[Mac Mini M4]]：Apple Silicon Mac Mini，作为家庭服务器运行 FRP 客户端
|
||||
- [[VPS]]：公网虚拟专用服务器，运行 frps 作为内网穿透的中转站（IP: 192.227.222.142）
|
||||
- [[frpc]]：FRP 客户端程序，运行在 Mac Mini 上，建立与 frps 的连接
|
||||
- [[frps]]：FRP 服务端程序，运行在 VPS 上，接收公网请求并转发到 frpc
|
||||
- [[Gatekeeper]]：macOS 安全机制，阻止未签名应用运行
|
||||
- [[UFW防火墙]]：VPS 上的防火墙，需开放 FRP 映射端口
|
||||
|
||||
## Connections
|
||||
- [[Mac Mini M4]] ← runs_on ← [[frpc]]
|
||||
- [[VPS]] ← runs_on ← [[frps]]
|
||||
- [[frpc]] ← creates_tunnel ← [[frps]]
|
||||
- [[内网穿透]] ← enables ← [[远程SSH访问]]
|
||||
- [[launchd]] ← manages ← [[frpc]] 进程生命周期
|
||||
- [[Gatekeeper]] ← blocks ← [[frpc]] (需解除)
|
||||
- [[UFW防火墙]] ← controls_access ← [[SSH隧道]]（需开放 remotePort 60026）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
## Environment Details
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 系统 | macOS（Mac Mini M4）|
|
||||
| 架构 | Apple Silicon (ARM64) |
|
||||
| 软件 | FRP 0.65.0 |
|
||||
| 安装目录 | `/opt/frp/frp_0.65.0_darwin_arm64` |
|
||||
| 客户端程序 | `frpc` |
|
||||
| 配置文件 | `frpc.toml` |
|
||||
| frps服务器 | 192.227.222.142:7000 |
|
||||
| frps映射端口 | 6000（SSH），60026（实际案例端口）|
|
||||
|
||||
## Installation Steps
|
||||
1. 创建安装目录：`sudo mkdir -p /opt/frp && sudo chown -R $(whoami) /opt/frp`
|
||||
2. 下载 ARM64 版本：`wget https://github.com/fatedier/frp/releases/download/v0.65.0/frp_0.65.0_darwin_arm64.tar.gz`
|
||||
3. 解压：`tar -xzf frp_0.65.0_darwin_arm64.tar.gz`
|
||||
4. 解除 Gatekeeper：`xattr -rd com.apple.quarantine .`
|
||||
5. 配置 frpc.toml：设置 serverAddr、serverPort、auth.token 和 proxies
|
||||
6. 启动 frpc：`./frpc -c frpc.toml`
|
||||
|
||||
## Background Running Methods
|
||||
1. **tmux**（推荐开发环境）：创建持久会话，断开 SSH 后仍保持运行
|
||||
2. **nohup**（简单后台）：重定向输出到日志文件，适合简单部署
|
||||
3. **launchd**（生产环境）：系统级服务，开机自启，推荐使用 plist 配置
|
||||
|
||||
## Best Practices
|
||||
- 统一安装路径：`/opt/frp/<version>` 便于版本管理
|
||||
- 创建软链接：`ln -sfn /opt/frp/frp_0.65.0_darwin_arm64 /opt/frp/current` 简化启动命令
|
||||
- 日志独立存储：配置 StandardOutPath 和 StandardErrorPath 分离日志
|
||||
- 进程守护：使用 launchd KeepAlive=true 确保服务持续运行
|
||||
|
||||
## SSH 远程访问案例（完整配置）
|
||||
|
||||
### 网络架构
|
||||
```
|
||||
本地 Mac Mini
|
||||
│ SSH 22
|
||||
│
|
||||
frpc 客户端
|
||||
│ FRP 隧道
|
||||
│
|
||||
远端 VPS (frps)
|
||||
│ 60026
|
||||
│
|
||||
公网 SSH 访问：ssh username@VPS_IP -p 60026
|
||||
```
|
||||
|
||||
### VPS 防火墙配置（UFW）
|
||||
```bash
|
||||
sudo ufw allow 60026
|
||||
sudo ufw status
|
||||
# 输出：60026/tcp ALLOW Anywhere
|
||||
```
|
||||
|
||||
### frpc.toml SSH 代理配置
|
||||
```toml
|
||||
serverAddr = "VPS_IP"
|
||||
serverPort = 7000
|
||||
|
||||
auth.method = "token"
|
||||
auth.token = "your_token"
|
||||
|
||||
[[proxies]]
|
||||
name = "macmini-ssh"
|
||||
type = "tcp"
|
||||
localIP = "127.0.0.1"
|
||||
localPort = 22
|
||||
remotePort = 60026
|
||||
```
|
||||
|
||||
### SSH 客户端配置（~/.ssh/config）
|
||||
```ssh-config
|
||||
Host macmini
|
||||
HostName VPS_IP
|
||||
Port 60026
|
||||
User billy
|
||||
```
|
||||
|
||||
配置后可直接使用 `ssh macmini` 登录 Mac Mini，无需记忆 IP 和端口。
|
||||
|
||||
@@ -1,41 +1,41 @@
|
||||
---
|
||||
title: "macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）"
|
||||
type: source
|
||||
tags: [obsidian, openclaw, symbolic-link, macos]
|
||||
date:
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：macOS 下为 OpenClaw 隐藏目录创建和解除符号链接，使 Finder / Obsidian 可直接访问
|
||||
- 问题域：OpenClaw 默认使用 `~/.openclaw` 隐藏目录，不便于文件管理器直接操作
|
||||
- 方法/机制：通过 `ln -s` 创建符号链接，将隐藏目录映射为可见目录 `~/openclaw`；通过 `rm` 删除链接文件而非真实目录
|
||||
- 结论/价值：实现 OpenClaw 与 Obsidian 共用同一数据目录，无需复制文件，同时保留原 OpenClaw 的正常功能
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- OpenClaw 默认隐藏目录 `~/.openclaw` 不便于 Finder 或 Obsidian 直接访问
|
||||
- 使用 `ln -s ~/.openclaw ~/openclaw` 创建符号链接后，Obsidian 可将 `~/openclaw` 作为 Vault 打开
|
||||
- 使用 `rm ~/openclaw` 仅删除链接文件，不会影响真实目录 `~/.openclaw` 中的数据
|
||||
- 推荐长期方案：建立可见目录 `~/openclaw` 作为实际存储，反向链接 `~/.openclaw -> ~/openclaw`，便于 Git 管理和 Finder 访问
|
||||
|
||||
## Key Quotes
|
||||
> `ln -s ~/.openclaw ~/openclaw` — 创建符号链接的标准命令，将隐藏目录映射为可见目录
|
||||
> `rm ~/openclaw` — 删除符号链接（注意：不会删除真实目录中的数据）
|
||||
> `⚠️ 该操作只会删除链接文件，不会删除真实目录` — 强调操作安全性
|
||||
|
||||
## Key Concepts
|
||||
- [[SymbolicLink]]：Unix/Linux/macOS 中的符号链接（Symlink），是一种特殊类型的文件，指向另一个文件或目录路径
|
||||
- [[ObsidianVault]]：Obsidian 知识库的核心概念，以本地文件夹为单位的笔记管理方式
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：AI Agent 管理工具，默认使用隐藏目录存储记忆、Skills、Prompts 等数据
|
||||
- [[Obsidian]]：本地 Markdown 笔记应用，支持将任意文件夹作为 Vault 使用
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] ← 使用 ← [[SymbolicLink]]
|
||||
- [[Obsidian]] ← 访问 ← [[OpenClaw]]（通过 [[SymbolicLink]] 映射后的可见目录）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容
|
||||
---
|
||||
title: "macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）"
|
||||
type: source
|
||||
tags: [obsidian, openclaw, symbolic-link, macos]
|
||||
date:
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/macOS 创建与解除 Symbolic Link（OpenClaw 目录映射）.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：macOS 下为 OpenClaw 隐藏目录创建和解除符号链接，使 Finder / Obsidian 可直接访问
|
||||
- 问题域：OpenClaw 默认使用 `~/.openclaw` 隐藏目录，不便于文件管理器直接操作
|
||||
- 方法/机制：通过 `ln -s` 创建符号链接，将隐藏目录映射为可见目录 `~/openclaw`；通过 `rm` 删除链接文件而非真实目录
|
||||
- 结论/价值：实现 OpenClaw 与 Obsidian 共用同一数据目录，无需复制文件，同时保留原 OpenClaw 的正常功能
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- OpenClaw 默认隐藏目录 `~/.openclaw` 不便于 Finder 或 Obsidian 直接访问
|
||||
- 使用 `ln -s ~/.openclaw ~/openclaw` 创建符号链接后，Obsidian 可将 `~/openclaw` 作为 Vault 打开
|
||||
- 使用 `rm ~/openclaw` 仅删除链接文件，不会影响真实目录 `~/.openclaw` 中的数据
|
||||
- 推荐长期方案：建立可见目录 `~/openclaw` 作为实际存储，反向链接 `~/.openclaw -> ~/openclaw`，便于 Git 管理和 Finder 访问
|
||||
|
||||
## Key Quotes
|
||||
> `ln -s ~/.openclaw ~/openclaw` — 创建符号链接的标准命令，将隐藏目录映射为可见目录
|
||||
> `rm ~/openclaw` — 删除符号链接（注意：不会删除真实目录中的数据）
|
||||
> `⚠️ 该操作只会删除链接文件，不会删除真实目录` — 强调操作安全性
|
||||
|
||||
## Key Concepts
|
||||
- [[SymbolicLink]]：Unix/Linux/macOS 中的符号链接（Symlink），是一种特殊类型的文件，指向另一个文件或目录路径
|
||||
- [[ObsidianVault]]：Obsidian 知识库的核心概念，以本地文件夹为单位的笔记管理方式
|
||||
|
||||
## Key Entities
|
||||
- [[OpenClaw]]：AI Agent 管理工具，默认使用隐藏目录存储记忆、Skills、Prompts 等数据
|
||||
- [[Obsidian]]：本地 Markdown 笔记应用，支持将任意文件夹作为 Vault 使用
|
||||
|
||||
## Connections
|
||||
- [[OpenClaw]] ← 使用 ← [[SymbolicLink]]
|
||||
- [[Obsidian]] ← 访问 ← [[OpenClaw]]（通过 [[SymbolicLink]] 映射后的可见目录）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容
|
||||
|
||||
@@ -1,59 +1,59 @@
|
||||
---
|
||||
title: "Public vs Private vs Hybrid Cloud Differences Explained"
|
||||
type: source
|
||||
tags: [cloud-computing, cloud-strategy, infrastructure]
|
||||
date: 2025-06-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public vs Private vs Hybrid Cloud Differences Explained]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- **核心主题：** 公有云、私有云与混合云三种云计算部署模型的核心差异、优缺点及适用场景对比
|
||||
- **问题域：** 企业如何根据安全、成本、可扩展性、合规等需求选择合适的云部署模式
|
||||
- **方法/机制：** 系统性地从定义、优势、劣势、适用场景四个维度对比三种云模型；强调混合云作为折中方案的价值；提出"共享责任模型"概念
|
||||
- **结论/价值：** 三种云模型各有优劣，企业应根据工作负载特点制定有意图（intentional）的云策略，而非简单选择某一模型
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **公有云** 通过多租户共享模式提供高弹性、低成本、快速上线的计算服务，但在大规模企业场景下 TCO 可能指数级上升，且安全性和合规控制最弱
|
||||
- **私有云** 为单一组织提供专用环境，带来更高的安全性、控制力和合规灵活性，但成本最高、管理复杂、对远程用户不够友好
|
||||
- **混合云** 通过在同一架构中组合公私云实现"安全与扩展兼得"——敏感工作负载在私有云，普通负载在公有云，兼顾成本效率与安全韧性
|
||||
- **云选择决策** 应以工作负载需求为驱动，基于安全性、性能、成本三大维度制定有意图的云策略，且需持续评估和调整
|
||||
|
||||
## Key Quotes
|
||||
> "The public cloud is the shared cloud. In this model, third-party providers deliver storage, computing power, and applications to multiple users." — 公有云的定义：第三方提供商向多用户交付共享资源
|
||||
|
||||
> "The private cloud is dedicated to your organization, which you access over a secure private network." — 私有云的定义：组织专用的安全私有网络访问环境
|
||||
|
||||
> "The hybrid cloud is a computing environment that uses both the public and private cloud models, sharing data and apps between the two to take advantage of the benefits that each provides." — 混合云的定义：融合两种模型，通过数据和应用在两者间的共享实现优势互补
|
||||
|
||||
> "No matter which cloud environment you work in, your problems don't go away. Though you're purchasing services from third-party vendors, you still have to do your due diligence." — 共享责任模型：无论哪种云环境，用户组织仍需对访问控制、云安全和灾难恢复承担最终责任
|
||||
|
||||
## Key Concepts
|
||||
- [[CloudComputing]]：通过互联网远程使用第三方服务器上的计算资源，无需本地部署硬件
|
||||
- [[PublicCloud]]：多租户共享模式，第三方提供商向多个组织交付存储、计算能力和应用，按用量付费
|
||||
- [[PrivateCloud]]：单一组织专用的云环境，通过安全私有网络访问，可本地托管或第三方管理，提供更高安全性、控制力和合规性
|
||||
- [[HybridCloud]]：同时使用公有云和私有云的计算环境，数据和应用在两者间共享，根据安全、性能、成本需求分配工作负载
|
||||
- [[SaaS-PaaS-IaaS]]：云计算服务交付模式的三层——软件即服务、平台即服务、基础设施即服务
|
||||
- [[SharedResponsibilityModel]]：云安全责任分配模型——供应商负责底层基础设施灵活性与敏捷性，用户组织负责访问控制、安全加密和灾难恢复规划
|
||||
- [[CloudStrategy]]：有意图的云战略——从工作负载需求出发，权衡公私混合各模型利弊，制定并持续调整的云部署策略
|
||||
|
||||
## Key Entities
|
||||
- [[BMC]]：BMC Software — 源文章的发布机构，全球企业软件公司，为 Forbes Global 50 中 86% 的企业提供自动化应用、系统和服务
|
||||
- BMC Helix：独立运营的公司，帮助企业将 AI 转化为行动
|
||||
- RaaS（Ransomware as a Service）：勒索软件即服务——网络犯罪分子利用云基础设施的"犯罪即服务"模式
|
||||
|
||||
## Connections
|
||||
- [[PublicCloud]] ← extends ← [[CloudComputing]]
|
||||
- [[PrivateCloud]] ← extends ← [[CloudComputing]]
|
||||
- [[HybridCloud]] ← extends ← [[CloudComputing]]
|
||||
- [[HybridCloud]] ← combines ← [[PublicCloud]] + [[PrivateCloud]]
|
||||
- [[CloudStrategy]] ← drives ← [[PublicCloud]] + [[PrivateCloud]] + [[HybridCloud]]
|
||||
- [[SharedResponsibilityModel]] ← applies_to ← [[PublicCloud]] + [[PrivateCloud]] + [[HybridCloud]]
|
||||
- [[SaaS-PaaS-IaaS]] ← delivered_by ← [[PublicCloud]] + [[PrivateCloud]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[CloudComputing]]（来源：[[cloud-maturity-model]]）可能存在视角冲突：
|
||||
- **冲突点：** 本文强调"云消除了基础设施管理复杂性"，而云成熟度模型强调云迁移后运维复杂性的增加
|
||||
- **当前观点：** 公有云"减少复杂度"——供应商负责维护最新硬件和应用版本，降低内部 IT 专业知识需求
|
||||
- **对方观点：** 实际云迁移会增加运维复杂度——多租户安全治理、成本追踪、跨环境集成等问题需要专门的云运维能力
|
||||
---
|
||||
title: "Public vs Private vs Hybrid Cloud Differences Explained"
|
||||
type: source
|
||||
tags: [cloud-computing, cloud-strategy, infrastructure]
|
||||
date: 2025-06-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/Public vs Private vs Hybrid Cloud Differences Explained]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- **核心主题：** 公有云、私有云与混合云三种云计算部署模型的核心差异、优缺点及适用场景对比
|
||||
- **问题域：** 企业如何根据安全、成本、可扩展性、合规等需求选择合适的云部署模式
|
||||
- **方法/机制：** 系统性地从定义、优势、劣势、适用场景四个维度对比三种云模型；强调混合云作为折中方案的价值；提出"共享责任模型"概念
|
||||
- **结论/价值：** 三种云模型各有优劣，企业应根据工作负载特点制定有意图（intentional）的云策略，而非简单选择某一模型
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **公有云** 通过多租户共享模式提供高弹性、低成本、快速上线的计算服务，但在大规模企业场景下 TCO 可能指数级上升，且安全性和合规控制最弱
|
||||
- **私有云** 为单一组织提供专用环境，带来更高的安全性、控制力和合规灵活性，但成本最高、管理复杂、对远程用户不够友好
|
||||
- **混合云** 通过在同一架构中组合公私云实现"安全与扩展兼得"——敏感工作负载在私有云，普通负载在公有云，兼顾成本效率与安全韧性
|
||||
- **云选择决策** 应以工作负载需求为驱动，基于安全性、性能、成本三大维度制定有意图的云策略，且需持续评估和调整
|
||||
|
||||
## Key Quotes
|
||||
> "The public cloud is the shared cloud. In this model, third-party providers deliver storage, computing power, and applications to multiple users." — 公有云的定义：第三方提供商向多用户交付共享资源
|
||||
|
||||
> "The private cloud is dedicated to your organization, which you access over a secure private network." — 私有云的定义：组织专用的安全私有网络访问环境
|
||||
|
||||
> "The hybrid cloud is a computing environment that uses both the public and private cloud models, sharing data and apps between the two to take advantage of the benefits that each provides." — 混合云的定义：融合两种模型，通过数据和应用在两者间的共享实现优势互补
|
||||
|
||||
> "No matter which cloud environment you work in, your problems don't go away. Though you're purchasing services from third-party vendors, you still have to do your due diligence." — 共享责任模型：无论哪种云环境，用户组织仍需对访问控制、云安全和灾难恢复承担最终责任
|
||||
|
||||
## Key Concepts
|
||||
- [[CloudComputing]]：通过互联网远程使用第三方服务器上的计算资源，无需本地部署硬件
|
||||
- [[PublicCloud]]：多租户共享模式，第三方提供商向多个组织交付存储、计算能力和应用，按用量付费
|
||||
- [[PrivateCloud]]：单一组织专用的云环境，通过安全私有网络访问，可本地托管或第三方管理，提供更高安全性、控制力和合规性
|
||||
- [[HybridCloud]]：同时使用公有云和私有云的计算环境，数据和应用在两者间共享，根据安全、性能、成本需求分配工作负载
|
||||
- [[SaaS-PaaS-IaaS]]：云计算服务交付模式的三层——软件即服务、平台即服务、基础设施即服务
|
||||
- [[SharedResponsibilityModel]]：云安全责任分配模型——供应商负责底层基础设施灵活性与敏捷性，用户组织负责访问控制、安全加密和灾难恢复规划
|
||||
- [[CloudStrategy]]：有意图的云战略——从工作负载需求出发，权衡公私混合各模型利弊，制定并持续调整的云部署策略
|
||||
|
||||
## Key Entities
|
||||
- [[BMC]]：BMC Software — 源文章的发布机构，全球企业软件公司，为 Forbes Global 50 中 86% 的企业提供自动化应用、系统和服务
|
||||
- BMC Helix：独立运营的公司，帮助企业将 AI 转化为行动
|
||||
- RaaS（Ransomware as a Service）：勒索软件即服务——网络犯罪分子利用云基础设施的"犯罪即服务"模式
|
||||
|
||||
## Connections
|
||||
- [[PublicCloud]] ← extends ← [[CloudComputing]]
|
||||
- [[PrivateCloud]] ← extends ← [[CloudComputing]]
|
||||
- [[HybridCloud]] ← extends ← [[CloudComputing]]
|
||||
- [[HybridCloud]] ← combines ← [[PublicCloud]] + [[PrivateCloud]]
|
||||
- [[CloudStrategy]] ← drives ← [[PublicCloud]] + [[PrivateCloud]] + [[HybridCloud]]
|
||||
- [[SharedResponsibilityModel]] ← applies_to ← [[PublicCloud]] + [[PrivateCloud]] + [[HybridCloud]]
|
||||
- [[SaaS-PaaS-IaaS]] ← delivered_by ← [[PublicCloud]] + [[PrivateCloud]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[CloudComputing]]（来源：[[cloud-maturity-model]]）可能存在视角冲突：
|
||||
- **冲突点：** 本文强调"云消除了基础设施管理复杂性"，而云成熟度模型强调云迁移后运维复杂性的增加
|
||||
- **当前观点：** 公有云"减少复杂度"——供应商负责维护最新硬件和应用版本，降低内部 IT 专业知识需求
|
||||
- **对方观点：** 实际云迁移会增加运维复杂度——多租户安全治理、成本追踪、跨环境集成等问题需要专门的云运维能力
|
||||
|
||||
@@ -1,73 +1,73 @@
|
||||
---
|
||||
title: "RTO vs RPO: Key Differences for Modern Disaster Recovery"
|
||||
type: source
|
||||
tags: [cloud-devops, disaster-recovery, sre, feature-flags, continuous-delivery]
|
||||
date: 2019-01-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/RTO vs RPO Key Differences for Modern Disaster Recovery]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：RTO（Recovery Time Objective）和 RPO（Recovery Point Objective）在现代灾难恢复和持续交付中的关键区别与实践应用
|
||||
- 问题域：云原生/DevOps 环境下的灾难恢复规划、软件部署风险管控、Feature Flag 驱动的微恢复策略
|
||||
- 方法/机制：
|
||||
- RTO 衡量系统停机时长容忍度，RPO 衡量数据丢失容忍度
|
||||
- 应用分层（Tier 1/2/3）分配差异化恢复目标
|
||||
- Feature Flag 实现部署与发布解耦，支持渐进式灰度发布和即时 Kill Switch
|
||||
- Feature Flag 将 RTO 从"小时级回滚"缩短至"秒级开关切换"
|
||||
- 结论/价值：预防优于恢复；Feature Flag 是现代持续交付中实现激进 RTO/RPO 目标的最佳投资回报比方案
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Feature Flag 将部署（Deploy）与发布（Release）解耦，使回滚从"紧急代码部署（小时级）"变为"配置变更（秒级）"
|
||||
- 渐进式灰度发布（1%→5%→25%→100%）将故障影响范围限制在早期阶段，RTO 可降至秒级
|
||||
- 不能单独优化 RTO 或 RPO——高频备份（优秀 RPO）+ 慢速恢复（糟糕 RTO）等于无用功
|
||||
- 不同的应用/功能应拥有不同的恢复目标（Core Payment: 秒级 RTO + 零 RPO；Beta 功能: 分钟级 RTO）
|
||||
- 成本效益原则：若停机一小时损失 $10K，不要每年花 $100K 基础设施去预防它
|
||||
|
||||
## Key Quotes
|
||||
> "RTO is about speed: how fast you get back online. RPO is about data: how much you can afford to lose." — 核心概念区分
|
||||
> "Deploy whenever you want, release when you're ready." — Feature Flag 解耦哲学
|
||||
> "Having backups every 30 seconds (a great RPO) doesn't help if it takes you 6 hours to restore from those backups (a terrible RTO)." — RTO/RPO 必须同时优化
|
||||
> "Prevention beats cure: the best disaster recovery solution is the one you'll actually use when things go wrong." — HP 案例引出核心结论
|
||||
|
||||
## Key Concepts
|
||||
- [[概念页面待创建]]：**RTO（Recovery Time Objective）**——系统允许的最大停机时长，从故障发生时刻开始计时
|
||||
- [[概念页面待创建]]：**RPO（Recovery Point Objective）**——允许丢失的最大数据量，从上一备份时刻向前测量
|
||||
- [[概念页面待创建]]：**Feature Flag**——通过条件分支控制功能上线，无需重新部署即可启用/禁用功能
|
||||
- [[概念页面待创建]]：**Kill Switch**——紧急禁用故障功能的即时开关，Feature Flag 驱动的 RTO 保险机制
|
||||
- [[概念页面待创建]]：**Progressive Rollout**——渐进式功能发布（1%/5%/25%/100%），限制故障影响范围
|
||||
- [[概念页面待创建]]：**Micro-Recovery**——基于 Feature Flag 的功能级回滚，而非整应用回滚
|
||||
|
||||
## Key Entities
|
||||
- [[实体页面待创建]]：**LaunchDarkly**——Feature Flag 管理平台，本文档的主要案例引用来源（HP、Christian Dior 等案例）
|
||||
- [[实体页面待创建]]：**Veeam / Acronis**——传统 DR 工具（备份/服务器镜像/跨区域复制），作为传统方案对照组
|
||||
|
||||
## Connections
|
||||
- [[what-i-know-about-cloud-service-delivery-1]] ← 包含 ← [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]（本文档是云服务交付"备份恢复与灾难管理"领域的具体展开）
|
||||
- [[devops-maturity-model-from-traditional-it-to-advanced-devops]] ← 支撑 ← [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]（DevOps 成熟度中"监控可观测性"和"错误预算"是 RTO/RPO 的量化手段）
|
||||
- [[cloud-devop-maturity-guideline]] ← 关联 ← [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]（DORA 四项指标中的 MTTR 直接对应 RTO）
|
||||
- [[continuous-delivery]]（概念尚待建立）← 核心应用场景 ← [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统 DR 思维存在框架冲突：
|
||||
- 冲突点：传统 DR 关注硬件灾难（火灾/断电/硬件故障），本文档认为现代高频部署场景下软件故障（Bug/错误迁移/AI 模型异常）才是主要风险
|
||||
- 当前观点：Feature Flag + Kill Switch + 渐进式发布比传统热备基础设施更有效且成本更低
|
||||
- 对方观点：传统 DR 基础设施（Veeam/Acronis + 多数据中心热备）仍是不可替代的硬件级保障
|
||||
- 注：两者并不互斥——软件层面用 Feature Flag 快速止血，基础设施层面仍需传统 DR 兜底
|
||||
|
||||
## Tier System Reference（应用分级体系）
|
||||
|
||||
| Tier | 示例 | RTO 目标 | RPO 目标 | 策略 |
|
||||
|------|------|---------|---------|------|
|
||||
| (1) Critical | 支付处理、用户认证、核心产品 | < 5 分钟 | < 1 分钟 | Feature Flag + 自动回滚 + 24/7 告警 |
|
||||
| (2) Important | 管理后台、报表、客户支持工具 | < 1 小时 | < 15 分钟 | Feature Flag + 手动回滚 + 工作时间监控 |
|
||||
| (3) Nice-to-have | 内部工具、开发环境、文档站 | < 4 小时 | < 1 小时 | 基础监控 + 人工恢复流程 |
|
||||
|
||||
## LaunchDarkly Business Impact Data
|
||||
- HP：将回滚时间从"小时级"缩短至"分钟级"
|
||||
- Christian Dior：将 15 分钟回滚缩短为"即时开关切换"
|
||||
- 86% 的 LaunchDarkly 客户在一天内从故障中恢复
|
||||
- 42% 的 LaunchDarkly 客户在"小时级（甚至分钟级）"内恢复
|
||||
- 8% 客户运营成本降低超过 50%
|
||||
- 59% 客户运营成本降低 11%-50%
|
||||
---
|
||||
title: "RTO vs RPO: Key Differences for Modern Disaster Recovery"
|
||||
type: source
|
||||
tags: [cloud-devops, disaster-recovery, sre, feature-flags, continuous-delivery]
|
||||
date: 2019-01-18
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/RTO vs RPO Key Differences for Modern Disaster Recovery]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：RTO（Recovery Time Objective）和 RPO（Recovery Point Objective）在现代灾难恢复和持续交付中的关键区别与实践应用
|
||||
- 问题域：云原生/DevOps 环境下的灾难恢复规划、软件部署风险管控、Feature Flag 驱动的微恢复策略
|
||||
- 方法/机制：
|
||||
- RTO 衡量系统停机时长容忍度，RPO 衡量数据丢失容忍度
|
||||
- 应用分层（Tier 1/2/3）分配差异化恢复目标
|
||||
- Feature Flag 实现部署与发布解耦，支持渐进式灰度发布和即时 Kill Switch
|
||||
- Feature Flag 将 RTO 从"小时级回滚"缩短至"秒级开关切换"
|
||||
- 结论/价值：预防优于恢复；Feature Flag 是现代持续交付中实现激进 RTO/RPO 目标的最佳投资回报比方案
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Feature Flag 将部署（Deploy）与发布（Release）解耦，使回滚从"紧急代码部署（小时级）"变为"配置变更（秒级）"
|
||||
- 渐进式灰度发布（1%→5%→25%→100%）将故障影响范围限制在早期阶段，RTO 可降至秒级
|
||||
- 不能单独优化 RTO 或 RPO——高频备份（优秀 RPO）+ 慢速恢复（糟糕 RTO）等于无用功
|
||||
- 不同的应用/功能应拥有不同的恢复目标（Core Payment: 秒级 RTO + 零 RPO；Beta 功能: 分钟级 RTO）
|
||||
- 成本效益原则：若停机一小时损失 $10K，不要每年花 $100K 基础设施去预防它
|
||||
|
||||
## Key Quotes
|
||||
> "RTO is about speed: how fast you get back online. RPO is about data: how much you can afford to lose." — 核心概念区分
|
||||
> "Deploy whenever you want, release when you're ready." — Feature Flag 解耦哲学
|
||||
> "Having backups every 30 seconds (a great RPO) doesn't help if it takes you 6 hours to restore from those backups (a terrible RTO)." — RTO/RPO 必须同时优化
|
||||
> "Prevention beats cure: the best disaster recovery solution is the one you'll actually use when things go wrong." — HP 案例引出核心结论
|
||||
|
||||
## Key Concepts
|
||||
- [[概念页面待创建]]：**RTO（Recovery Time Objective）**——系统允许的最大停机时长，从故障发生时刻开始计时
|
||||
- [[概念页面待创建]]：**RPO（Recovery Point Objective）**——允许丢失的最大数据量，从上一备份时刻向前测量
|
||||
- [[概念页面待创建]]：**Feature Flag**——通过条件分支控制功能上线，无需重新部署即可启用/禁用功能
|
||||
- [[概念页面待创建]]：**Kill Switch**——紧急禁用故障功能的即时开关，Feature Flag 驱动的 RTO 保险机制
|
||||
- [[概念页面待创建]]：**Progressive Rollout**——渐进式功能发布（1%/5%/25%/100%），限制故障影响范围
|
||||
- [[概念页面待创建]]：**Micro-Recovery**——基于 Feature Flag 的功能级回滚，而非整应用回滚
|
||||
|
||||
## Key Entities
|
||||
- [[实体页面待创建]]：**LaunchDarkly**——Feature Flag 管理平台，本文档的主要案例引用来源（HP、Christian Dior 等案例）
|
||||
- [[实体页面待创建]]：**Veeam / Acronis**——传统 DR 工具（备份/服务器镜像/跨区域复制），作为传统方案对照组
|
||||
|
||||
## Connections
|
||||
- [[what-i-know-about-cloud-service-delivery-1]] ← 包含 ← [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]（本文档是云服务交付"备份恢复与灾难管理"领域的具体展开）
|
||||
- [[devops-maturity-model-from-traditional-it-to-advanced-devops]] ← 支撑 ← [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]（DevOps 成熟度中"监控可观测性"和"错误预算"是 RTO/RPO 的量化手段）
|
||||
- [[cloud-devop-maturity-guideline]] ← 关联 ← [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]（DORA 四项指标中的 MTTR 直接对应 RTO）
|
||||
- [[continuous-delivery]]（概念尚待建立）← 核心应用场景 ← [[rto-vs-rpo-key-differences-for-modern-disaster-recovery]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统 DR 思维存在框架冲突：
|
||||
- 冲突点：传统 DR 关注硬件灾难（火灾/断电/硬件故障），本文档认为现代高频部署场景下软件故障（Bug/错误迁移/AI 模型异常）才是主要风险
|
||||
- 当前观点：Feature Flag + Kill Switch + 渐进式发布比传统热备基础设施更有效且成本更低
|
||||
- 对方观点：传统 DR 基础设施（Veeam/Acronis + 多数据中心热备）仍是不可替代的硬件级保障
|
||||
- 注：两者并不互斥——软件层面用 Feature Flag 快速止血，基础设施层面仍需传统 DR 兜底
|
||||
|
||||
## Tier System Reference（应用分级体系）
|
||||
|
||||
| Tier | 示例 | RTO 目标 | RPO 目标 | 策略 |
|
||||
|------|------|---------|---------|------|
|
||||
| (1) Critical | 支付处理、用户认证、核心产品 | < 5 分钟 | < 1 分钟 | Feature Flag + 自动回滚 + 24/7 告警 |
|
||||
| (2) Important | 管理后台、报表、客户支持工具 | < 1 小时 | < 15 分钟 | Feature Flag + 手动回滚 + 工作时间监控 |
|
||||
| (3) Nice-to-have | 内部工具、开发环境、文档站 | < 4 小时 | < 1 小时 | 基础监控 + 人工恢复流程 |
|
||||
|
||||
## LaunchDarkly Business Impact Data
|
||||
- HP：将回滚时间从"小时级"缩短至"分钟级"
|
||||
- Christian Dior：将 15 分钟回滚缩短为"即时开关切换"
|
||||
- 86% 的 LaunchDarkly 客户在一天内从故障中恢复
|
||||
- 42% 的 LaunchDarkly 客户在"小时级（甚至分钟级）"内恢复
|
||||
- 8% 客户运营成本降低超过 50%
|
||||
- 59% 客户运营成本降低 11%-50%
|
||||
|
||||
@@ -1,58 +1,58 @@
|
||||
---
|
||||
title: "The Myths and Misconceptions About Cloud Computing | LinkedIn"
|
||||
type: source
|
||||
tags: [cloud-computing, misconceptions, cloud-security, cost-optimization]
|
||||
date: 2025-03-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/The Myths and Misconceptions About Cloud Computing LinkedIn]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：云计算领域的7大常见误解及其真相
|
||||
- 问题域：企业或个人在采用云计算时的认知误区
|
||||
- 方法/机制：通过逐一反驳误解，揭示云计算的实际能力与优势
|
||||
- 结论/价值：帮助决策者消除顾虑，正确认识云计算的安全性、成本效益和可靠性
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 云安全往往比本地解决方案更强大：主流云服务商投入大量资源于加密、防火墙、多因素认证，符合 ISO 27001、HIPAA、GDPR 等严苛标准
|
||||
- 云远不止是"别人的电脑"：云是由冗余、可扩展、高可用的数据中心网络组成，远超典型本地解决方案
|
||||
- 通过适当管理，云计算具有成本效益：采用按需付费模式、预留实例、自动扩展和无服务器计算可显著降低成本
|
||||
- 云服务提供强大的数据治理工具：组织可管理权限、加密数据、监控访问日志，支持混合云和多云部署
|
||||
- 各类规模的企业都能从云计算中受益：中小企业可享受灵活定价，无需大额前期投资即可使用企业级技术
|
||||
- 适当的规划可使云迁移顺利推进：分阶段迁移、混合云方案和专业迁移服务可降低风险
|
||||
- 主要云服务商提供高可用性和冗余：SLA 保证可用性通常超过 99.99%
|
||||
|
||||
## Key Quotes
|
||||
> "Leading cloud providers invest heavily in security measures, including encryption, firewalls, and multi-factor authentication." — 云服务商在安全措施上的持续投入
|
||||
|
||||
> "Cloud computing follows a pay-as-you-go model, allowing businesses to scale resources as needed." — 按需付费的灵活性
|
||||
|
||||
> "Major cloud providers offer service-level agreements (SLAs) that guarantee uptime, often exceeding 99.99%." — 服务等级协议保证高可用性
|
||||
|
||||
## Key Concepts
|
||||
- [[CloudComputing]]：通过互联网按需提供计算资源、存储和应用的服务模式
|
||||
- [[CloudSecurity]]：云环境下的安全实践，包括加密、MFA、安全合规认证
|
||||
- [[PayAsYouGo]]：按使用量付费的成本模型
|
||||
- [[HybridCloud]]：混合云，结合本地设施和公有云的部署模式
|
||||
- [[MultiCloud]]：多云战略，使用多个云服务商的服务
|
||||
- [[CloudMigration]]：将工作负载从本地迁移到云端的过程
|
||||
- [[HighAvailability]]：高可用性设计，确保服务持续运行
|
||||
- [[AutoScaling]]：根据负载自动调整资源的能力
|
||||
|
||||
## Key Entities
|
||||
- [[ISO27001]]：国际认可的信息安全管理标准
|
||||
- [[HIPAA]]：美国医疗保健信息保护法规
|
||||
- [[GDPR]]：欧盟通用数据保护条例
|
||||
|
||||
## Connections
|
||||
- [[CloudComputing]] ← topic ← [[The Myths and Misconceptions About Cloud Computing]]
|
||||
- [[CloudSecurity]] ← key_mechanism ← [[CloudComputing]]
|
||||
- [[PayAsYouGo]] ← cost_model ← [[CloudComputing]]
|
||||
- [[HybridCloud]] ← solution_type ← [[CloudMigration]]
|
||||
|
||||
## Contradictions
|
||||
- 与 On-Premises 相比的误解：
|
||||
- 冲突点：安全性、控制权、可靠性
|
||||
- 当前观点：云安全更强（专业团队 24/7 监控、自动更新）、数据控制完善、高可用 SLA
|
||||
- 对方观点：本地部署更安全、更可控、性能更稳定
|
||||
---
|
||||
title: "The Myths and Misconceptions About Cloud Computing | LinkedIn"
|
||||
type: source
|
||||
tags: [cloud-computing, misconceptions, cloud-security, cost-optimization]
|
||||
date: 2025-03-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/The Myths and Misconceptions About Cloud Computing LinkedIn]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：云计算领域的7大常见误解及其真相
|
||||
- 问题域：企业或个人在采用云计算时的认知误区
|
||||
- 方法/机制：通过逐一反驳误解，揭示云计算的实际能力与优势
|
||||
- 结论/价值：帮助决策者消除顾虑，正确认识云计算的安全性、成本效益和可靠性
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 云安全往往比本地解决方案更强大：主流云服务商投入大量资源于加密、防火墙、多因素认证，符合 ISO 27001、HIPAA、GDPR 等严苛标准
|
||||
- 云远不止是"别人的电脑"：云是由冗余、可扩展、高可用的数据中心网络组成，远超典型本地解决方案
|
||||
- 通过适当管理，云计算具有成本效益：采用按需付费模式、预留实例、自动扩展和无服务器计算可显著降低成本
|
||||
- 云服务提供强大的数据治理工具：组织可管理权限、加密数据、监控访问日志，支持混合云和多云部署
|
||||
- 各类规模的企业都能从云计算中受益：中小企业可享受灵活定价，无需大额前期投资即可使用企业级技术
|
||||
- 适当的规划可使云迁移顺利推进：分阶段迁移、混合云方案和专业迁移服务可降低风险
|
||||
- 主要云服务商提供高可用性和冗余：SLA 保证可用性通常超过 99.99%
|
||||
|
||||
## Key Quotes
|
||||
> "Leading cloud providers invest heavily in security measures, including encryption, firewalls, and multi-factor authentication." — 云服务商在安全措施上的持续投入
|
||||
|
||||
> "Cloud computing follows a pay-as-you-go model, allowing businesses to scale resources as needed." — 按需付费的灵活性
|
||||
|
||||
> "Major cloud providers offer service-level agreements (SLAs) that guarantee uptime, often exceeding 99.99%." — 服务等级协议保证高可用性
|
||||
|
||||
## Key Concepts
|
||||
- [[CloudComputing]]：通过互联网按需提供计算资源、存储和应用的服务模式
|
||||
- [[CloudSecurity]]：云环境下的安全实践，包括加密、MFA、安全合规认证
|
||||
- [[PayAsYouGo]]：按使用量付费的成本模型
|
||||
- [[HybridCloud]]：混合云，结合本地设施和公有云的部署模式
|
||||
- [[MultiCloud]]：多云战略，使用多个云服务商的服务
|
||||
- [[CloudMigration]]：将工作负载从本地迁移到云端的过程
|
||||
- [[HighAvailability]]：高可用性设计，确保服务持续运行
|
||||
- [[AutoScaling]]：根据负载自动调整资源的能力
|
||||
|
||||
## Key Entities
|
||||
- [[ISO27001]]：国际认可的信息安全管理标准
|
||||
- [[HIPAA]]：美国医疗保健信息保护法规
|
||||
- [[GDPR]]：欧盟通用数据保护条例
|
||||
|
||||
## Connections
|
||||
- [[CloudComputing]] ← topic ← [[The Myths and Misconceptions About Cloud Computing]]
|
||||
- [[CloudSecurity]] ← key_mechanism ← [[CloudComputing]]
|
||||
- [[PayAsYouGo]] ← cost_model ← [[CloudComputing]]
|
||||
- [[HybridCloud]] ← solution_type ← [[CloudMigration]]
|
||||
|
||||
## Contradictions
|
||||
- 与 On-Premises 相比的误解：
|
||||
- 冲突点：安全性、控制权、可靠性
|
||||
- 当前观点：云安全更强（专业团队 24/7 监控、自动更新）、数据控制完善、高可用 SLA
|
||||
- 对方观点：本地部署更安全、更可控、性能更稳定
|
||||
|
||||
@@ -1,54 +1,54 @@
|
||||
---
|
||||
title: "These 6 Linux Apps Let You Monitor System Resources in Style"
|
||||
type: source
|
||||
tags: [linux, system-monitoring, open-source, devops, tooling]
|
||||
date: 2025-12-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/These 6 Linux apps let you monitor system resources in style.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Linux 系统资源监控工具横向评测，推荐 6 款替代桌面环境默认资源管理器的应用
|
||||
- 问题域：Linux 用户需要比桌面默认资源管理器更轻量、更美观或功能更丰富的系统监控方案
|
||||
- 方法/机制：按 TUI（命令行文本界面）和 GUI 两大类，分别评测 6 款工具的功能与体验
|
||||
- 结论/价值：作者首推 **Btop++**（TUI 类），理由是兼具美观与可用性；GUI 类首选 **Mission Center**（类 Task Manager 体验）和 **Stacer**（功能最丰富）；TUI 工具在 SSH 远程场景下尤为实用
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Btop++：主体（TUI 监控工具）+ 机制（多面板布局、支持进程信号/Nice 值/主题切换）+ 结果（作者首选）
|
||||
- Htop：主体（TUI 进程监控）+ 机制（键盘驱动/F 键操作）+ 结果（适合追求极简流程监控的用户）
|
||||
- Glances：主体（轻量 TUI 监控）+ 机制（全键盘导航/k 键杀进程）+ 结果（最轻最快）
|
||||
- Bottom：主体（实时图形化资源监控）+ 机制（专注 CPU/网络/内存图表，非任务管理器）+ 结果（纯图形监控，无交互）
|
||||
- Mission Center：主体（GNOME 原生 GUI 资源管理器）+ 机制（性能/应用/服务三标签页，类 Task Manager）+ 结果（Debian/Ubuntu 仅有 Snap 包）
|
||||
- Stacer：主体（功能最全面的 GUI 资源管理器）+ 机制（仪表盘/进程/服务/启动项/APT 仓库/缓存清理）+ 结果（唯一支持桌面定制和垃圾清理的工具）
|
||||
|
||||
## Key Quotes
|
||||
> "TUI apps make the best resource monitors, in my opinion. They're snappy and responsive, even when the GUI is lagging." — 作者偏好 TUI 的核心理由
|
||||
> "Btop++ always gets my vote. It features a nice balance between usability and aesthetics." — Btop++ 推荐结论
|
||||
> "Mission Center is your friend" if you want something close to the Windows Task Manager — Mission Center 推荐定位
|
||||
|
||||
## Key Concepts
|
||||
- [[TUI]]：文本用户界面，通过终端运行，响应迅速，适合 SSH 远程场景
|
||||
- [[System-Monitoring]]：系统资源监控，涵盖 CPU、内存、存储、网络、进程等维度
|
||||
- [[Process-Management]]：进程管理，包括查看、搜索、终止、优先级调整
|
||||
|
||||
## Key Entities
|
||||
- [[Btop++]]：作者首选 TUI 资源监控器，支持 Pacman 安装和 Snap 包（Debian/Ubuntu）
|
||||
- [[Htop]]：经典 TUI 进程监控器，全键盘驱动，适合进程优先场景
|
||||
- [[Glances]]：极轻量 TUI 监控器，全键盘操作，适合资源受限环境
|
||||
- [[Bottom]]：专注实时图形化监控的工具，支持进程树视图，非交互式任务管理器
|
||||
- [[Mission-Center]]：GNOME 原生 GUI 资源管理器，提供性能/应用/服务三标签页
|
||||
- [[Stacer]]：功能最丰富的 GUI 资源管理器，支持缓存清理、启动项管理、APT 仓库配置
|
||||
- [[HowToGeek]]：文章来源的技术博客
|
||||
|
||||
## Connections
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] ← 应用层 ← [[These-6-Linux-Apps-Let-You-Monitor-System-Resources-in-Style]]：本文工具为单机能见度层，与 Prometheus/Grafana 企业监控方案互补
|
||||
- [[linux-运维必会的-150-个命令]] ← 关联 ← [[These-6-Linux-Apps-Let-You-Monitor-System-Resources-in-Style]]：系统监控是 Linux 运维基础技能，本文 6 款工具覆盖该技能核心场景
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] ← 对比 ← [[These-6-Linux-Apps-Let-You-Monitor-System-Resources-in-Style]]：企业级（Prometheus/Grafana）vs 轻量级（本文工具）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] 定位差异：
|
||||
- 冲突点：监控方案选择
|
||||
- 当前观点：单机能见度优先，用 Btop++ 或 Mission Center 快速定位问题
|
||||
- 对方观点：企业级基础设施需 Prometheus + Grafana 实现集中可观测性
|
||||
- 说明：两者面向不同场景，不构成直接冲突；建议单节点用本文工具，多节点/生产环境用 Prometheus/Grafana
|
||||
---
|
||||
title: "These 6 Linux Apps Let You Monitor System Resources in Style"
|
||||
type: source
|
||||
tags: [linux, system-monitoring, open-source, devops, tooling]
|
||||
date: 2025-12-16
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/These 6 Linux apps let you monitor system resources in style.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Linux 系统资源监控工具横向评测，推荐 6 款替代桌面环境默认资源管理器的应用
|
||||
- 问题域：Linux 用户需要比桌面默认资源管理器更轻量、更美观或功能更丰富的系统监控方案
|
||||
- 方法/机制：按 TUI（命令行文本界面）和 GUI 两大类，分别评测 6 款工具的功能与体验
|
||||
- 结论/价值：作者首推 **Btop++**（TUI 类），理由是兼具美观与可用性；GUI 类首选 **Mission Center**（类 Task Manager 体验）和 **Stacer**（功能最丰富）；TUI 工具在 SSH 远程场景下尤为实用
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Btop++：主体（TUI 监控工具）+ 机制（多面板布局、支持进程信号/Nice 值/主题切换）+ 结果（作者首选）
|
||||
- Htop：主体（TUI 进程监控）+ 机制（键盘驱动/F 键操作）+ 结果（适合追求极简流程监控的用户）
|
||||
- Glances：主体（轻量 TUI 监控）+ 机制（全键盘导航/k 键杀进程）+ 结果（最轻最快）
|
||||
- Bottom：主体（实时图形化资源监控）+ 机制（专注 CPU/网络/内存图表，非任务管理器）+ 结果（纯图形监控，无交互）
|
||||
- Mission Center：主体（GNOME 原生 GUI 资源管理器）+ 机制（性能/应用/服务三标签页，类 Task Manager）+ 结果（Debian/Ubuntu 仅有 Snap 包）
|
||||
- Stacer：主体（功能最全面的 GUI 资源管理器）+ 机制（仪表盘/进程/服务/启动项/APT 仓库/缓存清理）+ 结果（唯一支持桌面定制和垃圾清理的工具）
|
||||
|
||||
## Key Quotes
|
||||
> "TUI apps make the best resource monitors, in my opinion. They're snappy and responsive, even when the GUI is lagging." — 作者偏好 TUI 的核心理由
|
||||
> "Btop++ always gets my vote. It features a nice balance between usability and aesthetics." — Btop++ 推荐结论
|
||||
> "Mission Center is your friend" if you want something close to the Windows Task Manager — Mission Center 推荐定位
|
||||
|
||||
## Key Concepts
|
||||
- [[TUI]]：文本用户界面，通过终端运行，响应迅速，适合 SSH 远程场景
|
||||
- [[System-Monitoring]]：系统资源监控，涵盖 CPU、内存、存储、网络、进程等维度
|
||||
- [[Process-Management]]：进程管理，包括查看、搜索、终止、优先级调整
|
||||
|
||||
## Key Entities
|
||||
- [[Btop++]]：作者首选 TUI 资源监控器，支持 Pacman 安装和 Snap 包（Debian/Ubuntu）
|
||||
- [[Htop]]：经典 TUI 进程监控器，全键盘驱动，适合进程优先场景
|
||||
- [[Glances]]：极轻量 TUI 监控器，全键盘操作，适合资源受限环境
|
||||
- [[Bottom]]：专注实时图形化监控的工具，支持进程树视图，非交互式任务管理器
|
||||
- [[Mission-Center]]：GNOME 原生 GUI 资源管理器，提供性能/应用/服务三标签页
|
||||
- [[Stacer]]：功能最丰富的 GUI 资源管理器，支持缓存清理、启动项管理、APT 仓库配置
|
||||
- [[HowToGeek]]：文章来源的技术博客
|
||||
|
||||
## Connections
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] ← 应用层 ← [[These-6-Linux-Apps-Let-You-Monitor-System-Resources-in-Style]]：本文工具为单机能见度层，与 Prometheus/Grafana 企业监控方案互补
|
||||
- [[linux-运维必会的-150-个命令]] ← 关联 ← [[These-6-Linux-Apps-Let-You-Monitor-System-Resources-in-Style]]：系统监控是 Linux 运维基础技能，本文 6 款工具覆盖该技能核心场景
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] ← 对比 ← [[These-6-Linux-Apps-Let-You-Monitor-System-Resources-in-Style]]：企业级（Prometheus/Grafana）vs 轻量级（本文工具）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] 定位差异：
|
||||
- 冲突点：监控方案选择
|
||||
- 当前观点：单机能见度优先，用 Btop++ 或 Mission Center 快速定位问题
|
||||
- 对方观点：企业级基础设施需 Prometheus + Grafana 实现集中可观测性
|
||||
- 说明：两者面向不同场景，不构成直接冲突；建议单节点用本文工具，多节点/生产环境用 Prometheus/Grafana
|
||||
|
||||
@@ -1,57 +1,57 @@
|
||||
---
|
||||
title: "Trae远程开发部署指南"
|
||||
type: source
|
||||
tags: [remote-ssh, trae, ubuntu]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/Trae远程开发部署指南]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：使用 Trae IDE 通过 SSH 远程连接 Ubuntu 服务器进行 Docker 容器化项目的开发工作流配置
|
||||
- 问题域：远程开发环境搭建、Docker 与 IDE 集成、内网穿透访问
|
||||
- 方法/机制：SSH 免密登录 → Trae Remote-SSH 连接 → Docker 容器 Attach 或宿主机文件编辑 → Tailscale/FRP 公网访问
|
||||
- 结论/价值：提供一套完整的"本地 UI + 远程服务器开发"解决方案，支持 Attach 容器调试和 docker-compose 编排两种模式
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Trae 原生支持 VS Code 插件生态，通过 Remote-SSH 插件可远程连接 Ubuntu 服务器
|
||||
- 开发模式 A（Attach 容器）：适合调试，环境完全隔离，直接使用容器内语言环境
|
||||
- 开发模式 B（宿主机文件 + Docker CLI）：适合编排 docker-compose.yml 和管理多容器配置
|
||||
- 用户必须加入 docker 用户组才能让 Trae 的 Docker 插件正常工作
|
||||
- 文件权限（UID/GID）问题会导致 Volume 挂载生成的 Build 文件归属 root，宿主机无法操作
|
||||
|
||||
## Key Quotes
|
||||
> "开发环境的核心在于 Bind Mount（绑定挂载），实现代码修改实时生效" — 解释开发环境 docker-compose.yml 的设计原则
|
||||
|
||||
> "SSH 登录服务器执行：sudo usermod -aG docker $USER，必须注销并重新登录" — Docker 用户组配置关键步骤
|
||||
|
||||
> "不要直接暴露 SSH 端口，建议安装 Tailscale 或 Cloudflare Tunnel" — 内网穿透安全建议
|
||||
|
||||
## Key Concepts
|
||||
- [[Remote-SSH]]：通过 SSH 协议将本地 IDE 连接到远程服务器，代码运行在服务器端但 UI 在本地
|
||||
- [[Bind Mount]]：Docker Volume 挂载方式，将宿主机目录映射到容器内，实现代码修改实时生效
|
||||
- [[Attach 容器]]：将 IDE 直接连接到正在运行的 Docker 容器内部进行开发调试的模式
|
||||
- [[Docker 用户组]]：将用户加入 docker 组使其无需 sudo 即可运行 docker 命令
|
||||
- [[SSH Config]]：SSH 客户端配置文件（~/.ssh/config），定义 Host 别名和连接参数
|
||||
- [[SSH 免密登录]]：通过 ssh-copy-id 公钥分发实现无密码 SSH 连接
|
||||
- [[Docker Compose 开发模式]]：使用 docker-compose.yml 编排开发环境，通过 volumes 实现源码挂载
|
||||
|
||||
## Key Entities
|
||||
- [[Trae]]：国产 AI IDE，基于 VS Code，支持 Remote-SSH 远程开发，与 Cursor 功能类似
|
||||
- [[Ubuntu 2]]：开发服务器（192.168.3.45），存放源码，运行带 Bind Mount 的开发容器
|
||||
- [[Ubuntu 1]]：生产服务器（192.168.3.47），运行生产容器，通过 Docker 卷持久化数据
|
||||
- [[ThinkBook]]：本地笔记本，作为 Trae UI 端连接远程服务器
|
||||
- [[Tailscale]]：零配置 VPN 工具，可替代 FRP 提供安全的公网 SSH 访问
|
||||
- [[Docker]]：容器化平台，远程开发的核心载体
|
||||
|
||||
## Connections
|
||||
- [[Trae]] ← remote-ssh ← [[Ubuntu 2]]
|
||||
- [[Docker]] ← hosts ← [[Ubuntu 2]]
|
||||
- [[Docker Compose]] ← manages containers on ← [[Ubuntu 2]]
|
||||
- [[Remote-SSH]] ← 公网穿透方案 ← [[Tailscale]] / [[frp]]
|
||||
- [[Ubuntu 2]] ← 公网访问 ← [[frp]] (ubuntu2-ext: ubuntu2.ishenwei.online:60024)
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容
|
||||
|
||||
---
|
||||
title: "Trae远程开发部署指南"
|
||||
type: source
|
||||
tags: [remote-ssh, trae, ubuntu]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/Trae远程开发部署指南]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：使用 Trae IDE 通过 SSH 远程连接 Ubuntu 服务器进行 Docker 容器化项目的开发工作流配置
|
||||
- 问题域：远程开发环境搭建、Docker 与 IDE 集成、内网穿透访问
|
||||
- 方法/机制：SSH 免密登录 → Trae Remote-SSH 连接 → Docker 容器 Attach 或宿主机文件编辑 → Tailscale/FRP 公网访问
|
||||
- 结论/价值：提供一套完整的"本地 UI + 远程服务器开发"解决方案，支持 Attach 容器调试和 docker-compose 编排两种模式
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Trae 原生支持 VS Code 插件生态，通过 Remote-SSH 插件可远程连接 Ubuntu 服务器
|
||||
- 开发模式 A（Attach 容器）：适合调试，环境完全隔离，直接使用容器内语言环境
|
||||
- 开发模式 B（宿主机文件 + Docker CLI）：适合编排 docker-compose.yml 和管理多容器配置
|
||||
- 用户必须加入 docker 用户组才能让 Trae 的 Docker 插件正常工作
|
||||
- 文件权限（UID/GID）问题会导致 Volume 挂载生成的 Build 文件归属 root，宿主机无法操作
|
||||
|
||||
## Key Quotes
|
||||
> "开发环境的核心在于 Bind Mount（绑定挂载），实现代码修改实时生效" — 解释开发环境 docker-compose.yml 的设计原则
|
||||
|
||||
> "SSH 登录服务器执行：sudo usermod -aG docker $USER，必须注销并重新登录" — Docker 用户组配置关键步骤
|
||||
|
||||
> "不要直接暴露 SSH 端口，建议安装 Tailscale 或 Cloudflare Tunnel" — 内网穿透安全建议
|
||||
|
||||
## Key Concepts
|
||||
- [[Remote-SSH]]：通过 SSH 协议将本地 IDE 连接到远程服务器，代码运行在服务器端但 UI 在本地
|
||||
- [[Bind Mount]]：Docker Volume 挂载方式，将宿主机目录映射到容器内，实现代码修改实时生效
|
||||
- [[Attach 容器]]：将 IDE 直接连接到正在运行的 Docker 容器内部进行开发调试的模式
|
||||
- [[Docker 用户组]]：将用户加入 docker 组使其无需 sudo 即可运行 docker 命令
|
||||
- [[SSH Config]]：SSH 客户端配置文件（~/.ssh/config），定义 Host 别名和连接参数
|
||||
- [[SSH 免密登录]]：通过 ssh-copy-id 公钥分发实现无密码 SSH 连接
|
||||
- [[Docker Compose 开发模式]]：使用 docker-compose.yml 编排开发环境，通过 volumes 实现源码挂载
|
||||
|
||||
## Key Entities
|
||||
- [[Trae]]：国产 AI IDE，基于 VS Code，支持 Remote-SSH 远程开发，与 Cursor 功能类似
|
||||
- [[Ubuntu 2]]：开发服务器（192.168.3.45），存放源码，运行带 Bind Mount 的开发容器
|
||||
- [[Ubuntu 1]]：生产服务器（192.168.3.47），运行生产容器，通过 Docker 卷持久化数据
|
||||
- [[ThinkBook]]：本地笔记本，作为 Trae UI 端连接远程服务器
|
||||
- [[Tailscale]]：零配置 VPN 工具，可替代 FRP 提供安全的公网 SSH 访问
|
||||
- [[Docker]]：容器化平台，远程开发的核心载体
|
||||
|
||||
## Connections
|
||||
- [[Trae]] ← remote-ssh ← [[Ubuntu 2]]
|
||||
- [[Docker]] ← hosts ← [[Ubuntu 2]]
|
||||
- [[Docker Compose]] ← manages containers on ← [[Ubuntu 2]]
|
||||
- [[Remote-SSH]] ← 公网穿透方案 ← [[Tailscale]] / [[frp]]
|
||||
- [[Ubuntu 2]] ← 公网访问 ← [[frp]] (ubuntu2-ext: ubuntu2.ishenwei.online:60024)
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突内容
|
||||
|
||||
|
||||
@@ -1,44 +1,44 @@
|
||||
---
|
||||
title: "Ubuntu 24.04 启动 SSH 服务"
|
||||
type: source
|
||||
tags: [ssh, ubuntu, linux]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/Ubuntu 24.04 enable SSH.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Ubuntu 24.04 中启用 SSH 远程访问服务的完整操作指南
|
||||
- 问题域：Linux 服务器远程管理、SSH 服务配置与防火墙设置
|
||||
- 方法/机制：安装 OpenSSH Server → 启动并设置开机自启 → 配置 UFW 防火墙 → 验证服务状态 → 远程连接；核心变化：Ubuntu 24.04 默认使用 `ssh.socket` 激活机制（按需启动而非持续运行）
|
||||
- 结论/价值：提供 Ubuntu 24.04 SSH 快速启用指南，附带进阶配置（自定义端口、切换传统模式）
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Ubuntu 24.04 默认使用 **ssh.socket 激活机制**：仅在连接请求进入时才启动 SSH 守护进程，与旧版本（持续运行后台进程）行为不同
|
||||
- SSH 服务可通过 `sudo systemctl start ssh` 和 `sudo systemctl enable ssh` 手动启动并设置开机自启
|
||||
- 防火墙配置：使用 `sudo ufw allow ssh` 或 `sudo ufw allow 22/tcp` 放行 SSH 流量
|
||||
- 进阶配置：可通过 `sudo systemctl edit ssh.socket` 修改监听端口，而非仅修改 `/etc/ssh/sshd_config`
|
||||
- 如需切换回传统模式：先禁用 socket 激活（`sudo systemctl disable --now ssh.socket`），再启用 service 模式（`sudo systemctl enable --now ssh.service`）
|
||||
|
||||
## Key Quotes
|
||||
> "在 Ubuntu 24.04 中开启 SSH 服务非常简单，但这个版本引入了一个重要的变化：默认使用 ssh.socket 激活机制" — Ubuntu 24.04 SSH 配置说明
|
||||
|
||||
> "如果你习惯了旧版本的管理方式，或者需要修改自定义端口（例如改为 2222），在 24.04 中你可能需要注意：现在推荐通过 sudo systemctl edit ssh.socket 来修改监听端口" — 进阶配置说明
|
||||
|
||||
## Key Concepts
|
||||
- [[SocketActivation]]：按需激活机制，ssh.socket 在接收到连接请求时才启动 sshd 守护进程，与传统持续运行的 ssh.service 不同
|
||||
- [[UFW]]（Uncomplicated Firewall）：Ubuntu 默认防火墙管理工具，通过 `ufw allow ssh` 简化 iptables 规则配置
|
||||
- [[OpenSSH]]：开源 SSH 协议实现，Ubuntu 通过 `openssh-server` 包提供服务端功能
|
||||
|
||||
## Key Entities
|
||||
- [[Ubuntu-24.04]]：Canonical Ltd 发布的 Linux 发行版，引入 ssh.socket 默认激活机制
|
||||
- [[systemd]]：Linux 系统和服务管理器，通过 systemctl 管理 ssh.service 和 ssh.socket
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu服务器通过rsync实现日常增量备份]] ← related_to ← [[Ubuntu-24.04-启动SSH服务]]（SSH 是远程管理 Ubuntu 服务器的基础，用于执行 rsync 备份命令）
|
||||
- [[Ubuntu Server科学上网]] ← related_to ← [[Ubuntu-24.04-启动SSH服务]]（SSH 隧道可用于建立安全通道）
|
||||
- [[Linux运维必会的150个命令]] ← related_to ← [[Ubuntu-24.04-启动SSH服务]]（SSH 相关命令如 ssh/scp/sftp 是运维必备命令）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
---
|
||||
title: "Ubuntu 24.04 启动 SSH 服务"
|
||||
type: source
|
||||
tags: [ssh, ubuntu, linux]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/Ubuntu 24.04 enable SSH.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Ubuntu 24.04 中启用 SSH 远程访问服务的完整操作指南
|
||||
- 问题域：Linux 服务器远程管理、SSH 服务配置与防火墙设置
|
||||
- 方法/机制：安装 OpenSSH Server → 启动并设置开机自启 → 配置 UFW 防火墙 → 验证服务状态 → 远程连接；核心变化：Ubuntu 24.04 默认使用 `ssh.socket` 激活机制（按需启动而非持续运行）
|
||||
- 结论/价值：提供 Ubuntu 24.04 SSH 快速启用指南，附带进阶配置（自定义端口、切换传统模式）
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Ubuntu 24.04 默认使用 **ssh.socket 激活机制**：仅在连接请求进入时才启动 SSH 守护进程，与旧版本（持续运行后台进程）行为不同
|
||||
- SSH 服务可通过 `sudo systemctl start ssh` 和 `sudo systemctl enable ssh` 手动启动并设置开机自启
|
||||
- 防火墙配置：使用 `sudo ufw allow ssh` 或 `sudo ufw allow 22/tcp` 放行 SSH 流量
|
||||
- 进阶配置：可通过 `sudo systemctl edit ssh.socket` 修改监听端口，而非仅修改 `/etc/ssh/sshd_config`
|
||||
- 如需切换回传统模式：先禁用 socket 激活（`sudo systemctl disable --now ssh.socket`），再启用 service 模式（`sudo systemctl enable --now ssh.service`）
|
||||
|
||||
## Key Quotes
|
||||
> "在 Ubuntu 24.04 中开启 SSH 服务非常简单，但这个版本引入了一个重要的变化：默认使用 ssh.socket 激活机制" — Ubuntu 24.04 SSH 配置说明
|
||||
|
||||
> "如果你习惯了旧版本的管理方式，或者需要修改自定义端口（例如改为 2222），在 24.04 中你可能需要注意：现在推荐通过 sudo systemctl edit ssh.socket 来修改监听端口" — 进阶配置说明
|
||||
|
||||
## Key Concepts
|
||||
- [[SocketActivation]]：按需激活机制，ssh.socket 在接收到连接请求时才启动 sshd 守护进程，与传统持续运行的 ssh.service 不同
|
||||
- [[UFW]]（Uncomplicated Firewall）：Ubuntu 默认防火墙管理工具，通过 `ufw allow ssh` 简化 iptables 规则配置
|
||||
- [[OpenSSH]]：开源 SSH 协议实现，Ubuntu 通过 `openssh-server` 包提供服务端功能
|
||||
|
||||
## Key Entities
|
||||
- [[Ubuntu-24.04]]：Canonical Ltd 发布的 Linux 发行版，引入 ssh.socket 默认激活机制
|
||||
- [[systemd]]：Linux 系统和服务管理器，通过 systemctl 管理 ssh.service 和 ssh.socket
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu服务器通过rsync实现日常增量备份]] ← related_to ← [[Ubuntu-24.04-启动SSH服务]]（SSH 是远程管理 Ubuntu 服务器的基础，用于执行 rsync 备份命令）
|
||||
- [[Ubuntu Server科学上网]] ← related_to ← [[Ubuntu-24.04-启动SSH服务]]（SSH 隧道可用于建立安全通道）
|
||||
- [[Linux运维必会的150个命令]] ← related_to ← [[Ubuntu-24.04-启动SSH服务]]（SSH 相关命令如 ssh/scp/sftp 是运维必备命令）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
@@ -1,56 +1,56 @@
|
||||
---
|
||||
title: "Ubuntu服务器通过rsync实现日常增量备份"
|
||||
type: source
|
||||
tags: [backup, nas, rsync, ubuntu]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Ubuntu服务器通过rsync实现日常增量备份.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：使用 rsync 在 Ubuntu Server 上实现自动化增量备份，将 Docker 数据和配置文件同步到 NAS 存储
|
||||
- 问题域：工作室级数据保护体系建设——在已完成 Clonezilla 全盘镜像备份的基础上，通过 rsync 实现不关机的日常增量同步
|
||||
- 方法/机制：
|
||||
- rsync 增量同步（仅传输变化文件）+ Crontab 凌晨自动执行
|
||||
- NFS 永久挂载通过 `/etc/fstab` 配置，配合 `_netdev` 参数确保网络就绪后再挂载
|
||||
- 备份脚本内置锁文件机制（防止并发运行）、挂载点检查（防止写入本地磁盘）
|
||||
- Docker 卷备份（直接同步 `/var/lib/docker/volumes`）+ 数据库一致性建议（mysqldump 优先）
|
||||
- 结论/价值：形成"全盘镜像（Clonezilla）+ 日常增量（rsync）"双层数据保护体系，兼顾灾难恢复与实时数据安全
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- rsync 可以在不关机的情况下运行，且只传输变化过的文件，适合作为日常增量备份工具
|
||||
- NFS 永久挂载必须写入 `/etc/fstab`，并使用 `_netdev` 参数防止开机时因网络未就绪而卡死
|
||||
- 备份脚本若不加挂载点检查，NAS 掉线时 rsync 会将数据写入本地挂载点目录，导致硬盘迅速爆满
|
||||
- Docker 卷（Volumes）默认存储路径为 `/var/lib/docker/volumes`，是备份的核心数据
|
||||
- 数据库类容器（MySQL）备份应先用 `mysqldump` 导出 SQL 文件再 rsync，避免二进制文件损坏
|
||||
- rsync 返回码 23 或 24 表示部分文件因权限或消失未传输，这在运行中的系统上属于正常情况
|
||||
- 使用 `killall`（SIGTERM）优雅停止 rsync 比 `kill -9`（SIGKILL）更安全，可防止临时文件残留
|
||||
|
||||
## Key Quotes
|
||||
> "不要直接在命令行输入长命令，建议创建一个专门的脚本。" — 备份脚本管理最佳实践
|
||||
> "`_netdev`：告诉系统这是一个网络设备，务必等到网络服务完全启动后再尝试挂载，防止开机过程因找不到网络而卡死。" — /etc/fstab NFS 挂载参数说明
|
||||
> "rsync 返回 23 表示部分文件由于权限或消失未传输，这在备份正在运行的系统时常见。" — 错误码处理说明
|
||||
|
||||
## Key Concepts
|
||||
- [[Rsync-Incremental-Backup]]：rsync 通过其 delta-transfer 算法，只发送源文件和目标文件之间的差异部分，实现高效的增量备份；常用参数 `-azR --delete`（归档、压缩、保持相对路径、删除目标端多余文件）
|
||||
- [[NFS-Permanent-Mount]]：NFS 挂载通过 `/etc/fstab` 实现永久化，关键参数包括 `timeo=900`（90秒超时）、`retrans=5`（5次重试）、`_netdev`（等待网络就绪）；测试前必须用 `sudo mount -a` 验证，禁止直接重启
|
||||
- [[Docker-Volume-Backup]]：Docker 卷默认存储在 `/var/lib/docker/volumes`，备份时对数据库容器应先用 `docker exec <容器> mysqldump` 导出再做 rsync，避免二进制文件损坏
|
||||
- [[Fstab]]：Linux 文件系统表（/etc/fstab），用于定义开机自动挂载的设备和参数；修改后必须用 `mount -a` 测试，禁止直接重启
|
||||
- [[Backup-Strategy]]：双层备份体系——Clonezilla 全盘镜像（应对硬盘彻底损坏）+ rsync 增量备份（应对日常文件丢失）
|
||||
|
||||
## Key Entities
|
||||
- [[Clonezilla]]：用于整机镜像备份的工具，与 rsync 形成互补（全量 vs 增量）
|
||||
- [[Synology-NAS]]：NAS 存储设备，提供 NFS 共享作为 rsync 备份目标
|
||||
- [[Ubuntu-Server]]：运行 rsync 备份脚本的操作系统环境
|
||||
- [[Docker]]：容器化平台，其 volumes 和配置文件是备份的核心数据
|
||||
- [[NFS]]：网络文件系统协议，用于 Ubuntu Server 挂载 Synology NAS 共享目录
|
||||
|
||||
## Connections
|
||||
- [[Clonezilla对Ubuntu Server进行全盘镜像备份]] ← backup_strategy ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
- [[如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹]] ← foundation ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
- [[Docker]] ← backup_target ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
- [[Synology-NAS]] ← backup_destination ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
---
|
||||
title: "Ubuntu服务器通过rsync实现日常增量备份"
|
||||
type: source
|
||||
tags: [backup, nas, rsync, ubuntu]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Ubuntu服务器通过rsync实现日常增量备份.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：使用 rsync 在 Ubuntu Server 上实现自动化增量备份，将 Docker 数据和配置文件同步到 NAS 存储
|
||||
- 问题域：工作室级数据保护体系建设——在已完成 Clonezilla 全盘镜像备份的基础上，通过 rsync 实现不关机的日常增量同步
|
||||
- 方法/机制：
|
||||
- rsync 增量同步（仅传输变化文件）+ Crontab 凌晨自动执行
|
||||
- NFS 永久挂载通过 `/etc/fstab` 配置，配合 `_netdev` 参数确保网络就绪后再挂载
|
||||
- 备份脚本内置锁文件机制（防止并发运行）、挂载点检查（防止写入本地磁盘）
|
||||
- Docker 卷备份（直接同步 `/var/lib/docker/volumes`）+ 数据库一致性建议（mysqldump 优先）
|
||||
- 结论/价值：形成"全盘镜像（Clonezilla）+ 日常增量（rsync）"双层数据保护体系，兼顾灾难恢复与实时数据安全
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- rsync 可以在不关机的情况下运行，且只传输变化过的文件，适合作为日常增量备份工具
|
||||
- NFS 永久挂载必须写入 `/etc/fstab`，并使用 `_netdev` 参数防止开机时因网络未就绪而卡死
|
||||
- 备份脚本若不加挂载点检查，NAS 掉线时 rsync 会将数据写入本地挂载点目录，导致硬盘迅速爆满
|
||||
- Docker 卷（Volumes）默认存储路径为 `/var/lib/docker/volumes`，是备份的核心数据
|
||||
- 数据库类容器（MySQL）备份应先用 `mysqldump` 导出 SQL 文件再 rsync，避免二进制文件损坏
|
||||
- rsync 返回码 23 或 24 表示部分文件因权限或消失未传输，这在运行中的系统上属于正常情况
|
||||
- 使用 `killall`（SIGTERM）优雅停止 rsync 比 `kill -9`（SIGKILL）更安全，可防止临时文件残留
|
||||
|
||||
## Key Quotes
|
||||
> "不要直接在命令行输入长命令，建议创建一个专门的脚本。" — 备份脚本管理最佳实践
|
||||
> "`_netdev`：告诉系统这是一个网络设备，务必等到网络服务完全启动后再尝试挂载，防止开机过程因找不到网络而卡死。" — /etc/fstab NFS 挂载参数说明
|
||||
> "rsync 返回 23 表示部分文件由于权限或消失未传输，这在备份正在运行的系统时常见。" — 错误码处理说明
|
||||
|
||||
## Key Concepts
|
||||
- [[Rsync-Incremental-Backup]]：rsync 通过其 delta-transfer 算法，只发送源文件和目标文件之间的差异部分，实现高效的增量备份；常用参数 `-azR --delete`（归档、压缩、保持相对路径、删除目标端多余文件）
|
||||
- [[NFS-Permanent-Mount]]：NFS 挂载通过 `/etc/fstab` 实现永久化，关键参数包括 `timeo=900`（90秒超时）、`retrans=5`（5次重试）、`_netdev`（等待网络就绪）；测试前必须用 `sudo mount -a` 验证，禁止直接重启
|
||||
- [[Docker-Volume-Backup]]：Docker 卷默认存储在 `/var/lib/docker/volumes`，备份时对数据库容器应先用 `docker exec <容器> mysqldump` 导出再做 rsync，避免二进制文件损坏
|
||||
- [[Fstab]]：Linux 文件系统表（/etc/fstab），用于定义开机自动挂载的设备和参数；修改后必须用 `mount -a` 测试，禁止直接重启
|
||||
- [[Backup-Strategy]]：双层备份体系——Clonezilla 全盘镜像（应对硬盘彻底损坏）+ rsync 增量备份（应对日常文件丢失）
|
||||
|
||||
## Key Entities
|
||||
- [[Clonezilla]]：用于整机镜像备份的工具，与 rsync 形成互补（全量 vs 增量）
|
||||
- [[Synology-NAS]]：NAS 存储设备，提供 NFS 共享作为 rsync 备份目标
|
||||
- [[Ubuntu-Server]]：运行 rsync 备份脚本的操作系统环境
|
||||
- [[Docker]]：容器化平台，其 volumes 和配置文件是备份的核心数据
|
||||
- [[NFS]]：网络文件系统协议，用于 Ubuntu Server 挂载 Synology NAS 共享目录
|
||||
|
||||
## Connections
|
||||
- [[Clonezilla对Ubuntu Server进行全盘镜像备份]] ← backup_strategy ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
- [[如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹]] ← foundation ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
- [[Docker]] ← backup_target ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
- [[Synology-NAS]] ← backup_destination ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
@@ -1,45 +1,45 @@
|
||||
---
|
||||
title: "Ubuntu禁用合盖休眠"
|
||||
type: source
|
||||
tags: [ubuntu, systemd, 服务器配置]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/Ubuntu禁用合盖休眠]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Ubuntu 24.04 笔记本合盖休眠行为配置
|
||||
- 问题域：服务器场景下笔记本合盖后不应进入休眠状态
|
||||
- 方法/机制：通过修改 `systemd-logind` 的 `logind.conf` 配置文件，将 `HandleLidSwitch` 系列参数设为 `ignore`；进阶方法通过 `systemctl mask` 彻底禁用所有休眠目标
|
||||
- 结论/价值：提供两步完成服务器场景下笔记本合盖持续运行的生产级方案
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- systemd-logind 是 Ubuntu 24.04 控制笔记本合盖行为的登录管理器
|
||||
- 通过 `HandleLidSwitch`、`HandleLidSwitchExternalPower`、`HandleLidSwitchDocked` 三个配置项可覆盖不同场景
|
||||
- 将配置值设为 `ignore` 后系统合盖不执行任何操作，继续运行
|
||||
- 修改配置后需执行 `systemctl restart systemd-logind` 重启服务才能生效
|
||||
- 可通过 `systemctl mask` 从内核级别彻底禁止待机（sleep/suspend/hibernate/hybrid-sleep）
|
||||
- `mask` 与 `unmask` 可逆，恢复时将 mask 改为 unmask 即可
|
||||
|
||||
## Key Quotes
|
||||
> "在执行此命令时，你的当前会话（包括图形界面或当前的 SSH 连接）可能会短暂断开或重新加载。" — 重启 systemd-logind 服务的注意事项
|
||||
|
||||
## Key Concepts
|
||||
- [[systemd-logind]]：Linux 系统登录管理器，负责管理用户会话、电源管理和设备访问权限，合盖行为由其控制
|
||||
- [[HandleLidSwitch]]：systemd-logind 配置项，定义笔记本合盖时的电源行为
|
||||
- [[sleep.target suspend.target hibernate.target hybrid-sleep.target]]：Linux 休眠相关系统目标，通过 `systemctl mask` 可从内核级别彻底禁用
|
||||
|
||||
## Key Entities
|
||||
- [[Ubuntu 24.04]]：Canonical 发布的长期支持版 Ubuntu，本配置方法的适用系统
|
||||
- [[systemd]]：Linux 系统和服务管理器，systemd-logind 为其组件之一
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu禁用合盖休眠]] ← relates_to ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
- [[Ubuntu禁用合盖休眠]] ← related_topic ← [[Mac Mini 服务器配置：防止自动锁屏与睡眠]]（不同 OS，方法不同，无冲突）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Mac Mini 服务器配置：防止自动锁屏与睡眠]] 无冲突：
|
||||
- 冲突点：无（macOS 使用 `pmset` 命令，与 Ubuntu systemd 配置完全不同）
|
||||
- 当前观点：Ubuntu 通过 systemd-logind 配置
|
||||
- 对方观点：macOS 通过 pmset 命令配置
|
||||
---
|
||||
title: "Ubuntu禁用合盖休眠"
|
||||
type: source
|
||||
tags: [ubuntu, systemd, 服务器配置]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/Ubuntu禁用合盖休眠]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Ubuntu 24.04 笔记本合盖休眠行为配置
|
||||
- 问题域：服务器场景下笔记本合盖后不应进入休眠状态
|
||||
- 方法/机制：通过修改 `systemd-logind` 的 `logind.conf` 配置文件，将 `HandleLidSwitch` 系列参数设为 `ignore`；进阶方法通过 `systemctl mask` 彻底禁用所有休眠目标
|
||||
- 结论/价值：提供两步完成服务器场景下笔记本合盖持续运行的生产级方案
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- systemd-logind 是 Ubuntu 24.04 控制笔记本合盖行为的登录管理器
|
||||
- 通过 `HandleLidSwitch`、`HandleLidSwitchExternalPower`、`HandleLidSwitchDocked` 三个配置项可覆盖不同场景
|
||||
- 将配置值设为 `ignore` 后系统合盖不执行任何操作，继续运行
|
||||
- 修改配置后需执行 `systemctl restart systemd-logind` 重启服务才能生效
|
||||
- 可通过 `systemctl mask` 从内核级别彻底禁止待机（sleep/suspend/hibernate/hybrid-sleep）
|
||||
- `mask` 与 `unmask` 可逆，恢复时将 mask 改为 unmask 即可
|
||||
|
||||
## Key Quotes
|
||||
> "在执行此命令时，你的当前会话（包括图形界面或当前的 SSH 连接）可能会短暂断开或重新加载。" — 重启 systemd-logind 服务的注意事项
|
||||
|
||||
## Key Concepts
|
||||
- [[systemd-logind]]：Linux 系统登录管理器，负责管理用户会话、电源管理和设备访问权限，合盖行为由其控制
|
||||
- [[HandleLidSwitch]]：systemd-logind 配置项，定义笔记本合盖时的电源行为
|
||||
- [[sleep.target suspend.target hibernate.target hybrid-sleep.target]]：Linux 休眠相关系统目标，通过 `systemctl mask` 可从内核级别彻底禁用
|
||||
|
||||
## Key Entities
|
||||
- [[Ubuntu 24.04]]：Canonical 发布的长期支持版 Ubuntu，本配置方法的适用系统
|
||||
- [[systemd]]：Linux 系统和服务管理器，systemd-logind 为其组件之一
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu禁用合盖休眠]] ← relates_to ← [[Ubuntu服务器通过rsync实现日常增量备份]]
|
||||
- [[Ubuntu禁用合盖休眠]] ← related_topic ← [[Mac Mini 服务器配置：防止自动锁屏与睡眠]]（不同 OS，方法不同，无冲突）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Mac Mini 服务器配置：防止自动锁屏与睡眠]] 无冲突：
|
||||
- 冲突点：无（macOS 使用 `pmset` 命令，与 Ubuntu systemd 配置完全不同）
|
||||
- 当前观点：Ubuntu 通过 systemd-logind 配置
|
||||
- 对方观点：macOS 通过 pmset 命令配置
|
||||
|
||||
@@ -1,57 +1,57 @@
|
||||
---
|
||||
title: "Vibe Coding 经验收集"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-12-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/vibe coding经验收集.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Vibe Coding 实战经验与最佳实践的精选合集
|
||||
- 问题域：AI 辅助编程的工作流优化、代码质量保证、多 AI 协作模式、文档与导航化工具
|
||||
- 方法/机制：设计文档→伪代码→代码的递进式开发、多 AI 协作验证、文件注释标准化、代码可导航化
|
||||
- 结论/价值：Vibe Coding 已从单纯提示词工程演变为系统性工程实践，强调验证而非理解、文档优于记忆
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **递进式开发工作流**：设计文档写细（含伪代码）→ AI 直出代码 → 另一 AI review → 跑测试用例 → AI 自动 commit+push，可一遍直出
|
||||
- **System Prompt 优化效果**：针对 Gemini 3 Pro 的系统 prompt 优化可使多代理基准测试性能提升约 5%
|
||||
- **点线体迭代方法**：逐级迭代（点→线→体），先用单个基础任务打磨，再基于此批量执行
|
||||
- **文件头注释规范**：一段话描述代码作用、上下游链路，降低认知负载，参考 Claude skill 格式
|
||||
- **代码验证优先**：未来软件工程核心不是"看懂代码"而是"验证代码按正确逻辑运行"，依赖自动化测试、静态分析、形式化验证
|
||||
- **激励式提示词**：如"如果第一次就做得好，我会打赏100美元"可提升生成效果
|
||||
- **CodeWeaver 工具**：将代码库编织成可导航的 Markdown 文档，简化 AI/ML 工具集成
|
||||
|
||||
## Key Quotes
|
||||
> "我是把设计文档写得很细，包括service层的具体逻辑都用伪代码写了，然后交给AI，一遍直出，再用另一个AI review一遍，根据review意见修改一下，跑一下测试用例，让AI自己生成commit后push" — 需求→伪代码→代码递进工作流
|
||||
|
||||
> "代码最终会被转换成机器码执行，高级语言只是一层方便人类理解的抽象，重要的是验证程序的执行逻辑" — 代码验证哲学
|
||||
|
||||
> "请你根据我的要求，用 Three.js 创建一个实时交互的3D粒子系统，如果你第一次就做得好，我将会打赏你100美元的小费" — 激励式提示词示例
|
||||
|
||||
> "CodeWeaver 将你的代码库编织成一个可导航的 Markdown 文档……所有代码都给你塞进代码块里，极大地简化了代码库的共享、文档化以及与 AI/ML 工具集成" — CodeWeaver 工具价值
|
||||
|
||||
## Key Concepts
|
||||
- [[Vibe Coding]]：使用 AI 辅助编程的实践方法论，强调人机协作而非纯自动生成
|
||||
- [[Design-to-Code Workflow]]：设计文档→伪代码→代码的递进式开发流程
|
||||
- [[Multi-AI Review]]：多 AI 协作验证，一个生成一个 review 的双人编程模式
|
||||
- [[Code Documentation]]：文件头注释规范，降低 AI 和人类认知负载
|
||||
- [[Verification-First Engineering]]：验证优先于理解，强调自动化测试和形式化验证
|
||||
- [[Iterative Scaling]]：点→线→体的逐级迭代，从单任务打磨到批量执行
|
||||
- [[CodeWeaver]]：将代码库转换为可导航 Markdown 文档的工具
|
||||
|
||||
## Key Entities
|
||||
- [[CodeWeaver]]：GitHub 开源项目，将代码库编织成可导航 Markdown 文档的工具
|
||||
|
||||
## Connections
|
||||
- [[Vibe Coding]] ← extends ← [[Agentic AI]]
|
||||
- [[Design-to-Code Workflow]] ← refines ← [[Vibe Coding]]
|
||||
- [[Multi-AI Review]] ← part_of ← [[Design-to-Code Workflow]]
|
||||
- [[CodeWeaver]] ← enables ← [[Vibe Coding]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统软件工程方法冲突：
|
||||
- 冲突点：传统方法强调"先理解代码再修改"，Vibe Coding 强调"验证而非理解"
|
||||
- 当前观点：通过自动化测试和验证确保行为正确，降低人类理解代码的必要性
|
||||
- 对方观点：人类开发者必须理解代码才能安全地进行修改和重构
|
||||
---
|
||||
title: "Vibe Coding 经验收集"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2025-12-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/vibe coding经验收集.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Vibe Coding 实战经验与最佳实践的精选合集
|
||||
- 问题域：AI 辅助编程的工作流优化、代码质量保证、多 AI 协作模式、文档与导航化工具
|
||||
- 方法/机制：设计文档→伪代码→代码的递进式开发、多 AI 协作验证、文件注释标准化、代码可导航化
|
||||
- 结论/价值：Vibe Coding 已从单纯提示词工程演变为系统性工程实践，强调验证而非理解、文档优于记忆
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- **递进式开发工作流**：设计文档写细（含伪代码）→ AI 直出代码 → 另一 AI review → 跑测试用例 → AI 自动 commit+push，可一遍直出
|
||||
- **System Prompt 优化效果**：针对 Gemini 3 Pro 的系统 prompt 优化可使多代理基准测试性能提升约 5%
|
||||
- **点线体迭代方法**：逐级迭代（点→线→体），先用单个基础任务打磨，再基于此批量执行
|
||||
- **文件头注释规范**：一段话描述代码作用、上下游链路，降低认知负载，参考 Claude skill 格式
|
||||
- **代码验证优先**：未来软件工程核心不是"看懂代码"而是"验证代码按正确逻辑运行"，依赖自动化测试、静态分析、形式化验证
|
||||
- **激励式提示词**：如"如果第一次就做得好，我会打赏100美元"可提升生成效果
|
||||
- **CodeWeaver 工具**：将代码库编织成可导航的 Markdown 文档，简化 AI/ML 工具集成
|
||||
|
||||
## Key Quotes
|
||||
> "我是把设计文档写得很细，包括service层的具体逻辑都用伪代码写了，然后交给AI，一遍直出，再用另一个AI review一遍，根据review意见修改一下，跑一下测试用例，让AI自己生成commit后push" — 需求→伪代码→代码递进工作流
|
||||
|
||||
> "代码最终会被转换成机器码执行，高级语言只是一层方便人类理解的抽象，重要的是验证程序的执行逻辑" — 代码验证哲学
|
||||
|
||||
> "请你根据我的要求，用 Three.js 创建一个实时交互的3D粒子系统，如果你第一次就做得好，我将会打赏你100美元的小费" — 激励式提示词示例
|
||||
|
||||
> "CodeWeaver 将你的代码库编织成一个可导航的 Markdown 文档……所有代码都给你塞进代码块里，极大地简化了代码库的共享、文档化以及与 AI/ML 工具集成" — CodeWeaver 工具价值
|
||||
|
||||
## Key Concepts
|
||||
- [[Vibe Coding]]：使用 AI 辅助编程的实践方法论，强调人机协作而非纯自动生成
|
||||
- [[Design-to-Code Workflow]]：设计文档→伪代码→代码的递进式开发流程
|
||||
- [[Multi-AI Review]]：多 AI 协作验证，一个生成一个 review 的双人编程模式
|
||||
- [[Code Documentation]]：文件头注释规范，降低 AI 和人类认知负载
|
||||
- [[Verification-First Engineering]]：验证优先于理解，强调自动化测试和形式化验证
|
||||
- [[Iterative Scaling]]：点→线→体的逐级迭代，从单任务打磨到批量执行
|
||||
- [[CodeWeaver]]：将代码库转换为可导航 Markdown 文档的工具
|
||||
|
||||
## Key Entities
|
||||
- [[CodeWeaver]]：GitHub 开源项目，将代码库编织成可导航 Markdown 文档的工具
|
||||
|
||||
## Connections
|
||||
- [[Vibe Coding]] ← extends ← [[Agentic AI]]
|
||||
- [[Design-to-Code Workflow]] ← refines ← [[Vibe Coding]]
|
||||
- [[Multi-AI Review]] ← part_of ← [[Design-to-Code Workflow]]
|
||||
- [[CodeWeaver]] ← enables ← [[Vibe Coding]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统软件工程方法冲突：
|
||||
- 冲突点：传统方法强调"先理解代码再修改"，Vibe Coding 强调"验证而非理解"
|
||||
- 当前观点：通过自动化测试和验证确保行为正确，降低人类理解代码的必要性
|
||||
- 对方观点：人类开发者必须理解代码才能安全地进行修改和重构
|
||||
|
||||
@@ -1,50 +1,50 @@
|
||||
---
|
||||
title: "Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南"
|
||||
type: source
|
||||
tags: [npm, npx, pm2, ubuntu, vibe-coding, vibe-kanban]
|
||||
date: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 Ubuntu Server 上非 root 用户（shenwei）安装 Node 20、Vibe-Kanban、OpenCode，并通过 pm2 进程管理，实现 AI 辅助编程工作流
|
||||
- 问题域：Ubuntu Server 环境下的 AI Coding Agent 部署与长期运维
|
||||
- 方法/机制：使用 nvm 管理 Node 版本、npm/npx 安装工具、pm2 管理进程生命周期、权限配置确保非 root 用户正常运行
|
||||
- 结论/价值：完整记录了从零开始在 Ubuntu Server 上搭建 Vibe Coding 环境的全流程，含验证步骤和故障排查要点
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 使用 nvm 安装 Node 20 可确保版本兼容性和环境隔离
|
||||
- pm2 能可靠管理 Vibe-Kanban 和 OpenCode Executor 进程并支持开机自启
|
||||
- 权限配置（/var/tmp/vibe-kanban 和 ~/.vibe-kanban 归属 shenwei）是避免 I/O error 的关键
|
||||
- 不应以 root 用户启动 OpenCode serve，避免权限问题
|
||||
- Vibe-Kanban 会自动 spawn OpenCode executor（随机端口），无需手动固定端口
|
||||
|
||||
## Key Quotes
|
||||
> "不要用 root 启动 OpenCode serve，vibe-kanban 会自动 spawn executor" — 核心安全与架构原则
|
||||
> "遇到 I/O error 时，通常是 executor 没启动或端口被占用" — 常见故障排查方向
|
||||
> "pm2 只管理 vibe-kanban，executor 随进程一起管理" — 进程管理边界定义
|
||||
|
||||
## Key Concepts
|
||||
- [[Vibe Coding]]：使用自然语言与 AI 编程工具协作的开发方式，Vibe-Kanban + OpenCode 是其代表性工具栈
|
||||
- [[nvm]]（Node Version Manager）：Node.js 版本管理工具，通过 $NVM_DIR/$HOME/.nvm 安装，支持多版本共存和快速切换
|
||||
- [[pm2]]：Node.js 进程管理器，支持进程守护、负载均衡、日志管理和开机自启（systemd）
|
||||
- [[Node 20]]：LTS 版 Node.js，Vibe-Kanban 和 OpenCode 的推荐运行时版本
|
||||
|
||||
## Key Entities
|
||||
- [[Vibe-Kanban]]：AI 编程辅助工具，提供看板界面与 OpenCode executor 集成，通过 npx vibe-kanban 启动
|
||||
- [[OpenCode]]：开源 AI Coding CLI agent，与 Vibe-Kanban 配合使用，npm install -g opencode-ai 安装
|
||||
- [[shenwei]]：文档作者，非 root 普通用户，用于在 Ubuntu Server 上运行 Vibe-Kanban 和 OpenCode
|
||||
|
||||
## Connections
|
||||
- [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] ← extends ← [[vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南]]
|
||||
- [[Vibe Coding 经验收集]] ← related_to ← [[vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南]]
|
||||
- [[OpenCode]] ← depends_on ← [[Node 20]]
|
||||
- [[Vibe-Kanban]] ← depends_on ← [[OpenCode]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] 部分重叠：
|
||||
- 冲突点：两篇文档都介绍 Ubuntu 上安装 OpenCode 和 Vibe-Kanban
|
||||
- 当前观点：本篇更详细，覆盖完整 6 步流程、pm2 进程管理、权限配置和验证步骤
|
||||
- 对方观点：前篇侧重基础安装步骤
|
||||
---
|
||||
title: "Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南"
|
||||
type: source
|
||||
tags: [npm, npx, pm2, ubuntu, vibe-coding, vibe-kanban]
|
||||
date: 2026-04-17
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/Vibe-Kanban + OpenCode 在 Ubuntu Server 上安装与管理指南]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 Ubuntu Server 上非 root 用户（shenwei）安装 Node 20、Vibe-Kanban、OpenCode，并通过 pm2 进程管理，实现 AI 辅助编程工作流
|
||||
- 问题域：Ubuntu Server 环境下的 AI Coding Agent 部署与长期运维
|
||||
- 方法/机制：使用 nvm 管理 Node 版本、npm/npx 安装工具、pm2 管理进程生命周期、权限配置确保非 root 用户正常运行
|
||||
- 结论/价值：完整记录了从零开始在 Ubuntu Server 上搭建 Vibe Coding 环境的全流程，含验证步骤和故障排查要点
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 使用 nvm 安装 Node 20 可确保版本兼容性和环境隔离
|
||||
- pm2 能可靠管理 Vibe-Kanban 和 OpenCode Executor 进程并支持开机自启
|
||||
- 权限配置（/var/tmp/vibe-kanban 和 ~/.vibe-kanban 归属 shenwei）是避免 I/O error 的关键
|
||||
- 不应以 root 用户启动 OpenCode serve，避免权限问题
|
||||
- Vibe-Kanban 会自动 spawn OpenCode executor（随机端口），无需手动固定端口
|
||||
|
||||
## Key Quotes
|
||||
> "不要用 root 启动 OpenCode serve，vibe-kanban 会自动 spawn executor" — 核心安全与架构原则
|
||||
> "遇到 I/O error 时，通常是 executor 没启动或端口被占用" — 常见故障排查方向
|
||||
> "pm2 只管理 vibe-kanban，executor 随进程一起管理" — 进程管理边界定义
|
||||
|
||||
## Key Concepts
|
||||
- [[Vibe Coding]]：使用自然语言与 AI 编程工具协作的开发方式，Vibe-Kanban + OpenCode 是其代表性工具栈
|
||||
- [[nvm]]（Node Version Manager）：Node.js 版本管理工具，通过 $NVM_DIR/$HOME/.nvm 安装，支持多版本共存和快速切换
|
||||
- [[pm2]]：Node.js 进程管理器，支持进程守护、负载均衡、日志管理和开机自启（systemd）
|
||||
- [[Node 20]]：LTS 版 Node.js，Vibe-Kanban 和 OpenCode 的推荐运行时版本
|
||||
|
||||
## Key Entities
|
||||
- [[Vibe-Kanban]]：AI 编程辅助工具，提供看板界面与 OpenCode executor 集成，通过 npx vibe-kanban 启动
|
||||
- [[OpenCode]]：开源 AI Coding CLI agent，与 Vibe-Kanban 配合使用，npm install -g opencode-ai 安装
|
||||
- [[shenwei]]：文档作者，非 root 普通用户，用于在 Ubuntu Server 上运行 Vibe-Kanban 和 OpenCode
|
||||
|
||||
## Connections
|
||||
- [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] ← extends ← [[vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南]]
|
||||
- [[Vibe Coding 经验收集]] ← related_to ← [[vibe-kanban-opencode-在-ubuntu-server-上安装与管理指南]]
|
||||
- [[OpenCode]] ← depends_on ← [[Node 20]]
|
||||
- [[Vibe-Kanban]] ← depends_on ← [[OpenCode]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] 部分重叠：
|
||||
- 冲突点：两篇文档都介绍 Ubuntu 上安装 OpenCode 和 Vibe-Kanban
|
||||
- 当前观点：本篇更详细，覆盖完整 6 步流程、pm2 进程管理、权限配置和验证步骤
|
||||
- 对方观点：前篇侧重基础安装步骤
|
||||
|
||||
@@ -1,66 +1,66 @@
|
||||
---
|
||||
title: "What I Know About Cloud Service Delivery 1"
|
||||
type: source
|
||||
tags: []
|
||||
date:
|
||||
author: shenwei
|
||||
sources: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/What I know about Cloud Service Delivery 1]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- **核心主题**：云服务交付（Cloud Service Delivery）的完整生命周期管理框架，涵盖从基础设施到客户支持的 12 大领域
|
||||
- **问题域**：如何将云技术（IaaS/PaaS/SaaS）的能力可靠、安全、高性能且成本有效地传递给最终用户
|
||||
- **方法/机制**：由多角色 Cloud Service Delivery Team 驱动，通过 IaC、监控、合规、成本优化等手段实现端到端管理
|
||||
- **结论/价值**：云服务交付是连接云技术能力与企业/用户实际需求之间的桥梁，需要多学科协作和持续运营
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Cloud Service Delivery Team（多角色团队）→ 通过专业分工 → 实现完整的云服务生命周期管理
|
||||
- Service Provisioning & Deployment → 自动化部署 + 资源配置和扩缩容 → 提高部署效率、加快交付速度
|
||||
- Infrastructure Management → 监控 + 补丁更新 + 高可用设置 → 确保底层基础设施稳定运行
|
||||
- Platform Management（PaaS）→ 中间件、数据库、开发工具和运行时管理 → 保证平台可扩展、安全、高性能
|
||||
- Application Operations & Management → 应用性能监控 + 持续部署 + 配置和密钥管理 → 确保应用弹性和可扩展性
|
||||
- Security & Compliance Management → 防火墙、IDS/IPS、加密、IAM 合规审计 → 保障云环境安全和合规
|
||||
- Performance & Availability Monitoring → 24/7 全栈监控 + SLA/SLO 管理 + 主动检测 → 确保服务高可用和性能达标
|
||||
- Incident & Problem Management → 快速响应 + 全栈故障排除 + 根因分析 → 最小化服务中断时间和影响
|
||||
- Change & Configuration Management → IaC + 变更控制 + 测试和回滚 → 降低变更风险、保证环境一致性
|
||||
- Cost Management & Optimization → 消费监控 + 消除浪费 + 合理选型（Savings Plans）→ 降低云支出、提升 ROI
|
||||
- Customer Onboarding & Support → 用户引导 + 文档培训 + 服务台运营 → 提升用户体验和满意度
|
||||
- Backup, Recovery & Disaster Management → 备份策略 + 恢复测试 + DR 演练 → 确保业务连续性和数据安全
|
||||
|
||||
## Key Quotes
|
||||
|
||||
## Key Concepts
|
||||
- [[Cloud Service Delivery]]：将云技术（IaaS/PaaS/SaaS）能力可靠、安全、高性能且成本有效地传递给最终用户的完整生命周期管理
|
||||
- [[Infrastructure as Code (IaC)]]：通过代码管理基础设施配置，确保一致性和可重复性（Change & Configuration Management）
|
||||
- [[Service Level Agreement (SLA)]]：服务等级协议，定义服务的可用性目标（如 99.9% vs 99.99%）
|
||||
- [[Service Level Objective (SLO)]]：服务等级目标，SLA 分解到具体服务的具体指标
|
||||
- [[FinOps]]：云财务管理，通过监控消费、消除浪费、合理选型来优化云成本
|
||||
- [[Incident Management]]：事件管理，快速响应和恢复服务中断
|
||||
- [[Problem Management]]：问题管理，识别根因并实施永久性修复
|
||||
- [[Disaster Recovery (DR)]]：灾难恢复，确保业务连续性的备份和故障切换机制
|
||||
- [[Cloud DevOps Maturity Model]]：云 DevOps 成熟度模型（本文件末尾提及，待扩展）
|
||||
- [[AIOps]]：人工智能运维（本文件末尾提及，待扩展）
|
||||
|
||||
## Key Entities
|
||||
- **AWS CloudWatch**：AWS 原生监控数据源，可接入 Grafana 实现统一可观测性
|
||||
- **Grafana**：监控可视化平台，支持 AWS CloudWatch 等多数据源
|
||||
- **New Relic**：APM/BPM 应用性能监控工具
|
||||
- **AWS CloudWatch Synthetic**：AWS 提供的服务可用性主动检测（Synthetic Monitoring）工具
|
||||
- **WAF (Web Application Firewall)**：云应用防火墙，管理云应用程序安全
|
||||
- **OpenText**：（作者所在组织）企业级云服务提供商
|
||||
|
||||
## Connections
|
||||
- [[Cloud Maturity Model - A Detailed Guide For Cloud Adoption]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]
|
||||
- [[DevOps Culture and Transformation]] ← extends ← [[What I Know About Cloud Service Delivery 1]]
|
||||
- [[Public Cloud Learning Sessions - Observability with OpenTelemetry]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]（可观测性层面）
|
||||
- [[CTP Topic 8 - Implementation of Cloud Monitoring]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]（监控实践）
|
||||
- [[Public Cloud Learning Sessions - Reducing Cloud Costs]] ← extends ← [[What I Know About Cloud Service Delivery 1]]（成本管理）
|
||||
- [[Public Cloud Learning Sessions - EKS Optimization]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]（平台管理）
|
||||
- [[CTP Topic 73 AWS Backup Implementation]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]（备份与灾难恢复）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[DevOps Maturity Model From Traditional IT to Advanced DevOps]] 潜在交叉：两者均涉及 DevOps 文化成熟度，但本文更侧重运营层面，后者侧重文化转型；暂无实质性冲突
|
||||
---
|
||||
title: "What I Know About Cloud Service Delivery 1"
|
||||
type: source
|
||||
tags: []
|
||||
date:
|
||||
author: shenwei
|
||||
sources: []
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/What I know about Cloud Service Delivery 1]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- **核心主题**：云服务交付（Cloud Service Delivery）的完整生命周期管理框架，涵盖从基础设施到客户支持的 12 大领域
|
||||
- **问题域**：如何将云技术（IaaS/PaaS/SaaS）的能力可靠、安全、高性能且成本有效地传递给最终用户
|
||||
- **方法/机制**：由多角色 Cloud Service Delivery Team 驱动，通过 IaC、监控、合规、成本优化等手段实现端到端管理
|
||||
- **结论/价值**：云服务交付是连接云技术能力与企业/用户实际需求之间的桥梁，需要多学科协作和持续运营
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Cloud Service Delivery Team（多角色团队）→ 通过专业分工 → 实现完整的云服务生命周期管理
|
||||
- Service Provisioning & Deployment → 自动化部署 + 资源配置和扩缩容 → 提高部署效率、加快交付速度
|
||||
- Infrastructure Management → 监控 + 补丁更新 + 高可用设置 → 确保底层基础设施稳定运行
|
||||
- Platform Management（PaaS）→ 中间件、数据库、开发工具和运行时管理 → 保证平台可扩展、安全、高性能
|
||||
- Application Operations & Management → 应用性能监控 + 持续部署 + 配置和密钥管理 → 确保应用弹性和可扩展性
|
||||
- Security & Compliance Management → 防火墙、IDS/IPS、加密、IAM 合规审计 → 保障云环境安全和合规
|
||||
- Performance & Availability Monitoring → 24/7 全栈监控 + SLA/SLO 管理 + 主动检测 → 确保服务高可用和性能达标
|
||||
- Incident & Problem Management → 快速响应 + 全栈故障排除 + 根因分析 → 最小化服务中断时间和影响
|
||||
- Change & Configuration Management → IaC + 变更控制 + 测试和回滚 → 降低变更风险、保证环境一致性
|
||||
- Cost Management & Optimization → 消费监控 + 消除浪费 + 合理选型（Savings Plans）→ 降低云支出、提升 ROI
|
||||
- Customer Onboarding & Support → 用户引导 + 文档培训 + 服务台运营 → 提升用户体验和满意度
|
||||
- Backup, Recovery & Disaster Management → 备份策略 + 恢复测试 + DR 演练 → 确保业务连续性和数据安全
|
||||
|
||||
## Key Quotes
|
||||
|
||||
## Key Concepts
|
||||
- [[Cloud Service Delivery]]：将云技术（IaaS/PaaS/SaaS）能力可靠、安全、高性能且成本有效地传递给最终用户的完整生命周期管理
|
||||
- [[Infrastructure as Code (IaC)]]：通过代码管理基础设施配置，确保一致性和可重复性（Change & Configuration Management）
|
||||
- [[Service Level Agreement (SLA)]]：服务等级协议，定义服务的可用性目标（如 99.9% vs 99.99%）
|
||||
- [[Service Level Objective (SLO)]]：服务等级目标，SLA 分解到具体服务的具体指标
|
||||
- [[FinOps]]：云财务管理，通过监控消费、消除浪费、合理选型来优化云成本
|
||||
- [[Incident Management]]：事件管理，快速响应和恢复服务中断
|
||||
- [[Problem Management]]：问题管理，识别根因并实施永久性修复
|
||||
- [[Disaster Recovery (DR)]]：灾难恢复，确保业务连续性的备份和故障切换机制
|
||||
- [[Cloud DevOps Maturity Model]]：云 DevOps 成熟度模型（本文件末尾提及，待扩展）
|
||||
- [[AIOps]]：人工智能运维（本文件末尾提及，待扩展）
|
||||
|
||||
## Key Entities
|
||||
- **AWS CloudWatch**：AWS 原生监控数据源，可接入 Grafana 实现统一可观测性
|
||||
- **Grafana**：监控可视化平台，支持 AWS CloudWatch 等多数据源
|
||||
- **New Relic**：APM/BPM 应用性能监控工具
|
||||
- **AWS CloudWatch Synthetic**：AWS 提供的服务可用性主动检测（Synthetic Monitoring）工具
|
||||
- **WAF (Web Application Firewall)**：云应用防火墙，管理云应用程序安全
|
||||
- **OpenText**：（作者所在组织）企业级云服务提供商
|
||||
|
||||
## Connections
|
||||
- [[Cloud Maturity Model - A Detailed Guide For Cloud Adoption]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]
|
||||
- [[DevOps Culture and Transformation]] ← extends ← [[What I Know About Cloud Service Delivery 1]]
|
||||
- [[Public Cloud Learning Sessions - Observability with OpenTelemetry]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]（可观测性层面）
|
||||
- [[CTP Topic 8 - Implementation of Cloud Monitoring]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]（监控实践）
|
||||
- [[Public Cloud Learning Sessions - Reducing Cloud Costs]] ← extends ← [[What I Know About Cloud Service Delivery 1]]（成本管理）
|
||||
- [[Public Cloud Learning Sessions - EKS Optimization]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]（平台管理）
|
||||
- [[CTP Topic 73 AWS Backup Implementation]] ← related_to ← [[What I Know About Cloud Service Delivery 1]]（备份与灾难恢复）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[DevOps Maturity Model From Traditional IT to Advanced DevOps]] 潜在交叉：两者均涉及 DevOps 文化成熟度，但本文更侧重运营层面，后者侧重文化转型；暂无实质性冲突
|
||||
|
||||
@@ -1,62 +1,62 @@
|
||||
---
|
||||
title: "What is DevSecOps? Best Practices, Benefits, and Tools"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2023-10-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/What is DevSecOps Best Practices, Benefits, and Tools]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：DevSecOps 将安全实践深度嵌入软件开发生命周期（SDLC），实现"安全即代码"
|
||||
- 问题域：传统 DevOps 在后期才引入安全导致漏洞修复成本高、交付速度慢的问题
|
||||
- 方法/机制：通过 Shift Left（左移）和 Shift Right（右移）策略，在 CI/CD 流水线中集成 SAST/DAST/SCA/IAST 等自动化安全工具，培养"全员安全责任"文化
|
||||
- 结论/价值：DevSecOps 能将 70% 的上线后发现的安全漏洞提前预防，实现安全与速度的平衡
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 70% 的软件漏洞可在 DevSecOps 实践中被预防
|
||||
- 安全左移（Shift Left）使团队能在开发早期发现并修复安全问题，降低修复成本
|
||||
- 自动化安全测试集成到 CI/CD 流水线中，可在不减缓开发速度的前提下保障安全
|
||||
- DevSecOps 通过"break the build"机制，当安全风险过高时停止构建流程
|
||||
- SAST、DAST、SCA、IAST 四类安全工具分别覆盖代码编写、运行时、第三方依赖和交互测试等不同阶段
|
||||
|
||||
## Key Quotes
|
||||
> "DevSecOps is a working methodology that includes security checks throughout the software development process." — DevSecOps 核心定义
|
||||
|
||||
> "70% of software vulnerabilities discovered post-launch could have been prevented with DevSecOps" — DevSecOps 价值量化
|
||||
|
||||
> "Everyone in the organization developing software is liable for security." — 全员安全责任文化
|
||||
|
||||
> "Shift left means identifying security flaws early in the software development lifecycle." — 左移策略定义
|
||||
|
||||
## Key Concepts
|
||||
- [[DevSecOps]]：在 DevOps 中全程集成安全实践的工作方法论
|
||||
- [[Shift Left]]：在软件开发生命周期早期识别并修复安全缺陷的策略
|
||||
- [[Shift Right]]：在应用上线后持续进行安全监控和问题修复的策略
|
||||
- [[SAST]]：静态应用安全测试，在代码编写阶段分析源代码以发现漏洞
|
||||
- [[DAST]]：动态应用安全测试，模拟外部攻击从运行时发现漏洞
|
||||
- [[SCA]]：软件成分分析，扫描第三方依赖库和框架的已知安全漏洞
|
||||
- [[IAST]]：交互式应用安全测试，在应用运行时检测其他工具遗漏的漏洞
|
||||
- [[CI/CD 安全]]：在持续集成/持续交付流水线中自动化执行安全扫描
|
||||
- [[Break the Build]]：当安全风险超过阈值时自动停止构建流程的机制
|
||||
- [[Policy as Code]]：以代码形式定义和自动执行安全策略的方法
|
||||
|
||||
## Key Entities
|
||||
- [[OWASP Top Ten]]：Web 应用安全标准，DevSecOps 测试中的重要参考框架
|
||||
- [[AWS CodePipeline]]：AWS 的 CI/CD 工具，可集成安全扫描
|
||||
- [[Amazon Inspector]]：AWS 漏洞管理自动化工具
|
||||
- [[Amazon CodeGuru Reviewer]]：AWS 代码安全和最佳实践审查工具
|
||||
|
||||
## Connections
|
||||
- [[DevOps]] ← extends ← [[DevSecOps]]（DevSecOps 是 DevOps 的安全扩展）
|
||||
- [[CI/CD 安全]] ← depends_on ← [[SAST]] / [[DAST]] / [[SCA]] / [[IAST]]
|
||||
- [[DevSecOps]] ← applies ← [[Shift Left]]
|
||||
- [[DevSecOps]] ← applies ← [[Shift Right]]
|
||||
- [[Agile Development]] ← integrates ← [[DevSecOps]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统瀑布式开发相比：
|
||||
- 冲突点：传统方式在 SDLC 末期才进行安全测试
|
||||
- 当前观点：DevSecOps 强调安全全程嵌入
|
||||
- 对方观点：安全专家在开发完成后再统一介入更专业
|
||||
---
|
||||
title: "What is DevSecOps? Best Practices, Benefits, and Tools"
|
||||
type: source
|
||||
tags: []
|
||||
date: 2023-10-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Cloud & DevOps/What is DevSecOps Best Practices, Benefits, and Tools]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：DevSecOps 将安全实践深度嵌入软件开发生命周期（SDLC），实现"安全即代码"
|
||||
- 问题域：传统 DevOps 在后期才引入安全导致漏洞修复成本高、交付速度慢的问题
|
||||
- 方法/机制：通过 Shift Left（左移）和 Shift Right（右移）策略，在 CI/CD 流水线中集成 SAST/DAST/SCA/IAST 等自动化安全工具，培养"全员安全责任"文化
|
||||
- 结论/价值：DevSecOps 能将 70% 的上线后发现的安全漏洞提前预防，实现安全与速度的平衡
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 70% 的软件漏洞可在 DevSecOps 实践中被预防
|
||||
- 安全左移（Shift Left）使团队能在开发早期发现并修复安全问题，降低修复成本
|
||||
- 自动化安全测试集成到 CI/CD 流水线中，可在不减缓开发速度的前提下保障安全
|
||||
- DevSecOps 通过"break the build"机制，当安全风险过高时停止构建流程
|
||||
- SAST、DAST、SCA、IAST 四类安全工具分别覆盖代码编写、运行时、第三方依赖和交互测试等不同阶段
|
||||
|
||||
## Key Quotes
|
||||
> "DevSecOps is a working methodology that includes security checks throughout the software development process." — DevSecOps 核心定义
|
||||
|
||||
> "70% of software vulnerabilities discovered post-launch could have been prevented with DevSecOps" — DevSecOps 价值量化
|
||||
|
||||
> "Everyone in the organization developing software is liable for security." — 全员安全责任文化
|
||||
|
||||
> "Shift left means identifying security flaws early in the software development lifecycle." — 左移策略定义
|
||||
|
||||
## Key Concepts
|
||||
- [[DevSecOps]]：在 DevOps 中全程集成安全实践的工作方法论
|
||||
- [[Shift Left]]：在软件开发生命周期早期识别并修复安全缺陷的策略
|
||||
- [[Shift Right]]：在应用上线后持续进行安全监控和问题修复的策略
|
||||
- [[SAST]]：静态应用安全测试，在代码编写阶段分析源代码以发现漏洞
|
||||
- [[DAST]]：动态应用安全测试，模拟外部攻击从运行时发现漏洞
|
||||
- [[SCA]]：软件成分分析，扫描第三方依赖库和框架的已知安全漏洞
|
||||
- [[IAST]]：交互式应用安全测试，在应用运行时检测其他工具遗漏的漏洞
|
||||
- [[CI/CD 安全]]：在持续集成/持续交付流水线中自动化执行安全扫描
|
||||
- [[Break the Build]]：当安全风险超过阈值时自动停止构建流程的机制
|
||||
- [[Policy as Code]]：以代码形式定义和自动执行安全策略的方法
|
||||
|
||||
## Key Entities
|
||||
- [[OWASP Top Ten]]：Web 应用安全标准，DevSecOps 测试中的重要参考框架
|
||||
- [[AWS CodePipeline]]：AWS 的 CI/CD 工具，可集成安全扫描
|
||||
- [[Amazon Inspector]]：AWS 漏洞管理自动化工具
|
||||
- [[Amazon CodeGuru Reviewer]]：AWS 代码安全和最佳实践审查工具
|
||||
|
||||
## Connections
|
||||
- [[DevOps]] ← extends ← [[DevSecOps]]（DevSecOps 是 DevOps 的安全扩展）
|
||||
- [[CI/CD 安全]] ← depends_on ← [[SAST]] / [[DAST]] / [[SCA]] / [[IAST]]
|
||||
- [[DevSecOps]] ← applies ← [[Shift Left]]
|
||||
- [[DevSecOps]] ← applies ← [[Shift Right]]
|
||||
- [[Agile Development]] ← integrates ← [[DevSecOps]]
|
||||
|
||||
## Contradictions
|
||||
- 与传统瀑布式开发相比：
|
||||
- 冲突点：传统方式在 SDLC 末期才进行安全测试
|
||||
- 当前观点：DevSecOps 强调安全全程嵌入
|
||||
- 对方观点：安全专家在开发完成后再统一介入更专业
|
||||
|
||||
@@ -1,46 +1,46 @@
|
||||
---
|
||||
title: "在Synology NAS上安装CloudDrive2"
|
||||
type: source
|
||||
tags: [clouddrive2, nas, synology, 阿里云盘]
|
||||
date: 2025-12-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/在Synology NAS上安装CloudDrive2.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 Synology NAS（DSM 7+）上安装并配置 CloudDrive2，实现阿里云盘的本地挂载
|
||||
- 问题域：群晖 NAS 用户希望将阿里云盘像本地硬盘一样挂载使用，无需手动同步
|
||||
- 方法/机制：通过 Synology 社群（矿神源）安装 CloudDrive2 → 执行 root 权限修复命令（DSM 7+ 专用）→ Web UI 配置 → 阿里云盘 App 扫码授权 → 挂载 Aliyun 目录
|
||||
- 结论/价值：CloudDrive2 提供了在 NAS 上原生挂载云盘的能力，适合影视、文件等大体积内容管理
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 主体 + 机制 + 结果
|
||||
- Synology 社群安装方式：矿神源 → 社群 → CloudDrive2（标准流程）
|
||||
- DSM 7+ 特殊处理：需执行 `sed` 命令修改 CloudDrive2 权限文件，将 `package` 替换为 `root`，否则因权限不足无法正常运行
|
||||
- Web UI 访问：通过 `http://192.168.3.17:19798/` 访问 CloudDrive2 配置界面
|
||||
- 阿里云盘授权：使用阿里云盘 App 扫码授权，仅授权「资源目录」（不要授权「备份目录」）
|
||||
|
||||
## Key Quotes
|
||||
> "因为我的 DSM 是 7+ 版本，所以需要额外在 root 下执行一条命令" — DSM 7+ 权限修复说明
|
||||
> "请主要，不要授权备份目录，仅资源目录即可" — 安全提示，避免备份文件被挂载
|
||||
|
||||
## Key Concepts
|
||||
- [[CloudDrive2]]：云盘挂载工具，支持阿里云盘、百度网盘等多种云存储，可将云端文件像本地硬盘一样在 NAS 上使用
|
||||
- [[Synology NAS]]：群晖网络附加存储设备，运行 DSM 操作系统；通过社群套件源安装第三方应用
|
||||
- [[矿神源]]：Synology 社群第三方套件源，提供大量社群维护的应用（如 CloudDrive2）
|
||||
|
||||
## Key Entities
|
||||
- [[阿里云盘]]：阿里巴巴旗下云盘服务，CloudDrive2 支持挂载的云存储之一；通过 App 扫码授权连接
|
||||
- [[CloudDrive2]]：云盘挂载应用，可在 NAS/PC 上将云盘映射为本地文件系统（WebDAV/SMB 等协议）
|
||||
|
||||
## Connections
|
||||
- [[群晖NAS科学上网方法]] ← related ← [[在Synology NAS上安装CloudDrive2]]（同一设备上的网络配置需求）
|
||||
- [[用Docker安装Jellyfin]] ← related ← [[在Synology NAS上安装CloudDrive2]]（Jellyfin 可读取 CloudDrive2 挂载的阿里云盘影视资源）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
## Related Sources
|
||||
- [[群晖NAS科学上网方法]]
|
||||
- [[用Docker安装Jellyfin]]
|
||||
---
|
||||
title: "在Synology NAS上安装CloudDrive2"
|
||||
type: source
|
||||
tags: [clouddrive2, nas, synology, 阿里云盘]
|
||||
date: 2025-12-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/在Synology NAS上安装CloudDrive2.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 Synology NAS（DSM 7+）上安装并配置 CloudDrive2，实现阿里云盘的本地挂载
|
||||
- 问题域：群晖 NAS 用户希望将阿里云盘像本地硬盘一样挂载使用，无需手动同步
|
||||
- 方法/机制：通过 Synology 社群（矿神源）安装 CloudDrive2 → 执行 root 权限修复命令（DSM 7+ 专用）→ Web UI 配置 → 阿里云盘 App 扫码授权 → 挂载 Aliyun 目录
|
||||
- 结论/价值：CloudDrive2 提供了在 NAS 上原生挂载云盘的能力，适合影视、文件等大体积内容管理
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 主体 + 机制 + 结果
|
||||
- Synology 社群安装方式：矿神源 → 社群 → CloudDrive2（标准流程）
|
||||
- DSM 7+ 特殊处理：需执行 `sed` 命令修改 CloudDrive2 权限文件，将 `package` 替换为 `root`，否则因权限不足无法正常运行
|
||||
- Web UI 访问：通过 `http://192.168.3.17:19798/` 访问 CloudDrive2 配置界面
|
||||
- 阿里云盘授权：使用阿里云盘 App 扫码授权，仅授权「资源目录」（不要授权「备份目录」）
|
||||
|
||||
## Key Quotes
|
||||
> "因为我的 DSM 是 7+ 版本，所以需要额外在 root 下执行一条命令" — DSM 7+ 权限修复说明
|
||||
> "请主要，不要授权备份目录，仅资源目录即可" — 安全提示，避免备份文件被挂载
|
||||
|
||||
## Key Concepts
|
||||
- [[CloudDrive2]]：云盘挂载工具，支持阿里云盘、百度网盘等多种云存储，可将云端文件像本地硬盘一样在 NAS 上使用
|
||||
- [[Synology NAS]]：群晖网络附加存储设备，运行 DSM 操作系统；通过社群套件源安装第三方应用
|
||||
- [[矿神源]]：Synology 社群第三方套件源，提供大量社群维护的应用（如 CloudDrive2）
|
||||
|
||||
## Key Entities
|
||||
- [[阿里云盘]]：阿里巴巴旗下云盘服务，CloudDrive2 支持挂载的云存储之一；通过 App 扫码授权连接
|
||||
- [[CloudDrive2]]：云盘挂载应用，可在 NAS/PC 上将云盘映射为本地文件系统（WebDAV/SMB 等协议）
|
||||
|
||||
## Connections
|
||||
- [[群晖NAS科学上网方法]] ← related ← [[在Synology NAS上安装CloudDrive2]]（同一设备上的网络配置需求）
|
||||
- [[用Docker安装Jellyfin]] ← related ← [[在Synology NAS上安装CloudDrive2]]（Jellyfin 可读取 CloudDrive2 挂载的阿里云盘影视资源）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
## Related Sources
|
||||
- [[群晖NAS科学上网方法]]
|
||||
- [[用Docker安装Jellyfin]]
|
||||
|
||||
@@ -1,51 +1,51 @@
|
||||
---
|
||||
title: "在Ubuntu上安装Vibe-Kanban"
|
||||
type: source
|
||||
tags: [npm, npx, pm2, ubuntu, vibe-coding, vibe-kanban]
|
||||
date: 2026-06-04
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/在Ubuntu上安装Vibe-Kanban.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 Ubuntu Server 上安装和配置 Vibe-Kanban AI 任务管理工具
|
||||
- 问题域：AI 辅助编程工作流、任务管理工具的服务器端部署
|
||||
- 方法/机制：通过 npx 直接运行 Vibe-Kanban，使用 PM2 进程管理器实现后台运行和开机自启
|
||||
- 结论/价值：提供完整的 Vibe-Kanban 安装指南，包括可选的 GitHub CLI 和 MCP 集成
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Vibe Kanban 默认以 `--dangerously-skip-permissions/--yolo` 标志运行 AI 代理，允许自主操作无需持续审批
|
||||
- 每个任务在隔离的 git worktree 中运行，防止代理之间相互干扰
|
||||
- 使用 `PORT=8080 npx vibe-kanban` 可指定固定端口
|
||||
- PM2 可以实现进程自动重启和开机自启，通过 `pm2 startup` 配置
|
||||
- 使用 `HOST=0.0.0.0 PORT=9999 npx vibe-kanban` 可实现局域网访问
|
||||
|
||||
## Key Quotes
|
||||
> "Vibe Kanban runs AI agents with —dangerously-skip-permissions/—yolo flags by default so they can work autonomously without constant approval prompts." — 安全机制说明
|
||||
> "Each task runs in an isolated git worktree, preventing agents from interfering with each other." — 隔离机制说明
|
||||
> "Vibe Kanban uses the GitHub CLI for creating pull requests. Ensure gh is installed and authenticated on your system." — GitHub 集成依赖
|
||||
|
||||
## Key Concepts
|
||||
- [[PM2]]：Node.js 进程管理器，提供进程守护、自动重启和开机自启功能
|
||||
- [[npx]]：Node.js 包执行工具，无需全局安装即可运行包
|
||||
- [[Vibe Coding]]：AI 辅助编程范式，通过自然语言描述让 AI 代理完成编码任务
|
||||
- [[MCP Server]]：Model Context Protocol 服务器，用于标准化 AI 代理与外部工具的集成
|
||||
|
||||
## Key Entities
|
||||
- [[Vibe-Kanban]]：BloopAI 出品的 AI 任务管理看板工具，支持多种编码代理
|
||||
- [[BloopAI]]：开发 Vibe-Kanban 的 AI 代码工具公司
|
||||
- [[Node.js]]：Vibe-Kanban 运行所需的 JavaScript 运行时环境
|
||||
- [[GitHub CLI]]：用于创建 Pull Request 的命令行工具，Vibe-Kanban 可选集成
|
||||
|
||||
## Connections
|
||||
- [[Vibe-Kanban]] ← depends_on ← [[Node.js]]
|
||||
- [[Vibe-Kanban]] ← extends ← [[GitHub CLI]]
|
||||
- [[Vibe-Kanban]] ← optional_integration ← [[MCP Server]]
|
||||
- [[PM2]] ← manages ← [[Vibe-Kanban]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] 部分重叠：
|
||||
- 冲突点：两者都介绍 Vibe-Kanban 安装，但侧重点不同
|
||||
- 当前观点：本文档侧重官方标准安装流程和 PM2 进程管理
|
||||
- 对方观点：[[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] 侧重 OpenCode 集成配置
|
||||
---
|
||||
title: "在Ubuntu上安装Vibe-Kanban"
|
||||
type: source
|
||||
tags: [npm, npx, pm2, ubuntu, vibe-coding, vibe-kanban]
|
||||
date: 2026-06-04
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/在Ubuntu上安装Vibe-Kanban.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在 Ubuntu Server 上安装和配置 Vibe-Kanban AI 任务管理工具
|
||||
- 问题域：AI 辅助编程工作流、任务管理工具的服务器端部署
|
||||
- 方法/机制：通过 npx 直接运行 Vibe-Kanban，使用 PM2 进程管理器实现后台运行和开机自启
|
||||
- 结论/价值：提供完整的 Vibe-Kanban 安装指南，包括可选的 GitHub CLI 和 MCP 集成
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Vibe Kanban 默认以 `--dangerously-skip-permissions/--yolo` 标志运行 AI 代理，允许自主操作无需持续审批
|
||||
- 每个任务在隔离的 git worktree 中运行，防止代理之间相互干扰
|
||||
- 使用 `PORT=8080 npx vibe-kanban` 可指定固定端口
|
||||
- PM2 可以实现进程自动重启和开机自启，通过 `pm2 startup` 配置
|
||||
- 使用 `HOST=0.0.0.0 PORT=9999 npx vibe-kanban` 可实现局域网访问
|
||||
|
||||
## Key Quotes
|
||||
> "Vibe Kanban runs AI agents with —dangerously-skip-permissions/—yolo flags by default so they can work autonomously without constant approval prompts." — 安全机制说明
|
||||
> "Each task runs in an isolated git worktree, preventing agents from interfering with each other." — 隔离机制说明
|
||||
> "Vibe Kanban uses the GitHub CLI for creating pull requests. Ensure gh is installed and authenticated on your system." — GitHub 集成依赖
|
||||
|
||||
## Key Concepts
|
||||
- [[PM2]]：Node.js 进程管理器，提供进程守护、自动重启和开机自启功能
|
||||
- [[npx]]：Node.js 包执行工具，无需全局安装即可运行包
|
||||
- [[Vibe Coding]]：AI 辅助编程范式，通过自然语言描述让 AI 代理完成编码任务
|
||||
- [[MCP Server]]：Model Context Protocol 服务器，用于标准化 AI 代理与外部工具的集成
|
||||
|
||||
## Key Entities
|
||||
- [[Vibe-Kanban]]：BloopAI 出品的 AI 任务管理看板工具，支持多种编码代理
|
||||
- [[BloopAI]]：开发 Vibe-Kanban 的 AI 代码工具公司
|
||||
- [[Node.js]]：Vibe-Kanban 运行所需的 JavaScript 运行时环境
|
||||
- [[GitHub CLI]]：用于创建 Pull Request 的命令行工具，Vibe-Kanban 可选集成
|
||||
|
||||
## Connections
|
||||
- [[Vibe-Kanban]] ← depends_on ← [[Node.js]]
|
||||
- [[Vibe-Kanban]] ← extends ← [[GitHub CLI]]
|
||||
- [[Vibe-Kanban]] ← optional_integration ← [[MCP Server]]
|
||||
- [[PM2]] ← manages ← [[Vibe-Kanban]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] 部分重叠：
|
||||
- 冲突点：两者都介绍 Vibe-Kanban 安装，但侧重点不同
|
||||
- 当前观点：本文档侧重官方标准安装流程和 PM2 进程管理
|
||||
- 对方观点：[[如何在Ubuntu上安装OpenCode并配置Vibe-Kanban]] 侧重 OpenCode 集成配置
|
||||
|
||||
@@ -1,62 +1,62 @@
|
||||
---
|
||||
title: "在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透"
|
||||
type: source
|
||||
tags: [vps, caddy, frp, reverse-proxy, troubleshooting, cloudflare, ubuntu, 内网穿透]
|
||||
date: 2026-05-28
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 VPS（公网服务器）+ frp（反向隧道）+ Caddy（自动 HTTPS 反向代理）实现家庭内网服务的公网域名访问
|
||||
- 问题域：家庭/办公内网中的 NAS、Ubuntu 服务器运行的服务（如 n8n、Grafana、Transmission、SSH 等）如何通过自定义域名从公网安全访问
|
||||
- 方法/机制：Cloudflare DNS A 记录指向 VPS 公网 IP → VPS 运行 frps（frp 服务端）和 Caddy → 内网主机运行 frpc（frp 客户端）将本地端口映射到 VPS → Caddy 反向代理到 frp 映射端口，自动申请 Let's Encrypt 证书提供 HTTPS
|
||||
- 结论/价值：完整梳理了从 DNS 配置、frps/frpc 安装配置、Caddy 反向代理到 SSH 穿透的全套流程，并提供了 7 步系统化故障排查指南
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- frp 内网穿透工具包含 frps（服务端）和 frpc（客户端），通过 TCP 反向隧道将内网端口暴露到公网 VPS，支持 NAT 穿透和自动重连
|
||||
- Caddy 自动管理 HTTPS 证书（Let's Encrypt），无需手动配置 SSL，通过 reverse_proxy 指令将请求转发到 frp 映射的本地端口
|
||||
- Cloudflare DNS 仅负责将子域名 A 记录指向 VPS 公网 IP，不影响 TCP 流量的直接路由
|
||||
- SSH 穿透不同于 HTTP/HTTPS，不经过 Caddy，仅通过 frps + frpc 的 TCP 映射实现（`type = tcp`，`remote_port = 60022`）
|
||||
- 内网 NAS 上的 V2RayA 透明代理可能干扰 frp 连接，需要停止代理后重启 frpc
|
||||
- frp 连接失败的主要原因包括：端口被占用/token 不一致/防火墙拦截/Caddy 误 proxy TCP 端口
|
||||
- 通过 `ssh -p 60022 user@ubuntu1.ishenwei.online` 可从公网 SSH 到内网 Ubuntu（需 DNS A 记录 + frpc 配置）
|
||||
|
||||
## Key Quotes
|
||||
> "思路：Cloudflare DNS 指向公网上的一台VPS，VPS 上运行 Caddy；内网主机通过 frp 将服务暴露到 VPS（本地 127.0.0.1 或某个端口），VPS 反向代理到该端口。" — 整体方案架构描述
|
||||
|
||||
> "Caddy 会自动申请并更新 Let's Encrypt 证书，提供 HTTPS 访问。" — Caddy 自动 HTTPS 特性
|
||||
|
||||
> "⚠️ **重点提醒（安全性）**：SSH 穿透与 HTTP 不同，它是纯 TCP 流量，不经 Caddy（Caddy 只处理 HTTP/HTTPS），所以：Caddy 不参与 SSH 的代理，只用 frps + frpc 配置即可完成。" — SSH 与 HTTP 代理架构差异
|
||||
|
||||
> "authentication failed token mismatch invalid login → 那肯定是 token 和 frpc 不一致。" — frp 连接失败的核心原因之一
|
||||
|
||||
> "很多人遇到的问题是：他们编辑了 `/opt/frp/frps.ini`，但 systemd service 其实加载另一个路径，例如 `/etc/frp/frps.ini`。" — frps 配置加载路径的常见陷阱
|
||||
|
||||
## Key Concepts
|
||||
- [[内网穿透]]：通过公网服务器中转，使 NAT/防火墙后的内网服务可被外部访问的技术，本方案使用 frp 反向隧道实现
|
||||
- [[反向代理]]：Caddy 作为反向代理，将公网 HTTPS 请求转发到本地 frp 映射端口，提供统一的 HTTPS 入口
|
||||
- [[TCP隧道]]：frp 通过 TCP 协议在 frpc 客户端和 frps 服务端之间建立持久隧道，支持非 HTTP 协议（如 SSH、MySQL）
|
||||
- [[自动HTTPS]]：Caddy 内置 Let's Encrypt 证书自动申请和续期，无需手动管理 SSL 证书
|
||||
- [[DNS A记录]]：Cloudflare DNS 配置，将子域名（如 nas.ishenwei.online）指向 VPS 公网 IP
|
||||
|
||||
## Key Entities
|
||||
- [[RackNerd VPS]]：VPS 提供商（192.227.222.142），托管 frps 服务端和 Caddy 反向代理，作为内网穿透的公网中转站
|
||||
- [[Synology NAS DS718]]：内网 NAS 设备（192.168.3.17），运行 frpc 客户端，通过 frp 暴露 NAS 服务（5000端口 → VPS 15000）、Navidrome、Calibre、WebDAV、Miniflux、Zipline、MySQL、SSH 等多个服务
|
||||
- [[frp]]：开源内网穿透工具，本方案的核心，包含 frps（服务端，监听 7000 端口）和 frpc（客户端），版本 0.65.0；通过 token 认证确保连接安全
|
||||
- [[Caddy]]：Go 语言编写的自动 HTTPS 反向代理服务器，与 frp 配合为内网服务提供 HTTPS 域名访问；支持 `caddy validate` 命令验证配置语法
|
||||
- [[Cloudflare]]：域名 DNS 托管服务商，通过 A 记录将 ishenwei.online 子域名指向 VPS 公网 IP
|
||||
|
||||
## Connections
|
||||
- [[家庭网络环境概览_2026-04-03]] ← extends ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（本文是该概览中内网穿透架构的详细展开）
|
||||
- [[ubuntu-安装-frp-0-65-0-x86_64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（FRP 安装是该方案的前置步骤）
|
||||
- [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（Mac Mini FRP 客户端配置参考）
|
||||
- [[Ubuntu Server]] ← hosts ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（Ubuntu Server 24.04 是本方案的目标操作系统）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] 可能的差异点：
|
||||
- 冲突点：监控方案中是否包含完整的公网访问配置
|
||||
- 当前观点：本文提供完整公网域名访问方案，包含 HTTPS 和 SSH 穿透的详细配置
|
||||
- 对方观点：监控方案侧重于 Prometheus + Grafana + exporters 的部署和告警配置，未展开公网访问细节
|
||||
- 建议：在监控方案中补充指向本文内网穿透配置的外链，实现监控方案 + 公网访问的完整闭环
|
||||
---
|
||||
title: "在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透"
|
||||
type: source
|
||||
tags: [vps, caddy, frp, reverse-proxy, troubleshooting, cloudflare, ubuntu, 内网穿透]
|
||||
date: 2026-05-28
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 VPS（公网服务器）+ frp（反向隧道）+ Caddy（自动 HTTPS 反向代理）实现家庭内网服务的公网域名访问
|
||||
- 问题域：家庭/办公内网中的 NAS、Ubuntu 服务器运行的服务（如 n8n、Grafana、Transmission、SSH 等）如何通过自定义域名从公网安全访问
|
||||
- 方法/机制：Cloudflare DNS A 记录指向 VPS 公网 IP → VPS 运行 frps（frp 服务端）和 Caddy → 内网主机运行 frpc（frp 客户端）将本地端口映射到 VPS → Caddy 反向代理到 frp 映射端口，自动申请 Let's Encrypt 证书提供 HTTPS
|
||||
- 结论/价值：完整梳理了从 DNS 配置、frps/frpc 安装配置、Caddy 反向代理到 SSH 穿透的全套流程，并提供了 7 步系统化故障排查指南
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- frp 内网穿透工具包含 frps（服务端）和 frpc（客户端），通过 TCP 反向隧道将内网端口暴露到公网 VPS，支持 NAT 穿透和自动重连
|
||||
- Caddy 自动管理 HTTPS 证书（Let's Encrypt），无需手动配置 SSL，通过 reverse_proxy 指令将请求转发到 frp 映射的本地端口
|
||||
- Cloudflare DNS 仅负责将子域名 A 记录指向 VPS 公网 IP，不影响 TCP 流量的直接路由
|
||||
- SSH 穿透不同于 HTTP/HTTPS，不经过 Caddy，仅通过 frps + frpc 的 TCP 映射实现（`type = tcp`，`remote_port = 60022`）
|
||||
- 内网 NAS 上的 V2RayA 透明代理可能干扰 frp 连接，需要停止代理后重启 frpc
|
||||
- frp 连接失败的主要原因包括：端口被占用/token 不一致/防火墙拦截/Caddy 误 proxy TCP 端口
|
||||
- 通过 `ssh -p 60022 user@ubuntu1.ishenwei.online` 可从公网 SSH 到内网 Ubuntu（需 DNS A 记录 + frpc 配置）
|
||||
|
||||
## Key Quotes
|
||||
> "思路：Cloudflare DNS 指向公网上的一台VPS，VPS 上运行 Caddy；内网主机通过 frp 将服务暴露到 VPS（本地 127.0.0.1 或某个端口），VPS 反向代理到该端口。" — 整体方案架构描述
|
||||
|
||||
> "Caddy 会自动申请并更新 Let's Encrypt 证书，提供 HTTPS 访问。" — Caddy 自动 HTTPS 特性
|
||||
|
||||
> "⚠️ **重点提醒（安全性）**：SSH 穿透与 HTTP 不同，它是纯 TCP 流量，不经 Caddy（Caddy 只处理 HTTP/HTTPS），所以：Caddy 不参与 SSH 的代理，只用 frps + frpc 配置即可完成。" — SSH 与 HTTP 代理架构差异
|
||||
|
||||
> "authentication failed token mismatch invalid login → 那肯定是 token 和 frpc 不一致。" — frp 连接失败的核心原因之一
|
||||
|
||||
> "很多人遇到的问题是：他们编辑了 `/opt/frp/frps.ini`，但 systemd service 其实加载另一个路径，例如 `/etc/frp/frps.ini`。" — frps 配置加载路径的常见陷阱
|
||||
|
||||
## Key Concepts
|
||||
- [[内网穿透]]：通过公网服务器中转，使 NAT/防火墙后的内网服务可被外部访问的技术，本方案使用 frp 反向隧道实现
|
||||
- [[反向代理]]：Caddy 作为反向代理，将公网 HTTPS 请求转发到本地 frp 映射端口，提供统一的 HTTPS 入口
|
||||
- [[TCP隧道]]：frp 通过 TCP 协议在 frpc 客户端和 frps 服务端之间建立持久隧道，支持非 HTTP 协议（如 SSH、MySQL）
|
||||
- [[自动HTTPS]]：Caddy 内置 Let's Encrypt 证书自动申请和续期，无需手动管理 SSL 证书
|
||||
- [[DNS A记录]]：Cloudflare DNS 配置，将子域名（如 nas.ishenwei.online）指向 VPS 公网 IP
|
||||
|
||||
## Key Entities
|
||||
- [[RackNerd VPS]]：VPS 提供商（192.227.222.142），托管 frps 服务端和 Caddy 反向代理，作为内网穿透的公网中转站
|
||||
- [[Synology NAS DS718]]：内网 NAS 设备（192.168.3.17），运行 frpc 客户端，通过 frp 暴露 NAS 服务（5000端口 → VPS 15000）、Navidrome、Calibre、WebDAV、Miniflux、Zipline、MySQL、SSH 等多个服务
|
||||
- [[frp]]：开源内网穿透工具，本方案的核心，包含 frps（服务端，监听 7000 端口）和 frpc（客户端），版本 0.65.0；通过 token 认证确保连接安全
|
||||
- [[Caddy]]：Go 语言编写的自动 HTTPS 反向代理服务器，与 frp 配合为内网服务提供 HTTPS 域名访问；支持 `caddy validate` 命令验证配置语法
|
||||
- [[Cloudflare]]：域名 DNS 托管服务商，通过 A 记录将 ishenwei.online 子域名指向 VPS 公网 IP
|
||||
|
||||
## Connections
|
||||
- [[家庭网络环境概览_2026-04-03]] ← extends ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（本文是该概览中内网穿透架构的详细展开）
|
||||
- [[ubuntu-安装-frp-0-65-0-x86_64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（FRP 安装是该方案的前置步骤）
|
||||
- [[mac-mini-安装-frp-0-65-0-arm64-操作笔记]] ← depends_on ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（Mac Mini FRP 客户端配置参考）
|
||||
- [[Ubuntu Server]] ← hosts ← [[在Ubuntu上通过VPS+内网反向代理实现域名访问内网穿透]]（Ubuntu Server 24.04 是本方案的目标操作系统）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]] 可能的差异点：
|
||||
- 冲突点：监控方案中是否包含完整的公网访问配置
|
||||
- 当前观点：本文提供完整公网域名访问方案，包含 HTTPS 和 SSH 穿透的详细配置
|
||||
- 对方观点：监控方案侧重于 Prometheus + Grafana + exporters 的部署和告警配置，未展开公网访问细节
|
||||
- 建议：在监控方案中补充指向本文内网穿透配置的外链，实现监控方案 + 公网访问的完整闭环
|
||||
|
||||
@@ -1,44 +1,44 @@
|
||||
---
|
||||
title: "如何传输Docker images 并且在另一个Docker安装"
|
||||
type: source
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/如何传输Docker images 并且在另一个Docker安装]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Docker 镜像在两台 Docker 环境之间的离线传输方法
|
||||
- 问题域：无镜像仓库的内网环境或离线场景下的镜像迁移
|
||||
- 方法/机制：`docker save` 导出为 tar → 上传目标机器 → `docker load` 导入
|
||||
- 结论/价值：提供了无需镜像仓库的离线迁移标准流程，适用于家庭 NAS 与工作设备之间的镜像同步
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- `docker pull` 从远程仓库拉取镜像到本地 Docker 环境
|
||||
- `docker save -o <output.tar> <image>` 将镜像导出为 tar 归档文件，可离线拷贝
|
||||
- `docker load < <input.tar` 在目标机器从 tar 文件加载镜像，无需网络连接
|
||||
- 上传 tar 包到目标机器后，可在 Container Manager 等 Web UI 中直接看到已导入的镜像
|
||||
|
||||
## Key Quotes
|
||||
> "cd 到 xiaoya.tar 存放的路径之后运行以下命令 docker load < xiaoya.tar" — 在 Synology NAS 上通过 SSH 执行镜像导入
|
||||
> "再进入 NAS 的 Container Manager 界面后在 image 里就可以看到 xiaoya/alist 这个 image 了" — 验证镜像导入成功的方式
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker-Image]]：容器镜像，Docker 应用打包的标准格式
|
||||
- [[Docker-Save]]：`docker save` 命令将镜像导出为 tar 归档文件
|
||||
- [[Docker-Load]]：`docker load` 命令从 tar 文件加载镜像到本地 Docker 引擎
|
||||
- [[Docker-Registry]]：镜像仓库（本文未使用，但提及作为替代方案）
|
||||
|
||||
## Key Entities
|
||||
- [[Docker]]：容器化平台，本文的操作基础环境
|
||||
- [[Synology-NAS]]：群晖 NAS，运行 Docker（Container Manager），本文镜像迁移的目标端
|
||||
- [[Alist]]：开源网盘聚合工具（xiaoyaliu/alist），本文操作的示例镜像
|
||||
|
||||
## Connections
|
||||
- [[如何在Ubuntu Server安装 Docker & Docker Compose]] ← extends ← [[如何传输Docker images 并且在另一个Docker安装]]
|
||||
- [[在Synology NAS上安装CloudDrive2]] ← related_to ← [[如何传输Docker images 并且在另一个Docker安装]]（同为 Synology NAS Docker 操作场景）
|
||||
|
||||
## Contradictions
|
||||
- （无已知冲突）
|
||||
---
|
||||
title: "如何传输Docker images 并且在另一个Docker安装"
|
||||
type: source
|
||||
tags: []
|
||||
sources: []
|
||||
last_updated: 2026-05-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/如何传输Docker images 并且在另一个Docker安装]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Docker 镜像在两台 Docker 环境之间的离线传输方法
|
||||
- 问题域：无镜像仓库的内网环境或离线场景下的镜像迁移
|
||||
- 方法/机制：`docker save` 导出为 tar → 上传目标机器 → `docker load` 导入
|
||||
- 结论/价值：提供了无需镜像仓库的离线迁移标准流程，适用于家庭 NAS 与工作设备之间的镜像同步
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- `docker pull` 从远程仓库拉取镜像到本地 Docker 环境
|
||||
- `docker save -o <output.tar> <image>` 将镜像导出为 tar 归档文件，可离线拷贝
|
||||
- `docker load < <input.tar` 在目标机器从 tar 文件加载镜像，无需网络连接
|
||||
- 上传 tar 包到目标机器后，可在 Container Manager 等 Web UI 中直接看到已导入的镜像
|
||||
|
||||
## Key Quotes
|
||||
> "cd 到 xiaoya.tar 存放的路径之后运行以下命令 docker load < xiaoya.tar" — 在 Synology NAS 上通过 SSH 执行镜像导入
|
||||
> "再进入 NAS 的 Container Manager 界面后在 image 里就可以看到 xiaoya/alist 这个 image 了" — 验证镜像导入成功的方式
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker-Image]]：容器镜像，Docker 应用打包的标准格式
|
||||
- [[Docker-Save]]：`docker save` 命令将镜像导出为 tar 归档文件
|
||||
- [[Docker-Load]]：`docker load` 命令从 tar 文件加载镜像到本地 Docker 引擎
|
||||
- [[Docker-Registry]]：镜像仓库（本文未使用，但提及作为替代方案）
|
||||
|
||||
## Key Entities
|
||||
- [[Docker]]：容器化平台，本文的操作基础环境
|
||||
- [[Synology-NAS]]：群晖 NAS，运行 Docker（Container Manager），本文镜像迁移的目标端
|
||||
- [[Alist]]：开源网盘聚合工具（xiaoyaliu/alist），本文操作的示例镜像
|
||||
|
||||
## Connections
|
||||
- [[如何在Ubuntu Server安装 Docker & Docker Compose]] ← extends ← [[如何传输Docker images 并且在另一个Docker安装]]
|
||||
- [[在Synology NAS上安装CloudDrive2]] ← related_to ← [[如何传输Docker images 并且在另一个Docker安装]]（同为 Synology NAS Docker 操作场景）
|
||||
|
||||
## Contradictions
|
||||
- （无已知冲突）
|
||||
|
||||
@@ -1,59 +1,59 @@
|
||||
---
|
||||
title: "如何删除旧的废弃的 Docker Container + Volume"
|
||||
type: source
|
||||
tags: [docker, container, portainer, volume]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/如何删除旧的废弃的docker container +volume.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：清理 Docker 环境中废弃的 Portainer 容器、Volume 和 Network 的完整操作流程
|
||||
- 问题域：Docker 容器残留导致的端口冲突、卷数据残留、以及重启 Portainer 时出现的 WARN 警告
|
||||
- 方法/机制：通过 `docker stop/rm`、`docker volume ls/rm`、`docker network ls/rm` 系列命令手动清理；使用 `docker compose down` 一键清理整个 compose 项目；通过 `external: true` 配置避免 future 部署时的资源冲突
|
||||
- 结论/价值：提供了从手动单步清理到一键重装的完整操作链，以及 WARN 原因分析和解决方案
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- `docker compose down` 命令可同时删除容器、网络和匿名 Volume，但保留命名 Volume
|
||||
- `docker volume rm` 可显式删除指定 Volume（如 `portainer_data`），从而清除 Portainer 所有用户数据和配置
|
||||
- Docker WARN "Network already exists" 表示同名 network 由另一个 compose 项目创建，与当前项目冲突
|
||||
- Docker WARN "Volume is used by another service" 表示同名 volume 属于另一个 compose 项目的不同 project name
|
||||
- 在 compose 文件中设置 `external: true` 可让新项目复用旧 network/volume 而不触发冲突警告
|
||||
|
||||
## Key Quotes
|
||||
> "⚠️ 注意：这会删除 Portainer 所有数据（用户、配置）。如果你想保留数据，不要删 volume，只需要在 compose 文件里加：`external: true`" — 删除 portainer_data 的重要提示
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker Container]]：Docker 镜像的运行实例，`docker ps -a` 查看所有容器，`docker rm` 删除已停止容器，`docker rm -f` 强制删除运行中容器
|
||||
- [[Docker Volume]]：持久化存储机制，挂载到容器内部用于保存数据；`docker volume ls` 列出所有卷，`docker volume rm` 删除指定卷
|
||||
- [[Docker Network]]：容器间通信的虚拟网络；同名 network 冲突是 compose 项目隔离机制导致的警告
|
||||
- [[Docker Compose]]：`docker compose down` 停止并删除整个 compose 项目中的容器、网络，以及（非 external 的）命名卷
|
||||
- [[Docker Socket]]：Docker 守护进程的 Unix Socket（通常为 `/var/run/docker.sock`），Portainer 通过挂载它实现对本地 Docker 的管理
|
||||
|
||||
## Key Entities
|
||||
- [[Portainer]]：开源 Docker 容器管理面板，本文档的清理目标；`portainer/portainer-ce` 为其 Community Edition 镜像
|
||||
- [[portainer_data]]：Portainer 的命名 Docker Volume，存储用户、配置等持久化数据
|
||||
|
||||
## Connections
|
||||
- [[用Docker安装Portainer]] ← depends_on ← [[如何删除旧的废弃的 Docker Container + Volume]]
|
||||
- [[如何在Ubuntu Server安装 Docker & Docker Compose]] ← related_to ← [[如何删除旧的废弃的 Docker Container + Volume]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
## 完整操作流程速查
|
||||
|
||||
```bash
|
||||
# 最干净的重装流程
|
||||
docker stop portainer && docker rm portainer
|
||||
docker volume rm portainer_data
|
||||
docker network rm portainer_network
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
```bash
|
||||
# 一键清理（compose 部署）
|
||||
docker compose down # 删除容器+网络+匿名卷
|
||||
docker compose down -v # 额外删除命名卷（谨慎！）
|
||||
```
|
||||
---
|
||||
title: "如何删除旧的废弃的 Docker Container + Volume"
|
||||
type: source
|
||||
tags: [docker, container, portainer, volume]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/如何删除旧的废弃的docker container +volume.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：清理 Docker 环境中废弃的 Portainer 容器、Volume 和 Network 的完整操作流程
|
||||
- 问题域：Docker 容器残留导致的端口冲突、卷数据残留、以及重启 Portainer 时出现的 WARN 警告
|
||||
- 方法/机制：通过 `docker stop/rm`、`docker volume ls/rm`、`docker network ls/rm` 系列命令手动清理；使用 `docker compose down` 一键清理整个 compose 项目；通过 `external: true` 配置避免 future 部署时的资源冲突
|
||||
- 结论/价值：提供了从手动单步清理到一键重装的完整操作链，以及 WARN 原因分析和解决方案
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- `docker compose down` 命令可同时删除容器、网络和匿名 Volume，但保留命名 Volume
|
||||
- `docker volume rm` 可显式删除指定 Volume（如 `portainer_data`），从而清除 Portainer 所有用户数据和配置
|
||||
- Docker WARN "Network already exists" 表示同名 network 由另一个 compose 项目创建，与当前项目冲突
|
||||
- Docker WARN "Volume is used by another service" 表示同名 volume 属于另一个 compose 项目的不同 project name
|
||||
- 在 compose 文件中设置 `external: true` 可让新项目复用旧 network/volume 而不触发冲突警告
|
||||
|
||||
## Key Quotes
|
||||
> "⚠️ 注意：这会删除 Portainer 所有数据（用户、配置）。如果你想保留数据，不要删 volume，只需要在 compose 文件里加：`external: true`" — 删除 portainer_data 的重要提示
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker Container]]：Docker 镜像的运行实例，`docker ps -a` 查看所有容器，`docker rm` 删除已停止容器，`docker rm -f` 强制删除运行中容器
|
||||
- [[Docker Volume]]：持久化存储机制，挂载到容器内部用于保存数据；`docker volume ls` 列出所有卷，`docker volume rm` 删除指定卷
|
||||
- [[Docker Network]]：容器间通信的虚拟网络；同名 network 冲突是 compose 项目隔离机制导致的警告
|
||||
- [[Docker Compose]]：`docker compose down` 停止并删除整个 compose 项目中的容器、网络，以及（非 external 的）命名卷
|
||||
- [[Docker Socket]]：Docker 守护进程的 Unix Socket（通常为 `/var/run/docker.sock`），Portainer 通过挂载它实现对本地 Docker 的管理
|
||||
|
||||
## Key Entities
|
||||
- [[Portainer]]：开源 Docker 容器管理面板，本文档的清理目标；`portainer/portainer-ce` 为其 Community Edition 镜像
|
||||
- [[portainer_data]]：Portainer 的命名 Docker Volume，存储用户、配置等持久化数据
|
||||
|
||||
## Connections
|
||||
- [[用Docker安装Portainer]] ← depends_on ← [[如何删除旧的废弃的 Docker Container + Volume]]
|
||||
- [[如何在Ubuntu Server安装 Docker & Docker Compose]] ← related_to ← [[如何删除旧的废弃的 Docker Container + Volume]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
## 完整操作流程速查
|
||||
|
||||
```bash
|
||||
# 最干净的重装流程
|
||||
docker stop portainer && docker rm portainer
|
||||
docker volume rm portainer_data
|
||||
docker network rm portainer_network
|
||||
docker compose up -d
|
||||
```
|
||||
|
||||
```bash
|
||||
# 一键清理（compose 部署）
|
||||
docker compose down # 删除容器+网络+匿名卷
|
||||
docker compose down -v # 额外删除命名卷（谨慎！）
|
||||
```
|
||||
|
||||
@@ -1,49 +1,49 @@
|
||||
---
|
||||
title: "如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹"
|
||||
type: source
|
||||
tags: [nas, nfs, synology, ubuntu]
|
||||
date: 2025-12-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 NFS 协议将 Synology NAS 的共享文件夹挂载到 Ubuntu Server，实现永久性网络存储挂载
|
||||
- 问题域：Ubuntu 服务器与 Synology NAS 之间的网络存储集成，适用于备份场景
|
||||
- 方法/机制：
|
||||
- Synology DSM 控制面板配置 NFS 权限（IP白名单、Squash 映射为 admin、_netdev 参数）
|
||||
- Ubuntu 端安装 `nfs-common`，使用 `mount -t nfs` 临时挂载
|
||||
- 通过 `/etc/fstab` 配置永久挂载，含 `timeo=900`、`retrans=5`、`_netdev` 等参数
|
||||
- rsync 脚本中加入挂载点检测保护，防止 NAS 掉线时数据写入本地
|
||||
- 结论/价值：相比 Samba，NFS 能保留 Linux 文件权限（uid/gid），避免 Docker 卷恢复时的权限报错，是 Linux 服务器挂载 NAS 的标准方案
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Synology NAS 的 Squash 设置"映射所有用户为 admin"，可将 Ubuntu 端 root 请求在 NAS 端以 admin 身份执行，绕过 Linux 权限校验
|
||||
- `/etc/fstab` 中的 `_netdev` 参数可防止开机时网络未就绪导致系统挂起
|
||||
- NFS 相比 Samba 在处理 Docker 配置文件（大量小文件）时性能更强
|
||||
- rsync 脚本中加入挂载点检查，可在 NAS 掉线时主动终止备份，防止数据写入本地目录
|
||||
|
||||
## Key Quotes
|
||||
> "NFS 能完美保留（Linux 文件所有权信息），而 Samba 会丢失，导致恢复 Docker 卷时权限报错" — NFS 相对 Samba 的核心优势说明
|
||||
|
||||
> "_netdev：告诉系统这是一个网络设备，务必等到网络服务完全启动后再尝试挂载，防止开机过程因找不到网络而卡死" — fstab 中 _netdev 参数的关键作用
|
||||
|
||||
> "如果 `sudo mount -a` 没有报错，且 `df` 能看到 NAS 空间，那么以后重启服务器，挂载都会自动生效" — 永久挂载验证方法
|
||||
|
||||
## Key Concepts
|
||||
- [[NFS]]：Network File System，Linux/Unix 标准的网络文件系统协议，支持保留原始 uid/gid 权限
|
||||
- [[/etc/fstab]]：Linux 文件系统表，用于配置开机自动挂载；`_netdev` 参数确保网络设备就绪后再挂载
|
||||
- [[rsync]]：增量备份工具，可配合 NFS 挂载点实现服务器到 NAS 的自动化备份
|
||||
- [[Squash]]：NFS 权限设置中的用户映射选项，"映射所有用户为 admin" 可简化跨平台权限问题
|
||||
|
||||
## Key Entities
|
||||
- [[Synology NAS]]：群晖网络附加存储设备，提供 DSM 管理界面和 NFS 共享服务；本文示例 IP：192.168.3.17，挂载路径：/volume2/backup
|
||||
- [[Ubuntu Server]]：Linux 服务器操作系统，本文版本为 Ubuntu 24.04；示例 IP：192.168.3.47，挂载点：/mnt/nas_backup
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu服务器通过rsync实现日常增量备份]] ← depends_on ← [[如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹]]（rsync 备份依赖 NFS 挂载的 NAS 存储）
|
||||
- [[群晖NAS科学上网方法]] ← related ← [[如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹]]（同为 Synology NAS 相关配置文档）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
---
|
||||
title: "如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹"
|
||||
type: source
|
||||
tags: [nas, nfs, synology, ubuntu]
|
||||
date: 2025-12-29
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 NFS 协议将 Synology NAS 的共享文件夹挂载到 Ubuntu Server，实现永久性网络存储挂载
|
||||
- 问题域：Ubuntu 服务器与 Synology NAS 之间的网络存储集成，适用于备份场景
|
||||
- 方法/机制：
|
||||
- Synology DSM 控制面板配置 NFS 权限（IP白名单、Squash 映射为 admin、_netdev 参数）
|
||||
- Ubuntu 端安装 `nfs-common`，使用 `mount -t nfs` 临时挂载
|
||||
- 通过 `/etc/fstab` 配置永久挂载，含 `timeo=900`、`retrans=5`、`_netdev` 等参数
|
||||
- rsync 脚本中加入挂载点检测保护，防止 NAS 掉线时数据写入本地
|
||||
- 结论/价值：相比 Samba，NFS 能保留 Linux 文件权限（uid/gid），避免 Docker 卷恢复时的权限报错，是 Linux 服务器挂载 NAS 的标准方案
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Synology NAS 的 Squash 设置"映射所有用户为 admin"，可将 Ubuntu 端 root 请求在 NAS 端以 admin 身份执行，绕过 Linux 权限校验
|
||||
- `/etc/fstab` 中的 `_netdev` 参数可防止开机时网络未就绪导致系统挂起
|
||||
- NFS 相比 Samba 在处理 Docker 配置文件（大量小文件）时性能更强
|
||||
- rsync 脚本中加入挂载点检查，可在 NAS 掉线时主动终止备份，防止数据写入本地目录
|
||||
|
||||
## Key Quotes
|
||||
> "NFS 能完美保留（Linux 文件所有权信息），而 Samba 会丢失，导致恢复 Docker 卷时权限报错" — NFS 相对 Samba 的核心优势说明
|
||||
|
||||
> "_netdev：告诉系统这是一个网络设备，务必等到网络服务完全启动后再尝试挂载，防止开机过程因找不到网络而卡死" — fstab 中 _netdev 参数的关键作用
|
||||
|
||||
> "如果 `sudo mount -a` 没有报错，且 `df` 能看到 NAS 空间，那么以后重启服务器，挂载都会自动生效" — 永久挂载验证方法
|
||||
|
||||
## Key Concepts
|
||||
- [[NFS]]：Network File System，Linux/Unix 标准的网络文件系统协议，支持保留原始 uid/gid 权限
|
||||
- [[/etc/fstab]]：Linux 文件系统表，用于配置开机自动挂载；`_netdev` 参数确保网络设备就绪后再挂载
|
||||
- [[rsync]]：增量备份工具，可配合 NFS 挂载点实现服务器到 NAS 的自动化备份
|
||||
- [[Squash]]：NFS 权限设置中的用户映射选项，"映射所有用户为 admin" 可简化跨平台权限问题
|
||||
|
||||
## Key Entities
|
||||
- [[Synology NAS]]：群晖网络附加存储设备，提供 DSM 管理界面和 NFS 共享服务；本文示例 IP：192.168.3.17，挂载路径：/volume2/backup
|
||||
- [[Ubuntu Server]]：Linux 服务器操作系统，本文版本为 Ubuntu 24.04；示例 IP：192.168.3.47，挂载点：/mnt/nas_backup
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu服务器通过rsync实现日常增量备份]] ← depends_on ← [[如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹]]（rsync 备份依赖 NFS 挂载的 NAS 存储）
|
||||
- [[群晖NAS科学上网方法]] ← related ← [[如何在Ubuntu Server上通过NFS挂载Synology NAS上的共享文件夹]]（同为 Synology NAS 相关配置文档）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
@@ -1,54 +1,54 @@
|
||||
---
|
||||
title: "如何在Ubuntu Server安装 Docker & Docker Compose"
|
||||
type: source
|
||||
tags: [Docker, Ubuntu, 容器化, DevOps]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/如何在Ubuntu Server安装 docker & docker compose]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Ubuntu Server 上安装 Docker Engine 和 Docker Compose V2 的完整操作指南
|
||||
- 问题域：Ubuntu Server 容器运行时环境搭建，是后续所有 Docker 部署类笔记的前置依赖
|
||||
- 方法/机制：通过添加 Docker 官方 APT 仓库（GPG 密钥验证）→ 安装 Docker Engine 核心组件（dockerd、containerd、buildx、compose）→ 验证安装 → 配置非 root 用户权限
|
||||
- 结论/价值：官方仓库安装确保版本最新，与 Ubuntu 内置旧版 docker.io 包完全兼容；Docker Compose V2 通过 `docker compose` 调用，与传统 `docker-compose` 命令分离
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Docker 官方 APT 仓库安装比 Ubuntu 默认仓库版本更新、功能更完整
|
||||
- 安装 `docker-compose-plugin` 即获得 Docker Compose V2，使用 `docker compose` 而非 `docker-compose` 命令
|
||||
- 将用户加入 `docker` 用户组后无需 `sudo` 即可运行 Docker 命令
|
||||
- 完整安装包含 5 个组件包：docker-ce、docker-ce-cli、containerd.io、docker-buildx-plugin、docker-compose-plugin
|
||||
|
||||
## Key Quotes
|
||||
> "The `docker-compose-plugin` installs Docker Compose V2, which is used via the command `docker compose` instead of `docker-compose`." — 源文档 Step 3 安装说明
|
||||
> "Log out and log back in (or restart your terminal session, or run `newgrp docker`) for the changes to take effect." — 源文档 Step 5 用户组配置说明
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker Engine]]：容器运行时核心，包含 dockerd 守护进程、containerd 容器运行时、docker CLI 工具
|
||||
- [[Docker Compose]]：多容器应用编排工具，V2 版本通过 `docker compose` 子命令调用
|
||||
- [[containerd]]：Docker 的底层容器运行时，本文档安装 `containerd.io` 包
|
||||
- [[GPG 密钥验证]]：Docker 官方通过 GPG 密钥（`/etc/apt/keyrings/docker.asc`）验证 APT 包来源真实性
|
||||
- [[APT 仓库配置]]：通过在 `/etc/apt/sources.list.d/docker.list` 添加 Docker 官方仓库启用
|
||||
- [[Docker 用户组]]：通过 `usermod -aG docker $USER` 将用户加入 docker 组实现免 sudo 运行
|
||||
|
||||
## Key Entities
|
||||
- [[Docker]]：Docker 公司及其容器平台生态
|
||||
- [[Docker-CE]]：Docker Community Edition 开源版本
|
||||
- [[hello-world]]：官方验证镜像，用于测试 Docker 安装是否成功
|
||||
- [[Docker-Buildx-Plugin]]：Docker 多平台镜像构建插件
|
||||
- [[Docker-Compose-Plugin]]：Docker Compose V2 插件形式实现
|
||||
|
||||
## Connections
|
||||
- [[Docker Engine]] ← 依赖 ← [[containerd]]（安装 containerd.io 包）
|
||||
- [[Docker Engine]] ← 依赖 ← [[Docker-Buildx-Plugin]]（安装时一并安装）
|
||||
- [[Docker Engine]] ← 依赖 ← [[Docker-Compose-Plugin]]（安装时一并安装）
|
||||
- [[Ubuntu Server]] ← 目标平台 ← [[如何在ubuntu-server安装-docker-docker-compose]]（本文档）
|
||||
- [[Docker]] ← 官方维护 ← [[Docker-CE]]（上游包来源）
|
||||
- [[如何在ubuntu-server安装-docker-docker-compose]] → 前置依赖 → [[用docker安装it-tools]]（it-tools 需 Docker 环境）
|
||||
- [[如何在ubuntu-server安装-docker-docker-compose]] → 前置依赖 → [[用docker安装portainer]]（Portainer 需 Docker 环境）
|
||||
- [[如何在ubuntu-server安装-docker-docker-compose]] → 前置依赖 → [[用docker安装transmission]]（Transmission 需 Docker 环境）
|
||||
- [[如何在ubuntu-server安装-docker-docker-compose]] → 前置依赖 → [[用docker中安装navidrome]]（Navidrome 需 Docker 环境）
|
||||
|
||||
## Contradictions
|
||||
- 无冲突。文档聚焦 Ubuntu Server 单机安装流程，与企业级 Kubernetes 容器编排（[[Container-Lifecycle-Hardening]]）等来源属不同层次，无内容矛盾。
|
||||
---
|
||||
title: "如何在Ubuntu Server安装 Docker & Docker Compose"
|
||||
type: source
|
||||
tags: [Docker, Ubuntu, 容器化, DevOps]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/如何在Ubuntu Server安装 docker & docker compose]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Ubuntu Server 上安装 Docker Engine 和 Docker Compose V2 的完整操作指南
|
||||
- 问题域：Ubuntu Server 容器运行时环境搭建，是后续所有 Docker 部署类笔记的前置依赖
|
||||
- 方法/机制：通过添加 Docker 官方 APT 仓库（GPG 密钥验证）→ 安装 Docker Engine 核心组件（dockerd、containerd、buildx、compose）→ 验证安装 → 配置非 root 用户权限
|
||||
- 结论/价值：官方仓库安装确保版本最新，与 Ubuntu 内置旧版 docker.io 包完全兼容；Docker Compose V2 通过 `docker compose` 调用，与传统 `docker-compose` 命令分离
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Docker 官方 APT 仓库安装比 Ubuntu 默认仓库版本更新、功能更完整
|
||||
- 安装 `docker-compose-plugin` 即获得 Docker Compose V2，使用 `docker compose` 而非 `docker-compose` 命令
|
||||
- 将用户加入 `docker` 用户组后无需 `sudo` 即可运行 Docker 命令
|
||||
- 完整安装包含 5 个组件包：docker-ce、docker-ce-cli、containerd.io、docker-buildx-plugin、docker-compose-plugin
|
||||
|
||||
## Key Quotes
|
||||
> "The `docker-compose-plugin` installs Docker Compose V2, which is used via the command `docker compose` instead of `docker-compose`." — 源文档 Step 3 安装说明
|
||||
> "Log out and log back in (or restart your terminal session, or run `newgrp docker`) for the changes to take effect." — 源文档 Step 5 用户组配置说明
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker Engine]]：容器运行时核心，包含 dockerd 守护进程、containerd 容器运行时、docker CLI 工具
|
||||
- [[Docker Compose]]：多容器应用编排工具，V2 版本通过 `docker compose` 子命令调用
|
||||
- [[containerd]]：Docker 的底层容器运行时，本文档安装 `containerd.io` 包
|
||||
- [[GPG 密钥验证]]：Docker 官方通过 GPG 密钥（`/etc/apt/keyrings/docker.asc`）验证 APT 包来源真实性
|
||||
- [[APT 仓库配置]]：通过在 `/etc/apt/sources.list.d/docker.list` 添加 Docker 官方仓库启用
|
||||
- [[Docker 用户组]]：通过 `usermod -aG docker $USER` 将用户加入 docker 组实现免 sudo 运行
|
||||
|
||||
## Key Entities
|
||||
- [[Docker]]：Docker 公司及其容器平台生态
|
||||
- [[Docker-CE]]：Docker Community Edition 开源版本
|
||||
- [[hello-world]]：官方验证镜像，用于测试 Docker 安装是否成功
|
||||
- [[Docker-Buildx-Plugin]]：Docker 多平台镜像构建插件
|
||||
- [[Docker-Compose-Plugin]]：Docker Compose V2 插件形式实现
|
||||
|
||||
## Connections
|
||||
- [[Docker Engine]] ← 依赖 ← [[containerd]]（安装 containerd.io 包）
|
||||
- [[Docker Engine]] ← 依赖 ← [[Docker-Buildx-Plugin]]（安装时一并安装）
|
||||
- [[Docker Engine]] ← 依赖 ← [[Docker-Compose-Plugin]]（安装时一并安装）
|
||||
- [[Ubuntu Server]] ← 目标平台 ← [[如何在ubuntu-server安装-docker-docker-compose]]（本文档）
|
||||
- [[Docker]] ← 官方维护 ← [[Docker-CE]]（上游包来源）
|
||||
- [[如何在ubuntu-server安装-docker-docker-compose]] → 前置依赖 → [[用docker安装it-tools]]（it-tools 需 Docker 环境）
|
||||
- [[如何在ubuntu-server安装-docker-docker-compose]] → 前置依赖 → [[用docker安装portainer]]（Portainer 需 Docker 环境）
|
||||
- [[如何在ubuntu-server安装-docker-docker-compose]] → 前置依赖 → [[用docker安装transmission]]（Transmission 需 Docker 环境）
|
||||
- [[如何在ubuntu-server安装-docker-docker-compose]] → 前置依赖 → [[用docker中安装navidrome]]（Navidrome 需 Docker 环境）
|
||||
|
||||
## Contradictions
|
||||
- 无冲突。文档聚焦 Ubuntu Server 单机安装流程，与企业级 Kubernetes 容器编排（[[Container-Lifecycle-Hardening]]）等来源属不同层次，无内容矛盾。
|
||||
|
||||
@@ -1,53 +1,53 @@
|
||||
---
|
||||
title: "如何用指纹浏览器安全注册并订阅Claude Pro会员全攻略"
|
||||
type: source
|
||||
tags: [adspower, claude, ip, pingme]
|
||||
date: 2025-12-31
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/如何用指纹浏览器安全注册并订阅Claude Pro会员全攻略]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过指纹浏览器 + 高纯净度代理IP + 接码平台 + 虚拟信用卡，实现安全注册并订阅 Claude Pro，避免账号被封。
|
||||
- 问题域：国内用户注册 Claude 账号面临的IP关联、支付限制、验证码接收三大障碍。
|
||||
- 方法/机制：
|
||||
- AdsPower 指纹浏览器创建隔离浏览器环境，模拟不同设备和IP
|
||||
- SOCKS5 代理 + 多网站IP一致性检测 + Scamalytics 纯净度评估
|
||||
- PingMe 接码平台获取美国长期有效手机号
|
||||
- WildCard 虚拟信用卡解决跨境支付
|
||||
- 结论/价值：掌握完整流程可有效降低封号风险，稳定使用 Claude Pro 会员服务。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 使用本地浏览器直接访问 Claude 会暴露设备和IP特征，导致账号关联被封。
|
||||
- 代理IP在多个检测网站测试结果不一致时，会被平台判定为异常。
|
||||
- IP纯净度"中等风险"或更高的IP大幅增加封号风险，必须使用低风险IP。
|
||||
- 一次性接码号码不稳定，易导致账号绑定失败。
|
||||
- 国内信用卡无法完成 Claude Pro 支付，必须使用虚拟信用卡。
|
||||
|
||||
## Key Quotes
|
||||
> "AdsPower指纹浏览器，支持谷歌授权登录，提供客户端体验完整功能。" — 工具推荐
|
||||
> "代理设置成功后，用检查代理功能确认IP归属地为美国，实现代理连接成功。" — IP验证步骤
|
||||
> "通过访问多个IP检测网站，确认测试点国内、国外和谷歌三处IP保持高度一致，保证IP稳定性。" — IP一致性检测
|
||||
> "重要的IP风险评估，理想纯净度为'低风险'，数值越低越安全。中等风险或以上可能被封号。" — Scamalytics纯净度评估
|
||||
> "手机验证码推荐用新兴接码平台PingMe，支持中文界面，需下载App，用手机号注册并充值最低2美元。" — 接码平台推荐
|
||||
> "国内信用卡无法支付，推荐使用WildCard虚拟信用卡解决跨境支付难题。" — 支付方案
|
||||
|
||||
## Key Concepts
|
||||
- [[指纹浏览器]]：一种可模拟不同设备、网络环境的多账号浏览器，通过隔离使用环境减少账号关联风险。
|
||||
- [[SOCKS5代理]]：一种网络代理协议，支持灵活的传输隧道，有助于隐匿真实IP和地理位置。
|
||||
- [[IP纯净度]]：通过Scamalytics等平台评估IP风险等级，低风险代表良好信誉和较少异常记录。
|
||||
- [[接码平台]]：提供短信接码服务的应用或网站，支持接收短消息以完成注册或验证。
|
||||
|
||||
## Key Entities
|
||||
- [[AdsPower]]：推荐使用的指纹浏览器，支持Chrome授权登录，免费可用5个环境。
|
||||
- [[PingMe]]：新兴接码平台，支持中文界面，需App注册，最低充值2美元，提供美国长期号码。
|
||||
- [[WildCard]]：虚拟信用卡，支持支付宝充值，用于解决Claude Pro海外支付。
|
||||
|
||||
## Connections
|
||||
- Claude Pro ← 订阅目标 ← [[指纹浏览器]]（环境隔离）+ [[SOCKS5代理]]（IP隐匿）+ [[WildCard]]（支付解决）
|
||||
- [[接码平台]] ← 支持注册 ← Claude
|
||||
- [[IP纯净度]] ← 评估工具 ← Scamalytics
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突页面。
|
||||
---
|
||||
title: "如何用指纹浏览器安全注册并订阅Claude Pro会员全攻略"
|
||||
type: source
|
||||
tags: [adspower, claude, ip, pingme]
|
||||
date: 2025-12-31
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/如何用指纹浏览器安全注册并订阅Claude Pro会员全攻略]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过指纹浏览器 + 高纯净度代理IP + 接码平台 + 虚拟信用卡，实现安全注册并订阅 Claude Pro，避免账号被封。
|
||||
- 问题域：国内用户注册 Claude 账号面临的IP关联、支付限制、验证码接收三大障碍。
|
||||
- 方法/机制：
|
||||
- AdsPower 指纹浏览器创建隔离浏览器环境，模拟不同设备和IP
|
||||
- SOCKS5 代理 + 多网站IP一致性检测 + Scamalytics 纯净度评估
|
||||
- PingMe 接码平台获取美国长期有效手机号
|
||||
- WildCard 虚拟信用卡解决跨境支付
|
||||
- 结论/价值：掌握完整流程可有效降低封号风险，稳定使用 Claude Pro 会员服务。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 使用本地浏览器直接访问 Claude 会暴露设备和IP特征，导致账号关联被封。
|
||||
- 代理IP在多个检测网站测试结果不一致时，会被平台判定为异常。
|
||||
- IP纯净度"中等风险"或更高的IP大幅增加封号风险，必须使用低风险IP。
|
||||
- 一次性接码号码不稳定，易导致账号绑定失败。
|
||||
- 国内信用卡无法完成 Claude Pro 支付，必须使用虚拟信用卡。
|
||||
|
||||
## Key Quotes
|
||||
> "AdsPower指纹浏览器，支持谷歌授权登录，提供客户端体验完整功能。" — 工具推荐
|
||||
> "代理设置成功后，用检查代理功能确认IP归属地为美国，实现代理连接成功。" — IP验证步骤
|
||||
> "通过访问多个IP检测网站，确认测试点国内、国外和谷歌三处IP保持高度一致，保证IP稳定性。" — IP一致性检测
|
||||
> "重要的IP风险评估，理想纯净度为'低风险'，数值越低越安全。中等风险或以上可能被封号。" — Scamalytics纯净度评估
|
||||
> "手机验证码推荐用新兴接码平台PingMe，支持中文界面，需下载App，用手机号注册并充值最低2美元。" — 接码平台推荐
|
||||
> "国内信用卡无法支付，推荐使用WildCard虚拟信用卡解决跨境支付难题。" — 支付方案
|
||||
|
||||
## Key Concepts
|
||||
- [[指纹浏览器]]：一种可模拟不同设备、网络环境的多账号浏览器，通过隔离使用环境减少账号关联风险。
|
||||
- [[SOCKS5代理]]：一种网络代理协议，支持灵活的传输隧道，有助于隐匿真实IP和地理位置。
|
||||
- [[IP纯净度]]：通过Scamalytics等平台评估IP风险等级，低风险代表良好信誉和较少异常记录。
|
||||
- [[接码平台]]：提供短信接码服务的应用或网站，支持接收短消息以完成注册或验证。
|
||||
|
||||
## Key Entities
|
||||
- [[AdsPower]]：推荐使用的指纹浏览器，支持Chrome授权登录，免费可用5个环境。
|
||||
- [[PingMe]]：新兴接码平台，支持中文界面，需App注册，最低充值2美元，提供美国长期号码。
|
||||
- [[WildCard]]：虚拟信用卡，支持支付宝充值，用于解决Claude Pro海外支付。
|
||||
|
||||
## Connections
|
||||
- Claude Pro ← 订阅目标 ← [[指纹浏览器]]（环境隔离）+ [[SOCKS5代理]]（IP隐匿）+ [[WildCard]]（支付解决）
|
||||
- [[接码平台]] ← 支持注册 ← Claude
|
||||
- [[IP纯净度]] ← 评估工具 ← Scamalytics
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突页面。
|
||||
|
||||
@@ -1,75 +1,75 @@
|
||||
---
|
||||
title: "安装Ubuntu 24.04.2在HP ZBook工作站笔记本上"
|
||||
type: source
|
||||
tags: [hp, ubuntu, zbook, rufus, uefi, nvme, efibootmgr]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/安装Ubuntu-24.04.2在HP Zbook工作站笔记本上.md]]
|
||||
|
||||
## Summary (中文)
|
||||
- **核心主题**：在 HP ZBook 工作站笔记本上安装 Ubuntu 24.04.2 Desktop 的完整实操指南，涵盖启动盘制作、分区配置、BIOS/UEFI 设置及启动引导故障排除。
|
||||
- **问题域**：HP ZBook 笔记本 + Ubuntu 24.04.2 双系统安装，聚焦 UEFI/GPT 引导环境下的 NVMe 硬盘分区与 HP BIOS 固执行为导致的启动项丢失问题。
|
||||
- **方法/机制**：
|
||||
- Rufus ISOHybrid 镜像写入（ISO 镜像模式优先，DD 模式为备选）
|
||||
- GPT 分区方案（/boot/efi FAT32 512MB-1GB, / ext4 100-200GB, /home ext4 剩余空间, swap 8-32GB）
|
||||
- HP BIOS F9 启动菜单、F10 进入 BIOS 设置
|
||||
- HP BIOS Storage → AHCI 模式（非 RAID/Intel RST）
|
||||
- 关闭 Secure Boot 和 Fast Boot 避免驱动安装障碍
|
||||
- efibootmgr NVRAM 强制重写 BootOrder
|
||||
- EFI 默认路径伪装（shimx64.efi → /EFI/BOOT/BOOTX64.EFI）
|
||||
- BIOS Boot Mode 切换为 UEFI Only，消除 Legacy BBS 遗留项干扰
|
||||
- **结论/价值**：HP ZBook 等现代 UEFI 工作站安装 Ubuntu 的完整故障排除路线图。核心痛点是 HP BIOS 不持久化 NVRAM 启动项；终极解法是切换 Boot Mode 为 UEFI Only，可使 Legacy BBS 项自动消失，BIOS 被迫只识别 Ubuntu 启动项。文中建议安装完成后立即用 rsync 还原数据，并用 Clonezilla 制作母版镜像以备将来快速恢复。
|
||||
|
||||
## Key Claims (中文)
|
||||
- HP ZBook 必须使用 GPT 分区表配合 UEFI 启动，MBR/Legacy 不适用于现代 UEFI 工作站。
|
||||
- Rufus 写入 ISOHybrid 镜像时应优先选择"ISO 镜像模式"；DD 模式仅在启动失败后才重新制作选择。
|
||||
- HP BIOS 有固执行为（不保存自定义启动项），可通过三种方式绕过：efibootmgr 强制重写 NVRAM BootOrder → EFI 默认路径伪装 → BIOS 切换 UEFI Only（终极方案）。
|
||||
- 混合模式（Legacy/CSM）会产生大量 BBS 遗留启动项干扰 UEFI 识别，切换为 UEFI Only 后 Boot0000-0004 自动消失。
|
||||
- SATA 模式须设为 AHCI（非 RAID/Intel RST），Ubuntu 24.04 对 RST 兼容性差。
|
||||
- NVMe 硬盘安装 Ubuntu 24.04 时系统会自动识别并优化分区对齐，手动分区时保持默认扇区起始位置（通常 2048）即可。
|
||||
- ext4 是 HP ZBook Docker 环境最兼容的文件系统；ZFS/Btrfs 虽有快照功能但兼容性不及 ext4。
|
||||
|
||||
## Key Quotes
|
||||
> "HP 的旧款 ZBook 有个'坏习惯'：如果它在 NVRAM 里找不到它认为'标准'的启动项，它会重置 BootOrder。我们可以把 Ubuntu 的引导文件复制到磁盘的默认备用路径。这样即使 BIOS 抽风忽略了 NVRAM，也会因为在磁盘上找到了文件而启动。" — HP ZBook 引导伪装大法
|
||||
|
||||
> "一旦切换为 UEFI Only，那些无效的 0000-0004 就会消失，BIOS 将被迫只看 0005 (Ubuntu)。" — UEFI Only 切换后效果
|
||||
|
||||
> "Legacy Support (传统支持)：确保设置为 Disabled (或者选择 UEFI Without Legacy)。从你的输出看，你现在有大量的 BBS (Legacy) 启动项，这会干扰 UEFI 的识别。" — 混合模式问题诊断
|
||||
|
||||
> "HP BIOS 有时非常固执，它只会寻找磁盘上默认的启动文件（/EFI/BOOT/BOOTX64.EFI）。如果它不保存你的自定义项，我们可以通过在 Ubuntu 内将 shimx64.efi 伪装成默认文件来'欺骗' BIOS。" — EFI 文件伪装修复原理
|
||||
|
||||
## Key Concepts
|
||||
- [[GPT分区表]]：现代 UEFI 设备的标准分区方案，支持 2TB+ 硬盘，与 UEFI 引导完美兼容；HP ZBook 等工作站必须使用 GPT 而非 MBR。
|
||||
- [[efibootmgr]]：Linux 系统下管理 NVRAM 启动项的工具，可查看（`efibootmgr`）、重写启动顺序（`-o 0005,0000,...`）、手动添加启动项（`-c -d /dev/nvme0n1 -p 1`）。
|
||||
- [[ISOHybrid镜像]]：同时支持 BIOS 和 UEFI 引导的混合 ISO 镜像；Rufus 提供 ISO 镜像模式（推荐）和 DD 模式（备选）两种写入方式。
|
||||
- [[UEFI启动修复]]：HP BIOS 固执行为导致启动项丢失的完整解决方案链路（efibootmgr 强制写入 → EFI 路径伪装 → UEFI Only 切换）。
|
||||
- [[NVMe硬盘分区]]：Ubuntu 24.04 自动识别并优化 NVMe 分区对齐；手动分区时保持默认扇区起始位置（2048）即可。
|
||||
- [[Socket Activation]]：Ubuntu 24.04 SSH 默认使用 ssh.socket 按需激活机制（相关链接页面）。
|
||||
|
||||
## Key Entities
|
||||
- [[HP ZBook]]：HP 工作站笔记本，F9 启动菜单，F10 进入 BIOS，固执的 BIOS NVRAM 行为；存储模式须设为 AHCI，Boot Mode 建议切换为 UEFI Only。
|
||||
- [[Rufus]]：开源 U 盘启动盘制作工具，ISOHybrid 镜像写入（推荐 ISO 镜像模式），自动下载 ldlinux.sys/ldlinux.bss 引导文件。
|
||||
- [[Ubuntu 24.04]]：LTS 桌面操作系统，默认 ssh.socket 按需激活，支持 NVMe 自动优化，ext4 为推荐文件系统。
|
||||
- [[Clonezilla]]：全盘镜像备份工具（相关链接页面），文中建议安装完成后用 Clonezilla 制作母版镜像。
|
||||
|
||||
## Connections
|
||||
- [[HP ZBook]] ← 安装目标 ← [[Rufus]]（启动盘制作工具）
|
||||
- [[efibootmgr]] ← 修复工具 ← [[UEFI启动修复]]（核心手段）
|
||||
- [[GPT分区表]] ← 分区方案 ← [[NVMe硬盘分区]]（自动对齐优化）
|
||||
- [[UEFI启动修复]] ← 终极方案 ← [[HP ZBook]] BIOS 固执行为
|
||||
- [[clonezilla对ubuntu-server进行全盘镜像备份]] ← 备份建议 ← [[Ubuntu 24.04]] 安装完成后（母版镜像）
|
||||
- [[ubuntu-24-04-enable-ssh]] ← 后置配置 ← [[Ubuntu 24.04]]（SSH 服务启用）
|
||||
- [[ubuntu禁用合盖休眠]] ← 后置配置 ← [[Ubuntu 24.04]]（合盖休眠设置）
|
||||
|
||||
## Contradictions
|
||||
- **无冲突**：本文档与其他来源一致，未检测到矛盾点。
|
||||
|
||||
## Related Sources
|
||||
- [[ubuntu-24-04-enable-ssh]] — Ubuntu 24.04 安装后的 SSH 配置
|
||||
- [[ubuntu禁用合盖休眠]] — Ubuntu 24.04 合盖休眠设置
|
||||
- [[ubuntu-server科学上网]] — Ubuntu Server 科学上网配置
|
||||
- [[ubuntu用rustdesk远程登录出现不能使用wayland登录的错误]] — Ubuntu RustDesk Wayland 登录问题
|
||||
- [[ubuntu服务器通过rsync实现日常增量备份]] — 安装完成后 rsync 数据恢复建议
|
||||
- [[clonezilla对ubuntu-server进行全盘镜像备份]] — 母版镜像制作工具，文中提及 Clonezilla
|
||||
---
|
||||
title: "安装Ubuntu 24.04.2在HP ZBook工作站笔记本上"
|
||||
type: source
|
||||
tags: [hp, ubuntu, zbook, rufus, uefi, nvme, efibootmgr]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/安装Ubuntu-24.04.2在HP Zbook工作站笔记本上.md]]
|
||||
|
||||
## Summary (中文)
|
||||
- **核心主题**：在 HP ZBook 工作站笔记本上安装 Ubuntu 24.04.2 Desktop 的完整实操指南，涵盖启动盘制作、分区配置、BIOS/UEFI 设置及启动引导故障排除。
|
||||
- **问题域**：HP ZBook 笔记本 + Ubuntu 24.04.2 双系统安装，聚焦 UEFI/GPT 引导环境下的 NVMe 硬盘分区与 HP BIOS 固执行为导致的启动项丢失问题。
|
||||
- **方法/机制**：
|
||||
- Rufus ISOHybrid 镜像写入（ISO 镜像模式优先，DD 模式为备选）
|
||||
- GPT 分区方案（/boot/efi FAT32 512MB-1GB, / ext4 100-200GB, /home ext4 剩余空间, swap 8-32GB）
|
||||
- HP BIOS F9 启动菜单、F10 进入 BIOS 设置
|
||||
- HP BIOS Storage → AHCI 模式（非 RAID/Intel RST）
|
||||
- 关闭 Secure Boot 和 Fast Boot 避免驱动安装障碍
|
||||
- efibootmgr NVRAM 强制重写 BootOrder
|
||||
- EFI 默认路径伪装（shimx64.efi → /EFI/BOOT/BOOTX64.EFI）
|
||||
- BIOS Boot Mode 切换为 UEFI Only，消除 Legacy BBS 遗留项干扰
|
||||
- **结论/价值**：HP ZBook 等现代 UEFI 工作站安装 Ubuntu 的完整故障排除路线图。核心痛点是 HP BIOS 不持久化 NVRAM 启动项；终极解法是切换 Boot Mode 为 UEFI Only，可使 Legacy BBS 项自动消失，BIOS 被迫只识别 Ubuntu 启动项。文中建议安装完成后立即用 rsync 还原数据，并用 Clonezilla 制作母版镜像以备将来快速恢复。
|
||||
|
||||
## Key Claims (中文)
|
||||
- HP ZBook 必须使用 GPT 分区表配合 UEFI 启动，MBR/Legacy 不适用于现代 UEFI 工作站。
|
||||
- Rufus 写入 ISOHybrid 镜像时应优先选择"ISO 镜像模式"；DD 模式仅在启动失败后才重新制作选择。
|
||||
- HP BIOS 有固执行为（不保存自定义启动项），可通过三种方式绕过：efibootmgr 强制重写 NVRAM BootOrder → EFI 默认路径伪装 → BIOS 切换 UEFI Only（终极方案）。
|
||||
- 混合模式（Legacy/CSM）会产生大量 BBS 遗留启动项干扰 UEFI 识别，切换为 UEFI Only 后 Boot0000-0004 自动消失。
|
||||
- SATA 模式须设为 AHCI（非 RAID/Intel RST），Ubuntu 24.04 对 RST 兼容性差。
|
||||
- NVMe 硬盘安装 Ubuntu 24.04 时系统会自动识别并优化分区对齐，手动分区时保持默认扇区起始位置（通常 2048）即可。
|
||||
- ext4 是 HP ZBook Docker 环境最兼容的文件系统；ZFS/Btrfs 虽有快照功能但兼容性不及 ext4。
|
||||
|
||||
## Key Quotes
|
||||
> "HP 的旧款 ZBook 有个'坏习惯'：如果它在 NVRAM 里找不到它认为'标准'的启动项，它会重置 BootOrder。我们可以把 Ubuntu 的引导文件复制到磁盘的默认备用路径。这样即使 BIOS 抽风忽略了 NVRAM，也会因为在磁盘上找到了文件而启动。" — HP ZBook 引导伪装大法
|
||||
|
||||
> "一旦切换为 UEFI Only，那些无效的 0000-0004 就会消失，BIOS 将被迫只看 0005 (Ubuntu)。" — UEFI Only 切换后效果
|
||||
|
||||
> "Legacy Support (传统支持)：确保设置为 Disabled (或者选择 UEFI Without Legacy)。从你的输出看，你现在有大量的 BBS (Legacy) 启动项，这会干扰 UEFI 的识别。" — 混合模式问题诊断
|
||||
|
||||
> "HP BIOS 有时非常固执，它只会寻找磁盘上默认的启动文件（/EFI/BOOT/BOOTX64.EFI）。如果它不保存你的自定义项，我们可以通过在 Ubuntu 内将 shimx64.efi 伪装成默认文件来'欺骗' BIOS。" — EFI 文件伪装修复原理
|
||||
|
||||
## Key Concepts
|
||||
- [[GPT分区表]]：现代 UEFI 设备的标准分区方案，支持 2TB+ 硬盘，与 UEFI 引导完美兼容；HP ZBook 等工作站必须使用 GPT 而非 MBR。
|
||||
- [[efibootmgr]]：Linux 系统下管理 NVRAM 启动项的工具，可查看（`efibootmgr`）、重写启动顺序（`-o 0005,0000,...`）、手动添加启动项（`-c -d /dev/nvme0n1 -p 1`）。
|
||||
- [[ISOHybrid镜像]]：同时支持 BIOS 和 UEFI 引导的混合 ISO 镜像；Rufus 提供 ISO 镜像模式（推荐）和 DD 模式（备选）两种写入方式。
|
||||
- [[UEFI启动修复]]：HP BIOS 固执行为导致启动项丢失的完整解决方案链路（efibootmgr 强制写入 → EFI 路径伪装 → UEFI Only 切换）。
|
||||
- [[NVMe硬盘分区]]：Ubuntu 24.04 自动识别并优化 NVMe 分区对齐；手动分区时保持默认扇区起始位置（2048）即可。
|
||||
- [[Socket Activation]]：Ubuntu 24.04 SSH 默认使用 ssh.socket 按需激活机制（相关链接页面）。
|
||||
|
||||
## Key Entities
|
||||
- [[HP ZBook]]：HP 工作站笔记本，F9 启动菜单，F10 进入 BIOS，固执的 BIOS NVRAM 行为；存储模式须设为 AHCI，Boot Mode 建议切换为 UEFI Only。
|
||||
- [[Rufus]]：开源 U 盘启动盘制作工具，ISOHybrid 镜像写入（推荐 ISO 镜像模式），自动下载 ldlinux.sys/ldlinux.bss 引导文件。
|
||||
- [[Ubuntu 24.04]]：LTS 桌面操作系统，默认 ssh.socket 按需激活，支持 NVMe 自动优化，ext4 为推荐文件系统。
|
||||
- [[Clonezilla]]：全盘镜像备份工具（相关链接页面），文中建议安装完成后用 Clonezilla 制作母版镜像。
|
||||
|
||||
## Connections
|
||||
- [[HP ZBook]] ← 安装目标 ← [[Rufus]]（启动盘制作工具）
|
||||
- [[efibootmgr]] ← 修复工具 ← [[UEFI启动修复]]（核心手段）
|
||||
- [[GPT分区表]] ← 分区方案 ← [[NVMe硬盘分区]]（自动对齐优化）
|
||||
- [[UEFI启动修复]] ← 终极方案 ← [[HP ZBook]] BIOS 固执行为
|
||||
- [[clonezilla对ubuntu-server进行全盘镜像备份]] ← 备份建议 ← [[Ubuntu 24.04]] 安装完成后（母版镜像）
|
||||
- [[ubuntu-24-04-enable-ssh]] ← 后置配置 ← [[Ubuntu 24.04]]（SSH 服务启用）
|
||||
- [[ubuntu禁用合盖休眠]] ← 后置配置 ← [[Ubuntu 24.04]]（合盖休眠设置）
|
||||
|
||||
## Contradictions
|
||||
- **无冲突**：本文档与其他来源一致，未检测到矛盾点。
|
||||
|
||||
## Related Sources
|
||||
- [[ubuntu-24-04-enable-ssh]] — Ubuntu 24.04 安装后的 SSH 配置
|
||||
- [[ubuntu禁用合盖休眠]] — Ubuntu 24.04 合盖休眠设置
|
||||
- [[ubuntu-server科学上网]] — Ubuntu Server 科学上网配置
|
||||
- [[ubuntu用rustdesk远程登录出现不能使用wayland登录的错误]] — Ubuntu RustDesk Wayland 登录问题
|
||||
- [[ubuntu服务器通过rsync实现日常增量备份]] — 安装完成后 rsync 数据恢复建议
|
||||
- [[clonezilla对ubuntu-server进行全盘镜像备份]] — 母版镜像制作工具，文中提及 Clonezilla
|
||||
|
||||
@@ -1,48 +1,48 @@
|
||||
---
|
||||
title: "安装v2rayN"
|
||||
type: source
|
||||
tags: [linux, v2rayn, windows]
|
||||
date: 2026-05-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/安装v2rayN.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：v2rayN 跨平台代理工具的各操作系统安装包说明与安装方法
|
||||
- 问题域：用户在不同操作系统（Windows、Linux、macOS）上安装 v2rayN 客户端的需求
|
||||
- 方法/机制：通过官方提供的便携版（zip）和安装版（deb/rpm/dmg）两种方式覆盖不同使用场景；内置 Xray、sing-box、mihomo 核心；支持 x64 和 ARM64 架构
|
||||
- 结论/价值：提供了清晰的跨平台安装指引，用户可根据系统和架构选择对应包
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- v2rayN 发布包内置部分 Core（Xray、sing-box、mihomo），其他 Core 需自行下载
|
||||
- zip 格式为便携版，解压即用，文件存储在程序文件夹，可复制多份互相独立
|
||||
- Windows 版需要 Windows 10+；x64 版提供 WPF 界面（需 .NET 8.0 Runtime）和 Avalonia UI 界面两种选择
|
||||
- Linux 版支持 Debian 12+、Ubuntu 22.04+、Fedora 36+、Redhat 9+；提供 zip 便携版和 deb/rpm 安装版
|
||||
- macOS 版支持 macOS 12+；dmg 安装包因无签名会提示"应用已损坏"，需执行 `xattr -cr` 修复
|
||||
- ARM64 架构在 Windows、Linux、macOS 上均有对应包
|
||||
|
||||
## Key Quotes
|
||||
> "zip格式包为便携版，解压缩到文件夹后直接可以运行，存储文件位置为本文件夹；可以复制多份互相独立" — 便携版特性说明
|
||||
> "v2rayN-windows-64-desktop.zip Avalonia UI 实现的界面" — WPF vs Avalonia 区别
|
||||
> "由于安装包没有签名，会提示应用已损坏；安装后需要运行：xattr -cr /Applications/v2rayN.app" — macOS dmg 安装后必须操作
|
||||
|
||||
## Key Concepts
|
||||
- [[代理客户端]]：运行代理协议的桌面/服务器端程序，接收本地流量并转发至远程服务器
|
||||
- [[代理核心 Core]]：代理客户端的内核引擎，负责实际的协议通信；v2rayN 支持 Xray、sing-box、mihomo 等多种核心
|
||||
- [[跨平台兼容]]：同一软件支持 Windows、Linux、macOS 多操作系统
|
||||
- [[ARM64 架构支持]]：支持 Apple Silicon、ARM 服务器等 ARM64 硬件平台
|
||||
|
||||
## Key Entities
|
||||
- [[v2rayN]]：2dust 开发的跨平台代理客户端，支持多种代理协议和多个代理核心
|
||||
- [[Xray]]：代理核心之一，内置于 v2rayN 发布包
|
||||
- [[sing-box]]：代理核心之一，内置于 v2rayN 发布包
|
||||
- [[mihomo]]：代理核心（Clash.Meta）之一，内置于 v2rayN 发布包
|
||||
- [[Microsoft .NET 8.0 Desktop Runtime]]：Windows WPF 版 v2rayN 的运行时依赖
|
||||
|
||||
## Connections
|
||||
- [[3X-UI Xray on BandwagonVPS]] ← relates_to ← [[安装v2rayn]]（均涉及 Xray/代理工具生态）
|
||||
- [[Ubuntu Server科学上网]] ← extends ← [[安装v2rayn]]（Linux 服务器端科学上网的客户端安装参考）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
---
|
||||
title: "安装v2rayN"
|
||||
type: source
|
||||
tags: [linux, v2rayn, windows]
|
||||
date: 2026-05-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/安装v2rayN.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：v2rayN 跨平台代理工具的各操作系统安装包说明与安装方法
|
||||
- 问题域：用户在不同操作系统（Windows、Linux、macOS）上安装 v2rayN 客户端的需求
|
||||
- 方法/机制：通过官方提供的便携版（zip）和安装版（deb/rpm/dmg）两种方式覆盖不同使用场景；内置 Xray、sing-box、mihomo 核心；支持 x64 和 ARM64 架构
|
||||
- 结论/价值：提供了清晰的跨平台安装指引，用户可根据系统和架构选择对应包
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- v2rayN 发布包内置部分 Core（Xray、sing-box、mihomo），其他 Core 需自行下载
|
||||
- zip 格式为便携版，解压即用，文件存储在程序文件夹，可复制多份互相独立
|
||||
- Windows 版需要 Windows 10+；x64 版提供 WPF 界面（需 .NET 8.0 Runtime）和 Avalonia UI 界面两种选择
|
||||
- Linux 版支持 Debian 12+、Ubuntu 22.04+、Fedora 36+、Redhat 9+；提供 zip 便携版和 deb/rpm 安装版
|
||||
- macOS 版支持 macOS 12+；dmg 安装包因无签名会提示"应用已损坏"，需执行 `xattr -cr` 修复
|
||||
- ARM64 架构在 Windows、Linux、macOS 上均有对应包
|
||||
|
||||
## Key Quotes
|
||||
> "zip格式包为便携版，解压缩到文件夹后直接可以运行，存储文件位置为本文件夹；可以复制多份互相独立" — 便携版特性说明
|
||||
> "v2rayN-windows-64-desktop.zip Avalonia UI 实现的界面" — WPF vs Avalonia 区别
|
||||
> "由于安装包没有签名，会提示应用已损坏；安装后需要运行：xattr -cr /Applications/v2rayN.app" — macOS dmg 安装后必须操作
|
||||
|
||||
## Key Concepts
|
||||
- [[代理客户端]]：运行代理协议的桌面/服务器端程序，接收本地流量并转发至远程服务器
|
||||
- [[代理核心 Core]]：代理客户端的内核引擎，负责实际的协议通信；v2rayN 支持 Xray、sing-box、mihomo 等多种核心
|
||||
- [[跨平台兼容]]：同一软件支持 Windows、Linux、macOS 多操作系统
|
||||
- [[ARM64 架构支持]]：支持 Apple Silicon、ARM 服务器等 ARM64 硬件平台
|
||||
|
||||
## Key Entities
|
||||
- [[v2rayN]]：2dust 开发的跨平台代理客户端，支持多种代理协议和多个代理核心
|
||||
- [[Xray]]：代理核心之一，内置于 v2rayN 发布包
|
||||
- [[sing-box]]：代理核心之一，内置于 v2rayN 发布包
|
||||
- [[mihomo]]：代理核心（Clash.Meta）之一，内置于 v2rayN 发布包
|
||||
- [[Microsoft .NET 8.0 Desktop Runtime]]：Windows WPF 版 v2rayN 的运行时依赖
|
||||
|
||||
## Connections
|
||||
- [[3X-UI Xray on BandwagonVPS]] ← relates_to ← [[安装v2rayn]]（均涉及 Xray/代理工具生态）
|
||||
- [[Ubuntu Server科学上网]] ← extends ← [[安装v2rayn]]（Linux 服务器端科学上网的客户端安装参考）
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
@@ -1,61 +1,61 @@
|
||||
---
|
||||
title: "家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor + Blackbox"
|
||||
type: source
|
||||
tags: [prometheus, grafana, monitoring, docker, home-server]
|
||||
date: 2025-11-11
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor +Blackbox]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：家庭/小型服务器监控的完整 Docker 化解决方案
|
||||
- 问题域：主机层、容器层、服务层的可观测性覆盖，以及告警通知渠道
|
||||
- 方法/机制：Prometheus 拉取模式采集 + Grafana 可视化 + Alertmanager 告警分发；通过 node_exporter、cAdvisor、blackbox_exporter 三个 exporter 覆盖主机、容器和网络探测；提供可直接拷贝的 docker-compose 完整模板
|
||||
- 结论/价值：面向 NAS / Ubuntu Server 用户的零门槛可落地监控栈，含具体 PromQL 告警规则和 Grafana Dashboard ID
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Prometheus + node_exporter + cAdvisor + blackbox_exporter + Grafana + Alertmanager 的组合可覆盖家庭服务器的完整监控面
|
||||
- 主机层监控 CPU / 内存 / 磁盘 / 网络 / I/O / inode，容器层监控运行状态、重启次数、资源使用，服务层监控 HTTP 可用性、响应码、延迟、TLS 证书到期、DNS 解析
|
||||
- TLS 证书剩余天数 < 14 天应触发告警
|
||||
- 黑箱探测 `probe_success == 0` 连续 3 次应触发告警
|
||||
- Docker socket 挂载存在宿主机 root 等效权限风险，需审慎处理
|
||||
- Grafana 官方 Dashboard ID：Node Exporter Full (`1860`)、cAdvisor Container Metrics (`14282`)、Blackbox Exporter Probe (`7587`)
|
||||
|
||||
## Key Quotes
|
||||
> "Docker socket 挂载存在宿主机 root 等效权限风险" — 容器安全注意事项
|
||||
> "Prometheus 本地磁盘会增长，考虑长期保留要用远端存储或定期 snapshot" — 存储注意事项
|
||||
> "Grafana 仪表盘 JSON 导出，Prometheus rule 与配置放在 Git（GitOps）" — 备份最佳实践
|
||||
> "把容器/服务启动时打上 service=xxx、env=prod 标签，便于 PromQL 分组和 SLA 报表" — 标签化运维建议
|
||||
|
||||
## Key Concepts
|
||||
- [[Prometheus]]：开源时序数据库 + 监控系统，采用拉取（pull）模式从 exporters 采集指标
|
||||
- [[Grafana]]：跨数据源的可视化与告警平台，支持 Prometheus/Loki/VictoriaMetrics 等
|
||||
- [[Observability]]（可观测性）：覆盖指标（Metrics）、日志（Logs）、链路（Traces）三大支柱
|
||||
- [[Container Monitoring]]（容器监控）：通过 cAdvisor 采集容器资源使用、重启次数、退出码等指标
|
||||
- [[Synthetic Monitoring]]（合成监控）：通过 blackbox_exporter 和 Uptime Kuma 做主动式可用性探测，区别于基于真实用户流量的 RUM
|
||||
- [[Alert Management]]（告警管理）：Prometheus 定义告警规则 → Alertmanager 接收 → 抑制/分组/路由到邮件/Slack/Webhook/PagerDuty
|
||||
- [[Home Server Automation]]：家庭服务器的运维自动化与监控覆盖
|
||||
|
||||
## Key Entities
|
||||
- [[Prometheus]]（监控数据采集与告警规则引擎）：负责从各 exporter 拉取指标并执行告警条件判断
|
||||
- [[Grafana]]（可视化与告警平台）：展示 Prometheus 时序数据，配置告警规则和通知渠道
|
||||
- [[Alertmanager]]（Prometheus 告警分发组件）：负责告警的抑制、分组、向邮件/Slack/Teams 等渠道分发
|
||||
- [[Node Exporter]]（主机指标采集器）：Prometheus 官方 exporter，采集 CPU/内存/磁盘/网络/文件系统指标
|
||||
- [[cAdvisor]]（Google 容器指标采集器）：采集容器级别的资源使用情况（CPU/内存/网络/磁盘 I/O）
|
||||
- [[Blackbox Exporter]]（黑箱探测 exporter）：通过 HTTP/TCP/ICMP/DNS 探测外部或内部服务端点
|
||||
- [[Uptime Kuma]]（自托管可用性监控工具）：开源 uptime monitoring，支持 HTTP/TCP/DNS/TLS 探测与历史记录
|
||||
- [[Netdata]]（实时监控看板）：开箱即用的详细实时主机/容器监控面板，默认 19999 端口
|
||||
- [[Portainer]]（Docker 可视化管理平台）：图形化管理 Docker 主机/Swarm，带监控/日志功能
|
||||
|
||||
## Connections
|
||||
- [[Prometheus]] ← scrape_configs ← [[Node Exporter]]
|
||||
- [[Prometheus]] ← scrape_configs ← [[cAdvisor]]
|
||||
- [[Prometheus]] ← scrape_configs ← [[Blackbox Exporter]]
|
||||
- [[Prometheus]] ← sends alerts ← [[Alertmanager]]
|
||||
- [[Grafana]] ← datasource ← [[Prometheus]]
|
||||
- [[Grafana]] ← dashboards ← [[Node Exporter]], [[cAdvisor]], [[Blackbox Exporter]]
|
||||
- [[家庭网络环境概览]] ← provides context for ← [[Home Server Automation]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Uptime Kuma]] 描述存在侧重差异：源文档将 Uptime Kuma 定位为"合成监控补充工具"与 blackbox_exporter 并列，实际部署中两者均可独立完成 HTTP/TLS 探测，Uptime Kuma 更适合做外网监控（无公网 IP 时），blackbox_exporter 更适合内网和更细粒度的 PromQL 告警集成
|
||||
---
|
||||
title: "家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor + Blackbox"
|
||||
type: source
|
||||
tags: [prometheus, grafana, monitoring, docker, home-server]
|
||||
date: 2025-11-11
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor +Blackbox]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：家庭/小型服务器监控的完整 Docker 化解决方案
|
||||
- 问题域：主机层、容器层、服务层的可观测性覆盖，以及告警通知渠道
|
||||
- 方法/机制：Prometheus 拉取模式采集 + Grafana 可视化 + Alertmanager 告警分发；通过 node_exporter、cAdvisor、blackbox_exporter 三个 exporter 覆盖主机、容器和网络探测；提供可直接拷贝的 docker-compose 完整模板
|
||||
- 结论/价值：面向 NAS / Ubuntu Server 用户的零门槛可落地监控栈，含具体 PromQL 告警规则和 Grafana Dashboard ID
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Prometheus + node_exporter + cAdvisor + blackbox_exporter + Grafana + Alertmanager 的组合可覆盖家庭服务器的完整监控面
|
||||
- 主机层监控 CPU / 内存 / 磁盘 / 网络 / I/O / inode，容器层监控运行状态、重启次数、资源使用，服务层监控 HTTP 可用性、响应码、延迟、TLS 证书到期、DNS 解析
|
||||
- TLS 证书剩余天数 < 14 天应触发告警
|
||||
- 黑箱探测 `probe_success == 0` 连续 3 次应触发告警
|
||||
- Docker socket 挂载存在宿主机 root 等效权限风险，需审慎处理
|
||||
- Grafana 官方 Dashboard ID：Node Exporter Full (`1860`)、cAdvisor Container Metrics (`14282`)、Blackbox Exporter Probe (`7587`)
|
||||
|
||||
## Key Quotes
|
||||
> "Docker socket 挂载存在宿主机 root 等效权限风险" — 容器安全注意事项
|
||||
> "Prometheus 本地磁盘会增长，考虑长期保留要用远端存储或定期 snapshot" — 存储注意事项
|
||||
> "Grafana 仪表盘 JSON 导出，Prometheus rule 与配置放在 Git（GitOps）" — 备份最佳实践
|
||||
> "把容器/服务启动时打上 service=xxx、env=prod 标签，便于 PromQL 分组和 SLA 报表" — 标签化运维建议
|
||||
|
||||
## Key Concepts
|
||||
- [[Prometheus]]：开源时序数据库 + 监控系统，采用拉取（pull）模式从 exporters 采集指标
|
||||
- [[Grafana]]：跨数据源的可视化与告警平台，支持 Prometheus/Loki/VictoriaMetrics 等
|
||||
- [[Observability]]（可观测性）：覆盖指标（Metrics）、日志（Logs）、链路（Traces）三大支柱
|
||||
- [[Container Monitoring]]（容器监控）：通过 cAdvisor 采集容器资源使用、重启次数、退出码等指标
|
||||
- [[Synthetic Monitoring]]（合成监控）：通过 blackbox_exporter 和 Uptime Kuma 做主动式可用性探测，区别于基于真实用户流量的 RUM
|
||||
- [[Alert Management]]（告警管理）：Prometheus 定义告警规则 → Alertmanager 接收 → 抑制/分组/路由到邮件/Slack/Webhook/PagerDuty
|
||||
- [[Home Server Automation]]：家庭服务器的运维自动化与监控覆盖
|
||||
|
||||
## Key Entities
|
||||
- [[Prometheus]]（监控数据采集与告警规则引擎）：负责从各 exporter 拉取指标并执行告警条件判断
|
||||
- [[Grafana]]（可视化与告警平台）：展示 Prometheus 时序数据，配置告警规则和通知渠道
|
||||
- [[Alertmanager]]（Prometheus 告警分发组件）：负责告警的抑制、分组、向邮件/Slack/Teams 等渠道分发
|
||||
- [[Node Exporter]]（主机指标采集器）：Prometheus 官方 exporter，采集 CPU/内存/磁盘/网络/文件系统指标
|
||||
- [[cAdvisor]]（Google 容器指标采集器）：采集容器级别的资源使用情况（CPU/内存/网络/磁盘 I/O）
|
||||
- [[Blackbox Exporter]]（黑箱探测 exporter）：通过 HTTP/TCP/ICMP/DNS 探测外部或内部服务端点
|
||||
- [[Uptime Kuma]]（自托管可用性监控工具）：开源 uptime monitoring，支持 HTTP/TCP/DNS/TLS 探测与历史记录
|
||||
- [[Netdata]]（实时监控看板）：开箱即用的详细实时主机/容器监控面板，默认 19999 端口
|
||||
- [[Portainer]]（Docker 可视化管理平台）：图形化管理 Docker 主机/Swarm，带监控/日志功能
|
||||
|
||||
## Connections
|
||||
- [[Prometheus]] ← scrape_configs ← [[Node Exporter]]
|
||||
- [[Prometheus]] ← scrape_configs ← [[cAdvisor]]
|
||||
- [[Prometheus]] ← scrape_configs ← [[Blackbox Exporter]]
|
||||
- [[Prometheus]] ← sends alerts ← [[Alertmanager]]
|
||||
- [[Grafana]] ← datasource ← [[Prometheus]]
|
||||
- [[Grafana]] ← dashboards ← [[Node Exporter]], [[cAdvisor]], [[Blackbox Exporter]]
|
||||
- [[家庭网络环境概览]] ← provides context for ← [[Home Server Automation]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Uptime Kuma]] 描述存在侧重差异：源文档将 Uptime Kuma 定位为"合成监控补充工具"与 blackbox_exporter 并列，实际部署中两者均可独立完成 HTTP/TLS 探测，Uptime Kuma 更适合做外网监控（无公网 IP 时），blackbox_exporter 更适合内网和更细粒度的 PromQL 告警集成
|
||||
|
||||
@@ -1,56 +1,56 @@
|
||||
---
|
||||
title: "家庭网络环境概览"
|
||||
type: source
|
||||
tags: [home-office, nas, synology, ubuntu, vps, home-lab]
|
||||
date: 2026-04-03
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/家庭网络环境概览_2026-04-03.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：个人家庭网络的完整基础设施架构文档，记录了从公网VPS到内网各服务器的完整拓扑、应用部署和域名映射
|
||||
- 问题域：家庭服务器集群的规划、部署与公网访问方案；多设备、多服务的管理与监控
|
||||
- 方法/机制：通过 FRP 内网穿透 + Caddy 反向代理实现公网访问；使用 Docker 容器化部署各类服务；Cloudflare DNS 托管
|
||||
- 结论/价值：构建了一套完整的自托管服务生态，覆盖开发、媒体、监控、自动化等多个场景
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- FRP（Fast Reverse Proxy）通过公网VPS中转，实现了内网设备的无公网IP公网访问
|
||||
- Caddy 作为前置反向代理，通过 *.ishenwei.online 子域名自动申请 HTTPS 证书
|
||||
- Synology NAS DS718 是家庭媒体中心，运行 Jellyfin、Navidrome、Calibre-web 等多媒体服务
|
||||
- Ubuntu1 运行 Grafana + Prometheus 监控栈，收集所有服务器的指标数据
|
||||
- Ubuntu2 承载 n8n 工作流自动化平台和 Gitea 自建 Git 服务
|
||||
- Mac Mini M4 作为主控节点，运行 OpenClaw AI 助手框架及 STQ 项目管理系统
|
||||
|
||||
## Key Quotes
|
||||
> "Caddy — 现代化 Web 服务器，自带 HTTPS 自动化证书申请，常作为前置反向代理处理业务流量" — 文档中定义
|
||||
> "FRP Server — 高性能内网穿透服务端（frps），负责将内网 NAS 或本地开发环境的服务暴露至公网访问" — 文档中定义
|
||||
> "域名 DNS 托管于 Cloudflare，提供免费 CDN 与 SSL 证书" — 基础设施说明
|
||||
|
||||
## Key Concepts
|
||||
- [[FRP 内网穿透]]：通过 Fast Reverse Proxy 在公网VPS和内网设备之间建立反向隧道，实现内网服务公网访问
|
||||
- [[Caddy 反向代理]]：现代化 Web 服务器，自动管理 HTTPS 证书，通过子域名路由内网服务
|
||||
- [[Docker 容器化]]：所有应用服务均以 Docker 方式部署，便于管理和迁移
|
||||
- [[Home Lab]]：个人自托管服务器集群，包含媒体、监控、开发、自动化等多种服务
|
||||
- [[Prometheus 监控]]：使用 Prometheus + Grafana + Node Exporter + cAdvisor 构建完整监控体系
|
||||
|
||||
## Key Entities
|
||||
- [[RackNerd VPS]]：公网服务器（IP: 192.227.222.142），运行 Caddy 和 FRP Server，是内网穿透的核心节点
|
||||
- [[Mac Mini M4]]：家庭主控节点（内网IP: 192.168.3.189），运行 OpenClaw AI助手、vaultwarden、STQ项目管理系统
|
||||
- [[Synology NAS DS718]]：家庭媒体中心（内网IP: 192.168.3.17），运行 Jellyfin、Navidrome、Calibre等多媒体服务
|
||||
- [[Ubuntu1]]：监控与开发服务器（内网IP: 192.168.3.47），运行 Grafana、Superset、Homarr导航面板
|
||||
- [[Ubuntu2]]：自动化与代码服务器（内网IP: 192.168.3.45），运行 n8n 工作流自动化、Gitea 自建Git服务
|
||||
- [[Cloudflare]]：提供免费DNS托管、CDN加速和SSL证书
|
||||
|
||||
## Connections
|
||||
- [[RackNerd VPS]] ← provides_public_ip ← [[Home Lab]]
|
||||
- [[Mac Mini M4]] ← hosts ← [[OpenClaw]]
|
||||
- [[Synology NAS DS718]] ← hosts ← [[Jellyfin]]
|
||||
- [[Synology NAS DS718]] ← hosts ← [[Navidrome]]
|
||||
- [[Ubuntu1]] ← hosts ← [[Grafana]]
|
||||
- [[Ubuntu2]] ← hosts ← [[n8n 工作流自动化]]
|
||||
- [[Home Lab]] ← uses ← [[FRP 内网穿透]]
|
||||
- [[Home Lab]] ← uses ← [[Caddy 反向代理]]
|
||||
|
||||
## Contradictions
|
||||
- 与其他文档暂无已知冲突
|
||||
---
|
||||
title: "家庭网络环境概览"
|
||||
type: source
|
||||
tags: [home-office, nas, synology, ubuntu, vps, home-lab]
|
||||
date: 2026-04-03
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/家庭网络环境概览_2026-04-03.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：个人家庭网络的完整基础设施架构文档，记录了从公网VPS到内网各服务器的完整拓扑、应用部署和域名映射
|
||||
- 问题域：家庭服务器集群的规划、部署与公网访问方案；多设备、多服务的管理与监控
|
||||
- 方法/机制：通过 FRP 内网穿透 + Caddy 反向代理实现公网访问；使用 Docker 容器化部署各类服务；Cloudflare DNS 托管
|
||||
- 结论/价值：构建了一套完整的自托管服务生态，覆盖开发、媒体、监控、自动化等多个场景
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- FRP（Fast Reverse Proxy）通过公网VPS中转，实现了内网设备的无公网IP公网访问
|
||||
- Caddy 作为前置反向代理，通过 *.ishenwei.online 子域名自动申请 HTTPS 证书
|
||||
- Synology NAS DS718 是家庭媒体中心，运行 Jellyfin、Navidrome、Calibre-web 等多媒体服务
|
||||
- Ubuntu1 运行 Grafana + Prometheus 监控栈，收集所有服务器的指标数据
|
||||
- Ubuntu2 承载 n8n 工作流自动化平台和 Gitea 自建 Git 服务
|
||||
- Mac Mini M4 作为主控节点，运行 OpenClaw AI 助手框架及 STQ 项目管理系统
|
||||
|
||||
## Key Quotes
|
||||
> "Caddy — 现代化 Web 服务器，自带 HTTPS 自动化证书申请，常作为前置反向代理处理业务流量" — 文档中定义
|
||||
> "FRP Server — 高性能内网穿透服务端（frps），负责将内网 NAS 或本地开发环境的服务暴露至公网访问" — 文档中定义
|
||||
> "域名 DNS 托管于 Cloudflare，提供免费 CDN 与 SSL 证书" — 基础设施说明
|
||||
|
||||
## Key Concepts
|
||||
- [[FRP 内网穿透]]：通过 Fast Reverse Proxy 在公网VPS和内网设备之间建立反向隧道，实现内网服务公网访问
|
||||
- [[Caddy 反向代理]]：现代化 Web 服务器，自动管理 HTTPS 证书，通过子域名路由内网服务
|
||||
- [[Docker 容器化]]：所有应用服务均以 Docker 方式部署，便于管理和迁移
|
||||
- [[Home Lab]]：个人自托管服务器集群，包含媒体、监控、开发、自动化等多种服务
|
||||
- [[Prometheus 监控]]：使用 Prometheus + Grafana + Node Exporter + cAdvisor 构建完整监控体系
|
||||
|
||||
## Key Entities
|
||||
- [[RackNerd VPS]]：公网服务器（IP: 192.227.222.142），运行 Caddy 和 FRP Server，是内网穿透的核心节点
|
||||
- [[Mac Mini M4]]：家庭主控节点（内网IP: 192.168.3.189），运行 OpenClaw AI助手、vaultwarden、STQ项目管理系统
|
||||
- [[Synology NAS DS718]]：家庭媒体中心（内网IP: 192.168.3.17），运行 Jellyfin、Navidrome、Calibre等多媒体服务
|
||||
- [[Ubuntu1]]：监控与开发服务器（内网IP: 192.168.3.47），运行 Grafana、Superset、Homarr导航面板
|
||||
- [[Ubuntu2]]：自动化与代码服务器（内网IP: 192.168.3.45），运行 n8n 工作流自动化、Gitea 自建Git服务
|
||||
- [[Cloudflare]]：提供免费DNS托管、CDN加速和SSL证书
|
||||
|
||||
## Connections
|
||||
- [[RackNerd VPS]] ← provides_public_ip ← [[Home Lab]]
|
||||
- [[Mac Mini M4]] ← hosts ← [[OpenClaw]]
|
||||
- [[Synology NAS DS718]] ← hosts ← [[Jellyfin]]
|
||||
- [[Synology NAS DS718]] ← hosts ← [[Navidrome]]
|
||||
- [[Ubuntu1]] ← hosts ← [[Grafana]]
|
||||
- [[Ubuntu2]] ← hosts ← [[n8n 工作流自动化]]
|
||||
- [[Home Lab]] ← uses ← [[FRP 内网穿透]]
|
||||
- [[Home Lab]] ← uses ← [[Caddy 反向代理]]
|
||||
|
||||
## Contradictions
|
||||
- 与其他文档暂无已知冲突
|
||||
|
||||
@@ -1,70 +1,70 @@
|
||||
---
|
||||
title: "开发经验与项目规范整理文档"
|
||||
type: source
|
||||
tags: [vibe-coding, software-engineering, best-practices, coding-standards, microservices, redis, message-queue]
|
||||
sources: []
|
||||
last_updated: 2025-12-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/开发经验与项目规范整理文档]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Vibe Coding 环境下的开发经验与项目规范最佳实践，涵盖编码规范、系统架构原则、程序设计思想及基础设施（微服务、Redis、消息队列）
|
||||
- 问题域：如何建立可持续维护的 AI 辅助开发项目；如何制定团队编码规范；如何通过规范提升 AI 生成的代码质量
|
||||
- 方法/机制：
|
||||
- 变量名维护方案（统一变量索引文件，格式：变量名 | 变量注释 | 出现位置 | 出现频率）
|
||||
- 文件结构与命名规范（子文件夹含 agents + claude.md；文件命名小写英文 + 下划线/小驼峰）
|
||||
- 编码规范（单一职责、DRY、模块化；消费端/生产端/状态/变换模型）
|
||||
- 并发编程规范（共享资源、数据竞争、锁机制、并发 vs 异步区分）
|
||||
- 系统架构原则（先梳理架构 → 理解需求 → 保持简单 → 自动化测试 → 小步迭代）
|
||||
- 程序设计核心思想（从问题出发、清晰命名、单一职责、可读性优先、合理注释、测试优先）
|
||||
- 微服务拆分原则（独立开发/部署/扩容，服务间通过 API 通信）
|
||||
- Redis 缓存策略（提升读性能、降低 DB 压力、提供计数/锁/队列/Session 能力）
|
||||
- 消息队列异步通信（解耦、削峰填谷、异步任务处理）
|
||||
- 结论/价值：为 AI 辅助开发项目提供系统化规范框架，强调从问题出发而非代码出发，提升代码可维护性和团队协作效率
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 统一变量索引文件能降低命名冲突和语义不清晰带来的风险，实现 AI 与团队全局命名一致性管理
|
||||
- 编码规范中的「消费端 → 生产端 → 状态 → 变换」模型能清晰划分系统行为边界，明确输入→处理→输出各环节
|
||||
- 系统开发应遵循「先理解需求 → 保持架构与代码简单 → 写可维护的自动化测试 → 小步迭代，不做大爆炸开发」的严谨流程
|
||||
- 编程第一步永远是「你要解决什么问题」，复杂问题拆解为可独立完成的小单元，减少复杂度、魔法代码、晦涩技巧
|
||||
- 注释解释「为什么」，而非「怎么做」；代码可读性优先，写的代码是给别人理解的，不是来炫技的
|
||||
- 未测试的代码迟早会出问题，调试是程序员核心技能，永远不要把代码只放本地
|
||||
- 微服务将系统拆解为多个独立开发、独立部署、独立扩容的服务，服务间通过 API 通信（HTTP、RPC、MQ 等）
|
||||
- Redis 通过缓存提升系统读性能、降低数据库压力，并提供计数、锁、队列、Session 等扩展能力
|
||||
- 消息队列实现服务间的异步通信，带来解耦、削峰填谷、异步任务处理等系统稳定性与吞吐收益
|
||||
|
||||
## Key Quotes
|
||||
> "编程的第一步永远是：你要解决什么问题？" — 从问题出发而非代码
|
||||
> "你写的代码是给别人理解的，不是来炫技的。" — 代码可读性优先
|
||||
> "注释解释'为什么'，不是'怎么做'。" — 合理注释原则
|
||||
> "未测试的代码迟早会出问题。" — 测试优先
|
||||
> "永远不要把代码只放本地。" — 调试是必修课
|
||||
|
||||
## Key Concepts
|
||||
- [[单一职责原则]]：每个文件、类、函数应只负责一件事，提炼公共逻辑，避免重复代码（DRY）
|
||||
- [[DRY原则]]：Don't Repeat Yourself，避免重复代码，提高复用价值
|
||||
- [[模块化编程]]：将系统分解为独立模块，提高复用价值，函数化、类化、模块化
|
||||
- [[输入-处理-输出模型]]：明确区分消费端（接收外部数据）、生产端（生成数据/输出结果）、状态（存储当前系统信息）、变换（处理状态/改变数据的逻辑）
|
||||
- [[并发编程]]：区分共享资源、数据竞争、必要时加锁或使用线程安全结构，区分"并发处理"和"异步处理"的差异
|
||||
- [[微服务架构]]：将系统拆解为独立开发、部署、扩容的服务，服务间通过 API 通信
|
||||
- [[Redis缓存]]：作为缓存提升系统读性能，降低数据库压力，提供计数/锁/队列/Session 能力
|
||||
- [[消息队列]]：用于服务之间的异步通信，实现解耦、削峰填谷、异步任务处理
|
||||
- [[系统架构梳理]]：模块划分、输入输出、数据流向、服务边界、技术栈、依赖关系在写代码前先明确
|
||||
|
||||
## Key Entities
|
||||
- 无特定商业实体提及，本文档为方法论文档，涵盖软件工程通用规范框架
|
||||
|
||||
## Connections
|
||||
- [[Vibe Coding]] ← 相关领域 ← 本文：提供 AI 辅助开发的项目规范框架
|
||||
- [[单一职责原则]] ← 编码规范核心 ← [[DRY原则]] ← 模块化基础
|
||||
- [[微服务架构]] ← 服务拆分原则 ← [[Redis缓存]] ← 性能优化手段
|
||||
- [[消息队列]] ← 异步通信基础设施 ← 微服务间通信机制
|
||||
- [[输入-处理-输出模型]] ← 系统行为划分 ← [[系统架构梳理]] ← 开发前置工作
|
||||
|
||||
## Contradictions
|
||||
- 与传统软件开发方法冲突：
|
||||
- 冲突点：传统强调"先理解代码再修改"，本文强调"从问题出发而非代码出发"
|
||||
- 当前观点：Vibe Coding 环境下，AI 生成代码量大，应先明确问题再让 AI 生成，而非逐步理解 AI 生成的代码
|
||||
- 对方观点：传统软件工程强调对代码的深度理解是维护和修改的前提
|
||||
---
|
||||
title: "开发经验与项目规范整理文档"
|
||||
type: source
|
||||
tags: [vibe-coding, software-engineering, best-practices, coding-standards, microservices, redis, message-queue]
|
||||
sources: []
|
||||
last_updated: 2025-12-30
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Vibe Coding/开发经验与项目规范整理文档]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Vibe Coding 环境下的开发经验与项目规范最佳实践，涵盖编码规范、系统架构原则、程序设计思想及基础设施（微服务、Redis、消息队列）
|
||||
- 问题域：如何建立可持续维护的 AI 辅助开发项目；如何制定团队编码规范；如何通过规范提升 AI 生成的代码质量
|
||||
- 方法/机制：
|
||||
- 变量名维护方案（统一变量索引文件，格式：变量名 | 变量注释 | 出现位置 | 出现频率）
|
||||
- 文件结构与命名规范（子文件夹含 agents + claude.md；文件命名小写英文 + 下划线/小驼峰）
|
||||
- 编码规范（单一职责、DRY、模块化；消费端/生产端/状态/变换模型）
|
||||
- 并发编程规范（共享资源、数据竞争、锁机制、并发 vs 异步区分）
|
||||
- 系统架构原则（先梳理架构 → 理解需求 → 保持简单 → 自动化测试 → 小步迭代）
|
||||
- 程序设计核心思想（从问题出发、清晰命名、单一职责、可读性优先、合理注释、测试优先）
|
||||
- 微服务拆分原则（独立开发/部署/扩容，服务间通过 API 通信）
|
||||
- Redis 缓存策略（提升读性能、降低 DB 压力、提供计数/锁/队列/Session 能力）
|
||||
- 消息队列异步通信（解耦、削峰填谷、异步任务处理）
|
||||
- 结论/价值：为 AI 辅助开发项目提供系统化规范框架，强调从问题出发而非代码出发，提升代码可维护性和团队协作效率
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 统一变量索引文件能降低命名冲突和语义不清晰带来的风险，实现 AI 与团队全局命名一致性管理
|
||||
- 编码规范中的「消费端 → 生产端 → 状态 → 变换」模型能清晰划分系统行为边界，明确输入→处理→输出各环节
|
||||
- 系统开发应遵循「先理解需求 → 保持架构与代码简单 → 写可维护的自动化测试 → 小步迭代，不做大爆炸开发」的严谨流程
|
||||
- 编程第一步永远是「你要解决什么问题」，复杂问题拆解为可独立完成的小单元，减少复杂度、魔法代码、晦涩技巧
|
||||
- 注释解释「为什么」，而非「怎么做」；代码可读性优先，写的代码是给别人理解的，不是来炫技的
|
||||
- 未测试的代码迟早会出问题，调试是程序员核心技能，永远不要把代码只放本地
|
||||
- 微服务将系统拆解为多个独立开发、独立部署、独立扩容的服务，服务间通过 API 通信（HTTP、RPC、MQ 等）
|
||||
- Redis 通过缓存提升系统读性能、降低数据库压力，并提供计数、锁、队列、Session 等扩展能力
|
||||
- 消息队列实现服务间的异步通信，带来解耦、削峰填谷、异步任务处理等系统稳定性与吞吐收益
|
||||
|
||||
## Key Quotes
|
||||
> "编程的第一步永远是：你要解决什么问题？" — 从问题出发而非代码
|
||||
> "你写的代码是给别人理解的，不是来炫技的。" — 代码可读性优先
|
||||
> "注释解释'为什么'，不是'怎么做'。" — 合理注释原则
|
||||
> "未测试的代码迟早会出问题。" — 测试优先
|
||||
> "永远不要把代码只放本地。" — 调试是必修课
|
||||
|
||||
## Key Concepts
|
||||
- [[单一职责原则]]：每个文件、类、函数应只负责一件事，提炼公共逻辑，避免重复代码（DRY）
|
||||
- [[DRY原则]]：Don't Repeat Yourself，避免重复代码，提高复用价值
|
||||
- [[模块化编程]]：将系统分解为独立模块，提高复用价值，函数化、类化、模块化
|
||||
- [[输入-处理-输出模型]]：明确区分消费端（接收外部数据）、生产端（生成数据/输出结果）、状态（存储当前系统信息）、变换（处理状态/改变数据的逻辑）
|
||||
- [[并发编程]]：区分共享资源、数据竞争、必要时加锁或使用线程安全结构，区分"并发处理"和"异步处理"的差异
|
||||
- [[微服务架构]]：将系统拆解为独立开发、部署、扩容的服务，服务间通过 API 通信
|
||||
- [[Redis缓存]]：作为缓存提升系统读性能，降低数据库压力，提供计数/锁/队列/Session 能力
|
||||
- [[消息队列]]：用于服务之间的异步通信，实现解耦、削峰填谷、异步任务处理
|
||||
- [[系统架构梳理]]：模块划分、输入输出、数据流向、服务边界、技术栈、依赖关系在写代码前先明确
|
||||
|
||||
## Key Entities
|
||||
- 无特定商业实体提及，本文档为方法论文档，涵盖软件工程通用规范框架
|
||||
|
||||
## Connections
|
||||
- [[Vibe Coding]] ← 相关领域 ← 本文：提供 AI 辅助开发的项目规范框架
|
||||
- [[单一职责原则]] ← 编码规范核心 ← [[DRY原则]] ← 模块化基础
|
||||
- [[微服务架构]] ← 服务拆分原则 ← [[Redis缓存]] ← 性能优化手段
|
||||
- [[消息队列]] ← 异步通信基础设施 ← 微服务间通信机制
|
||||
- [[输入-处理-输出模型]] ← 系统行为划分 ← [[系统架构梳理]] ← 开发前置工作
|
||||
|
||||
## Contradictions
|
||||
- 与传统软件开发方法冲突：
|
||||
- 冲突点：传统强调"先理解代码再修改"，本文强调"从问题出发而非代码出发"
|
||||
- 当前观点：Vibe Coding 环境下，AI 生成代码量大，应先明确问题再让 AI 生成，而非逐步理解 AI 生成的代码
|
||||
- 对方观点：传统软件工程强调对代码的深度理解是维护和修改的前提
|
||||
|
||||
@@ -1,47 +1,47 @@
|
||||
---
|
||||
title: "用Docker中安装Navidrome"
|
||||
type: source
|
||||
tags: [docker, music, navidrome]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/用Docker中安装Navidrome.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 Docker Compose 在群晖 NAS 上部署 Navidrome 开源音乐流媒体服务器
|
||||
- 问题域：家庭音乐库、个人媒体服务、NAS 多媒体服务
|
||||
- 方法/机制：使用 deluan/navidrome:latest 官方镜像，通过 Docker Compose YAML 配置服务；以只读方式挂载 /volume1/music 音乐目录，/volume1/docker/navidrome/data 存储应用数据；配置 ND_LOGLEVEL=info 详细日志、ND_ENABLETRANSCODINGCONFIG 启用转码配置界面、ND_AUTOTRANSCODEDOWNLOAD 自动根据客户端需求转码下载、ND_TRANSCODINGCACHESIZE=200MB 限制转码缓存大小
|
||||
- 结论/价值：构建家庭音乐流媒体服务，支持多客户端自适应转码播放，实现"音乐文件存储 → 流媒体播放"完整工作流
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Navidrome 官方镜像 deluan/navidrome:latest 提供开箱即用的音乐服务器功能
|
||||
- 群晖 NAS 使用 `user: "1026:100"` 固定 UID:GID，可避免容器内文件权限问题
|
||||
- 音乐目录 `/volume1/music:/music:ro` 以只读（:ro）方式挂载，确保原始音乐文件安全不被篡改
|
||||
- 转码缓存限制为 200MB，保护 NAS 磁盘空间
|
||||
- ND_AUTOTRANSCODEDOWNLOAD=true 使 Navidrome 能根据客户端能力自动转码并下载
|
||||
|
||||
## Key Quotes
|
||||
> "开启详细日志，便于排查流媒体传输问题" — 日志级别设置为 info 是排查 Docker 容器内 Navidrome 流媒体传输问题的基础
|
||||
> "限制转码缓存大小，保护磁盘空间" — ND_TRANSCODINGCACHESIZE=200MB 是 NAS 存储空间管理的重要配置
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker 媒体服务器]]：通过 Docker 容器部署的流媒体服务，Navidrome 和 Jellyfin 均属此类
|
||||
- [[音乐流媒体]]：通过网络协议（HTTP/WebDAV）向客户端传输音频内容的服务
|
||||
- [[音频转码]]：将音乐文件转换为客户端支持的格式（Navidrome 在服务端处理）
|
||||
- [[NAS 多媒体服务]]：在 NAS 设备上运行的多媒体服务器（视频/音乐/照片等）
|
||||
|
||||
## Key Entities
|
||||
- [[Navidrome]]：开源音乐流媒体服务器，支持 Subsonic API，本文部署的目标服务
|
||||
- [[deluan/navidrome]]：Navidrome 官方 Docker 镜像，由项目维护者 deluan 提供
|
||||
- [[群晖 NAS]]（Synology NAS）：NAS 设备类型，本文 Navidrome 的宿主机，提供 /volume1/docker 和 /volume1/music 存储路径
|
||||
|
||||
## Connections
|
||||
- [[Jellyfin]] ← 对标竞品 ← [[Navidrome]] — Jellyfin 服务视频，Navidrome 服务音乐，同属家庭媒体中心
|
||||
- [[用docker安装jellyfin]] ← 共用宿主机 ← [[用docker中安装Navidrome]] — 共享群晖 NAS Docker 环境和存储基础设施
|
||||
- [[群晖 NAS]] ← 宿主机 ← [[用docker中安装Navidrome]] — NAS 提供 Docker 环境和音乐文件存储
|
||||
- [[Transmission]] ← 下载端 ← [[Navidrome]]（播放端）— 下载端传输→整理音乐文件→Navidrome 播放
|
||||
- [[Docker卷]] ← 数据存储 ← [[Navidrome]] — /data 目录持久化配置和缓存
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
---
|
||||
title: "用Docker中安装Navidrome"
|
||||
type: source
|
||||
tags: [docker, music, navidrome]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/用Docker中安装Navidrome.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 Docker Compose 在群晖 NAS 上部署 Navidrome 开源音乐流媒体服务器
|
||||
- 问题域：家庭音乐库、个人媒体服务、NAS 多媒体服务
|
||||
- 方法/机制：使用 deluan/navidrome:latest 官方镜像，通过 Docker Compose YAML 配置服务；以只读方式挂载 /volume1/music 音乐目录，/volume1/docker/navidrome/data 存储应用数据；配置 ND_LOGLEVEL=info 详细日志、ND_ENABLETRANSCODINGCONFIG 启用转码配置界面、ND_AUTOTRANSCODEDOWNLOAD 自动根据客户端需求转码下载、ND_TRANSCODINGCACHESIZE=200MB 限制转码缓存大小
|
||||
- 结论/价值：构建家庭音乐流媒体服务，支持多客户端自适应转码播放，实现"音乐文件存储 → 流媒体播放"完整工作流
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Navidrome 官方镜像 deluan/navidrome:latest 提供开箱即用的音乐服务器功能
|
||||
- 群晖 NAS 使用 `user: "1026:100"` 固定 UID:GID，可避免容器内文件权限问题
|
||||
- 音乐目录 `/volume1/music:/music:ro` 以只读（:ro）方式挂载，确保原始音乐文件安全不被篡改
|
||||
- 转码缓存限制为 200MB，保护 NAS 磁盘空间
|
||||
- ND_AUTOTRANSCODEDOWNLOAD=true 使 Navidrome 能根据客户端能力自动转码并下载
|
||||
|
||||
## Key Quotes
|
||||
> "开启详细日志，便于排查流媒体传输问题" — 日志级别设置为 info 是排查 Docker 容器内 Navidrome 流媒体传输问题的基础
|
||||
> "限制转码缓存大小，保护磁盘空间" — ND_TRANSCODINGCACHESIZE=200MB 是 NAS 存储空间管理的重要配置
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker 媒体服务器]]：通过 Docker 容器部署的流媒体服务，Navidrome 和 Jellyfin 均属此类
|
||||
- [[音乐流媒体]]：通过网络协议（HTTP/WebDAV）向客户端传输音频内容的服务
|
||||
- [[音频转码]]：将音乐文件转换为客户端支持的格式（Navidrome 在服务端处理）
|
||||
- [[NAS 多媒体服务]]：在 NAS 设备上运行的多媒体服务器（视频/音乐/照片等）
|
||||
|
||||
## Key Entities
|
||||
- [[Navidrome]]：开源音乐流媒体服务器，支持 Subsonic API，本文部署的目标服务
|
||||
- [[deluan/navidrome]]：Navidrome 官方 Docker 镜像，由项目维护者 deluan 提供
|
||||
- [[群晖 NAS]]（Synology NAS）：NAS 设备类型，本文 Navidrome 的宿主机，提供 /volume1/docker 和 /volume1/music 存储路径
|
||||
|
||||
## Connections
|
||||
- [[Jellyfin]] ← 对标竞品 ← [[Navidrome]] — Jellyfin 服务视频，Navidrome 服务音乐，同属家庭媒体中心
|
||||
- [[用docker安装jellyfin]] ← 共用宿主机 ← [[用docker中安装Navidrome]] — 共享群晖 NAS Docker 环境和存储基础设施
|
||||
- [[群晖 NAS]] ← 宿主机 ← [[用docker中安装Navidrome]] — NAS 提供 Docker 环境和音乐文件存储
|
||||
- [[Transmission]] ← 下载端 ← [[Navidrome]]（播放端）— 下载端传输→整理音乐文件→Navidrome 播放
|
||||
- [[Docker卷]] ← 数据存储 ← [[Navidrome]] — /data 目录持久化配置和缓存
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
@@ -1,86 +1,86 @@
|
||||
---
|
||||
title: "用Docker安装Apache Superset"
|
||||
type: source
|
||||
tags: [apache, bi, docker, mysql, superset]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/用Docker安装Apache Superset.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- **核心主题**：通过 Docker 容器快速部署 Apache Superset BI 平台
|
||||
- **问题域**：数据可视化与 BI 工具的本地化安装
|
||||
- **方法/机制**：使用 Docker Hub 官方镜像 `apache/superset`，通过 docker exec 进入容器执行初始化命令
|
||||
- **结论/价值**：提供一套标准化、可复现的 Superset 部署流程，适合开发测试环境快速搭建
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Docker 容器化部署可将 Superset 安装时间压缩至分钟级别
|
||||
- 通过 `superset fab create-admin` 命令创建管理员账户是初始化第一步
|
||||
- `superset db upgrade` 确保数据库 Schema 与当前版本同步
|
||||
- `superset load_examples` 加载示例数据集，便于新用户快速上手
|
||||
- `superset init` 完成权限和缓存的初始化
|
||||
|
||||
## Key Quotes
|
||||
> `docker pull apache/superset:GHA-19524015706` — 拉取 GitHub Actions 构建版本的 Apache Superset 官方镜像
|
||||
>
|
||||
> `docker run -d -p 8777:8088 -e "SUPERSET_SECRET_KEY=*** --name superset apache/superset:GHA-19524015706` — 容器启动命令，将宿主机的 8777 端口映射到容器的 8088 端口（Superset 默认 Web UI 端口），设置 SECRET_KEY 环境变量
|
||||
>
|
||||
> `docker exec -it superset superset fab create-admin --username admin --firstname Superset --lastname Admin --email admin@superset.com --password admin` — 管理员账户创建命令，用于首次登录系统
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker]]：容器化平台，Superset 的部署底座
|
||||
- [[Docker-Image]]：`apache/superset` 官方镜像
|
||||
- [[容器初始化]]：docker exec 进入运行中的容器执行初始化命令的流程
|
||||
- [[BI平台]]：Business Intelligence 平台，Superset 属于开源 BI 工具
|
||||
- [[数据可视化]]：将数据库数据转化为图表/仪表盘的技术
|
||||
|
||||
## Key Entities
|
||||
- [[Apache Superset]]：开源 BI 和数据探索平台，由 Apache 软件基金会维护，支持 SQL 查询、可视化仪表盘和数据源连接
|
||||
- [[MySQL]]：关系型数据库，在 Superset 中作为可选元数据存储（默认使用 SQLite）
|
||||
- [[Docker Hub]]：官方镜像仓库，`apache/superset` 的托管位置
|
||||
|
||||
## Connections
|
||||
- [[Docker]] ← uses ← [[Apache Superset]]
|
||||
- [[MySQL]] ← stores ← [[Apache Superset 元数据]]
|
||||
- [[Docker]] ← extends ← [[Docker Compose]]（生产环境推荐多容器协同）
|
||||
- [[Apache Superset]] ← depends_on ← [[Flask]]（Web 框架）
|
||||
- [[Apache Superset]] ← depends_on ← [[SQLAlchemy]]（数据库 ORM）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[install-apache-superset-in-docker]] 无冲突：
|
||||
- 两篇文档内容高度一致，均使用 `docker run` 单容器模式 + GHA 构建版本镜像，适合快速尝鲜
|
||||
- 与 [[用docker安装portainer]] 同属 Home Office Docker 部署系列，可作为参考对照
|
||||
|
||||
## 安装步骤速查
|
||||
|
||||
```bash
|
||||
# 1. 拉取镜像
|
||||
docker pull apache/superset:GHA-19524015706
|
||||
|
||||
# 2. 运行容器
|
||||
docker run -d -p 8777:8088 \
|
||||
-e "SUPERSET_SECRET_KEY=***" \
|
||||
--name superset \
|
||||
apache/superset:GHA-19524015706
|
||||
|
||||
# 3. 创建管理员账户
|
||||
docker exec -it superset superset fab create-admin \
|
||||
--username admin \
|
||||
--firstname Superset \
|
||||
--lastname Admin \
|
||||
--email admin@superset.com \
|
||||
--password admin
|
||||
|
||||
# 4. 数据库迁移
|
||||
docker exec -it superset superset db upgrade
|
||||
|
||||
# 5. 加载示例数据
|
||||
docker exec -it superset superset load_examples
|
||||
|
||||
# 6. 初始化
|
||||
docker exec -it superset superset init
|
||||
```
|
||||
|
||||
访问地址：`http://localhost:8777`
|
||||
默认凭据：`admin / admin`
|
||||
---
|
||||
title: "用Docker安装Apache Superset"
|
||||
type: source
|
||||
tags: [apache, bi, docker, mysql, superset]
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/用Docker安装Apache Superset.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- **核心主题**：通过 Docker 容器快速部署 Apache Superset BI 平台
|
||||
- **问题域**：数据可视化与 BI 工具的本地化安装
|
||||
- **方法/机制**：使用 Docker Hub 官方镜像 `apache/superset`，通过 docker exec 进入容器执行初始化命令
|
||||
- **结论/价值**：提供一套标准化、可复现的 Superset 部署流程，适合开发测试环境快速搭建
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Docker 容器化部署可将 Superset 安装时间压缩至分钟级别
|
||||
- 通过 `superset fab create-admin` 命令创建管理员账户是初始化第一步
|
||||
- `superset db upgrade` 确保数据库 Schema 与当前版本同步
|
||||
- `superset load_examples` 加载示例数据集，便于新用户快速上手
|
||||
- `superset init` 完成权限和缓存的初始化
|
||||
|
||||
## Key Quotes
|
||||
> `docker pull apache/superset:GHA-19524015706` — 拉取 GitHub Actions 构建版本的 Apache Superset 官方镜像
|
||||
>
|
||||
> `docker run -d -p 8777:8088 -e "SUPERSET_SECRET_KEY=*** --name superset apache/superset:GHA-19524015706` — 容器启动命令，将宿主机的 8777 端口映射到容器的 8088 端口（Superset 默认 Web UI 端口），设置 SECRET_KEY 环境变量
|
||||
>
|
||||
> `docker exec -it superset superset fab create-admin --username admin --firstname Superset --lastname Admin --email admin@superset.com --password admin` — 管理员账户创建命令，用于首次登录系统
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker]]：容器化平台，Superset 的部署底座
|
||||
- [[Docker-Image]]：`apache/superset` 官方镜像
|
||||
- [[容器初始化]]：docker exec 进入运行中的容器执行初始化命令的流程
|
||||
- [[BI平台]]：Business Intelligence 平台，Superset 属于开源 BI 工具
|
||||
- [[数据可视化]]：将数据库数据转化为图表/仪表盘的技术
|
||||
|
||||
## Key Entities
|
||||
- [[Apache Superset]]：开源 BI 和数据探索平台，由 Apache 软件基金会维护，支持 SQL 查询、可视化仪表盘和数据源连接
|
||||
- [[MySQL]]：关系型数据库，在 Superset 中作为可选元数据存储（默认使用 SQLite）
|
||||
- [[Docker Hub]]：官方镜像仓库，`apache/superset` 的托管位置
|
||||
|
||||
## Connections
|
||||
- [[Docker]] ← uses ← [[Apache Superset]]
|
||||
- [[MySQL]] ← stores ← [[Apache Superset 元数据]]
|
||||
- [[Docker]] ← extends ← [[Docker Compose]]（生产环境推荐多容器协同）
|
||||
- [[Apache Superset]] ← depends_on ← [[Flask]]（Web 框架）
|
||||
- [[Apache Superset]] ← depends_on ← [[SQLAlchemy]]（数据库 ORM）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[install-apache-superset-in-docker]] 无冲突：
|
||||
- 两篇文档内容高度一致，均使用 `docker run` 单容器模式 + GHA 构建版本镜像，适合快速尝鲜
|
||||
- 与 [[用docker安装portainer]] 同属 Home Office Docker 部署系列，可作为参考对照
|
||||
|
||||
## 安装步骤速查
|
||||
|
||||
```bash
|
||||
# 1. 拉取镜像
|
||||
docker pull apache/superset:GHA-19524015706
|
||||
|
||||
# 2. 运行容器
|
||||
docker run -d -p 8777:8088 \
|
||||
-e "SUPERSET_SECRET_KEY=***" \
|
||||
--name superset \
|
||||
apache/superset:GHA-19524015706
|
||||
|
||||
# 3. 创建管理员账户
|
||||
docker exec -it superset superset fab create-admin \
|
||||
--username admin \
|
||||
--firstname Superset \
|
||||
--lastname Admin \
|
||||
--email admin@superset.com \
|
||||
--password admin
|
||||
|
||||
# 4. 数据库迁移
|
||||
docker exec -it superset superset db upgrade
|
||||
|
||||
# 5. 加载示例数据
|
||||
docker exec -it superset superset load_examples
|
||||
|
||||
# 6. 初始化
|
||||
docker exec -it superset superset init
|
||||
```
|
||||
|
||||
访问地址：`http://localhost:8777`
|
||||
默认凭据：`admin / admin`
|
||||
|
||||
@@ -1,42 +1,42 @@
|
||||
---
|
||||
title: "用Docker安装it-tools"
|
||||
type: source
|
||||
tags: [docker, it-tools]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/用Docker安装it-tools.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 Docker Compose 在 Home Server 环境中部署 it-tools 网络工具集
|
||||
- 问题域：Home Server 自托管服务的容器化安装与配置
|
||||
- 方法/机制：使用 Docker Compose YAML 配置，启动 `corentinth/it-tools:latest` 官方镜像，设置交互模式（stdin_open + tty）、端口映射（8999→80）及内存限制（128M）
|
||||
- 结论/价值：提供一键部署 IT 工具集的完整方案，适用于内网环境快速访问常用开发运维工具
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- CorentinTh/it-tools 镜像可作为 Home Server 常驻服务运行
|
||||
- Docker Compose 的 `stdin_open: true` 和 `tty: true` 配置对于交互式容器至关重要
|
||||
- 128M 内存限制对 it-tools 足够（该应用为纯前端工具）
|
||||
|
||||
## Key Quotes
|
||||
> "version: '3.8'" — Docker Compose 文件版本声明
|
||||
> "image: corentinth/it-tools:latest" — 使用的官方 it-tools 镜像
|
||||
> "restart: unless-stopped" — 容器自动重启策略
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker Compose]]：多容器 Docker 应用的声明式配置文件格式，本文档使用 version 3.8 版本
|
||||
- [[Containerization]]：容器化技术，将应用及其依赖打包为可移植的镜像，在隔离环境中运行
|
||||
- [[Home Server]]：家庭自托管服务器环境，用于部署私有化服务
|
||||
|
||||
## Key Entities
|
||||
- [[CorentinTh/it-tools]]：由 Corentin Thierart 开发的开源 IT 工具集合 Web 应用，提供 100+ 常用开发运维工具
|
||||
- [[Corentin Thierart]]：it-tools 项目的作者和维护者
|
||||
|
||||
## Connections
|
||||
- [[如何在Ubuntu Server安装 Docker & Docker Compose]] ← part_of ← it-tools 部署前提
|
||||
- [[用Docker安装Portainer]] ← similar ← [[用Docker安装it-tools]]（同为 Home Server Docker 服务）
|
||||
- [[用Docker安装Homarr]] ← similar ← [[用Docker安装it-tools]]（同为 Home Server 仪表盘/工具类 Docker 服务）
|
||||
|
||||
## Contradictions
|
||||
- （无已知冲突内容）
|
||||
---
|
||||
title: "用Docker安装it-tools"
|
||||
type: source
|
||||
tags: [docker, it-tools]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/用Docker安装it-tools.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 Docker Compose 在 Home Server 环境中部署 it-tools 网络工具集
|
||||
- 问题域：Home Server 自托管服务的容器化安装与配置
|
||||
- 方法/机制：使用 Docker Compose YAML 配置，启动 `corentinth/it-tools:latest` 官方镜像，设置交互模式（stdin_open + tty）、端口映射（8999→80）及内存限制（128M）
|
||||
- 结论/价值：提供一键部署 IT 工具集的完整方案，适用于内网环境快速访问常用开发运维工具
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- CorentinTh/it-tools 镜像可作为 Home Server 常驻服务运行
|
||||
- Docker Compose 的 `stdin_open: true` 和 `tty: true` 配置对于交互式容器至关重要
|
||||
- 128M 内存限制对 it-tools 足够（该应用为纯前端工具）
|
||||
|
||||
## Key Quotes
|
||||
> "version: '3.8'" — Docker Compose 文件版本声明
|
||||
> "image: corentinth/it-tools:latest" — 使用的官方 it-tools 镜像
|
||||
> "restart: unless-stopped" — 容器自动重启策略
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker Compose]]：多容器 Docker 应用的声明式配置文件格式，本文档使用 version 3.8 版本
|
||||
- [[Containerization]]：容器化技术，将应用及其依赖打包为可移植的镜像，在隔离环境中运行
|
||||
- [[Home Server]]：家庭自托管服务器环境，用于部署私有化服务
|
||||
|
||||
## Key Entities
|
||||
- [[CorentinTh/it-tools]]：由 Corentin Thierart 开发的开源 IT 工具集合 Web 应用，提供 100+ 常用开发运维工具
|
||||
- [[Corentin Thierart]]：it-tools 项目的作者和维护者
|
||||
|
||||
## Connections
|
||||
- [[如何在Ubuntu Server安装 Docker & Docker Compose]] ← part_of ← it-tools 部署前提
|
||||
- [[用Docker安装Portainer]] ← similar ← [[用Docker安装it-tools]]（同为 Home Server Docker 服务）
|
||||
- [[用Docker安装Homarr]] ← similar ← [[用Docker安装it-tools]]（同为 Home Server 仪表盘/工具类 Docker 服务）
|
||||
|
||||
## Contradictions
|
||||
- （无已知冲突内容）
|
||||
|
||||
@@ -1,34 +1,34 @@
|
||||
---
|
||||
title: "用Docker安装Portainer"
|
||||
type: source
|
||||
tags: [docker, portainer]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/用Docker安装Portainer]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 Docker Compose 方式安装 Portainer 容器管理面板
|
||||
- 问题域：家庭服务器或NAS环境下的Docker容器可视化管理工作
|
||||
- 方法/机制：使用 docker-compose.yml 配置文件定义 Portainer 服务，通过 `docker-compose run -d` 启动容器
|
||||
- 结论/价值：提供图形化界面管理Docker容器、卷、网络等资源，降低命令行操作复杂度
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Portainer 通过挂载 Docker Socket（`/var/run/docker.sock`）实现对本地Docker守护进程的管理
|
||||
- 使用 LTS 版本镜像（`portainer/portainer-ce:lts`）确保稳定性和长期支持
|
||||
- 容器配置为 `restart: always`，确保服务在系统重启后自动恢复
|
||||
- 默认暴露 9443（HTTPS管理界面）和 8000（Edge Agent通信）端口
|
||||
|
||||
## Key Quotes
|
||||
> "ports: - 9443:9443 - 8000:8000" — Portainer Web界面通过9443端口访问，8000端口用于Edge Agent通信（不使用Edge Agent时可移除）
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker Compose]]：定义和运行多容器Docker应用的工具，通过YAML配置文件管理服务
|
||||
- [[Portainer]]：开源的Docker和Kubernetes图形化管理界面，支持容器、镜像、卷、网络等资源管理
|
||||
|
||||
## Key Entities
|
||||
- [[Portainer]]：开源容器管理平台，本文档的核心安装目标
|
||||
|
||||
## Connections
|
||||
- [[如何删除旧的废弃的Docker Container + Volume]] ← related_to ← [[用Docker安装Portainer]]
|
||||
---
|
||||
title: "用Docker安装Portainer"
|
||||
type: source
|
||||
tags: [docker, portainer]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/用Docker安装Portainer]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 Docker Compose 方式安装 Portainer 容器管理面板
|
||||
- 问题域：家庭服务器或NAS环境下的Docker容器可视化管理工作
|
||||
- 方法/机制：使用 docker-compose.yml 配置文件定义 Portainer 服务，通过 `docker-compose run -d` 启动容器
|
||||
- 结论/价值：提供图形化界面管理Docker容器、卷、网络等资源，降低命令行操作复杂度
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Portainer 通过挂载 Docker Socket（`/var/run/docker.sock`）实现对本地Docker守护进程的管理
|
||||
- 使用 LTS 版本镜像（`portainer/portainer-ce:lts`）确保稳定性和长期支持
|
||||
- 容器配置为 `restart: always`，确保服务在系统重启后自动恢复
|
||||
- 默认暴露 9443（HTTPS管理界面）和 8000（Edge Agent通信）端口
|
||||
|
||||
## Key Quotes
|
||||
> "ports: - 9443:9443 - 8000:8000" — Portainer Web界面通过9443端口访问，8000端口用于Edge Agent通信（不使用Edge Agent时可移除）
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker Compose]]：定义和运行多容器Docker应用的工具，通过YAML配置文件管理服务
|
||||
- [[Portainer]]：开源的Docker和Kubernetes图形化管理界面，支持容器、镜像、卷、网络等资源管理
|
||||
|
||||
## Key Entities
|
||||
- [[Portainer]]：开源容器管理平台，本文档的核心安装目标
|
||||
|
||||
## Connections
|
||||
- [[如何删除旧的废弃的Docker Container + Volume]] ← related_to ← [[用Docker安装Portainer]]
|
||||
|
||||
@@ -1,47 +1,47 @@
|
||||
---
|
||||
title: "用Docker安装transmission"
|
||||
type: source
|
||||
tags: [docker, transmission, home-office]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/用Docker安装transmission.md]]
|
||||
|
||||
## Summary (用中文描述)
|
||||
- 核心主题：通过 Docker Compose 在 Home Server 部署 Transmission BT 下载服务
|
||||
- 问题域：BT 下载服务容器化部署、Web UI 访问、下载目录管理
|
||||
- 方法/机制：使用 linuxserver/transmission 官方镜像，通过 Docker Compose 定义端口映射、环境变量（PUID/PGID/TZ/认证）、卷挂载（配置目录+下载目录）实现一键部署
|
||||
- 结论/价值：Transmission 是家庭媒体中心的核心组件，与 Jellyfin/Navidrome 共同构成"下载→整理→播放"媒体工作流
|
||||
|
||||
## Key Claims (用中文描述)
|
||||
- LinuxServer.io 维护的 Transmission 镜像通过 docker-compose 一键部署
|
||||
- 端口 9091 映射 Web UI 访问，端口 51413/UDP 映射 BT Peer 通信
|
||||
- PUID/PGID 环境变量实现容器内进程以宿主机用户权限运行，避免文件权限问题
|
||||
- TZ=Etc/UTC 配置容器时区，可根据需要调整为 Asia/Shanghai
|
||||
- USER/PASS 环境变量启用 Web UI 认证，保护服务安全
|
||||
|
||||
## Key Quotes
|
||||
> "image: lscr.io/linuxserver/transmission:latest" — LinuxServer.io 官方维护镜像
|
||||
> "network_mode: bridge" — 采用桥接网络模式，与宿主机网络隔离但可访问
|
||||
> "restart: unless-stopped" — 容器异常退出后自动重启策略
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker Compose]]：YAML 格式定义多容器应用的配置规范，本文档使用 version: '3.8'
|
||||
- [[Docker Volume]]：持久化存储机制，/config 目录存储配置和下载状态，/downloads 目录挂载宿主下载目录
|
||||
- [[PUID/PGID]]：Docker 容器进程以宿主机指定用户运行的环境变量，解决文件权限问题
|
||||
- [[端口映射]]：-p host:container 格式将容器端口暴露到宿主机网络
|
||||
- [[桥接网络]]：bridge 网络模式下容器共享宿主机网络栈，实现端口映射访问
|
||||
|
||||
## Key Entities
|
||||
- [[LinuxServer.io]]：开源 Docker 镜像维护组织，transmission 镜像官方来源
|
||||
- [[Transmission]]：开源 BT 下载客户端，Home Server 媒体中心核心组件
|
||||
- [[Docker]]：容器化部署平台，本文档使用 docker-compose 管理服务生命周期
|
||||
|
||||
## Connections
|
||||
- [[Transmission]] ← deployed_via ← [[Docker Compose]]
|
||||
- [[Docker]] ← network_mode ← [[桥接网络]]
|
||||
- [[Transmission]] ← upstream_image ← [[LinuxServer.io]]
|
||||
|
||||
## Contradictions
|
||||
- 无冲突；与 [[用Docker安装jellyfin]] 形成互补（jellyfin=播放，transmission=下载，共同服务于家庭媒体中心工作流）
|
||||
---
|
||||
title: "用Docker安装transmission"
|
||||
type: source
|
||||
tags: [docker, transmission, home-office]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/用Docker安装transmission.md]]
|
||||
|
||||
## Summary (用中文描述)
|
||||
- 核心主题：通过 Docker Compose 在 Home Server 部署 Transmission BT 下载服务
|
||||
- 问题域：BT 下载服务容器化部署、Web UI 访问、下载目录管理
|
||||
- 方法/机制：使用 linuxserver/transmission 官方镜像，通过 Docker Compose 定义端口映射、环境变量（PUID/PGID/TZ/认证）、卷挂载（配置目录+下载目录）实现一键部署
|
||||
- 结论/价值：Transmission 是家庭媒体中心的核心组件，与 Jellyfin/Navidrome 共同构成"下载→整理→播放"媒体工作流
|
||||
|
||||
## Key Claims (用中文描述)
|
||||
- LinuxServer.io 维护的 Transmission 镜像通过 docker-compose 一键部署
|
||||
- 端口 9091 映射 Web UI 访问，端口 51413/UDP 映射 BT Peer 通信
|
||||
- PUID/PGID 环境变量实现容器内进程以宿主机用户权限运行，避免文件权限问题
|
||||
- TZ=Etc/UTC 配置容器时区，可根据需要调整为 Asia/Shanghai
|
||||
- USER/PASS 环境变量启用 Web UI 认证，保护服务安全
|
||||
|
||||
## Key Quotes
|
||||
> "image: lscr.io/linuxserver/transmission:latest" — LinuxServer.io 官方维护镜像
|
||||
> "network_mode: bridge" — 采用桥接网络模式，与宿主机网络隔离但可访问
|
||||
> "restart: unless-stopped" — 容器异常退出后自动重启策略
|
||||
|
||||
## Key Concepts
|
||||
- [[Docker Compose]]：YAML 格式定义多容器应用的配置规范，本文档使用 version: '3.8'
|
||||
- [[Docker Volume]]：持久化存储机制，/config 目录存储配置和下载状态，/downloads 目录挂载宿主下载目录
|
||||
- [[PUID/PGID]]：Docker 容器进程以宿主机指定用户运行的环境变量，解决文件权限问题
|
||||
- [[端口映射]]：-p host:container 格式将容器端口暴露到宿主机网络
|
||||
- [[桥接网络]]：bridge 网络模式下容器共享宿主机网络栈，实现端口映射访问
|
||||
|
||||
## Key Entities
|
||||
- [[LinuxServer.io]]：开源 Docker 镜像维护组织，transmission 镜像官方来源
|
||||
- [[Transmission]]：开源 BT 下载客户端，Home Server 媒体中心核心组件
|
||||
- [[Docker]]：容器化部署平台，本文档使用 docker-compose 管理服务生命周期
|
||||
|
||||
## Connections
|
||||
- [[Transmission]] ← deployed_via ← [[Docker Compose]]
|
||||
- [[Docker]] ← network_mode ← [[桥接网络]]
|
||||
- [[Transmission]] ← upstream_image ← [[LinuxServer.io]]
|
||||
|
||||
## Contradictions
|
||||
- 无冲突；与 [[用Docker安装jellyfin]] 形成互补（jellyfin=播放，transmission=下载，共同服务于家庭媒体中心工作流）
|
||||
|
||||
@@ -1,53 +1,53 @@
|
||||
---
|
||||
title: "网件RAX50路由器刷梅林固件与科学上网插件安装教程"
|
||||
type: source
|
||||
tags: [clash, merlin-clash, rax50, 科学上网, 梅林固件]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/网件RAX50路由器刷梅林固件与科学上网插件安装教程]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- **核心主题**：网件RAX50路由器刷入梅林固件并安装科学上网插件的完整操作指南
|
||||
- **问题域**：路由器固件刷入、科学上网插件配置、网络分流与故障转移
|
||||
- **方法/机制**：
|
||||
- 二次刷机流程（.chk 过渡固件 → .w 梅林固件）
|
||||
- JFFS双清操作清理旧缓存
|
||||
- 软件中心安装 MerlinClash 科学上网插件
|
||||
- 策略组配置实现节点分流与故障转移
|
||||
- 定时自动更新订阅、守护进程保证插件稳定运行
|
||||
- **结论/价值**：提供网件路由器科学上网的完整闭环方案，包含硬件刷机、软件配置与日常维护
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 网件RAX50路由器必须先刷 .chk 过渡固件，再刷 .w 梅林固件，直接刷 .w 会失败
|
||||
- JFFS双清可清理文件系统缓存，防止刷机后残留问题
|
||||
- MerlinClash 插件支持策略组自动分流和节点故障转移，比同类插件功能更全面
|
||||
- MerlinClash 与科学上网插件不可同时运行，只能选其一
|
||||
- 恢复出厂设置不会恢复网件原厂固件，仅重置梅林固件配置
|
||||
|
||||
## Key Quotes
|
||||
> "必须先刷 `.chk` 的过渡固件，再刷 `.w` 的正式梅林固件，二次刷机才能确保稳定" — 刷机顺序说明
|
||||
> "两个插件不能同时运行，选择一个即可，优选支持策略组分流的 MerlinClash" — 插件选择建议
|
||||
> "通过策略组配置不同节点和规则，实现基于应用、地区和服务的自动分流和节点故障转移" — MerlinClash 核心优势
|
||||
|
||||
## Key Concepts
|
||||
- [[梅林固件]]：华硕路由器第三方固件改良版，支持插件和科学上网
|
||||
- [[过渡固件]]：.chk 格式，用于网件路由器从原厂固件过渡到梅林固件
|
||||
- [[策略组分流]]：基于应用/地区/目标的流量分类转发机制
|
||||
- [[故障转移]]：连接故障时自动切换备用节点，保持网络通畅
|
||||
- [[订阅机制]]：通过机场订阅链接导入代理节点配置
|
||||
|
||||
## Key Entities
|
||||
- [[网件RAX50]]：WiFi 6 双频路由器，支持刷梅林固件
|
||||
- [[机场]]：提供代理节点订阅服务的数据中心
|
||||
- [[MerlinClash插件]]：基于 Clash 的高级科学上网插件（需新建 Entity）
|
||||
|
||||
## Connections
|
||||
- [[网件RAX50]] ← uses ← [[梅林固件]]
|
||||
- [[梅林固件]] ← enables ← [[MerlinClash插件]]
|
||||
- [[MerlinClash插件]] ← depends_on ← [[策略组分流]]
|
||||
- [[梅林固件]] ← requires ← [[过渡固件]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
---
|
||||
title: "网件RAX50路由器刷梅林固件与科学上网插件安装教程"
|
||||
type: source
|
||||
tags: [clash, merlin-clash, rax50, 科学上网, 梅林固件]
|
||||
date: 2026-04-26
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/网件RAX50路由器刷梅林固件与科学上网插件安装教程]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- **核心主题**：网件RAX50路由器刷入梅林固件并安装科学上网插件的完整操作指南
|
||||
- **问题域**：路由器固件刷入、科学上网插件配置、网络分流与故障转移
|
||||
- **方法/机制**：
|
||||
- 二次刷机流程（.chk 过渡固件 → .w 梅林固件）
|
||||
- JFFS双清操作清理旧缓存
|
||||
- 软件中心安装 MerlinClash 科学上网插件
|
||||
- 策略组配置实现节点分流与故障转移
|
||||
- 定时自动更新订阅、守护进程保证插件稳定运行
|
||||
- **结论/价值**：提供网件路由器科学上网的完整闭环方案，包含硬件刷机、软件配置与日常维护
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- 网件RAX50路由器必须先刷 .chk 过渡固件，再刷 .w 梅林固件，直接刷 .w 会失败
|
||||
- JFFS双清可清理文件系统缓存，防止刷机后残留问题
|
||||
- MerlinClash 插件支持策略组自动分流和节点故障转移，比同类插件功能更全面
|
||||
- MerlinClash 与科学上网插件不可同时运行，只能选其一
|
||||
- 恢复出厂设置不会恢复网件原厂固件，仅重置梅林固件配置
|
||||
|
||||
## Key Quotes
|
||||
> "必须先刷 `.chk` 的过渡固件，再刷 `.w` 的正式梅林固件，二次刷机才能确保稳定" — 刷机顺序说明
|
||||
> "两个插件不能同时运行，选择一个即可，优选支持策略组分流的 MerlinClash" — 插件选择建议
|
||||
> "通过策略组配置不同节点和规则，实现基于应用、地区和服务的自动分流和节点故障转移" — MerlinClash 核心优势
|
||||
|
||||
## Key Concepts
|
||||
- [[梅林固件]]：华硕路由器第三方固件改良版，支持插件和科学上网
|
||||
- [[过渡固件]]：.chk 格式，用于网件路由器从原厂固件过渡到梅林固件
|
||||
- [[策略组分流]]：基于应用/地区/目标的流量分类转发机制
|
||||
- [[故障转移]]：连接故障时自动切换备用节点，保持网络通畅
|
||||
- [[订阅机制]]：通过机场订阅链接导入代理节点配置
|
||||
|
||||
## Key Entities
|
||||
- [[网件RAX50]]：WiFi 6 双频路由器，支持刷梅林固件
|
||||
- [[机场]]：提供代理节点订阅服务的数据中心
|
||||
- [[MerlinClash插件]]：基于 Clash 的高级科学上网插件（需新建 Entity）
|
||||
|
||||
## Connections
|
||||
- [[网件RAX50]] ← uses ← [[梅林固件]]
|
||||
- [[梅林固件]] ← enables ← [[MerlinClash插件]]
|
||||
- [[MerlinClash插件]] ← depends_on ← [[策略组分流]]
|
||||
- [[梅林固件]] ← requires ← [[过渡固件]]
|
||||
|
||||
## Contradictions
|
||||
- 无已知冲突
|
||||
|
||||
@@ -1,48 +1,48 @@
|
||||
---
|
||||
title: "群晖NAS科学上网方法"
|
||||
type: source
|
||||
tags: [docker, nas, synology, v2raya, vpn, 透明代理]
|
||||
date: 2025-03-08
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/群晖NAS科学上网方法]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在群晖（Synology）NAS 上通过 Docker 安装 V2RayA，实现透明代理，使 NAS 本机和 Docker Daemon 均能科学上网
|
||||
- 问题域：群晖 DSM 环境下，Docker Daemon 网络栈不遵循 V2RayA 的 iptables 规则，导致 `docker pull` 仍无法走代理
|
||||
- 方法/机制：
|
||||
- 通过 Docker 部署 V2RayA 容器（Host 网络模式）
|
||||
- 透明代理（transparent proxy）劫持 NAS 本机出站流量
|
||||
- 路由规则选择"大陆白名单（Whitelist of Mainland China）"分流
|
||||
- 备用方案：显式配置 Docker Daemon HTTP 代理环境变量（推荐）
|
||||
- 结论/价值：透明代理对 NAS 本机有效，但对 Docker Daemon 无效；Engineering Best Practice 是显式配置 Docker 守护进程代理，而非依赖 Host 透明代理
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- V2RayA Docker 容器以 `--network=host` 模式运行，配合 `--restart=always` 确保开机自启
|
||||
- V2RayA 透明代理（分流模式"大陆白名单"）可使 NAS 本机流量走代理，验证方法：`curl https://www.google.com`（不加 `-x` 参数）直接返回 HTTP 200
|
||||
- DSM 7.x 中，Docker Daemon (`dockerd`) 网络栈不完全遵循 v2rayA 的 iptables 规则，`docker pull` 可能仍然失败
|
||||
- 显式配置 Docker Daemon 代理（systemd environment variables）是解决 `docker pull` 科学上网的推荐方案，符合 Engineering Best Practice
|
||||
|
||||
## Key Quotes
|
||||
> "在群晖 DSM 7.x 中，Docker Daemon (`dockerd`) 的网络栈有时候不会完全遵循 v2rayA 修改的 iptables 规则。如果上面的 `docker pull` 仍然慢或失败，**不要死磕透明代理**，直接配置 Docker 守护进程走 HTTP 代理是最稳妥的方案。" — 核心观点
|
||||
> "对于企业级或生产环境（即使是SOHO），我建议**不要**依赖 NAS Host 的透明代理来解决 `docker pull` 问题，因为这修改了系统级路由表，容易影响 NAS 其他服务。**显式配置 Docker Daemon 的 Proxy 环境变量（上面的最后一种方法）是更符合 Engineering Best Practice 的做法。**" — 最佳实践建议
|
||||
|
||||
## Key Concepts
|
||||
- [[V2RayA]]：基于 V2Ray 的轻量透明代理 Web 管理界面，支持多种分流规则（大陆白名单/GFWList 等）
|
||||
- [[透明代理]]（Transparent Proxy）：在网络层劫持并转发流量，无需客户端显式配置代理
|
||||
- [[Docker Daemon 代理]]：通过 systemd 环境变量为 Docker 守护进程配置 HTTP/HTTPS 代理，影响所有 `docker pull` 和容器出站流量
|
||||
- [[Traffic Splitting]]（流量分流）：V2RayA 的分流模式，根据路由规则决定流量直连或走代理
|
||||
|
||||
## Key Entities
|
||||
- [[Synology-DSM]]：群晖 NAS 操作系统，DSM 7.x 中 Docker 服务名为 `pkg-ContainerManager-dockerd`
|
||||
- [[Docker]]：容器化平台，本文档中作为 V2RayA 的运行环境和需要科学上网的主要场景
|
||||
- [[mzz2017/v2raya]]：V2RayA 官方 Docker 镜像，用于在 NAS 上部署代理服务
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu-Server科学上网]] ← similar_approach ← [[群晖NAS科学上网方法]]（同为 Linux 环境下部署 V2RayA 的实践）
|
||||
- [[Synology-NAS上安装CloudDrive2]] ← same_platform ← [[群晖NAS科学上网方法]]（均针对 Synology NAS 环境）
|
||||
- [[如何传输Docker-images-并且在另一个Docker安装]] ← referenced_by ← [[群晖NAS科学上网方法]]（文档内引用了镜像传输方法）
|
||||
|
||||
## Contradictions
|
||||
- 无冲突。与 [[Ubuntu-Server科学上网]] 的方法论一致（均推荐显式配置代理而非依赖透明代理）。
|
||||
---
|
||||
title: "群晖NAS科学上网方法"
|
||||
type: source
|
||||
tags: [docker, nas, synology, v2raya, vpn, 透明代理]
|
||||
date: 2025-03-08
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/群晖NAS科学上网方法]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：在群晖（Synology）NAS 上通过 Docker 安装 V2RayA，实现透明代理，使 NAS 本机和 Docker Daemon 均能科学上网
|
||||
- 问题域：群晖 DSM 环境下，Docker Daemon 网络栈不遵循 V2RayA 的 iptables 规则，导致 `docker pull` 仍无法走代理
|
||||
- 方法/机制：
|
||||
- 通过 Docker 部署 V2RayA 容器（Host 网络模式）
|
||||
- 透明代理（transparent proxy）劫持 NAS 本机出站流量
|
||||
- 路由规则选择"大陆白名单（Whitelist of Mainland China）"分流
|
||||
- 备用方案：显式配置 Docker Daemon HTTP 代理环境变量（推荐）
|
||||
- 结论/价值：透明代理对 NAS 本机有效，但对 Docker Daemon 无效；Engineering Best Practice 是显式配置 Docker 守护进程代理，而非依赖 Host 透明代理
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- V2RayA Docker 容器以 `--network=host` 模式运行，配合 `--restart=always` 确保开机自启
|
||||
- V2RayA 透明代理（分流模式"大陆白名单"）可使 NAS 本机流量走代理，验证方法：`curl https://www.google.com`（不加 `-x` 参数）直接返回 HTTP 200
|
||||
- DSM 7.x 中，Docker Daemon (`dockerd`) 网络栈不完全遵循 v2rayA 的 iptables 规则，`docker pull` 可能仍然失败
|
||||
- 显式配置 Docker Daemon 代理（systemd environment variables）是解决 `docker pull` 科学上网的推荐方案，符合 Engineering Best Practice
|
||||
|
||||
## Key Quotes
|
||||
> "在群晖 DSM 7.x 中，Docker Daemon (`dockerd`) 的网络栈有时候不会完全遵循 v2rayA 修改的 iptables 规则。如果上面的 `docker pull` 仍然慢或失败，**不要死磕透明代理**，直接配置 Docker 守护进程走 HTTP 代理是最稳妥的方案。" — 核心观点
|
||||
> "对于企业级或生产环境（即使是SOHO），我建议**不要**依赖 NAS Host 的透明代理来解决 `docker pull` 问题，因为这修改了系统级路由表，容易影响 NAS 其他服务。**显式配置 Docker Daemon 的 Proxy 环境变量（上面的最后一种方法）是更符合 Engineering Best Practice 的做法。**" — 最佳实践建议
|
||||
|
||||
## Key Concepts
|
||||
- [[V2RayA]]：基于 V2Ray 的轻量透明代理 Web 管理界面，支持多种分流规则（大陆白名单/GFWList 等）
|
||||
- [[透明代理]]（Transparent Proxy）：在网络层劫持并转发流量，无需客户端显式配置代理
|
||||
- [[Docker Daemon 代理]]：通过 systemd 环境变量为 Docker 守护进程配置 HTTP/HTTPS 代理，影响所有 `docker pull` 和容器出站流量
|
||||
- [[Traffic Splitting]]（流量分流）：V2RayA 的分流模式，根据路由规则决定流量直连或走代理
|
||||
|
||||
## Key Entities
|
||||
- [[Synology-DSM]]：群晖 NAS 操作系统，DSM 7.x 中 Docker 服务名为 `pkg-ContainerManager-dockerd`
|
||||
- [[Docker]]：容器化平台，本文档中作为 V2RayA 的运行环境和需要科学上网的主要场景
|
||||
- [[mzz2017/v2raya]]：V2RayA 官方 Docker 镜像，用于在 NAS 上部署代理服务
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu-Server科学上网]] ← similar_approach ← [[群晖NAS科学上网方法]]（同为 Linux 环境下部署 V2RayA 的实践）
|
||||
- [[Synology-NAS上安装CloudDrive2]] ← same_platform ← [[群晖NAS科学上网方法]]（均针对 Synology NAS 环境）
|
||||
- [[如何传输Docker-images-并且在另一个Docker安装]] ← referenced_by ← [[群晖NAS科学上网方法]]（文档内引用了镜像传输方法）
|
||||
|
||||
## Contradictions
|
||||
- 无冲突。与 [[Ubuntu-Server科学上网]] 的方法论一致（均推荐显式配置代理而非依赖透明代理）。
|
||||
|
||||
@@ -1,54 +1,54 @@
|
||||
---
|
||||
title: "通过VPS+内网反向代理实现域名访问内网穿透"
|
||||
type: source
|
||||
tags: [vps, caddy, frp, reverse-proxy, troubleshooting, cloudflare]
|
||||
date: 2026-04-03
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/通过VPS+内网反向代理实现域名访问内网穿透.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 VPS（frps + Caddy）建立反向隧道，使内网服务（NAS、Ubuntu）可通过 `*.ishenwei.online` 域名从公网安全访问。
|
||||
- 问题域：家庭内网设备无公网 IP，无法被外网直接访问；需要将内网服务通过公网 VPS 暴露为 HTTPS 域名。
|
||||
- 方法/机制：frp（frps 服务端 + frpc 客户端）建立 TCP 反向隧道 → VPS 本地端口映射 → Caddy 反向代理到对应端口并自动申请 Let's Encrypt HTTPS 证书。
|
||||
- 结论/价值：完整的内网穿透方案，支持 NAS、n8n、Transmission、Grafana、Navidrome、Calibre、WebDAV 等多个服务，附 SSH 穿透和故障排查指南。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- frp 专为内网穿透设计，支持 NAT 穿透、自动重连、Web 管理面板，比纯 SSH 隧道更适合多设备多端口场景。
|
||||
- Caddy 自动处理 Let's Encrypt 证书申请和续期，无需手动配置 HTTPS。
|
||||
- SSH 穿透（TCP 映射）不经过 Caddy，只依赖 frps + frpc 配置。
|
||||
- 故障排查核心：确认 frps 监听端口正确、token 一致、防火墙放行 7000 端口、frps 日志无 token mismatch。
|
||||
|
||||
## Key Quotes
|
||||
> "frp 优点：专为内网穿透设计，支持 NAT、自动重连、Web 管理面板（可选）。推荐当你有多台设备和多端口时使用。" — 方案选型说明
|
||||
> "Caddy 会自动申请并更新 Let's Encrypt 证书，提供 HTTPS 访问。" — HTTPS 配置结果
|
||||
> "SSH 穿透与 HTTP 不同，它是纯 TCP 流量，不经 Caddy（Caddy 只处理 HTTP/HTTPS），所以：Caddy 不参与 SSH 的代理。" — SSH vs HTTP 穿透关键区别
|
||||
> "authentication failed token mismatch invalid login → 那肯定是 token 和 frpc 不一致。" — 常见故障根因
|
||||
|
||||
## Key Concepts
|
||||
- [[反向代理]]：Caddy 将公网请求反向代理到 VPS 本地 frp 映射端口（127.0.0.1:xxxxx）。
|
||||
- [[内网穿透]]：通过 frp 反向隧道穿透 NAT/防火墙，使内网设备可被公网访问。
|
||||
- [[TCP隧道]]：frp 将内网 TCP 端口映射到 VPS remote_port，实现任意 TCP 协议穿透。
|
||||
- [[Caddy]]：Go 语言反向代理服务器，自动 HTTPS（Let's Encrypt），Caddyfile 配置各子域名反向代理到对应 frp 端口。
|
||||
- [[frp]]：开源内网穿透工具，frps（服务端）监听 7000 端口，frpc（客户端）建立反向隧道。
|
||||
|
||||
## Key Entities
|
||||
- [[RackNerd]]：VPS 提供商（IP: 192.227.222.142），托管 frps 和 Caddy，作为内网穿透公网中转站。
|
||||
- [[Synology NAS DS718]]：群晖 NAS（192.168.3.17），运行 NAS 管理界面（5000）、Navidrome（4533）、Calibre（8083）、WebDAV（5005）等服务，通过 frpc 映射到 VPS。
|
||||
- [[Ubuntu]]（内网 Ubuntu1 192.168.3.47）：运行 n8n（5678）、Transmission（9091）、Grafana（3000）、SSH（22），通过 frpc 映射到 VPS。
|
||||
- [[n8n]]：自动化工作流工具（192.168.3.47:5678），通过 frp 暴露为 `https://n8n.ishenwei.online`。
|
||||
- [[阿里云-DNS]]：管理 `ishenwei.online` 域名解析，A 记录指向 VPS 公网 IP。
|
||||
|
||||
## Connections
|
||||
- [[frp]] ← reverse_tunnel ← [[Synology NAS DS718]]（frpc 客户端，映射 5000→15000）
|
||||
- [[frp]] ← reverse_tunnel ← [[Ubuntu]]（frpc 客户端，映射 5678/9091/3000/22）
|
||||
- [[Caddy]] ← reverse_proxy ← [[frp]]（反向代理到 frp 映射的本地端口）
|
||||
- [[阿里云-DNS]] ← DNS_record ← [[RackNerd]]（A 记录指向 VPS IP 192.227.222.142）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Ubuntu安装FRP操作笔记]] 冲突：
|
||||
- 冲突点：两者都描述 frp 安装，但侧重不同。
|
||||
- 当前观点：本文档（通过VPS+内网反向代理）侧重完整方案（frps+VPS+Caddy+多服务+SSH穿透+故障排查），是完整的操作指南。
|
||||
- 对方观点：[[Ubuntu安装FRP操作笔记]] 侧重 FRP 本身安装配置（frps.ini/frpc.ini 详解），偏向 FRP 工具参考手册。
|
||||
- 说明：两者互补，本文档是完整实践指南，对方是工具参考，两者不存在实质矛盾。
|
||||
---
|
||||
title: "通过VPS+内网反向代理实现域名访问内网穿透"
|
||||
type: source
|
||||
tags: [vps, caddy, frp, reverse-proxy, troubleshooting, cloudflare]
|
||||
date: 2026-04-03
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[Home Office/通过VPS+内网反向代理实现域名访问内网穿透.md]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：通过 VPS（frps + Caddy）建立反向隧道，使内网服务（NAS、Ubuntu）可通过 `*.ishenwei.online` 域名从公网安全访问。
|
||||
- 问题域：家庭内网设备无公网 IP，无法被外网直接访问；需要将内网服务通过公网 VPS 暴露为 HTTPS 域名。
|
||||
- 方法/机制：frp（frps 服务端 + frpc 客户端）建立 TCP 反向隧道 → VPS 本地端口映射 → Caddy 反向代理到对应端口并自动申请 Let's Encrypt HTTPS 证书。
|
||||
- 结论/价值：完整的内网穿透方案，支持 NAS、n8n、Transmission、Grafana、Navidrome、Calibre、WebDAV 等多个服务，附 SSH 穿透和故障排查指南。
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- frp 专为内网穿透设计，支持 NAT 穿透、自动重连、Web 管理面板，比纯 SSH 隧道更适合多设备多端口场景。
|
||||
- Caddy 自动处理 Let's Encrypt 证书申请和续期，无需手动配置 HTTPS。
|
||||
- SSH 穿透（TCP 映射）不经过 Caddy，只依赖 frps + frpc 配置。
|
||||
- 故障排查核心：确认 frps 监听端口正确、token 一致、防火墙放行 7000 端口、frps 日志无 token mismatch。
|
||||
|
||||
## Key Quotes
|
||||
> "frp 优点：专为内网穿透设计，支持 NAT、自动重连、Web 管理面板（可选）。推荐当你有多台设备和多端口时使用。" — 方案选型说明
|
||||
> "Caddy 会自动申请并更新 Let's Encrypt 证书，提供 HTTPS 访问。" — HTTPS 配置结果
|
||||
> "SSH 穿透与 HTTP 不同，它是纯 TCP 流量，不经 Caddy（Caddy 只处理 HTTP/HTTPS），所以：Caddy 不参与 SSH 的代理。" — SSH vs HTTP 穿透关键区别
|
||||
> "authentication failed token mismatch invalid login → 那肯定是 token 和 frpc 不一致。" — 常见故障根因
|
||||
|
||||
## Key Concepts
|
||||
- [[反向代理]]：Caddy 将公网请求反向代理到 VPS 本地 frp 映射端口（127.0.0.1:xxxxx）。
|
||||
- [[内网穿透]]：通过 frp 反向隧道穿透 NAT/防火墙，使内网设备可被公网访问。
|
||||
- [[TCP隧道]]：frp 将内网 TCP 端口映射到 VPS remote_port，实现任意 TCP 协议穿透。
|
||||
- [[Caddy]]：Go 语言反向代理服务器，自动 HTTPS（Let's Encrypt），Caddyfile 配置各子域名反向代理到对应 frp 端口。
|
||||
- [[frp]]：开源内网穿透工具，frps（服务端）监听 7000 端口，frpc（客户端）建立反向隧道。
|
||||
|
||||
## Key Entities
|
||||
- [[RackNerd]]：VPS 提供商（IP: 192.227.222.142），托管 frps 和 Caddy，作为内网穿透公网中转站。
|
||||
- [[Synology NAS DS718]]：群晖 NAS（192.168.3.17），运行 NAS 管理界面（5000）、Navidrome（4533）、Calibre（8083）、WebDAV（5005）等服务，通过 frpc 映射到 VPS。
|
||||
- [[Ubuntu]]（内网 Ubuntu1 192.168.3.47）：运行 n8n（5678）、Transmission（9091）、Grafana（3000）、SSH（22），通过 frpc 映射到 VPS。
|
||||
- [[n8n]]：自动化工作流工具（192.168.3.47:5678），通过 frp 暴露为 `https://n8n.ishenwei.online`。
|
||||
- [[阿里云-DNS]]：管理 `ishenwei.online` 域名解析，A 记录指向 VPS 公网 IP。
|
||||
|
||||
## Connections
|
||||
- [[frp]] ← reverse_tunnel ← [[Synology NAS DS718]]（frpc 客户端，映射 5000→15000）
|
||||
- [[frp]] ← reverse_tunnel ← [[Ubuntu]]（frpc 客户端，映射 5678/9091/3000/22）
|
||||
- [[Caddy]] ← reverse_proxy ← [[frp]]（反向代理到 frp 映射的本地端口）
|
||||
- [[阿里云-DNS]] ← DNS_record ← [[RackNerd]]（A 记录指向 VPS IP 192.227.222.142）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Ubuntu安装FRP操作笔记]] 冲突：
|
||||
- 冲突点：两者都描述 frp 安装，但侧重不同。
|
||||
- 当前观点：本文档（通过VPS+内网反向代理）侧重完整方案（frps+VPS+Caddy+多服务+SSH穿透+故障排查），是完整的操作指南。
|
||||
- 对方观点：[[Ubuntu安装FRP操作笔记]] 侧重 FRP 本身安装配置（frps.ini/frpc.ini 详解），偏向 FRP 工具参考手册。
|
||||
- 说明：两者互补，本文档是完整实践指南，对方是工具参考，两者不存在实质矛盾。
|
||||
|
||||
Reference in New Issue
Block a user