Tech on HiDa

屏蔽深信服BBC登录页粒子动画

Thu, 21 May 2026 10:50:57 +0800

前言

每次登录深信服 BBC（Business Behavior Control）时，都会被登录页面上那个花里胡哨的粒子动画困扰——漂浮的小点、连线，看起来酷炫，实际毫无用处，纯纯画蛇添足、华而不实，还白白浪费 CPU 和 GPU 资源。

解决方案

只需要在 uBlock Origin Lite 中添加一条自定义过滤规则，即可屏蔽这个烦人的粒子动画。

操作步骤

打开 uBlock Origin Lite 的选项页面（点击扩展图标 → 齿轮图标）
切换到 “我的规则”（My Rules） 选项卡
在规则输入框中添加以下规则：

<hostip>##canvas.particles-js-canvas-el

将 <hostip> 替换为你的深信服 BBC 服务器地址，例如：

10.0.0.1##canvas.particles-js-canvas-el

点击 “应用更改”（Apply changes）

规则说明

10.0.0.1 — 你的深信服 BBC 服务器 IP 地址
## — uBlock Origin 的元素隐藏语法
canvas.particles-js-canvas-el — 粒子动画使用的 Canvas 元素的 CSS 选择器

这条规则会让 uBlock Origin Lite 直接隐藏该 Canvas 元素，页面不再渲染粒子动画，登录页面瞬间清爽，CPU/GPU 占用也随之降低。

效果

添加规则后，深信服 BBC 登录页面将不再显示粒子动画，只保留干净的登录表单。页面加载更快，资源占用更低。

参考

firewalld 配置 internal 到 public 区域的流量转发

Mon, 18 May 2026 19:22:32 +0800

firewalld 支持通过 Policy 对象实现跨区域流量转发。本文介绍如何配置策略，允许 internal 区域的流量转发到 public 区域，使内网主机可以通过防火墙访问外部网络。

前提条件

firewalld 已安装并运行（systemctl status firewalld）
有 root 或 sudo 权限
了解 firewalld 的 Zone 和 Policy 概念

创建转发策略

firewalld 的 Zone 控制接口上的流量方向，而 Policy 用于定义跨区域的流量转发规则。我们需要创建一个 Policy，将 internal 作为入口区域，public 作为出口区域。

# 创建新策略
sudo firewall-cmd --permanent --new-policy allow-internal-to-public

# 设置入口区域（源）为 internal，出口区域（目标）为 public
sudo firewall-cmd --permanent --policy allow-internal-to-public --add-ingress-zone internal
sudo firewall-cmd --permanent --policy allow-internal-to-public --add-egress-zone public

# 设置动作为 ACCEPT，并给予高优先级（确保不被其他策略覆盖）
sudo firewall-cmd --permanent --policy allow-internal-to-public --set-target ACCEPT
sudo firewall-cmd --permanent --policy allow-internal-to-public --set-priority -100

关键参数说明：

参数	说明
`--add-ingress-zone`	流量进入的区域（源区域）
`--add-egress-zone`	流量出去的区域（目标区域）
`--set-target ACCEPT`	匹配该策略的流量默认放行
`--set-priority -100`	优先级数值越小越优先，负数确保优先于默认策略

开启伪装（MASQUERADE）

为了让内网 IP 的流量通过 public 区域的出口 IP 访问外部网络，需要为 public 区域开启源地址伪装（SNAT）：

sudo firewall-cmd --permanent --zone=public --add-masquerade

启用 IP 转发

Linux 内核默认关闭 IP 转发功能，需要手动开启：

# 临时启用（重启后失效）
sudo sysctl -w net.ipv4.ip_forward=1

# 永久启用
echo net.ipv4.ip_forward=1 | sudo tee -a /etc/sysctl.d/99-ipforward.conf

重载防火墙

以上所有 --permanent 操作需要重载后才会生效：

sudo firewall-cmd --reload

验证配置

# 查看策略列表
sudo firewall-cmd --get-policies

# 查看策略详情
sudo firewall-cmd --info-policy allow-internal-to-public

# 查看 public 区域是否开启伪装
sudo firewall-cmd --zone=public --query-masquerade

# 查看 IP 转发状态
sysctl net.ipv4.ip_forward

常见问题

内网主机无法访问外部？ 检查以下几点：

确认 net.ipv4.ip_forward 已设为 1
确认 public 区域的伪装已开启
确认 internal 区域的接口绑定正确：sudo firewall-cmd --zone=internal --list-all
确认内网主机的默认网关指向防火墙的 internal 接口 IP

