Tema 3 · 2 · Desplegar Adminer y conectar con tu RDS

Diapositivas del Tema 3: 39 y 40 (cliente SQL y formulario de entrada; la carga de la base, diapositivas 41 y 42, está en 03.03). Duración: 2 a 5 minutos de despliegue (medido con la versión anterior de los scripts: 35 s el script A y 1 min la plantilla B hasta crear la instancia; Adminer responde ~1 min 20 s después) más unos 5 minutos de subida de ficheros. Coste: una EC2 t3.small por hora encendida; se apaga sola a las 4 horas (ampliable, ver «Apagado automático») y apagada solo factura su disco.

Sobre esta versión de los scripts. Se han reescrito para que un alumno no tenga que depurar nada: cada script es un solo fichero (la plantilla de CloudFormation va dentro), tiene los mismos comandos (crear, estado, extender, eliminar, arrancar, --grant-rds, extraer, ayuda) y un menú numerado, y eliminar borra todo a la fuerza y se puede repetir. Se han probado de extremo a extremo en una cuenta real de AWS (los dos modos, cli y cloudformation, con todas sus opciones).

¿Dudas con un script? Todos los scripts de esta carpeta traen su propia ayuda: ./gestionar-adminer.sh --ayuda (también vale --help o -h) explica los pasos y las opciones. Este README.md es el paso a paso de la actividad: tenlo a mano y consúltalo antes de preguntar.

Etiquetas de lo que creas. ./gestionar-adminer.sh crear etiqueta la instancia, su disco, el Security Group y el stack con curso = G214, universidad = CUNEF, actividad = 03.02-adminer y script = gestionar-adminer.sh. Las verás en la consola (pestaña Tags del recurso) y, si hiciera falta borrar a mano, se localizan con aws resourcegroupstaggingapi get-resources --region eu-north-1 --tag-filters Key=actividad,Values=03.02-adminer. Más detalle (cómo etiquetar con la CLI, cómo buscar y qué hacer en una emergencia): README principal, sección «Etiquetas».

Qué vas a hacer

Vas a levantar Adminer, un cliente web de bases de datos (una sola página PHP con la que entras a tu RDS, lanzas SQL, importas y exportas), en una EC2 propia, y vas a conectarlo con la RDS que creaste en 03.01. Hay tres formas; elige UNA de las dos primeras (A o B), y la C solo si quieres un Adminer en tu PC.

CloudShell ──(script A o B)──> EC2 Adminer (Apache + PHP, puerto 80)
                                   │  regla: Security Group Adminer ──> puerto 3306
                                   ▼
                              tu RDS MariaDB

Qué se crea en AWS:

Qué contiene esta carpeta

Cada script lleva todo dentro: la plantilla de CloudFormation y lo que se instala en la máquina van embebidos al final del fichero (entre las marcas INICIO ARCHIVO EMBEBIDO y FIN ARCHIVO EMBEBIDO). No hace falta subir nada más. Si necesitas la plantilla suelta (por ejemplo, para pegarla en la consola de CloudFormation, apartado «Opción B desde la consola»), el comando extraer la escribe en la carpeta actual:

./gestionar-adminer.sh extraer          # escribe plantilla-adminer.yaml en la carpeta actual
./gestionar-adminer.sh extraer mi-carpeta   # o en la carpeta que indiques

Hay un solo script con dos formas de desplegar: por defecto cli (opción A) y, con --modo cloudformation, un stack de CloudFormation (opción B). Para estado, extender, eliminar, arrancar, crear (si ya existe) y --grant-rds no hace falta indicar el modo: el script detecta con cuál lo creaste.

Fichero que genera el script al crear: informacion_adminer.txt (con la IP y la URL, en la carpeta donde lo lances). Ya no hay fichero de estado oculto: los scripts encuentran lo que han creado consultando AWS (por la etiqueta Name de la instancia, el nombre del Security Group o el nombre del stack), así que puedes lanzarlos desde cualquier carpeta.

Comandos

Apagado automático

