返回首页
最新
错误：循环：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%不等的税费。
根据 https://www.githubstatus.com/history 的记录，今年到目前为止，GitHub 在22天中有13天出现了重大问题。这些问题需要单独的状态页面进行跟踪，但根据我的个人经验，几乎每天都能感受到服务的某种性能下降，尤其是在我当地时间的晚上。
作为一名长期付费的 GitHub 用户，我发现其稳定性多年来一直很差，而这种情况在最近有所加剧。GitHub 内部发生了什么？我们还能期待它会有所改善吗？
我在调试多模态AI API时为自己开发了这个工具。
问题是：我总是遇到包含Base64编码图像的JSON响应。每次都得复制字符串，找到在线解码器，粘贴，预览。每张图像都要重复这个过程，实在是太麻烦了。
于是我制作了ViewJSON。只需粘贴你的JSON，它会自动检测并内联渲染Base64媒体：图像、音频、视频，甚至PDF文件。再也不用进行复制粘贴和解码的循环了。
它还具备其他功能：
- 格式化/压缩JSON
- 粘贴图像，获取Base64字符串（反向操作）
- 构建API请求，复制为cURL
- 测试时的变量替换
- 通过URL分享JSON
无需登录，完全免费。欢迎对我可能遗漏的边缘案例提供反馈！
我正在部署能够调用外部API的AI代理——处理退款、发送电子邮件、修改数据库。代理根据用户输入和大语言模型的推理来决定采取什么行动。
我担心的是：代理有时会尝试一些不该做的操作，并且没有清晰的审计记录来说明它做了什么或为什么这样做。
我目前看到的选项有：
1. 完全信任代理（这很可怕）
2. 手动审核每一个操作（这违背了自动化的初衷）
3. 某种权限/审批层（这种东西存在吗？）
对于那些在生产环境中运行AI代理的人：
- 你们是如何限制代理可以做的事情的？
- 对于高风险操作，你们是否需要审批？
- 事后你们是如何审计发生了什么的？
我很想知道哪些模式是有效的。
嗨，HN——我开发了一个名为 SkillLens 的小型命令行工具，旨在帮助回答：“我安装了哪些代理技能，它们中有哪个是可疑的？”
许多代理生态系统（如 Claude、Codex、OpenCode 等）将技能存储为带有 SKILL.md 文件的文件夹。这些文件可能包含意想不到的强大指令（有时还可能包含不安全的模式），但一旦安装后容易被遗忘。我们通常会以 --dangerously-skip-permissions 的方式运行它们，并让它们安装任何想要的内容，但我对此有些焦虑，因此决定构建一个工具来让自己安心。
我决定不使用 AST 静态检查，而是使用您本地已有的任何命令行工具进行验证。
SkillLens 主要完成两件事：
1. 发现：它扫描常见的本地技能位置（可配置），并列出找到的内容。
2. 可选审计：如果您安装了审计工具（如 Claude 或 Codex），它会将每个 SKILL.md 文件（目前限制为约 12,000 个字符）发送给审计工具，并请求结构化的 JSON 输出：
- 判决：安全 | 可疑 | 不安全
- 风险：0–10
- 摘要 + 证据中的问题
它还会在本地缓存审计结果，因此重新运行时不会再次检查技能，除非这些技能被更新，您安装了新内容，或者您明确要求使用 --force 标志进行检查。
安装/运行：
```
npx skilllens scan
# 或者
pnpm dlx skilllens scan
```
注意事项/警告：
- v0.1；我仍在对提示/模式和“什么算作可疑”的启发式进行迭代。
- 今天它会将技能文本发送给您的审计工具（因此请将其视为与该提供者共享技能内容）。计划中有“编辑证据提取”，但尚未实现。
- 如果未安装审计工具，它仍然会生成扫描报告，并将审计标记为跳过。