Bonjour à tous et merci pour votre travail !
Mes excuses si ce sujet existe déjà, j’ai fait de mon mieux pour le chercher mais je n’ai rien trouvé.
J’ai du code dans un référentiel Gitea que je voudrais exécuter dans le cadre de mon flux de travail n8n (auto-hébergé dans un conteneur docker). Pour le moment, j’utilise un nœud git pull et un nœud execute_command pour exécuter le script sur la machine. Les scripts font principalement référence à une API logicielle et manipulent des fichiers.
Est-ce la meilleure façon de procéder ? J’utilise aussi des nœuds de code pour d’autres choses, mais il y a certaines choses que je dois vraiment écrire et déboguer dans mon IDE…
Merci !
1 « J'aime »
Le modèle git pull + Execute Command que vous utilisez est en fait une excellente approche pour les configurations Docker auto-hébergées - cela maintient vos scripts sous contrôle de version et séparés du cœur de n8n. Un point à considérer : si vos scripts doivent s’exécuter dans un environnement spécifique (version Python différente, packages installés, etc.), vous pourriez envisager d’appeler le script via un petit wrapper HTTP ou un conteneur séparé plutôt que de l’exécuter directement à l’intérieur du conteneur n8n. De cette façon, vous ne polluez pas l’environnement d’exécution de n8n et vos scripts restent indépendamment testables depuis votre IDE sans toucher à n8n du tout.
1 « J'aime »
Ouais, cette configuration peut fonctionner, mais je ferais attention à faire git pull à chaque exécution du workflow. Je mettrais probablement à jour le dépôt séparément, puis je ferais exécuter par n8n un script à chemin fixe avec Execute Command, comme /scripts/my-task.py.
Si le script a besoin de packages spéciaux, mets-les dans l’image/conteneur Docker plutôt que de les installer pendant l’exécution du workflow. Ça permet à n8n de rester l’orchestrateur au lieu de laisser le workflow gérer ses propres mises à jour de code.
1 « J'aime »
Merci à vous deux pour vos contributions !
J’ai deux questions de suivi :
@nguyenthieutoan : mon exécuteur Python est configuré dans un conteneur sidecar à celui qui héberge n8n. Est-ce un bon endroit pour exécuter les scripts ou serait-ce aussi considéré comme polluant l’environnement n8n ?
@OMGItsDerek : quel serait le risque de cloner un dépôt à chaque exécution du workflow ?
Merci encore, j’ai hâte d’entendre vos réflexions !
Ouais, le plus gros problème avec un git pull à chaque exécution de workflow, c’est que ça peut devenir imprévisible très rapidement. Une exécution peut exécuter un code légèrement différent de la précédente sans que tu t’en rendes compte. Tu peux aussi rencontrer des défaillances aléatoires si Git/Gitea ou le réseau sont temporairement indisponibles.
Un autre truc auquel je ferais attention, c’est la concurrence. Si deux exécutions de workflow se produisent en même temps et essaient toutes les deux de pull/mettre à jour le même dépôt, des problèmes bizarres peuvent survenir selon la façon dont les fichiers sont utilisés.
Ça rend aussi le débogage plus difficile parce que quand quelque chose plante, tu dois maintenant te demander « était-ce le workflow lui-même, ou le code a-t-il changé entre les exécutions ? »
C’est pourquoi j’aurais généralement tendance à garder le déploiement séparé de l’exécution. Je laisserais n8n simplement exécuter un chemin de script fixe, et mettre à jour le dépôt indépendamment. Si tu veux vraiment des mises à jour automatiques, je te conseillerais au moins de journaliser le SHA du commit pour chaque exécution et de s’assurer qu’un seul pull peut se produire à la fois.
1 « J'aime »
Ce sont vraiment de très bons points, merci !
On m’a également recommandé une intégration avec Github Actions. Est-ce que quelqu’un a de l’expérience avec ça ?
De toute façon, je vais essayer quelques trucs et vous dire ce qu’on finira par faire.
La configuration sidecar est en fait idéale pour cela - c’est exactement la séparation dont je parlais. Votre conteneur n8n gère l’orchestration, votre conteneur Python gère l’exécution, et il n’y a pas de fuite d’exécution entre les deux. Vous appelez le sidecar via HTTP ou Execute Command (s’ils se trouvent sur le même réseau Docker), et chaque côté reste indépendamment testable. Pour l’intégration GitHub Actions, cela fonctionne aussi mais est mieux adapté aux pipelines CI/CD plutôt qu’à l’exécution de scripts à la demande à l’intérieur d’un workflow.
2 « J'aime »