• Adminer se apaga solo a las 4 horas de crearlo (para que no se quede encendido y facturando si te olvidas). Al vencer se apaga, no se borra: la instancia queda stopped y solo eliminar la borra.
• Ampliar: vuelve a ejecutar ./gestionar-adminer.sh crear (arranca la instancia si estaba parada y concede otras 4 h; también vale arrancar) o extender (solo cambia el plazo). Con --horas N (1-24) eliges otro plazo.
• Permanente: ./gestionar-adminer.sh crear --permanente (o extender --permanente); estado avisará con «PERMANENTE (¡ojo con el coste!)».
• estado muestra siempre la línea «Apagado automático: se apagará a las HH:MM UTC (dentro de N min)», PERMANENTE o «ya se apagó: ejecuta crear».
• Cómo funciona: la instancia lleva la etiqueta g214-apagar-tras (hora de vencimiento o permanente) y un servicio interno la lee cada 30 s. Si la arrancas a mano con el plazo vencido, tiene 60 min de gracia.

Opciones: --si (o -y, --yes) no pide confirmación; --modo cli|cloudformation elige la forma de desplegar; --rds NOMBRE (con crear) da acceso a esa RDS nada más crear. Sin comando y con terminal interactiva se abre un menú numerado; sin terminal (por ejemplo, desde otro script) imprime el uso y termina sin quedarse esperando.

Antes de empezar

• [ ] Tienes la RDS MariaDB creada y en estado Available (03.01). Sin ella, Adminer se despliega igual pero no podrás conectarte a nada, y los scripts solo ven las RDS que existen en ese momento.
• [ ] Región de la consola eu-north-1, elegida ANTES de abrir CloudShell.
• [ ] Sabes tu endpoint, el usuario admin y tu contraseña.
• [ ] Un navegador desde el que puedas abrir http://<IP>/adminer.php (si tu red muestra Web Filter Violation o Access Blocked, es el filtro web de tu red: prueba con otra red, por ejemplo los datos del móvil).

Cómo llevar los ficheros a donde toque

Los ficheros los tienes en tu PC; CloudShell es otro ordenador. Para no subirlos uno a uno, súbelos en un solo zip.

1. En tu PC, comprime esta carpeta (la carpeta entera, no solo su contenido): clic derecho sobre 03.02-adminer y Comprimir en archivo ZIP (Windows 11), Enviar a > Carpeta comprimida en zip (Windows 10) o Comprimir (Mac). Obtienes 03.02-adminer.zip.
2. En la consola de AWS, comprueba que la región es eu-north-1 y abre CloudShell. Espera a que aparezca el prompt.
3. Pulsa Actions > Upload file, elige 03.02-adminer.zip y sube el fichero.
4. Descomprime, entra en la carpeta y deja los scripts listos:

unzip -o 03.02-adminer.zip && cd 03.02-adminer
sed -i 's/\r$//' *.sh
chmod -R u+rwX . && chmod +x *.sh
ls

Si ya subiste g214-materiales.zip (README principal), no necesitas este zip: entra con cd ~/g214-materiales/tema3/03.02-adminer y, si algún fichero da Permission denied, ejecuta allí chmod -R u+rwX . && chmod +x *.sh.

Qué hace cada línea: unzip -o descomprime (el -o sobrescribe sin preguntar si subes el zip otra vez) y cd entra en la carpeta; sed -i 's/\r$//' quita los finales de línea de Windows de los scripts (si no se quitan, bash falla con bad interpreter: /bin/bash^M o $'\r': command not found; si ya estaban bien, no cambia nada); chmod +x da permiso de ejecución (un zip creado en Windows no lo conserva; sin él, ./gestionar-adminer.sh da Permission denied; también puedes lanzarlo con bash gestionar-adminer.sh crear).

Qué verás: ls muestra gestionar-adminer.sh y README.md. Si no ves la carpeta, el zip se descomprimió en otro sitio: ls desde tu carpeta personal te dice dónde.

Alternativa para subir solo un fichero: Actions > Upload file y elige el script (es autónomo), y luego sed -i 's/\r$//' gestionar-adminer.sh && chmod +x gestionar-adminer.sh.

Si cierras CloudShell y vuelves más tarde, entra de nuevo con cd 03.02-adminer (tu carpeta personal normalmente se conserva entre sesiones de la misma región; si no la encuentras, vuelve a subir el zip). A diferencia de la versión anterior, ya no importa desde qué carpeta lances el script: lo que ha creado se averigua consultando AWS.

