Initialiser une instance avec User Data

AWSBeginner
Pratiquer maintenant

Introduction

Votre équipe veut que chaque nouveau serveur de rapports démarre avec le bon message d'accueil. Vous allez écrire un script Bash User Data, le fournir au lancement d'une instance EC2, puis examiner l'application obtenue et le journal de démarrage.

Vous devez déjà savoir lancer une instance EC2 et vous connecter en SSH. Ce nouvel environnement fournit sa propre image, son réseau et sa paire de clés ; vous créerez le serveur et sa configuration de démarrage.

Lien avec la certification

Ce laboratoire pratique la configuration programmatique des ressources et l'automatisation du démarrage, liées à la tâche 3.1 des objectifs du domaine 3 d'AWS Certified Cloud Practitioner CLF-C02.

Configurer l'application au lancement

Dans cette étape, vous écrirez un script de démarrage, lancerez une instance avec ce script et vérifierez la réponse de l'application.

User Data désigne les informations transmises à une instance lors de son lancement. Un script de démarrage Linux peut les utiliser pour configurer automatiquement les logiciels. Par défaut, ces scripts s'exécutent en tant que root au premier démarrage : leurs commandes n'ont donc pas besoin de sudo. Le guide officiel EC2 User Data décrit ce comportement et l'emplacement du journal.

Commencez dans votre espace de travail :

cd /home/labex/project

L'image préparée contient l'application de rapports. Chargez les identifiants de l'image et du réseau dans votre shell actuel :

source launch.env

Créez user-data.sh avec un here-document. Les marqueurs externes SCRIPT délimitent le script complet ; les marqueurs internes JSON délimitent la configuration de l'application. Les marqueurs entre guillemets préservent le texte littéral. La première ligne, #!/bin/bash, sélectionne Bash, tandis que set -euo pipefail arrête le script si une commande échoue ou si une variable non définie est utilisée. Le dernier echo écrit une entrée utile dans le journal de démarrage.

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

Cela crée un fichier local ; aucune instance n'est encore modifiée. Transmettez ce fichier à run-instances avec --user-data file://user-data.sh. AWS CLI lit et encode le fichier pour l'API : vous n'avez pas à l'encoder vous-même. Nommez ce serveur 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}]'

Enregistrez l'identifiant de la nouvelle instance. Le filtre sélectionne son tag de nom et $(...) capture le résultat en texte brut :

INSTANCE_ID=$(aws ec2 \
  describe-instances \
  --filters Name=tag:Name,Values=bootstrap-server \
  --query 'Reservations[0].Instances[0].InstanceId' \
  --output text)

Inspectez l'état et l'adresse publique :

aws ec2 \
  describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name,PublicIPv4:PublicIpAddress}'

Confirmez running. Si l'état est encore pending, attendez un instant et répétez la requête. L'état en cours d'exécution ne prouve pas à lui seul que la configuration de démarrage a réussi ; vous allez maintenant examiner l'application.

Ouvrez AWS View, cliquez sur Refresh resources et sélectionnez bootstrap-server sous Application requests. Cliquez sur Check application. Confirmez HTTP 200 et le message Started with User Data. Vous avez configuré le serveur par son script de démarrage, sans le modifier après le lancement.

AWS View affiche HTTP 200 pour l'application configurée au démarrage

Cet exemple montre la réponse attendue. Les identifiants de votre instance et de votre réseau seront différents.

Récupérez l'adresse publique pour vous connecter en SSH :

PUBLIC_IP=$(aws ec2 \
  describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[0].Instances[0].PublicIpAddress' \
  --output text)

La configuration SSH fournie sélectionne la clé privée et le chemin d'accès du laboratoire :

ssh -F ssh_config ubuntu@"$PUBLIC_IP"

Vous êtes maintenant dans l'instance de l'application. Lisez le journal de sortie du démarrage avec les privilèges administrateur :

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

Recherchez Report application configuration applied. Il s'agit de la sortie du script fourni. Pour diagnostiquer un échec de démarrage, cherchez les erreurs de commandes dans ce journal, puis testez l'application elle-même au lieu de vous fier uniquement à l'état de l'instance.

Revenez au terminal LabEx :

exit

Vous pouvez aussi récupérer les données User Data stockées sur l'instance. Cette requête sélectionne leur valeur Base64 et le pipe la transmet à base64 --decode pour afficher le script d'origine :

aws ec2 \
  describe-instance-attribute \
  --instance-id "$INSTANCE_ID" \
  --attribute userData \
  --query 'UserData.Value' \
  --output text | base64 --decode

Confirmez que le script Bash et le message d'accueil correspondent à votre fichier. User Data s'exécute normalement uniquement au premier démarrage ; arrêter puis redémarrer une instance ne répète pas automatiquement cette configuration. Utilisez l'automatisation du démarrage pour obtenir une configuration initiale reproductible et n'incluez pas d'identifiants secrets dans le script.

Terminer le serveur initialisé

Dans cette étape, vous supprimerez l'instance créée et vérifierez son état final.

Terminez uniquement l'instance identifiée par votre variable enregistrée :

aws ec2 \
  terminate-instances \
  --instance-ids "$INSTANCE_ID"

Attendez que l'instance atteigne terminated. Le waiter interroge périodiquement l'état et se termine sans sortie lorsqu'il réussit :

aws ec2 \
  wait instance-terminated \
  --instance-ids "$INSTANCE_ID"

Confirmez l'état final :

aws ec2 \
  describe-instances \
  --instance-ids "$INSTANCE_ID" \
  --query 'Reservations[].Instances[].{Instance:InstanceId,State:State.Name}'

Le résultat doit indiquer terminated. Actualisez AWS View et confirmez que bootstrap-server n'est plus une cible d'application en cours d'exécution. Conservez le réseau et la paire de clés préparés.

Résumé

Vous avez écrit un script Bash User Data et l'avez transmis à EC2 au lancement. Vous avez vérifié la configuration automatique de l'application dans AWS View, examiné le journal de sortie du démarrage et récupéré le script stocké. Enfin, vous avez terminé le serveur et confirmé son état final.