Устранение неполадок при подготовке виртуальной машины с помощью cloud-init

Внимание

Эта статья ссылается на CentOS, дистрибутив Linux, который является состоянием "Конец жизни" (EOL). Обратите внимание на использование и план соответствующим образом. Дополнительные сведения см. в руководстве centOS End Of Life.

Область применения: ✔️ Виртуальные машины Linux ✔️ Гибкие масштабируемые наборы

Если вы создали обобщенные пользовательские образы, используя для подготовки cloud-init, но обнаружили, что виртуальная машина создана неправильно, вам потребуется устранить неполадки в пользовательских образах.

Некоторые примеры проблем с подготовкой:

• Виртуальная машина зависает на "создании" в течение 40 минут, и создание виртуальной машины помечается как неудачное.
• CustomData не обрабатывается.
• Не удалось подключить временный диск.
• Пользователи не создаются или возникают проблемы с доступом пользователей.
• Сеть не настроена правильно.
• Сбои файла или секции.

В этой статье описывается устранение неполадок сloud-init. Больше подробностей см. в cloud-init deep dive.

Шаг 1. Тестирование развертывания с помощью customData

Cloud-init может принять передаваемый в нее customData при создании ВМ. Во-первых, следует убедиться, что это не вызывает проблем с развертываниями. Попробуйте подготовить виртуальную машину без передачи какой бы то ни было конфигурации. Если вы обнаружите, что виртуальная машина не подготавливается, выполните описанные ниже действия, если вы обнаружите, что конфигурация, которую вы передаете, не применяется, перейдите к шагу 4.

Шаг 2. Проверка требований к образу

Основная причина сбоя подготовки виртуальной машины — образ ОС не удовлетворяет предварительным требованиям для работы в Azure. Убедитесь, что образы правильно подготовлены, прежде чем пытаться подготовить их в Azure.

В следующих статьях показаны шаги для подготовки различных дистрибутивов Linux, поддерживаемых в Azure.

• Подготовка виртуальной машины на основе CentOS для Azure
• Подготовка виртуального жесткого диска Debian для Azure
• Flatcar Container Linux
• Oracle Linux
• Red Hat Enterprise Linux
• Подготовка виртуальной машины SLES или openSUSE для Azure
• Ubuntu
• Информация о нерекомендованных дистрибутивах

Для поддерживаемых образов Azure cloud-initдистрибутивы Linux уже имеют все необходимые пакеты и конфигурации, чтобы правильно подготавливать образ в Azure. Если вы обнаружите, что виртуальная машина не может создать данные из собственного проверенного образа, попробуйте использовать поддерживаемый образ Azure Marketplace, который уже настроен для Cloud-init, с необязательным customData. Если приложение customData правильно работает с образом Azure Marketplace, возможно, у вас есть проблемы с проверенным образом.

Шаг 3. Получение & проверки журналов виртуальных машин

Если виртуальная машина не подготовилась к работе, в Azure отобразится состояние "создание" в течение 20 минут. Затем перезагрузите виртуальную машину и подождите еще 20 минут, прежде чем пометить развертывание виртуальной машины как неудачное, прежде чем помечать ее ошибкойOSProvisioningTimedOut.

Пока виртуальная машина запущена, вам понадобятся журналы с виртуальной машины, чтобы понять, почему подготовка не удалась. Чтобы понять, почему не удалось подготовить виртуальную машину, не останавливайте ее. Пусть он продолжает работать. Для получения журналов необходимо сохранить работоспособность виртуальной машины в состоянии выполнения. Чтобы собрать журналы, используйте один из следующих методов.

• Включите диагностику загрузки перед созданием виртуальной машины и Просмотрите их во время загрузки.

• Последовательная консоль

• Выполните восстановление виртуальной машины AZ, чтобы подключить и подключить диск ОС с помощью chroot, что позволит собирать следующие журналы:

sudo cat /rescue/var/log/cloud-init*
sudo cat /rescue/var/log/waagent*
sudo cat /rescue/var/log/syslog*
sudo cat /rescue/var/log/rsyslog*
sudo cat /rescue/var/log/messages*
sudo cat /rescue/var/log/kern*
sudo cat /rescue/var/log/dmesg*
sudo cat /rescue/var/log/boot*

Примечание.

Кроме того, можно создать виртуальную машину спасения вручную с помощью портал Azure. Дополнительные сведения см. в статье "Устранение неполадок виртуальной машины Linux путем подключения диска ОС к виртуальной машине восстановления с помощью портал Azure".