Paso a paso

Paso 1. Comprobar CloudShell y elegir opción.

aws sts get-caller-identity
echo "$AWS_REGION"

Qué verás: un JSON con tu cuenta y eu-north-1. El script trabaja siempre en eu-north-1 (la región del curso); si tu terminal está en otra región, lo avisan en amarillo justo después de mostrar la región (cierra CloudShell, cambia la región de la consola a Estocolmo y vuelve a abrirlo, para que la consola web y el script vean lo mismo).

Qué tienen en común las dos opciones:

• La misma máquina: Amazon Linux 2023 (la AMI más reciente, resuelta por SSM) con Apache, PHP y Adminer, que se descarga de adminer.org (latest-mysql.php, la edición para MySQL/MariaDB) y queda en /adminer-core.php; /adminer.php es un envoltorio de siete líneas que activa el cifrado TLS hacia la RDS (necesario con MariaDB 11.x) y carga el anterior. Tú abres siempre /adminer.php. Tipo de instancia por defecto: t3.small (INSTANCE_TYPE=t3.micro ./gestionar-adminer.sh crear lo cambia; en el modo cloudformation solo se admiten t3.micro, t3.small y t3.medium; el cambio con la opción B).
• Se lanzan en la VPC por defecto de la región, en una subred con IP pública. Si no hay VPC por defecto, el script se detiene con un mensaje que dice cómo crearla.
• Su Security Group abre el puerto 80 (HTTP, sin cifrar) a cualquier IP. No abre nada más, salvo en la opción B desplegada desde la consola si indicas un KeyName: entonces abre también el 22 (SSH).
• Se apagan solas a las 4 horas (se apagan, no se borran): ver «Apagado automático».
• Admiten subir ficheros de hasta 100 MB (límites de PHP ajustados y php-fpm reiniciado al instalar).
• Dan acceso de red a UNA de tus RDS, la que tú indiques: al crearse, listan las RDS de la región, te preguntan a cuál das acceso (Enter = a ninguna), te enseñan la regla que van a añadir y piden confirmación (s). La regla (puerto 3306 o 5432, el de esa RDS) se añade solo en el Security Group de esa RDS, con la descripción G214-Adminer (así el script reconoce después lo que añadió él); las demás RDS de la cuenta no se tocan (salvo que compartan Security Group: el script lo avisa). Si creas la RDS después, o quieres dar acceso a otra, repítelo con --grant-rds NOMBRE_DE_LA_RDS. Si no hay entrada por teclado (por ejemplo, sin terminal), no se concede nada salvo que uses crear --rds NOMBRE --si o --grant-rds NOMBRE --yes.
• Al eliminar, los dos quitan esa regla (solo las reglas cuyo origen es el Security Group de Adminer o llevan la descripción G214-Adminer; el resto del Security Group de tu RDS no se toca): AWS no deja borrar un Security Group mientras otro lo referencia.
• Resilientes: comprueban la AWS CLI y las credenciales al empezar, reintentan solos si AWS responde «Throttling», esperan con un máximo y enseñan el progreso, y si algo falla dicen qué ha pasado y qué hacer, sin trazas.
• Necesitan la AWS CLI con credenciales válidas (en CloudShell ya las tienes) y bash. No necesitan jq ni Python.

Comparativa:

Cuándo elegir: B (CloudFormation) si dudas: lo creado se ve y se borra como una unidad en la consola de CloudFormation y funciona igual que los scripts de los temas 4 y 5; es también tu plan B si la A no levanta Adminer. A (script) si no quieres pasar por CloudFormation. No despliegues las dos a la vez: tendrías dos máquinas y dos Security Groups facturando, y cada una añadiría sus propias reglas en tu RDS (el script avisa si detecta un Adminer del otro modo).

Paso 2A. Opción A: gestionar-adminer.sh

Solo te pregunta por teclado a qué RDS dar acceso (puedes pulsar Enter para no dar acceso a ninguna).

./gestionar-adminer.sh crear

Si lo lanzas sin nada (./gestionar-adminer.sh) se abre el menú numerado: elige 1) Crear.

Qué verás, en este orden (cada línea lleva un símbolo al principio; la secuencia exacta de mensajes de esta versión):

