8

我正在用 pycharm 编写一个烧瓶 API。当我在本地运行我的代码时，使用 boto3 从秘密管理器获取秘密的请求不到一秒钟。但是，当我将代码放在 EC2 上时，大约需要 3 分钟（在 t2.micro 和 m5.large 中都尝试过）。

起初我认为这可能是 Python 问题，所以我通过 awscli 在我的 EC2 中运行它：

aws secretsmanager get-secret-value --secret-id secretname

大约花了3分钟。为什么会这样？理论上这不应该在 EC2 中比在我的本地机器中更快吗？

编辑：这仅在 EC2 位于不同于默认 VPC 的 VPC 内时发生。

4

3 回答 3

12

在我们的本地机器上与同样的问题斗争了将近两个月之后，我们今天终于取得了一些进展。

事实证明，问题与 IPv6 有关。

如果您使用的是 IPv6，则机密管理器域将解析为 IPv6 地址。由于某种原因，cli 无法使用 IPv6 建立安全连接。超时后，cli 回退到 IPv4，然后成功。

要验证您是否解析到 IPv6 地址，只需 ping secretsmanager.us-east-1.amazonaws.com。不用担心 ping 响应，您只想查看域解析到的 IP 地址。

要解决此问题，您现在有 3 个选项：

  1. 找出您的网络问题。这可能是您的机器或路由器上的某些东西。如果在 AWS VPC 中，请检查您的路由表和安全组。确保您允许出站 IPv6 流量 (::/0)。
  2. 减少 cli 连接超时以使 IPv6 调用更快失败。这将使 IPv4 回退更快发生。您可能想要提供更好的超时值，但总体思路是添加如下内容：--cli-connect-timeout 1
  3. 禁用 IPv6。您可以在您的机器/路由器上完全禁用 IPv6，或者您可以调整您的机器以首选 IPv4 用于此特定地址（请参阅：https ://superuser.com/questions/436574/ipv4-vs-ipv6-priority-in-窗户7）。

最终，选项 1 是真正的解决方案，但由于它如此广泛，其他选项可能更容易。

希望这可以帮助其他人在遇到此问题时保持理智。

于 2018-11-14T22:08:57.253 回答
3

我在通过 Cisco AnyConnect VPN 客户端在家工作时遇到了这个问题。显然它会阻止任何 IPv6。

我的解决方案是在我的笔记本电脑上完全禁用 IPv6。

为 macOS 执行此操作：

networksetup -setv6off Wi-Fi  # wireless
networksetup -setv6off Ethernet  # wired

重新启用：

networksetup -setv6automatic Wi-Fi  # wireless
networksetup -setv6automatic Ethernet  # wired
于 2020-01-10T12:27:03.073 回答
0

我从自己的计算机和t2.nano该区域的 Amazon EC2 实例运行了以下命令ap-southeast-2：

aws secretsmanager create-secret --name foo --secret-string 'bar' --region ap-southeast-2
aws secretsmanager get-secret-value --secret-id foo --region ap-southeast-2
aws secretsmanager delete-secret --secret-id foo --region ap-southeast-2

在这两种情况下，每个命令都会在一秒钟内返回。

额外的：

为了测试您的情况，我做了以下（在悉尼地区）：

  • 使用 VPC 向导创建了一个新的 VPC（只是一个公共子网）
  • 在新 VPC 中启动了一个新的 Amazon EC2 实例，角色授予访问 Secrets Manager 的权限
  • 在实例上升级了AWS CLI（安装的版本不知道secretsmanager
  • 运行上述命令

他们都立即返回。

因此，问题在于您的实例或 VPC。

于 2018-05-06T23:52:31.343 回答