Ysicing | 缘生的 RSS 预览

MinIO迁移RustFS实战指南一

2025-12-14 21:36:18

作为资深 MinIO 用户，经历过 MinIO 一系列操作，从砍掉网关模式，砍掉控制台，到维护模式。老实说，我个人认为这类开源产品很难实现商业化。这种不断收缩能力边界的变化，对使用者来说影响是实实在在的。并不是功能不好，而是你已经把它当作基础设施依赖了，却发现它的产品路线在变，这也是我开始认真考虑 MinIO 之外的选择的直接原因

项目地址

MinIO https://github.com/minio/minio
RustFS https://github.com/rustfs/rustfs

为啥选择 RustFS，经过大量讨论与实践，RustFS 逐渐成为那个改动最小、适配最易的首选替代品，深度兼容 MinIO 的 API 与架构。

快速部署

本次主要迁移了一个大盘鸡备份 MinIO, 方便操作直接使用 compose 部署

services:
  minio:
    image: ccr.ccs.tencentyun.com/k7scn/minio:2025
    container_name: minio
    restart: always
    environment:
      - MINIO_ROOT_USER=Fah0quaixei0
      - MINIO_ROOT_PASSWORD=wi0iez3gaaZoghohCai5zeedeenatooxunoh8AhwangeiPho8Obahja
      - MINIO_DEFAULT_BUCKETS=backup
    ports:
      - '100.90.80.15:9000:9000'
      - '100.90.80.15:9001:9001'
    volumes:
      - '/data/minio:/bitnami/minio/data'

  rustfs:
    image: ccr.ccs.tencentyun.com/k7scn/rustfs:latest
    container_name: rustfs
    restart: always
    environment:
      - RUSTFS_ACCESS_KEY=Fah0quaixei0
      - RUSTFS_SECRET_KEY=wi0iez3gaaZoghohCai5zeedeenatooxunoh8AhwangeiPho8Obahja
    ports:
      - '192.168.94.15:9000:9000'
      - '192.168.94.15:9001:9001'
    volumes:
      - '/data/rustfs/data:/data'
      - '/data/rustfs/logs:/logs'

注意 RustFS 的日志目录，不确定官方文档和示例有冲突(/logs 或者 /app/logs), 其实影响不大。

docker compose up -d
chown -R 10001:10001 /data/rustfs/data /data/rustfs/logs
docker compose down -v
docker compose up -d

其他的都和 MinIO 没啥区别，登录控制台创建 Bucket

可以直接使用 MC 操作

mc alias set rustfs http://192.168.94.15:9000 Fah0quaixei0 wi0iez3gaaZoghohCai5zeedeenatooxunoh8AhwangeiPho8Obahja

测试直接使用 restic 测试

export RESTIC_REPOSITORY=s3:http://192.168.94.15:9000/backup/test
export AWS_ACCESS_KEY_ID=Fah0quaixei0
export AWS_SECRET_ACCESS_KEY=wi0iez3gaaZoghohCai5zeedeenatooxunoh8AhwangeiPho8Obahja
export RESTIC_PASSWORD=eexeeWie1ri

直接备份测试

restic init
restic backup /data/mariadb --tag mariadb

repository 7d5b008d opened (version 2, compression level auto)
found 2 old cache directories in /root/.cache/restic, run `restic cache --cleanup` to remove them
no parent snapshot found, will read all files
[0:01] 100.00%  1 / 1 index files loaded

Files:         205 new,     0 changed,     0 unmodified
Dirs:            8 new,     0 changed,     0 unmodified
Added to the repository: 10.385 MiB (730.814 KiB stored)

processed 205 files, 124.408 MiB in 0:10
snapshot fed84173 saved

从目前来看没啥问题，可以先跑一段时间再看看。也可以使用 mc mirror 等工具将存量数据从 MinIO 迁移至 RustFS

最后

开源的魅力，就是你永远有选择的余地。

Tailscale Peer Relay 最新变更解读

2025-12-11 22:50:34

在我之前的文章 Tailscale Peer Relay 实战指南，让内网穿透更稳更快中，我介绍了如何通过在 Tailnet 内配置一台网络条件良好的设备作为中继，来优化内网穿透体验。最近 Tailscale 官方对 Peer Relay 做出了重要更新，尤其是 新增支持 Static Endpoints，这是一次值得关注的变化。

核心更新一览

