Ampliación · Preparar el servidor con user data

Ya instalaste y verificaste Apache desde una sesión SSH. Ahora pasarás esas tareas a un script de user data, datos de usuario que entregas al lanzar la instancia. En la AMI Linux de la práctica, cloud-init ejecuta este tipo de script como root en el primer arranque por defecto. La máquina puede aparecer en ejecución mientras aún se instala el servidor. User data de EC2.

Lanza una instancia con el script

Parte del recorrido guiado completo y del inventario cerrado. Usa una sola instancia. Descarga user-data.sh y léelo antes de usarlo. Instala Apache, escribe el HTML público e inicia el servicio con arranque habilitado. El bloque entre <<'HTML' y la línea final HTML proporciona el texto que cat escribe en el archivo. chmod 0644 permite que Apache lo lea. set -euo pipefail ayuda a que el script se detenga cuando una orden falla, se usa una variable sin asignar o falla un tramo de una tubería.

Repite la configuración comprobada del bloque 01. En Advanced details → User data, pega el texto tal como está en el archivo. La consola realiza la codificación al enviar la solicitud. Usa solo datos ficticios. Revisa el coste previsto, el disco y las reglas de acceso antes de lanzar.

Comprueba el resultado

Verifica la huella y entra por SSH como en el bloque 02. En EC2, espera a que se complete cloud-init y revisa las comprobaciones:

sudo cloud-init status --wait
systemctl is-active httpd
systemctl is-enabled httpd
curl -fsS http://127.0.0.1/

El resultado local debe incluir «Aviso instalado por user data.». Si el arranque muestra errores, lee el final del registro desde EC2. tail -n 40 muestra las últimas cuarenta líneas. Distingue un error al instalar el paquete de un problema al escribir el HTML o iniciar el servicio.

sudo tail -n 40 /var/log/cloud-init-output.log

Cuando la prueba local funcione, permite HTTP temporalmente y prueba la página desde Debian y el navegador. Comprueba que la página es la del script.

Comprobación adicional · Identificar la instancia

Puedes consultar los metadatos de la instancia desde la sesión remota mediante IMDSv2. En el lanzamiento, comprueba que el endpoint está habilitado y los tokens se requieren. El primer curl obtiene un token de sesión durante un minuto y lo guarda en una variable. El segundo lo pasa en el encabezado para leer solo el identificador de instancia. Comprueba la coincidencia con la consola y registra únicamente si coincide.

if TOKEN_IMDS=$(curl -fsS --max-time 3 -X PUT \
  -H 'X-aws-ec2-metadata-token-ttl-seconds: 60' \
  http://169.254.169.254/latest/api/token); then
  curl -fsS --max-time 3 -H "X-aws-ec2-metadata-token: $TOKEN_IMDS" \
    http://169.254.169.254/latest/meta-data/instance-id
  printf '\n'
fi
unset TOKEN_IMDS

Uso de IMDSv2.

Comprobación adicional · Inventario desde Debian

Si tienes AWS CLI en Debian y quieres consultar el estado de tu instancia, prepara o renueva los tres valores del perfil temporal learnerlab como en AWS-S3. Introduce el identificador que muestra la consola. La consulta pide ese recurso y muestra solo estado y tipo. Ejecuta este bloque en el cliente Debian.

read -r -p 'Identificador de tu instancia: ' ID_EC2
if [[ "$ID_EC2" =~ ^i-[0-9a-f]+$ ]]; then
  aws ec2 describe-instances --profile learnerlab --region us-east-1 \
    --instance-ids "$ID_EC2" --no-cli-pager \
    --query 'Reservations[].Instances[].{Estado:State.Name,Tipo:InstanceType}'
fi

Contrasta la salida con la consola. Si la consulta está denegada, registra la acción sin exponer los datos de cuenta.

Limpieza

Cuando completes las comprobaciones elegidas, aplica el cierre del bloque 04. Si preparaste credenciales temporales para la consulta desde Debian, retíralas siguiendo el cierre de AWS-S3 y conserva los perfiles ajenos a la práctica.

A entregar

Anota qué tareas hizo el script, cómo comprobaste su finalización, qué respondió el servidor y qué retiraste al cerrar. Si haces la comprobación de metadatos, añade el resultado de la comparación con la consola.