返回首页
最新
错误：循环：aws_security_group.app -> aws_security_group.db -> aws_security_group.app
如果你在将AWS基础设施导入Terraform时遇到这个错误，你一定知道这种痛苦。
Terraform的核心引擎依赖于有向无环图（DAG）。它需要知道：“先创建A，然后创建B。”
但是AWS是最终一致的，并且乐于允许循环的存在。
死锁
最常见的罪魁祸首是安全组。想象一下两个微服务：
- SG-App允许向SG-DB的出站流量
- SG-DB允许来自SG-App的入站流量
如果你用内联规则编写这个（这是terraform import的默认行为），你就会创建一个循环：
```hcl
resource "aws_security_group" "app" {
egress {
security_groups = [aws_security_group.db.id]
}
}
resource "aws_security_group" "db" {
ingress {
security_groups = [aws_security_group.app.id]
}
}
```
Terraform无法应用这个配置。它无法在没有db的ID的情况下创建app，反之亦然。
图论视角
在构建一个基础设施反向工程工具时，我意识到我不能仅仅将API响应直接转储为HCL。我们将AWS建模为一个图：节点是资源，边是依赖关系。
在一个健康的配置中，依赖关系是一个DAG：
[VPC] --> [Subnet] --> [EC2]
但安全组往往会形成循环：
```
┌──────────────┐
▼ │
[SG-App] [SG-DB]
│ ▲
└──────────────┘
```
寻找“结”
为了为数千个资源解决这个问题，我们使用Tarjan算法来查找强连通分量（SCCs）。它识别出“结”——循环依赖的节点集群——并将其标记以进行处理。
在我们的测试中，一个典型的企业AWS账户拥有500多个安全组，通常包含3到7个这样的集群。
解决方案：“壳与填充”
我们使用一种策略来打破循环：
1. 创建空壳：生成没有规则的安全组。Terraform会立即创建这些。
2. 用规则填充：将规则提取到单独的aws_security_group_rule资源中，并引用这些壳。
```hcl
第一步：创建壳
[SG-App (空)] [SG-DB (空)]
第二步：创建规则
▲ ▲
│ │
[规则：出站->DB] [规则：入站<-App]
```
现在图是无环的。
“为什么不总是使用单独的规则？”
这是个合理的问题。问题在于：
1. terraform import通常生成内联规则。
2. 许多现有代码库更喜欢内联规则以提高可读性。
3. AWS API呈现的是“逻辑”视图（规则捆绑在一起）。
该工具需要检测循环并仅对有问题的部分进行处理。
为什么terraform import不够
标准导入按原样读取状态。它不会在生成代码之前构建全局依赖图或执行拓扑排序。它将重构的负担放在了人类身上。对于拥有2000多个资源的现有迁移，这并不可行。
---
我在一个名为RepliMap的工具中实现了这个图引擎。我已经开源了运行只读扫描所需的文档和IAM策略。
如果你对像这样的边缘案例（或root_block_device陷阱）感兴趣，仓库在这里：
https://github.com/RepliMap/replimap-community
欢迎提问。
嗨，HN，
我正在构建 Formtone，这是一个表单后端，能够分析表单响应并提取通常被埋没的重要信息。
一旦表单开始接收到大量真实反馈（如支持请求、反馈、评论），逐一阅读每一份提交就变得不可行。重要问题可能会被遗漏，所有内容似乎都变得同样紧急。用户可能会以多种不同的方式指出同一个问题或请求同一功能，而手动筛选往往无法捕捉到这些。
Formtone 处理输入文本并：
- 检测情感
- 评分优先级
- 将响应分类到用户定义的类别中
- 总结响应内容
- 草拟建议回复
- 基于重复模式提供可行的见解
它还会跟踪每个表单每周的情感变化，并找出最常见的问题。
它通过简单的 API 或 webhook 与任何表单配合使用，并可以将见解推送到 Slack 或 Discord 等工具。
我特别希望得到以下方面的反馈：
- 这是否解决了你们的实际问题
- 你希望首先提取哪些信号
- 你目前是如何处理表单反馈的
欢迎提问。感谢你的关注。
开发了一款现代化的网络应用，帮助巴基斯坦的用户计算移动设备的进口税。巴基斯坦电信管理局（PTA）根据用户的身份类型，要求缴纳18%至47%不等的税费。