Менеджер секретов очень медленно в EC2 через awscli и boto3 - PullRequest
Новая
       44

Менеджер секретов очень медленно в EC2 через awscli и boto3

0 голосов
/ 06 мая 2018

Я пишу API фляги в Pycharm. Когда я запускаю свой код локально, запросы с использованием boto3 для получения секретов от менеджера секретов занимают меньше секунды. Однако когда я помещаю свой код в EC2, это занимает около 3 минут (пробовал как в t2.micro, так и в m5.large).

Сначала я подумал, что это может быть проблема с Python, поэтому я запустил его в своих EC2 через awscli, используя: 

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

Это заняло около 3 минут. Почему это происходит? Разве это теоретически не должно быть быстрее в EC2, чем на моей локальной машине?

EDIT: Это происходит только тогда, когда EC2 находится внутри VPC, отличного от VPC по умолчанию.

Ответы [ 2 ]

0 голосов
/ 15 ноября 2018

После борьбы с этой же проблемой на наших локальных машинах в течение почти двух месяцев мы наконец-то достигли определенного прогресса сегодня.

Оказывается, проблема связана с IPv6.

Если вы используете IPv6, домен диспетчера секретов будет преобразован в адрес IPv6. По какой-то причине клиент не может установить безопасное соединение с использованием IPv6. По истечении этого времени cli возвращается к IPv4, а затем успешно.

Чтобы проверить, разрешаете ли вы адрес IPv6, просто отправьте команду ping secretsmanager.us-east-1.amazonaws.com. Не беспокойтесь об ответе ping, вы просто хотите увидеть IP-адрес, к которому относится домен.

Чтобы решить эту проблему, у вас есть 3 варианта:

  1. Выясните свои проблемы с сетью. Это может быть что-то на вашей машине или маршрутизаторе. Если вы используете AWS VPC, проверьте таблицы маршрутизации и группы безопасности. Убедитесь, что вы разрешаете исходящий трафик IPv6 (:: / 0).
  2. Сократите время ожидания соединения, чтобы ускорить сбой вызова IPv6. Это сделает возврат к IPv4 раньше. Возможно, вы захотите дать лучшее значение времени ожидания, но общая идея состоит в том, чтобы добавить что-то вроде этого: --cli-connect-timeout 1
  3. Отключить IPv6. Вы можете либо полностью отключить IPv6 на своем компьютере / маршрутизаторе, либо настроить свой компьютер так, чтобы он предпочитал IPv4 для этого конкретного адреса (см .: https://superuser.com/questions/436574/ipv4-vs-ipv6-priority-in-windows-7).

В конечном счете, вариант 1 - это реальное решение, но, поскольку оно настолько широкое, другие могут быть проще.

Надеюсь, это поможет кому-то еще обрести хоть немного здравомыслия, когда он его ударит.

0 голосов
/ 07 мая 2018

Я выполнил следующие команды со своего компьютера и из экземпляра Amazon EC2 t2.nano в регионе 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 (просто общедоступная подсеть)
  • Запущен новый экземпляр Amazon EC2 в новом VPC с ролью, предоставляющей разрешение на доступ к Secrets Manager
  • Обновлен AWS CLI на экземпляре (установленная версия не знала о secretsmanager
  • Запустил вышеуказанные команды

Они все немедленно вернулись .

Следовательно, проблема связана с тем, что связано с вашими экземплярами или вашим VPC.

...