[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f371fggnbqer0q":3},{"code":4,"message":5,"data":6,"timestamp":60},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":45,"summary_md":46,"topic":47,"github_topics":50,"license":56,"homepage":57,"updated_at":58,"history":59},"hashicorp\u002Fterraform",23,"Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.","Go",50111,10599,613,4608,[16,22,28,34,39],{"id":17,"title":18,"points":19,"comments":20,"posted_at":21},27433863,"Terraform 1.0",691,308,"2021-06-08",{"id":23,"title":24,"points":25,"comments":26,"posted_at":27},28425849,"Terraform is currently not reviewing community pull requests",249,117,"2021-09-05",{"id":29,"title":30,"points":31,"comments":32,"posted_at":33},37085382,"Terraform changes its license to Business Source License",8,1,"2023-08-11",{"id":35,"title":36,"points":37,"comments":32,"posted_at":38},19985149,"Terraform v0.12.0",7,"2019-05-22",{"id":40,"title":41,"points":42,"comments":43,"posted_at":44},10396194,"Terraform v0.6.4 released",5,0,"2015-10-15","面向需要以声明式配置可复现地创建、变更多云基础设施的团队。","## 解决什么问题\n很多团队的基础设施是在云控制台里点出来的，或者靠零散脚本堆出来的，结果环境无法复现、变更无法评审、依赖关系没人说得清。Terraform 的做法是：把资源的期望状态写成配置文件，和业务代码放在一起纳入版本管理；执行前先算出 plan，告诉你到底会改什么；确认后再按资源图并行下发。读 README 的规划、资源图、变更自动化几段，说的其实就是这一套状态收敛模型。\n\n## 有什么不同\n和命令式脚本或各家云 SDK 封装相比，它的核心是「声明目标状态 + 记录 state + 计算差异」，人写意图，工具算动作。和 AWS CloudFormation 这类云原生方案相比，同一套语言和工作流可以覆盖多个 provider，适合跨云或混合 SaaS 的场景。与同空间的其他多云工具相比，它把核心做得很薄，provider 以插件形式独立发布在 Registry 上——这是真正的架构取舍：core 稳定，但每种资源类型都依赖第三方插件，插件质量与发版节奏不由你控制。\n\n## 适合谁\n适合平台工程师和基础设施工程师：手上不止一套环境，希望在正常的 PR 流程里评审基础设施变更，并且愿意认真管理一份 state。也适合已有一定运维规范、想把云资源的生命周期拉齐到代码生命周期的团队。不适合只做一次性实验的个人、只用一个云且对官方原生工具满意的团队，以及无法接受把 state 当成关键运维数据的组织。如果你的需求是集群编排而非资源创建，应该看别的方向。\n\n## 上手成本\ncore 是一个 Go 二进制，README 里也明确说本仓库只包含 core（CLI 与图引擎）。provider 是独立插件，从 Registry 下载，因此网络访问和对第三方 provider 的信任是成本的一部分。state 需要存放位置——本地文件能用，但一旦多人协作就很快会被推向远程 backend 和加锁，这本身就意味着额外的基础设施和额外的故障面。README 基本是文档索引，没有性能、升级兼容或版本迁移方面的说明，这些得从 release notes 和生态里补。License 是 Business Source License 1.1，并非 OSI 认可的开源协议，License 政策严格的组织在标准化之前应先核对。项目足够成熟，但成熟和许可合规是两件事。\n\n## 点评\n这不是一个靠热度冲榜的新项目：2014 年创建，生态积累很深。HotRepo 的榜单上本月 Go 分类 +608 stars、排在第 23 位，属于稳定的持续关注而非爆发；社区声量最高的一次仍是 2021 年的 1.0 发布讨论（691 分、308 条评论）。可以把它当作已被大规模部署的基础设施来看待——真正的决策点不是它能不能用，而是它的 License、state 管理模型和插件供应链是否匹配你的组织。",{"slug":48,"name":49},"devops","运维与部署",[51,52,53,54,55],"cloud","cloud-management","graph","infrastructure-as-code","terraform","NOASSERTION","http:\u002F\u002Fdeveloper.hashicorp.com\u002Fterraform","2026-10-24T20:35:48Z",[],1792890818]