Введение
Ваша команда хочет, чтобы каждый новый сервер отчётов запускался с правильным приветствием приложения. Вы напишете Bash-скрипт User Data, передадите его при запуске инстанса EC2 и проверите получившееся приложение и журнал запуска.
Вы уже должны уметь запускать инстанс EC2 и подключаться по SSH. Эта новая среда предоставляет собственные образ, сеть и пару ключей; сервер и его конфигурацию запуска создадите вы.
Связь с сертификацией
Эта лабораторная работа отрабатывает программную настройку ресурсов и автоматизацию запуска, связанные с задачей 3.1 целей домена 3 AWS Certified Cloud Practitioner CLF-C02.
Настроить приложение при запуске
На этом шаге вы напишете скрипт запуска, запустите инстанс с этим скриптом и проверите ответ приложения.
User Data — информация, передаваемая инстансу при запуске. Стартовый скрипт Linux может использовать её для автоматической настройки программ. По умолчанию такие скрипты выполняются от имени root при первой загрузке, поэтому их командам не нужен sudo. Официальное руководство EC2 User Data описывает это поведение и расположение журнала.
Начните в рабочем каталоге:
cd /home/labex/project
Подготовленный образ содержит приложение отчётов. Загрузите ID образа и сети в текущую оболочку:
source launch.env
Создайте user-data.sh с помощью here-document. Внешние маркеры SCRIPT ограничивают весь скрипт, а внутренние JSON — конфигурацию приложения. Маркеры в кавычках сохраняют текст буквально. Первая строка #!/bin/bash выбирает Bash, а set -euo pipefail останавливает скрипт при ошибках команд или использовании неопределённых переменных. Последний echo выводит полезную запись в журнал запуска.
cat > user-data.sh <<'SCRIPT'
#!/bin/bash
set -euo pipefail
cat > /etc/report-app/config.json <<'JSON'
{
"message": "Started with User Data"
}
JSON
echo 'Report application configuration applied.'
SCRIPT
Это создаёт локальный файл и пока не меняет ни один инстанс. Передайте файл в run-instances через --user-data file://user-data.sh. AWS CLI прочитает и закодирует его для API, поэтому самостоятельно кодировать его не нужно. Назовите сервер bootstrap-server:
aws ec2 \
run-instances \
--image-id "$AMI_ID" \
--instance-type t3.micro \
--subnet-id "$SUBNET_ID" \
--security-group-ids "$SECURITY_GROUP_ID" \
--key-name report-key \
--count 1 \
--user-data file://user-data.sh \
--tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=bootstrap-server}]'
Сохраните ID нового инстанса. Фильтр выбирает его тег имени, а $(...) получает результат в виде обычного текста:
INSTANCE_ID=$(aws ec2 \
describe-instances \
--filters Name=tag:Name,Values=bootstrap-server \
--query 'Reservations[0].Instances[0].InstanceId' \
--output text)
Проверьте состояние и публичный адрес:
aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name,PublicIPv4:PublicIpAddress}'
Убедитесь, что состояние — running. Если оно всё ещё pending, немного подождите и повторите запрос. Работающий инстанс сам по себе не доказывает успешной настройки при запуске; далее вы проверите приложение.
Откройте AWS View, нажмите Refresh resources и выберите bootstrap-server в Application requests. Нажмите Check application. Подтвердите HTTP 200 и сообщение Started with User Data. Вы настроили сервер стартовым скриптом, не редактируя его после запуска.
Этот пример показывает ожидаемый ответ. ID вашего инстанса и сети будут отличаться.
Получите публичный адрес для подключения по SSH:
PUBLIC_IP=$(aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[0].Instances[0].PublicIpAddress' \
--output text)
Предоставленная конфигурация SSH выбирает закрытый ключ и маршрут доступа лабораторной работы:
ssh -F ssh_config ubuntu@"$PUBLIC_IP"
Теперь вы внутри инстанса приложения. Прочитайте журнал вывода запуска с правами администратора:
sudo cat /var/log/cloud-init-output.log
Найдите Report application configuration applied. Это вывод переданного вами скрипта. При диагностике сбоя запуска сначала проверьте этот журнал на ошибки команд, затем протестируйте само приложение, не полагаясь только на состояние инстанса.
Вернитесь в терминал LabEx:
exit
Можно также получить User Data, сохранённые на инстансе. Этот запрос выбирает их значение Base64, а конвейер передаёт его в base64 --decode, чтобы показать исходный скрипт:
aws ec2 \
describe-instance-attribute \
--instance-id "$INSTANCE_ID" \
--attribute userData \
--query 'UserData.Value' \
--output text | base64 --decode
Убедитесь, что Bash-скрипт и приветствие совпадают с вашим файлом. Обычно User Data выполняются только при первой загрузке; остановка и повторный запуск инстанса не повторяют эту настройку автоматически. Используйте автоматизацию запуска для воспроизводимой начальной настройки и не включайте учётные данные в скрипт.
Завершить инициализированный сервер
На этом шаге вы удалите созданный инстанс и проверите его окончательное состояние.
Завершите только инстанс, указанный в сохранённой переменной:
aws ec2 \
terminate-instances \
--instance-ids "$INSTANCE_ID"
Дождитесь состояния terminated. Waiter периодически запрашивает состояние и при успехе завершает работу без вывода:
aws ec2 \
wait instance-terminated \
--instance-ids "$INSTANCE_ID"
Подтвердите окончательное состояние:
aws ec2 \
describe-instances \
--instance-ids "$INSTANCE_ID" \
--query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name}'
Результат должен показывать terminated. Обновите AWS View и убедитесь, что bootstrap-server больше не является работающей целью приложения. Оставьте подготовленные сеть и пару ключей.
Итоги
Вы написали Bash-скрипт User Data и передали его EC2 при запуске. Вы проверили автоматическую настройку приложения через AWS View, изучили журнал вывода запуска и получили сохранённый скрипт. Наконец, вы завершили сервер и подтвердили его окончательное состояние.
