OpenIM

如果你想在寻找一篇针对 OpenIM 并且准备好具体的问题想来这里找到答案的话。那么很遗憾的告诉你，这篇并不是记录问题和编写答案的，这篇是读者经过开发和业务实战中以 OpenIM 为例总结出来的故障排查的方法，以及调试的技巧。如果你想从我这里学习到故障的排查以及问题定位的经验，那么请你继续读下去。 我将会从工作中经常出现的一些情况总结成类型来分析。 一个小小的玩笑，或许我比较逆人性，其他人都很害怕遇到 bug 的时候，我倒是对出现 bug 比较兴奋，我们后期读代码的时间和维护代码的时间其实是远远高于写代码的时间的。所以面对 bug， 我们的思考和总结尤其是非常重要，尤其是帮我们在写代码的时候也思考，代码的扩展性，和错误处理，是否可以禁得起考验 ~ 故障排查的基本概念 故障排查，我主要是分为几种情况，分别是，编译的故障排查，启动的故障排查，以及服务运行故障排查。这几种情况的故障排查思路都是大同小异的。 首先，我们需要发现问题，然后定位问题。我们可能需要经过多轮分析排查才能定位到问题的根因，最后去解决问题。排障流程如下图所示： 开始 | V 发现问题 ------> 记录问题的症状和相关情况 | V 定位问题 | V 进行初步分析 --------> 确定可能的原因 | | V | 是否需要深入分析？-----> 是 ------> 进行深入分析 | | | | | V | | 确定具体原因 | | | | | V | <-------- 是否已找到根本原因？ | | | 否 | V 是否解决了问题？ | 是 ------> 记录解决过程和解决方案 | | 否 ------> 调整策略或寻求帮助 | V 结束 如果想排查问题并解决问题，你还需要具备以下两个基本能力： 能够找到组件日志，并理解错误日志的内容； 根据错误日志，找出解决方案。 发现问题 要排查问题，我们首先要发现问题，我们通常用下面这几种方式来发现问题： 代码审查：在开发过程中进行代码审查可以发现代码中的问题和潜在的错误； 安全审计：通过安全审计可以发现软件或系统中的安全漏洞和风险； 服务状态检查：可以通过检查服务的运行状态，来发现问题。例如：如果是 linux-system 模式部署 openim，那么启动 openim-api 服务后，执行 ``systemctl status openim-api 发现 openim-api 启动失败，即 Active 的值不为 active (running)`； 代码测试：通过进行各种类型的测试，如单元测试(util-test)、集成测试(api-test)、系统测试（e2e-test）等，可以发现软件或系统中的问题。例如：访问 openim-api 服务，发现接口返回异常错误码、接口值返回不对等； 自动化测试：我们也可以通过运行自动化测试，来帮助我们快速发现问题； 日志记录：在服务或接口异常时，我们需要排查日志。通过在日志中发现一些 WARN、ERRORV、PANIC、FATAL 等级别的错误日志来发现问题； 监控告警：通过监控指标、告警等，也可以发现问题。如果通过日志，能发现已经发生的问题，通过监控，还可以发现一些潜在的问题； 用户反馈：产品或功能发布后，用户在使用过程中，也可能会发现一些问题，并将问题反馈给开发人员。 上面发现问题的途径多种多样，有些发现问题的途径，通常发生在特定的软件阶段，例如：测试阶段，我们可以通过测试、质量保障团队来发现问题。产品发布后，可以通过用户反馈来发现问题。 ...

OpenIM 构建高效的版本控制和测试流程 开源项目的成功与否在很大程度上取决于其质量管理和协作流程。在 OpenIM 开源社区中，项目管理和测试流程的规范性至关重要，以确保代码的质量和稳定性。本文将简要介绍我们的测试方案、分支管理和质量控制策略，以及如何应用于 main 分支、PR 测试分支和稳定的 release 分支，以满足开发者、测试人员和社区管理者的需求。除此之外，还将介绍OpenIM开源社区的规范、测试方案和项目管理策略，旨在提供清晰的指导，以确保项目的稳定性和可持续性。 分支管理与版本控制 对于 OpenIM 来说分支的版本管理策略是尤其重要的，这里面设计到两块，一块是 OpenIM 的部署分支策略，一个是镜像版本策略，这两块分别参考下面的文章： 分支以及 tag 的版本策略 镜像的版本策略 总的来说： 在OpenIM社区中，main 分支被视为稳定版本的代表。所有代码必须经过严格的代码审查和测试，确保其质量和稳定性，然后才能合并到 main 分支中。 release 分支用于发布稳定版本。在 openim-docker 以及 openim-k8s 中使用的镜像版本也都是 release-v3.* 。在 release 分支上的任何更改都应该是针对已知问题的修复或功能的精心策划的添加。测试工作应重点关注于 release 分支，以确保发布版本的可靠性。 测试方案 Main 分支测试 在 main 分支上进行的测试应覆盖核心功能和关键路径，以确保基本功能的稳定性。测试工作应包括单元测试、集成测试和端到端测试。这部分所有的工作全部交给自动化去做，而不需要测试干预。 Release 分支测试 对于三种仓库，分别是 https://github.com/openimsdk/open-im-server 仓库，https://github.com/openimsdk/chat 仓库，https://github.com/openimsdk/openim-sdk-core 仓库。 在 release 分支上进行的测试要求更严格。测试团队应深入测试所有功能，并着重检查先前已知的问题是否已解决。确保在发布前没有潜在的问题。 这里的 PR 合并规则： 以 这个PR 为例： 首先是 PR 标题，PR 标题 fix pageFindUser ，首先，我们知道 git commit 信息包括是三种： ...

引言：深圳福田会展中心的全球视野 2023年12月6日，在深圳福田会展中心，GTC 2023 全球流量大会如火如荼地展开。这场盛会汇集了来自全球的技术精英，共同探索互联网行业的前沿动态和未来发展趋势。身为参与者，我有幸深入这场融合科技与商业的交流盛会，特别是“聚焦开源，扩展出海新领航”这一议题，让我收获颇丰，印象深刻。 大会聚焦于全球化的多元话题，包括出海市场的选择、广告推广策略等，与我此前参加的专注于日本市场出海活动的公司非常相似。然而，这次大会让我首次深入接触开源社区，不仅结识了众多开源界的领袖和布道者，也与许多杰出的开发者交流了心得。通过这些交流，我不仅学习到了许多新知识，还在思想上得到了升华。 在这篇博客中，我将对这次独特的经历进行深入的反思和总结，分享我在开源和全球化交汇中的洞见和学习。 对于 OpenIM 来说，我们现阶段正在全力准备奔向海外市场，希望打开国界，将 OpenIM 好用而且免费的开源核心功能贡献给全世界开发者。 开源项目天生就是分布式协作的，这是一种松散的结构。以 OpenIM 的开发者为例，我们现在有很多贡献者，开发者，虽然社区有双周会，但是还是很难和人或者同事有深层次的交流。 但对于开源商业公司而言，并不能简单的使用这种远程工作模式。在商业公司中，协作会更加的密切，而且对时效性的要求更高，当面沟通更能保证信息传递的完整性，这是远程工作难以替代的。当然，远程工作也有自己的优势，那就是吸引全球的人才。 所以，开源商业公司采用远程协作并没有问题，但一定要保证沟通的足够充分，拉平信息： 要视频沟通，文字只作为最终的记录。视频是沟通过程中信息丢失比较少的方式，是远程工作交流的首选方式。千万不要用文字来讨论非技术问题，这会带来巨大的信息差和误解。 保证沟通的尊重和善意。在开源项目中，大家因为没有雇佣关系，都是无偿做贡献，所以在异步沟通时特别强调尊重和善意；而在商业公司的远程办公时，因为缺少同事之间的沟通、吐槽和心理按摩，就更要注意沟通的尊重。 定期线下见面，增加相互之间的了解和信任。 另外一点，长期的远程协作，对于参与的工程师来说，除了需要很高的自律和自我管理的要求外，也要注意工作和生活的隔离，保持正常的社交活动和运动健身，否则很容易与社会脱节。 之前和 Apache APISIX 的某个小姐姐聊天，她说的一句话感触很深。也有很多适应不了远程工作的同事一一离去，这也是一个适者生存的达尔文法则。 关于 OpenIM 的远程工作，以及企业的文化，强烈推荐阅读下面的博客： Englist Version 中文版本 出海挑战：中国互联网企业的全球化之旅 中国互联网企业在全球化道路上的探索充满挑战与机遇。从初涉海外市场的尝试到在竞争激烈的国际环境中求生存，它们不断在新的市场环境中寻找增长点。这一过程中，企业需要超越传统的商业模式，适应多元文化和不同的市场需求。 首先，来到了第一个话题，为什么要去做海外社区？ 和很多的开源社区的布道者和专家沟通交流，然后反思，我深信建立一个活跃的海外社区是开源项目成功的关键。在全球化的今天，开源不仅是关于代码的分享，更是一种文化和思想的交流。通过建立海外社区，我们不仅能将技术带到世界的每个角落，还能促进不同文化背景下的思想碰撞和创新。 人性化地讲，建立海外社区意味着建立更广泛的连接和共鸣。每一位开源贡献者，不论身处何地，都希望他们的声音被听见，他们的贡献被认可。海外社区提供了一个平台，让来自世界各地的开发者能够参与到项目中来，分享他们独特的视角和经验。这种多元化的参与不仅丰富了项目本身，还激发了更多创新的火花。 同时，海外社区的建立也是对开源精神的一种致敬。开源精神强调的是开放、协作和共享，而这些价值观在全球范围内都是通用的。当我们向海外扩展时，我们不仅在分享代码，更在传播这种包容和合作的精神。 此外，对于开源项目而言，海外社区的建立还意味着更广阔的市场和使用场景。不同的地区和文化背景下，用户对技术的需求和应用方式可能截然不同。这些多样性的输入是项目发展不可或缺的，它们有助于项目更全面地成长，更好地服务于全球用户。 我从大一开始接触 Github ，这个成功打开我通往未来的钥匙。 从2020年左右我开始接触开源，觉得开源比业务代码更有意义。因为开源不仅有技术积累，而且能把你学到的东西分享给其他人，一起成长，所以开源对程序员来说是一个双赢的事。 最开始的时候，我通过学习做笔记，分享笔记到 GitHub ，到后面做项目，参与到一些顶级的开源项目中来，然后慢慢的追求精益。整个过程，我很清晰的看到自己的成长。 甚至我的代码，就像 Git 或者 区块链的默克尔树结构，一步步的串起来记录，每当一个时间段，看到以前的 PR ，满满的都是回忆和尴尬 … 同样，我也是一个云原生的爱好者。 在如今这个时代，开源已经成为了一个不可逆的潮流，尤其是在云原生的领域。以微软为例，他们在 Github 上的开源项目贡献位居全球前列，这充分体现了他们对开源的全面拥抱。在云原生时代，如果你不拥抱开源，不利用开源组件去构建和优化你的核心系统，很可能会在激烈的市场竞争中落后。云原生技术的迅猛发展要求企业和开发者必须快速适应新技术和方法论，而开源社区正是这种创新和合作的孵化器。在这个时代，开源不仅仅是技术选择，更是一种必要的战略思维。 开源社区国际化选择：第一站，启航 美国：开源发展的领头羊 美国仍然是全球最大的开发者社区，拥有超过2000万的开发者，过去一年增长了21%。美国的开源社区历史悠久且成熟，是全球开源活动的重要推动者。 亚太地区：快速增长的新星 亚太地区，尤其是印度、日本和新加坡，正经历着显著的开源社区增长。印度的开发者社区增长尤为显著，预计到2027年将超过美国，成为全球最大的开源社区。 非洲：充满潜力的新兴市场 非洲各地区，尤其是尼日利亚、加纳和肯尼亚，也在迅速发展成为技术公司的新兴枢纽。这些地区的开发者数量每年都在显著增长。 南美洲：稳健增长的活跃区域 南美洲的开发者社区，特别是在阿根廷和巴西，也在持续增长，与亚太和非洲的增长速度相仿。 欧洲：稳定增长的成熟市场 欧洲的开源社区虽然增长速度较美国慢，但在西班牙、德国和英国等国家仍保持稳定增长。 Github 年度总结分析 2023 年 Github 年度报告精华： 生成式 AI 项目和个人贡献者数量的显著增长 ...

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 然后执行： make init docker compose up -d 配置 要在 Grafana 中配置 Prometheus 数据源，请遵循以下步骤： ...

需求 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.10.0 \ --set ingressShim.defaultIssuerName=letsencrypt-prod \ --set ingressShim.defaultIssuerKind=ClusterIssuer \ --set ingressShim.defaultIssuerGroup=cert-manager.io \ --set installCRDs=true 此外，还需要为 Cert-manager 创建 ClusterIssuer，用来提供签发机构。将下面的内容保存为 cluster-issuer.yaml。 ...

容器运行时 容器运行时(Container Runtime)，运行于Kubernetes (k8s)集群的每个节点中，负责容器的整 个生命周期。其中Docker是目前应用最广的。随着容器云的发展,越来越多的容器运行时涌现。为了 解决这些容器运行时和Kubernetes的集成问题，在Kubernetes 1.5版本中，社区推出了CRI ( Container Runtime Interface,容器运行时接口)以支持更多的容器运行时。 什么是 CRI CRI 是 Kubernetes 定义的一组 gRPC 服务。 kubelet 作为客户端，基于 gRPC 框架，通过 Socket 和容器运行时通信。它包括两类服务: 镜像服务(Image Service)：提供下载、检查和删除镜像的远程程序调用； 运行时服务(Runtime Service)：包含用于管理容器生命周期，以及与容器交互的调用(exec/ attach / port-forward)的远程程序调用。 运行时的层级 容器运行时可以分为高层和低层的运行时： Dockershime，containerd 和 CRI-O 都是遵循 CRI 的容器运行时，我们称之为 高级运行时。 OCI 定义了创建容器的格式和运行时的开源行业标准，包括 镜像规范（Image Specification) 和 容器运行时规范 （runtime specification） 镜像规范定义了 OCI 镜像标准，高层级运行时 将会下载一个 OCI 镜像，并且将它解压为 OCI 运行时文件系统包（file system bundle） 运行时规范描述了如何从 OCI 运行时文件系统包运行容器程序。并且定义它的配置，运行环境和生命周期。如何为新的容器设置命名空间（namespace）和控制组（cgroup) ，以及挂载根文件系统（rootfs）等等操作，都是在这里定义的。它的一个参考实现是 runc，我们称其为 低层级运行时（Low-level Runtime) ...

会议和参考链接 会议参考文档：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的集群化部署提供有力的参考和指导。 ...

任务分配 time：Within a week 完成 first contribute，目的：了解开源项目的贡献流程 完成 sealos 开发环境构建 了解 kuberentes 基本使用，核心概念，核心组件的作用 基本使用： 创建 一个 pod 并理解什么是 pod 创建一个 deployment 理解 deployment 与 pod 的关系 创建一个 configmap， 理解挂载配置文件给 pod 创建一个 service，通过 service 在集群内访问 pod 核心概念，核心组件的作用： kubectl apiserver controller-manager scheduler kubelet kube-proxy etcd 这些组件分别是做什么的 可以用一个 kubectl apply 一个 deployment 这些组件分别做了哪些事来梳理整个流程 🚸 next time：会分配一个具体的任务以及介绍 sealos 源码架构。 资源🗓️ 参考资料： 贡献文档：https://github.com/labring/sealos/blob/main/CONTRIBUTING.md 开发环境搭建文档：https://github.com/labring/sealos/blob/main/DEVELOPGUIDE.md 使用 sealos 快速构建 kubernetes 学习环境文档：https://github.com/labring/sealos#quickstart 搭建单机环境即可。 ...

社区不规范怎么办 作为 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 来签证，这是一个很好的习惯。 ...

准备 这篇文章等的太久了，大致 四个月了把，也是自己经历 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，未来可能需要在 日志包和 错误码设计上进行改进，这是成就一个优秀的开源项目的必要条件~ ...