Dockhand v1.0.55 programa contenedores por horario

Cuando un contenedor no necesita vivir las 24 horas

En un homelab es habitual mantener servicios encendidos por costumbre, aunque solo se utilicen durante unas horas. Un servidor multimedia, un entorno de desarrollo o una aplicación interna no siempre necesitan estar disponibles de madrugada. Tener esa decisión automatizada evita depender de acordarse de apagar y encender cosas manualmente.

Dockhand v1.0.55 incorpora arranque y parada programados para contenedores individuales. La programación se puede configurar desde su interfaz, pero la parte más interesante para mí está en poder declararla mediante etiquetas de Docker Compose. Así, el horario deja de ser un ajuste perdido en una interfaz y pasa a formar parte del repositorio.

La política queda junto al servicio

Las etiquetas nuevas son dockhand.start.at y dockhand.stop.at. Ambas aceptan una hora diaria con formato HH:MM o una expresión cron de cinco campos. El cron usa el orden habitual: minuto, hora, día del mes, mes y día de la semana.

Este ejemplo define un entorno Laravel disponible de lunes a viernes durante la jornada de trabajo. No es una receta para todos los proyectos, pero muestra bien dónde encaja esta función: el ciclo de vida del contenedor se expresa junto a su configuración. Al redeplegar el stack, la política sigue estando ahí.

services:
  laravel:
    build: .
    labels:
      - "dockhand.start.at=0 8 * * 1-5"
      - "dockhand.stop.at=0 20 * * 1-5"

Una hora como 23:30 equivale a ejecutar la acción todos los días a esa hora. Para horarios semanales o casos menos repetitivos, cron da bastante más margen sin necesitar scripts externos. En este caso, 0 8 * * 1-5 inicia el contenedor a las 08:00 de lunes a viernes y 0 20 * * 1-5 lo detiene a las 20:00.

Un uso razonable para Laravel y el homelab

Yo lo veo especialmente útil para entornos Laravel locales o de pruebas que levantamos desde un servidor doméstico. Si el proyecto tiene su propio contenedor de aplicación, worker de cola o servicio de desarrollo, puedo decidir cuáles deben seguir el horario y cuáles no. La base de datos, por ejemplo, merece una decisión separada si la comparten otros proyectos.

También encaja con servicios de homelab que generan ruido, consumen recursos o simplemente no necesito fuera de horario. No sustituye una estrategia de ahorro energético para todo el host, pero sí permite recortar actividad de forma selectiva. Y, al vivir en compose.yaml, cualquiera que despliegue el stack puede entender qué servicios están pensados para funcionar y cuándo.

La letra pequeña importa

Las etiquetas tienen prioridad sobre cualquier horario configurado desde el editor de contenedores de Dockhand. Cuando un contenedor lleva una de estas etiquetas, la programación se muestra como solo lectura en la interfaz y hay que cambiar el Compose para modificarla. Si se elimina la etiqueta después, el horario configurado previamente desde la interfaz no reaparece.

Los horarios se interpretan con la zona horaria configurada para el entorno de Dockhand, no con una zona definida dentro de cada contenedor. Además, Dockhand revisa las etiquetas periódicamente, por lo que un horario declarado tras un despliegue puede tardar hasta cinco minutos en aparecer en la página de programaciones. Conviene revisar esa zona horaria antes de confiar una parada nocturna a una expresión cron.

No convierte Docker Compose en un orquestador

Esto arranca y detiene contenedores; no resuelve dependencias de aplicación, migraciones, colas pendientes ni apagados consistentes de una arquitectura compleja. Si paro un worker de Laravel mientras procesa una tarea, la responsabilidad de que el worker cierre bien sigue siendo de la aplicación y de su configuración. Para bases de datos o servicios con datos sensibles, conviene validar primero cómo reaccionan a una parada normal del contenedor.

También hay comportamientos que no deben sorprender: iniciar un contenedor que ya está en marcha o detener uno que ya está parado se registra como una acción omitida. Un contenedor pausado cuenta como activo para la parada, pero un arranque programado no lo reanuda. Las etiquetas tampoco están disponibles para los propios contenedores de Dockhand y Hawser.

Para servicios aislados, laboratorios de desarrollo y aplicaciones con horarios claros, la novedad evita mantener pequeños scripts de cron repartidos por el host. Para una plataforma crítica, no la tomaría como sustituto de una planificación operativa completa. La ventaja real está en hacer explícita una política sencilla y conservarla versionada junto al stack.

• Fuente: Dockhand
• Documentación oficial: Manual de Dockhand