管理后台和监控的部署与设计

OpenIM 提供了多种灵活的部署选项,适用于不同的环境和需求。以下是这些部署方案的简化和优化描述: 源码部署: 普通源码部署:使用 nohup 方式进行部署。这是一种基础的部署方法,适合于开发和测试环境。详情参见:普通源码部署指南。 生产级部署:采用 system 方式,更适合于生产环境。这种方法提供了更高的稳定性和可靠性。详情参见:生产级部署指南。 集群部署: Kubernetes 部署:提供两种方式,包括通过 helm 和 sealos 进行部署。这适用于需要高可用性和可扩展性的环境。具体方法请参考:Kubernetes 部署指南。 Docker 部署: 普通 Docker 方式:适用于快速部署和小型项目。详细信息请见:Docker 部署指南。 Docker Compose 方式:提供了更便捷的服务管理和配置,适合于复杂的多容器应用。 接下来,我们将逐一介绍这些部署方法的具体步骤、监控和管理后台的配置,以及使用技巧,帮助您根据自己的需求选择最合适的部署方案。 源码 & Docker 部署 源码部署 openim-server 和 openim-chat ,其他的组件都是通过 Docker 部署。 docker 部署则通过 https://github.com/openimsdk/openim-docker 仓库一键部署所有的组件。 部署的配置文件,可以阅读 https://github.com/openimsdk/open-im-server/blob/main/scripts/install/environment.sh 文档了解如何学习以及熟悉各个环境变量。 对于 Prometheus 来说,默认是没有开启 Prometheus 的,如果需要开启的话,需要在 make init 之前设置环境变量: export PROMETHEUS_ENABLE=true # 默认是 false 然后执行:...

November 15, 2023 · 3 分钟 · 453 字 · 熊新伟, 我

OpenIM 使用 Harbor 构建企业镜像仓库

需求 OpenIM 提供了多种公共的镜像注册地址,比如说 aliyun, github, Docker hub ~ 阅读 https://github.com/openimsdk/open-im-server/blob/main/docs/conversions/images.md 获取更多的镜像构建指南。 大部分企业都会选择自己做镜像仓库,使用 Harbor 来搭建企业级的镜像仓库,将它集成 CICD Pipeline 流程中,最终替换 Docker Hub,进一步降低镜像存储的成本。 此外,在生产环境下,Harbor 一般都会开启 TLS,所以你还需要准备一个可用的域名。 中国的服务器使用域名,需要对域名进行备案 安装 Helm Helm,以及 集群的部署参考 https://github.com/openimsdk/open-im-server/tree/main/deployments 安装 Cert-manager 接下来我们安装 Cert-manager,它会为我们自动签发免费的 Let’s Encrypt HTTPS 证书,并在过期前自动续期。 首先,运行 helm repo add 命令添加官方 Helm 仓库。 $ helm repo add jetstack https://charts.jetstack.io 然后,运行 helm repo update 更新本地缓存。 $ helm repo update 接下来,运行 helm install 来安装 Cert-manager。 $ helm install cert-manager jetstack/cert-manager \ --namespace cert-manager \ --create-namespace \ --version v1....

October 25, 2023 · 2 分钟 · 350 字 · 熊鑫伟, Me

OpenIM 的集群化设计 | Kubernetes 部署 | 方案讨论 | 总结

