我如何设计 DevOps 下的 OpenIM 标准开发流 & 敏捷体系 & 精益模式

DevOps DevOps 🔥 DevOps是一种软件开发和运营的文化和方法论,旨在通过自动化和协作来缩短软件开发周期和提高软件质量。 DevOps(Development和Operations的混成词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。通过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。 为什么 OpenIM 需要 DevOps? 我想用一句话来概括,DevOps 能解决 OpenIM 当前的团队管理,能高效组织团队,并且能通过 自动化 工具协作于沟通。 从而实现用更少的浪费、更频繁的交付更稳定的产品。 最开始的 OpenIM 是什么样子的? 找到了之前的一个很古老的版本,链接是:https://github.com/OpenIMSDK/Open-IM-Server/tree/test-tuoyun 几乎存在 commit 信息丢失,因为信息不全导致代码无法跟踪问题,导致文档缺失,代码不规范等一系列的问题。 我们跨越了从原始社会到传统的协作方式,再到后面的 devops 为什么说及时到现在,我依旧没有将 OpenIM 转变为 devops,一个很明显的判断标准,每一次运维和交互工作依旧需要我手动去做,无疑是区分了 dev 和 ops 的职责。不仅仅让成本变高,效率变低,更重要的是团队没有了更清晰的定位。 那么我后面的计划如何? 不管是 prow, actions, 等等 CI 工具,以及各种 ops(gitops, aiops, chatops,) 也不管是各种设计的 自动化 以及 自动化管理工具,自动化交互工具。 无疑他们是一套体系: 提供无感知的开发环境,无论交付是否频繁,每一个 feature 的 PR 都能快速的,规范并且经过大量自动化测试,更加快速上线,也能更快地响应客户需求。每一次发布的变更变少,所以风险,以及合并的冲突,工作量就变少。而且代码 code review 更方便,代码质量和团队水平提升很高的档次。 🔥 OpenIM 当时我的设计理念是 main 分支作为一个类似于传统的 dev 分支,保证代码的最新以及基本可靠,release-v* 分支作为稳定的分支。 DevOps 最重要的就是自动化,和自动化运维。非常鼓励自动化,甚至可以让开发者即使不会任何运维也能去走整套自动化的流程。 OpenIM 的团队约束制定:https://traveling-thistle-a0c.notion.site/OpenIM-standardization-ebd0c1529ab54e4fb92840e67a73aac1?pvs=4...

September 2, 2023 · 3 分钟 · 458 字 · 熊鑫伟,我

我是如何优雅设计 OpenIM 多进程管理策略的

主要模块 这篇文章将会从 OpenIM 最基本的单进程前台运行开始,到 nohup 后台运行,到 system 系统进程,然后再到 Supervisord,容器化管理,kubernetes 健康检测。 目前问题 阅读:https://github.com/cubxxw/Open-IM-Server/blob/refactor/feat-enhance/scripts/install/openim-crontask.sh 源码 目前 OpenIM 之前的进程管理策略是通过 nohup 在后台启动的。 整个项目由多个进程共同运行,现在需要一个可靠的保活机制,以便能够在进程崩溃的时候能够快速把它拉起来。openim 的解决方案无非就是写个保活脚本,在后台一直运行,如果发现某进程被关闭了,那么由脚本拉起来,或者是通过 docker compose 健康检测机制: healthcheck: test: ["CMD-SHELL", "./scripts/check-all.sh"] interval: 30s timeout: 10s retries: 5 但是脚本它自己挂掉怎么办?(总不能使用脚本继续保活保活脚本套娃吧)。此外,另一个办法就是配置出来一个服务,让Linux操作系统帮你守护进程,显然,这种办法完全不需要担心守护进程自己挂掉,毕竟是systemd帮你守护,如果它挂掉了,操作系统应该也没了。 我们适配通用的 Ubuntu 和 CentOS 即可,因为 其他 的操作系统比如说 alpine , Alpine Linux 并不使用 systemd 作为其默认的初始化系统。相反,Alpine Linux 使用 OpenRC 作为其默认的初始化系统。这也是许多人选择 Alpine Linux 的原因,因为它是轻量级的,并且没有引入 systemd。 现在新版的 Ubuntu 和 CentOS 都支持的,旧版的linux使用service httpd start启动服务,新版的linux使用systemctl start httpd来启动服务,此外使用initd作为初始化系统的操作系统添加服务是在/etc/init.d/中添加脚本,而使用systemd作为初始化系统的操作系统只需要在/etc/systemd/system/文件夹中添加配置文件就好了。 前台进程 前台进程:是在终端中运行的命令,那么该终端就为进程的控制终端,一旦这个终端关闭,这个进程也随之消失,这时就把Shell给占据了,我们无法进行其他操作。对于那些没有交互的进程,我们希望将其在后台启动,可以在启动参数的时候加一个’&’实现这个目的。 后台进程:也叫守护进程(Daemon),是运行在后台的一种特殊进程,不受终端控制,它不需要终端的交互;Linux的大多数服务器就是使用守护进程实现的。比如Web服务器的httpd等。 解决方案 1. 使用&后台运行程序:...

August 16, 2023 · 7 分钟 · 1477 字 · 熊鑫伟,我

OpenIM离线部署设计

1. 基础镜像 以下是你需要的基础镜像及其版本: wurstmeister/kafka redis:7.0.0 mongo:6.0.2 mysql:5.7 wurstmeister/zookeeper minio/minio 使用以下命令拉取这些基础镜像: docker pull wurstmeister/kafka docker pull redis:7.0.0 docker pull mongo:6.0.2 docker pull mysql:5.7 docker pull wurstmeister/zookeeper docker pull minio/minio 2. OpenIM 与 Chat 镜像 详细了解 OpenIM 和 Chat 的版本管理及存储: version.md OpenIM 镜像 获取镜像版本信息: images.md 根据所需版本,执行以下命令: docker pull ghcr.io/openimsdk/openim-server:<version-name> Chat 镜像 执行以下命令来拉取镜像: docker pull ghcr.io/openimsdk/openim-server:<version-name> 3. 镜像存储选择 存储库: 阿里云:registry.cn-hangzhou.aliyuncs.com/openimsdk/openim-server Docker Hub:openim/openim-server 版本选择: 稳定版:如 release-v3....

May 19, 2023 · 1 分钟 · 140 字 · 熊鑫伟,我

开源的阶段性成长指南

✨ 熟悉我的人都知道,我是一名不折不扣的开源爱好者,从大一开始接触到 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 分钟 · 430 字 · 熊鑫伟, 我

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

一篇适用远程工作的约定指南: OpenIM 远程工作团队协作协议 v1.3

Principles 0)Ownership & Leadership 如果看到团队或是项目有问题的时候,不要等,也不忍,请马上说出来,并给出相应的方案, 自己跳出来召集开会,及时调整。不要闷在那里,自己憋! “每个团队成员都承担Owner和Leader的角色。发现问题时,勇于指出并提供解决方案,不要等待或沉默。” 1)Initiative 每人个都必需是主动的,都需要自己发起要做的事,或是自己要认领要做的事,如果发现自己没有事情了, 需要学会主动发现问题,主动找到可以improve的地方,创新来源于此。没有路要学会自己造路! “为团队创新和改进提供动力。” 2)Objectives Oriented 每个人都是产品经理,也都是项目经理,每个人都必需把自己的工作和我们大的目标连接在一起,知道什么是重点,重点的东西就是两件事:一)从用户的角度出发,二)从产品的角度出发。 这意味着我们要随时观察整个产品的样子,而不只是自己这一块东西 。 “始终保持用户和产品的双重视角,确保工作与总体目标一致。” 3)Insists on High Standard 举法其上,得乎其中,举法其中,得乎其下,举法其下,法不得也。我们要坚持用高的标准要求自己,对于高标准的目标不妥协,但是在实施路径和策略上可以妥协。 “始终坚持高标准,确保质量。在实施过程中可以灵活,但对于高标准的最终目标绝不妥协。” Practices 0)Online 工作的时候必需在线。如果不在线了,需要说一下不在线的时长, 目前我们工作的事宜在通讯工具采用Slack, 如果需要请假的情况,如果不是紧急情况,需要提前一天 在MegaEase的Slack #random 频道中提前说明。如果是紧急情况,也需要提前在insider频道中告知大家。 “工作时,请确保在线。若需离线,务必在Slack #insider 频道提前通知。” 1) Documentation Driven 面对面交谈、电话语音、微信、Slack虽然是比较实时的反馈工具,但是只有文档是可以把重要信息给结构化的,而且写文档其实是比起前面的方式来说是更为深度的思考,因为会让你自己审视自己的想法。所以,对于一些重要 “功能”、“流程”、“业务逻辑” 、“设计”、“问题”,以及“想法”,最好都以文档化的方式进行。请使用Github的 wiki、project、issue这些工具或是使用Google Doc. “确保关键信息持久化和可追溯。” 2)Design Review 对于一些重要的问题或是工作(每个人都能够判断什么是关键问题和工作), 需要先把自己的想法share出来,而不是先实现 。 一个好的 Design 文档需要包括如下项: Background。交待这个事的背景、需求和要解决问题。 Objectives。说明这个事的目标和意义。 Alternative Solutions 。 给出多个解决方案,并能够进行 Pros/Cons 对比。 Reference。方案需要有权威引用支持。 Data。方案需要有相关数据数据支持。 Conclusion。结论是什么。...

March 29, 2023 · 1 分钟 · 156 字 · 熊鑫伟,我