¡Hola a todos y gracias por vuestro trabajo!
Disculpad si este tema ya existe, he hecho mi mejor esfuerzo buscando pero no lo he encontrado.
Tengo algo de código en un repositorio de Gitea que me gustaría ejecutar como parte de mi flujo de trabajo en n8n (auto-hospedado en un contenedor de docker). Ahora mismo estoy usando un nodo git pull y un nodo execute_command para ejecutar el script en la máquina. Los scripts principalmente hacen referencia a una API de software y manipulan archivos.
¿Es esta la forma ideal de hacerlo? También uso nodos de código para otras cosas, pero algunas cosas realmente necesito escribir y depurar en mi IDE…
¡Gracias!
1 me gusta
El patrón de git pull + Execute Command que estás usando es en realidad un enfoque sólido para configuraciones Docker auto-hospedadas - mantiene tus scripts versionados y separados del núcleo de n8n. Una cosa que vale la pena considerar: si tus scripts necesitan ejecutarse en un entorno específico (versión diferente de Python, paquetes instalados, etc.), podrías plantearte llamar el script a través de un pequeño envoltorio HTTP o un contenedor separado en lugar de ejecutarlo directamente dentro del contenedor de n8n. De esa manera no estarías contaminando el entorno de ejecución de n8n y tus scripts permanecerían independientemente probables desde tu IDE sin tocar n8n en absoluto.
1 me gusta
Sí, esa configuración puede funcionar, pero ten cuidado con hacer git pull como parte de cada ejecución del flujo de trabajo. Probablemente actualizarías el repositorio por separado y luego tendrías que n8n ejecute una ruta de script fija con Execute Command, como /scripts/my-task.py.
Si el script necesita paquetes especiales, ponlos en la imagen/contenedor Docker en lugar de instalarlos durante la ejecución del flujo de trabajo. Eso mantiene n8n como el orquestador en lugar de hacer que el flujo de trabajo gestione sus propias actualizaciones de código.
1 me gusta
¡Gracias a ambos por vuestras aportaciones!
Tengo dos preguntas de seguimiento:
@nguyenthieutoan : mi ejecutor de Python está configurado en un contenedor sidecar del que aloja n8n. ¿Es un buen lugar para ejecutar los scripts o también se consideraría que estoy contaminando el entorno de n8n?
@OMGItsDerek : ¿cuál sería el riesgo de extraer un repositorio como parte de cada ejecución de flujo de trabajo?
¡Gracias de nuevo, espero con interés conocer vuestras opiniones!
Sí, el mayor problema con hacer un git pull en cada ejecución de flujo de trabajo es que las cosas pueden volverse impredecibles muy rápidamente. Una ejecución podría ejecutar código ligeramente diferente que la anterior sin que te des cuenta. También puedes encontrarte con fallos aleatorios si Git/Gitea o la red no están disponibles temporalmente.
Otra cosa a la que estaría atento es la concurrencia. Si dos ejecuciones de flujo de trabajo suceden al mismo tiempo e intentan hacer pull/actualizar el mismo repositorio, pueden suceder cosas raras dependiendo de cómo se estén utilizando los archivos.
También hace que la depuración sea más difícil porque cuando algo se rompe, ahora tienes que preguntarte «¿fue el flujo de trabajo en sí, o el código cambió entre ejecuciones?»
Por eso normalmente mantendría la implementación separada de la ejecución. Dejaría que n8n simplemente ejecute una ruta de script fija e actualizaría el repositorio de forma independiente. Si realmente quieres actualizaciones automáticas, al menos registraría el SHA del commit para cada ejecución y me aseguraría de que solo pueda ocurrir un pull a la vez.
1 me gusta
¡Estos son puntos realmente excelentes, gracias!
¿También me recomendaron una integración con Github Actions. ¿Alguien tiene experiencia con eso?
De todas formas, probaré algunas cosas y te cuento qué hacemos al final.
La configuración de sidecar es en realidad ideal para esto - es exactamente la separación a la que me refería. Tu contenedor n8n maneja la orquestación, tu contenedor Python maneja la ejecución, y no hay fuga de runtime entre los dos. Llamas al sidecar a través de HTTP o Execute Command (si están en la misma red Docker), y cada lado permanece independientemente comprobable. Para la integración de GitHub Actions, eso también funciona pero es más adecuado para pipelines de CI/CD en lugar de ejecución de scripts bajo demanda dentro de un flujo de trabajo.
2 Me gusta