G214 · Materiales de las prácticas

Material de la asignatura G214 · Procesamiento y almacenamiento de datos en la nube (CUNEF). Todo lo que hay aquí se usa en tu propia cuenta de AWS. No depende de ningún servidor externo de la asignatura.

Las prácticas de cada tema son las actividades de su carpeta, con los pasos detallados, qué debes ver después de cada paso y qué hacer si algo falla. Léelas antes de ejecutar nada.

Web de consulta. Durante las clases (jueves de 10:30 a 12:30 y viernes de 10:00 a 13:00, hora de Madrid) puedes leer estos mismos README en https://g214.paredero.com y usar Adminer en https://g214.paredero.com/adminer/. El zip se descarga siempre desde Canvas. Fuera de ese horario el servidor está apagado: usa los README de tu copia local.

Cómo está organizado

Una carpeta por tema. Dentro de cada una, las actividades van numeradas en el orden en que se hacen (<tema>.<actividad>-Nombre):

• Un fichero .md suelto (por ejemplo 01.02-ServidorWeb.md) es una guía paso a paso que se sigue en la consola de AWS o en la terminal; no necesita ficheros.
• Una carpeta (por ejemplo 02.01-s3primerbucket/) es un laboratorio o ejercicio con varios ficheros: su README.md explica qué hay dentro y los pasos. Si dos actividades usan el mismo fichero, cada carpeta tiene su copia.

Cada carpeta de tema tiene además un README.md con el índice de sus actividades.

Cómo llevar los ficheros a donde toque

Los ficheros los descargas en tu PC, pero casi todo se ejecuta en otro sitio. Hay tres casos:

1. En tu PC. Los ficheros SQL y CSV que se importan desde el navegador (Adminer) y los datos de las prácticas que se suben a S3 se cargan desde tu PC con la consola de AWS. No necesitas CloudShell.

2. En CloudShell (terminal Linux dentro de la consola de AWS, con tus credenciales ya puestas). Es lo que se usa en los Temas 2 a 5. Todo el material va en un único fichero, g214-materiales.zip, que subes una sola vez:

   1. Descarga g214-materiales.zip desde Canvas. No lo descomprimas en tu PC: se sube tal cual.
   2. Abre CloudShell con la región eu-north-1 (Estocolmo) seleccionada en la consola.
   3. Actions → Upload file y elige el zip. Queda en tu carpeta personal (~).
   4. Descomprime y arregla los permisos. Hazlo cada vez que descomprimas, porque el zip hecho en Windows deja los ficheros de solo lectura y sin permiso de ejecución. La primera línea chmod (da error silencioso la primera vez, es normal) permite sobrescribir una versión anterior; la segunda permite editar y borrar todo con normalidad; la tercera da permiso de ejecución a los scripts (bash y Python):

   cd ~
   chmod -R u+rwX ~/g214-materiales 2>/dev/null
   unzip -o g214-materiales.zip
   chmod -R u+rwX ~/g214-materiales
   find ~/g214-materiales -type f \( -name "*.sh" -o -name "*.py" \) -exec chmod +x {} +
   

   5. Entra en la carpeta de la actividad que vayas a hacer y ejecuta los scripts siempre desde dentro de esa carpeta:

   cd ~/g214-materiales/tema4/04.02-titanic
   ./gestionar-titanic.sh --ayuda
   

   Si hay una versión nueva del zip: súbela igual y repite el paso 4 (unzip -o sobrescribe los ficheros del material y conserva los tuyos). Para empezar de cero, borra antes la versión anterior con chmod -R u+rwX ~/g214-materiales, rm -rf ~/g214-materiales y rm -f ~/g214-materiales.zip (el chmod evita el Permission denied al borrar); ojo, rm -rf borra también lo que hayas creado dentro, así que copia antes lo que quieras conservar (cp -r ~/g214-materiales ~/copia-materiales) y no lo uses con un laboratorio creado en AWS sin haber ejecutado antes su eliminar. Linux distingue mayúsculas: todo el material va en minúsculas.

3. Dentro de las máquinas EC2. Upload file de CloudShell sube el fichero a CloudShell, no a las máquinas virtuales, y no hace falta copiar ni pegar nada: los gestionar-webapp.sh, gestionar-euribor.sh, gestionar-cafeteria.sh y gestionar-bicimad.sh crean las máquinas con sus scripts ya dentro (los suben a un bucket temporal y cada máquina los descarga al arrancar: todo corre en EC2, nada se instala en tu PC). Solo los scripts disco.sh (Linux) y disco-windows.ps1 (Windows, se copia al Bloc de notas de la máquina) de las prácticas de discos se llevan a mano; el README de esa carpeta lo explica.

