python pulumi

# 聊聊Pulumi当Python遇上基础设施最近几年基础设施即代码这个概念越来越火各种工具层出不穷。今天想聊的是一个比较有意思的工具——Pulumi特别是它和Python结合使用时的那种感觉。它到底是什么Pulumi本质上是一个基础设施即代码的平台但它的特别之处在于它让你可以用真正的编程语言来定义和管理云资源。不是YAML不是JSON也不是某种特定的领域特定语言而是像Python、TypeScript、Go这样的通用编程语言。这听起来可能没什么大不了的但实际用起来会发现这完全改变了基础设施管理的体验。以前写CloudFormation或者Terraform配置文件时总觉得像是在填表格而现在你是在写程序。变量、函数、循环、条件判断——这些编程中最基本的概念现在都可以用来管理你的云资源。它能做什么想象一下这样的场景你需要为公司的十个不同环境开发、测试、生产等创建相似的AWS资源。传统的做法可能是复制粘贴十份配置文件然后小心翼翼地修改每个文件中的环境变量。用Pulumi的话你可以写一个Python函数接收环境名作为参数然后动态生成所有资源。它支持几乎所有主流的云平台——AWS、Azure、Google Cloud还有Kubernetes、Docker这些。你可以用同一套代码管理虚拟机、数据库、存储桶、网络配置甚至整个Kubernetes集群的部署。更妙的是Pulumi不只是创建资源它还管理资源的整个生命周期。当你修改代码后重新部署Pulumi会计算出需要创建、更新或删除哪些资源然后按正确的顺序执行这些操作。它会维护一个状态文件记录当前部署的资源情况有点像数据库的迁移脚本管理数据库结构的变化。怎么开始使用安装Pulumi很简单pip install pulumi就行。不过真正开始前需要先配置云提供商的凭证这和你直接使用AWS CLI或者Azure CLI时的配置是一样的。创建一个新项目通常从pulumi new命令开始选择Python模板然后你就得到了一个标准的Python项目结构。主文件通常叫__main__.py在这里你可以导入pulumi的各种模块开始定义你的基础设施。定义资源的方式很直观。比如要创建一个S3存储桶代码大概长这样importpulumiimportpulumi_awsasaws bucketaws.s3.Bucket(my-bucket,websiteaws.s3.BucketWebsiteArgs(index_documentindex.html))pulumi.export(bucket_name,bucket.id)这看起来就像在调用一个普通的Python库。运行pulumi up命令Pulumi会分析代码生成执行计划然后询问你是否确认部署。确认后它就会在AWS上创建实际的S3存储桶。真正强大的地方在于你可以在定义资源时使用所有的Python特性。比如根据某些条件决定是否创建某个资源或者用循环批量创建相似的资源。这种灵活性是传统的配置文件很难提供的。一些实践中的体会用了一段时间后发现有些做法能让Pulumi用起来更顺手。首先是把基础设施代码当作真正的软件项目来管理。这意味着要有良好的项目结构把相关的资源组织到不同的模块或类中。比如可以把所有网络相关的资源放在一个模块数据库相关的放在另一个模块。测试也很重要。虽然测试基础设施代码和测试业务逻辑代码不太一样但基本的单元测试还是可以做的。Pulumi提供了一些测试工具可以模拟资源创建过程验证你的代码逻辑是否正确。状态管理是个需要注意的地方。Pulumi默认把状态文件存储在它自己的服务上有免费层这对于团队协作很方便。但如果你有特殊的安全要求也可以把状态文件存储在AWS S3、Azure Blob Storage或者Google Cloud Storage上。版本控制要跟上。每次部署前确保代码已经提交到版本控制系统。Pulumi的部署历史很有用但配合Git的提交历史能更清楚地知道每次变更的原因和背景。还有一个建议是不要试图一次性把所有基础设施都迁移到Pulumi。可以从一个小项目开始比如先管理几个S3存储桶熟悉了工作流程后再逐步扩大范围。这样风险可控学习曲线也更平缓。和其他工具的比较提到基础设施即代码很多人会想到Terraform。Terraform确实很流行它的HCL语言专门为基础设施管理设计生态也很成熟。但HCL毕竟是一种领域特定语言它的表达能力有限。当你需要复杂的逻辑时可能会觉得束手束脚。CloudFormation和ARM模板是AWS和Azure自家的解决方案和各自平台的集成很深。但它们的模板语言JSON或YAML写起来很冗长而且缺乏编程语言的灵活性。调试起来也比较麻烦。Pulumi的独特价值在于它让你用熟悉的编程语言来管理基础设施。如果你是Python开发者你不需要学习一门新语言就能直接开始管理云资源。你可以重用已有的编程技能使用熟悉的工具链IDE、调试器、测试框架等。不过Pulumi也不是没有缺点。因为它相对较新有些云服务的资源类型可能还没有完全支持或者支持得不如Terraform成熟。社区规模也比不上Terraform遇到问题时可能需要更多时间自己摸索。另一个考虑因素是团队技能。如果团队里都是开发者用Pulumi可能很自然。但如果团队里有专职的运维人员他们可能更习惯传统的配置文件方式。最后的一些想法用Pulumi的感觉有点像第一次用Docker的感觉——它改变了你思考和工作的方式。你不再是把基础设施当作一堆需要手动配置的服务器而是把它看作可以版本控制、可以测试、可以重复部署的代码。这种转变带来的好处是多方面的。基础设施变更变得更可预测、更可审计。团队协作变得更顺畅因为代码审查流程可以直接应用到基础设施代码上。文档也变得更准确因为代码本身就是最好的文档。当然任何工具都不是银弹。Pulumi最适合的场景是那些基础设施配置比较复杂需要一定编程逻辑来管理的项目。对于非常简单的部署可能传统的配置文件更直接。但总的来说Pulumi代表了一个值得关注的方向——基础设施管理的开发者体验正在变得越来越好。当开发者能够用自己最熟悉的工具和语言来管理基础设施时很多以前觉得麻烦的事情突然变得简单了。这或许就是技术进步最实在的体现。