Mental Studio

在K8s上部署Mastodon

Sun, 04 Jan 2026 21:54:21 +0800

准备工作

因为原来用于跑毛象的服务器（参见旧文《Docker下的Mastodon安装笔记》）到期停机了，正好手里有一个高配的arm免费机可以用，于是就打算把服务迁移过来——顺便试试部署到K8s上。

需要：

一台或多台服务器集群，内存至少4G，推荐8G，最好16G或更多，有外网IP，有一个域名
安装Kubernetes集群（可以使用k3s、minikube或云服务商的K8s服务，本文使用一个kubeadm安装的单节点k8s，见《在单机上用kubeadm安装K8s》）
一个SMTP服务——第三方或本地，这里用了第三方服务
创建必要的存储目录（根据实际节点名称调整路径，这里使用/var/data）
拉取Redis/Postgresql/ES/Mastodon镜像

crictl pull redis:7-alpine
crictl pull postgres:17-alpinie
crictl pull elasticsearch:7.10.1
crictl pull ghcr.io/mastodon/mastodon:v4.5.2
crictl pull ghcr.io/mastodon/mastodon-streaming:v4.5.2

配置存储

1. 创建命名空间

首先创建mastodon命名空间：

kubectl apply -f ns_mastodon.yml

ns_mastodon.yml

apiVersion: v1
kind: Namespace
metadata:
  name: mastodon

2. 配置Local PV/PVC（用于有状态服务）

我们使用local PV/PVC为PostgreSQL、Redis和Elasticsearch提供持久化存储：

Redis存储配置

# 创建Redis数据目录（在目标节点上）
sudo mkdir -p /var/data/redis/data
sudo chown 999:999 /var/data/redis/data

# 应用PV/PVC配置
kubectl apply -f local_redis.yml

local_redis.yml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: local-redis-data
  labels:
    type: local
spec:
  capacity:
    storage: 10Gi  # 总容量，根据实际需要调整
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-redis-data
  local:
    path: /var/data/redis/data
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - myserver  # 替换为实际节点名称
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: redis-data-pvc
  namespace: mastodon
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi  # 主数据存储大小
  storageClassName: local-redis-data
  selector:
    matchLabels:
      type: local

PostgreSQL存储配置

# 创建PostgreSQL数据目录（在目标节点上）
sudo mkdir -p /var/data/pgdata
sudo mkdir -p /var/data/pgbak
sudo chown 70:70 /var/data/pgdata /var/data/pgbak
sudo chmod 700 /var/data/pgdata

# 应用PV/PVC配置
kubectl apply -f local_posgresql.yml  # 内容参考redis，不过需要配置data和bak两个PV/PVC

Elasticsearch存储配置

# 创建Elasticsearch数据目录（在目标节点上）
sudo mkdir -p /var/data/elasticsearch
sudo chown 1000:1000 /var/data/elasticsearch

# 应用PV/PVC配置
kubectl apply -f local_elasticsearch.yml  # 内容参考redis

3. 配置NFS PV/PVC（用于Mastodon Public文件夹）

Mastodon需要共享存储来存储用户上传的媒体文件，因为需要同时给两个服务（web和streaming）使用，所以使用NFS PV/PVC：

# 创建NFS共享目录
sudo mkdir -p /var/data/mastodon
sudo chown 991:991 /var/data/mastodon

# 配置NFS服务器（如果尚未配置）
# 安装NFS服务器
sudo apt-get install nfs-kernel-server

# 配置NFS导出
echo "/var/data/mastodon *(rw,sync,no_subtree_check,no_root_squash,all_squash,anonuid=991,anongid=991)" | sudo tee -a /etc/exports
sudo exportfs -a  # 应用配置
sudo systemctl restart nfs-kernel-server
sudo exportfs -v  # 查看应用结果

# 应用NFS配置
kubectl apply -f nfs_mastodon.yml

nsf_mastodon.yml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-mastodon-data-web
  labels:
    type: nfs
spec:
  capacity:
    storage: 150Gi  # 总容量，根据实际需要调整
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs-mastodon-data-web
  nfs:
    server: 10.244.0.1  # flannel的IP
    path: /var/data/mastodon
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mastodon-data-web-pvc
  namespace: mastodon
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 150Gi  # 主数据存储大小
  storageClassName: nfs-mastodon-data-web
  selector:
    matchLabels:
      type: nfs
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-mastodon-data-sidekiq
  labels:
    type: nfs
spec:
  capacity:
    storage: 150Gi  # 总容量，根据实际需要调整
  volumeMode: Filesystem
  accessModes:
  - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  storageClassName: nfs-mastodon-data-sidekiq
  nfs:
    server: 10.244.0.1  # 连同一个NFS
    path: /var/data/mastodon
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mastodon-data-sidekiq-pvc
  namespace: mastodon
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 150Gi  # 主数据存储大小
  storageClassName: nfs-mastodon-data-sidekiq
  selector:
    matchLabels:
      type: nfs

部署有状态服务（Stateful Headless Services）

1. 部署Redis

创建Redis的StatefulSet配置：

kubectl apply -f svc_redis.yml

