标签 GitOps 下的文章

前言

之前薅了某为云的 2c2g 鸡,一直吃着灰,反观我的另一台 1c1g 鸡跑了好几个服务,是时候迁移了,顺便也来试试传说中的 GitOps,做个步骤记录,欢迎佬们提提建议

迁移

首先在所有鸡上都安装上 docker

随后先是 Portainer 的迁移。

  1. 在旧机器上:

    • 登录 Portainer Web 界面。

    • 进入 SettingsBackup

    • 选择 Download backup file

    • 设置个密码(可选),点击 Download。你会得到一个 .tar.gz 文件。

  2. 在新机器上:

    • ssh 上去,拉起一个新的、空的 Portainer。

    • 第一次访问登录页面时,不要创建新管理员,点击下方的 Restore from file

    • 上传刚才下载的备份文件,然后配置都回来了

然后是 docker 的容器部分。首先确认卷名,找到你真正需要的数据卷

docker volume ls # 找到后停掉
docker stop <容器ID>

打包

sudo -i
# 进入 Docker 卷目录 cd /var/lib/docker/volumes/ 
# 把你需要迁移的卷打包
tar -czvf /root/migration.tar.gz gpt_load-data newapi-data sub-store_data
# 直接 scp 扔过去 # 这里我尝试了 Termius 的 SFTP,估计是走本机中转,速度只有几十 k
scp /root/migration.tar.gz root@<IP>:/var/lib/docker/volumes/
# 在另一台机子上 sudo -i
cd /var/lib/docker/volumes/
tar -xzvf migration.tar.gz
# 让 docker 认出来
docker volume create gpt_load-data 
docker volume create newapi-data 
docker volume create sub-store_data

仓库配置

你需要把你的所有 docker-compose 文件组织起来,初始化 Git 仓库里并上传,这里以上传到 GitHub 为例。

文件结构仅供参考:

│  renovate.json
│          
├─ai
│      docker-compose.yml
│      
├─cloudflare-imgbed
│      docker-compose.yml
│      wrangler.toml
│      
├─network
│  │  docker-compose.yml
│  │  
│  ├─conf
│  │      Caddyfile
│  │      
│  └─site
├─nezha-dashboard
│      docker-compose.yml
│      
├─portainer
│      docker-compose.yml
│      
└─sub-store
        docker-compose.yml

接下来所有的容器相关操作都来到 Portainer 里面进行。

Portainer 配置

去 Portainer 创建 stack,Build method 选择到仓库类型,照着填就行

注意,如果你的 compose 文件里还依赖于仓库里的其他文件,比如 .env,那么得把下图中最下面的 Enable relative path volumes 勾上,Portainer 会从你填写的目录里把你的整个仓库拉下来再执行 compose 命令。

Re-pull image 这里我没有测试未勾选的效果,Force redeployment 的效果是每次 Webhook 触发时都会让容器重新部署,我这里没有勾选。

然后我们来到 GitHub 仓库里,填入对应 Webhook 地址,Payload URL 填 Portainer 给的, Content type 两种都可以。

完成后点 Update 就可以了。如果你之前给 Portainer 配置过 ZeroTrust,测试不通可能是 cf 那里没有配置 bypass 策略,得加个策略放行一下。

Note

如果后续要给 Portainer 配置多节点,记得在 cf 那里还要放行一个 api/endpoints

不出意外的话就可以了。

一些可能的报错

ErrorFailureCould not get the contents of the file '**/docker-compose.yml
检查 compose 文件是否有误,比如是否写了正确的镜像名

Renovate 配置

现在我们只是实现了代码即基础设施,上了一辆定制的电动车,但是不踩油门不动,每个镜像都要手动改镜像版本再 git push,太麻烦了。接下来我们将引入Renovate 机器人,实现自动更新镜像。

Warning

我也没用过 WatchTower,几种方法也没有孰好孰坏之分,这里不展开讨论

首先我们来把机器人安装到我们的仓库里,直达链接。添加到新仓库后会跳转到新页面来配置。这里没有许可证,选第二个免费版。

下一步,选择 Scan and Alert,这样子就会自动提 PR 了。

配置完成会跳转到个人主页,这里还能看到对应仓库的每一次触发日志

等一会仓库会自动收到一条来自机器人的 PR,类似于下图:

这条 PR 里会列出你的所有 compose 文件以及更新提示,可以直接 Merge,也可以顺手直接用下面配置覆盖。合并之后会多出一个 Dependency Dashboard 的 issue,可以在这里进行快速操作。

关于 renovate 的配置,建议仔细阅读一遍官方文档,这里放几个可能会用到的

两条路

这里我让 Gemini 和 Claude 改了 2 份 renovate.json,第一份让机器人来管理合并的事,挂了快一周,实测小版本更新自动 commit 没有问题;第二份中 "platformAutomerge" 不填,默认为 true,托管给 GitHub 来管理自动合并。但是 GitHub 私人仓库的 AutoMerge 功能只对 Pro 用户开放,而且我死活调不出来,一个 PR 挂在那里一天了都没有触发自动合并,等一位大佬来帮我看看

作用是上游镜像推了个小更新,就自动 commit 掉,大版本更新提 PR 手动批准

可用配置