策略优先级被覆盖？ 使用更小的优先级数值（如 -200），firewalld 优先级范围是 -32768 到 32767，数值越小越优先。

参考

在VyOS上运行ZeroTier实现站点间组网

Wed, 22 Apr 2026 10:42:28 +0800

前言

VyOS 是一个开源的路由器操作系统，ZeroTier 则是一个易于使用的 SD-WAN 方案。将两者结合，可以用 VyOS 作为各站点的网关设备，通过 ZeroTier 组建虚拟网络，实现站点间的安全通信。

相比传统的 IPsec VPN 或 BGP over WireGuard 方案，ZeroTier 的优势在于：无需公网 IP、无需手动配置隧道对端、通过 Central 控制台统一管理路由。适合中小规模的多站点部署。

本文基于 VyOS 1.4（Rolling Release）和 ZeroTier 官方 Docker 镜像，演示从容器部署到路由配置的完整流程。

网络拓扑

假设有 3 个站点，每个站点一台 VyOS 路由器，通过 ZeroTier 组网：

Site 1：RTR1，本地子网 10.1.0.0/24
Site 2：RTR2，本地子网 10.2.0.0/24
Site 3：RTR3，本地子网 10.3.0.0/24

ZeroTier 虚拟网络分配 10.13.0.0/16，每个节点通过 ZeroTier 自动分配一个 IP。

基础网络配置

确保每台 VyOS 有互联网连接和 DNS 解析：

configure
set interfaces ethernet eth0 address dhcp
set system name-server 223.5.5.5
commit
save

验证连通性：

ping 223.5.5.5 count 2

部署 ZeroTier 容器

VyOS 1.4 原生支持容器管理，我们使用 ZeroTier 官方 Docker 镜像。

1. 拉取镜像

add container image zerotier/zerotier:latest

VyOS 1.4 下载镜像时没有进度条，静默等待即可。用以下命令确认：

show container image

2. 创建持久化目录

将 ZeroTier 数据目录映射到 /config/ 下，确保重启后配置不丢失：

sudo mkdir -p /config/containers/zt1

3. 配置容器

configure
set container name zt1 allow-host-networks
set container name zt1 cap-add net-admin
set container name zt1 device tun destination /dev/net/tun
set container name zt1 device tun source /dev/net/tun
set container name zt1 image zerotier/zerotier:latest
set container name zt1 volume ZT_Path destination /var/lib/zerotier-one
set container name zt1 volume ZT_Path source /config/containers/zt1
commit
save

关键参数说明：

allow-host-networks：容器共享宿主网络栈，ZeroTier 创建的接口直接出现在 VyOS 上
cap-add net-admin：授予容器网络管理权限，允许创建虚拟网卡
device tun：将宿主的 TUN 设备映射进容器
volume ZT_Path：持久化 ZeroTier 的身份文件和配置

验证容器状态：

show container

映射 ZeroTier 接口

通过 devicemap 文件将 ZeroTier 网络映射为指定的以太网接口（如 zt0），便于后续配置防火墙策略：

sudo su
cd /config/containers/zt1
cat > devicemap << EOF
<NetworkID>=zt0
EOF
exit

将 <NetworkID> 替换为你在 ZeroTier Central 创建的网络 ID。然后重启容器使映射生效：

restart container zt1

加入 ZeroTier 网络

进入容器，执行 join 命令：

connect container zt1
zerotier-cli join <NetworkID>
exit

返回 200 join OK 表示加入成功。记录下 zerotier-cli info 输出的 Node ID。

在 Central 中授权节点

找到新加入的节点，将 Node ID 与各路由器对上
勾选 Auth 列的复选框授权
可选：为每个节点设置名称便于识别

授权后，在 VyOS 上确认接口已获取 IP：

show interfaces ethernet zt0

应能看到 ZeroTier 分配的 IP（如 10.13.x.x/16）。

配置路由

方法一：通过 ZeroTier Central 推送路由（推荐）

在 ZeroTier Central 的 Managed Routes 中添加各站点路由：

目标网段	Via（节点 IP）
10.1.0.0/24	10.13.x.1（RTR1）
10.2.0.0/24	10.13.x.2（RTR2）
10.3.0.0/24	10.13.x.3（RTR3）

路由会自动下发到所有节点。ZeroTier 将路由 metric 设为 5000，不会覆盖本地更优先的路由。

方法二：在 VyOS 上配置静态路由

如果不想依赖 Central 推送，也可以手动在 VyOS 上配置：

configure
# RTR1 上
set protocols static route 10.2.0.0/24 next-hop 10.13.x.2
set protocols static route 10.3.0.0/24 next-hop 10.13.x.3
commit
save