svc_redis.yml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
  namespace: mastodon
spec:
  serviceName: redis-headless  # 需要一个 Headless Service 管理网络标识
  replicas: 1
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:7-alpine
        ports:
        - containerPort: 6379
        volumeMounts:
        - name: redis-data
          mountPath: /data
        livenessProbe:
          exec:
            command: ["redis-cli", "ping"]
          initialDelaySeconds: 30
          periodSeconds: 10
        readinessProbe:
          exec:
            command: ["redis-cli", "ping"]
          initialDelaySeconds: 5
          periodSeconds: 10
      volumes:
      - name: redis-data
        persistentVolumeClaim:
          claimName: redis-data-pvc  # 直接使用现有 PVC
  volumeClaimTemplates: []
---
apiVersion: v1
kind: Service
metadata:
  name: redis-headless
  namespace: mastodon
spec:
  clusterIP: None  # Headless Service，直接解析到 Pod IP
  selector:
    app: redis
  ports:
  - port: 6379
    name: redis

2. 部署PostgreSQL

PostgreSQL使用StatefulSet和Headless Service：

kubectl apply -f svc_postgresql.yml  # 内容参考svc_redis.yml，不过要mount两个卷

3. 部署Elasticsearch

创建Elasticsearch的StatefulSet配置：

kubectl apply -f svc_elasticsearch.yml  # 内容参考svc_redis.yml

4. 验证部署

kubectl get statefulsets -n mastodon
kubectl get pods -n mastodon -l app=postgresql
kubectl get services -n mastodon | grep postgresql

配置Mastodon

1. 准备环境配置文件

编辑 env.production 文件，配置以下关键参数：

# Redis配置
REDIS_HOST=redis-headless.mastodon.svc.cluster.local
REDIS_PORT=6379

# 数据库配置
DB_HOST=postgresql-headless.mastodon.svc.cluster.local
DB_PORT=5432
DB_NAME=mastodon
DB_USER=mastodon
DB_PASS=你的数据库密码

# Elasticsearch配置
ES_ENABLED=true
ES_HOST=es-headless.mastodon.svc.cluster.local
ES_PORT=9200

# 域名配置
LOCAL_DOMAIN=你的域名

2. 创建Secret配置

将环境配置创建为Secret：

kubectl create secret generic mastodon-env --from-env-file=env.production -n mastodon

3. 部署Mastodon服务

注意：除非是全新安装的实例，否则此操作需要在数据库恢复后进行。

创建Mastodon的Deployment配置：

kubectl apply -f svc_mastodon.yml  # 类似svc_redis.yml，不过里面有三个服务：web,streaming,sidekiq

其中mastodon的web和streaming是以NodePort方式输出服务。

恢复数据库

1. 全库备份恢复方式

使用pg_dumpall备份全库再恢复到k8s里。

# 从源docker环境备份整个库
docker exec postgresql pg_dumpall -U postgres | gzip > pgoldbak.sql.gz
# 把备份传输到k8s环境
# 恢复数据
gunzip -c pgoldbak.sql.gz | kubectl exec postgresql -i -n mastodon --command -- psql -U postgres

2. 基于WAL的增量备份恢复方式

备份恢复方式参考《PostgreSQL的连续备份配置》

3. 启动实例

恢复数据库确认无误后即可启动毛象实例。

启动服务

所有服务启动后检查状态：

kubectl get all -n mastodon

如果所有Pod都处于Running状态，说明部署成功。如果有问题，则需要查看日志检查原因。

kubectl logs -f <podname> -nmastodon

配置Nginx反向代理

创建Nginx配置，将流量代理到Mastodon服务：

cat > nginx/mastodon.conf << EOF
upstream backend {
    server <NODE_IP>:3xxxx;  # 替换为节点IP和mastodon-web的NodePort
}

upstream streaming {
    server <NODE_IP>:3yyyy;  # 替换为节点IP和mastodon-streaming的NodePort
}

server {
    listen 80;
    server_name 你的域名;
    return 301 https://\$server_name\$request_uri;
}

server {
    listen 443 ssl http2;
    server_name 你的域名;

    ssl_certificate /etc/ssl/你的域名/fullchain.pem;
    ssl_certificate_key /etc/ssl/你的域名/privkey.pem;

    root /var/data/mastodon/public;
    
    location / {
        try_files \$uri @proxy;
    }

    location @proxy {
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
        proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto \$scheme;
        proxy_set_header Proxy "";
        proxy_pass_header Server;

        proxy_pass http://backend;
        proxy_buffering off;
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_set_header Upgrade \$http_upgrade;
        proxy_set_header Connection "upgrade";

        tcp_nodelay on;
    }

    location /api/v1/streaming/ {
        proxy_set_header Host \$host;
        proxy_set_header X-Real-IP \$remote_addr;
        proxy_set_header X-Forwarded-For \$proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto \$scheme;
        proxy_set_header Proxy "";

        proxy_pass http://streaming;
        proxy_buffering off;
        proxy_redirect off;
        proxy_http_version 1.1;
        proxy_set_header Upgrade \$http_upgrade;
        proxy_set_header Connection "upgrade";

        tcp_nodelay on;
    }
}
EOF

