TL; DR: при запуске экземпляра AMI, созданного с помощью CLI aws ec2 create-image, предыдущий примененный user-data исчезает, в то время как запуск AMI, созданного в консоли, имеет все user-data модификации.
Сценарий:
Я хочу автоматизировать создание пользовательского AMI для нашего использования, которое само основано на регулярно обновляемом базовом AMI. Всякий раз, когда я получаю уведомление, я беру новый идентификатор AMI, а затем запускаю сценарий, из которого я извлеку.
Я раскручиваю экземпляр EC2, к которому добавляю user-data некоторой формы. Создание файлов, добавление пакетов и т. Д. Этот шаг прост и работает.
# base_ami_id is set elsewhere
ec2_id=$(aws ec2 run-instances \
--image-id ${base_ami_id} \
--count 1 \
--instance-type t2.micro \
--key-name ${key_name} \
--security-group-ids ${security_group} \
--subnet-id ${subnet} \
--user-data file://user-data.sh \
--iam-instance-profile Name=${iamprof} \
--output text --query 'Instances[*].InstanceId' \
)
echo "Instance ID is ${ec2_id}"
echo "Waiting for instance ${ec2_id} to run"
aws ec2 wait instance-running --instance-ids ${ec2_id}
ПРИМЕЧАНИЕ : На этом этапе я могу ssh в созданный экземпляр и убедиться, что cloud-init правильно применил все мои user-data. Все хорошо.
Взяв возвращенный идентификатор экземпляра, я создаю AMI-изображение согласно
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/creating-an-ami-ebs.html
echo Create image from instance ${ec2_id}
image_id=$(aws ec2 create-image --name ${image_name} --instance-id ${ec2_id} --output text --query 'ImageId')
echo "image ID is ${image_id}"
echo "Waiting for image ${image_id} to be available"
aws ec2 wait image-available --image-ids ${image_id}
echo "Image ${image_id} (${image_name}) available"
Смотря в консоль, через некоторое время я вижу свой новый AMI.
Чтобы проверить, я запускаю экземпляр с AMI, созданного этим шагом - и удивляюсь, обнаружив, что мои модификации НЕ в экземпляре! Как будто я запустил оригинальный AMI. Что не имеет смысла: как описано выше, user-data был там, когда я сделал тестовый вход в систему. И, как видно из приведенной выше выдержки из оболочки, я использовал возврат $[ec2_id}, полученный на этапе aws ec2 run-instance, в качестве основы для создания AMI, а не случайно, какой-то другой идентификатор.
Чтобы сделать это еще более запутанным, я использую консоль и тестирую, выполняя Create Image именно из этого запущенного экземпляра, с идентификатором экземпляра ${ec2_id}, как указано выше, который показал, что все мои user-data были там.
Затем я запускаю экземпляр с , который AMI - и вы не узнаете, что имеет все мои модификации! Все есть.
Я проверил и трижды проверил, и я просто не вижу, где / что я делаю неправильно! Я подумал, что, возможно, в aws ec2 create-image есть некоторые дополнительные параметры командной строки, которые используются в консольном эквиваленте при вызове API. Если есть, то не вижу.
Чего мне не хватает ?!
Это похоже на то, что AMI, созданный из консоли, с одинаковым идентификатором экземпляра и идентификатором из CLI отличается, но я сравнил идентификаторы, они определенно совпадают. Можно подумать, что использование правильного идентификатора экземпляра подразумевает, что базовые снимки и / или тома будут одинаковыми, потому что --instance-id - это единственное значение, которое я могу предоставить для create-image, верно?
EDIT:
Следуя совету @ Michael-sqlbot, я просмотрел журналы CloudTrail. К сожалению, это сделало это еще более расстраивающим.
РЕДАКТИРОВАТЬ РЕДАКТИРОВАТЬ:
Я удалил журналы CloudTrail, так как они оказались не относящимися к проблеме и ее решению и, возможно, только запутали бы вещи.