525 - Blog vacacional hundido por Ghost y Watchtower
Descubre la crónica de un proyecto de blog vacacional naufragado debido a desafíos con Ghost y Watchtower. Todo para descubrir que un fue error humano
Entre los proyectos de esta pasada temporada, se encontraba el de hacer un blog, con mi mujer, sobre lugares que visitar a lo largo del año. Me parecía un proyecto interesante, que podía servirnos para documentar unas futuras vacaciones. Y finalmente lo pusimos en marcha, pero los resultados no fueron los esperados, y todo por no hacer bien las cosas. Así, en este episodio del podcast, te voy a hablar precisamente sobre ese blog vacacional hundido por Ghost y Watchtower
Blog vacacional hundido por Ghost y Watchtower
¿Porque en Ghost?
La primera pregunta que es posible que te plantees es ¿porque en Ghost?. Como sabes, siempre he utilizado WordPress, así que probablemente este tenía que haber sido el camino. Sin embargo, no quería calentarme la cabeza, ni preocuparme mucho por el mantenimiento. En algún sitio, había leído, que Ghost, podía funcionar con sqlite3, y para este tipo de proyectos, me parece la solución ideal… Así que este fue el camino…
Los primeros problemas
Lo primero fue la instalación, que como ya te puedes imaginar iba en Docker, esto era requisito indispensable para poner este proyecto en marcha.
SQLite
Y aquí fue donde me encontré el primero de los problemas, porque parece que sqlite ya no está soportado. Anda que yo me había informado perfectamente…, menudo fenómeno estoy hecho.
Menos mal que encontré el blog de Parravidales, donde explica como continuar utilizando SQLite con Ghost 5 y Docker. Esto es mas o menos, porque mas adelante verás donde metí la pata…
El idioma
Lo siguiente era el idioma, y es que la parte de administración de Ghost está en inglés, y el tema por supuesto que también. A esta parte si que conseguí encontrar una solución para el tema, pero lo que es el backend, no hubo manera de resolverlo. Así que se quedó en inglés.
No es que esto suponga un problema, pero me llama la atención, que un CMS que se equipara con WordPress, únicamente esté disponible en inglés, muy, pero que muy llamativo.
Los accesos
El siguiente problema fue el acceso, la cuestión es que para acceder es necesario tener configurado el correo electrónico, es mas, tiene que haber confirmación por correo electrónico. Como te puedes imaginar, yo no quería configurar correo electrónico, con lo que ha sido caótico la gestión de acceso. Finalmente puse un enlace directo en la página principal para poder acceder. Algo muy raro. Supongo que con un poco mas de investigación, se puede resolver. Probablemente no le haya dedicado el tiempo que se merece.
Aún así, no me parece que esto sea la mejor experiencia de usuario que alguien puede esperar. Siempre esperas que esto sea puesta en marcha y a escribir, pero… que le vamos a hacer.
Sobre el auto guardado
Otro de los problemas con los que nos encontramos fue el auto guardado. Y es que cuando comienzas a escribir un artículo, da la impresión que se realiza el auto guardado. Sin embargo, en mas de una ocasión nos hemos encontrado con la desagradable experiencia de que esto no era así. Imagina, que estás escribiendo un artículo, o como nosotros, preparando tus vacaciones, y de repente parte se pierde… Aunque todavía es peor, como verás mas adelante.
La restricción de contenido
Como los artículos de nuestras vacaciones son únicamente para nosotros, pensé en restringir el contenido, de forma que no fuera accesible a todo el mundo. Pues no hubo manera de poder consultarlo cuando estaba restringido, lo que me obligó a quitar esta restricción.
Entiendo que esto está directamente relacionado con los accesos, pero como te digo, tampoco me iba a poner a investigar.
El docker-compose de la discordia,
El archivo docker-compose.yml, tal y como lo tenía montado tenía un aspecto como el que te muestro a continuación,
version: '3.7'
services:
ghost:
image: ghost:alpine
container_name: ghost
init: true
restart: unless-stopped
networks:
- proxy
volumes:
- ghost:/var/lig/ghost/content
environment:
url: https://${FQDN}
database__client: sqlite3
database__connection__filename: /var/lib/ghost/content/data/ghost.db
database__useNullAsDefault: "true"
database__debug: "false"
GHOST_USERNAME: belcar
GHOST_PASSWORD: euldlmdc
GHOST_EMAIL: tranbonel@gmail.com
labels:
- traefik.enable=true
- traefik.http.services.ghost.loadbalancer.server.port=2368
- traefik.http.routers.ghost-secure.entrypoints=https
- traefik.http.routers.ghost-secure.rule=Host(`${FQDN}`)
- traefik.http.routers.ghost-secure.tls=true
- traefik.http.routers.ghost-secure.tls.certresolver=myresolver
volumes:
ghost: {}
networks:
proxy:
external: trueSi te fijas en la línea de volumes hay un error, dice lig donde debería decir lib. Y esto mi grave problema.
Una de las cosas que hago habitualmente es reiniciar el servidor para comprobar que todo funciona correctamente. Yo diría que reinicié el servidor, pero al parecer, por lo que sucedió después, está claro que, no lo reinicié.
Watchtower
Por defecto tengo establecido que todos los contenedores se actualicen con Watchtower, salvo los que explicidamente indico que no.
Por ejemplo, y como he comentado en alguna que otra ocasión, uno de los que no actualizo de forma automática es precisamente el proxy inverso Traefik, sino que lo hago de forma manual. Mas ahora, que está previsto una nueva versión desde la 2.X a la 3.X. Si llevas algo de tiempo con esto de selfhosted, recordarás lo traumático que fue el cambio de la 1.X a la 2.X, así que en este caso ando con mucho cuidado. Quedarme sin proxy inverso, implica quedarme sin ninguno de los servicios que estoy utilizando.
En fin, que como era de esperar, cuando algo puede salir mal, sale mal, y así sucedió. Los desarrolladores de Ghost, lanzaron una nueva versión, y evidentemente se actualizó. Y con el error en la declaración del volumen, lo que sucedió es que todo lo que teníamos se perdió.
Imagina la situación, después del trabajo que se pegó mi mujer, después de la defensa a ultranza que había hecho yo de selfhosted, la primera en la frente.
Inicialmente yo pensé que el problema había sido que en la nueva versión habían dejado de dar soporte a SQLite definitivamente, así que las culpas cayeron sobre los desarrolladores. En ese momento, pensé las acciones que debía haber tomado,
- bloquear la actualización de Ghost por parte de Watchtower, la primera
- haber utilizado MariaDB como base de datos. Sin embargo, esto precisamente era algo que quería evitar.
La cuestión, es que como de costumbre, el problema había sido mucho mas sencillo, y de nuevo, un error humano.
De cualquier forma, y superados los problemas que he contado, esta es la forma mas sencilla de tener Ghost funcionando sin preocuparte de bases de datos externos.
Espero que te haya gustado este nuevo episodio del podcast. Si puedes, te agradecería una valoración en iVoox y/o en Apple Podcast.