Kestra frente a cron: flujos, logs y reintentos
Guía técnica para pasar tareas sueltas de cron a flujos con Kestra: YAML, entradas, tareas, logs, reintentos, permisos y costo inicial antes de producción.
Un flujo YAML guarda orden, condición, entrada y salida para que una tarea deje rastro. Kestra 1.3.37, publicado el 2 de septiembre, vuelve útil una pregunta vieja en pymes: qué pasa cuando un script nocturno falla y nadie sabe si reintentar, borrar un archivo o esperar otro proceso. Esta guía muestra cómo migrar una automatización chica local sin perder control.
Qué problema resuelve un flujo
La página oficial de flows presenta el flujo como el elemento central de Kestra. Tiene identificador, namespace, tareas, entradas, disparadores y configuración. Esa estructura ordena algo que en muchas empresas aparece como una línea de cron, un script Bash y un mail enviado por costumbre. El trabajo puede funcionar durante meses, hasta que una credencial vence o un proveedor cambia el nombre de un archivo. El job nocturno necesita recibo. La encuesta 2025 de Stack Overflow muestra Bash/Shell con 48,7% de uso entre quienes respondieron. No mide automatizaciones argentinas ni calidad de operación. Sirve para explicar una realidad reconocible: muchas rutinas de negocio empiezan como comandos simples y terminan decidiendo facturación, stock, cobranzas o reportes. Kestra entra cuando ese comando necesita entradas declaradas, logs, reintentos y lectura por más de una persona. El antagonista concreto es el cron sin registro compartido. En una pyme de logística, un script baja pedidos a las 02:00, otro arma etiquetas a las 02:15 y otro envía un CSV a administración. Si el primero falla, los otros dos pueden trabajar con datos viejos. Si alguien reintenta a mano, quizá pisa un archivo correcto. La herramienta no cambia el negocio; convierte cada paso en una ejecución visible, con estado, duración, salida y error. La versión reciente importa menos por una función aislada que por disciplina de actualización. Un orquestador se vuelve parte de la operación: debe tener base, almacenamiento, permisos, backups y monitoreo. Cuando esa base queda escrita, el debate cambia de "me parece que corrió" a "esta ejecución falló por este mensaje y este reintento usó esta entrada".
Cómo funciona por dentro
El flujo mínimo separa seis componentes. Primero, el namespace ordena los flujos por área o cliente. Segundo, las entradas reciben fecha, archivo, cliente o entorno. Tercero, las tareas ejecutan comandos, llamadas HTTP, consultas SQL o transformaciones. Cuarto, los disparadores inician el flujo por horario, evento o solicitud manual. Quinto, los logs guardan salida y errores por ejecución. Sexto, los reintentos definen qué tarea puede repetirse y qué falla debe cortar el proceso. La documentación de tasks explica que cada tarea representa una unidad ejecutable dentro de un flujo. Eso ayuda a partir el problema: descargar archivo, validar columnas, cargar base, enviar aviso y archivar evidencia. Una tarea puede fallar sin esconder el resto del proceso. El tablero de ejecuciones permite ver estado, duración y mensajes, de modo que administración puede pedir una reejecución con una causa escrita en lugar de pedir acceso al servidor. La configuración de Kestra cubre runtime, almacenamiento, observabilidad, seguridad y plugins. Para una instalación real, esos puntos pesan más que el YAML inicial. El Docker Compose documentado en la guía de Docker puede trabajar con PostgreSQL; en ese esquema, la base guarda metadatos de operación y el servidor mantiene ejecuciones y configuración. Los archivos de negocio pueden ir a S3, MinIO o un volumen respaldado, según el alcance. Si PostgreSQL falla, se pierde estado operativo. Si el almacenamiento falla, quedan ejecuciones sin archivo. Si el secreto queda en texto plano, cualquier usuario con acceso al servidor puede usarlo fuera del flujo. Si no hay límite de concurrencia, dos ejecuciones pueden tocar el mismo archivo. La arquitectura mínima debe dejar claro dónde vive cada pieza.
Qué se instala o configura primero
En un proyecto UMSA, el primer entregable sería migrar una rutina real de tres pasos: tomar un CSV de ventas, validar columnas y cargar una tabla de staging. El piloto define namespace, entrada de fecha, tarea de descarga, tarea de validación, tarea de carga, reintentos, alerta por fallo y evidencia archivada. Recién después conviene sumar flujos paralelos. La pila inicial puede usar Kestra, PostgreSQL, almacenamiento S3 o MinIO, proxy con TLS, backup diario, SMTP para avisos y monitoreo básico. Servidor, respaldo y monitoreo pueden ubicarse entre USD 35 y USD 80 mensuales, entre $53.550 y $122.400 al dólar oficial vendedor de $1530. La implementación inicial, con un flujo, secretos, logs, reintentos, tablero y restauración probada, puede ir de USD 900 a USD 1.800, entre $1.377.000 y $2.754.000. Ese rango deja afuera limpieza profunda de datos, rediseño de procesos y conectores pagos. El primer corte verificable es breve: se fuerza un fallo, aparece el error, se reintenta una sola tarea y el archivo procesado queda archivado con fecha y hash.
Dónde se rompe y cómo probarlo
El primer riesgo es migrar comandos sin definir contrato de entrada. El síntoma aparece cuando un flujo recibe un archivo con columnas cambiadas y sigue hasta cargar basura. La prueba toma un CSV incompleto, exige fallo temprano y guarda mensaje legible para la persona qué carga datos. El segundo riesgo está en reintentos ciegos. El síntoma aparece cuando una tarea falla por datos inválidos y el sistema insiste hasta llenar logs. La prueba separa errores transitorios, como timeout HTTP, de errores funcionales, como columna faltante. Sólo los primeros reciben reintento automático. El tercer riesgo es el secreto visible. El síntoma aparece cuando una credencial de proveedor queda en YAML o en un log. La prueba revisa configuración, ejecuta el flujo con salida redactada y bloquea impresión de variables sensibles. El cuarto riesgo es no probar restauración. La prueba levanta otra instancia, restaura PostgreSQL y almacenamiento, y abre la ejecución fallida con sus logs y archivos. La automatización cumple cuando un error deja una ruta de reparación, no una conversación de madrugada.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.