Separa las reservas de prueba de las reales

Introducción

STILL STUDIO organiza pequeños talleres de cerámica. Los invitados eligen un taller, reservan una plaza y ven su nombre en la lista. El equipo quiere probar una sesión en Garden Room sin ocupar plazas de la lista real de Riverside Room. Darás a la misma aplicación su propio entorno de staging: un sitio de pruebas claramente identificado con datos de reservas separados.

Basta con conocer el uso básico de la terminal. Aquí se presentan Docker Compose, la configuración, las rutas, los puertos y los volúmenes de datos. La aplicación y su imagen están suministradas; no escribes código ni instalas herramientas. Todas las reservas son ficticias. No se utilizan correos, pagos, cuentas externas ni información personal real.

Usa Live Bookings para el sitio preparado en el puerto 8081, Preview Bookings para tu sitio de staging en el puerto 8082 y Workstation para los comandos. Preview Bookings no está disponible hasta que lo inicies en el paso 2. Esta unidad comienza de forma independiente.

Conoce el negocio y configura la vista previa

En este paso, recorrerás una reserva normal y prepararás un conjunto separado de valores de configuración. Empieza en Live Bookings.

Reserva una plaza en el servicio normal

La página principal presenta el taller y muestra LIVE BOOKINGS, Riverside Room y 4 of 6 places left. Selecciona Explore the clay workshop. La página describe la sesión e incluye el campo Guest name. Introduce el nombre ficticio Live guest y selecciona Reserve a place.

El navegador abre Guest list con Maria, Jun y Live guest. Ahora quedan 3 of 6 places left. Es una escritura real en la base de datos, no un mensaje decorativo de éxito. Selecciona STILL STUDIO para volver al inicio. Conserva las tres reservas.

Si envías el mismo nombre dos veces por accidente, el sitio indica que ya está reservado y no añade otra reserva. Si escribes mal tu nombre, abre Guest list, selecciona Cancel únicamente junto a tu reserva equivocada y reserva de nuevo con Live guest. Nunca canceles a Maria o Jun ni vacíes toda la lista para corregir una errata.

Lee el límite de la configuración

Cambia a Workstation, que ya está en /home/labex/project/booking. Una ruta identifica un archivo o directorio. pwd imprime el directorio actual y ls muestra su contenido:

pwd

/home/labex/project/booking

ls

Deberías ver compose.yaml y live.env. cat imprime un archivo de texto:

cat live.env

PORT=8081
APP_ENV=live
VENUE=Riverside Room
CAPACITY=6
DATA_VOLUME=still-live-data

La configuración proporciona opciones a una aplicación sin cambiar su código. Estas líneas KEY=value seleccionan el puerto publicado, el distintivo del entorno, el lugar, la capacidad y el volumen de datos. VENUE cambia el lugar real mostrado en todo el sitio. CAPACITY limita las reservas aceptadas, en lugar de cambiar solo una etiqueta.

Docker ejecuta una aplicación en un contenedor creado a partir de una imagen guardada. Ambos sitios usarán la imagen suministrada still-booking:1. Cada contenedor recibe sus propias variables de entorno al crearse. Un volumen con nombre guarda la base de datos fuera del contenedor reemplazable. Distintos contenedores pueden compartir un volumen: un nombre de contenedor diferente no separa por sí solo sus registros.

Estos son los recursos preparados:

El nombre del volumen selecciona almacenamiento real. Nunca elijas el volumen de producción para reservas de prueba.

Entiende el pequeño archivo Compose

Docker Compose describe contenedores relacionados en un archivo YAML. YAML agrupa ajustes mediante sangría: conserva el espaciado suministrado y usa espacios, no tabulaciones. Lee el archivo proporcionado:

cat compose.yaml

Dentro de services, booking usa still-booking:1. La sección environment pasa valores a la aplicación. ${VENUE} indica que Compose sustituye el valor llamado VENUE antes de crear el contenedor. Un archivo de entorno aporta datos para esa sustitución; no cambia automáticamente un proceso que ya está ejecutándose.

ports establece ${PORT}:8000: antes de los dos puntos está el puerto publicado de la instancia del laboratorio; 8000 es donde escucha la aplicación dentro del contenedor. Los dos sitios necesitan puertos publicados distintos.

