所有文章

SeaweedFS 已经用docker compose的方式部署在生产环境内中了，对外只开放了一个S3的端口127.0.0.1:8333，然后前面套上Caddy的https代理，这样很安全了。 那进阶的要求又来了： 一、S3的pre signed的URL 由于程序之前是在AWS跑的，所以用了S3的最佳实践，pre sign url来进行上传和下载，那seaweedfs也是完全支持的，基本是无缝修改 给出验证程序： import boto3 from botocore.client import Config # Configure the S3 client to point to your SeaweedFS S3 gateway s3_client = boto3.client( 's3', endpoint_url='https://s3.rendoumi.com', # Replace with your SeaweedFS S3 gateway address aws_access_key_id='aaaaaaaa', aws_secret_access_key='bbbbbbb', config=Config(signature_version='s3v4') ) bucket_name = 'myfiles' object_key = 'your-object-key' expiration_seconds = 3600 # URL valid for 1 hour # Generate a pre-signed URL for uploading (PUT) try: upload_url = s3_client.generate_presigned_url( 'put_object', Params={'Bucket': bucket_name, 'Key': object_key, 'ContentType': 'application/octet-stream'}, ExpiresIn=expiration_seconds ) print(f"Pre-signed URL for upload: {upload_url}") except Exception as e: print(f"Error generating upload URL: {e}") # Generate a pre-signed URL for downloading (GET) try: download_url = s3_client.generate_presigned_url( 'get_object', Params={'Bucket': bucket_name, 'Key': object_key}, ExpiresIn=expiration_seconds ) print(f"Pre-signed URL for download: {download_url}") except Exception as e: print(f"Error generating download URL: {e}") 能看到临时生成的upload的URL和download的URL，是完美支持的 ...

最近狠折腾了一通postgres的备份，跟MySQL的阿里RDB恢复一样，如何不停止数据库服务，恢复某个表的数据到某个时间点，然后放到另一个表中呢？ 其实用之前的wal恢复一样的，就是要把当天实例的全备份和wal都复制到另外一台上，然后恢复，再把数据给dump下来，再建一个新表，把数据导回去。 Postgres的wal和PITR时间点恢复 用pgbackrest感觉会好一些，其实都差不多，步骤如下： 一、安装并配置pgbackrest apt install pgbackrest # 建立备份的大本营 mkdir -p /var/lib/pgbackrest chmod 750 /var/lib/pgbackrest chown postgres:postgres /var/lib/pgbackrest # 编辑 /etc/pgbackrest.conf [global] repo1-path=/var/lib/pgbackrest repo1-retention-full=26 repo1-retention-archive=180 log-level-file=info log-level-console=info [global:archive-push] compress-level=3 [main] pg1-path=/var/lib/postgresql/13/main pg1-port=5432 讲解一下参数 global里面是全局配置 repo1-path=/var/lib/pgbackrest # pgBackRest 存储库路径 repo1-retention-full=26 # 保留最近的 26 个全量备份，大概6个月，180天 repo1-retention-archive=180 # 保留最近 180 天的 WAL 日志 log-level-file=info # 文件日志级别 log-level-console=info # 控制台日志级别 global:archive-push 设置的是wal归档的保存方式是压缩保存 main部分设置的是要备份的postgres源的路径和端口，【main】是stanza的名字 上面的备份其实有三种备份，full和incr和wal备份，那如果full和增量都没了，只要wal还在，那么依然能恢复到180天之内的某个时间点。wal很占空间，full也很占空间，一定要算准了。 那其实pgbackrest是用postgres身份去执行命令的，所以不用认证身份。 二、配置postgres vi /etc/postgresql/13/main/postgresql.conf # wal归档方法： #archive_mode = on #archive_command = 'cp %p /data/backup/%f' # pgbackrest归档方法： archive_mode = on archive_command = 'pgbackrest --stanza=main archive-push %p' wal_level = replica #备份级别是副本 max_wal_senders = 3 #最多wal日志发到3个客户端去 # 需要重启postgres systemctl restart postgresql 三、测试pgbackrest的备份功能 # 建立一个stanza sudo -u postgres pgbackrest --stanza=main --log-level-console=info stanza-create # 检查 sudo -u postgres pgbackrest --stanza=main --log-level-console=info check # 查看信息 sudo -u postgres pgbackrest info ...