验证连通性

查看路由表确认路由已下发：

show ip route

从 RTR1 ping 其他站点：

ping 10.2.0.1 source-address 10.1.0.1 count 2
ping 10.3.0.1 source-address 10.1.0.1 count 2

注意事项

Managed Routes 上限：ZeroTier Central 限制每个网络最多 128 条托管路由
路由优先级：ZeroTier 推送的路由 metric 为 5000，本地静态路由默认 metric 20，后者优先
MTU：ZeroTier 虚拟接口 MTU 通常为 2800（内部会自动分片），一般无需调整
持久化：/config/ 下的文件在 save 和重启后会保留，容器数据和 devicemap 都在其中
容器自动启动：配置 set container name zt1 后，VyOS 重启会自动启动容器

扩展：大规模部署

如果站点数量超过 127 个（128 条路由减去默认路由），或者需要多租户隔离，可以考虑：

使用 BGP over ZeroTier 替代托管路由，实现更灵活的路由策略
结合 MPLS 实现多租户场景
自建 ZeroTier Planet/Moon 控制器，脱离 Central 的托管路由限制

总结

在 VyOS 上通过容器运行 ZeroTier 是一种轻量且易维护的组网方式。核心步骤只有：拉镜像、配容器、join 网络、授权、配路由。对于没有公网 IP 的站点，ZeroTier 可以通过 NAT 穿透建立 P2P 连接，无需额外的 VPN 网关或 DDNS 配置。

原文：Using ZeroTier for Site-to-Site Routing on VyOS

redirusr 和 redircmp — Active Directory 默认容器重定向

Tue, 09 Sep 2025 23:45:00 +0000

Active Directory（AD）新建用户和计算机时，默认存放在 CN=Users 和 CN=Computers 容器中。这两个是容器（Container）而非组织单元（OU），无法直接应用组策略（GPO）。在生产环境中，通常需要将默认位置指向自定义 OU，以便统一管理策略和权限。

Windows Server 提供了 redirusr.exe 和 redircmp.exe 两个内置工具来完成这一操作。

为什么需要重定向

对比	Users / Computers 容器	自定义 OU
类型	Container（容器）	OU（组织单元）
GPO 链接	❌ 不支持	✅ 支持
委派控制	❌ 不支持	✅ 支持
典型用途	AD 内置账户、域控制器	按部门/角色组织管理对象

新建用户时如果忘记选择目标 OU，对象就会落入默认容器，导致策略未生效。重定向可以从根本上避免这个问题。

原理：wellKnownObjects 属性

重定向的本质是修改域根对象的 wellKnownObjects 属性。AD 通过该属性记录几个知名容器的 DN：

CN=Users → 新建用户默认位置
CN=Computers → 新计算机加入域时的默认位置

redirusr 和 redircmp 只是修改这个属性的便捷工具，效果等同于用 ADSI Edit 或 LDP 手动修改。

使用方法

两个工具位于域控制器上的 %SystemRoot%\System32 目录下，语法完全一致。

redirusr — 重定向用户默认容器

redirusr "OU=Staff,DC=example,DC=com"

执行后，所有新建用户将默认放入 OU=Staff,DC=example,DC=com。

redircmp — 重定向计算机默认容器

redircmp "OU=Workstations,DC=example,DC=com"

执行后，新计算机加入域时将默认放入 OU=Workstations,DC=example,DC=com。

验证

通过 ADSI Edit 查看：

打开 ADSI Edit → 连接到默认命名上下文
右键点击域根节点（如 DC=example,DC=com）→ 属性
找到 wellKnownObjects 属性
确认 CN=Users 和 CN=Computers 对应的 DN 已更新

也可以用 PowerShell 快速查看：

Get-ADDomain | Select-Object UsersContainer, ComputersContainer

重定向后此命令会返回新的 OU 路径。

完整示例

假设域名为 corp.example.com，计划结构如下：

DC=corp,DC=example,DC=com
├── OU=Accounts ← 用户默认位置
│ ├── OU=Admins
│ └── OU=Employees
├── OU=Workstations ← 计算机默认位置
│ ├── OU=Laptops
│ └── OU=Desktops
├── OU=Servers
├── OU=Groups
├── CN=Users ← 原默认容器（保留，不可删除）
└── CN=Computers ← 原默认容器（保留，不可删除）

执行：

# 在域控制器上以域管理员身份运行
redirusr "OU=Accounts,DC=corp,DC=example,DC=com"
redircmp "OU=Workstations,DC=corp,DC=example,DC=com"

之后新建用户 john，会自动出现在 OU=Accounts 下而非 CN=Users。

