很抱歉这个号鸽了很久,因为我从三月初开始在上海进入隔离状态,一直被隔离到六月初,前后历时 87 天,这 87 天的隔离使我感到十分的疲惫,所以休息了一段时间,在这段时间里除了工作,其余时间在做一些不费脑子的事情想要放松一下,所以很长时间没有更新了。后面我会逐步视情况开始恢复更新。2022 年 06 月 20-22 日在荷兰阿姆斯特丹,HashiCorp 举办了 HashiConf Europe 会议,本次会议恢复了线下会议,并且提供了线上回看。我在这里就简单汇报一下我走马观花看的几个点,和我的一些看法。想到哪里写到哪里,想多少写多少,不保证没有遗漏,也只代表我个人的主观看法,所以这不是一篇「关于 HashiConf Europe 2022 只要看这一篇就够了」的文章,感兴趣的朋友还是要自己去看一下回播。
HashiCorp 在过去的一年中最大的变化很明显是他们在纳斯达克上市了,股票代码 HCP,发行价 85 美元,最高价格 102.95,最低时 25.51,目前 32.77。这个表现当然不能说好,但我坚信云计算正在深刻地改变这个世界,而 HashiCorp 正在深刻地改变人们使用云的方式,所以我对 HashiCorp 的未来还是很有信心的(不构成投资建议)。
今年早些时候 HashiCorp 大约有 2000+ 名雇员,而这个数字是去年同期的大约四倍。可以说 HashiCorp 在过去一年中经历了爆炸式的扩张。看起来 HashiCorp 在 IPO 后获得了充沛的资金,可以大规模扩展团队,但同时我个人对这种扩张速度是捏了一把汗的,不知道他们能不能在扩张的同时保持原有的特色和质量。在过去的一年里 HashiCorp 的工具被下载了 2.5 亿次。即使把 Github Action 这样每次都是从头构建 CI 环境的因素考虑进来,这个数字都是一个非常了不起的成绩,这充分说明了 HashiStack 正在逐渐成为全球云计算的基础设施。
目前有约 20000+ 人通过了 HashiCorp 的考试取得了认证。目前有四种 HashiCorp 认证可以考取:
- HashiCorp Infrastructure Automation Certification:主要考核 Terraform 知识
- HashiCorp Security Automation Certification:主要考核 Vault 知识
- HashiCorp Networking Automation Certification:主要考核 Consul 知识
有趣的一点是,位列 HashiCorp 四大天王的 Nomad 至今仍然没有相关的考试。一方面可能是 Nomad 仍然在快速发展,所以还不太好确定考纲?或者是 Nomad 目前实际使用量仍然不足?总之我们注意到,四大天王中只有 Nomad 目前没有属于自己的 SaaS 版本,也没有属于自己的考试。其实在我看来,Nomad 实在是一个被严重低估了价值的任务编排平台,它的价值其实非常高,设计的极为巧妙,可以在 K8s 一统江湖的时代找到属于自己利基市场。
庞大的 Provider 生态是 Terraform 最坚固的护城河
目前有约 2000+ 个 Provider,构成了庞大的 Terraform 生态,或者说生态都已经不足以描述了,而是 Terraform 宇宙。如今的 Terraform 完全有资格说,他们不需要主动去对接某个产品或是某个平台,而是现如今如果某个产品或是某个平台不去对接 Terraform 那么在全球市场推广时会遭遇到极大的阻力(中国市场除外,中国已经与全球走上了不同的道路)。这种由大量社区主动贡献的 Provider 已经构成了 Terraform 强有力的护城河,任何后来的竞争者或是云平台自己都不可能与之竞争。像 Pulumi 或是 Crossplane 那样使用转换器复用 Terraform Provider 的做法才是最现实的,但这样做本身也是双刃剑,意味着 Provider 的标准定义权牢牢地掌握在 HashiCorp 的手里了。另外我们可以看到 HashiCorp 也正在逐步将这种模式推广到他们的其他产品中,例如 Packer 和 Vault 都开放了第三方的插件体系,只是目前还没有壮大到像 Terraform 那样可以组建独立的 HashiCorp Registry 的程度。3000+ 的付费用户,全球 2000 强中有 1/5 是 HashiCorp 的付费客户。HashiCorp 的商业战略是通过开源版本在喜欢激进地使用新技术的小团队中打磨自己的产品,然后提供满足大型企业需求的付费功能,在大客户身上获得持续的订阅收入。这一方面我就不多说了,总之据我所知一些全球超级巨头企业都是 HashiCorp 的付费客户,并且他们对 HashiCorp 产品的使用绝非买来装样子的,而是用的非常深入,也非常专业,某些客户的水平令我叹为观止。
如今的 HashiCorp 与其说是 IaC 厂商,不如说是多云部署与管理解决方案提供商。根据 HashiCorp 在 2021 年进行的一项调查 中得到的数据显示:HashiCorp 提出的 HashiStack 就是为应用开发与运维团队提供一个适合于多云的统一平台:这个统一的平台就是 HashiStack。HashiStack 将云端基础设施分为四个层次:基础设施、安全、网络以及应用编排。这四个层次主要通过 Terraform、Vault、Consul 以及 Nomad 来负责提供多云方案,并辅以 Packer、Boundary 以及 Waypoint 三个工具。基于这些工具的组合以及庞大的插件生态,HashiStack 可以运行在任意云平台,甚至是私有数据中心中,对外提供一致的统一的部署与维护模型。今天的 HashiCorp 的定位主要就是瞄准了多云,他为了应对 Aws Azure 这样的巨头的竞争所设立的护城河就是将 Terraform 打造成用云的入口点,发展出一套可以对接万物的插件生态,而这也是为什么他不惧怕大型云厂商与他竞争的原因,因为用户选择 Terraform 时选择的不是一种具体的工具,而是一种与基础设施交互的方式,进而选择 HashiCorp 的其他产品以避免供应商锁定。Aws 是公认的开源之敌,已经和 MongoDB、Redis、Elastic 多个开源厂商结下了梁子,但遇到 HashiCorp 这样的定位的开源厂商,Aws 毫无办法,反过来必须主动与之合作:
Terraform 1.2 引入的 precondition 与 postcondition
Terraform 1.2 中在 lifecycle
块中新增了对资源的验证能力:precondition
与 postcondition
。关于这两个新的语法我已经在我的电子书《Terraform 入门教程》中有过介绍,不过在发布会上 Armon Dadgar 的一段介绍让我突然意识到我原来对 postcondition
的理解还是不足的:Armon 举的例子是在创建 EC2 主机之后检查主分区的磁盘空间大小,防止比如运行数据库应用时会因为磁盘空间不足而遭遇错误。为什么这项检查要放在 postcondition
而不是 precondition
?这是因为根据文档:By default, the size of the root volume is determined by the size of the snapshot.
原先对 postcondition
没有做深入的思考,现在差不多明白它的设计目标就是为了验证那些只有在资源被创建完后,由服务端决定的资源属性的值是否符合预期。
Terraform 的哲学是:如果你使用 Terraform 创建基础设施,那么就应该始终使用 Terraform 来管理基础设施;所有将 Terraform 作为一种目标代码,使用其他工具生成 Terraform 代码的实践在 Terraform 官方看来都是异端,是不推荐的。但是在实际使用时的确会有许多的带外(Out of Band)变更,例如紧急状态下直接通过 GUI 或是命令行操作基础设施。这些带外变更如果没能及时被发现,那么在下一次执行 Terraform Apply 时会被改回原先的状态,这有可能会引发严重的后果。Terraform 付费版(特指 Terraform Cloud 以及 Terraform 企业版)中这次新增了配置漂移检测:配置漂移检测会定期检测代码描述的状态以及云端实际的状态之间是否存在不一致,如果发现了漂移则可以通过预先配置的通知方式通知团队进行处理。这项功能其实引出一个更有意思的问题:Terraform 实际上已经培育出一个以它为重要核心的新的 SaaS 生态,例如 Scalr、Snyk 或是中国的 Cloud IaC,他们都试图提供与 HashiCorp Terraform Cloud 相似的功能。例如配置漂移检测这样的功能上述几个平台有的已经实现了,有的承诺会予以实现,现在 HashiCorp 官方提供了这个功能,未来 HashiCorp 的 SaaS 与第三方的竞品将是一种什么关系?HashiCorp 本身是 Terraform 的开发者与维护者,他们可以对 Terraform 代码做深度集成和定制,例如 Terraform 付费版中的 Workspace 与开源版中的 Workspace 就是两个拥有相同名称但实际上可以说是完全不同的功能。面对原厂亲自下场做 SaaS 的挑战,第三方独立厂商又要如何寻找自己的定位?是打价格战吗?还是试图在产品设计上寻找突破口?又或是趁着 HashiCorp 目前没有在中国大陆地区发展 SaaS 业务占领一块足够大的半封闭市场?这个问题比配置漂移检测这个功能本身有意思的多。
Registry + HCP (HashiCorp Cloud Platform)
HashiCorp Sentinel 是 HashiCorp 推出的 Policy as Code 解决方案,通过 DSL 撰写基础设施需要遵守的合规,并且在 Terraform 付费版中对现存的代码以及状态文件进行检查,确保基础设施是合规的。目前 HashiCorp 推出了 Sentinel 代码的 Registry,社区可以像 Provider 那样浏览、使用、上传 Sentinel 代码。Packer 现在也可以把构建的镜像版本化地保存在属于 Packer 的 Registry 里,然后在 Terraform 中使用对应的 data
进行引用:Sentinel 与 Packer 都开始有属于自己的 Registry,我们可以清楚地理出 HashiCorp 商业化的路线:用 Registry 打造丰富的生态作为护城河,以 SaaS 服务作为主要营收手段,二者深度结合。这是以往很多开源工具企业想做但是没做好的,目前看 HashiCorp 已经确定了属于他的路线。
HashiCorp Nomad 可能是国内很少听到有人用的产品,如果要用最短的语言来介绍它,我想可以是:一个安装维护起来极其简单的与 K8s 相似的平台。但实际上这话过于简短以至于可能有些失真。Nomad 在很多功能上,比如网络,比 K8s 弱很多;而在某些功能上又强很多。Nomad 可以让团队用维护 K8s 集群 20% 的精力,得到一个拥有 K8s 80% 功能的调度平台,某些场景下它还可以做到 K8s 做不到的事。例如 Nomad 不止可以调度 Docker 容器,还可以调度虚拟机、普通的进程、甚至是传统的 Windows IIS 站点,甚至最近又宣布支持调度 Podman 容器和 WASM 程序。越来越多的团队开始使用 Nomad 管理他们的应用程序,甚至出现了将 Nomad Client 安装在树莓派上的案例:既然开始有人使用 Nomad 调度运行在嵌入式设备上的应用,那么必然会有人开始尝试使用 Nomad 建立云边一体的分布式应用:为了解决边缘节点与云计算平台之间网络连接不稳定的问题,Nomad 最新支持不稳定的网络连接:像这个例子里,Nomad 支持工作节点与集群服务器之间网络连接至多中断 12 小时。在 K8s 上我们当然也有边缘计算相关的产品,但 Nomad 胜在它部署维护相当简单,对小团队想要部署维护应用来说,简单性是一个非常巨大的优势。
在过去 Nomad 努力保持简单性,这里的简单性有两层意思,一层是 Nomad 无意与 K8s 竞争,另一层是自身代码实现与运维维护的简单,所以 Nomad 无意提供一个 K8s 这样庞大的体系,而是选择把很多功能交给其他社区工具来处理,例如它没有 K8s 原生的 Service、Ingress 等等网络功能,但在过去两年里逐步添加了对 CSI CNI 插件的支持。Nomad 过去的服务发现是通过集成 Consul 来完成的,如果我们要在 Nomad 上使用服务发现,最方便的做法是再部署一套 Consul 集群。另外如果要在 Nomad 中使用机密,例如数据库用户名密码、公有云的 AccessKey 和 SecretKey,那么最方便的做法是再部署一套 Vault 集群组合使用。这种做法使得 Nomad 本身的逻辑的确是简单了,但部署运维的复杂度就变高了,我们为了要使用完整的 Nomad 功能,必须额外部署维护 Consul 集群和 Vault 集群。Nomad 即将推出原生的服务发现功能以及机密变量功能。这些功能可以很好地应对小团队在初期的需求,同时当需求变得更复杂,要求更高时,迁移到 Consul 与 Vault 也只需要对任务配置文件进行很小的修改就可以完成。从这里可以看出,HashiCorp 对 Nomad 的态度似乎发生了些微的改变,开始逐渐增强 Nomad 的独立性。现在 Nomad 还没有属于自己的 HCP SaaS 服务,我个人猜测这可能是 Nomad 即将面临一些比较大的方向调整,所以目前 HashiCorp 认为将它做成云服务还不够稳定。
说起来这应该不是今年新发布的功能,但我平日里对 Nomad 的关注较少,所以很惭愧也是最近才知道的。对于这个功能我感到非常有趣,虽然我想不太出有什么实际应用场景,但可以看出来 WASM 逐渐成长为可以和容器掰掰腕子的一种应用打包分发运行形式了,Istio 里就已经支持 WASM 插件了,未来 WASM 非常有可能做到更多。
在过去 HashiCorp 每一个产品都会有属于自己的网站,我们可以在对应的网站上检索对应产品的文档。其次 HashiCorp 提供了一个非常棒的教学网站 https://learn.hashicorp.com/,我们可以在教学网站上找到 HashiCorp 所有产品的教程,而且说实话 HashiCorp 的教程是我见过的写的最好的,深入浅出,并且根据不同的场景设计了不同的学习线路。Armon 宣布 HashiCorp 准备推出一个统一的开发者网站 developer.hashicorp.com,未来 HashiCorp 所有产品的文档、教程、支持论坛都会被整合在一起。随着 HashiCorp 的产品线日益膨胀,文档和教程工程变得越来越难做,也越来越重要。MSDN 文档就变得非常混乱和冗长,我个人在日常工作时宁可去搜索第三方撰写的博客,也不太愿意阅读 MSDN 文档,更别提在 MSDN 里搜索了。开源软件企业要把文档和教程看作和产品代码同等重要的工作来抓,文档就好比是产品的宣传和广告,产品再好,用户学习曲线陡峭,还是很难推广。话说回来,HashiCorp 的某些产品的文档也开始有和代码脱节的情况出现了,比如某些 Terraform Provider 的文档,有不少改了代码实现但忘了同步更新文档的情况,可能需要提供更加自动化的工具来对文档进行分析和检测。
Armon 第二天的 Keynote 演讲主要围绕着 HashiCorp 的网络产品,或者说是零信任网络展开。我之前翻译的《HashiCorp 零信任白皮书》里已经有过简述,在此不再赘述细节。
Consul HCP on Azure 公测版发布
在之前 HashiCorp 发布的 HCP SaaS 服务基本上都只有 Aws 版本,而这次官宣公测的是 Consul HCP Azure 版本。HashiCorp 在 IPO 后招聘了大量的人员,看起来的确是打算一鼓作气扩展将 HCP 服务扩展到更多的公有云上,甚至在未来,由于 HashiCorp 的服务越来越接近于云计算基础设施,可能会出现三巨头(Aws、Azure、GCP)以外的公有云恳求 HashiCorp 将 HCP 接入他们的平台的情况(阿里云我在说你们)。国内云平台想要打入国际市场的话,不妨趁现在 HashiCorp 还没有成为一个巨头,很多合作还比较好谈的时候趁机搞好关系,主动接入 HCP 服务。(阿里云、华为云,甚至是火山引擎)
Boundary 宣布发布 HCP 公测版本(毫无意外)
我后面会尝试介绍 HashiCorp Boundary
Boundary 是一个用来解决人类访问云端系统的零信任解决方案,关于 Boundary 的介绍文章我将会在后面的时间里慢慢写。我曾经想过把 HashiCorp 四大天王(Terraform、Vault、Consul 和 Nomad)的文档翻译成中文,前年搞定了 Terraform,今年年初翻译了 Vault(翻译过程很累,感觉眼睛很疲劳,现在好像都没缓过来)。本来今年想歇歇的,但评上了 HashiCorp Ambassador 后感到一万年太久,只争朝夕,原本想继续开始学习 Consul 的,但中途想到国内总体来说对 HashiCorp 的产品还处在一个早期评估阶段,Terraform Vault 这样优秀的工具国内的接受程度都还不高,而 Consul 恐怕推广难度更高了。但是 Boundary 是我觉得一个比较不同的产品,它解决的问题很有可能是国内也会很感兴趣的,因为用「堡垒机」的概念去推销比较容易被国内理解和接受,所以有了先推广 Boundary 的想法。但因为长时间的封城,感到精神能量严重不足,所以一直耽搁到了现在。后面需要大家的鼓励,我慢慢把 Boundary 研究一下,争取为大家写出浅显易懂的入门教程。
全美 CEO 认为企业面临的最大威胁不是经济衰退,而是信息安全。美国人为什么不学中国搞私有云?不通公网不就都安全了?还需要搞什么零信任呀,都是小厂商造出来骗钱的概念[手动狗头]。发生过严重数据泄露的公司,有 95% 事后亡羊补牢开始使用 Vault。
所以说如果一家企业号称自己的数据是多么的重要,自己是如何重视信息安全和隐私保护的,但被发现他们没有使用 HashiCorp Vault,大概率是说谎或者无能,或者是说谎同时无能。
某些客户需要严格遵守合规,所有的加密密钥都必须保存在硬件加密模块(HSM)中,即使是 Vault 也不能读取,所以 Vault 现在支持将一些证书相关的操作托管给 HSM 完成。我想到本周为 Terraform Aks Module 提交的一个补丁,目的是要让测试代码符合 BridgeCrew Checkov 所规定的一个策略:国家通过立法,或者行业出台行业规范,用以给企业建立一个强制性的基础信息安全标准,现在看益处很大,否则信息安全很容易沦为可有可无的东西。国家应该考虑召集真正的行业专家,制定出细致的信息安全合规细则,强制执行,这对整个行业的发展大有益处。
HashiCorp 最近两年全力在推 HCP SaaS 服务,这应该是上市所要求的,必须在营收和利润上有持续的增长,而 SaaS 在美国是一个被证明了的好模式。有关 HashiCorp 的商业模式总结,这篇笔记。然而!Mitchell 在一次采访中,提出了非常非常关键的一点:不同阶段,你所需要的 enterprise 客户也是不一样的。
他说,早期客户就是你的 Design partners,所以他们对这些客户非常重视,两个 founder 都会经常到现场跟客户一起解决问题。每个季度都会定期去拜访,了解客户需求。
但是这些 enterprise 有什么特点呢?Mitchell用了一个非常有意思的名称:Hipster Enterprise (他说是别的地方听到的,但是我也没有Google出来……)。
什么是 Hipster Enterprise?他们非常 techical, 对新的趋势和新的技术非常敏感而且乐于尝试。他们对于早期跟你一起打磨产品,甚至做你的evangelist,都很积极。
但是但是但是!Hipster Enterprise 长期来看,的确不是什么好的客户。正是因为他们技术能力太强了,所以他们付费意愿都不会很强,也不会像其他典型的 enterprise 客户那样需要你的各种 support。
当你跟这些客户打磨好了以后,就可以转向真正典型的 enterprise, 比如Fortune 500 的公司。
对此,Mitchell提出了一个很好的警醒:不要被银行大「大单」冲昏了头脑,生意要做,但是不要忘了,你的 priority 仍然是要 build the machine,而不是服务一两个大客户。
中国软件行业的发展,或者说一个很经典的问题,为什么中国的 SaaS 产业发展的没有全球那么好?我想原因就出在在中国没有足够多口袋够深的大企业能在最后把 SaaS 的营收给做起来,所以你的产品打磨的再好,在中国最终可能还是找不到足够的大客户给你足够的营收和利润,这又反过来决定了在中国做软件或者做 SaaS 吸引不到足够多的资本和人才。所以我一贯的观点是,中国的云计算、SaaS 和软件需要的是需求侧改革,只有淘汰消灭落后的需求,这个行业才能有长足的发展。