El servicio monta booking-data en /data, donde esta aplicación guarda su base de datos. La entrada de volumen de nivel superior resuelve ese alias como ${DATA_VOLUME}. external: true significa que el volumen ya existe y que Compose debe usar ese recurso exacto. Un nombre de proyecto agrupa contenedores de Compose; no cambia el nombre de un volumen externo seleccionado explícitamente.

Escribe y resuelve los valores de la vista previa

Mantén live.env sin cambios. Crea preview.env con estos valores. cat > preview.env reemplaza ese archivo. El ENV entre comillas inicia un here-document: pega el bloque completo, incluido el ENV final en su propia línea. Las comillas conservan el texto literalmente.

cat > preview.env <<'ENV'
PORT=8082
APP_ENV=staging
VENUE=Garden Room
CAPACITY=3
DATA_VOLUME=still-trial-data
ENV

Un puerto identifica un servicio de red. Aquí 8082 pertenece a Preview Bookings y 8081 sigue siendo Live Bookings. APP_ENV=staging activa el distintivo visible de pruebas. No selecciona por sí mismo almacenamiento separado: esa es la función de DATA_VOLUME.

--env-file preview.env indica a Compose qué valores sustituir. -p still-preview selecciona el proyecto. config imprime la configuración resuelta sin iniciar ni modificar contenedores:

docker compose --env-file preview.env -p still-preview config

Busca APP_ENV: staging, VENUE: Garden Room, capacidad 3, puerto publicado 8082 y volumen still-trial-data. El formato varía según la versión de Compose. Los valores resueltos son la prueba, no solo que el comando termine correctamente.

Si Compose informa de una variable o un archivo ausente, revisa pwd y cat preview.env, corrige la escritura repitiendo el here-document completo y vuelve a ejecutar config. Si tu shell ya exportó una variable como VENUE, su valor puede prevalecer sobre el archivo. unset VENUE elimina esa anulación del shell; aplica el mismo método solo a una clave en conflicto que hayas exportado intencionadamente. No inicies la vista previa hasta que los valores resueltos sean correctos.

Inicia la vista previa y prueba su capacidad real

En este paso, iniciarás la copia de staging y demostrarás que sus reservas utilizan una lista separada. Empieza en Workstation.

Inicia la aplicación configurada

up crea o actualiza los contenedores del proyecto. -d los mantiene en segundo plano, dejando disponible la terminal:

docker compose --env-file preview.env -p still-preview up -d

La salida nombra el contenedor creado. ps muestra el estado real del proyecto y el puerto publicado:

docker compose --env-file preview.env -p still-preview ps

Busca el servicio booking en ejecución y el puerto 8082 conectado a 8000. Si falla el arranque, logs imprime los mensajes de la aplicación:

docker compose --env-file preview.env -p still-preview logs

Un volumen externo no disponible suele indicar que el nombre del recurso está mal escrito. Corrige preview.env, repite config y después up -d. No crees un volumen sustituto para ocultar un destino equivocado. Un conflicto de puerto suele significar que elegiste el de producción: conserva 8081 y usa 8082 para esta vista previa.

Haz una reserva de prueba

Cambia a Preview Bookings y recarga si hace falta. La página principal debe mostrar STAGING · TEST BOOKINGS ONLY, Garden Room y 3 of 3 places left. Selecciona Explore the clay workshop, introduce Trial guest y pulsa Reserve a place. Guest list muestra ahora solo Trial guest, con 2 of 3 places left.

Cambia a Live Bookings, selecciona Guest list y recarga. Debe seguir mostrando Maria, Jun y Live guest, con 3 of 6 places left. Si aparecen aquí datos de prueba, deja de crear reservas de prueba. En Workstation corrige el volumen de la vista previa, aplica up -d y cancela únicamente tu registro de prueba identificable en la lista real. Conserva todas las reservas legítimas. Abre Preview Bookings y crea allí Trial guest después de corregir el aislamiento.

Esta comparación importa más que el distintivo. Una etiqueta de staging con una base de datos compartida seguiría consumiendo plazas reales.

Prueba la capacidad menor

Permanece en Preview Bookings. Sigue Back to the workshop y reserva Capacity A. Vuelve otra vez al taller y reserva Capacity B. La lista tiene tres invitados y 0 of 3 places left.

Intenta otra reserva, Overflow guest. La página debe indicar Every place is taken. y No booking was added. Sigue View the guest list: Overflow guest debe estar ausente. La capacidad menor cambió el comportamiento de la aplicación.