注意事项

1. 不可逆

重定向是单向操作，微软不提供撤销命令。如需回退，只能通过 ADSI Edit 手动将 wellKnownObjects 中的 DN 改回 CN=Users / CN=Computers。

2. 原容器仍存在

CN=Users 和 CN=Computers 容器不会被删除，其中的现有对象也不受影响。已有用户/计算机停留在原位，只有后续新建的对象才会进入新 OU。

如需将已有对象迁移到新 OU：

# 批量移动 CN=Users 下的用户到新 OU
Get-ADUser -Filter * -SearchBase "CN=Users,DC=corp,DC=example,DC=com" |
 Move-ADObject -TargetPath "OU=Accounts,DC=corp,DC=example,DC=com"

# 批量移动 CN=Computers 下的计算机到新 OU
Get-ADComputer -Filter * -SearchBase "CN=Computers,DC=corp,DC=example,DC=com" |
 Move-ADObject -TargetPath "OU=Workstations,DC=corp,DC=example,DC=com"

3. 目标 OU 必须已存在

执行前确保目标 OU 已创建，否则会报错：

# 预先创建 OU
New-ADOrganizationalUnit -Name "Accounts" -Path "DC=corp,DC=example,DC=com"
New-ADOrganizationalUnit -Name "Workstations" -Path "DC=corp,DC=example,DC=com"

4. 不影响手动指定 OU

通过 ADUC、New-ADUser、New-ADComputer 等工具手动指定了目标 OU 的操作不受影响。重定向只改变不指定位置时的默认行为。

5. 需要域管理员权限

执行 redirusr 和 redircmp 需要域管理员（Domain Admins）权限。

与其他方法的对比

方法	优点	缺点
redirusr / redircmp	简单一行命令，微软官方工具	不可逆，需手动迁移已有对象
ADSI Edit 修改 wellKnownObjects	更灵活，可回退	操作复杂，容易出错
脚本创建时指定 OU	完全可控	无法防止 ADUC 图形界面忘记选择
Powershell 策略审计	可检测遗漏	需要额外部署，非根本解决

对于大多数场景，redirusr + redircmp 是最简单直接的方案。

最佳实践

建域时就执行：在新建域之后、创建大量用户之前完成重定向
预先创建好 OU 结构：规划好组织架构后再执行
立即迁移已有对象：避免部分对象在新 OU、部分在旧容器造成混乱
记录变更：在运维文档中记录重定向操作，方便后续排查
验证 GPO 生效：重定向后创建测试用户/计算机，确认链接到 OU 的 GPO 正常应用

使用官方 Registry v2 搭建 Docker Mirror 私有镜像仓库

Mon, 09 Jun 2025 22:51:00 +0800

在国内网络环境下，直接从 Docker Hub 拉取镜像经常遇到超时或被限流的问题。搭建一个本地 Docker Mirror 代理仓库可以有效解决这个痛点。本文介绍如何使用官方 Registry v2 搭建私有镜像代理仓库。

为什么要搭 Docker Mirror

1. Docker Hub 公网限速

Docker Hub 对匿名用户的拉取限速为 100 次/6 小时，免费账户为 200 次/6 小时。在 CI/CD 流水线或多人团队环境下，这个限额很容易触达。通过自建 Mirror 代理，所有节点的拉取请求汇聚到 Mirror 节点，Mirror 对上游只产生一次请求，有效规避限额。

2. 缓存加速 Build

在 CI/CD 构建中，每次 docker build 都需要拉取基础镜像。即使代码没有变化，基础镜像也会被反复从公网拉取，浪费时间。Mirror 缓存了基础镜像后：

首次构建：从上游拉取并缓存
后续构建：直接从 Mirror 拉取，速度提升 5-10 倍
多节点并行构建：共享同一个 Mirror，只消耗一次外网流量

3. 离线可用与稳定性

特性	说明
离线可用	已缓存的镜像在内网环境下随时可用，不依赖外网连接
稳定可控	不受 Docker Hub 宕机、限速、DNS 污染等公网问题影响
节省带宽	多个节点共享缓存，外网出口带宽消耗大幅降低

架构说明

Docker Client → Caddy (HTTPS) → Registry v2 (Mirror) → DaoCloud 上游 → Docker Hub
 ↓
 本地缓存（命中则直接返回）

整个链路的请求流程：

Docker Client 向 docker pull 配置的 Mirror 地址发起拉取请求
请求经 Caddy HTTPS 反向代理转发到 Registry v2
Registry 检查本地缓存，命中则直接返回
缓存未命中时，Registry 向 DaoCloud 上游代理转发请求
DaoCloud 再从 Docker Hub 获取镜像数据并逐层返回
Registry 将收到的每一层数据写入本地缓存

