自动化的高级追求: Prow 是什么?Kubernetes 为什么需要它

why? 故事是从这个 proposal 开始idea~ 🤖 OpenIM cicd robot machine proposal Prow是基于Kubernetes的CI/CD系统。作业可以由各种类型的事件触发,并将其状态报告给许多不同的服务。除了作业执行,Prow还以策略执行、通过 /foo 风格命令的聊天操作和自动PR合并的形式提供GitHub自动化。 有关 Golang 文档,请参阅 GoDoc。请注意,这些库仅供prow使用,我们不会尝试保留向后兼容性。 Kubernetes 专门为 Prow 提供了网页命令查询: https://prow.k8s.io/command-help 关于Prow如何运行作业的简要概述,请参阅 Prow作业的生命周期。 要查看Prow的常用用法和交互流,请参见拉取请求交互序列图。 hello world 最简单的一个上手案例莫过于 pull request 。 提出一个拉取请求(以下简称PR)。在PR正文中,可以随意添加区域标签(如果合适),例如 /area <AREA> 。标签列表在这里。也可以随意推荐一位评论者 /assign @theirname 。 一旦你的审阅者满意,他们会说 /lgtm ,这将应用 lgtm 标签,如果他们是OWNER,将应用 approved 标签。 approved 标签也将自动应用于所有者打开的PR。如果你和你的审阅者都不是OWNER,请 /assign 某个所有者。如果你的PR有 lgtm 和 approved 标签,没有任何 do-not-merge/* 标签,并且所有测试均通过,则PR将自动合并。 查看测试结果 Kubernetes TestGrid 显示历史测试结果 在 testgrid/config.yaml 配置自己的 testgrid 仪表盘 Gubernator 格式化每次运行的输出 PR Dashboard 查找需要注意的 PR Prow 安排测试并更新问题 Prow 响应 GitHub 事件、定时器和在 GitHub 评论中给出的手动命令。 prow dashboard 显示当前正在测试什么 在 config/jobs 配置 prow 运行新测试 Triage Dashboard 汇总故障 将故障集群在一起 搜索跨作业的测试失败 在特定的测试和/或作业的 regex 中过滤失败 Velodrome 指标跟踪作业和测试健康状况。 Kettle 进行收集,metrics 进行报告,velodrome 是前端。 功能和特性 prow 的功能很强大,甚至是比 actions 更加出众。可以测试、批处理、工件发布的作业执行。...

September 16, 2023 · 4 分钟 · 796 字 · 熊鑫伟,我

速读开源项目 Sealos 的源码

准备 这篇文章等的太久了,大致 四个月了把,也是自己经历 docker 跨越到 Kubernetes 以及 CloudNative 生态的过程。 反过来再去理解开源、理解 sealos、 理解 Kubernetes,有种豁然开朗的视角。 这篇文章和其他文章不一样的是,这篇是按照自己现在的思路来写的,具体为什么,在以前的文章中能找到答案~ 从 CMD 角度上对接源码,从最开始出发: 不管是 sealer 还是 sealctl,都离不开 镜像的构建核心》 buildah: package main import ( "github.com/containers/buildah" "github.com/labring/sealos/cmd/sealctl/cmd" ) func main() { if buildah.InitReexec() { return } cmd.Execute() } 从 InitReexec 调用 buildah 初始化开始,进行走进 sealos 的大门:Execute 在 cobra 中,Execute 只会执行一次,不管是正确的还是失败的~ 在调用的时候,会先执行 init 初始化函数,它 定义了一些初始化工作以及标志: func init() { cobra.OnInitialize(func() { logger.CfgConsoleLogger(debug, showPath) }) rootCmd.PersistentFlags().BoolVar(&debug, "debug", false, "enable debug logger") rootCmd.PersistentFlags().BoolVar(&showPath, "show-path", false, "enable show code path") } 哈哈,sealos 对于日志包的封装,还是很让我惊喜的,使用了 zap 进行二次开发和封装,用于适合自己的业务需要,这对我是有参考意义的,包括 horizon,未来可能需要在 日志包和 错误码设计上进行改进,这是成就一个优秀的开源项目的必要条件~...

September 11, 2023 · 12 分钟 · 2381 字 · 熊鑫伟, 我

开源的阶段性成长指南