Cómo funcionan los scripts

Cada laboratorio que crea cosas en AWS se gestiona con un único script (todo lo que necesita, como plantillas de CloudFormation o el código de la Lambda, va dentro) con las mismas órdenes en todos:

Nombres. Los scripts que crean y borran recursos se llaman siempre gestionar-<actividad>.sh (por ejemplo gestionar-datalake.sh, gestionar-etl-titanic.sh, gestionar-adminer.sh); las herramientas sueltas llevan verbo y objeto (descargar-datos.sh, vaciar-bucket.py, csv-a-parquet.py); lo que sale de extraer se llama plantilla-<actividad>.yaml (CloudFormation) o lambda-<actividad>.py (código de la función). Todo en minúsculas y con guiones.

Opciones comunes a todos los gestionar-*.sh: --si (también -y o --yes) responde «sí» a las preguntas, --no responde «no» (no borra nada) y --ayuda (también --help, -h o ayuda) muestra los pasos y el uso. Alias en inglés: create, status, delete, extract.

Si lo ejecutas sin ninguna orden en una terminal, se abre un menú numerado; sin terminal, solo muestra la ayuda y no hace nada. El orden de uso lo marca la numeración de las carpetas (04.01, 04.02…): primero la base del tema (por ejemplo 04.01-creardatalake) y después los ejercicios.

Ayuda en cualquier script. Todos los scripts (los gestionar-*.sh, descargar-datos.sh, dividir-padron.sh, procesa-viajes.sh, caja.sh, oficina.sh y las herramientas .py) responden a --ayuda (o --help): explican sus pasos y opciones y te recuerdan que cada carpeta trae un README.md con el paso a paso y las dudas frecuentes. Ante cualquier duda: primero ./script.sh --ayuda, después el README.md de la carpeta y, si sigues atascado, escribe al profesor.

Si te equivocas o algo se queda a medias, la solución casi siempre es la misma: ./script.sh estado para ver qué hay y ./script.sh eliminar para empezar de cero.

Los scripts que se ejecutan dentro de una máquina virtual (caja.sh, oficina.sh, procesa-viajes.sh) llevan --ayuda (o ayuda) y estado, y caja.sh y procesa-viajes.sh también limpiar/eliminar (solo borran los ficheros de ejemplo, nunca formatean). caja.sh y oficina.sh, sin órdenes, hacen la comprobación completa del laboratorio.

Etiquetas: cómo se identifica todo lo que creas

Una etiqueta (tag) es un par clave = valor que se pega a un recurso de AWS (un bucket, una máquina, una base de datos...). No cambia cómo funciona el recurso: sirve para saber de quién es y de qué actividad viene, repartir costes y, si hay una emergencia, encontrarlo y borrarlo sin dudar. Un recurso puede llevar varias etiquetas a la vez; aquí usamos siempre estas:

Reglas: las claves van siempre en minúscula (AWS distingue mayúsculas: Curso y curso serían dos etiquetas distintas) y los valores se escriben exactamente como en la tabla. Hay tres etiquetas más que no debes cambiar ni quitar: Name (la consola la enseña como nombre del recurso, por eso es la única que lleva mayúscula), g214-apagar-tras (la lee el vigilante que apaga sola la máquina, Temas 3 a 5) y project=g214-etl (la llevan los stacks del Tema 5).

Lo que etiquetan los scripts por ti

Los gestionar-*.sh etiquetan todo lo que crean, y eliminar lo borra por completo. No tienes que hacer nada:

Lo que creas a mano: etiquétalo tú

Todo lo que crees en la consola o con la CLI (las máquinas del Tema 1 y 2, el bucket de 02.01, la RDS de 03.01, las tablas de DynamoDB, las Lambdas adicionales...) lo etiquetas tú con curso, universidad y actividad (sin script):

• En la consola: al crearlo, apartado Tags / Etiquetas → Add tag; o después, en la pestaña Tags del recurso → Manage tags. En el asistente de EC2 está en «Name and tags» → Add additional tags.
• Con la CLI, según el recurso (cambia el nombre y la actividad por los tuyos):