环境准备

Docker 20.10+：确保 Docker Engine 版本支持 registry-mirrors 配置
域名：一个已解析到服务器 IP 的域名，用于 Caddy 自动申请 HTTPS 证书（如 mirror.example.com）
SSD 存储：建议至少 100GB 以上，镜像层文件较大且频繁读写，SSD 能显著提升缓存命中后的响应速度
开放端口：只需开放 443 端口（HTTPS），Registry 本身通过 Docker 内部网络通信，不暴露端口到宿主机

部署 Registry v2 Mirror

配置文件

创建 config.yml：

# Registry 配置文件版本，当前为 0.1
version: 0.1

# 日志配置
log:
 # 日志级别：debug / info / warn / error / fatal，默认 info
 level: info
 # 日志格式：json / text / logfmt，默认 logfmt
 formatter: logfmt
 # 附加字段，会添加到每条日志中，默认无
 fields:
 service: registry
 environment: production

# 存储配置
storage:
 # 存储驱动类型，默认 filesystem
 filesystem:
 # 镜像层数据的存储根目录，默认 /var/lib/registry
 rootdirectory: /var/lib/registry
 # 并发文件系统操作的线程数，默认 100
 maxthreads: 100
 # Blob 描述符缓存，用于加速 manifest 请求
 cache:
 blobdescriptor: inmemory
 # 启用删除 API，允许通过 DELETE 接口删除 blob，默认 false
 delete:
 enabled: true
 # 存储维护任务配置
 maintenance:
 # 上传清理，自动清理未完成的上传文件
 uploadpurging:
 # 是否启用上传清理，默认 true
 enabled: true
 # 未完成上传文件的保留时间，超过此时间将被清理，默认 168h（7 天）
 age: 168h
 # 清理检查间隔，默认 24h
 interval: 24h
 # 是否只预览不实际删除，默认 false
 dryrun: false
 # 只读模式开关，设为 true 时拒绝所有写入操作（push、delete），拉取正常
 # 可用于 GC 时临时开启，防止并发写入，默认 false
 readonly:
 enabled: false

# HTTP 服务器配置
http:
 # 监听地址和端口，默认 :5000
 addr: :5000
 # 监听的网络接口，默认 localhost（仅本地访问）
 host: 0.0.0.0
 # HTTP 响应头设置
 headers:
 # 防止浏览器 MIME 类型嗅探，安全最佳实践
 X-Content-Type-Options: [nosniff]
 # CORS 允许的来源，设为 * 允许所有来源
 Access-Control-Allow-Origin: ['*']
 # CORS 允许的 HTTP 方法
 Access-Control-Allow-Methods:
 - HEAD
 - GET
 - OPTIONS
 # CORS 允许的请求头
 Access-Control-Allow-Headers:
 - Authorization
 - Accept

# 上游代理配置
proxy:
 # 上游镜像源地址（必填）
 remoteurl: https://docker.m.daocloud.io
 # 上游认证用户名（可选，公共源不需要）
 # username:
 # 上游认证密码（可选，公共源不需要）
 # password:

# 健康检查配置
health:
 storagedriver:
 # 是否启用存储健康检查（默认：true）
 enabled: true
 # 检查间隔（默认：10s）
 interval: 10s
 # 连续失败多少次后标记不健康（默认：3）
 threshold: 3

关键配置项说明

配置项	默认值	说明
`storage.filesystem.rootdirectory`	`/var/lib/registry`	镜像存储路径
`storage.cache.blobdescriptor`	`inmemory`	Blob 元数据缓存方式，可选 `redis`
`storage.delete.enabled`	`false`	必须设为 true，否则无法执行 GC
`storage.maintenance.readonly.enabled`	`false`	只读模式，GC 时临时开启
`proxy.remoteurl`	-	上游镜像源地址
`health.storagedriver.enabled`	`true`	存储驱动健康检查

上游源选择：DaoCloud

特性	说明
稳定性	DaoCloud 是国内主流容器厂商，镜像站长期维护
完整性	同步 Docker Hub 全量镜像
速度	国内 CDN 加速
免费	公共服务，无需注册

其他可选的上游源：

# DaoCloud
remoteurl: https://docker.m.daocloud.io

# 阿里云
remoteurl: https://registry.cn-hangzhou.aliyuncs.com

# 腾讯云
remoteurl: https://mirror.ccs.tencentyun.com

可以部署多个 Mirror 实例使用不同的上游源，互为备份。