G214 - Instalación de Adminer
Región: eu-north-1
Buscando VPC por defecto...
VPC: vpc-...
Buscando una subred pública...
Subred: subnet-...
Resolviendo la AMI más reciente de Amazon Linux 2023...
AMI: ami-...
Preparando Security Group...
Security Group: sg-...
Lanzando instancia EC2 (t3.small)...
Instancia lanzada: i-...
Buscando instancias RDS existentes en eu-north-1...
RDS encontradas en eu-north-1:
  1) nombre-base-datos  (mariadb, puerto 3306, Security Group sg-...)
¿A cuál das acceso desde Adminer? (número o nombre; Enter = a ninguna): 1
Se va a añadir esta regla de entrada (solo en la RDS elegida):
  Security Group sg-... (el de nombre-base-datos): TCP 3306 <- Security Group de Adminer (sg-...)
¿Continuar? [s/N]: s
Acceso concedido: sg-... puerto 3306 <- Adminer (sg-...)
Adminer ya puede administrar la RDS nombre-base-datos.
Esperando a que la instancia esté en marcha...
Listo
G214 - Adminer
Instancia: i-...
IP pública: <IP>
URL: http://<IP>/adminer.php
(más notas sobre el apagado automático y la nueva IP)
Apagado automático: se apagará a las HH:MM UTC (dentro de 240 min). (...) Bórrala con 'eliminar' cuando ya no la necesites.

Tarda unos 35 segundos (medido con la versión anterior, sin contar lo que tardes en contestar a la pregunta de la RDS). La IP y la URL también quedan guardadas en informacion_adminer.txt (cat informacion_adminer.txt). Si no tienes ninguna RDS todavía, verás No hay ninguna instancia RDS todavía en eu-north-1 y una línea que te dice que ejecutes ./gestionar-adminer.sh --grant-rds NOMBRE_DE_LA_RDS cuando la crees. Si contestas con Enter, o el script no recibe entrada por teclado, no se concede acceso a nada (No se ha concedido acceso a ninguna RDS) y la creación continúa igual. Un número o un nombre que no está en la lista da No se ha cambiado nada. Si contestas n (o cualquier cosa distinta de s) a ¿Continuar?, dice No se ha cambiado nada. Para saltarte las preguntas: ./gestionar-adminer.sh crear --rds nombre-base-datos --si.

El script termina cuando la instancia está en marcha, pero Apache, PHP y Adminer se instalan después, dentro de la máquina. El propio script avisa de que puede tardar «~1 minuto»; medido: respondió al cabo de 1 min 15 s. Dale unos minutos antes de dudar. Después, ve al Paso 3.

Las demás opciones de la A:

./gestionar-adminer.sh estado                    # estado de la instancia y su URL actual
./gestionar-adminer.sh arrancar                  # arranca la instancia si está parada y renueva el plazo
./gestionar-adminer.sh extender --horas 6        # solo cambia el plazo (o --permanente)
./gestionar-adminer.sh --grant-rds               # lista tus RDS y te pregunta a cuál dar acceso
./gestionar-adminer.sh --grant-rds NOMBRE_RDS    # da acceso a esa RDS (pide confirmación; con --yes no pregunta)
./gestionar-adminer.sh eliminar                  # borra TODO (pide confirmación; con --si no pregunta)
./gestionar-adminer.sh extraer                   # escribe plantilla-adminer.yaml en la carpeta actual
./gestionar-adminer.sh ayuda                     # uso completo

