对开源商业化的思考 & 全球流量大会(GTC)学习以及总结

引言:深圳福田会展中心的全球视野 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 项目和个人贡献者数量的显著增长...

十二月 7, 2023 · 3 分钟 · 477 字 · 熊鑫伟,我

Kubernetes Kustomize 学习指南

介绍 关于 kustomize github 地址 Get Started Kustomize 是一个专为 Kubernetes 设计的开源配置管理工具,它能帮助用户定制 Kubernetes 对象,并以声明式的方式管理这些对象,而无需修改原始的 YAML 文件1。这意味着你可以保留应用和组件的基本设置,同时通过应用名为“补丁”的声明式 YAML 文档来覆盖默认设置,而不会更改原始文件。Kustomize 提供了一种声明式的方法,符合 Kubernetes 的哲学,并且能够以一种可重用、快速生成、易于调试和可伸缩的方式定制 Kubernetes 配置。 Kustomize 的主要功能包括: 声明式配置: 允许你以声明式的方式定义和管理 Kubernetes 对象,例如部署、Daemonsets、服务、ConfigMaps 等,为多个环境提供支持,而无需修改原始的 YAML 文件 配置层叠: 通过利用层叠来保留应用和组件的基本设置,并通过覆盖声明式的 YAML 文档(称为补丁)来选择性地覆盖默认设置 集成与独立使用: Kustomize 可以作为一个独立的工具使用,或者与 kubectl 结合使用。从 Kubernetes 1.14 版本开始,kubectl 也开始支持使用 kustomization 文件来管理 Kubernetes 对象 Kustomize 提供了一种自定义 Kubernetes 资源配置的解决方案,该方案摆脱了模板和 DSL。 版本关系 & kubectl 集成 要查找kubectl最新版本中嵌入的kustomize版本,请运行 kubectl version : $ kubectl version --short --client Client Version: v1.26.0 Kustomize Version: v4....

十月 31, 2023 · 6 分钟 · 1195 字 · 熊鑫伟,我

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

十月 25, 2023 · 3 分钟 · 476 字 · 熊鑫伟,我

自动化测试的学习(一)