缓存类型

Registry v2 的 proxy 模式使用以下缓存机制：

1. Blob 缓存（层缓存）

镜像的每一层（layer）都会被缓存到本地存储：

/var/lib/registry/
├── docker/
│ └── registry/
│ └── v2/
│ ├── blobs/
│ │ └── sha256/ # 镜像层数据
│ └── repositories/ # 仓库元数据

2. Manifest 缓存（清单缓存）

镜像的 manifest（包含层关系、tag 等信息）也会被缓存。

3. BlobDescriptor 缓存（元数据缓存）

配置 storage.cache.blobdescriptor：

# 内存缓存（默认，适合中小规模）
storage:
 cache:
 blobdescriptor: inmemory

# Redis 缓存（适合大规模部署）
storage:
 cache:
 blobdescriptor: redis
redis:
 addr: redis:6379
 password: yourpassword
 db: 0
 ringlimit: 100

缓存策略

缓存类型	说明	建议场景
`inmemory`	元数据存内存，blob 存磁盘	镜像数量 < 10000
`redis`	元数据存 Redis，blob 存磁盘	镜像数量 > 10000，多实例

缓存未命中

Registry 检查本地存储 → 未找到
转发请求到上游（DaoCloud）
上游返回数据 → Registry 同时缓存到本地并返回给客户端
后续请求直接从本地返回

GC（垃圾回收）

随着时间推移，Registry 中会积累大量不再使用的镜像层数据（例如旧版本镜像被更新替换）。GC 用于清理这些无用数据，释放磁盘空间。

GC 原理

Registry 使用 content-addressable 存储，每个 blob 通过 SHA256 哈希标识。GC 的核心逻辑：

标记所有被当前 manifest 引用的 blob
删除未被引用的 blob（垃圾数据）

manifest v2 → 引用 blob A, B, C
manifest v1 → 引用 blob A, B, D（旧版本）

GC 后：blob D 被清除（只被旧 manifest 引用）

在线 GC（read-only 模式）

Registry v2 支持 只读模式（read-only mode），GC 前切换为只读，避免并发写入导致数据不一致：

将 Registry 切换为只读模式（拒绝写入，拉取正常）
执行 GC 清理未引用的 blob
恢复读写模式

第一步：预览（dry-run）

# 安全操作，不影响服务，建议先执行确认
docker exec registry-mirror bin/registry garbage-collect \
 /etc/docker/registry/config.yml \
 --dry-run

输出示例：

ubuntu for sha256:abc123...
nginx for sha256:def456...

第二步：切换只读 + 执行 GC + 恢复

注意：不能通过环境变量 REGISTRY_STORAGE_MAINTENANCE_READONLY_ENABLED=true 设置只读模式，会触发 panic（Registry 的已知 bug，环境变量覆盖 maintenance 子配置时 map key 类型不匹配）。 正确做法是通过 docker exec 修改容器内的 config.yml，再用 docker restart 重载配置。

# 1. 开启只读模式 + 重启生效
docker exec registry-mirror sed -i "/readonly:/,/enabled:/ s/enabled: false/enabled: true/" /etc/docker/registry/config.yml
docker restart registry-mirror

# 2. 等待容器就绪后执行 GC
sleep 5
docker exec registry-mirror bin/registry garbage-collect /etc/docker/registry/config.yml

# 3. 恢复读写模式 + 重启生效
docker exec registry-mirror sed -i "/readonly:/,/enabled:/ s/enabled: true/enabled: false/" /etc/docker/registry/config.yml
docker restart registry-mirror

定期 GC 建议

建议通过 cron 定期执行 GC：

# 每月 1 号凌晨 3 点执行 GC
0 3 1 * * root docker exec registry-mirror sed -i "/readonly:/,/enabled:/ s/enabled: false/enabled: true/" /etc/docker/registry/config.yml && docker restart registry-mirror && sleep 5 && docker exec registry-mirror bin/registry garbage-collect /etc/docker/registry/config.yml && docker exec registry-mirror sed -i "/readonly:/,/enabled:/ s/enabled: true/enabled: false/" /etc/docker/registry/config.yml && docker restart registry-mirror

GC 与删除 API 的区别

方式	作用	用途
`DELETE /v2/<name>/manifests/<digest>`	删除指定 manifest	删除特定镜像 tag
`garbage-collect`	清理未引用的 blob	回收磁盘空间

两者通常配合使用：先通过 DELETE API 删除不需要的 manifest，再执行 GC 释放空间。

Caddy Server — HTTPS 反向代理