日常运维

1. 监控服务状态

# 查看所有资源状态
kubectl get all -n mastodon

# 查看Pod日志
kubectl logs -f deployment/mastodon-web -n mastodon
kubectl logs -f deployment/mastodon-streaming -n mastodon
kubectl logs -f deployment/mastodon-sidekiq -n mastodon

# 查看有状态服务日志
kubectl logs -f statefulset/postgresql -n mastodon
kubectl logs -f statefulset/redis -n mastodon
kubectl logs -f statefulset/elasticsearch -n mastodon

2. 定期清理

由于联邦宇宙中的内容会不断增加，需要定期清理过期数据，具体实现与之前docker方式部署一样，只是把docker命令改成相应的kubectl命令。

可以将这些清理任务添加到crontab中定期执行。

3. 备份与恢复

也可以参考前文实现，或者参考pgsql的wal备份那篇用备份wal的方式实现连续备份。

4. 升级Mastodon版本

升级Mastodon需要按顺序进行：

备份数据库
更新镜像版本
重新部署服务

# 更新镜像版本
sed -i 's|ghcr.io/mastodon/mastodon:v4.5.2|ghcr.io/mastodon/mastodon:新版本|g' svc_mastodon.yml
sed -i 's|ghcr.io/mastodon/mastodon-streaming:v4.5.2|ghcr.io/mastodon/mastodon-streaming:新版本|g' svc_mastodon.yml

# 重新部署
kubectl apply -f svc_mastodon.yml

K8s下的rollout升级：

# 不涉及数据库变更的小版本升级可以用rollout方式平稳升级：
kubectl set image deployment/mastodon-streaming streaming=ghcr.io/mastodon/mastodon-streaming:v4.5.4 -nmastodon
kubectl set image deployment/mastodon-sidekiq sidekiq=ghcr.io/mastodon/mastodon:v4.5.4 -nmastodon
kubectl set image deployment/mastodon-web mastodon-web=ghcr.io/mastodon/mastodon:v4.5.4 -nmastodon

kubectl rollout status deployment/mastodon-streaming -nmastodon
kubectl rollout status deployment/mastodon-sidekiq -nmastodon
kubectl rollout status deployment/mastodon-web -nmastodon

升级完成。

故障排除

1. Pod无法启动

检查Pod状态和日志：

kubectl describe pod <pod-name> -n mastodon
kubectl logs <pod-name> -n mastodon

常见问题：

存储卷挂载失败：检查PV/PVC状态 kubectl get pv,pvc -n mastodon
资源配置不足：检查资源限制 kubectl describe pod <pod-name> -n mastodon | grep -A 5 Resources
镜像拉取失败：检查镜像名称和标签

2. 服务无法访问

检查服务状态：

kubectl get services -n mastodon
kubectl describe service <service-name> -n mastodon

确保NodePort在正确范围内（30000-32767）。

3. 数据库连接问题

检查数据库服务：

# 测试数据库连接
kubectl run test-db-connection --rm -i --restart=Never \
  --image=postgres:17-alpine --namespace=mastodon -- \
  psql -h postgresql-headless.mastodon.svc.cluster.local -U postgres -c "\l"

4. 存储问题

检查存储状态：

kubectl get pv,pvc -n mastodon
kubectl describe pvc <pvc-name> -n mastodon

确保本地目录存在且有正确权限。

总结

本指南介绍了如何使用Kubernetes部署Mastodon实例，包括：

存储配置：使用local PV/PVC为有状态服务（PostgreSQL、Redis、Elasticsearch）提供持久化存储
网络配置：使用NFS PV/PVC为Mastodon public文件夹提供共享存储
服务部署：使用StatefulSet和Headless Service部署有状态服务，使用Deployment部署无状态服务
运维管理：包括监控、清理、备份、升级等日常运维操作

相比docker-compose部署方式，Kubernetes部署提供了更好的可扩展性、高可用性和运维便利性。可以根据实际需求调整资源配置和副本数量。

注意事项

安全性：生产环境需要配置更严格的安全策略，如Network Policies、Pod Security Policies等
性能：根据实际负载调整资源限制和副本数量
监控：建议配置Prometheus和Grafana进行监控
备份：定期备份数据库和重要数据
更新：关注Mastodon和安全更新，及时升级

如有问题，请参考Mastodon官方文档或Kubernetes官方文档。

推送到[go4pro.org]

将supervisor迁移到systemd

Sat, 20 Dec 2025 21:58:45 +0800

历史问题

在前systemd时代，要配置一个启动运行的服务还是比较麻烦的，所以才有了supervisor这种服务，但是现在systemd已经很成熟了，不再需要多此一举：

systemd启动supervisord，supervisord再来启动自定义服务

是时候把supervisor的服务迁移到systemd下了。

转换配置文件

首先是把/etc/supervisor/conf.d/下面的服务配置文件改成systemd格式的，然后放到/etc/systemd/system/下。

转换对照表如下：

