AWS EC2 Windows 10 не может получить доступ к метаданным

Что может объяснить, почему экземпляр EC2 под управлением Windows 10 не всегда имеет доступ к своим собственным метаданным или данным пользователя?

Я знаю, что пользовательские данные установлены правильно, потому что один и тот же сценарий использовался для примерно тридцати запусков экземпляров t2.nano и c4.xlarge: t2.nano никогда не сталкивался с проблемой чтения метаданных, но из трех попыток с c4.xlarge только один имел доступ к нему. Скрипт отличался только по имени экземпляра (по крайней мере, по истории git).

Я следовал приведенным ниже инструкциям, и даже из Powershell Uri не загружается (см. Рисунок 2).

Любая подсказка приветствуется.

Документация AWS по метаданным Сбои Powershell

Источник

4 ответа

Решение

Есть вызов скрипта InitializeInstance.ps1 это сбрасывает некоторую информацию о конфигурации.

Например, если экземпляр изменил подсети, он может работать неправильно из-за кэшированных правил маршрутизации. InitializeInstance.ps1 можно исправить это.

Источник

Мы столкнулись с той же проблемой на сервере Windows 2016 на EC2. Мы заметили, что шлюз по умолчанию на 169 IP-маршрутах (постоянный) указывает на несуществующий (старый?) IP-шлюз.

Мы изменили маршруты на шлюз по умолчанию основного адаптера, после этого метаданные экземпляра начали работать, и сервис AmazonSSMAgent снова работает.

Старая ситуация:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     172.16.3.129     172.16.3.152     15
     ....
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
  169.254.169.254  255.255.255.255     172.16.0.129      15
  169.254.169.250  255.255.255.255     172.16.0.129      15
  169.254.169.251  255.255.255.255     172.16.0.129      15

Обратите внимание, что шлюз на постоянных маршрутах для 169 указывает на IP, который не является значением по умолчанию для 0.0.0.0. Это 172.16.0.129 также не пингуется.

После изменения маршрута с использованием ИЗМЕНЕНИЯ маршрута:

route CHANGE 169.254.169.254 MASK 255.255.255.255  172.16.3.129 METRIC 15 IF 4 /P
route CHANGE 169.254.169.250 MASK 255.255.255.255  172.16.3.129 METRIC 15 IF 4 /P
route CHANGE 169.254.169.251 MASK 255.255.255.255  172.16.2.129 METRIC 15 IF 4 /P

Куда:

  • 172.16.3.129 - это шлюз по умолчанию на основном сетевом интерфейсе. Это будет отличаться в каждом случае.
  • И 4 в конце METRIC 15 IF 4 это идентификатор интерфейса основного адаптера, указанный в списке интерфейсов на маршруте PRINT, он также может быть разным для каждого экземпляра.

Теперь у нас есть:

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     172.16.3.129     172.16.3.152     15
....
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
  169.254.169.254  255.255.255.255     172.16.3.129      15
  169.254.169.250  255.255.255.255     172.16.3.129      15
  169.254.169.251  255.255.255.255     172.16.3.129      15
===========================================================================

Это в основном то, что для упомянутых ProgramData/Amazon/EC2-Windows/Launch/Module/Scripts/Add-Routes.ps1 скрипт делает.

Источник

Не могу редактировать Джона Ротенштейна, поэтому добавлю сюда,

Эта проблема была решена с моей стороны путем повторной инициализации экземпляра, это происходит, когда вы создаете образ в одной подсети или vpc и запускаете его в другой.

Предупреждение , что это изменит пароль администратора, убедитесь, что у вас есть доступ к необходимому ключу, чтобы получить новый пароль на консоли.

Чтобы инициализировать экземпляр только один раз:

      C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeInstance.ps1 -Schedule

чтобы инициализировать его при каждой загрузке

      C:\ProgramData\Amazon\EC2-Windows\Launch\Scripts\InitializeInstance.ps1 -SchedulePerBoot

документы: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2launch.html

после его запуска перезагружаем инстанс, получаем новый пароль из консоли, rdp внутри и можно получить метаданные и использовать aws s3 cli/powershell с присоединенной ролью IAM инстанса

Источник

Лучшим способом сделать это было бы запустить функцию AWS Add-Routes. Но для этого его сначала нужно импортировать.

Вы можете импортировать его и запустить в одном файле, например, из PowerShell на своем экземпляре, для которого метаданные недоступны;

      Import-Module c:\ProgramData\Amazon\EC2-Windows\Launch\Module\Ec2Launch.psm1 ; Add-Routes

ЭтотAdd-RoutesФункция — это то, что запускает сценарий InitializeInstance.ps1 для исправления метаданных.

К вашему сведению, я постоянно сталкиваюсь с этой проблемой на Windows 2019 Server и чувствую, что это проблема на стороне AWS, где иногда экземпляры раскручиваются и не всегда завершают инициализацию облака. Это часто используемая команда для групп ASG и т. д.

Преимущество этого по сравнению с ответом @John Rotenstein заключается в том, что он будет запускать только маршруты, а не команду «Инициализировать диски», поэтому завершится быстрее.

Еще одно замечание, которое, возможно, было бы полезно добавить в этот пост: существует два способа получить метаданные экземпляра. Упомянутый выше метод IMDSv1 может не работать, если вы используете IMDSv2. Правильный способ получить метаданные для IMDSv2:

      PS C:\> [string]$token = Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token-ttl-seconds" = "21600"} -Method PUT -Uri http://169.254.169.254/latest/api/token

PS C:\> Invoke-RestMethod -Headers @{"X-aws-ec2-metadata-token" = $token} -Method GET -Uri http://169.254.169.254/latest/meta-data/

Документы по этому поводу здесь

Источник
Другие вопросы по тегам