新增 Static Endpoints
- 过去：Peer Relay 只能依赖 Tailnet 内的某个设备作为中继，设备必须在线。
- 现在：支持配置 固定的中继地址（Static Endpoint），例如云服务器或数据中心节点。
- 意义：让 Peer Relay 从“临时设备中继”升级为“可控的固定中继”，更稳定、更适合企业和高吞吐场景。
官方定位调整
- 旧理解：Peer Relay 可以替代 DERP。
- 新定位：Peer Relay 是 DERP 的补充，在直连失败时优先尝试，如果不可用仍会回退到 DERP。
- 这意味着 DERP 依旧是兜底方案，而 Peer Relay 更像是加速器。
权限与安全控制
- 官方强调避免过度宽泛的 ACL 配置（如 src: *），否则可能导致所有设备都走中继，增加延迟。
- 最佳实践：只针对受限环境或特定标签设备开放 Peer Relay/Static Endpoint。

配置与验证方式

启用命令保持一致：

tailscale set --relay-server-port=40000

ACL 中新增写法：

{
  "grants": [
    {
      "src": ["tag:restricted-devices"],
      "dst": ["static:relay.example.com:40000"],
      "app": { "tailscale.com/cap/relay": [] }
    }
  ]
}

验证方式：除了 tailscale ping，还可以用
```
tailscale status | grep peer-relay
```
来确认连接是否走中继。

典型应用场景
- 大文件传输：提升吞吐，避免 DERP 带宽瓶颈。
- 媒体流播放：高清视频/音频流更流畅。
- 区域优化：在不同地理位置部署静态中继，降低跨区延迟。
禁用

tailscale set --relay-server-port=""

总结

这次更新的最大亮点就是 Static Endpoints 的支持，让 Peer Relay 从“设备中继”走向“固定中继”，更适合企业和高吞吐场景。同时，官方也明确了 Peer Relay 的定位——它是 DERP 的补充，而不是替代。

如果你之前已经部署过 Peer Relay，现在可以考虑在云端或数据中心配置一个 Static Endpoint，让整个 Tailnet 的中继更加稳定和可控。

Umami 升级提醒：尽快更新以修复 Next.js CVE-2025-66478 漏洞

2025-12-06 01:17:27

最近 Next.js 官方发布了 CVE-2025-66478 安全公告（详情可见官方链接）。由于 Umami 采用 Next.js 构建，因此同样受到本次漏洞影响

好消息是：Umami 官方已经发布新版本修复漏洞

同时需要注意：Umami 从 v3 起彻底移除 MySQL 支持，统一切换为 PostgreSQL
如果你仍在使用 MySQL 版本，强烈建议你尽快升级并迁移数据，避免暴露在风险中

v2 升级到最新版本

我已经同步好了官方镜像, 替换直接升级，由于 v2 版本没有打 patch 只能升级到 v3 才能解决

- ghcr.io/umami-software/umami:mysql-latest
- ccr.ccs.tencentyun.com/k7scn/umami:mysql-latest

将 MySQL 迁移到 PostgreSQL

Umami v3 确保数据的一致性，废弃了对 mysql 的支持，统一采用 PostgreSQL。本步骤参考官方文档 install-umami-with-a-postgresql-database 实践。

升级真是一件糟糕的体验，如果你之前是使用 MySQL，不建议升级，直接重装 v3

环境要求

官方要求迁移前 MySQL 结构必须达到 v2.19.0，否则执行迁移脚本会失败
你可以通过升级镜像确保数据库 schema 是最新的

两个数据库的登录凭证：

MySQL: mysql://user:password@host:port/dbname
PostgreSQL: postgresql://user:password@host:port/dbname

PG 数据库

bitnami 操作也很蜜汁。如下示例，对应 ip 密码自行修改

services:
  postgresql:
    image: h.ysicing.net/bitnami/postgresql
    container_name: postgresql
    ports:
      - '100.90.80.10:5432:5432'
    volumes:
      - '/data/postgresql:/bitnami/postgresql'
    environment:
      - POSTGRESQL_DATABASE=umami
      - POSTGRESQL_USERNAME=user
      - POSTGRESQL_PASSWORD=password
      - POSTGRESQL_POSTGRES_PASSWORD=password_root
    restart: always

导出 mysql 数据

mysqldump --no-create-info --default-character-set=utf8mb4 --quick --skip-add-locks -uroot -h100.90.80.10 -poAkahz4ahvei1oReing6oh5ubaen1veV umami > umami.sql