{ "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": [ "config:recommended" ], "timezone": "Asia/Shanghai", "schedule": ["at any time"], "platformAutomerge": false, "automergeSchedule": ["at any time"], "ignoreTests": true, "packageRules": [ { "matchDatasources": ["docker"], "matchUpdateTypes": ["minor", "patch", "digest"], "automerge": true, "automergeType": "branch", "groupName": "all non-major docker updates" }, { "matchDatasources": ["docker"], "matchUpdateTypes": ["major"], "automerge": false, "addLabels": ["major-update-warning"] } ] } 

[未成功] GitHub Pro 用户配置

需要打开仓库设置里的 Allow auto-merge

在我这里未生效,仅供参考

{ "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": [ "config:recommended" ], "timezone": "Asia/Shanghai", "schedule": ["at any time"], "packageRules": [ { "matchDatasources": ["docker"], "matchUpdateTypes": ["minor", "patch", "digest"], "automerge": true, "groupName": "all non-major docker updates" }, { "matchDatasources": ["docker"], "matchUpdateTypes": ["major"], "automerge": false, "addLabels": ["major-update-warning"] } ] } 

后记

修改完文件记得跑一下下方的检查命令:

npx --yes --package renovate -- renovate-config-validator renovate.json 

实测 bunx 不可用:

"err": { "code": "MODULE_NOT_FOUND", 

如果忘了也没关系,机器人会在 issue 里报错

要是没啥问题,机器人就能自动干活了:


📌 转载信息
转载时间:
2026/1/14 10:58:07

亚马逊云科技推出了Amazon EKS Capabilities,这是一套完全托管的、Kubernetes 原生特性,旨在简化工作负载编排、AWS 云资源管理以及 Kubernetes 资源组合和自动化。这些能力现在已在大多数 AWS 商业区域普遍可用,它将流行的开源工具捆绑到一个托管的平台层中,减轻了工程团队的运维负担,并在Amazon Elastic Kubernetes Service(EKS)上实现了更快的应用程序部署和扩展。

 

EKS Capabilities 集成了许多 Kubernetes 用户已经依赖的三个核心组件:Argo CDAWS Controllers for Kubernetes(ACK)和Kube Resource Orchestrator(KRO),并在 AWS 拥有的基础设施中运行它们,这些基础设施与客户集群抽象隔离。Argo CD 提供声明式的持续部署和GitOps工作流,允许直接从版本控制同步资源和应用程序。ACK 通过自定义资源扩展 Kubernetes,用于直接在 Kubernetes API 内管理 AWS 服务,如S3DynamoDBRDS。KRO 提供了一个简化的机制,用于创建和管理组合的自定义资源,帮助平台团队定义可重用的、更高层次的抽象,而无需手动处理复杂的控制器逻辑。

 

通过将这些能力作为托管的 AWS 资源而不是集群内的插件提供,EKS Capabilities消除了用户自己安装、补丁、扩展或更新基础 Kubernetes 工具的需求。AWS 处理扩展、维护、安全补丁和兼容性升级,使平台工程师和开发人员能够更多地专注于交付业务逻辑,而不是管理平台组件。实际上,团队继续使用熟悉的接口如kubectl、GitOps 工作流和声明式清单与 Kubernetes 一起工作;不同的是,持续部署和资源编排等核心服务由 AWS 作为 EKS 平台的一部分提供和维护。

 

这种转变与云原生运维的更广泛趋势相一致,在云原生运维中,托管服务越来越多地吸收了无差别的繁重工作,使组织能够更容易地扩展 Kubernetes 的采用。平台团队可以将常规的基础设施集成卸载到 AWS 托管的能力中,同时保留原生的 Kubernetes 工作流,应用程序开发人员则从统一、一致的能力中受益,这些能力跨越了集群,而无需投资于定制的平台工具。通过 EKS 控制台、AWS CLIeksctl或其他自动化工具启用 EKS 能力。当将 Argo CD、ACK 或 KRO 等能力添加到集群中时,它将作为 AWS 资源出现,可以像其他 AWS 服务一样进行标记、管理和监控。权限通过 AWSIdentity and Access Management(IAM)配置,对于 Argo CD 单点登录等功能,支持与 AWS IAM 身份中心的集成。AWS 还自动分析破坏性变更,并对活动功能应用更新或补丁,减少管理开销。

 

虽然每个功能都是独立且可选的,允许团队只启用他们需要的功能,但它们共同为 Kubernetes 环境提供了一个连贯、可扩展的平台层,融合了应用程序部署、AWS 资源控制和自定义资源组合。这种方法旨在缩短交付时间,最小化操作摩擦,并帮助组织在开发、测试和生产环境中大规模采用 Kubernetes。

 

这次更新引起了云和 DevOps 社区的共鸣。在Reddit上,实践者强调了托管 Argo CD 支持和集成的 AWS 资源管理的便利性,这是尝试新功能的令人信服的理由,特别是对于那些寻求统一 GitOps 工作流和资源配置而不进行手动插件管理的团队。同时,一些观察者指出,尽管托管能力减少了设置工作,但它们仍然需要 Kubernetes 专业知识和仔细的成本考虑,因为采用规模扩大,成本也被质疑是一个潜在的问题,因为许多团队可能已经有自己管理这些的方法,并且看不到为这项新的 AWS 功能支付额外费用的好处。

 

随着企业继续在混合云和多云环境中采用 Kubernetes,Amazon EKS Capabilities 通过将运维最佳实践嵌入到服务本身,代表了降低平台复杂性和加速云原生应用程序交付的一步。

 

https://www.infoq.com/news/2025/12/aws-eks-workload-orchestration/