公司要做系统迁移，从AWS迁移到自建机房，那迁移的项目就一大堆，S3也在其中之列。 找来找去，第一首选的替代软件是minio，可是万恶的minio团队在这个时间点，已经后台移除了 admin 相关的操作权限 要想用呢，只能用个老版本的：quay.io/minio/minio:RELEASE.2025-04-22T22-12-26Z 那只能再找了，于是找到了SeaweedFS，这个软件其实是个彻头彻尾的单文件，但是分布式全集群架构 简单的说，就是一个软件，包含了10几种功能。 而我们呢，其实就要它的一个功能s3，而且要用于生产。网上一大堆的教程都是各种分布式的部署，如果机器足够，大家可以参考网上教程。 我们单台机器，硬盘底层是raid10，然后上层就只提供s3，而且要配置简单，没有什么安全问题，这台机器是直接暴露公网IP的。 那最简单的方法就是Docker compose，而且只放开s3的指定端口： services: seaweedfs-s3: image: chrislusf/seaweedfs container_name: seaweedfs-s3 volumes: - ./data:/data - ./config/config.json:/seaweedfs/config.json ports: - "127.0.0.1:8333:8333" # - "9333:9333" entrypoint: /bin/sh -c command: | "echo 'Starting SeaweedFS S3 server' && \ weed server -dir=/data -volume.max=120 -s3 -s3.config /seaweedfs/config.json" restart: unless-stopped 仔细解释上面的参数： ports 只开了 127.0.0.1:8333 的S3端口，其它都不开，如果需要查看服务状态，可以临时打开9333端口查看，看完再关 -volume.max=120，这个务必要注意，seaweed是分卷的，一个卷最多30G，缺省是8个卷。那缺省就是只有240G的容量，我们的硬盘是4T的，剩余3.7TB，那算下来，30*120=3600G=3.6T。这样就对准了，这个参数一定要根据生产的实际情况进行调整. 另外还把config.json的配置文件给mount入docker卷中了，配置文件里放的就是S3的IAM访问权限控制 详细看一下config.json { "identities": [ { "name": "admin", "credentials": [ { "accessKey": "aaa", "secretKey": "bbb" } ], "actions": [ "Admin", "Read", "List", "Tagging", "Write" ] }, { "name": "goods", "credentials": [ { "accessKey": "ccc", "secretKey": "ddd" } ], "actions": [ "Read:goods", "Write:goods", "List:goods", "Tagging:goods", "Admin:goods" ] } ] } 解释一下，上面定义了一个admin用户，可以对所有s3进行读写和管理。 ...

要在生产环境建一套Elasticsearch 8.0，单节点搭配Kibana，确实是困难重重，新版本需要TLS验证了 现在这个时间节点，2025年9月2日，Elasticsearch最新版本是9.0，后撤2个版本是8.18.6 那就用这个版本了，然后根据官方的文档会把人搞糊涂的。 正确的方法如下： 一、建立自签的证书 其实可以用ACME的证书，但是没有人会三个月就去重启一下ES的容器，更新证书吧！ 那只能选择自建CA，自签一个证书了！ 因为有2个pod，es和kibana，所以要签两张证书，签证书随便用ES的一个版本就可以： wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-8.4.1-linux-x86_64.tar.gz tar -zxf elasticsearch-8.4.1-linux-x86_64.tar.gz cd elasticsearch-8.4.1/ ./bin/elasticsearch-certutil ca --pem # 得到CA证书，放在当前目录ca目录下 unzip elastic-stack-ca.zip # 生成签发配置文件 cat << EOF >instances.yml instances: - name: es01 dns: - es01 - localhost ip: - 127.0.0.1 - name: kibana dns: - kibana - localhost ip: - 127.0.0.1 EOF # 签发2个pod的证书 ./bin/elasticsearch-certutil cert --ca-cert ca/ca.crt --ca-key ca/ca.key --pem --in instances.yml # 得到2张证书和key unzip certificate-bundle.zip # 生成两个目录，es01和kibana # 准备好证书目录 mkdir -p /data/elasticsearch/certs mv ca es01 kibana /data/elasticsearch/certs # 准备好持久化卷 mkdir -p /data/elasticsearch/kibanadata mkdir -p /data/elasticsearch/esdata01 二、配置docker-compose.yaml 8.18.6版本的docker-compose.yaml文件，位于：/data/elasticsearch/docker-compose.yaml ...