部署 pg 版 Umami v2

具体参考流程可以参考部署轻量数据统计分析 umami

官方镜像 ghcr.io/umami-software/umami:postgresql-v2
国内镜像 ccr.ccs.tencentyun.com/k7scn/umami:postgresql-v2

替换一下镜像地址和环境变量

mysql 环境变量为

- env:
        - name: DATABASE_URL
          value: mysql://root:[email protected]:3306/umami
        - name: HASH_SALT
          value: ezee4eGhalaishiphese8yaiphomon
        - name: DATABASE_TYPE
          value: mysql
        image: ccr.ccs.tencentyun.com/k7scn/umami:mysql-latest

pg 环境变量为

- env:
        - name: DATABASE_URL
          value: postgresql://ysicing:[email protected]:5432/umami
        - name: HASH_SALT
          value: ezee4eGhalaishiphese8yaiphomon
        image: ccr.ccs.tencentyun.com/k7scn/umami:postgresql-v2

去掉了 DATABASE_TYPE, 修改了 DATABASE_URL 值
镜像换成了 pg v2 版本镜像

等初始化完成，关闭服务，避免重复初始化数据库(避免影响下面流程)

修改 pg 数据库

使用 DataGrip 连接 umami 数据库，执行下面的 sql，这两个表数据将从 mysql 的数据中获取

truncate table "_prisma_migrations";
truncate table "user";

效果如下

[2025-12-05 22:24:47] 已连接到 umami
[2025-12-05 22:24:47] umami> truncate table "_prisma_migrations"
[2025-12-05 22:24:47] 在 10 ms 内完成
[2025-12-05 22:24:47] umami> truncate table "user"
[2025-12-05 22:24:47] 在 11 ms 内完成

导入数据

使用上面的备份数据 umami.sql

22:22 ➜  ~ ls -alh umami.sql
-rw-r--r--  1 ysicing  staff    99M 12  5 22:09 umami.sql

将反引号替换为双引号，使其与 PostgreSQL 兼容, 如果 macOS 执行有问题，在 Linux 搞下。操作前可以备份一下，避免搞坏了

sed -i 's/`/"/g' umami.sql

macOS

sed -i '' 's/`//g' umami.sql
sed -i '' 's/\\"/"/g' umami.sql
sed -i '' "s/\\\\'/'/g" umami.sql
sed -i '' "s/Xi'an/Xi''an/g" umami.sql
sed -i '' "s/Lu'an/Lu''an/g" umami.sql
sed -i '' "s/Ma'anshan/Ma''anshan/g" umami.sql
sed -i '' "s/Rui'an/Rui''an/g" umami.sql
sed -i '' "s/Yu'an/Yu''an/g" umami.sql
sed -i '' "s/Bo'an/Bo''an/g" umami.sql
sed -i '' "s/Tai'an/Tai''an/g" umami.sql
sed -i '' "s/Cao'an/Cao''an/g" umami.sql
sed -i '' "s/Chang'an/Chang''an/g" umami.sql
sed -i '' 's/ENGINE=[^ ]*//g' umami.sql
sed -i '' 's/AUTO_INCREMENT/[generated always as identity]/g' umami.sql
sed -i '' 's/unsigned//g' umami.sql
sed -i '' '/_prisma_migrations/d' umami.sql

可以手搓如下，我这里直接使用 DataGrip

psql -U username -d mydb < umami.sql

由于 MySQL → PostgreSQL 差异巨大，需要执行大量替换操作。报错太多，决定放弃升级改成使用 v3 版本, 还是重装方便

v3 版本镜像

由于兼容性问题太多，我最终选择放弃 v2 的 MySQL → PostgreSQL 迁移，转而直接部署全新的 Umami v3。

v3 镜像地址：

官方：ghcr.io/umami-software/umami:postgresql-latest
国内同步：ccr.ccs.tencentyun.com/k7scn/umami:postgresql-latest

v3 使用体验更流畅、性能也更好，而且完全修复了此次 Next.js 漏洞。

总结：请大家尽快升级，避免被入侵

Umami 因 Next.js 漏洞受到影响

v3 已发布修复版本
强烈建议优先考虑升级至 v3
MySQL 用户请务必注意：v3 不再支持 MySQL

如果你还在运行旧版本，请尽快升级，避免站点暴露在风险中！我今天至少已经看到 10+ 站点被入侵挂马了。

出一台闲置的物理服务器

