Canal de compilación

Las compilaciones se ejecutan en los nodos de compilación de Lizard — no necesitas Docker localmente. Cuando despliegas, la plataforma decide cómo convertir tu código fuente en una imagen de contenedor usando un orden de decisión fijo, y luego ejecuta esa imagen en un pod aislado. No todos los container as a service compilan la imagen por ti; el blog compara las tres formas en que se presenta esta categoría.

Orden de decisión de compilación

La plataforma elige exactamente una estrategia de compilación, en este orden:

1. Dockerfile sintetizado — si buildCommand y/o startCommand están configurados en el servicio (o se pasan mediante lizard up --build-command / --start-command), Lizard genera un Dockerfile a partir de esos comandos. lizardpack no se invoca.
2. Dockerfile del repositorio (literal) — si dockerfilePath está configurado en el servicio, ese Dockerfile de tu repositorio se usa sin cambios.
3. Autodetección de lizardpack — en caso contrario, la plataforma clona tu código fuente y ejecuta lizardpack, su generador de buildpacks/Dockerfile.

Autodetección de lizardpack

lizardpack inspecciona tu repositorio y construye una imagen optimizada de múltiples etapas. Stacks compatibles, emparejados en este orden:

Hugo → Go → Node → Python → Rust → Ruby → PHP → Java → static

Consulta las Guías de frameworks para ver scripts de producción, adaptadores, rutas de salida y puertos. La detección usa archivos del proyecto y dependencias; un repositorio que coincida con varios proveedores sigue este orden.

En esta ruta:

• Si existe un Dockerfile del repositorio y tiene un paso de compilación real (una línea RUN <package-manager>, no solo COPY dist/), se usa literalmente.
• En caso contrario, lizardpack genera el Dockerfile por ti.
• El comando de inicio se detecta automáticamente: una línea Procfile web: (Python/Ruby) o package.json scripts.start (Node) se recoge automáticamente. Para ver la línea exacta que quieren Django, Flask y FastAPI, consulta hosting de aplicaciones Python.
• El puerto se infiere a partir de EXPOSE, los valores predeterminados del framework o una variable de entorno PORT explícita.

Ojo: Un Dockerfile que solo copia artefactos ya compilados (COPY dist/, build/, out/, .next/, public/) sin un paso de compilación RUN se considera incompleto y lizardpack lo regenera. Añade un paso de compilación real o configura dockerfilePath para forzar el uso literal.

Qué activa una reconstrucción

No compiles dos veces. Después de un service set que cambia un campo de compilación, la reconstrucción se activa automáticamente — no encadenes un lizard redeploy después, o pondrás en cola una segunda compilación redundante.

Ver una compilación

Los registros de compilación se transmiten durante lizard up. Para cualquier servicio:

lizard logs --build            # the most recent build's logs
lizard events                  # deploy history + replica status

Si una compilación falla, lee lizard logs --build, corrige la causa (en tu repositorio o ajustando buildCommand / startCommand mediante lizard service set) y luego lizard redeploy.

Notas de runtime

• Sin Docker HEALTHCHECK. El runtime no ejecuta el ciclo de healthcheck de Docker, por lo que las directivas HEALTHCHECK se ignoran. Lizard ejecuta en su lugar una sonda TCP contra tu puerto (omitida en modo worker).
• No escribas un Dockerfile sin necesidad. lizardpack detecta automáticamente la mayoría de los stacks — prueba primero con un despliegue y añade un Dockerfile (o configura dockerfilePath) solo si la compilación automática no se ajusta a tu caso.

Referencia de configuración de compilación

Configura cualquiera de estos con lizard service set <svc> --set <field>=<value>. Consulta lizard service.