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...

主要模块 这篇文章将会从 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. 使用&后台运行程序：...

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....

✨ 熟悉我的人都知道，我是一名不折不扣的开源爱好者，从大一开始接触到 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 等，并进行测试。...

自动化构建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工作流中定义。确保根据需要查看和更新工作流。 确保在单独的分支或环境中测试此过程，以避免中断。

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