Supervisor 指令	systemd 指令	说明
command	ExecStart	运行程序的完整路径和参数
directory	WorkingDirectory	程序运行的起始目录
user	User	运行该服务的用户
environment	Environment	环境变量设置
autostart	WantedBy=multi-user.target	是否随系统启动
autorestart	Restart=always	进程退出后是否自动重启
stdout_logfile	StandardOutput	标准输出（通常交给 journald）
stderr_logfile	StandardError	标准错误输出

一个典型的systemd服务单元配置如下：

[Unit]
Description=My Python Application
After=network.target

[Service]
# 基础配置
User=www-data
Group=www-data
WorkingDirectory=/var/www

# 环境变量 (注意语法：空格分隔或多次声明)
Environment=NODE_ENV=production
Environment=PORT=8080

# 启动命令 (必须使用绝对路径)
ExecStart=/usr/bin/python3 /var/www/app.py

# 重启策略
Restart=always
# 启动失败后的等待时间（可选）
RestartSec=5

# 日志处理：默认会发送到 journald
StandardOutput=append:/var/log/my-app.out.log
StandardError=inherit

[Install]
# 允许随系统启动
WantedBy=multi-user.target

管理systemd服务

常用的命令如下：

# 新增或修改配置文件以后需要重新加载，类似 supervisorctl reread && supervisorctl update，或者更粗暴的supervisorctl reload
systemctl daemon-reload
# 查看服务状态
systemctl status [yourservice]
# 设置服务开机自启动
systemctl enable [yourservice]
# 加上--now选项可以在设置后立即启动服务，同理用disable命令可以禁用开机自启动
# 手工启动服务
systemctl start [yourservice]

推送到[go4pro.org]

Linuxmint中蓝牙配对问题的处理

Sat, 08 Nov 2025 17:35:07 +0800

起因

最近常用的这个Linuxmint系统忽然无法添加蓝牙设备了，表现为可以搜索到要添加的设备，但是点击添加后，显示正在连接，很长时间连不上，然后就报错了。有时也可以连接上，但是无法使用，一会之后又断开了。

问AI半天也没有解决方案，什么重启蓝牙服务，重装蓝牙管理器之类的方法都试过了，没一个管用的。甚至还试了改polkit权限配置、重新加载蓝牙内核模块之类的方法，也没用。

解决

自己试了半天后发现问题出在无法弹出配对确认框上，但是这个问题始终没有找到解决方案，最后只能通过手工配对的方式来解决：

# 进入命令行状态：
bluetoothctl
# 在交互界面操作：
power on
agent on
scan on
# 现在开始扫描周围的蓝牙设备，记录一下要添加的设备MAC
# 配对设备
pair <设备MAC>
# 信任设备（就是弹框需要做的操作）
trust <设备MAC>
# 连接设备
connect <设备MAC>

这样配对好以后就可以正常使用蓝牙设备了。

推送到[go4pro.org]

Ansible贴士二则

Sun, 12 Oct 2025 15:22:55 +0800

避免主机SSH指纹确认

通常在第一次用SSH连接一台远程主机的时候，都会弹出一个SSH指纹警告，需要人工确认后，把这个指纹加到本地.ssh/knwon_hosts文件中。以后要是同一远程主机的指纹变化了（比如被冒充），就会导致SSH报错后断开连接，除非你能确认这种变化，那就需要从known_hosts里把原来的指纹删除：

ssh-keygen -R remote_host:port

然后再次连接并确认记录新指纹。

手工单次连接时顺手确认一下没什么问题，但是用Ansible连接实际上也是走ssh，也要验证指纹，所以也会有这个交互过程。

但这就麻烦了，因为通常用Ansible跑playbook时都是需要处理一堆主机的，每个都这样人工确认就太麻烦了，所以更好的办法是先批量更新一下known_hosts：

# 主机地址列表
HOSTS=(xxx yyy zzz)

for h in "${HOSTS[@]}"
do
    ssh-keyscan -p 22 $h >> ~/.ssh/knwon_hosts
done

使用指定的key连接

通常用ssh连接时，可以通过-i参数指定key文件，比如：

ssh -i /path_to/your_key_file user@host

Ansible里也可以指定，使用ansible_ssh_private_key_file变量：

ansible_ssh_private_key_file: /path_to/your_key_file

外一则

之前在Ansible中创建用户用的生成密码命令：

python3 -c "import crypt; print(crypt.crypt('{{ plain_password }}'))"

现在会报一个警告：

DeprecationWarning: 'crypt' is deprecated and slated for removal in Python 3.13

从Python3.13开始要移除crypt模块了，所以需要换个方式。

一个方式是使用passlib模块：

python3 -c "from passlib.hash import sha512_crypt; print(sha512_crypt.hash('your_password'))"

不过更好的方法是使用Ansible内置的过滤器：

- name: 创建用户
  hosts: all
  vars:
    plain_password: "your_password"
  
  tasks:
    - name: 创建用户（使用过滤器生成哈希）
      user:
        name: youruser
        password: "{{ plain_password | password_hash('sha512') }}"
        state: present
      no_log: true

推送到[go4pro.org]

基于wstunnel的反向隧道配置

Sat, 06 Sep 2025 15:19:00 +0800

需求

