La API en una URL

Antes de empezar. El backend de Servidor tiene CI y una versión revisada en main. Hoy publicarás su JAR en una EC2 de AWS Academy Learner Lab. Conservamos el repositorio y el contrato existentes.

Preparación del docente antes de esta clase. Crear la clase Learner Lab, matricular o invitar al alumnado y comprobar un acceso de estudiante. Tener AWS Academy no significa tener ya un laboratorio asignado. La preparación de cuentas y la resolución de invitaciones se hacen antes del taller. El nombre DNS necesario para HTTPS también debe acordarse con antelación; el alumnado no tiene que comprar un dominio.

Recorrido de hoy: descargar el JAR aprobado → entrar en el laboratorio → crear una máquina → copiar el JAR → arrancarlo → comprobar su URL → detener la máquina. En las siguientes sesiones se reutiliza esa máquina.

Se explica

25 minutos · explicación y demostración

El entorno de este curso

Vas a pasar por tres pantallas distintas. No necesitas abrir una cuenta nueva en la web comercial de AWS:

EC2 es el servicio de máquinas virtuales; una instancia es tu máquina concreta. La región indica dónde se aloja. El grupo de seguridad es su filtro de conexiones. El JAR contiene tu aplicación Java. La clave PEM permite identificarte al entrar por SSH y debe mantenerse privada.

Usaremos AWS Academy Learner Lab, sin una cuenta personal de pago. El docente debe crear la clase e invitar al alumnado antes del taller. La cuenta docente no se comparte: cada estudiante utiliza el entorno asignado. Comprueba allí el presupuesto y las fechas, sin dar por supuesto un importe universal.

La sesión dura cuatro horas por defecto y puede renovarse con Start Lab antes de finalizar. Al terminar, EC2 se detiene; las instancias que estaban encendidas se vuelven a iniciar al abrir otra sesión, según la guía del laboratorio. El disco se conserva mientras dure el curso y haya presupuesto. La IP pública puede cambiar. Se evalúa una publicación de laboratorio comprobada durante las sesiones, con fecha, versión y evidencias conservadas; no se exige disponibilidad permanente.

El temporizador mide esta sesión, no una cuota de cuatro horas semanales. El dinero indicado es el presupuesto total de tu laboratorio para la clase: no se repone cada día ni al pulsar Start Lab. El indicador de gasto puede actualizarse con retraso; un valor de cero no demuestra que todos los recursos sean gratuitos.

La configuración de referencia es Ubuntu 24.04 LTS, t3.small, 8 GiB de disco y región us-east-1. Usaremos Java 21, Nginx y systemd. En la sesión 12 PostgreSQL utilizará el disco de esa misma máquina y escuchará solo en localhost. No necesitamos RDS, balanceador, NAT Gateway ni IP elástica. El almacenamiento puede seguir generando consumo con la instancia detenida; revisa inventario y presupuesto al cerrar.

CI y publicación son pasos distintos

GitHub Actions compila, prueba y conserva el JAR. Después, una persona publica ese mismo artefacto aprobado y registra su commit. Es integración continua y despliegue manual trazable, no despliegue continuo automático. Learner Lab restringe IAM: no se crean usuarios ni roles propios para conectar GitHub con AWS. No copies credenciales temporales del laboratorio a GitHub ni instales un runner persistente en una máquina expuesta.

HTTP de prueba y HTTPS del producto

La primera comprobación utiliza HTTP y datos ficticios sin autenticación. No envíes contraseñas, tokens ni datos personales por esa conexión. Antes de integrar un cliente servido por GitHub Pages o activar autenticación, hace falta HTTPS válido: el navegador bloquea las peticiones de una página HTTPS a una API HTTP. Abrir 443 por sí solo no instala TLS. El procedimiento de nombre y certificado aparece al final de esta sesión.

Se trabaja

140 minutos · trabajo guiado sobre el producto compartido

Bloque A · Conservar el artefacto aprobado

Mediante PR añade estos pasos al final del job de la sesión 7, después de verify. El ejemplo presupone un único módulo Maven y un JAR ejecutable de Spring Boot. Si hay varios módulos, fija la ruta concreta del backend.

      - name: Preparar el artefacto de main
        if: github.event_name == 'push' && github.ref == 'refs/heads/main'
        shell: bash
        run: |
          mkdir -p entrega
          mapfile -t jars < <(find target -maxdepth 1 -type f -name '*.jar' ! -name '*-sources.jar' ! -name '*-javadoc.jar')
          test "${#jars[@]}" -eq 1
          cp "${jars[0]}" entrega/app.jar
          printf '%s\n' "$GITHUB_SHA" > entrega/commit.txt
          (cd entrega && sha256sum app.jar > app.jar.sha256)

      - name: Conservar el JAR verificado
        if: github.event_name == 'push' && github.ref == 'refs/heads/main'
        uses: actions/upload-artifact@v4
        with:
          name: backend-${{ github.sha }}
          path: entrega/
          retention-days: 14

Fusiona la PR y espera al CI de main. Descarga desde Actions → ejecución correcta → Artifacts el archivo de esa ejecución. Extrae app.jar, commit.txt y app.jar.sha256 en una carpeta de entrega. Comprueba que el commit corresponde a main y que el JAR es ejecutable. No compiles otra versión para publicar. Conserva el artefacto fuera de la retención temporal de Actions si lo necesitas para recuperación.

Cómo encontrarlo: en tu repositorio de GitHub abre Actions, pulsa la ejecución de CI asociada al último commit aprobado de main y espera el indicador verde. Al final de su página aparece Artifacts, con un archivo llamado backend- seguido del commit. Descárgalo y utiliza Extraer todo en Windows; no trabajes dentro del ZIP. Si no aparece, comprueba que estás en una ejecución posterior a la fusión en main, no en la ejecución de la PR, y que terminó el paso de subida del artefacto.

Antes de seguir: debes ver tres archivos sueltos en la carpeta extraída: app.jar, commit.txt y app.jar.sha256. Abre commit.txt: es el identificador de la versión que vas a publicar. No abras ni descomprimas el JAR.

Bloque B · Crear el entorno una sola vez

1 · Entrar en tu clase. En AWS Academy abre el LMS y la clase indicada por el docente. En Módulos, pulsa Lanzamiento del Laboratorio para el alumnado de AWS Academy. Si no ves la clase o hay un requisito inicial pendiente, comunícalo al docente; no elijas otro curso ni crees una cuenta de pago.

2 · Activar la sesión. Pulsa Start Lab una vez y espera. El indicador junto a AWS debe ponerse verde; en el primer acceso puede necesitar varios minutos. No pulses Reset. Cuando esté listo, pulsa AWS para abrir la consola en otra pestaña. Si el navegador bloquea esa ventana, permite la apertura de la consola para esta página. Mantén abierta la pestaña del laboratorio.

3 · Elegir la región y el servicio. En la esquina superior derecha de la consola selecciona Estados Unidos (Norte de Virginia) / US East (N. Virginia), us-east-1. En el buscador superior escribe EC2, abre ese servicio y pulsa Lanzar instancia / Launch instance. Si ves recursos vacíos o errores de permisos, comprueba la región antes de crear nada más.

4 · Completar la máquina. Despliega cada apartado del formulario y utiliza esta tabla. Cambiar la imagen del sistema puede restablecer otros campos: revisa la red otra vez al terminar.

El JDK de la plantilla es Java 21: si el proyecto exige otra versión, acuerda y verifica la adaptación antes de continuar. Si no aparece una opción exacta, pregunta antes de elegir una máquina mayor o de pago diferente.

5 · Guardar la clave privada. Vuelve a la pestaña Learner Lab y abre AWS Details → Download PEM. Guarda el archivo, normalmente labsuser.pem, en una carpeta privada de tu equipo, fuera del repositorio y de las entregas. También puedes usar ese PEM con OpenSSH en Windows; PPK corresponde a otras herramientas, como PuTTY. Regresa a la consola sin cerrar el laboratorio.

6 · Configurar red y acceso. En Configuraciones de red / Network settings, utiliza Editar / Edit si necesitas ver todos los campos. Conserva la VPC predeterminada y una subred pública predeterminada, con Asignación automática de IP pública: Habilitar / Enable. Crea un grupo de seguridad para esta práctica. Sus únicas reglas iniciales son:

El menú Mi IP / My IP puede rellenar la dirección que ve la consola, pero debes contrastarla con la indicada para tu conexión de aula. No uses tu IP privada de Windows ni dejes SSH en Anywhere / Cualquier lugar. Si cambias de red, puede hacer falta actualizar esa regla. No abras 5432 ni 8080: la base y Spring Boot se comunican dentro de la máquina.

7 · Preparar el arranque. Abre Detalles avanzados / Advanced details. En Especificación de crédito / Credit specification, elige Estándar / Standard. Conserva IMDSv2 obligatorio y deja el perfil de IAM sin seleccionar. Al final aparece Datos de usuario / User data: es un cuadro para un script de arranque, no tus datos personales.

Descarga la plantilla de preparación de EC2. Ábrela como texto en VS Code o Bloc de notas, copia todo desde #!/bin/bash hasta el final y pégalo en ese cuadro. Si el enlace muestra texto en el navegador, también puedes copiarlo desde ahí. No ejecutes el archivo en Windows, no pegues la dirección del enlace y no marques que está codificado en base64. La plantilla prepara Java, Nginx, PostgreSQL y systemd; no crea otra API ni descarga el código del alumno.

8 · Revisar y lanzar. Contrasta imagen, tamaño, disco, número de máquinas y reglas con las tablas anteriores. Pulsa Lanzar instancia / Launch instance una vez. Anota el ID que empieza por i- y abre sus detalles. En Instancias / Instances, espera a que figure En ejecución / Running. Ese estado solo confirma que la máquina está encendida; no garantiza que haya terminado la instalación.

9 · Comprobar la instalación. Selecciona tu instancia y abre Acciones → Monitoreo y solución de problemas → Obtener registro del sistema / Actions → Monitor and troubleshoot → Get system log. Actualiza el registro hasta ver INTERMODULAR_INFRASTRUCTURE_READY. Es el mensaje final de nuestra plantilla. Si hay un error o no aparece tras varios minutos, conserva el mensaje y revísalo con el docente. No lances otra máquina para ocultar el fallo.

10 · Guardar la dirección. En los detalles de la instancia copia Dirección IPv4 pública / Public IPv4 address. Esa dirección sustituirá IP_ACTUAL en los comandos. La IPv4 privada y el ID i-... no sirven para conectarte desde tu portátil por Internet. La página web puede devolver 502 Bad Gateway en este punto: Nginx está preparado, pero todavía no hemos instalado el JAR.

No lances otra instancia en cada sesión. Anota su ID y grupo de seguridad. La plantilla se ejecuta una vez sobre una máquina nueva, no sobre una base con datos.

Bloque C · Publicar el JAR de esa ejecución

Este bloque empieza en Windows. Abre la carpeta que contiene los tres archivos extraídos del artefacto, haz clic derecho en una zona vacía y elige Abrir en Terminal. Utiliza PowerShell, no la terminal del servidor ni la de otro repositorio. Ejecuta primero Get-ChildItem: debes ver app.jar, commit.txt y app.jar.sha256.

Antes de copiar comandos, prepara estas sustituciones:

Escribe un comando cada vez. Espera a que termine y comprueba el resultado antes del siguiente:

Get-FileHash ./app.jar -Algorithm SHA256
scp -i "RUTA_A_LA_CLAVE.pem" ./app.jar ./commit.txt ./app.jar.sha256 ubuntu@IP_ACTUAL:/home/ubuntu/
ssh -i "RUTA_A_LA_CLAVE.pem" ubuntu@IP_ACTUAL

El primer comando muestra el hash: compáralo con el texto de app.jar.sha256; mayúsculas y minúsculas no cambian su valor. scp copia archivos y vuelve a PowerShell al terminar; ssh abre una terminal en Ubuntu. Ninguno pide la contraseña de PostgreSQL. En la primera conexión contrasta la huella SSH con la publicada por la instancia en su registro de arranque antes de aceptarla. No desactives esa comprobación.

Cambio de terminal: ahora estás en Ubuntu. El indicador suele parecerse a ubuntu@ip-...:~$, en lugar de PS C:\...>. No copies esos indicadores ni los signos $ de un ejemplo. Ejecuta whoami: debe responder ubuntu. Los siguientes comandos actúan en la máquina de AWS:

cd /home/ubuntu
sha256sum -c app.jar.sha256
sudo install -o root -g intermodular -m 640 app.jar /opt/intermodular/app.jar
sudo install -o root -g intermodular -m 640 commit.txt /opt/intermodular/commit.txt
sudo systemctl enable intermodular
sudo systemctl restart intermodular
sudo systemctl status intermodular --no-pager
sudo journalctl -u intermodular -n 60 --no-pager

Qué debes ver: sha256sum muestra app.jar: OK; systemctl status indica active (running) y los logs terminan mostrando el arranque de Spring Boot sin una excepción. Un estado activo momentáneo no basta si el proceso se reinicia continuamente: revisa también los logs. Para volver a PowerShell escribe exit. Cerrar SSH no detiene la API, porque la mantiene systemd.

La primera publicación conserva la configuración en memoria de Servidor; no adelantes JPA ni cambies de proyecto. Si la versión ya necesita base de datos, prepara primero la configuración de la sesión 12. El servicio mantiene Java escuchando en 127.0.0.1:8080; Nginx recibe el tráfico de Internet en el puerto 80. No uses una terminal que haya que dejar abierta para mantener la API.

Para actualizar, detén primero intermodular, conserva el JAR y commit.txt anteriores como recuperación, verifica el nuevo hash, instala ambos archivos y arranca el servicio. Si falla la comprobación, restaura la pareja anterior y registra el incidente. Un cambio de esquema necesita además su plan de recuperación de datos.

Bloque D · Comprobar y diagnosticar

En Ubuntu prueba una ruta real del proyecto contra http://127.0.0.1:8080, después contra http://127.0.0.1 y finalmente desde otro equipo contra http://IP_ACTUAL. /api/estado pertenece solo a la demo docente y no tiene que existir en tu API.

Por ejemplo, solo si tu colección ya utiliza /tareas, ejecuta en Ubuntu curl -i http://127.0.0.1:8080/tareas y después curl -i http://127.0.0.1/tareas. En tu navegador de Windows abre http://IP_ACTUAL/tareas, sustituyendo la IP. Si tu ruta es otra, utiliza exactamente la de tu colección en las tres comprobaciones. Un estado 200 y la respuesta esperada acreditan la consulta; una colección vacía puede devolver [] correctamente. Una ruta que exige permisos puede devolver 401 o 403, lo que requiere comprobar el contrato y no inventar un fallo de red.

Registra ejecución de CI, commit, hash, IP/URL, fecha y petición con resultado. Un curl localhost no acredita acceso público.

Bloque E · HTTPS antes del cliente y la autenticación

El docente debe proporcionar o acordar un nombre DNS público que pueda administrar. Su registro A debe apuntar a la IP actual de EC2. El nombre público de AWS no es un dominio que el alumno pueda administrar para emitir su propio certificado.

Con el nombre preparado, cambia server_name _; en /etc/nginx/sites-available/default por ese nombre, comprueba sudo nginx -t y recarga Nginx. Autoriza TCP/443 en el grupo de seguridad manteniendo 80 para la validación HTTP. En Ubuntu:

sudo apt-get install -y certbot python3-certbot-nginx
sudo certbot --nginx -d NOMBRE_ACORDADO
sudo certbot renew --dry-run

El titular debe revisar las condiciones del emisor al configurar el certificado. Comprueba desde otro equipo nombre, certificado válido y redirección a HTTPS. Si cambia la IP, actualiza DNS y comprueba de nuevo. La instalación anterior usa los paquetes de Ubuntu; consulta las instrucciones oficiales de Certbot para otras opciones de instalación y no mezcles paquetes apt y snap.

Si aún no existe un nombre y certificado válidos, conserva la evidencia HTTP y registra HTTPS pendiente. No presentes el cliente de GitHub Pages ni la autenticación como completados, ni resuelvas el contenido mixto desactivando protecciones. La integración posterior requiere resolver este requisito.

Cierre

15 minutos · comprobación del resultado

Comprueba la ruta pública, relaciona el JAR con el commit aprobado y explica CI frente a publicación manual. Anota si HTTPS está comprobado o pendiente. Antes de cerrar, revisa presupuesto e inventario y detén la instancia desde EC2 si has terminado; cerrar SSH no la apaga. Mantén el disco para la siguiente sesión. Al reabrir el laboratorio comprueba estado, IP y URL antes de repetir la colección.

Apagado al terminar: en EC2 → Instancias, selecciona solo tu máquina por nombre e ID y pulsa Estado de la instancia → Detener instancia → Detener. Espera a ver Detenida / Stopped. Después vuelve a la pestaña Learner Lab, pulsa End Lab y confirma el cierre. Detener conserva el disco; Terminar / Terminate elimina la máquina y puede borrar sus datos; Reset restablece el entorno. No son botones equivalentes. Conservar el disco mantiene un coste de almacenamiento aunque no haya cómputo.

Al empezar otro día: abre el mismo laboratorio con Start Lab, espera el indicador verde y entra en EC2 en us-east-1. Localiza el ID guardado. Si está detenida, usa Estado de la instancia → Iniciar instancia; no vuelvas a pulsar Lanzar instancia. Copia la IPv4 pública actual, comprueba el arranque y actualiza los destinos de SSH, la colección y DNS si procede. Conserva vockey y el disco: no repitas los datos de usuario, la creación de la base ni el esquema inicial.

Si la clase de AWS Academy ya terminó o se agotó el presupuesto, consulta al docente: crear otra instancia no recupera los archivos. Conserva fuera del laboratorio el código, el artefacto aprobado y las copias de datos que necesites.