Despliegues

Un despliegue es una compilación y publicación de un servicio. Los servicios se ejecutan como pods de Kubernetes. Una compilación correcta no demuestra por sí sola que la aplicación se haya iniciado o pueda atender solicitudes.

Cómo ocurre un despliegue

Cualquiera de estas acciones inicia un despliegue:

• Un git push a la rama seguida (para servicios con código fuente github).
• lizard redeploy: recompila desde el commit más reciente (git) o la última carga, con las variables actuales.
• lizard up: carga el directorio actual y lo despliega.
• Un service set que cambia un campo que afecta a la compilación.

lizard redeploy --service api      # rebuild + redeploy from current source
lizard up                          # upload cwd and deploy

Ciclo de vida

1. Compilación: la plataforma ejecuta tu compilación (consulta Proceso de compilación).
2. Predeploy: si están configurados tanto preDeployCommand como startCommand, el contenedor ejecuta sh -c "<pre> && exec <start>". El comando de predeploy se ejecuta al inicio de cada contenedor (cada réplica, cada reinicio), así que hazlo seguro para ejecutarse muchas veces y al mismo tiempo. Sin startCommand se omite.
3. Inicio: Lizard inicia el nuevo pod junto al anterior. Los workers y los servicios con un volumen conectado detienen primero el pod anterior, así que dejan de funcionar un momento en cada despliegue y reinicio.
4. Comprobación de estado: una sonda TCP comprueba el puerto de la app cada 2 segundos, y el tráfico pasa solo a un pod listo. Lizard espera unos 30 segundos; si el nuevo pod no está listo para entonces, el despliegue se marca como fallido. Los workers omiten la sonda.
5. Verificación: inspecciona el estado de la publicación y llama a la URL de la aplicación. La accesibilidad del puerto no es una comprobación completa del estado de la aplicación.

Salida en streaming

Cuando ejecutas un lizard up sin separarlo de la terminal (o redeploy), los registros de compilación se transmiten en vivo. Con lizard up --json, obtienes un evento JSON por línea:

{ "event": "log", "line": "..." }
{ "event": "deployed", "status": "...", "url": "https://..." }

El último evento es deployed, failed o deploying. lizard redeploy --json no imprime líneas de registro: devuelve un objeto al momento (status: "deploying") o, con --wait, un objeto al final con ok y el status final. Usa --detach para iniciar el despliegue y volver inmediatamente sin transmitir la salida.

Inspección del historial

lizard events                  # deploy history + per-replica status
lizard events --limit 25       # show more
lizard ps                      # current services, status, and URLs

En el panel, la pestaña Resumen de cada servicio lista sus despliegues. Abre uno para ver su estado, origen, registros de compilación y reinicios.

Reinicios vs. redespliegues

Consulta lizard restart y lizard redeploy. Usa restart para reiniciar réplicas (por ejemplo, para aplicar un secreto de ejecución que no se recargó en caliente); usa redeploy cuando necesites una nueva compilación.

Recuperación tras un fallo

Inspecciona los registros del fallo o reinicio más reciente:

lizard logs --restart latest       # log tail around the latest restart
lizard logs --restart <id>         # a specific restart
lizard events                      # see replica status

Cambios de configuración (sin recompilar)

La mayoría de los cambios en variables de entorno y secretos se aplican sin recompilar: Lizard actualiza la configuración del servicio y lo reinicia, lo que tarda unos segundos. Los valores de tiempo de compilación (VITE_*, NEXT_PUBLIC_*) y los cambios en campos de compilación sí fuerzan una recompilación de un servicio en ejecución: consulta la tabla de desencadenantes de recompilación y las variables de tiempo de compilación.

Publicaciones fallidas y recuperación

Una compilación fallida y un inicio fallido de la aplicación son casos distintos. Una compilación fallida no cambia nada: la versión en ejecución sigue funcionando. Si un pod nuevo nunca llega a estar listo, un servicio HTTP sigue atendiendo su versión anterior y el pod nuevo no recibe tráfico. Los workers y los servicios con un volumen conectado detienen el pod anterior antes de que arranque el nuevo, así que una publicación que nunca llega a estar lista los deja sin funcionar. Inspecciona el servicio activo, los registros de compilación y los registros de ejecución. lizard redeploy vuelve a compilar el origen seleccionado; no es un comando para restaurar una compilación anterior. Revierte el commit del código fuente cuando sea necesario, desplíegalo y comprueba el resultado. Consulta problemas conocidos.

Actualizado 21 de octubre de 2026