因为家里一条宽带换成移动的，没有外网IP了，所以从外面接入不太方便，IPv6虽然也是个方案，但是内网那台arm小机器是很老的Debian7，没有驱动也升级不了系统，还是搞个隧道简单点。

之前《使用docker和wstun实现隧道和反向隧道》，但是这个用Node.js实现的太笨重了，而且debian7上也装不了docker。还好现在有新方案，就是这个用Rust实现的wstunnel。一个可执行文件轻松跑起，还支持32位arm linux。

简单起见这里不再说正向隧道的配置了，参考前文，换成wstunnel即可。下面只说反向隧道的。

服务端

直接运行是最简单的：

wstunnel server ws://[::]:8080

但是这样有个安全风险就是只要能连接到这个websocket服务端就可以任意映射端口，等于绕过了防火墙的检查。

虽然官方建议是可以加上https和随机的path-prefix加以防护，但我觉得还是直接包进docker里更保险一点。

用Rust的好处之一就是这是独立可执行文件，没有依赖，直接用一个最小系统镜像（如alpine:3.22）就能运行：

docker run -d --name wstunnel -v $HOME/opt:/root/opt -p 127.0.0.1:8080:8080 -p 0.0.0.0:8022:8022 alpine:3.22 /root/opt/wstunnel server ws://[::]:8080

这个命令的功能就是用alpine:3.22的镜像来运行wstunnel（放在$HOME/opt下），把websocket端口8080映射到本地，把反向隧道的端口8022映射到外网。这样即使有其它的客户端想到映射别的端口，或者映射服务器的端口都无法实现，因为都是在docker容器里面。

当然为了保险起见，可以继续叠加官方的安全手段。

客户端

因为无法运行docker，就只能直接运行了：

wstunnel client -R 'tcp://[::]:8022:127.0.0.1:22' ws://server:8080

为了保持运行，我实际上是用supervisor加持了一下。

远程的地址实际上也不是这个，而是用https代理过的。

服务端https代理配置

也是使用Nginx的反向代理，如前文：

# 在http段加上全局配置
map $http_upgrade $connection_upgrade {
    default upgrade;
    '' close;
}
# 在server段加上代理配置
    location / {
        proxy_pass http://127.0.0.1:8080;
        
        # 启用WebSocket支持的关键配置
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

        # 保持连接和代理头信息
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

        # 设置较长的超时时间以保持持久连接
        proxy_read_timeout 86400;
        proxy_send_timeout 86400;
        keepalive_timeout 86400;
    }

这样配置以后，只要服务端和客户端保持运行，就可以通过服务端的8022端口连接到客户机的22。

推送到[go4pro.org]

在CentOS8.5上使用docker-compose

Sat, 02 Aug 2025 15:13:17 +0800

起因

说过很多次，我非常不喜欢CentOS，想用RedHat系就掏钱去用RHEL，不然就老老实实Debian之类。然而却不得不经常要面对别人装的CentOS。

这回就是这样，需要在一个别人装的CentOS8.5上装docker-compose。

安装docker

CentOS早就停止支持这事大家都知道了吧，当然旧版还是有archive源可以用的，我就用了一个阿里云的archive源来安装。

先备份原来的源配置，然后换成阿里，再安装：

cp /etc/yum.repos.d/epel.repo /etc/yum.repos.d/epel.repo.backup
cp /etc/yum.repos.d/epel-modular.repo /etc/yum.repos.d/epel-modular.repo.backup
# 下载并替换epel配置
wget -O /etc/yum.repos.d/epel.repo https://mirrors.aliyun.com/repo/epel-archive-8.repo
# 然后更新一下
yum update
# 因为RH系不提供docker，而是使用podman，所以只能安装兼容的podman-docker
yum install podman-docker

安装docker-compose

虽然这事已经是陈年往事了，但还是说明一下：因为docker是带有一个docker服务的，这点被嫌弃很多年，所以后来出了一些不需要服务的容器方案，比如containerd和podman。K8s也已经完全抛弃了docker。

但用这些方案带来的问题就是有些docker的功能不支持，比如docker-compose。

为了提供类似的功能，也有一些部分解决方案，比如现在我们要用的。

首先是配置podman.socket以提供一个docker服务兼容接口：

# 启用podman.socket服务
systemctl enable --now  podman.socket
systemctl status podman.socket
# 配置环境变量供docker-compose使用
export DOCKER_HOST=unix:///run/podman/podman.sock
# 也可以配置到.bashrc里

然后安装一下docker-compose：

# 先升级一下可能需要的依赖
pip3 install --user -U pip
pip3 install --user -U wheel
pip3 install --user -U setuptools
pip3 install --user -U setuptools_rust
# 安装docker-compose
pip3 install --user docker-compose

现在就可以正常使用docker-compose了：

~/.local/bin/docker-compose up -d

但是有些功能还是不能用的，比如docker-compose build，这种就只能先用podman把镜像先build好再用docker-compose了。

podman build -t your_image .

至少是能用了。

推送到[go4pro.org]

用uv代替pip和venv

Sat, 26 Jul 2025 11:17:09 +0800

为什么要换