• estado (antes --info) escribe Estado de tu Adminer, la instancia con su estado (running, stopped...) y, si está en marcha, URL: http://<IP>/adminer.php y si la aplicación ya responde. Termina con la línea «Apagado automático»: cuándo se apagará, PERMANENTE, o «ya se apagó: ejecuta crear para arrancarlo y ampliar el plazo» si está parada.
• arrancar (igual que volver a ejecutar crear) arranca la instancia parada, renueva el plazo de apagado automático, espera a que esté en marcha y te enseña la URL nueva (la IP cambia en cada parada y arranque).
• --grant-rds escribe Concediendo acceso a RDS, la lista de tus RDS (o usa la que le des por nombre), la regla que va a añadir y ¿Continuar? [s/N]; después Acceso concedido: .... Si esa regla ya existía dice La RDS <nombre> ya tenía concedido el acceso desde este Security Group. Si el nombre no existe, termina con error (No hay ninguna RDS llamada ...) sin tocar nada. Solo cambia el Security Group de la RDS elegida: las reglas van en el Security Group, no en cada RDS, así que si dos RDS comparten el mismo Security Group (por ejemplo BaseDeDatos), dar acceso a una lo da también a la otra (el script lo avisa). --yes omite la confirmación (úsalo solo cuando ya sepas qué RDS es).
• eliminar (antes --delete) enseña lo que va a borrar y pide confirmación (--si la omite). Después, a la fuerza y en este orden: quita de tu RDS las reglas de acceso que añadió, termina la instancia (si tuviera protección contra terminación, la desactiva), borra el Security Group reintentando hasta unos 3 minutos (AWS tarda en liberarlo) y limpia volúmenes sueltos. Al final hace una comprobación y escribe qué queda (Instancias EC2: ninguna, Security Groups: ninguno...) y Limpieza completa. Es idempotente: si lo repites, o si borraste algo a mano, no falla: borra lo que quede y confirma. Si algo no se pudo borrar, lo dice y sale con error: espera un minuto y repite ./gestionar-adminer.sh eliminar.

Qué pasa si repites la A:

Paso 2B. Opción B: gestionar-adminer.sh crear --modo cloudformation (CloudFormation)

Solo necesitas el script (la plantilla va dentro) y permiso de ejecución. Comprueba al empezar que la AWS CLI y las credenciales funcionan; si no, termina con un error que dice qué hacer.

./gestionar-adminer.sh --modo cloudformation

Qué verás: el encabezado G214 - Adminer (cloudformation), Región: eu-north-1 Modo: cloudformation y un menú numerado, que se repite después de cada acción hasta que eliges 0) Salir:

También admite modo directo, sin menú (los alias antiguos siguen funcionando):

./gestionar-adminer.sh crear --modo cloudformation   # opción 1 (o --create)
./gestionar-adminer.sh estado                      # opción 2 (o --status)
./gestionar-adminer.sh --grant-rds                 # opción 3 (te pregunta la RDS)
./gestionar-adminer.sh --grant-rds NOMBRE_RDS [--yes]    # sin preguntar la RDS
./gestionar-adminer.sh eliminar [--si]             # opción 4 (o --delete)
./gestionar-adminer.sh arrancar                    # opción 5
./gestionar-adminer.sh extender [--horas N|--permanente]   # opción 8
./gestionar-adminer.sh extraer                     # opción 6

Para crear el stack, escribe 1 y Enter (o usa crear). Qué verás (medido con la versión anterior: 61 segundos): Creando el stack de Adminer, la VPC y la subred detectadas, Creando stack 'cunef-adminer'..., Stack en creación. Esperando a CREATE_COMPLETE..., Stack creado correctamente y una tabla con los Outputs: InstanceId, PublicIP, AdminerURL y SecurityGroupId. Después te pregunta a qué RDS dar acceso (como en la A: lista, regla que va a añadir y ¿Continuar? [s/N]; Enter = a ninguna; Acceso concedido: ..., o No hay ninguna instancia RDS todavía en eu-north-1), escribe el resumen con la URL y termina con Apagado automático: se apagará a las HH:MM UTC (dentro de 240 min). (secuencia de mensajes de esta versión).

