ci: recrear Caddy cuando cambia su configuración - #54
Merged
Conversation
El Caddyfile entra en el contenedor como bind-mount de un fichero suelto, y eso ata el montaje al inode. `git reset --hard` en el VPS escribe un fichero nuevo, asi que Caddy se queda sirviendo el contenido viejo indefinidamente: un `up -d` a secas no lo arregla, porque su definicion en el compose no ha cambiado, y un `caddy reload` tampoco, porque dentro del contenedor el fichero sigue siendo el de antes. Paso de verdad con el PR #53: HSTS se desplego y no llego a produccion. Se comprueba el hash del Caddyfile antes y despues del reset y solo se recrea el contenedor si ha cambiado, para no cortar conexiones en cada despliegue. Es la misma clase de fallo que ya tuvo coturn, que es lo que hace pensar que merece la pena el hash y no solo recordar el comando.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Arreglo de un fallo que apareció al desplegar el PR #53: las cabeceras se subieron, pero HSTS
no llegó a producción.
Qué pasaba
El
docker-compose.ymlmonta el Caddyfile como bind-mount de un fichero suelto(
./Caddyfile:/etc/caddy/Caddyfile:ro), y eso ata el montaje al inode. El despliegue hacegit reset --hard origin/mainen el VPS, que escribe un fichero nuevo: el contenedor sigueviendo el anterior, indefinidamente.
Los dos arreglos evidentes no sirven:
docker compose up -d caddyno recrea nada, porque su definición en el compose no ha cambiado.caddy reloadtampoco: dentro del contenedor el fichero sigue siendo el de antes. Lo probé, yel reload dice
adapted config to JSONtan tranquilo mientras sirve lo viejo.Comprobado en el VPS: tras el despliegue,
docker compose exec caddy cat /etc/caddy/Caddyfiledevolvía la versión de hace dos semanas.
Arreglo
Se compara el hash del Caddyfile antes y después del
git reset, y solo entoncesdocker compose up -d --force-recreate caddy. Con el hash y no con un--force-recreatefijopara no cortar conexiones en cada despliegue: Caddy se reinicia en un segundo, pero un despliegue
de la app no tiene por qué tocarlo.
Es la misma clase de fallo que ya tuvo coturn hace dos releases —algo que vive en el VPS y que el
despliegue no recrea—, y por eso va con comprobación y no con un "acordarse del comando".
Estado de producción
Ya arreglado a mano mientras tanto, así que esto es para que no vuelva a pasar:
Y el contenedor de la app, con lo de #30:
drop Up (healthy),uid=1000(node).