这还真是个大活，耗费了整整一天的时间。 究其原因根本就是无论AWS托管的Valkey还是社区的Redis.io，都是被魔改过的阉割版，真是无语他妈给无语开门，无语到家了！ 说一下详细的过程： 接到这个任务，首先想到的是同步软件redis-Gunyu https://github.com/mgtv-tech/redis-GunYu 结果是失败，原因很奇葩，因为aws valkey是必须带tls连接的，Gunyu不支持，放弃。 然后找到了redis-shake https://tair-opensource.github.io/RedisShake 结果还是失败，理由是不支持PSync，用了scan_reader也失败 然后就又想到了万能的ChatGPT和Google的Gemini，分别给了2个python程序，也是失败 原因是不支持Migrate命令，而且valkey是基于redis 7.2改的，而Redis.io是8.0，命令不兼容 走投无路之下想到了rdb-tools，先把valkey做个备份，放到S3桶里 valeky-20250819-0001.rdb valeky-20250819-0002.rdb valeky-20250819-0003.rdb valeky-20250819-0004.rdb valeky-20250819-0005.rdb valeky-20250819-config.json cat valeky-20250819-config.json { "valeky-20250819/valeky-20250819-0002.rdb" : { "Slots" : "0-5496", "rdbSize" : "5234516" }, "valeky-20250819/valeky-20250819-0004.rdb" : { "Slots" : "5497-8375", "rdbSize" : "4340658" }, "valeky-20250819/valeky-20250819-0003.rdb" : { "Slots" : "10082-16383", "rdbSize" : "5962581" }, "valeky-20250819/valeky-20250819-0001.rdb" : { "Slots" : "8376", "rdbSize" : "2218" }, "valeky-20250819/valeky-20250819-0005.rdb" : { "Slots" : "8377-10081", "rdbSize" : "1540505" } } 看起来是5个rdb备份，每个文件对应redis不同的slots 用rdb来解析备份文件，结果失败，因为不认识valkey rdb的版本。 没办法了，又找到了这个软件 https://github.com/HDT3213/rdb 下载后，首先想处理成json文件，然后灌入到redis.io ./rdb-linux-amd64 -c json -o 0001.json valeky-20250819-0001.rdb 失败，因为json文件灌入的时候redis.io又被阉割了，命令不支持 ...

由于ios的openvpn大陆地区无法安装，而员工又需要手机或PC登录VPN访问云上的资源，没办法，找了又找，终于，发现cisco的vpn还是能在苹果市场下载安装的，那就装个开源的Ocserv吧，别说还挺好，能分组控制路由的发布，非常不错 记录一下安装配置过程，使用Ubuntu 24.04的底版： apt update apt upgrade apt-cache show ocserv apt-get install -y ocserv ocserv --version 安装步骤就如上，非常简单，跟openvpn一样，配置文件就一个 /etc/ocserv/ocserv.conf, 编辑一下： # 认证方式为用户名密码认证 auth = "plain[passwd=/etc/ocserv/passwd]" # 开放端口 tcp-port = 443 udp-port = 443 # 证书 server-cert = /etc/ocserv/_.rendoumi.com.crt server-key = /etc/ocserv/_.rendoumi.com.key # 最多用户数 max-clients = 1024 # 绑定域名 default-domain = m.rendoumi.com # 分配的动态ip段 ipv4-network = 10.8.12.0 ipv4-netmask = 255.255.255.0 # 不路由 no-route = 10.0.0.0/255.0.0.0 no-route = 172.16.0.0/255.240.0.0 no-route = 192.168.0.0/255.255.0.0 # 发布路由 route = 10.8.2.15/32 route = 10.10.247.234/32 route = 10.10.240.37/32 说明：端口开在了443端口，证书用的是acme的免费证书，域名是m.rendoumi.com，ip段是10.8.12.0/24 ...

Vault的使用继续深入，通常情况下都是先拿到valut的root token，然后登录设置aws的认证，同时把aws的iam root凭据灌进去，然后write进行论转，这样凭据就只存在于vault之中了，没有泄露的可能。然后从这个root凭据再派生成各种使用时长有限制的临时凭据用。 但是，嘿嘿，我偏偏没有root凭据，因为我是外面管理员。只能用 federation_token 进行登录。 那怎么使用呢？方法如下： 首先在AWS的IAM建立两个policy # Federator 的policy，用于获得token { "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "sts:GetFederationToken", "Resource": "*" } ] } # Change-self-access-keys 的policy，用于轮转key { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "iam:ListUsers", "iam:GetAccountPasswordPolicy" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "iam:*AccessKey*", "iam:GetUser" ], "Resource": [ "arn:aws:iam::*:user/${aws:username}" ] } ] } 然后在Vault中设置使用AWS secrets vault secrets enable aws # aws中需要对应IAM的权限 # 要么是真有aws iam的用户；要么是有一个role，和对应的临时用户；二选一 vault write aws/config/root access_key=YYY \ secret_key=XXX region=us-east-1 \ sts_endpoint=https://sts.us-east-1.amazonaws.com sts_region=us-east-1 # 轮转root凭据，这样root凭据就只存在于vault中了 vault write -force aws/config/rotate-root 使用方法： ...

