Docker Compose

Importa un archivo compose una vez. Nodion lo convierte en una app, procesos y servicios gestionados.

Guías de despliegue paso a paso: Docker Compose.

Esta vía es experimental. No es docker compose up. Nodion no sigue ejecutando Compose, no aplica las redes y no vuelve a leer el archivo en despliegues posteriores.

En Applications → New, conecta un repo de Gity, si el escaneo encuentra un archivo compose con al menos un servicio de app, aparece la opción Docker Compose. No viene preseleccionada. Haz clic en ella para revisar el plan y después crea la app.

Qué archivo

Se elige el archivo más cercano a la raíz del repositorio entre estos nombres:

• docker-compose.yml / docker-compose.yaml
• compose.yml / compose.yaml

Un archivo que solo tiene bases de datos o cachés (sin servicio de app) se ignora. Si se produce un error al analizarlo, también se ignora. Un archivo compose muy anidado dentro de un repo grande puede pasarse por alto si el escaneo se trunca.

Qué se crea

Una sola aplicación, no una app por servicio. Los servicios adicionales se convierten en procesos adicionales de esa app. El asistente te deja elegir el plan y las réplicas (1-16) antes de crearla. deploy.replicas del archivo se ignora.

Los tags de imagen como postgres:16 no eligen la versión del motor gestionado. Nodion usa su versión predeterminada actual para ese motor. Nodion genera los usuarios y las contraseñas de la base de datos, no salen de las variables de entorno de compose del servicio de base de datos.

Si un valor de entorno de un servicio de app apunta a otro servicio como host (postgres://…@db:5432/…, redis://cache:6379), esa clave se convierte en una vinculación (attach binding) y se inyecta al desplegar. Si no, las bases de datos tipo Postgres se vinculan como DATABASE_URL, Valkey como REDIS_URL y MinIO con las claves AWS/S3 habituales.

Solo se copian a la app las variables de entorno restantes del servicio de app principal. Las claves que parecen contener secretos se marcan como secretas en el formulario.

Volúmenes

Los volúmenes con nombre se convierten en volúmenes (5 GB por defecto, editable en el asistente) y se montan en los procesos correspondientes. Los bind mounts (./data:/data) y los volúmenes anónimos se omiten.

Cómo se construye la app después

La estrategia de la app sigue siendo Dockerfile o Buildpacks, según el mismo escaneo del repo. build.context y build.dockerfile de Compose no se copian en esos ajustes. Hay una build de Git por app. Un segundo servicio con su propio build: comparte esa imagen.

Un servicio que solo tiene image: (y no es una base de datos mapeada) conserva esa imagen y la ejecuta como proceso. El servicio principal con build: se renombra a web.

El primer despliegue espera a que las bases de datos y los buckets vinculados estén listos. Después de crear la app, cambia los procesos, las variables de entorno y los recursos en el dashboard. Editar el archivo compose en Git no actualiza el plan.

Qué se ignora

• Redes, perfiles y health checks de Compose
• depends_on como orden de arranque (se omite un contenedor auxiliar que solo sirve para esperar)
• Bind mounts
• Builds por servicio más allá de la única imagen de la app

Si un motor gestionado o el almacenamiento de objetos no está disponible en la región, ese recurso se omite y la app se crea igualmente.