# Bucket de S3 (sustituye TODAS las etiquetas del bucket, pon las tres a la vez)
aws s3api put-bucket-tagging --bucket g214-tuapellido-objetos --tagging 'TagSet=[{Key=curso,Value=G214},{Key=universidad,Value=CUNEF},{Key=actividad,Value=02.01-s3primerbucket}]'
# Máquina, volumen, snapshot, Security Group... (EC2)
aws ec2 create-tags --resources i-0123456789abcdef0 --tags Key=curso,Value=G214 Key=universidad,Value=CUNEF Key=actividad,Value=02.06-laboratoriocafeteria
# Tabla de DynamoDB (mejor al crearla: --tags en create-table)
aws dynamodb tag-resource --resource-arn arn:aws:dynamodb:eu-north-1:CUENTA:table/Estaciones --tags Key=curso,Value=G214 Key=universidad,Value=CUNEF Key=actividad,Value=03.10-estacionesdynamodb
# Función Lambda
aws lambda tag-resource --resource arn:aws:lambda:eu-north-1:CUENTA:function:mi-funcion --tags curso=G214,universidad=CUNEF,actividad=05.07-adicionalaree
# Base de datos RDS
aws rds add-tags-to-resource --resource-name arn:aws:rds:eu-north-1:CUENTA:db:mi-bd --tags Key=curso,Value=G214 Key=universidad,Value=CUNEF Key=actividad,Value=03.01-RDSMariaDB

Cómo ver y localizar lo etiquetado

• Consola: abre el recurso y mira la pestaña Tags; o usa Resource Groups & Tag Editor → Tag Editor, elige la región eu-north-1, todos los tipos de recurso y filtra por la etiqueta curso.
• Terminal (CloudShell): lista todo lo del curso o solo una actividad.

aws resourcegroupstaggingapi get-resources --region eu-north-1 --tag-filters Key=curso,Values=G214 --query 'ResourceTagMappingList[].ResourceARN' --output text
aws resourcegroupstaggingapi get-resources --region eu-north-1 --tag-filters Key=actividad,Values=04.01-creardatalake --query 'ResourceTagMappingList[].ResourceARN' --output text

Las instancias y los volúmenes ya borrados pueden seguir saliendo en esa lista durante cerca de una hora: es normal, comprueba su estado en la consola de EC2.

Si hay que borrar a mano (emergencia)

1. Prueba siempre primero el script de la actividad: ./gestionar-<actividad>.sh eliminar (con --si si no hay terminal). Borra todo en el orden correcto y comprueba al final que no queda nada.
2. Si el script no puede (por ejemplo, lo que quieres borrar lo creaste a mano), lista lo de esa actividad con el comando de arriba y borra desde el servicio: primero las máquinas y las bases de datos, después los discos, los snapshots y los buckets (vacíos), y los stacks desde CloudFormation (borrar el stack borra todo lo que contiene).
3. Los roles, políticas y perfiles de IAM llevan las mismas etiquetas (consola de IAM → recurso → pestaña Tags); bórralos al final y solo si llevan tu etiqueta de actividad.
4. Repasa en la consola de Billing que no queda nada facturando.

Reglas que valen para todos los laboratorios

• Región: todo en eu-north-1 (Estocolmo). Comprueba el selector de región de la consola antes de crear nada.
• Limpieza: al terminar, borra todo lo que hayas creado (cada README tiene el orden exacto). Las máquinas EC2, las bases de datos RDS y los volúmenes siguen facturando aunque no los uses.
• Coste: con un mínimo de cuidado son céntimos, pero un laboratorio olvidado puede gastar tu crédito. Activa un presupuesto con alerta por correo (AWS Budgets).
• Seguridad: no compartas capturas con claves de acceso ni contraseñas, no dejes bases de datos abiertas a todo Internet más tiempo del necesario y no subas tus credenciales a ningún sitio.
• Si algo falla: lee el mensaje de error completo (casi siempre dice qué falta), consulta la tabla de errores frecuentes del README de esa carpeta y, si sigues atascado, escribe al profesor por correo con una captura del error y del paso en el que estás.

Nota sobre los datos

Todo el contenido de este paquete se ha revisado para no incluir credenciales, claves de AWS, endpoints reales de infraestructura ni datos personales de alumnos. Las contraseñas que aparecen en los laboratorios son de ejemplo y solo valen para entornos de clase que tú creas y borras.