今天是2025年8月15日，大噩耗啊： external-secrets / external-secrets Link ⭐ 5416 | 🔀 1032 | Go 97.6% External Secrets Operator 项目暂停发布 由于维护团队规模过小，External Secrets Operator 决定暂停所有官方版本发布，直到重建足够的维护团队。 Key Takeaways 项目暂停所有官方版本发布，包括新功能、补丁和容器镜像。 将继续审核和合并社区的 PR，但不会提供 GitHub Discussions、Slack 或问题评论的支持。 需要至少五名长期维护者来确保项目的可持续发展。 鼓励依赖该项目的公司或团队积极参与贡献。 贡献者可通过填写表单或查看治理文档加入项目。 居然暂停发布了，那就抓紧时间把Vault跟它的集成记录下来： 一、首先必须在集群里安装Vault，然后安装external -secrets，都用helm装即可 helm repo add hashicorp https://helm.releases.hashicorp.com helm repo update helm install vault hashicorp/vault --set "server.dev.enabled=true" --set "injector.enabled=true" --namespace default helm repo add external-secrets https://charts.external-secrets.io helm repo update helm install external-secrets external-secrets/external-secrets --namespace external-secrets --create-namespace --set installCRDs=true 二、k8s授权，k8的授权体系就是 sa -> role -> rolebinding 那kubernetes会把pod中sa的Token注入到文件：/var/run/secrets/kubernetes.io/serviceaccount/token ...

这篇是一个大水贴，只是为了记录k3s的安装 这个东西被Rancher用得纯熟，先搭建一个k3s集群，然后再其上装控制软件，再去控制其它集群，非常好的想法，值得借鉴 安装和删除都非常简洁，准备工作： apt update && apt upgrade -y # 三台机器分别设置 hostnamectl set-hostname master hostnamectl set-hostname worker-1 hostnamectl set-hostname worker-2 # vi /etc/hosts 127.0.0.1 master # 两外两台也分别设置 127.0.0.1 worker-1 # 第3台 127.0.0.1 worker-2 准备工作都弄好了。下面安装 curl -sfL https://get.k3s.io | sh - systemctl status k3s cat /var/lib/rancher/k3s/server/node-token # 加入新节点 curl -sfL https://get.k3s.io | K3S_URL=https://192.168.0.200:6443 K3S_TOKEN=<your-token-here> INSTALL_K3S_EXEC="--node-ip=<worker-ip>" sh - 删除也就一句 /usr/local/bin/k3s-uninstall.sh 可以反复进行安装

欧拉 Page Cache 的内核编译 PageCache提供了一种限制page cache的能力，能够对page cache的总量进行控制, 增强系统在数据库等page cache占比较高场景下的稳定性，积极释放缓存。 它提供了以下sysctl接口： vm.pagecache_limit_ratio：pagecache占系统总内存的百分比，[0, 100]，0和100都表示功能关闭。 vm.pagecache_limit_reclaim_ratio：针对pagecache真实回收的比例，在实际回收时，总是比pagecache_limit_ratio的多回收一些，默认比例是2%。 vm.pagecache_limit_ignore_dirty：在回收时是否忽略脏页，默认忽略。因为对脏页的回收较耗时。 补丁是基于 openEuler-22.03-LTS 的，不适用于 24.03-LTS，代码都已不同了 编译过程如下： 一、安装好openEuler-22.03-LTS，磁盘留够空间，最少留20G 二、安装编译已经所需软件 dnf install -y rpm-build openssl-devel bc rsync gcc gcc-c++ flex bison m4 elfutils-libelf-devel dnf install -y python dnf install -y ncurses-devel dnf install -y dwarves 三、安装内核源代码 dnf install -y kernel-source 现在是2024年11月4日，内核版本是 linux-5.10.0-60.139.0.166.oe2203.x86_64，注意补丁的适用范围 四、打补丁 page.patch 将page.patch 放到 /usr/src cd /usr/src/linux-5.10.0-60.139.0.166.oe2203.x86_64 patch -p1 < ../page.patch 五、编辑内核版本号，EXTRAVERSION的版本号要大于当前内核版本，否则无法安装。当前是166，改成+1，167 cd /usr/src/linux-5.10.0-60.139.0.166.oe2203.x86_64 vi Makefile # SPDX-License-Identifier: GPL-2.0 VERSION = 5 PATCHLEVEL = 10 SUBLEVEL = 0 EXTRAVERSION = -60.139.0.167.oe2203.x86_64 NAME = Kleptomaniac Octopus OPENEULER_MAJOR = 2203 OPENEULER_MINOR = 0 六、编译 ...