云原生领域中GitHub开源Go项目的自动化测试实践与策略 介绍 作为 Github 上的 热门项目 OpenIM,如何在云原生时代中创造出价值,这是非常重要的,OpenIM 是一个优质的小团队,我们在自动化中并没有特别深入的见解。 使用 GitHub Actions 进行持续集成和持续交付 (CI/CD): GitHub Actions 提供了一个平台,可以自动构建和测试 Go 语言项目。通过配置 GitHub Actions 工作流,你可以在代码更改时自动运行测试,确保代码的质量和功能。 KubeVela 项目实践: KubeVela 是一个 Go 语言的云原生和开源项目,它展示了如何在云原生环境中组织 CI/CD 过程,包括自动化测试。KubeVela 使用声明性工作流来协调 CI/CD 过程,你可以参考 KubeVela 的 GitHub 仓库来理解和应用这些实践34[5](https://github.com/kubevela/workflow#:~:text=KubeVela Workflow is an open,engine in your own repository)。 云原生测试框架与工具: 在云原生开发中,合约测试(Contract Testing)是一种常见的测试实践,它确保服务间的通信符合预定义的 API 协议。例如,Cloud-Native Toolkit 中使用 Pact 进行合约测试。通过编写和集成测试,你可以验证服务间的通信是否符合预期6。 代码覆盖率检查: 在进行自动化测试时,检查代码覆盖率是一个好的实践。许多测试框架内置了代码覆盖率检查功能,可以配置它们来报告测试的代码覆盖率。例如,使用 SonarQube 工具来读取和报告代码覆盖率信息6。 利用开源工具和框架: 你可以利用开源工具和框架来进行测试,例如使用 Cypress 进行云原生应用的测试[7](https://dev.to/litmus-chaos/cloud-native-application-testing-automation-2bh5#:~:text=Cloud Native Application %26 Testing,Testing Using Cypress for)。还有其他的项目和资源,例如在 GitHub 上的 learning-cloud-native-go/myapp 仓库,提供了云原生 Go 项目的完成示例,你可以参考这些示例来理解和应用云原生测试实践[8](https://medium....

十月 14, 2023 · 18 分钟 · 3693 字 · 熊鑫伟,我

Kubernetes 控制平面 - 调度器

调度器 kube-scheduler 负责分配调度 Pod 到集群内的节点上,它监听 kube-apiserver,查询还未分配 Node 的 Pod,然后根据调度策略为这些 Pod 分配节点(更新 Pod 的 NodeName 字段)。 调度器需要充分考虑诸多的因素: 公平调度; 资源高效利用; QoS; affinity 和 anti-affinity; 数据本地化(data locality) ; 内部负载干扰(inter-workload interference) ; deadlines。 kube-scheduler 调度分为两个阶段, predicate 和 priority: predicate: 过滤不符合条件的节点; priority:优先级排序,选择优先级最高的节点。. predicate 策略 PodFitsHostPorts:检查是否有 Host Ports 冲突。 PodFitsPorts:同P odFitsHostPorts。 PodFitsResources:检查 Node 的资源是否充足,包括允许的Pod数量、CPU、内存、GPU个数以及其他的OpaqueIntResources。 HostName:检查 pod.Spec.NodeName 是否与候选节点一致。 MatchNodeSelector:检查候选节点的 pod.Spec.NodeSelector 是否匹配 NoVolumeZoneConflict:检查 volume zone 是否冲突。 MatchInterPodAffinity:检查是否匹配 Pod 的亲和性要求。 NoDiskConflict:检查是否存在 Volume 冲突,仅限于 GCE PD、AWS EBS、Ceph RBD以及 iSCSI。 PodToleratesNodeTaints:检查 Pod 是否容忍 Node Taints。 CheckNodeMemoryPressure:检查 Pod 是否可以调度到 MemoryPressure 的节点上。 CheckNodeDiskPressure:检查 Pod 是否可以调度到 DiskPressure 的节点上。 NoVolumeNodeConflict:检查节点是否满足 Pod 所引用的 Volume 的条件。 priority 策略 SelectorSpreadPriority:优先减少节点上属于同一个 Service 或 Replication Controller 的 Pod 数量。 尽量将同一个 rc 下的多个副本分散到不同节点,增加可用性 InterPodAffinityPriority:优先将Pod调度到相同的拓扑上(如同一个节点、Rack、Zone等)。 LeastRequestedPriority:优先调度到请求资源少的节点上。 BalancedResourceAllocation:优先平衡各节点的资源使用。 NodePreferAvoidPodsPriority:alpha....

九月 28, 2023 · 4 分钟 · 774 字 · 熊鑫伟,我

深入了解Kubernetes Kube apisserver的组件

深入理解Kube-APIServer kube-apiserver是Kubernetes最重要的核心组件之一,主要提供以下的功能 提供集群管理的REST API接口,包括认证授权、数据校验以及集群状态变更等 提供其他模块之间的数据交互和通信的枢纽(其他模块通过API Server查询或修改数据,只有API Server才直接操作etcd) apiserver 主要功能: 认证:使用集群判断身份。 鉴权:使用操作 CRUD,需要权限。 准入: 对于Kubernetes来说,需要一些额外的 actions,例如写入的值不规范,需要对其进行修改,修改后需要 校验。最后需要 限流,以防止恶意或者漏洞导致拥堵 Mutating Validating Admission 限流 APIServer对象的实现 访问控制 API Server 是所有组件交互的 中间枢纽。 Kubernetes API的每个请求都会经过多阶段的访问控制之后才会被接受,这包括认证、授权以及准入控制(Admission Control)等。 前面的是 Mutating Webhook,可以改一个对象的值,而 Validating Webhook 是不可以修改对象的值,不生效的。 更加详细的请求处理流程: 📜 对上面的解释: 如何处理API请求:API源码存在于kubernetes/pkg/api路径中,会处理集群内以及集群外客户端的请求。 那么,当HTTP请求到达Kubernetes API时,具体会发现什么呢?从上层看,会发现以下交互: HTTP请求由一串过滤器(filters)进行处理,这些过滤器注册在DefaultBuildHandlerChain()(参阅源码:https://github.com/kubernetes/apiserver中的config.go)中,并执行相应的处理。过滤器要么会将信息传递并附加到ctx.RequestInfo上(例如通过了身份认证的用户),要么返回适当的HTTP响应代码。 第二步,复用器(multiplexer,参阅源码:https://github.com/kubernetes/apiserver中的container.go)会根据HTTP路径,将HTTP请求路由到相应的处理程序(handler)。 第三步,routes(在routes/*中定义)会将处理程序(handler)与HTTP路径进行连接。 第四步,按照API Group进行注册的处理程序(参阅源码:https://github.com/kubernetes/apiserver中的groupversion.go和installer.go),会处理HTTP请求和上下文(context,如user、rights等),并将请求的对象从存储中传送出来。 注意,为了简洁,在上图中我们省略了HTTP路径中的$NAMESPACE字段。 现在我们进一步深入的对前文中提到的DefaultBuildHandlerChain()中建立的过滤器(filters)进行介绍: **WithRequestInfo():**在requestinfo.go中定义,将RequestInfo附加到上下文中。 **WithMaxInFlightLimit():**在maxinflight.go中定义,对当前的请求数量进行限制。 **WithTimeoutForNonLongRunningRequests():**在timeout.go中定义,超时暂停非长时间运行请求(如大多数GET,PUT,POST,DELETE请求),这种请求与长时间运行请求(如watch和proxy请求)正好相反。 **WithPanicRecovery():**在wrap.go中定义,包装一个http Handler来恢复和记录报错。 **WithCORS():**在cors.go中定义,提供了一个CORS实现;CORS代表跨原始资源共享(Cross-Origin Resource Sharing),是一种允许嵌入在HTML页面中的JavaScript生成XMLHttpRequests请求到一个域(domain)的机制,这个域不同于JavaScript的初始起源。 **WithAuthentication():**在authentication.go中定义,尝试以用户身份对给定的请求进行验证,并将用户信息存储在提供的上下文中。成功后,授权HTTP header将从请求中删除。 **WithAudit():**在audit.go中定义,使用所有传入请求的审计日志信息来充实handler。审计日志的条目包含很多信息,例如请求的源IP、调用操作的用户信息以及请求的命名空间等。 **WithImpersonation():**在impersonation.go中定义,通过检查试图对用户进行修改的请求(类似sudo),来对假用户进行处理; **WithAuthorization():**在authorization.go中定义,将所有授权的请求传递给已经将请求分发给正确的handler的复用器,否则返回禁止错误(forbidden error)。 认证 开启TLS时,所有的请求都需要首先认证。 Kubernetes支持多种认证机制,并支持同时开启多个认证插件(只要有一个认证通过即可)。如果认证成功,则用户的username会传入授权模块做进一步授权验证;而对于认证失败的请求则返回HTTP 401。 认证插件 我们上一节学的 ETCD ,知道 ETCD 作为 Kubernetes 的数据库,多么的重要:...

九月 28, 2023 · 7 分钟 · 1401 字 · 熊鑫伟,我

深入了解Kubernetes等组件之ETCD

开始前 ETCD 是 Kubernetes 中所有组件中最难的,因为 ETCD 是有状态的,而不是无状态的。 我在之前做 k3s runtime 设计的时候,了解了一些关于 ETCD 和 Raft 算法相关的概念,作为前奏知识,请分别前往 ETCD 以及 Raft算法 进行前奏学习。 这一篇来深入并且贯穿的讲解 ETCD 和 Raft。并且站在 Kubernetes 的角度来深入 剖析 ETCD。 ETCD 介绍 Etcd是CoreOS基于Raft开发的分布式key-value存储,可用于服务发现、共享配置以及一致性保障(如数据库选主、分布式锁等)。 包含的功能以及特性 前奏 都有学过,看下 Kubernetes 最关心的 存储: 主要功能 基本的key-value存储 监听机制 key的过期及续约机制,用于监控和服务发现 原子Compare And Swap和Compare And Delete,用于分布式锁和leader选举 使用场景 可以用于键值对存储,应用程序可以读取和写入 etcd 中的数据 etcd 比较多的应用场景是用于服务注册与发现 基于监听机制的分布式异步系统 etcd 是一个键值存储的组件,其他的应用都是基于其键值存储的功能展开。 采用kv型数据存储,一般情况下比关系型数据库快。 支持动态存储(内存)以及静态存储(磁盘)。 分布式存储,可集成为多节点集群。 存储方式,采用类似目录结构。(B+tree) 只有叶子节点才能真正存储数据,相当于文件。 叶子节点的父节点一定是目录,目录不能存储数据。 服务注册与发现: 强一致性、高可用的服务存储目录。 基于 Raft 算法的 etcd 天生就是这样一个强一致性、高可用的服务存储目录。 一种注册服务和服务健康状况的机制。 用户可以在 etcd 中注册服务,并且对注册的服务配置 key TTL,定时保持服务的心跳以达到监控健康状态的效果。 消息发布订阅:...

九月 26, 2023 · 6 分钟 · 1264 字 · 熊鑫伟,我

在开源社区中学会如何提问

author(Github) 在提问之前 在你准备要通过电子邮件、新闻群组或者聊天室提出技术问题前,请先做到以下事情: 尝试在你准备提问的论坛的旧文章中搜索答案。 尝试上网搜索以找到答案。 尝试阅读手册以找到答案。 尝试阅读常见问题文件(FAQ)以找到答案。 尝试自己检查或试验以找到答案。 向你身边的强者朋友打听以找到答案。 如果你是程序开发者,请尝试阅读源代码以找到答案。 当你提出问题的时候,请先表明你已经做了上述的努力;这将有助于树立你并不是一个不劳而获且浪费别人的时间的提问者。如果你能一并表达在做了上述努力的过程中所学到的东西会更好,因为我们更乐于回答那些表现出能从答案中学习的人的问题。 运用某些策略,比如先用 Google 搜索你所遇到的各种错误信息(搜索 Google 论坛和网页),这样很可能直接就找到了能解决问题的文件或邮件列表线索。即使没有结果,在邮件列表或新闻组寻求帮助时加上一句 我在 Google 中搜过下列句子但没有找到什么有用的东西 也是件好事,即使它只是表明了搜索引擎不能提供哪些帮助。这么做(加上搜索过的字串)也让遇到相似问题的其他人能被搜索引擎引导到你的提问来。 别着急,不要指望几秒钟的 Google 搜索就能解决一个复杂的问题。在向专家求助之前,再阅读一下常见问题文件(FAQ)、放轻松、坐得舒服一些,再花点时间思考一下这个问题。相信我们,他们能从你的提问看出你做了多少阅读与思考,如果你是有备而来,将更有可能得到解答。不要将所有问题一股脑拋出,只因你的第一次搜索没有找到答案(或者找到太多答案)。 准备好你的问题,再将问题仔细的思考过一遍,因为草率的发问只能得到草率的回答,或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力,你越有可能得到实质性的帮助。 小心别问错了问题。如果你的问题基于错误的假设,某个普通黑客(J. Random Hacker)多半会一边在心里想着蠢问题…,一边用无意义的字面解释来答复你,希望着你会从问题的回答(而非你想得到的答案)中汲取教训。 绝不要自以为够格得到答案,你没有;你并没有。毕竟你没有为这种服务支付任何报酬。你将会是自己去挣到一个答案,靠提出有内涵的、有趣的、有思维激励作用的问题 —— 一个有潜力能贡献社区经验的问题,而不仅仅是被动的从他人处索取知识。 另一方面,表明你愿意在找答案的过程中做点什么是一个非常好的开端。谁能给点提示?、我的这个例子里缺了什么?以及我应该检查什么地方比请把我需要的确切的过程贴出来更容易得到答复。因为你表现出只要有人能指个正确方向,你就有完成它的能力和决心。 当你提问时 慎选提问的论坛 小心选择你要提问的场合。如果你做了下述的事情,你很可能被忽略掉或者被看作失败者: 在与主题不合的论坛上贴出你的问题。 在探讨进阶技术问题的论坛张贴非常初级的问题;反之亦然。 在太多的不同新闻群组上重复转贴同样的问题(cross-post)。 向既非熟人也没有义务解决你问题的人发送私人电邮。 黑客会剔除掉那些搞错场合的问题,以保护他们沟通的渠道不被无关的东西淹没。你不会想让这种事发生在自己身上的。 因此,第一步是找到对的论坛。再说一次,Google 和其它搜索引擎还是你的朋友,用它们来找到与你遭遇到困难的软硬件问题最相关的网站。通常那儿都有常见问题(FAQ)、邮件列表及相关说明文件的链接。如果你的努力(包括阅读 FAQ)都没有结果,网站上也许还有报告 Bug(Bug-reporting)的流程或链接,如果是这样,链过去看看。 向陌生的人或论坛发送邮件最可能是风险最大的事情。举例来说,别假设一个提供丰富内容的网页的作者会想充当你的免费顾问。不要对你的问题是否会受到欢迎做太乐观的估计 —— 如果你不确定,那就向别处发送,或者压根别发。 在选择论坛、新闻群组或邮件列表时,别太相信它的名字,先看看 FAQ 或者许可书以弄清楚你的问题是否切题。发文前先翻翻已有的话题,这样可以让你感受一下那里的文化。事实上,事先在新闻组或邮件列表的历史记录中搜索与你问题相关的关键词是个极好的主意,也许这样就找到答案了。即使没有,也能帮助你归纳出更好的问题。 别像机关枪似的一次“扫射”所有的帮助渠道,这就像大喊大叫一样会使人不快。要一个一个地来。 搞清楚你的主题!最典型的错误之一是在某种致力于跨平台可移植的语言、套件或工具的论坛中提关于 Unix 或 Windows 操作系统程序界面的问题。如果你不明白为什么这是大错,最好在搞清楚这之间差异之前什么也别问。 一般来说,在仔细挑选的公共论坛中提问,会比在私有论坛中提同样的问题更容易得到有用的回答。有几个理由可以支持这点,一是看潜在的回复者有多少,二是看观众有多少。黑客较愿意回答那些能帮助到许多人的问题。 可以理解的是,老练的黑客和一些热门软件的作者正在接受过多的错发信息。就像那根最后压垮骆驼背的稻草一样,你的加入也有可能使情况走向极端 —— 已经好几次了,一些热门软件的作者由于涌入其私人邮箱的大量不堪忍受的无用邮件而不再提供支持。 Stack Overflow 搜索,然后在 Stack Exchange 问。 近年来,Stack Exchange 社区已经成为回答技术及其他问题的主要渠道,尤其是那些开放源码的项目。 因为 Google 索引是即时的,在看 Stack Exchange 之前先在 Google 搜索。有很高的几率某人已经问了一个类似的问题,而且 Stack Exchange 网站们往往会是搜索结果中最前面几个。如果你在 Google 上没有找到任何答案,你再到特定相关主题的网站去找。用标签(Tag)搜索能让你更缩小你的搜索结果。...

九月 17, 2023 · 4 分钟 · 826 字 · 熊鑫伟,我

自动化的高级追求: 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 更加出众。可以测试、批处理、工件发布的作业执行。...

九月 16, 2023 · 4 分钟 · 847 字 · 熊鑫伟,我

一份完整的开源贡献指南(提供给第一次踏入开源伙伴秘籍)

任务分配 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 搭建单机环境即可。 kubernetes 入门文档:https://kubernetes.io/docs/tutorials/kubernetes-basics/ 安装部分跳过直接使用 sealos 一键构建。...

九月 16, 2023 · 6 分钟 · 1104 字 · 熊鑫伟,我