Docker 客户端配置 registry-mirrors 要求使用 HTTPS。使用 Caddy 的核心优势是 零配置自动 HTTPS，自动申请和续期 Let’s Encrypt 证书。

为什么选 Caddy

特性	Caddy	Nginx
HTTPS 证书	自动申请续期	需配合 certbot
配置复杂度	极简	较复杂
HTTP/3	原生支持	需额外编译模块
适合场景	中小规模、快速部署	大规模、复杂路由

Caddyfile 配置

创建 Caddyfile：

mirror.example.com {
 reverse_proxy registry:5000

 # 上传大镜像需要放宽限制
 request_body {
 max_size 10GB
 }

 # Docker 客户端需要的 header
 header /v2/ Docker-Distribution-Api-Version "registry/2.0"

 # 访问日志
 log {
 output file /data/caddy/access.log
 format console
 }

 # 健康检查端点不记日志
 @health path /v2/
 log @health {
 output discard
 }
}

确保域名 mirror.example.com 的 DNS A 记录已指向服务器公网 IP，Caddy 才能自动申请 Let’s Encrypt 证书。

完整 docker-compose.yml（Caddy + Registry）

version: '3.8'

services:
 caddy:
 image: caddy:2-alpine
 container_name: registry-caddy
 restart: always
 ports:
 - "80:80"
 - "443:443"
 - "443:443/udp" # HTTP/3
 volumes:
 - ./Caddyfile:/etc/caddy/Caddyfile
 - ./caddy_data:/data
 - ./caddy_config:/config
 depends_on:
 registry:
 condition: service_healthy

 registry:
 image: registry:2
 container_name: registry-mirror
 restart: always
 # 不暴露端口，仅通过 Caddy 访问
 expose:
 - "5000"
 volumes:
 - ./data:/var/lib/registry
 - ./config.yml:/etc/docker/registry/config.yml
 environment:
 - REGISTRY_STORAGE_DELETE_ENABLED=true
 - REGISTRY_HTTP_ADDR=0.0.0.0:5000
 healthcheck:
 test: ["CMD", "wget", "--spider", "-q", "http://localhost:5000/v2/"]
 interval: 30s
 timeout: 10s
 retries: 3

启动服务

# 启动
docker compose up -d

# 查看 Caddy 日志，确认证书申请成功
docker logs -f registry-caddy

看到类似输出表示 HTTPS 证书已自动获取：

{"level":"info","msg":"certificate obtained successfully","identifier":"mirror.example.com"}

验证

# 测试 HTTPS 访问
curl https://mirror.example.com/v2/

# 应返回空 JSON：{}

Docker 客户端配置

{
 "registry-mirrors": [
 "https://mirror.example.com"
 ],
 "insecure-registries": []
}

使用 Caddy 提供 HTTPS 后，不需要 配置 insecure-registries，安全性更好。

Caddy 数据持久化

./caddy_data/ # TLS 证书（自动申请、自动续期）
./caddy_config/ # Caddy 配置缓存

证书续期由 Caddy 自动处理，无需人工干预。

日常运维

查看存储占用

# 查看缓存目录大小
du -sh /data/registry/

