Despliegue y Operación
Ejecutar Chinaski en producción: los servicios systemd, el proxy inverso delante del site público, los scripts de despliegue y las páginas operativas (logs, performance, air-gap, promotions) que lo mantienen sano. La sección asume que la instalación de Getting Started está hecha; cubre lo que realmente estás ejecutando.
En esta sección
- Servicios systemd: las unidades de instancia templated (
chinaski@<N>, backup, MCP), qué hacen, su hardening y cómo habilitarlas/reiniciarlas. - Proxy Inverso: los dos objetivos del proxy (salida estática + el daemon del CMS), las rutas que deben reenviarse (
/forms/,/documents/), las cabeceras de proxy que importan y la regla de Confiar en la IP real del cliente. - El Servidor Hypnotoad: el modelo de servidor (master + workers), el comportamiento de recarga sin downtime, la configuración EOTW/offline incluida y la diferencia daemon-vs-hypnotoad.
- Configuración: convenciones del archivo de entorno, la
LISTEN_URL/LISTEN, el manejo del secreto y la organización de ajustes por instancia. - Hospedaje Estático: servir la salida construida con nginx o Caddy; los formatos
_redirectsy qué rutas debe seguir reenviando un sitio mayormente estático. - Despliegue SSH / rsync: empujar la salida construida a un host remoto después de cada build exitoso.
- Publicación desde un teléfono: correr el admin en un teléfono Android con Termux y publicar a Cloudflare R2 como host público.
- Publicación desde una laptop: correr el admin en una laptop Linux y publicar a Cloudflare R2 como host público.
- Publica tu sitio con Cloudflare R2: guía paso a paso para publicar tu sitio en Cloudflare R2: bucket, claves de acceso, dominio propio, regla de reescritura y ajustes de despliegue de Chinaski.
- Webhooks de Build y Publish: disparar webhooks en eventos de build/publish para notificar a sistemas externos.
- Modo air-gap: instalar y ejecutar completamente offline; qué deshabilita el interruptor; bundles offline y actualizaciones offline.
- Logs y Monitoreo: logging por journal, los endpoints de health, los logs de build y la vista de métricas.
- Rendimiento: paralelismo de build, cabeceras de caché, índices de base de datos y la historia de benchmarks.
- Promotion Guard: cómo un build se niega a degradar el site en vivo (caída de páginas, enlaces rotos, regresiones de accesibilidad) y las rutas de force/override.
Cómo encajan las piezas
El layout estándar de producción es pequeño:
- Una unidad systemd ejecuta el daemon del CMS enlazado a loopback (
LISTEN_URL=http://127.0.0.1:<port>). - Un proxy inverso (Caddy o nginx) sirve el site público desde el árbol de salida estática, reenviando solo las rutas de forms/documents/admin al daemon del CMS.
- Los builds regeneran el árbol estático, disparados desde el dashboard, un webhook o el script de deploy, y el script de deploy (o un destino rsync/S3) mueve la salida a la ubicación de servicio.
- El monitoreo corre contra los endpoints de health, y el modo air-gap (activo por defecto en instalaciones nuevas) mantiene todo el stack fuera del negocio de llamadas salientes salvo que se abra explícitamente.
El ciclo se cierra con los backups (su propia sección) y deploys que fallan de forma segura: un build fallido nunca reinicia el servicio sobre una salida que nunca fue promovida. Así, toda la historia operativa queda en dos minutos de lectura: qué está corriendo, qué se sirve, qué lo reconstruye, cómo mantener ambos al día y dónde mirar cuando no lo están.
También en Despliegue y Operación
Ejecuta Chinaski con systemd: las unidades de instancia, respaldo y MCP, qué hace cada una y cómo habilitarlas y reiniciarlas.
Coloca Caddy o nginx delante de Chinaski: sirve el sitio estático como archivos planos y reenvía formularios, documentos y la interfaz de administración al daemon.
Hypnotoad, el servidor de producción de Mojolicious: el modelo de master y workers, la recarga en caliente y su uso frente al daemon de systemd.
Define las seis variables de entorno principales por instancia, maneja los secretos con seguridad y sabe qué ajustes viven en el panel de administración.
Sirve la salida construida desde nginx, Caddy o cualquier hosting estático, incluidos los archivos _redirects y las rutas que aún deben llegar al CMS.
Envía el sitio construido a un host remoto por SSH después de cada build exitoso, con sus salvaguardas y lo que ocurre si falla.
Envía webhooks firmados cuando termina un build o se publica contenido programado, para activar pipelines o refrescar un CDN.
Instala y ejecuta Chinaski sin conexiones salientes: qué desactiva el interruptor, los paquetes offline y las actualizaciones offline firmadas.
Encuentra tus logs y vigila el sistema: journald y eventos de seguridad, historial de builds y autenticación en la app, y los endpoints de salud.
Ajusta el paralelismo de los builds, los encabezados de caché y los índices de la base de datos, empezando por los cambios que más importan.
Evita que un build defectuoso reemplace el sitio en vivo: las cuatro verificaciones de regresión, sus umbrales y cómo forzar un build.
Ejecuta Chinaski por completo en un teléfono Android con Termux, publicando el site construido en Cloudflare R2.
Ejecuta Chinaski en una laptop Linux que ya no uses y sirve el sitio público desde Cloudflare R2, para que siga en línea con la laptop apagada.
Publica tu sitio Chinaski en Cloudflare R2 paso a paso: bucket, claves de acceso, dominio propio, regla de reescritura y ajustes de despliegue.