python的环境管理用过很多了，从最早的virtualenv到后来封装后的virtualenvwraper再到现在用的自带的venv，确实是越来越好用的。不过最近这个用rust写的uv似乎比较红，群里的MK和95也推荐，所以我也来试试。

安装

MK说只要pip install uv就可以了，但是在我的mint上似乎没这么简单。

首先是现在不允许直接安装系统python包了，怕破坏依赖关系，虽然可以加参数强制安装，但毕竟有风险。这种情况我通常是去apt里找一个类似：python3-uv这样的包来装，但不幸的是mint里还没有。

只好退而用另一个替代方案：

sudo apt install pipx
pipx install uv  # 官方源如果太慢，可以用-i参数使用国内镜像源
# 安装路径在$HOME/.local/bin，记得加到PATH里

使用

使用方法类似venv，只是需要前面加上uv命令。

uv venv # 在当前路径下创建.venv的虚拟环境，如果不想用.venv，可以在后面指定名字
. .venv/bin/activate # 切换到虚拟环境
uv pip install -r requirements.txt # 也可以用-i使用国内镜像源，不过uv不支持在requirements.txt里用--index指定源

安装速度真的是比pip高不知道哪里去……

需要注意的是，uv pip并不会使用默认的~/.pip/pip.conf里的配置，而是有自己的配置文件：~/.config/uv/uv.toml，所以如果想要指定默认镜像，还得加到这个配置文件里，比如：

# ~/.config/uv/uv.toml

index-url = "https://mirrors.aliyun.com/pypi/simple/"

虚拟环境

需要注意的是，在pip中，可以在不切换到虚拟环境的情况，直接使用类似.venv/bin/pip命令来直接管理虚拟环境里的包。这个功能在docker构建的时候特别好用。但是uv不行，不论是否在虚拟环境里，运行的uv命令都是在~/.local/bin下的，所以如果想在不切换到虚拟环境的情况下进行虚拟环境里的包管理则需要通过两种方式：

一种是在虚拟环境里安装一个uv，然后使用这个uv。另一种是指定使用虚拟环境里的python。

安装uv法：

. .venv/bin/activate # 切换到虚拟环境
uv pip install uv  # 在虚拟环境里安装uv
deactivate # 退出虚拟环境
.venv/bin/uv pip install -r requirements.txt  # 在虚拟环境里安装依赖

指定python法：

~/.local/bin/uv pip install -p .venv/bin/python -r requirements.txt  # 在.venv虚拟环境里安装依赖

个人推荐后者，因为比较简洁。

其实根本问题就是uv创建虚拟环境的时候没有默认在环境里装一个uv，但pip的虚拟环境里默认是有pip的。

推送到[go4pro.org]

DBeaver的数据库连接保持配置

Sat, 21 Jun 2025 11:09:33 +0800

问题

因为需要管理mysql和postgresql，所以我通常使用DBeaver（CE版）来管理，但是它有个问题就是一会不操作，数据库连接就会断开并且操作卡死，需要退出应用再重新运行才行，相当麻烦，所以前几年我在Mac下连mysql还是经常用Sequel Pro（后来的Ace）。

这几年改用Linux以后，就完全用DBeaver了，虽然中间也研究过一些配置，但也并不总是管用，想想还是把这些设置都记录一下，慢慢总结看看到底哪些方法是管用的。

全局配置

首先打开DBeaver的系统设置，找到全局设置（在菜单的“窗口”-“首选项”），将“连接”下的“错误和超时”设置中的“执行错误”-“自动重连次数”改大一点，比如3次，增加连接成功率。

数据库连接配置

然后在具体的数据库连接的“编辑连接”中的“连接设置”-“驱动属性”里修改以下几项（根据数据库不同可能有所不同）：

autoReconnect=True
connectionTimeout=3600
tcpKeepAlive=True

SSH隧道连接配置

如果通过SSH隧道连接，还需要再修改SSH里的“高级”：

修改“长连接时间间隔”，我一般用30秒，因为这里单位是毫秒，所以填：30000。

这项用于每30秒与SSH服务端通信一下，保持SSH连接。

经过以上几荐修改后，数据库连接可以较为稳定，正常情况下都不会断连，即使因为网络中断而断连后，重连也很正常，不像之前会重连卡死或反复重连失败。

推送到[go4pro.org]

用Alembic进行数据库版本管理

Sun, 25 May 2025 10:41:02 +0800

序

用SQLAlchemy进行数据库开发是很方便，特别是它有强大的ORM，只要在model里把数据库模型定义好，直接初始化一下就行了。

但是实际的开发不可能一开始就把数据库定义得这么完善，另外，也有时会碰到先有数据库再进行开发的情况，这时就比较麻烦了。

所以需要有工具支持。

Alembic就是一个配合SQLAlchemy的数据库管理工具。

在介绍Alembic之前，先来看看已经有数据库时要怎么办。

已有数据库

如果你之前已经用过SQLAlchemy，更常见的情况是实际的数据库经过一段时间的修改已经与早期定义的models不一致。不论是之前已有数据库，还没创建models，还是已有models，但与数据库不一致，都可以如下处理。

这就需要另外一个工具：sqlacodegen。安装的话就是一句PIP的事情：