# 查看各仓库占用
du -sh /data/registry/docker/registry/v2/repositories/*

查看日志

docker logs -f --tail 100 registry-mirror
docker logs -f --tail 100 registry-caddy

健康检查

# 检查服务状态
curl https://mirror.example.com/v2/

# 检查上游连通性
curl https://mirror.example.com/v2/_catalog

完整目录结构

docker-mirror/
├── docker-compose.yml # Caddy + Registry
├── Caddyfile # Caddy HTTPS 反向代理配置
├── config.yml # Registry 配置
├── data/ # Registry 镜像缓存
├── caddy_data/ # Caddy TLS 证书
└── caddy_config/ # Caddy 配置缓存

总结

要点	说明
核心组件	官方 Registry v2 + proxy 模式
HTTPS 代理	Caddy（零配置自动 HTTPS、证书自动续期）
上游源	DaoCloud（稳定、完整、免费）
缓存加速	Blob 磁盘缓存 + 元数据内存/Redis 缓存，加速 CI/CD Build
GC	read-only 模式 + docker exec，防止并发写入
运维要点	监控磁盘用量、定期 GC、关注上游可用性

对于内网 Docker 环境，搭建一个 Mirror 代理仓库是性价比极高的基础设施投入，一次部署长期受益。

使用 resolvectl 临时指定 DNS 服务器

Thu, 08 May 2025 10:16:00 +0800

在日常运维中，我们经常需要临时切换 DNS 服务器来排查域名解析问题。传统做法是修改 /etc/resolv.conf，但在使用 systemd-resolved 的现代 Linux 发行版中，resolvectl 提供了更优雅的解决方案。

为什么用 resolvectl

传统的修改 /etc/resolv.conf 方式有几个痛点：

systemd-resolved 管理下会被覆盖：直接编辑 /etc/resolv.conf 可能无效，因为该文件是一个指向 /run/systemd/resolve/stub-resolv.conf 的符号链接
需要 root 权限：编辑系统文件必须 sudo
容易忘记还原：排查完问题后忘记改回来，可能影响业务

而 resolvectl 的优势：

特性	传统方式	resolvectl
修改配置文件	✅	❌
需要 root	✅	❌（per-link）
重启后恢复	需手动还原	✅ 自动恢复
影响范围	全局	可按网卡控制

查看当前 DNS 状态

# 查看全局 DNS 配置
resolvectl status

# 查看指定网卡
resolvectl status eth0

# 查看当前生效的 DNS 服务器
resolvectl dns

输出示例：

Global
 Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Resolving DNS Servers: 192.168.1.1
Fallback DNS Servers: 8.8.8.8

Link 2 (eth0)
 Current Scopes: DNS
 Protocols: +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported
Resolving DNS Servers: 192.168.1.1
 DNS Domain: lan

临时指定 DNS（per-link）

指定单网卡 DNS

# 将 eth0 的 DNS 指定为 Google DNS
sudo resolvectl dns eth0 8.8.8.8

# 指定多个 DNS（主备）
sudo resolvectl dns eth0 8.8.8.8 1.1.1.1

# 指定国内 DNS
sudo resolvectl dns eth0 223.5.5.5 119.29.29.29

验证生效

# 查看当前 DNS
resolvectl dns eth0

# 测试解析
resolvectl query example.com

# 使用指定 DNS 解析
resolvectl query example.com --interface=eth0

恢复默认 DNS

# 恢复为空（回退到全局配置）
sudo resolvectl dns eth0

# 恢复为 DHCP 下发的 DNS
sudo resolvectl revert eth0

全局临时指定 DNS

如果需要全局修改（影响所有网卡）：

# 设置全局 DNS
sudo resolvectl dns 8.8.8.8 1.1.1.1

# 恢复全局 DNS
sudo resolvectl dns

⚠️ 全局修改同样会在重启后恢复，但会影响所有网卡的 DNS 解析。

常用国内公共 DNS

DNS 服务商	地址	说明
阿里	223.5.5.5 / 223.6.6.6	稳定快速
腾讯	119.29.29.29	DNSPod
百度	180.76.76.76	-
114 DNS	114.114.114.114	老牌公共 DNS
Google	8.8.8.8 / 8.8.4.4	海外推荐
Cloudflare	1.1.1.1 / 1.0.0.1	海外

实战场景

场景一：排查域名解析故障

# 1. 查看当前 DNS
resolvectl dns

# 2. 临时切换到公共 DNS 验证
sudo resolvectl dns eth0 223.5.5.5

# 3. 测试解析
resolvectl query api.example.com

# 4. 如果公共 DNS 正常，说明内网 DNS 有问题
# 5. 恢复原配置
sudo resolvectl revert eth0

场景二：测试 DoH/DoT

# 查看是否支持 DNS over TLS
resolvectl status | grep -i tls

# 开启 DNS over TLS（需要 DNS 服务器支持）
sudo resolvectl dns-over-tls eth0 yes
sudo resolvectl dns eth0 tls://dns.google

场景三：多网卡环境指定 DNS

# eth0 走内网 DNS
sudo resolvectl dns eth0 192.168.1.1

# eth1 走公共 DNS
sudo resolvectl dns eth1 223.5.5.5

# 查询时指定网卡
resolvectl query internal.example.com --interface=eth0
resolvectl query www.0niu.cn --interface=eth1

注意事项

临时性：resolvectl 的修改在系统重启后会自动恢复为配置文件中的默认值
与 NetworkManager 冲突：如果使用 NetworkManager 管理 DNS，可能会被 NM 覆盖，可以设置 NM_CONTROLLED=no 或在 NM 配置中指定 DNS
systemd-resolved 必须运行：确认服务状态 systemctl status systemd-resolved
域名搜索后缀：可以使用 resolvectl domain eth0 example.com 临时添加搜索域

总结

resolvectl 是 systemd-resolved 提供的 DNS 管理工具，用于临时切换 DNS 非常方便：

✅ 无需修改配置文件
✅ 重启自动恢复
✅ 可按网卡粒度控制
✅ 支持 DNS over TLS

下次排查 DNS 问题时，不妨试试 resolvectl。