✨ 熟悉我的人都知道,我是一名不折不扣的开源爱好者,从大一开始接触到 GitHub 后,逐渐的沉迷于 开源世界 ~ 今天这篇文章很特别,算是自己参考并且总结出来的开源阶段,以及学习开源项目的步骤和心得。未来自己也是按照自己的规划来进行成长。 同学习 Kubernetes 的成长轨迹一样,这篇文章将会长期更新,也可以参与贡献 ~ 目前我是处于第一阶段,处于一种对开源世界和对知识的沉淀与积累的过程中,这个阶段的主要表现是我们开始学一些基础。但是我喜欢做笔记将它们记录下来,供自己日后翻阅和复习,当然也是制作自己的内容价值。 GitHub - cubxxw/awesome-cs-cloudnative-blockchain: 📚 菜鸟成长手册🚀 CS系列 、云原生系列、区块链系列、web3系列🔥、Golang系列💡…… 这一阶段,并不是意味着我开始迈入第二阶段,第一阶段就 come to an end. 我认为以下所讲的所有阶段就像是人生轨迹,并不是意味着你当爸爸了就不是父母的孩子,你依旧可以扮演着多种角色,并且不断完善和改进自己的角色。开源项目也是如此,类比我们的成长经历,在后一阶段我依旧会扮演好前一阶段的角色。所以我会坚持做自己的内容创作和知识共享 ~ ✨ 下面开始介绍适合大多数人的开源项目的不同阶段,为了方便定位,我将上面知识积累称呼为 0 阶段知识积累阶段。下面开始从第一阶段开始讲起~ 第一阶段:简单看源码阶段 💦 在这一个层次的我们,是一个刚毕业或者没毕业的大学生,又或者是刚刚踏入职场,我们是一个新手,对于开源项目保持一心热血但是不知道从何开始。 方法: 简单看源码 说明: 简单看源码、文档、跑跑样例代码 学习效果: 1 ~ 2 有产出: 没有产出 是否达成学习闭环: 尽量问题驱动看源码,从问题出发学源码回归问题,达成闭环 Get 到的技能点: 阅读源码的技能 案例: 阅读 sealer、sealos、Kubernetes、k3s、horizoncd 的源码,并且测试 阶段 第一阶段:简单看源码阶段 方法 简单看源码 说明 简单看源码、文档、跑跑样例代码 学习效果 1 ~ 2 有产出 没有产出 是否达成学习闭环 尽量问题驱动看源码,从问题出发学源码回归问题,达成闭环 技能点 阅读源码的技能 案例 阅读 sealer、sealos、Kubernetes、k3s、horizoncd 的源码,并且测试 第一阶段的建议是简单地看源码、文档、跑跑样例代码来学习。这个阶段的主要目的是积累基础知识,建议尽量问题驱动看源码,从问题出发学源码回归问题,达成闭环。阅读源码的技能是这个阶段最重要的技能点。建议阅读一些开源项目,例如 sealer、sealos、Kubernetes、k3s、horizoncd 等,并进行测试。...

May 16, 2023 · 3 分钟 · 506 字 · 熊鑫伟, 我

Openkf 多架构镜像的构建策略设计

自动化构建openkf的多架构镜像并推送到多个镜像仓库 https://github.com/openimsdk/openkf 描述: 为了满足各种用户的需求,我们的目标是自动化构建用于各种架构的openkf Docker镜像,并无缝地将它们推送到多个镜像仓库。 目标: 自动构建openkf的linux/amd64和linux/arm64架构的Docker镜像。 将镜像推送到Docker Hub、阿里云Docker Hub和GitHub容器仓库。 任务: 设置多架构构建系统 使用GitHub Actions,配合QEMU和Docker Buildx,支持linux/amd64和linux/arm64的多架构构建。 在每次新版本发布、提交到main分支或定期事件时,触发构建过程。 支持多个镜像仓库 Docker Hub:推送到openim/openkf-server。 阿里云Docker Hub:推送到registry.cn-hangzhou.aliyuncs.com/openimsdk/openkf-server。 GitHub容器仓库:推送到ghcr.io/openimsdk/openkf-server。 动态镜像标记 使用Docker Metadata Action,基于事件(如定期触发器、分支提交、拉取请求、语义版本控制和提交SHA)生成动态标签。 确保在拉取请求事件中不推送已构建的镜像。 身份验证和安全性 使用秘密配置Docker Hub、阿里云和GitHub容器仓库的身份验证。 确保每个仓库的推送操作都是安全且无缝的。 通知和日志 通过GitHub Actions,如果有任何构建或推送失败,向开发团队发送通知。 保留每次构建和推送操作的日志以供追踪。 验收标准: openkf镜像应该成功地为linux/amd64和linux/arm64架构构建。 在成功构建后,镜像应该在Docker Hub、阿里云Docker Hub和GitHub容器仓库上可用。 根据定义的事件和属性正确标记镜像。 整个过程中不需要人工干预。 附加说明: 自动化过程在GitHub Actions工作流中定义。确保根据需要查看和更新工作流。 确保在单独的分支或环境中测试此过程,以避免中断。

April 23, 2023 · 1 分钟 · 46 字 · Me