Hallo allerseits und danke für eure Arbeit!
Entschuldigung, wenn dieses Thema bereits existiert, ich habe mein Bestes versucht zu suchen, konnte es aber nicht finden.
Ich habe etwas Code in einem Gitea-Repository, das ich als Teil meines n8n-Workflows ausführen möchte (selbst gehostet in einem Docker-Container). Im Moment nutze ich einen git pull Node und einen execute_command Node, um das Skript auf der Maschine auszuführen. Die Skripte beziehen sich hauptsächlich auf eine Software-API und manipulieren Dateien.
Ist das die ideale Vorgehensweise? Ich nutze auch Code Nodes für andere Dinge, aber manche Dinge muss ich wirklich in meiner IDE schreiben und debuggen…
Danke dir!
1 „Gefällt mir“
Das git pull + Execute Command-Muster, das du verwendest, ist tatsächlich ein solider Ansatz für selbstgehostete Docker-Setups – es hält deine Skripte versionskontrolliert und getrennt vom Kern von n8n. Eine Sache, die es wert ist, zu durchdenken: Wenn deine Skripte in einer bestimmten Umgebung ausgeführt werden müssen (andere Python-Version, installierte Pakete usw.), solltest du in Betracht ziehen, das Skript über einen kleinen HTTP-Wrapper oder einen separaten Container aufzurufen, anstatt es direkt im n8n-Container auszuführen. So verunreinigst du die Laufzeitumgebung von n8n nicht und deine Skripte bleiben unabhängig von deiner IDE aus testbar, ohne n8n überhaupt zu berühren.
1 „Gefällt mir“
Ja, dieses Setup kann funktionieren, aber ich würde vorsichtig sein, git pull als Teil jedes Workflow-Durchlaufs auszuführen. Ich würde das Repository wahrscheinlich separat aktualisieren und dann n8n ein festes Skriptpfad mit Execute Command ausführen lassen, wie /scripts/my-task.py.
Wenn das Skript spezielle Pakete benötigt, füge diese ins Docker-Image/Container ein, anstatt sie während des Workflow-Durchlaufs zu installieren. Das hält n8n als Orchestrator, anstatt den Workflow seine eigenen Code-Updates verwalten zu lassen.
1 „Gefällt mir“
Danke an euch beide für eure Rückmeldungen!
Ich habe zwei Anschlussfragen:
@nguyenthieutoan : Mein Python-Runner läuft in einem Sidecar-Container neben dem Container, der n8n hostet. Ist das ein guter Ort, um die Scripts auszuführen, oder würde das auch als Verschmutzung der n8n-Umgebung angesehen?
@OMGItsDerek : Welches Risiko würde es bergen, ein Repository bei jedem Workflow-Run zu pullen?
Danke nochmal, ich freue mich auf eure Gedanken!
Ja, das größte Problem bei einem git pull bei jedem Workflow-Durchlauf ist, dass die Dinge wirklich schnell unvorhersehbar werden können. Ein Durchlauf könnte leicht anderen Code ausführen als der vorherige, ohne dass du es bemerken würdest. Du kannst auch auf zufällige Fehler stoßen, wenn Git/Gitea oder das Netzwerk vorübergehend nicht verfügbar sind.
Eine andere Sache, auf die ich achten würde, ist Nebenläufigkeit. Wenn zwei Workflow-Durchläufe zur gleichen Zeit stattfinden und beide versuchen, das gleiche Repo zu ziehen/aktualisieren, können je nach Art der Dateiverwaltung merkwürdige Probleme auftreten.
Es macht auch das Debuggen schwieriger, denn wenn etwas kaputt geht, musst du jetzt fragen: „War es der Workflow selbst, oder hat sich der Code zwischen den Durchläufen geändert?‟
Deshalb würde ich Deployment normalerweise getrennt von der Ausführung halten. Ich würde n8n einfach einen festen Skriptpfad ausführen lassen und das Repo unabhängig aktualisieren. Wenn du automatische Updates möchtest, würde ich mindestens die Commit-SHA für jeden Durchlauf protokollieren und sicherstellen, dass nur ein Pull gleichzeitig stattfinden kann.
1 „Gefällt mir“
Das sind wirklich großartige Punkte, danke dafür!
Mir wurde auch eine Integration mit Github Actions empfohlen. Hat da jemand Erfahrung mit gemacht?
Anyways, ich probiere ein paar Sachen aus und gebe dir Bescheid, was wir am Ende machen.
Das Sidecar-Setup ist eigentlich ideal dafür - es ist genau die Trennung, auf die ich hingewiesen habe. Dein n8n-Container kümmert sich um die Orchestrierung, dein Python-Container kümmert sich um die Ausführung, und es gibt kein Runtime-Durcheinander zwischen den beiden. Du rufst den Sidecar via HTTP oder Execute Command auf (wenn sie sich im selben Docker-Netzwerk befinden), und beide Seiten bleiben unabhängig testbar. Für die GitHub-Actions-Integration funktioniert das auch, ist aber besser geeignet für CI/CD-Pipelines als für die bedarfsgesteuerte Skriptausführung in einem Workflow.
2 „Gefällt mir“