pip install sqlacodegen

然后用命令（以Mysql为例，pg的话就用psycopg2）：

sqlacodegen mysql+pymysql://user:pass@localhost:3306/dbname --outfile db/models.py

即可从数据库生成一个SQLAlchemy的models定义文件。有了这个保持一致的models才好用alembic来管理。

初始化

安装就不说了，也是一句PIP的事情。

然后在项目路径下执行：

alembic init alembic

会创建几个文件和目录：alembic.ini，alembic目录及其下面的env.py, README, script.py.mako和versions目录。

最简单的用法就是在alembic.ini里找到sqlalchemy.url参数，改为当前开发环境的数据库连接。然后修改alembic/env.py：

from db.models import Base  # 从你的sqlalchemy的models定义中导入Base

# ...

target_metadata = Base.metadata  # 把原来默认的None改为你的Base.metadata，以便alembic可以找到你的数据库模型定义

然后执行：

alembic revision --autogenerate -m "init"

即可以versions目录下生成一个版本文件。

如果数据库不存在，则这个版本可以作为初始化的建库基础。如果数据库已存在，那models一定要与现在的数据库保持一致，最好是用sqlacodegen从数据库重新生成一个models。

然后运行：

alembic upgrade head

如果数据库是新的空库，这个操作就会根据models的定义创建一个数据库结构。如果数据库已存在并且与models定义一致，即可将开发环境的数据库的alembic版本标记为当前版本，以便后续变更。

之后部署到正式环境，只需要配置好正式环境的数据库链接，然后运行alembic upgrade head，即可创建一个和开发环境一致的数据库。

版本升级

随着开发工作的进行，数据库肯定也会变更，这个时候要注意，不要直接在开发数据库上变更，所有的变更都要在sqlalchemy的models上进行。在更新了models以后，执行：

alembic revision --autogenerate -m "new feature"

生成一个new feature的alembic新版本记录。同样在生成以后alembic upgrade head更新一下开发环境的数据库版本。这样数据库就与models一致了，可以继续进行开发。

部署到正式环境后，同样执行一下alembic upgrade head，即可将正式环境数据库更新到和开发环境一致，这时再部署代码运行就不会有数据库不一致的问题了。

关于配置

修改alembic.ini里的数据库链接固然方便，但是不便于与生产环境同步，所以最好还是动态读取实际的配置。

假设配置信息放在一个单独的配置文件config.py里，生产环境和开发环境用的配置文件是不一样的，代码里通过一个Config类去读取，类似这样：

class Config:
    config: dict = load_config()  # 从配置文件里读取配置
    DB_URL: str = config.get("DB_URL")  # 读取数据库配置
    
settings = Config()

那么我们现在就可以来修改alembic的配置，让它去读取实际的配置，而不是写死在alembbic.ini里，这样不论是在开发环境还是在生产环境运行alembic，使用的都是正确的数据库配置。

首先修改alembic.ini，把sqlalchemy.url一项注释掉，然后修改alembic/env.py，让它改为读取项目配置，而不是alembic.ini：

# 导入配置
from config import settings

# ...

# 修改run_migrations_offline函数
def run_migrations_offline() -> None:
    # url = config.get_main_option("sqlalchemy.url")  # 注释掉原来读取alembic.ini的语句
    url = settings.DB_URI  # 改为读取项目配置
    
    # ...
    
# ...

# 修改run_migrations_online函数
def run_migrations_online() -> None:
    # 读取项目配置并设置到alembic的sqlalchemy配置里
    url = settings.DB_URI
    config.set_main_option("sqlalchemy.url", url)
    
    connectable = engine_from_config(
        config.get_section(config.config_ini_section, {}),
        prefix="sqlalchemy.",
        poolclass=pool.NullPool,
    )

    # ...
    
#...

这样就可以方便地在开发环境和生产环境之间同步了。

记得每次开发环境有修改过数据库模型，就创建一个alembic版本。

——注意，只能在models.py里修改，不得直接修改数据库

提交代码的时候把alembic版本一起提交上去，在正式环境上部署时同样要把变更的alembic版本更新下来，然后运行alembic upgrade head同步生产环境的数据库结构，这样就能保持一致了。

推送到[go4pro.org]

在单机上用kubeadm安装K8s

Sat, 12 Apr 2025 12:52:44 +0800

起因

最近（其实已经好几个月了）搞了一台配置比较高的机器，想用来跑多一些应用，当然直接用docker也不是不行，或者加上portainer，但还是觉得k8s更好玩一些。

因为之前是按照常规的组集群的方式安装的，这回只有单机，又不想用minikube之类的，所以还是按kubeadm的方式来装。加上新版本有一些变化，就懒得再去改旧文，还是重新水一篇吧。

基本的系统环境是：3C19G的ARM平台，系统是ubuntu 24.04LTS

基本安装

首先，新版的k8s已经不再使用docker，改用其它容器实现方案，我这边选择的是containerd。操作接近原来的docker，大部分情况下把docker命令换成crictl即可。

Ansible剧本

用的还是之前那个剧本，稍作修改，比如docker代理不需要了，因为服务器本身在国外。

