Добавьте Пару ключей к существующему экземпляру EC2

Ответ, предоставленный @aisby. Я использовал кавычки в переданном параметре.

Дата, которую вы передаете в своем URL, не соответствует формату '2019-03-18 00:00:01'. Попробуйте перейти по этому URL-адресу ... localhost: 8080 / its /… ... У меня есть URL, закодированный датой 2019-03-18 00:00:01 в строке запроса. Я вижу, что ваш комментарий показывает строку запроса даты, начинающуюся с% 27, которая представляет собой одинарную кавычку в кодировке URL. Вы должны отправлять значение только в переменных строки запроса. Не одиночные или двойные кавычки. - asiby 18 часов назад

224
задан gvasquez 4 July 2017 в 23:21
поделиться

2 ответа

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

Для восстановления, если это загрузочный AMI EBS, вы можете остановить его, сделав снимок тома. Создайте на его основе новый том. И иметь возможность использовать его обратно, чтобы запустить старый экземпляр, создать новый образ или восстановить данные.

Хотя данные при кратковременной памяти будут потеряны.


Из-за популярности этого вопроса и ответа я хотел зафиксировать информацию из ссылки, которую Родни разместил в своем комментарии.

Благодарим Эрика Хаммонда за эту информацию .

Исправление файлов на корневом томе EBS экземпляра EC2

Вы можете проверять и редактировать файлы на корневом томе EBS на экземпляре EC2, даже если вы находитесь в ситуации, которую вы считали катастрофической, например:

  • Вы проиграли ваш ключ ssh или забыли пароль
  • Вы допустили ошибку при редактировании файла / etc / sudoers и больше не можете получить root-доступ с помощью sudo, чтобы исправить это
  • Ваш долго работающий экземпляр завис по какой-то причине, не может быть связался, и не загружается должным образом
  • Вам нужно восстановить файлы из экземпляра, но вы не можете к нему добраться

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

Однако удаленный экземпляр EC2 кажется далеким и недоступным, когда вы находитесь в одной из этих ситуаций. К счастью, AWS предоставляет нам мощность и гибкость, позволяющие восстанавливать подобную систему, при условии, что мы запускаем загрузочные экземпляры EBS, а не хранилище экземпляров.

Подход на EC2 в некоторой степени похож на физическое решение, но мы собираемся переместить и смонтировать неисправный «жесткий диск» (корневой том EBS) в другой экземпляр, исправить его, а затем переместить обратно.

В некоторых ситуациях может быть проще запустить новый экземпляр EC2 и выбросить плохой, но если вы действительно хотите исправить свои файлы, вот подход, который сработал для многих:

Setup

Определите исходный экземпляр (A) и том, содержащий сломанный корневой том EBS, с файлами, которые вы хотите просмотреть и отредактировать.

instance_a=i-XXXXXXXX

volume=$(ec2-describe-instances $instance_a |
  egrep '^BLOCKDEVICE./dev/sda1' | cut -f3)

Определите второй экземпляр EC2 (B), который вы будете использовать для исправления файлов на исходном томе EBS. Этот экземпляр должен работать в той же зоне доступности, что и экземпляр A, чтобы к нему можно было присоединить том EBS. Если у вас еще нет запущенного экземпляра, запустите временный.

instance_b=i-YYYYYYYY

Остановите сломанный экземпляр A (ожидая его полной остановки), отсоедините корневой том EBS от экземпляра (ожидая его отсоединения), затем присоедините том к экземпляру B на неиспользуемом устройстве.

ec2-stop-instances $instance_a
ec2-detach-volume $volume
ec2-attach-volume --instance $instance_b --device /dev/sdj $volume

ssh к экземпляру B и смонтируйте том, чтобы получить доступ к его файловой системе.

ssh ...instance b...

sudo mkdir -p 000 /vol-a
sudo mount /dev/sdj /vol-a

Исправить

На этом этапе вся ваша корневая файловая система из экземпляра A доступна для просмотра и редактирования в / vol-a в экземпляре B. Например, вы можете захотеть:

  • Вставить правильные ключи ssh в /vol-a/home/ubuntu/.ssh/authorized_keys
  • Отредактируйте и исправьте / vol-a / etc / sudoers
  • Найдите сообщения об ошибках в / vol-a / var / log / syslog
  • Копировать важные файлы из / vol-a /…

Примечание: идентификаторы uid в двух экземплярах могут не совпадать, поэтому будьте осторожны, если вы создаете, редактируете или копируете файлы, принадлежащие пользователям без полномочий root. Например, ваш пользователь mysql в экземпляре A может иметь тот же UID, что и ваш пользователь postfix в экземпляре B, что может вызвать проблемы, если вы загрузите файлы с одним именем, а затем переместите том обратно в A.

Заключение

После того, как вы закончите и будете довольны файлами в / vol-a, отключите файловую систему (все еще в экземпляре-B):

sudo umount /vol-a
sudo rmdir /vol-a

Теперь вернитесь в вашу систему с помощью ec2-api -tools, продолжайте перемещать том EBS обратно в исходное положение на исходном экземпляре A и снова запустите экземпляр:

ec2-detach-volume $volume
ec2-attach-volume --instance $instance_a --device /dev/sda1 $volume
ec2-start-instances $instance_a

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

Примечание. Если у вас был эластичный IP-адрес, назначенный экземпляру A, когда вы его остановили, вам потребуется повторно связать его после повторного запуска.

Помните! Если ваш экземпляр B был временно запущен только для этого процесса, не забудьте завершить его сейчас.

168
ответ дан 23 November 2019 в 03:58
поделиться

Можно на самом деле добавить пару ключей через эластичную страницу конфигурации бобового стебля. это затем перезапускает Ваш экземпляр для Вас, и все работает.

0
ответ дан 23 November 2019 в 03:58
поделиться
Другие вопросы по тегам:

Похожие вопросы: