Indice Docker

• Arranque de entorno
• Arranque automático de Docker en Spring
• TestContainers
• Backend en Docker (Dockerfile)

Arranque de entorno

1. Iniciamos docker desktop
2. Ejecutamos Run Java desde el fichero de arranque

Si Run Java no nos funciona, realizaremos el siguiente workflow.

1. Iniciamos docker desktop
2. Realizamos los siguientes comandos:

docker compose up -d #Esto inicializa el contenedor, deben salir 3 nodos, Container, Volume y Network

**NOTA: ** Revisa que el estado del contenedor es healthy

docker ps  #Lista de contenedores activos, debe salir el que está configurado en el docker-compose.yaml

Si tiene otro tipo de estado, no te va a funcionar.

Cerrar servicio

Tienes 2 formas de hacerlo:

Con permanencia de datos no pre-integrados en migraciones:

docker compose down  #Te cerrará 2 servicios pero mantendrá el volume

Sin permanencia de datos, todos los datos "volátiles" serán borrados al cerrarse el contenedor

docker compose down -v  #Cierra y elimina toda la metadata, te saldrán los 3 servicios cerrados

PRECAUCIÓN: BORRARÁS TODOS LOS DATOS QUE HAYAS INTRODUCIDO.

Usa siempre el primero para mantener el volumen, el cuál alberga todos los datos que hayas introducido o modificado.

---

Arranque-automático-contenedor

Revisa configuración ficheros locales.

tasks.json: Aquí se crean los comandos para automatizar el arranque y cierre.
launch.json: Aquí se insertan las tasks para que se ejecuten.

TestContainers

El objetivo de implementar esto es poder generar un contenedor postgreSQL para ejecutar los test tanto unitarios como integrales que requieran del uso de la base de datos.

Workflow

1. Se realiza el testing
2. Se inicia contenedor
3. Se ejecutan test
4. Se cierra contenedor

Para conseguir esto, creamos 3 ficheros:

• Situados en: src\test\java\restaurante\team3\Giacobello\infrastructure
  • TestContainers.java: Crea y configura el contenedor PostgreSQL para los test
  • IntegrationTest.java: Configuración para implementar el servicio en los test
• Situado en: src\test\resources\application-test.yml
  • application-test.yml: Levanta el contexto Spring para que compruebe que las entidades coinciden con el esquema de la DB sin modificarlo.

---

Para que la clase use este servicio simplemente tienes que extenderla. Adjunto Ejemplo:

class ClaseDeEjemploTest extends IntegrationTest {
    // tests
}

IMPORTANTE: No todos los test deben utilizar este servicio. Razona si lo necesitas o no para no añadir carga innecesaria al proceso.

Backend-en-Docker

Además de PostgreSQL, el backend se puede ejecutar en Docker. Sirve para arrancar el proyecto entero sin Java instalado (por ejemplo, el día de la presentación) con un solo comando.

Ficheros

Fichero	Qué hace
Dockerfile	Construye la imagen de la API
.dockerignore	Deja fuera de la imagen target/, .env, .git, .claude, docs/ y los .md
docker-compose.yaml	Levanta PostgreSQL y, si se pide, la API
.env.example	Plantilla del .env con las variables necesarias

Cómo está hecho el Dockerfile

Tiene dos etapas:

1. build (eclipse-temurin:21-jdk): descarga las dependencias con ./mvnw dependency:go-offline y compila el jar con ./mvnw package -DskipTests. Las dependencias se copian antes que src/, así que Docker las reutiliza de la caché mientras no cambie el pom.xml.
2. Imagen final (eclipse-temurin:21-jre): copia solo el jar y lo arranca con java -jar app.jar. No lleva Maven ni el código fuente, y se ejecuta con el usuario giacobello, no como root.

Los tests no se pasan al construir la imagen porque necesitan Docker (Testcontainers). Se pasan antes con ./mvnw clean verify.

El servicio app del docker-compose

Servicio	Contenedor	Puerto	Cuándo arranca
postgres	giacobello-postgres	5432	Siempre
app	giacobello-app	8080	Solo con --profile app

app está detrás del perfil app para no cambiar el flujo de trabajo de arriba: docker compose up -d sigue levantando solo la base de datos y la API se arranca desde VS Code. Con el perfil, Compose construye la imagen y espera a que PostgreSQL esté healthy antes de arrancar la API.

Variables que recibe app (salen del .env):

Variable	Valor
SPRING_PROFILES_ACTIVE	La del .env, o dev si no está
SPRING_DATASOURCE_URL y DATABASE_URL	jdbc:postgresql://postgres:5432/giacobello (postgres es el nombre del servicio dentro de la red de Compose, no localhost)
DATABASE_USERNAME y DATABASE_PASSWORD	Las del .env
TZ	Europe/Madrid, para que pedidos y facturas guarden la hora de España
SUPABASE_URL, SUPABASE_SERVICE_KEY, SUPABASE_REPORTS_BUCKET, SALES_REPORT_ARCHIVE_CRON	Para el resumen de ventas automático en Supabase. Vacías, esa tarea no se activa

Comandos

cp .env.example .env                          # la primera vez, y rellenar las credenciales
docker compose --profile app up -d --build    # PostgreSQL + API, reconstruyendo la imagen
docker compose --profile app logs -f app      # ver los logs de la API
docker compose --profile app down             # parar todo (mantiene los datos)

La API queda en http://localhost:8080/api/v1 y Swagger en http://localhost:8080/swagger-ui/index.html.

NOTA: --build hace falta cada vez que cambia el código; sin él, Compose reutiliza la imagen anterior. Y antes de levantar la API en Docker para la que tengas arrancada en VS Code, porque las dos usan el puerto 8080.