AWS Сценарий пользовательских данных EC2 не запускается на экземплярах t3 - PullRequest
Новая
       53

AWS Сценарий пользовательских данных EC2 не запускается на экземплярах t3

0 голосов
/ 20 марта 2020

У меня есть довольно простой скрипт пользовательских данных , который устанавливает агент 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

1 Ответ

1 голос
/ 20 марта 2020

Как оказалось, неинтерактивный режим требовал взаимодействия. Понятия не было, почему это так, или почему последующий вызов сценария вручную не показал того же поведения. Подсказкой было искаженное сообщение в конце cloud-init-output.log (спасибо @Marcin за это).

Исправление состояло в том, чтобы изменить верхнюю часть скрипта так, чтобы она выглядела так: 

export DEBIAN_FRONTEND=noninteractive
apt-get update 
apt-get -y upgrade 
apt-get install awscli python-pip -y
pip install https://s3.amazonaws.com/cloudformation-examples/aws-cfn-bootstrap-latest.tar.gz
apt-get autoremove 
apt-get autoclean
...