Copia la URL (http://<IP>/adminer.php). Apache, PHP y Adminer se instalan después de CREATE_COMPLETE, dentro de la máquina: el propio stack avisa de que puede tardar «~1 minuto» en responder. Después, ve al Paso 3.

Qué pasa si repites la B:

• Con el stack ya creado, crear (o escribir 1 en el menú) no crea nada: avisa El stack 'cunef-adminer' ya existe (estado: ...) y muestra su estado.
• Si el stack quedó a medias de un intento anterior (ROLLBACK_COMPLETE, CREATE_FAILED...), crear lo elimina por completo antes de crear uno nuevo, en vez de pedirte que lo hagas tú. Si la creación falla, el script enseña los motivos que informa CloudFormation.
• --grant-rds se puede repetir sin problema: si la regla ya existe se salta.
• Sin stack, estado, --grant-rds y arrancar avisan de que no hay nada y eliminar dice que no hay nada que borrar.
• Un número que no está en el menú escribe Opción no válida; un argumento desconocido escribe el error y el uso.

Opción B desde la consola (sin el script). Si prefieres hacerlo tú con la plantilla:

1. Escribe la plantilla en tu carpeta con ./gestionar-adminer.sh extraer (en CloudShell; luego descarga plantilla-adminer.yaml con Actions > Download file), o ejecútalo en tu PC con Git Bash/WSL. Consola de AWS (región eu-north-1) > CloudFormation > Create stack > With new resources (standard) > Upload a template file > plantilla-adminer.yaml > Next.
2. Nombre del stack: cunef-adminer. Conviene usar exactamente ese nombre: el script lo busca por él para eliminar (si usaste otro, lánzalo con G214_STACK=tu-nombre ./gestionar-adminer.sh eliminar).
3. Parámetros: VpcId (la VPC por defecto, normalmente la única), SubnetId (una subred pública de esa VPC), InstanceType (t3.small por defecto), LatestAmiId (déjalo como está), KeyName (opcional: solo si quieres entrar por SSH; déjalo vacío) y SSHLocation (solo cuenta si rellenas KeyName).
4. Next > Next > Create stack. Esta plantilla no crea recursos de IAM, así que no hay casilla que marcar. Espera a CREATE_COMPLETE.
5. Pestaña Outputs: abre AdminerURL. Apunta también SecurityGroupId.
6. Desde la consola NO se da acceso a tu RDS automáticamente. Dos formas: (a) en CloudShell, ./gestionar-adminer.sh --grant-rds (te pregunta la RDS; encuentra la instancia por su etiqueta G214-AdminerWebserver), o (b) a mano: EC2 > Security Groups > el de tu RDS (BaseDeDatos) > Edit inbound rules > Add rule, tipo MySQL/Aurora, origen el SecurityGroupId del punto 5.
7. Para borrar, usa ./gestionar-adminer.sh eliminar, que primero quita esas reglas. Si pulsas Delete stack en la consola con la regla puesta, el Security Group de Adminer sigue referenciado desde el de tu RDS y el borrado falla (DELETE_FAILED). Si te pasa, ejecuta ./gestionar-adminer.sh eliminar: lo resuelve él (quita la regla y vuelve a borrar, forzando si hace falta); o quita a mano de tu Security Group de RDS la regla de entrada cuyo origen es el de Adminer y vuelve a pulsar Delete stack.

Paso 2C (alternativa). Adminer en tu PC con Docker

No crea nada en AWS. Requiere Docker Desktop abierto:

docker run -d -p 8080:8080 adminer

Abre http://localhost:8080. Para que llegue a tu RDS necesitas que la RDS tenga Public access: yes y que su Security Group permita el puerto 3306 desde tu IP (la diapositiva 35 lo abre a todo Internet). El servidor es el endpoint de tu RDS. Usa el puerto 8080 de tu PC: si también quieres la web rdstest (03.04) a la vez, arráncala en otro puerto. La imagen adminer admite subir ficheros de hasta 128 MB (límite medido en adminer:latest; puede variar según la versión). Este Adminer local no lleva el envoltorio de cifrado de los scripts: con una RDS MariaDB 11.x puede responder Connections using insecure transport are prohibited. Usa la 10.11 (03.01) o el Adminer de los scripts. Para pararlo: docker ps y docker stop <id>.

Paso 3. Abrir Adminer y conectar con tu RDS (diapositiva 40).

1. Espera ~1-2 minutos tras el despliegue y abre http://<IP>/adminer.php con http://, no https:// (el Security Group solo abre el puerto 80). Y con /adminer.php al final: la raíz de la IP no muestra Adminer.
2. Rellena el formulario de entrada:
   • El formulario no tiene selector de sistema (la versión actual de Adminer solo conecta con MySQL/MariaDB): rellena Server, Username y Password y deja Database vacío.
   • Server: el endpoint de tu RDS, sin puerto y sin http://. Por ejemplo <identificador>.<código>.eu-north-1.rds.amazonaws.com.
   • Username: admin.
   • Password: la contraseña que elegiste al crear la RDS.
   • Database: déjalo vacío.
   • «Permanent login» (la diapositiva 40 lo menciona) es opcional. Mejor no marcarlo: entre tu navegador y Adminer la conexión va por HTTP sin cifrar (el tramo de Adminer a la RDS sí va cifrado) y esa opción guarda la sesión en una cookie.
3. Pulsa Login.

Qué verás: la pantalla principal de Adminer, con un menú a la izquierda (entre otras entradas, SQL command, Import y Export), el desplegable de bases de datos y la lista de bases que ya tiene tu RDS (al principio, solo las de sistema; si ya has hecho 03.03, aparecerá universidad).

Si no entra:

• Se queda cargando y acaba con un error de conexión o de tiempo agotado: la red no llega a la RDS. Mira «Errores frecuentes» (Adminer y tu RDS en la misma región, reglas del Security Group, RDS Available).
• Dice Access denied: usuario o contraseña incorrectos.
• Dice que no resuelve el nombre del servidor (getaddrinfo o Name or service not known): has escrito mal el endpoint.

Seguridad: la página de Adminer es pública por HTTP. No uses contraseñas que uses en otros sitios, pulsa Logout al terminar y borra Adminer al acabar (apartado Limpieza).

Subida de ficheros: un Adminer creado con los scripts de esta carpeta admite ficheros de hasta 100 MB (upload_max_filesize = 100M y post_max_size = 100M, en /etc/php.d/99-g214-upload.ini de la instancia; los scripts reinician php-fpm y httpd después de escribirlo). Los ficheros grandes de los ejercicios adicionales se tratan en 03.09. Si te sale Maximum allowed file size is 2MB, tu Adminer no tiene ese ajuste: o lo desplegaste con una versión anterior de los scripts (PHP, que en Amazon Linux 2023 corre en php-fpm, no se reiniciaba) o es otro Adminer. Con los scripts actuales no debería pasar; si te pasa, reinicia la instancia (aws ec2 reboot-instances --instance-ids <id-de-la-instancia> --region eu-north-1; la IP no cambia con un reinicio) y espera un minuto, o bórrala (eliminar) y créala de nuevo.

Paso 4. Apagado automático, reinicio y nueva IP (para cuando vuelvas otro día).

• A las 4 horas de crearla (o del último crear/extender), la máquina se apaga sola: la página deja de responder y la instancia queda en estado stopped. No se pierde nada y no hay que volver a instalar.
• Para seguir trabajando, arráncala. Sea cual sea el modo: ./gestionar-adminer.sh estado te dice que está parada y ./gestionar-adminer.sh crear (o arrancar) la arranca, renueva el plazo y te enseña la URL nueva. Por consola: EC2 > Instances > tu instancia (G214-Adminer o G214-AdminerWebserver) > Instance state > Start instance (si lo haces así con el plazo vencido, tendrá 60 min de gracia; ejecuta luego crear para ampliar). Por CLI:

aws ec2 describe-instances --region eu-north-1 \
  --filters "Name=tag:Name,Values=G214-Adminer,G214-AdminerWebserver" \
            "Name=instance-state-name,Values=pending,running,stopping,stopped" \
  --query "Reservations[].Instances[].[InstanceId,State.Name,PublicIpAddress]" \
  --output table
aws ec2 start-instances --instance-ids <i-tu-instancia> --region eu-north-1

• Al arrancar, Apache (y Adminer con él) arranca solo.
• La IP pública cambia en cada parada y arranque. La URL antigua, informacion_adminer.txt y, en la opción B, los Outputs del stack pueden mostrar la IP anterior. Mira la IP vigente con estado (que consulta la instancia) o en EC2, columna Public IPv4 address.
• Con lo que se crea no puedes entrar en la máquina (no hay puerto 22 abierto ni rol para SSM; en la B, desde la consola, solo si indicaste un KeyName): el plazo se cambia siempre con el script (crear / extender), que modifica la etiqueta g214-apagar-tras de la instancia.
• El vigilante del apagado automático se instala al principio del arranque de la máquina, así que, aunque la instalación de Adminer falle, la instancia se apagará igualmente. Aun así, si Adminer no responde pasados unos minutos, bórrala (eliminar) y reinténtalo.

Errores frecuentes

Scripts y CloudShell

Adminer

Si Adminer no conecta con tu RDS, comprueba por este orden:

1. La región de CloudShell (echo "$AWS_REGION") es la de tu RDS.
2. La RDS está en available y usa la VPC por defecto.
3. La regla existe. estado muestra el Security Group de Adminer (Security Group: sg-...); sustituye <sg-adminer> por él:

aws ec2 describe-security-groups \
  --filters "Name=ip-permission.group-id,Values=<sg-adminer>" \
  --query "SecurityGroups[].GroupId" --output text --region eu-north-1

Debe imprimir el Security Group de tu RDS. Si no imprime nada, concede el acceso con --grant-rds NOMBRE_DE_LA_RDS (A y B), contestando la RDS que quieras y s a la confirmación. Si imprime un Security Group que no es el de tu RDS, mira en RDS > tu instancia > Connectivity & security cuál es el suyo.

Limpieza

No borres Adminer todavía: las actividades 03.03, 03.04 (exportar), 03.05, 03.06 y 03.09 lo usan. Esta carpeta es la que lo borra; hazlo al terminar la última actividad que use Adminer (la 03.09) y antes de borrar la RDS (03.01), porque Adminer quita sus reglas de tu Security Group. Si vas a parar un tiempo, déjalo como mínimo apagado o bórralo y créalo de nuevo después.

• Opción A: ./gestionar-adminer.sh eliminar (o el menú, 4). Enseña lo que va a borrar y pide confirmación; después quita la regla de tu RDS, termina la instancia, borra el Security Group (reintentando mientras AWS lo libera) y escribe la comprobación final con Limpieza completa. Si ves Ha quedado algo sin borrar, espera un minuto y repite el comando: es seguro repetirlo y continúa donde se quedó. Funciona aunque hayas borrado algo a mano o hayas perdido el rastro de lo creado (no depende de ningún fichero).
• Opción B: ./gestionar-adminer.sh eliminar (o el menú, 4). Quita la regla de acceso de tu RDS, borra el stack y, si se atasca en DELETE_FAILED, lo fuerza (y como último recurso lo borra conservando los recursos atascados y los elimina a mano), y comprueba al final que no queda nada. Con el stack sano, el borrado limpio se midió en 50-55 s con la versión anterior.
• No hace falta indicar el modo: eliminar detecta si lo creaste con comandos o con CloudFormation (si tuvieras los dos a la vez, usa --modo cli o --modo cloudformation para elegir cuál borrar).
• Opción C (Docker): docker ps y docker stop <id>.

Verificación (todo en eu-north-1; el propio eliminar ya la hace al terminar, pero puedes repetirla a mano):

aws ec2 describe-instances --region eu-north-1 \
  --filters "Name=instance-state-name,Values=pending,running,stopping,stopped" \
  --query "Reservations[].Instances[].[InstanceId,State.Name,Tags[?Key=='Name']|[0].Value]" --output table
aws ec2 describe-security-groups --region eu-north-1 \
  --filters "Name=group-name,Values=g214-adminer-sg-*" --query "SecurityGroups[].GroupName"
aws cloudformation list-stacks --region eu-north-1 \
  --stack-status-filter CREATE_COMPLETE UPDATE_COMPLETE ROLLBACK_COMPLETE DELETE_FAILED \
  --query "StackSummaries[].StackName"

Qué debes ver: ninguna instancia G214-Adminer ni G214-AdminerWebserver (si tienes instancias de otros laboratorios, saldrán aquí: son de otro tema), ningún Security Group g214-adminer-sg-* y ningún stack cunef-adminer.

Cómo sabes que has terminado

• [ ] Adminer desplegado (A o B), abierto con http://<IP>/adminer.php y conectado a tu RDS: ves tus bases de datos.
• [ ] Sabes cómo arrancarlo de nuevo tras el apagado automático (crear) y que la IP cambia.
• [ ] (Al final del tema) Has borrado Adminer y la verificación sale vacía.

Anterior: 03.01 · RDS MariaDB · Siguiente: 03.03 · SQL con la tabla de estudiantes