2025-12-02 22:35:49

很早之前我出的，然后又被我收到了，现在又闲置了，打算出了

厂家

老牌 IDC 了，工单响应速度极快，即使凌晨 15 分钟接单。

机器配置

Platinum8259CL*2
128GB DDR4
1TB NVMe SSD

续费 358/月
带宽上限 50Mbps (上行是 50Mbps，下行是 150Mbps)
防护峰值 400Gbps

迁移至宁波电信需在账单日进行且该机器为十堰活动款，迁移至宁波地区您的续费价格将会上调至 398 元，需要实名的。

12.19 到期, 一口价 300，需要自备实名账号，有意可以私聊我。

k8s免密拉取镜像实践

2025-12-01 22:09:17

算是一个比较老的知识点了 😂

之前都是使用云服务商提供的免密凭证，最近需要跨云跨账号，使用 AI 自己实现了一个通用的

原理

借助 ServiceAccount，实现 Pod 自动免密拉取私有镜像，做到镜像凭据配置一次，全命名空间或指定应用自动生效

主要优势

一个 ns 空间下只需要配置一次 secrets。Kubernetes 拉取私有镜像需要认证信息。如果每个服务都写 imagePullSecrets，不仅配置冗余，也不利于权限统一管理

使用 ServiceAccount 可以带来两个好处：

配置一次，全自动继承
不污染 Pod 等 yaml，让业务部署更干净

手动配置

主要参考官方文档为服务账号添加 ImagePullSecrets

首先，生成一个 imagePullSecret；接下来，验证该 Secret 已被创建。例如：

kubectl create secret docker-registry myregistrykey --docker-server=<registry name> \
        --docker-username=DUMMY_USERNAME --docker-password=DUMMY_DOCKER_PASSWORD \
        --docker-email=DUMMY_DOCKER_EMAIL
        
# 检查该 Secret 已经被创建
kubectl get secrets myregistrykey
NAME             TYPE                              DATA    AGE
myregistrykey    kubernetes.io/.dockerconfigjson   1       1d

将镜像拉取 Secret 添加到服务账号

接下来更改名字空间的默认服务账号，将该 Secret 用作 imagePullSecret

kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "myregistrykey"}]}'

效果等同于

apiVersion: v1
kind: ServiceAccount
metadata:
  creationTimestamp: 2021-07-07T22:02:39Z
  name: default
  namespace: default
  uid: 052fb0f4-3d50-11e5-b066-42010af0d7b6
imagePullSecrets:
  - name: myregistrykey

再当前命名空间下创建一个私有仓库的 Pod 测试看看

自动实现

原理就是 watch ns 创建，当收到 ns 创建后，自动创建相关凭证，同时给 ns 打上凭证版本标签，方便后续凭证有更新。

其他

不建议把 secret 绑定到 default ServiceAccount，因为权限难以收敛，当然我是没听他的建议。

Z-Image-Turbo，快就完事了

2025-11-30 21:48:04

最近比较火的，可以 NSFW, 模型默认生成美女 😂
如果你正在寻找一款高性能、轻量、可灵活集成的图片处理方案，那么 Z-Image-Turbo 绝对值得重点关注

简介

Z-Image 是由阿里云通义万相团队推出的一款高效文生图 AI 模型，其核心优势在于 Turbo 级的极致推理速度，能够在秒级时间内将文本描述转化为高质量图像，完美平衡了生成效率与画质表现，极大提升了 AI 创作的实时交互体验

主要优势

极致推理速度 (Turbo 级) 核心特点是快。通过深度模型优化或技术蒸馏，显著减少了推理步数，实现秒级图像生成，极大提升了创作的实时性和交互感
速度与质量兼备 在追求极致速度的同时，保持了高水准的图像生成质量。它在快速出图和细节、结构、光影表现之间取得了优秀的平衡，产出图片具备实用价值
原生中文语境理解 继承了通义大模型家族强大的语言能力，对中文提示词（Prompt）及中国文化元素有深刻的理解，能更准确地还原中文用户的创作意图
低门槛 对计算资源的消耗相对较低，降低了开发者的使用和部署门槛，利于集成到各类实时应用中
NSFW

体验地址

可能被人大量生成 NSFW，目前官方 demo 已经禁止，自建是没限制的

Tongyi-MAI/Z-Image-Turbo

其他

其实类似教程 L 站也有不少，有兴趣可以搜搜。

Ysicing | 缘生修改