Cancela solo Capacity A y Capacity B, conservando Trial guest. La vista previa vuelve a 2 of 3 places left. Si escribes mal un nombre, cancela ese registro concreto y repítelo; no hace falta vaciar la base de datos. Regresa a Live Bookings y confirma que su lista y sus plazas restantes no han cambiado.

Compara los resultados legibles por máquinas

Cambia a Workstation. HTTP es el protocolo de petición y respuesta que utiliza el navegador. curl envía una petición; -sS oculta el progreso y muestra los errores de conexión. En Workstation, 127.0.0.1 significa esta instancia del laboratorio. Una URL combina protocolo, dirección, puerto y ruta del recurso. /api/info devuelve la configuración real y la lista de la base de datos como JSON, un formato de texto estructurado. No necesitas un lenguaje de consultas.

curl -sS http://127.0.0.1:8081/api/info

Lee live, Riverside Room, capacidad 6, plazas restantes 3 y los tres nombres reales. Los identificadores pueden variar.

curl -sS http://127.0.0.1:8082/api/info

Lee staging, Garden Room, capacidad 3, plazas restantes 2 y solo Trial guest. Son dos puntos de acceso distintos, no dos etiquetas de la misma lista.

Reemplaza la vista previa sin perder sus reservas

En este paso, reemplazarás el contenedor de la vista previa y confirmarás que sus datos separados sobreviven. Empieza en Workstation.

Comprueba el montaje real de almacenamiento

ps -q imprime únicamente el identificador del contenedor del proyecto. docker inspect lee sus ajustes reales. --format selecciona un campo; la plantilla entre comillas convierte sus montajes a JSON. La expresión de shell $(...) ejecuta el comando interior e inserta su salida como argumento del contenedor:

docker inspect $(docker compose --env-file preview.env -p still-preview ps -q booking) --format '{{json .Mounts}}'

Busca un montaje de tipo volume, nombre still-trial-data y destino /data. Un proyecto distinto no protegería los datos reales si este montaje se llamase still-live-data.

Recrea solo el contenedor de la vista previa

--force-recreate indica a up que reemplace el contenedor aunque no cambie su configuración. Los volúmenes con nombre montados permanecen. Esto también demuestra cómo llega la configuración a un proceso nuevo: editar el archivo de entorno no actualizaría un contenedor en ejecución.

docker compose --env-file preview.env -p still-preview up -d --force-recreate

Espera a que ps muestre el servicio en ejecución:

docker compose --env-file preview.env -p still-preview ps

Cambia a Preview Bookings y recarga Guest list. Trial guest debe seguir en Garden Room, con 2 of 3 places left. Cambia a Live Bookings y recarga su lista. Maria, Jun y Live guest deben seguir en Riverside Room, con 3 of 6 places left. Ni reemplazar un contenedor ni hacer una reserva de prueba debe borrar el otro entorno.

No uses la eliminación de volúmenes ni down -v como recuperación. Si la vista previa no arranca, usa logs del mismo proyecto, corrige sus valores y aplica up -d de nuevo. El entorno real preparado queda fuera de tu ámbito de cambios.

Comprueba páginas y respuestas juntas

En Preview Bookings, selecciona STILL STUDIO, abre el taller y después Guest list. La ilustración local, los detalles y la navegación deben seguir funcionando. Una página principal correcta no equivale al servicio de reservas completo.

Cambia a Workstation. El estado HTTP 200 indica una respuesta correcta; 404 significa que la ruta solicitada no existe. -o /dev/null descarta el cuerpo; -w imprime el formato entre comillas. %{http_code} es el estado HTTP y \n termina la línea:

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8082/bookings

Espera 200 y confirma en el navegador que la lista es la correcta. Un 200 que contiene una página equivocada no es éxito.

curl -sS -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8081/workshop

Espera 200: el taller real continúa disponible. Un fallo de conexión es distinto de una respuesta HTTP de error; revisa ps y logs si ningún servidor responde. Ahora tienes una imagen, dos procesos configurados por separado y dos listas de invitados independientes y duraderas. Es aislamiento de formación en una sola instancia, no una barrera de seguridad frente a un administrador con acceso a Docker.

Resumen

Configuraste e iniciaste una copia de staging de la misma aplicación, elegiste un volumen con nombre separado, probaste la capacidad real y comparaste ambas listas. Recrear la vista previa conservó su reserva mientras el servicio real mantuvo sus invitados originales. Otra etiqueta o proyecto de Compose ayudaba a organizar; el destino real de los datos estableció el aislamiento.