会议和参考链接 会议参考文档:https://nsddd.notion.site/2899028707604b8090b36677c031cdf8?pvs=4 视频回放:Bilibili: https://www.bilibili.com/video/BV1s8411q7Um/?spm_id_from=333.999.0.0 评论: 那个中间件我觉得可以换成 https://kubeblocks.io 可以帮你管理多个数据库中间件 im 读取配置信息,读取的是 config/ 目录,代码中硬编码补充的 config.yaml,是否可以自动化来对 不同 服务的 rpc 划分,然后统一目录,默认读取的是二进制运行路径的上两层 openim version: https://github.com/openimsdk/open-im-server/blob/main/docs/conversions/version.md 存储可以考虑使用 : https://github.com/openebs/openebs https://github.com/rook/rook 核心目标: 开源项目和非开源项目的最大的区别,就是一套完整的解决方案。 非开源项目的 集群化部署方案的设计,比较在乎稳定,以及高效,快速,最好一键部署。 开源项目的 集群化部署方案的设计,比较在乎通用性,上手的难度,后期的维护难度,基础架构的稳定性。后面的开发者或者是贡献者,使用者,可以基于此创建自己的集群化部署方案,以及解决方案,并且成为 OpenIM 的集群化部署方案的使用案例。 OpenIM 集群化部署讨论会记录 先总结,后详细解读 ~ 关于开源部署环境的演变与变化 新部署方法:一种集二进制和部署于一体的一键操作。 Kubernetes 部署:在 Kubernetes 环境中实现一键部署的新型方案。 现存问题:涉及日志收集、服务重启追踪等,将在后续对这些问题进行改进并寻求解决方案。 CICD的开发与维护策略 CICD 概念:通过CICD实现Code Streaming。 开发阶段:需要编写出镜像文件。GitHub的CSD功能:已实现但尚待深入研究。 版本标记策略:推荐使用local branch而非直接标签。 关于软件开发与测试的实践经验分享 本地开发:推荐使用“auto-compile”工具快速生成稳定版本的镜像。 团队协作:介绍了各团队间如何协同进行开发、测试和发布。 代码重用:提及将库中的函数或方法封装为组件,实现跨项目调用。 Docker Deployment与Service Configuration 配置传递:主要通过如K8S中的配置文件。 部署方式:介绍了二进制部署和可部署两种策略,并讨论了各自的优缺点。 关于容器化部署和代码优化的探讨 容器化:提议将多个进程合并为一个容器进行管理。 部署方式兼容性:讨论了如何实现并进行微调。 技术架构和组件:如Helm chat、OpenM等,及其在系统中的作用和重要性。 关于一键部署的技术问题与解决方案 一键部署问题:可能的问题有无法翻墙、无法安装等。 解决方案:1) 将现有方案通用化;2) 采用第三方服务实现一键部署。 K8S部署与自动化的优化策略 部署工具:如使用Shell实现一键部署、K ks部署等。 组件整合:考虑如何将不同组件组合成完整解决方案,并保持不同环境中的一致性。 微服务架构中的最佳实践 应用程序部署:建议将应用程序划分为不同的容器,每个容器内运行一个业务进程。 代码整合:提议将相关代码整合为一个文件进行管理。 微服务的优化与部署策略 微服务划分:强调避免过于细致的模块分割。 自动化:部署时不增加额外维护工作量,采用自动化策略。 关于存储方式和编排工具的选择 文件存储:如使用NFS作为本地分布式文件存储。 编排工具:推荐使用 rook 进行对象存储编排,数据库使用专用编排器。 NFS与Flexible File System的应用 苹果手机上的MFS:讨论了其使用情况和如何同步全局配置文件到各业务模块。 PV/PVC管理数据:示例讲解如何使用此文件系统进行数据管理。 二进制代码与配置文件的应用 代码适配:通过配置文件进行,涉及传递配置路径、文件映射等细节。 关于软件开发中的优化与改进 项目脚本编写:讨论了性能瓶颈、部署统一处理、服务发现模块的优化建议。 关于Web应用配置文件的编写与优化 IP分配:配置文件用于IP分配和模块间分段处理。 接口应用:如在不同环境使用不同的接口实现心跳等功能。 技术架构改进:优化轻量化、提高开发效率和维护效果等。 结论:本次讨论会涉及了开源部署环境的多个方面,从软件开发、部署、测试到微服务架构和存储方式等多个领域。希望通过此次讨论,可以为OpenIM的集群化部署提供有力的参考和指导。...

September 17, 2023 · 2 分钟 · 342 字 · 熊鑫伟, Me

开源社区的规范设计思路

社区不规范怎么办 作为 OpenIM 社区首席运营官,对整个社区的 communtiy 以及 GitHub 配置仓库 进行了全面的配置。并且对整个 OpenIM 的 Makefile 和 CICD 流,以及整个 OpenIM 使用的日志包 、错误码、协同流、贡献者文档以及 社区文档 进行架构和设计。 在这个时候总会有一些问题,即使你觉得自己的 贡献者文档 写的很牛逼了,很全面了,但是依旧很少有人愿意花心思去按照你写的规范去学习。这对我打造顶级的开源社区是一个非常大的阻碍,于是就有了今天的这个文档,我会将它记录在 GitHub Gists 上,提供拉取和使用的说明、链接,并且定期的维护它。 首先,我提供克隆的链接: git clone https://gist.github.com/cubxxw/126b72104ac0b0ca484c9db09c3e5694 如何设计 首先是针对基础的功能,那就是我们熟知的 commit 信息和 push 信息。 我们可以对 commit 信息的格式进行设置 我们可以对 push 的大小进行设置 我们提供了 actions 的功能 我们提供了 Makefile 标记和清除 Hook 的能力 我之前在学习 git 的时候写了一篇很全的笔记,并且分享在 GitHub 上面,在这个 🤖 链接 上可以学习到 git 很多高级用法。 这篇文章讲解了 git 有哪些规范,寻找合适的 CICD 流: 统一格式: 统一格式:git commit -m 'type(scope): 描述(#issue)' 我们在提交的时候带上邮箱信息 -s 来签证,这是一个很好的习惯。...

September 16, 2023 · 7 分钟 · 1334 字 · 熊鑫伟, Me

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 字 · 熊鑫伟, Me

OpenIM 多进程管理

111: 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给占据了,我们无法进行其他操作。对于那些没有交互的进程,我们希望将其在后台启动,可以在启动参数的时候加一个’&’实现这个目的。...

August 16, 2023 · 7 分钟 · 1480 字 · 熊鑫伟, Me

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离线部署设计

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

1 分钟 · 140 字 · 熊鑫伟, Me