У меня есть довольно простой скрипт пользовательских данных , который устанавливает агент CodeDeploy в Ubuntu, а затем посылает сигнал CloudFormation, указывающий, что экземпляр исправен. Мой стек развернут с использованием CloudFormation, который устанавливает ASG, LaunchTemplate, TargetGroup и т. Д. c. Тип целевого экземпляра - Ubuntu 18.04 (ami-07ebfd5b3428b6f4d AMI) в экземплярах t3.small. Ранее у меня была такая же проблема на другом AMI, но обновление до ami-07ebfd5b3428b6f4d, казалось, исправило ее временно ... она работала в течение нескольких недель.
Недавно мой ASG попытался заменить некоторые нездоровые экземпляры, и новые случаи не появлялись. При дальнейшем расследовании я обнаружил, что снова вернулся к той же проблеме - скрипт userdata не запускается. Облако-init.log заканчивается следующей строкой:
2020-03-20 01:23:56,741 - util.py[DEBUG]: Running command ['/var/lib/cloud/instance/scripts/part-001'] with allowed return codes [0] (shell=False, capture=False)
Но, кажется, здесь зависает без активности в syslog. Этот файл из журнала правильно содержит сценарий, и этот сценарий выполняется успешно (без какого-либо обязательного взаимодействия), если я вызываю его вручную.
Изменение стека CloudFormation вместо использования экземпляров t2 решает проблему. Я зарезервировал емкость t3, поэтому мне нужно вернуться к t3.
Мысли / идеи кто-нибудь?
Обновление на основе комментариев. Вот несколько последних строк cloud-init-output.log:
Setting up apport (2.20.9-0ubuntu7.12) ...
Installing new version of config file /etc/init.d/apport ...
apport-autoreport.service is a disabled or a static unit, not starting it.
Setting up ubuntu-standard (1.417.4) ...
Setting up grub-pc (2.02-2ubuntu8.15) ...
ESC[1;24rESC[4lESC)0ESC[mESC(BESC[1;24rESC[HESC[JESC[1;1HPackage configurationESC[3;2H┌──────────────────────────┤ Configuring grub-pc ├──────────────────────────┐ESC[4;2H│ESC[75C│ESC[5;2H│ The GRUB boot loader was previously installed to a disk that is noESC[8C│ESC[6;2H│ longer present, or whose unique identifier has ch