Ответ 1
Вы не можете применить ключевую пару к исполняемому экземпляру. Вы можете использовать новую пару ключей для запуска нового экземпляра.
Для восстановления, если это AMI загрузочный AMI, вы можете остановить его, сделать снимок тома. Создайте новый том на основе этого. И сможете использовать его для запуска старого экземпляра, создания нового изображения или восстановления данных.
Хотя данные в эфемерном хранилище будут потеряны.
Из-за популярности этого вопроса и ответа я хотел зафиксировать информацию в ссылке, которую Родни опубликовал в своем комментарии.
Кредит переходит на Эрик Хаммонд для эту информацию.
Фиксация файлов на корневом EBS-диске экземпляра EC2
Вы можете просматривать и редактировать файлы на корневом EBS-томе на экземпляре EC2, даже если вы находитесь в том, что считаете катастрофической ситуацией, например:
- Вы потеряли свой ssh-ключ или забыли свой пароль.
- Вы сделали ошибку, отредактировав файл /etc/sudoers и больше не можете получить доступ root с помощью sudo, чтобы исправить его.
- Ваш длинный экземпляр по какой-то причине висит, не может быть связался и не смог нормально загрузиться
- Вам нужно восстановить файлы с экземпляра, но не можете добраться до него
На физическом компьютере, сидящем за вашим столом, вы можете просто загрузить систему с помощью CD или USB-накопителя, смонтировать жесткий диск, проверить и исправить файлы, а затем перезагрузить компьютер, чтобы вернуться в бизнес.
Удаленный экземпляр EC2, однако, кажется отдаленным и недоступным, когда вы находитесь в одной из этих ситуаций. К счастью, AWS предоставляет нам мощь и гибкость для восстановления такой системы, при условии, что мы запускаем экземпляры загрузки EBS, а не хранилище экземпляров.
Подход к EC2 несколько похож на физическое решение, но он собирается перемещать и монтировать неисправный "жесткий диск" (корень EBS) в другой экземпляр, исправлять его, а затем перемещать назад.
В некоторых ситуациях проще просто запустить новый экземпляр EC2 и выбросить плохую, но если вы действительно хотите исправить свои файлы, вот подход, который сработал для многих:
Настройка
Определите исходный экземпляр (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/...
Примечание: uids в двух экземплярах могут быть не идентичными, поэтому будьте осторожны, если вы создаете, редактируете или копируете файлы, принадлежащие пользователям без полномочий root. Например, ваш пользователь mysql в экземпляре A может иметь тот же UID, что и ваш постфиксный пользователь на экземпляре B, который может вызвать проблемы, если вы производите файлы с одним именем, а затем переместите том обратно в A.
Обернуть
После того, как вы закончите, и вы довольны файлами под /vol -a, отключите файловую систему (все еще на экземпляре-B):
sudo umount /vol-a
sudo rmdir /vol-a
Теперь вернемся к вашей системе с помощью ec2-api-инструментов, продолжайте перемещать том 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 был временно запущен именно для этого процесса, не забудьте его закрыть.