Чтобы начать первоначальное устранение неполадок, начните с журналов cloud-init и узнайте, где произошел сбой, а затем используйте другие журналы для углубленного изучения и получения дополнительных сведений.

• /var/log/cloud-init.log
• /var/log/cloud-init-output.log
• Последовательный журнал/журнал загрузки

Во всех журналах начните поиск по слову "Failed", "WARNING", "WARN", "Err", "Error", "ERROR". Рекомендуется игнорировать регистр при поиске.

Совет

При устранении неполадок с пользовательским образом рекомендуется добавить пользователя во время создания образа. Если при подготовке не удается установить пользователя с правами администратора, вы по-прежнему можете войти в ОС.

Анализ журналов

Ниже приведены дополнительные сведения о том, что следует искать в каждом журнале Cloud-init.

/var/log/cloud-init.log

По умолчанию все события Cloud-init с приоритетом Debug или выше записываются в /var/log/cloud-init.log. Это предоставляет подробные журналы всех событий, произошедших во время инициализации сloud-init.

Например:

2019-10-10 04:51:25,321 - util.py[DEBUG]: Failed mount of '/dev/sr0' as 'auto': Unexpected error while running command.
Command: ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpLIrklc']
Exit code: 32
Reason: -
Stdout:
Stderr: mount: unknown filesystem type 'udf'
2020-01-31 00:21:53,352 - DataSourceAzure.py[WARNING]: /dev/sr0 was not mountable

Когда вы обнаружите ошибку или предупреждение, прочтите журнал сloud-init в обратном порядке, чтобы понять, что Cloud-init выполнял перед ошибкой или предупреждением. Во многих случаях Cloud-init будет выполнять команды операционной системы или выполнять операции подготовки до возникновения ошибки, что позволяет получить подробные сведения о том, почему ошибки появляются в журналах. В следующем примере показано, что Cloud-init попыталось подключить устройство непосредственно перед ошибкой.

2019-10-10 04:51:24,010 - util.py[DEBUG]: Running command ['mount', '-o', 'ro,sync', '-t', 'auto', u'/dev/sr0', '/run/cloud-init/tmp/tmpXXXXX'] with allowed return codes [0] (shell=False, capture=True)

Если у вас есть доступ к последовательной консоли, можно попробовать повторно выполнить команду, которую пытался запустить cloud-init.

Ведение журнала для /var/log/cloud-init.log можно также перенастроить в /etc/cloud/cloud.cfg.d/05_logging.cfg. Дополнительные сведения о журнале cloud-init см. в документации по cloud-init

/var/log/cloud-init-output.log

Вы можете получить сведения из stdout и stderr во время этапов сloud-init. Обычно это включает сведения о таблице маршрутизации, сведения о сети, сведения о проверке ключа узла SSH stdout и stderr для каждого этапа Cloud-init, а также отметку времени для каждого этапа. При необходимости ведение журналов stderr stdout можно перенастроить в /etc/cloud/cloud.cfg.d/05_logging.cfg.

Последовательный журнал/журнал загрузки

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

Если вы по-прежнему не можете изолировать, почему не удалось выполнить инициализацию Cloud-init, необходимо понять, какие этапы Cloud-init и когда работают модули. Дополнительные сведения см. в статье Подробнее о Cloud-init.

Шаг 4. Выясните, почему конфигурация не применяется

Не все сбои в Cloud-init приводят к неустранимой ошибке подготовки. Например, если вы используете модуль runcmd в конфигурации Cloud-init, ненулевой код выхода из выполняемой команды приведет к сбою подготовки виртуальной машины. Это обусловлено тем, что он выполняется после основных функций подготовки, которые выполняются на первых трех стадиях Cloud-init. Чтобы устранить неполадки, связанные с тем, почему конфигурация не была применена, изучите журналы в шаге 3 и модули Cloud-init вручную. Например:

• runcmd — запускаются ли сценарии без ошибок? Запустите конфигурацию вручную из терминала, чтобы убедиться, что они выполняются должным образом.
• Установка пакетов. у виртуальной машины есть доступ к репозиториям пакетов?
• Кроме того, проверьте конфигурацию данных customData, предоставленную виртуальной машине, которая находится в папке /var/lib/cloud/instances/<unique-instance-identifier>/user-data.txt.

Следующие шаги

Если вы по-прежнему не можете изолировать, почему Cloud-init не выполнял конфигурацию, необходимо более внимательно ознакомиться с тем, что происходит на каждом этапе Cloud-init, а также при запуске модулей. Дополнительные сведения см. в статье Подробнее о настройке Cloud-init.