---
- name: Install packages
  apt:
    pkg:
      - arptables
      - ebtables
      - containerd
    update_cache: no
    install_recommends: no
    autoremove: yes
    autoclean: yes

- name: Update alternatives
  alternatives:
    name: "{{ item.name }}"
    path: "{{ item.path }}"
  with_items:
    - { name: 'iptables', path: '/usr/sbin/iptables-legacy' }
    - { name: 'ip6tables', path: '/usr/sbin/ip6tables-legacy' }
    - { name: 'arptables', path: '/usr/sbin/arptables-legacy' }
    - { name: 'ebtables', path: '/usr/sbin/ebtables-legacy' }

- name: Turn off swap
  command: swapoff -a
  
- name: Turn off swap forever
  lineinfile:
    path: /etc/fstab
    regexp: "^([^#].*none\\s+swap\\s+sw.*)$"
    line: "#\\g<1>"
    backrefs: yes

- name: Ensure directory for apt keyrings exists
  ansible.builtin.file:
    path: /etc/apt/keyrings
    state: directory
    mode: '0755'

- name: Download Kubernetes GPG key
  ansible.builtin.get_url:
    url: https://pkgs.k8s.io/core:/stable:/v1.32/deb/Release.key
    dest: /tmp/kubernetes-key.gpg
    mode: '0644'
    force: no  # 幂等性

- name: Convert and install the key
  community.gpg.gpg_convert:
    executable: gpg
    key: /tmp/kubernetes-key.gpg
    keyring: /etc/apt/keyrings/kubernetes-apt-keyring.gpg
    state: present

- name: Clean up temporary key file
  ansible.builtin.file:
    path: /tmp/kubernetes-key.gpg
    state: absent

- name: Add repository of kubernetes
  apt_repository:
    repo: "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.32/deb/ /"
    state: presen

- name: Actually install kubernetes
  apt:
    pkg:
      - kubelet
      - kubeadm
      - kubectl
    state: latest
    update_cache: yes
    install_recommends: no

- name: Hold kubernetes version
  dpkg_selections:
    name: "{{ item.name }}"
    selection: hold
  with_items:
    - { name: 'kubelet' }
    - { name: 'kubeadm' }
    - { name: 'kubectl' }

- name: Get kubernetes images
  shell: kubeadm config images pull

安装后配置

以下都是在root用户下操作，故略去sudo。

配置containerd和kubelet

先检查安装是否成功：

kubectl cluster-info

然后确保containerd和kubelet服务已经正常启动

systemctl status containerd
systemctl status kubelet

检查containerd的配置文件，启用systemd的cgroup：

# 如无则创建containerd配置文件，如有则略过
sudo mkdir -p /etc/containerd
containerd config default | tee /etc/containerd/config.toml > /dev/null
# 编辑配置文件，找到 [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] 部分
# 将 SystemdCgroup = false 修改为 SystemdCgroup = true
sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
# 重启 containerd
systemctl restart containerd

配置modules-load和sysctl参数：

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# 设置所需的 sysctl 参数，这些参数在重启后仍然有效
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF

# 应用 sysctl 参数设置，无需重启
sudo sysctl --system

初始化Control Plane

开始安装Control Plane

kubeadm init --pod-network-cidr 10.244.0.0/16 --apiserver-advertise-address=10.0.0.123 --kubernetes-version=v1.32.2

其中的pod-network-cidr是Flannel的网段，如果使用不同的网络插件，要就指定不同的网段。

apiserver-advertise-address是服务器的地址，不指定的话可能会导致服务启动失败。

kubernetes-version是指定k8s的版本，以确保版本正确。

初始化完成后返回这么一段内容：

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

  kubeadm join <control-plane-host>:<control-plane-port> --token <token> --discovery-token-ca-cert-hash sha256:<hash>

其中包含几个重要信息：

第一：如果要用非root用户操作kubectl，则需要在用户目录下创建.kube/config

第二：如果要在集群里部署应用，则使用kubectl apply命令

第三：如果有其它节点要加入这个集群，则使用kubeadm join命令，参数中的token和hash要注意安全保存，如果忘记记录token，可以用kubeadm token list查看

第四：token的有效期只有24小时，过期后需要重新创建kubeadm token create

初始化完成后可以看看当前的状态：

kubectl get nodes
kubectl get pods -A

正常情况下是刚开始的状态为Ready但很快变成NotReady，因为还没有安装Flannel网络。

安装网络

还是安装常用的Flannel，路径与原来有所不同：

kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

现在再查看状态应该就是Ready了。

将control plane作为worker node

默认情况下control plane不作为worker node，所以k8s集群至少需要2台机器，但实际上也可以用一台机器跑，那就是将control plane也同时配置为worker node。

首先查看一下control plane节点的污点状态：

kubectl describe node <control-plane-node-name> | grep Taint

可以看到类似‘NoSchedule’这样的污点，表示不能在这里调试普通pod。将其移除：

kubectl taint nodes <control-plane-node-name> node-role.kubernetes.io/control-plane:NoSchedule-

之后就可以在这个节点上部署pod了。

推送到[go4pro.org]