Etiqueta: Docker

  • Uptime Kuma: monitorea tus servicios Docker y Home Server

    Uptime Kuma: monitorea tus servicios Docker y Home Server

    Introducción

    Cuando administramos un Home Server, no basta con instalar aplicaciones y comprobar que funcionan correctamente. También necesitamos saber si nuestros servicios continúan disponibles, si responden correctamente y cuándo ocurre algún problema.

    Imaginemos que tenemos varios servicios funcionando en nuestro servidor: Jellyfin, Nextcloud, WordPress, Home Assistant o incluso una página web alojada en Internet.

    ¿Qué sucede si alguno deja de funcionar mientras no estamos en casa? ¿Cómo podemos saber si nuestro sitio web está disponible o si un contenedor Docker se ha detenido inesperadamente?

    Para solucionar este problema existe Uptime Kuma, una herramienta de monitorización de código abierto que nos permite supervisar servicios, servidores, páginas web y diferentes dispositivos desde un único panel de control.

    En este artículo veremos qué es Uptime Kuma, cuáles son sus funcionalidades, cómo instalarlo utilizando Docker Compose y cómo configurarlo para monitorear los servicios de nuestro Home Server.

    1. ¿Qué es Uptime Kuma?

    Uptime Kuma es una herramienta de monitorización autohospedada (self-hosted), diseñada para comprobar la disponibilidad de servicios y dispositivos de red.

    Su principal característica es ofrecer un panel de control desde el cual podemos visualizar el estado de nuestros servicios, consultar tiempos de respuesta, identificar interrupciones y recibir notificaciones cuando algo deja de funcionar.

    A diferencia de algunas plataformas comerciales de monitorización, Uptime Kuma puede instalarse directamente en nuestro propio servidor, por lo que mantenemos el control sobre su configuración y los datos de monitorización.

    Su interfaz gráfica permite administrar los monitores sin necesidad de escribir comandos constantemente.

    2. ¿Para qué sirve Uptime Kuma?

    Uptime Kuma permite supervisar prácticamente cualquier servicio que podamos comprobar mediante una conexión de red o un mecanismo compatible.

    Algunos ejemplos de uso son:

    • Comprobar si una página web está disponible.
    • Verificar que un servidor responde a solicitudes HTTP o HTTPS.
    • Supervisar puertos TCP de aplicaciones y servidores.
    • Comprobar la conectividad de dispositivos mediante Ping.
    • Monitorear contenedores Docker.
    • Verificar registros DNS.
    • Supervisar certificados SSL y sus fechas de expiración.
    • Recibir notificaciones cuando un servicio deja de responder.
    • Publicar páginas de estado para mostrar la disponibilidad de nuestros servicios.

    Por ejemplo, podemos configurar un monitor para comprobar que nuestro sitio web responde correctamente cada cierto intervalo.

    Si el sitio deja de responder, Uptime Kuma registra el incidente y puede enviarnos una notificación.

    De esta manera podemos identificar problemas sin tener que comprobar manualmente cada aplicación.

    3. Principales funcionalidades

    Monitorización HTTP y HTTPS

    Permite comprobar la disponibilidad de páginas web y aplicaciones accesibles mediante HTTP o HTTPS.

    Podemos configurar la URL que queremos supervisar y establecer los códigos de respuesta HTTP que consideramos válidos.

    También permite comprobar certificados SSL para identificar cuándo se aproxima su fecha de expiración.

    Monitorización TCP

    Permite comprobar si un puerto específico de un servidor está aceptando conexiones.

    Por ejemplo, podemos supervisar:

    • Puerto 22: SSH.
    • Puerto 80: HTTP.
    • Puerto 443: HTTPS.
    • Puerto 3001: Uptime Kuma.

    Esta funcionalidad es útil para comprobar que determinados servicios continúan escuchando en sus puertos correspondientes.

    Monitorización mediante Ping

    Permite comprobar si un dispositivo responde a solicitudes ICMP.

    Podemos utilizarlo para supervisar:

    • Routers.
    • Switches.
    • Servidores.
    • Computadoras.
    • Impresoras de red.
    • Otros dispositivos conectados a nuestra infraestructura.

    Es importante recordar que un dispositivo puede bloquear ICMP y seguir funcionando correctamente. Por eso, un resultado negativo de Ping no siempre significa que el dispositivo esté completamente fuera de servicio.

    Monitorización de contenedores Docker

    Una de las funcionalidades más interesantes para quienes utilizamos Docker es la posibilidad de supervisar directamente nuestros contenedores.

    Uptime Kuma puede conectarse al motor Docker y comprobar el estado de los contenedores seleccionados.

    Esto permite visualizar si un contenedor está ejecutándose o si ha dejado de estar disponible.

    Para utilizar esta funcionalidad necesitamos proporcionar acceso al socket de Docker, algo que veremos durante la instalación.

    Sistema de notificaciones

    Uptime Kuma permite configurar diferentes mecanismos para recibir alertas cuando ocurre algún incidente.

    Entre las integraciones disponibles encontramos:

    • Telegram.
    • Discord.
    • Slack.
    • Gotify.
    • Correo electrónico mediante SMTP.
    • Pushover.
    • Otros servicios compatibles.

    Esto permite recibir notificaciones sin necesidad de mantener abierto el panel de monitorización.

    Páginas públicas de estado

    Otra funcionalidad interesante es la posibilidad de crear páginas de estado.

    Estas páginas permiten mostrar la disponibilidad de determinados servicios sin necesidad de proporcionar acceso al panel administrativo.

    Podemos utilizarlas para informar a otras personas si nuestros servicios están funcionando correctamente o si existe alguna interrupción.

    4. Requisitos previos

    Para instalar Uptime Kuma utilizando Docker necesitamos:

    • Un servidor Linux con Docker Engine.
    • Docker Compose.
    • Acceso administrativo al servidor.
    • Conexión a Internet para descargar la imagen.
    • Espacio de almacenamiento para conservar la configuración y el historial de monitorización.

    En este tutorial utilizaremos Ubuntu Server y Docker Compose.

    5. Instalación de Uptime Kuma con Docker Compose

    La instalación mediante Docker Compose permite mantener la configuración organizada y facilita las tareas de mantenimiento.

    Paso 1. Crear el directorio de instalación

    Nos conectamos al servidor mediante SSH y creamos el directorio donde almacenaremos los archivos de configuración:

    mkdir -p ~/docker/uptime-kuma
    cd ~/docker/uptime-kuma

    Paso 2. Crear el archivo Docker Compose

    Creamos el archivo:

    nano docker-compose.yml

    Agregamos la siguiente configuración:

    services:
      uptime-kuma:
        image: louislam/uptime-kuma:2
        container_name: uptime-kuma
        restart: always
    
        ports:
          - "3001:3001"
    
        volumes:
          - ./data:/app/data
          - /var/run/docker.sock:/var/run/docker.sock

    Explicación de los parámetros:

    image: especifica la imagen Docker que utilizaremos. En este caso, la rama principal de Uptime Kuma 2.

    container_name: establece el nombre del contenedor.

    restart: permite que el contenedor vuelva a iniciarse automáticamente cuando sea necesario.

    ports: publica el puerto 3001 del contenedor en el servidor.

    ./data:/app/data: conserva la información de Uptime Kuma fuera del ciclo de vida del contenedor.

    /var/run/docker.sock: permite que Uptime Kuma se comunique con el motor Docker para supervisar contenedores.

    Paso 3. Iniciar el servicio

    Ejecutamos:

    docker compose up -d

    Comprobamos que el contenedor se encuentre funcionando:

    docker ps --filter name=uptime-kuma

    También podemos consultar su estado de salud:

    docker inspect uptime-kuma \
      --format '{{.State.Status}} | {{if .State.Health}}{{.State.Health.Status}}{{else}}sin healthcheck{{end}}'

    Paso 4. Acceder a la interfaz web

    Abrimos nuestro navegador y utilizamos la siguiente dirección:

    http://IP-DE-TU-SERVIDOR:3001

    Por ejemplo:

    http://192.168.8.10:3001

    En el primer inicio tendremos que completar el asistente de configuración y crear nuestra cuenta administrativa.

    Una vez finalizado este proceso, tendremos acceso al panel principal de Uptime Kuma.

    Nota: si queremos publicar Uptime Kuma mediante un proxy inverso o Cloudflare Tunnel, debemos configurar correctamente el acceso y proteger el panel administrativo. No es recomendable exponerlo directamente a Internet.

    6. Cómo configurar nuestro primer monitor

    Una vez dentro de Uptime Kuma, podemos comenzar a supervisar nuestros servicios.

    Para crear un monitor:

    1. Seleccionamos la opción para agregar un nuevo monitor.
    2. Elegimos el tipo de monitorización.
    3. Asignamos un nombre descriptivo.
    4. Introducimos la dirección IP, dominio o URL correspondiente.
    5. Configuramos el intervalo de comprobación.
    6. Guardamos los cambios.

    Por ejemplo, podemos crear un monitor HTTP(s) para comprobar nuestro sitio web:

    ParámetroEjemplo
    TipoHTTP(s)
    NombreSitio web
    URLhttps://dotbugs.com
    Intervalo60 segundos
    ReintentosSegún necesidad

    Una vez guardado, Uptime Kuma comenzará a realizar comprobaciones periódicas.

    El panel mostrará el estado actual, el tiempo de respuesta y el historial de disponibilidad.

    También podemos crear monitores TCP para comprobar puertos específicos y monitores Ping para verificar la conectividad de nuestros dispositivos.

    7. Cómo supervisar contenedores Docker

    Si utilizamos Docker para administrar nuestras aplicaciones, podemos aprovechar la integración de Uptime Kuma con Docker.

    Primero debemos asegurarnos de que el contenedor tenga acceso al socket:

    /var/run/docker.sock

    En nuestra instalación ya tenemos configurado este volumen en Docker Compose.

    Después, desde Uptime Kuma:

    1. Entramos en Settings.
    2. Buscamos la configuración de Docker Hosts.
    3. Agregamos un nuevo Docker Host.
    4. Seleccionamos la conexión mediante socket local.
    5. Indicamos la ruta del socket Docker.
    6. Guardamos la configuración.

    Una vez establecida la conexión, podemos crear un nuevo monitor de tipo Docker Container y seleccionar el contenedor que queremos supervisar.

    Por ejemplo, podemos monitorear:

    • Jellyfin.
    • Nextcloud.
    • WordPress.
    • Home Assistant.
    • Watchtower.

    Esto nos permite centralizar la supervisión de nuestros servicios Docker desde una sola interfaz.

    Consideración de seguridad: montar el socket Docker proporciona un acceso muy elevado al servidor. Aunque se monte como un volumen de solo lectura, eso no convierte automáticamente la API de Docker en una API de solo lectura. Debemos proteger el acceso administrativo a Uptime Kuma y evitar exponerlo públicamente sin controles adicionales.

    8. Configurar notificaciones

    Una de las ventajas de Uptime Kuma es que no necesitamos estar revisando constantemente el panel para detectar problemas.

    Podemos configurar notificaciones para recibir alertas cuando un monitor cambia de estado.

    Para hacerlo:

    1. Entramos en Settings.
    2. Seleccionamos Notifications.
    3. Agregamos un nuevo mecanismo de notificación.
    4. Introducimos los parámetros necesarios.
    5. Ejecutamos una prueba de conexión.
    6. Guardamos la configuración.

    Por ejemplo, podemos integrar Telegram para recibir mensajes cuando un servicio deja de responder y cuando vuelve a estar disponible.

    También podemos asociar una misma configuración de notificaciones a varios monitores.

    Esto resulta especialmente útil cuando tenemos numerosos servicios funcionando en nuestro Home Server.

    9. Consultar registros y diagnosticar problemas

    Como Uptime Kuma funciona dentro de Docker, podemos consultar sus registros directamente desde la terminal.

    Para visualizar los últimos registros:

    docker logs --tail 100 uptime-kuma

    Para observarlos en tiempo real:

    docker logs -f uptime-kuma

    También podemos comprobar el estado del contenedor:

    docker inspect uptime-kuma \
      --format '{{.State.Status}}'

    Si necesitamos reiniciar el servicio:

    cd ~/docker/uptime-kuma
    docker compose restart

    Y para comprobar que el puerto responde localmente:

    curl -I http://127.0.0.1:3001

    Estos comandos son útiles para identificar problemas de inicio, conectividad o funcionamiento del contenedor.

    10. Respaldos y buenas prácticas

    Uptime Kuma almacena su información en el directorio /app/data, que en nuestra instalación está vinculado a un directorio persistente del servidor.

    Aquí se conserva información importante como:

    • Configuración de la aplicación.
    • Monitores creados.
    • Historial de monitorización.
    • Datos de la base de datos.
    • Configuración de notificaciones.

    Por este motivo, debemos realizar respaldos periódicos del directorio de datos.

    Algunas recomendaciones:

    Realizar respaldos consistentes.

    Antes de copiar los archivos de datos, es recomendable detener temporalmente el contenedor o utilizar un procedimiento de respaldo consistente con la base de datos. No debemos asumir que copiar únicamente el archivo SQLite mientras la aplicación está escribiendo garantiza una copia válida.

    Proteger la cuenta administrativa.

    Utilizar una contraseña segura y habilitar la autenticación de dos factores cuando esté disponible.

    No exponer el socket Docker.

    El socket proporciona un acceso privilegiado al motor Docker. Debemos limitar quién puede acceder a Uptime Kuma.

    Configurar intervalos razonables.

    No todos los servicios necesitan comprobarse con la misma frecuencia. Podemos adaptar los intervalos según la importancia de cada aplicación.

    Utilizar notificaciones.

    Un sistema de monitorización es mucho más útil cuando recibimos alertas oportunamente.

    Supervisar desde una ubicación independiente.

    Si Uptime Kuma y los servicios monitorizados se encuentran en el mismo servidor, una caída completa del servidor también puede dejar sin funcionamiento al sistema de monitorización. Para una supervisión más completa, podemos instalar una segunda instancia en otro equipo o servidor.

    11. Conclusión

    Uptime Kuma es una excelente alternativa para quienes queremos tener mayor visibilidad sobre los servicios que administramos en nuestro Home Server.

    Su interfaz sencilla, las diferentes opciones de monitorización, la integración con Docker y el sistema de notificaciones permiten identificar problemas de disponibilidad sin depender de comprobaciones manuales.

    Además, al ser una herramienta autohospedada, podemos ejecutarla en nuestra propia infraestructura y mantener el control sobre los datos.

    Si administramos varios servicios Docker, contar con una herramienta como Uptime Kuma facilita considerablemente las tareas de supervisión y mantenimiento.

    Un Home Server no solamente necesita funcionar; también necesitamos saber cuándo deja de hacerlo.

    Referencias y documentación

  • Watchtower: cómo actualizar automáticamente tus contenedores Docker en un Home Server

    Watchtower: cómo actualizar automáticamente tus contenedores Docker en un Home Server

    Introducción

    Cuando administramos un Home Server con Docker, una de las tareas que debemos realizar periódicamente es mantener actualizados nuestros contenedores.

    Servicios como Jellyfin, Nextcloud, Home Assistant, Uptime Kuma o WordPress reciben actualizaciones que incorporan nuevas funcionalidades, correcciones de errores y mejoras de seguridad.

    Sin embargo, actualizar cada contenedor manualmente puede convertirse en una tarea repetitiva, especialmente cuando tenemos varios servicios funcionando en nuestro servidor.

    Aquí es donde entra Watchtower, una herramienta que permite automatizar la detección de nuevas versiones de imágenes Docker y actualizar los contenedores cuando existen versiones disponibles.

    En este artículo veremos qué es Watchtower, cómo funciona, cómo instalarlo utilizando Docker Compose y cómo configurarlo para realizar actualizaciones programadas.

    1. ¿Qué es Watchtower?

    Watchtower es una herramienta de código abierto diseñada para supervisar y actualizar automáticamente contenedores Docker.

    Su funcionamiento consiste en comprobar periódicamente si existen nuevas versiones de las imágenes utilizadas por nuestros contenedores.

    Cuando detecta una actualización, puede realizar automáticamente las siguientes operaciones:

    1. Detectar que existe una nueva versión de la imagen Docker.
    2. Descargar la nueva imagen desde el repositorio correspondiente.
    3. Detener el contenedor que utiliza la versión anterior.
    4. Crear nuevamente el contenedor utilizando la imagen actualizada.
    5. Conservar la configuración original del contenedor, incluyendo variables de entorno, puertos, redes y volúmenes configurados.

    De esta manera, no necesitamos conectarnos constantemente al servidor para comprobar y actualizar manualmente cada servicio.

    Importante: Watchtower no actualiza el sistema operativo ni los paquetes de Ubuntu. Su función se limita a administrar las actualizaciones de las imágenes de los contenedores Docker.

    2. ¿Para qué sirve Watchtower?

    Su principal objetivo es simplificar el mantenimiento de un entorno Docker.

    Imaginemos que tenemos cinco servicios instalados en nuestro Home Server:

    • Jellyfin para administrar nuestra biblioteca multimedia.
    • Uptime Kuma para supervisar la disponibilidad de los servicios.
    • Home Assistant para automatización del hogar.
    • Calibre-Web para administrar libros electrónicos.
    • WordPress para alojar nuestro sitio web.

    Sin una herramienta de automatización, tendríamos que comprobar periódicamente si existen nuevas imágenes y actualizar los contenedores manualmente.

    Con Watchtower podemos automatizar este proceso y establecer un horario para realizar las comprobaciones.

    Esto resulta especialmente útil cuando administramos varios servicios y queremos reducir las tareas de mantenimiento.

    3. Principales funcionalidades

    Actualizaciones automáticas

    Comprueba si existen nuevas versiones de las imágenes Docker y puede actualizar los contenedores automáticamente.

    Actualizaciones programadas

    Permite definir intervalos de comprobación o utilizar expresiones cron para establecer días y horarios específicos.

    Exclusión de contenedores

    Permite evitar que determinados servicios sean actualizados automáticamente mediante etiquetas de Docker.

    Limpieza de imágenes antiguas

    Con la opción Cleanup puede eliminar las imágenes anteriores después de completar una actualización, ayudando a evitar la acumulación de imágenes que ya no se utilizan.

    Notificaciones

    Permite configurar notificaciones para conocer cuándo se detectan o realizan actualizaciones, utilizando los mecanismos de notificación compatibles.

    4. Requisitos previos

    Antes de instalar Watchtower necesitamos:

    • Un servidor Linux, Windows o cualquier sistema compatible con Docker.
    • Docker Engine instalado y funcionando.
    • Docker Compose.
    • Acceso administrativo al servidor.
    • Conexión a Internet para descargar las imágenes.

    También es recomendable tener configurado un sistema de respaldos para los servicios y sus bases de datos.

    5. Instalación de Watchtower con Docker Compose

    Watchtower funciona como un contenedor Docker independiente y necesita comunicarse con el motor Docker del servidor.

    Para ello utiliza el socket:

    /var/run/docker.sock

    Este socket permite que Watchtower consulte y administre los contenedores del servidor.

    Nota sobre el proyecto: el repositorio original containrrr/watchtower fue archivado el 17 de diciembre de 2025. Para una instalación nueva, este tutorial utiliza la continuación comunitaria nickfedor/watchtower. Es importante comprobar el estado y la procedencia de las imágenes antes de instalarlas.

    Paso 1. Crear el directorio

    Nos conectamos al servidor mediante SSH y creamos el directorio donde almacenaremos la configuración:

    mkdir -p ~/docker/watchtower
    cd ~/docker/watchtower

    Paso 2. Crear el archivo Docker Compose

    Creamos el archivo de configuración:

    nano docker-compose.yml

    Agregamos el siguiente contenido:

    services:
      watchtower:
        image: nickfedor/watchtower:latest
        container_name: watchtower
        restart: unless-stopped
    
        environment:
          TZ: America/Mexico_City
          WATCHTOWER_SCHEDULE: "0 0 4 * * *"
          WATCHTOWER_CLEANUP: "true"
    
        volumes:
          - /var/run/docker.sock:/var/run/docker.sock

    Guardamos los cambios.

    Paso 3. Iniciar Watchtower

    Ejecutamos:

    docker compose up -d

    Comprobamos que el contenedor esté funcionando:

    docker ps --filter name=watchtower

    Si aparece con estado Up, el contenedor se encuentra en ejecución.

    6. Configurar actualizaciones programadas

    Una de las características más útiles de Watchtower es la posibilidad de establecer un horario específico para comprobar actualizaciones.

    En nuestro ejemplo utilizamos:

    WATCHTOWER_SCHEDULE: "0 0 4 * * *"

    Esta expresión indica que Watchtower realizará sus comprobaciones todos los días a las 04:00:00 horas.

    Es importante tener en cuenta que Watchtower utiliza una expresión cron de seis campos:

    CampoValorSignificado
    Segundos0Segundo cero
    Minutos0Minuto cero
    Horas4Cuatro de la mañana
    Día del mes*Todos los días
    Mes*Todos los meses
    Día de la semana*Todos los días de la semana

    También configuramos:

    TZ: America/Mexico_City

    Esto permite que el horario programado y los registros utilicen la zona horaria de Ciudad de México.

    7. Cómo excluir contenedores de las actualizaciones

    No siempre es recomendable actualizar automáticamente todos los servicios.

    Por ejemplo, podemos tener una aplicación que funciona correctamente y preferimos actualizar manualmente después de revisar las notas de cada versión.

    Watchtower permite excluir contenedores utilizando etiquetas de Docker.

    Para excluir un servicio, agregamos la siguiente etiqueta en su archivo Docker Compose:

    labels:
      - "com.centurylinklabs.watchtower.enable=false"

    Por ejemplo:

    services:
      wordpress:
        image: wordpress:php8.3-apache
        container_name: wordpress-web
    
        labels:
          - "com.centurylinklabs.watchtower.enable=false"

    Con esta configuración, Watchtower omitirá ese contenedor durante sus actualizaciones automáticas.

    Esta funcionalidad es especialmente útil para servicios importantes, bases de datos y aplicaciones que requieren una validación previa antes de actualizarse.

    8. Cómo comprobar los registros de Watchtower

    Podemos consultar los registros del contenedor para comprobar si está funcionando correctamente:

    docker logs watchtower

    Para visualizar los registros en tiempo real:

    docker logs -f watchtower

    También podemos comprobar cuándo se realizó la última ejecución y si se encontraron imágenes nuevas.

    Si queremos salir de la visualización en tiempo real, presionamos Ctrl + C. Esto no detiene el contenedor.

    9. Buenas prácticas y recomendaciones

    Aunque Watchtower facilita el mantenimiento de Docker, es importante considerar algunos aspectos antes de habilitar actualizaciones automáticas.

    Realizar respaldos periódicos.

    Antes de actualizar servicios importantes, debemos contar con respaldos de sus configuraciones y bases de datos.

    No actualizar todo sin supervisión.

    Las nuevas versiones pueden introducir cambios incompatibles. Es recomendable excluir los servicios críticos o utilizar un proceso de actualización manual para ellos.

    Evitar depender exclusivamente de la etiqueta latest.

    Es conveniente revisar qué versiones y etiquetas utilizan nuestros contenedores, especialmente cuando necesitamos mantener una versión específica.

    Proteger el acceso al socket de Docker.

    El acceso a /var/run/docker.sock proporciona un nivel de control muy elevado sobre Docker y, en la práctica, puede equivaler a privilegios administrativos sobre el servidor. No debemos exponerlo a redes o usuarios no confiables.

    Revisar los registros después de las actualizaciones.

    Una actualización exitosa no garantiza que la aplicación funcione correctamente. Debemos comprobar que los servicios continúen operativos.

    No confundir actualización con respaldo.

    Watchtower no crea copias de seguridad ni garantiza que podamos regresar automáticamente a una versión anterior.

    10. Conclusión

    Watchtower es una herramienta interesante para quienes administramos un Home Server con múltiples servicios Docker.

    Su capacidad para detectar nuevas imágenes, programar actualizaciones y excluir determinados contenedores permite simplificar considerablemente las tareas de mantenimiento.

    Sin embargo, la automatización debe utilizarse con precaución. No todos los servicios deberían actualizarse sin supervisión, especialmente aquellos que almacenan información importante.

    La mejor estrategia es combinar Watchtower con respaldos periódicos, supervisión de los contenedores y actualizaciones controladas para los servicios críticos.

    Así podemos mantener nuestro Home Server actualizado sin perder el control sobre los servicios que tenemos funcionando.

    Documentación de Watchtower

    Repositorio GitHub de la continuación comunitaria

    Repositorio original y aviso de archivado

    Configuración de parámetros y programación

  • Cómo instalar WordPress con Docker y Cloudflare Tunnel en un homeserver Ubuntu

    Cómo instalar WordPress con Docker y Cloudflare Tunnel en un homeserver Ubuntu

    Introducción

    Tener un sitio web propio no necesariamente requiere contratar un servicio de hosting tradicional. Si disponemos de un servidor en casa, una conexión a Internet y algunos conocimientos de Linux, podemos alojar WordPress utilizando Docker y publicar el sitio mediante Cloudflare Tunnel.

    En este artículo documentamos una implementación real de WordPress sobre Ubuntu Server, utilizando contenedores Docker para ejecutar WordPress y MariaDB, y Cloudflare Tunnel para permitir el acceso público mediante HTTPS sin tener que exponer directamente los puertos del servidor a Internet.

    El objetivo no es solamente mostrar cómo poner WordPress en funcionamiento, sino explicar la arquitectura, las decisiones técnicas, las medidas de seguridad y las comprobaciones necesarias para mantener el servicio.

    La implementación descrita corresponde a un entorno de homelab. No debe interpretarse como una arquitectura de alta disponibilidad ni como sustituto de una estrategia completa de recuperación ante desastres.

    1. Arquitectura de la solución

    La implementación utiliza tres servicios principales:

    • WordPress: aplicación web ejecutada sobre Apache y PHP.
    • MariaDB: motor de base de datos que almacena el contenido y la configuración de WordPress.
    • Cloudflare Tunnel: establece la conexión entre el servidor y la infraestructura de Cloudflare para publicar el sitio.

    Los servicios se ejecutan en contenedores Docker y comparten una red interna.

    Flujo de conexión

                     INTERNET
                         |
                         |
                  
    Inicio
    | | CLOUDFLARE | | CLOUDFLARE TUNNEL | | Docker: wordpress_net | +-------+-------+ | | | | wordpress-web wordpress-db | | Apache MariaDB | | +-------+-------+ | Volúmenes Docker

    Una característica importante de esta arquitectura es que WordPress no necesita publicar su puerto directamente en Internet. El contenedor de Cloudflare Tunnel se comunica con WordPress a través de la red interna de Docker.

    Componentes utilizados

    ComponenteImplementación
    Sistema operativoUbuntu Server 26.04 LTS
    ContenedoresDocker Engine
    OrquestaciónDocker Compose
    CMSWordPress
    Servidor webApache
    PHP8.3
    Base de datosMariaDB 11.4
    Publicación externaCloudflare Tunnel
    Red Dockerwordpress_net

    2. Preparación del entorno

    Antes de desplegar WordPress es necesario contar con un servidor Ubuntu actualizado y Docker Engine con Docker Compose.

    Podemos verificar las versiones instaladas con:

    docker --version
    docker compose version

    También conviene comprobar que Docker esté funcionando:

    sudo systemctl status docker --no-pager

    Para esta implementación se utiliza el usuario habitual del servidor, con permisos para administrar Docker.

    Es recomendable trabajar con un directorio dedicado para mantener organizados los archivos de configuración:

    mkdir -p ~/docker/wordpress
    cd ~/docker/wordpress

    La estructura de trabajo utilizada es:

    /home/dotbugs/docker/wordpress/
    ├── .env
    ├── docker-compose.yml
    └── php-security.ini

    El archivo .env contiene variables de entorno y credenciales. No debe publicarse, compartirse ni incluirse en repositorios públicos.

    3. Organización de los servicios Docker

    La implementación utiliza tres contenedores:

    ContenedorImagen
    wordpress-webwordpress.3-apache
    wordpress-dbmariadb:11.4
    wordpress-cloudflaredcloudflare/cloudflared

    La base de datos no publica ningún puerto en el servidor. WordPress accede a MariaDB mediante el nombre del servicio dentro de la red Docker.

    WordPress, por su parte, publica su puerto HTTP únicamente en la interfaz local:

    ports:
      - "127.0.0.1:8088:80"

    Esto significa que el servicio puede consultarse desde el propio servidor mediante 127.0.0.1:8088, pero no queda directamente expuesto en la interfaz de red pública o LAN del servidor mediante ese mapeo.

    El contenedor de Cloudflare Tunnel utiliza la red Docker para alcanzar WordPress mediante:

    http://wordpress-web:80

    Variables y credenciales

    Las credenciales de MariaDB y WordPress se administran mediante variables de entorno almacenadas en .env.

    Un ejemplo de las variables que deben gestionarse es:

    MARIADB_DATABASE=wordpress
    MARIADB_USER=wordpress_user
    MARIADB_PASSWORD=CAMBIAR_POR_UNA_CLAVE_SEGURA
    MARIADB_ROOT_PASSWORD=CAMBIAR_POR_OTRA_CLAVE_SEGURA

    Los valores son ilustrativos. Deben utilizarse contraseñas largas, únicas y aleatorias.

    El token de Cloudflare Tunnel también debe mantenerse fuera del archivo público de configuración y nunca compartirse en capturas, registros o repositorios.

    4. Persistencia de datos: un aspecto fundamental

    Los contenedores son reemplazables. Los datos importantes deben mantenerse fuera de la capa temporal del contenedor.

    En esta implementación se utilizan dos volúmenes Docker:

    VolumenDestino dentro del contenedor
    wordpress_wordpress_files/var/www/html
    wordpress_wordpress_db/var/lib/mysql

    El primero conserva los archivos de WordPress, incluyendo temas, plugins, archivos multimedia y configuración.

    El segundo conserva los datos de MariaDB.

    Podemos revisar los volúmenes existentes con:

    docker volume ls

    Y consultar dónde están montados:

    docker inspect wordpress-web \
      --format '{{range .Mounts}}{{println .Type .Name .Destination}}{{end}}'
    
    docker inspect wordpress-db \
      --format '{{range .Mounts}}{{println .Type .Name .Destination}}{{end}}'

    En esta arquitectura también se utiliza un archivo de configuración PHP montado como solo lectura.

    Es importante recordar que los volúmenes permiten conservar los datos al recrear contenedores, pero no sustituyen una copia de seguridad.

    Precaución: no utilizar docker compose down -v sin comprender sus consecuencias. La opción -v puede eliminar los volúmenes asociados y, con ellos, los datos persistentes.

    5. Publicación mediante Cloudflare Tunnel

    Uno de los objetivos de esta implementación fue evitar la apertura directa de puertos entrantes en el router.

    Cloudflare Tunnel permite que el servidor establezca conexiones salientes hacia la infraestructura de Cloudflare. De esta manera, el servicio puede publicarse sin configurar un reenvío tradicional de los puertos 80 y 443 hacia el servidor doméstico.

    En la configuración utilizada, el hostname público es:

    dotbugs.com

    El destino interno del túnel es:

    http://wordpress-web:80

    El tráfico sigue este recorrido:

    1. El visitante accede a https://dotbugs.com.
    2. Cloudflare recibe la solicitud.
    3. Cloudflare Tunnel transporta la solicitud hasta el servidor.
    4. El contenedor de Cloudflare Tunnel se comunica con WordPress por la red Docker.
    5. WordPress procesa la solicitud y devuelve la respuesta.

    ¿Por qué se utiliza HTTP entre los contenedores?

    En esta implementación, la comunicación entre Cloudflare Tunnel y WordPress utiliza HTTP dentro de la red privada de Docker.

    La conexión pública del visitante utiliza HTTPS. Esto no significa que debamos configurar HTTP público sin protección: la terminación HTTPS y la comunicación interna son tramos diferentes de la arquitectura.

    Si se utiliza este modelo, es importante proteger el acceso al servidor y controlar quién puede acceder a la red Docker.

    6. Configuración adicional de seguridad PHP

    Durante la revisión de la instalación se identificó una medida preventiva relacionada con el mecanismo de seguimiento del progreso de cargas de archivos de PHP.

    Para aplicarla se utiliza un archivo personalizado:

    ; Mitigación preventiva temporal del aviso de seguridad de PHP
    session.upload_progress.enabled = 0

    El archivo se encuentra en:

    /home/dotbugs/docker/wordpress/php-security.ini

    Y se monta en el contenedor como:

    /usr/local/etc/php/conf.d/zz-security.ini

    El montaje se realiza en modo de solo lectura.

    Comprobar que PHP aplica la configuración

    No basta con escribir una directiva en un archivo. Es importante verificar el valor efectivo dentro del contenedor:

    docker exec wordpress-web php -r '
    echo "session.upload_progress.enabled=";
    var_export(ini_get("session.upload_progress.enabled"));
    echo PHP_EOL;
    '

    En nuestra instalación, el resultado fue:

    session.upload_progress.enabled='0'

    También podemos comprobar la versión de PHP:

    docker exec wordpress-web php -v

    Esta medida es una mitigación específica. No sustituye las actualizaciones de PHP, WordPress, los plugins ni las demás medidas de seguridad.

    7. Verificación del funcionamiento

    Una vez desplegados los servicios, es necesario comprobar que todos estén funcionando.

    Estado de los contenedores

    cd ~/docker/wordpress
    docker compose ps

    En nuestra implementación, los tres contenedores se encontraban en ejecución.

    MariaDB cuenta además con una comprobación de salud propia.

    Podemos consultar su estado mediante:

    docker inspect wordpress-db \
      --format '{{.State.Status}} | Salud: {{.State.Health.Status}}'

    Resultado esperado:

    running | Salud: healthy

    Es importante señalar que WordPress y Cloudflare Tunnel no tienen un healthcheck de Docker configurado en esta implementación. Por lo tanto, que aparezcan como Up no garantiza por sí solo que la aplicación web sea accesible.

    Comprobar WordPress localmente

    Como el puerto está publicado únicamente en localhost, podemos realizar la prueba desde el propio servidor:

    curl -sS -o /dev/null \
      --max-time 15 \
      -w "HTTP %{http_code} | Tiempo %{time_total}s\n" \
      http://127.0.0.1:8088/

    Comprobar el acceso público

    curl -sS -o /dev/null \
      --max-time 20 \
      -w "HTTP %{http_code} | Tiempo %{time_total}s\n" \
      https://dotbugs.com/

    En las comprobaciones realizadas el 3 de noviembre de 2026 obtuvimos:

    PruebaResultado
    WordPress localHTTP 200
    Acceso público HTTPSHTTP 200
    MariaDBHealthy
    Tiempo de respuesta localAproximadamente 0.07 segundos
    Tiempo de respuesta públicoAproximadamente 0.31 segundos

    Estos resultados corresponden a las pruebas realizadas en ese momento; no representan una garantía de disponibilidad permanente.

    8. Diagnóstico y monitorización semanal

    Además de comprobar manualmente los servicios, implementamos un script de diagnóstico semanal.

    El script se encuentra en:

    /home/dotbugs/scripts/wordpress-weekly-check.sh

    Su función es revisar distintos aspectos de la instalación:

    • Disponibilidad del sitio público.
    • Respuesta local de WordPress.
    • Estado de los contenedores.
    • Salud de MariaDB.
    • Actualizaciones disponibles de WordPress, plugins y temas.
    • Diferencias entre los digest locales y remotos de las imágenes Docker.
    • Existencia y antigüedad de los respaldos.
    • Integridad del archivo comprimido.
    • Presencia de contenido SQL esperado.

    Un segundo script ejecuta el diagnóstico y genera un informe con fecha y hora:

    /home/dotbugs/scripts/run-wordpress-weekly-check.sh

    Los informes se almacenan en:

    /home/dotbugs/reports/wordpress/

    El directorio y los informes individuales utilizan permisos restrictivos para proteger su contenido.

    Programación mediante cron

    La tarea se ejecuta los lunes a las 09:00, hora de Ciudad de México.

    La entrada configurada es:

    0 15 * * 1 /home/feram/scripts/run-wordpress-weekly-check.sh >> /home/feram/reports/wordpress/cron.log 2>&1

    El horario corresponde a las 15:00 UTC.

    Podemos consultar la programación con:

    crontab -l

    Y revisar los informes generados con:

    ls -lah /home/dotbugs/reports/wordpress/

    Importante: este mecanismo es un diagnóstico programado, no un servicio de monitorización continua. Tampoco actualiza automáticamente WordPress ni las imágenes Docker.

    9. Copias de seguridad: qué tenemos y qué falta

    Una instalación con volúmenes persistentes sigue necesitando copias de seguridad independientes.

    En nuestro servidor se identificaron respaldos completos que contienen:

    • Una exportación SQL de la base de datos.
    • Un archivo comprimido con los archivos de WordPress.

    El directorio utilizado es:

    /home/dotbugs/backups/wordpress/

    Los nombres de los archivos son:

    wordpress-database.sql
    wordpress-files.tar.gz

    El diagnóstico semanal verifica que ambos archivos existan, que no estén vacíos, que el archivo comprimido pueda validarse y que la antigüedad de la copia no supere el límite configurado de ocho días.

    Sin embargo, hay una distinción importante: la implementación documentada cuenta con copias de seguridad existentes y comprobaciones automáticas, pero no tiene confirmada una tarea periódica que genere nuevas copias automáticamente.

    Tampoco se ha documentado una restauración completa probada.

    Por ello, antes de considerar el entorno protegido ante cualquier incidente, todavía es necesario implementar y probar:

    1. Generación periódica de copias SQL y de archivos.
    2. Una política de retención y rotación.
    3. Una segunda ubicación de almacenamiento independiente del servidor.
    4. Un procedimiento de restauración probado.

    Un respaldo que nunca se ha restaurado sigue siendo una copia cuya capacidad de recuperación no hemos demostrado.

    10. Consideraciones de seguridad y mantenimiento

    Al alojar un sitio web desde un servidor doméstico, debemos tener presentes algunos aspectos:

    • Mantener Ubuntu, Docker, WordPress, PHP y MariaDB actualizados.
    • Revisar los plugins y temas instalados y retirar los que no se utilicen.
    • Utilizar contraseñas únicas y robustas.
    • Proteger el archivo .env y el token de Cloudflare Tunnel.
    • Evitar publicar directamente el puerto de MariaDB.
    • Limitar la exposición de los servicios que no necesitan acceso externo.
    • Realizar copias de seguridad independientes.
    • Probar periódicamente los procedimientos de recuperación.
    • Revisar los informes de diagnóstico y las advertencias de actualización.
    • Evitar actualizar imágenes de producción sin revisar los cambios y contar con un respaldo reciente.

    También conviene recordar que utilizar etiquetas como latest facilita el despliegue, pero no fija una versión inmutable. Antes de actualizar es recomendable revisar la imagen disponible, realizar una copia de seguridad y validar el funcionamiento posterior.

    11. Conclusiones

    Alojar WordPress en un homeserver utilizando Docker y Cloudflare Tunnel es una alternativa viable para quienes desean administrar su propia infraestructura y aprender sobre contenedores, redes y servicios web.

    En esta implementación conseguimos:

    • Ejecutar WordPress y MariaDB en contenedores independientes.
    • Mantener los datos mediante volúmenes Docker.
    • Evitar publicar directamente el puerto de WordPress en la interfaz de red del servidor.
    • Publicar el sitio mediante Cloudflare Tunnel.
    • Aplicar una configuración PHP personalizada.
    • Comprobar la disponibilidad local y pública.
    • Automatizar diagnósticos semanales y generar informes.

    La experiencia también demuestra que desplegar un servicio es solamente una parte del trabajo. Mantenerlo actualizado, verificar su disponibilidad y contar con una estrategia de respaldos y recuperación son responsabilidades igual de importantes.

    La ventaja de un homelab es que permite construir, experimentar y documentar una infraestructura real. La clave está en conocer sus límites y no confundir que un servicio esté funcionando con que esté completamente protegido.


    Nota técnica: este artículo describe una implementación real en Ubuntu Server 26.04 LTS, Docker y Cloudflare Tunnel, revisada el 3 de noviembre de 2026. Las rutas, nombres de contenedores y resultados corresponden a ese entorno y pueden necesitar ajustes en otras instalaciones.