Despliegue en Caddy
Caddy es el web server de referencia de Chinaski: TLS automático, y dos piezas de cableado por instancia; un site block que sirve el output estático, y el snippet de redirects generado por el builder incluido por site. Esta página recorre una configuración de Caddy en producción; el ejemplo de Caddyfile incluido es la copia fuente de la cual partir.
Requisitos previos
- Una instancia del CMS corriendo (la unidad
chinaski@<N>), con el daemon atado a loopback. - Un directorio de output construido por idioma (
/var/www/chinaski<N>/output/<lang>, uoutput/para sites monolingües). - El ejemplo incluido
deploy/chinaski.Caddyfile.examplepara copiar.
Copia y adapta el ejemplo
Caddy no tiene templating de instancias, así que cada deploy recibe su propia copia editada. En el ejemplo, define por instancia:
- Los hostnames del site (el dominio del admin más los vhosts de idioma que haya).
- El puerto del upstream; la dirección de loopback que coincide con
LISTEN_URLen el archivo de env de esa instancia (instancia 1 → 3001, instancia 2 → 3002). - Los document roots; los directorios de output por idioma.
Caddy obtiene y renueva los certificados TLS automáticamente una vez que el DNS apunte al host y los puertos 80/443 sean alcanzables; no hay paso de certbot. Verifica con curl -I https://<host> tras el primer arranque.
Los forwards que incluye el ejemplo
Un site Caddy mayormente estático todavía reenvía esto al daemon del CMS en loopback:
/forms/*: renderizado público de formularios y manejo de POST. Sin esto, los envíos de formularios embebidos devuelven 404./documents/*: descargas de documentos (el path de track-and-count que un file server estático no puede hacer).- Paths honeypot de scanner (
/.env,/.git/config,wp-login.phpy amigos); enrutados al CMS para que las sondeos queden en el log y con throttle en lugar de responderse con un 404 plano del server.
El ejemplo también incluye una ruta de descarga del installer servida directo del directorio de deploy; útil para el patrón documentado de URL del installer con curl.
Las llamadas del proxy fijan X-Forwarded-For, X-Forwarded-Proto y X-Forwarded-Host explícitamente, que es justo lo que pide el checklist de producción del README; y como el ejemplo hace proxy desde loopback (confiable por defecto), no se necesita ningún CHINASKI_TRUSTED_PROXIES extra; solo un hop de red de contenedores lo requeriría.
Encabezados de caché
El bloque incluido coincide con la política estándar de cache (HTML con cache corto revalidado por build; sw.js no-cache; fonts inmutables por un año; otros assets diarios), y repite el set de security headers de la app como doble seguridad para respuestas servidas antes de que la app pueda hacerlo.
Incluir los redirects generados
Después de cada build, el builder escribe _redirects.caddy en la raíz del output; tus redirects de slug más (cuando hay un Site URL configurado) el enforcement del dominio canónico como en el _redirects del mismo archivo. Incluye el snippet con sintaxis Caddy en cada site block como lo indica el header comment del propio archivo; como la línea de dominio canónico de Caddy usa el marcador de fuerza 301!, este archivo está pensado específicamente para Caddy (otros hosts deberían revisar esa sintaxis como se describe en la página de formatos de redirect).
La confianza del loopback local significa cero config extra
El ejemplo hace proxy desde 127.0.0.1, que el CMS ya confía; así el logging de la IP del cliente y el rate limiting por IP funcionan sin settings extra. Si tu topología en cambio hace proxy desde una dirección no loopback (un puente de contenedor, por ejemplo), agrega esa red a CHINASKI_TRUSTED_PROXIES para que la IP real del visitante sea la que quede en el log y la limitada.