Olá a todos e obrigado pelo trabalho de vocês!
Peço desculpas se este tópico já existe, fiz o meu melhor para pesquisar mas não consegui encontrá-lo.
Tenho alguns códigos em um repositório Gitea que gostaria de executar como parte do meu fluxo de trabalho n8n (auto-hospedado em um contêiner Docker). No momento estou usando um nó git pull e um nó execute_command para executar o script na máquina. Os scripts fazem principalmente referência a uma API de software e manipulam arquivos.
Esta é a forma ideal de fazer isso? Também uso nós de código para outras coisas, mas algumas coisas eu realmente preciso escrever e depurar no meu IDE…
Obrigado!
1 curtida
O padrão git pull + Execute Command que você está usando é na verdade uma abordagem sólida para configurações Docker self-hosted - mantém seus scripts versionados e separados do núcleo do n8n. Uma coisa que vale a pena pensar: se seus scripts precisarem ser executados em um ambiente específico (versão diferente do Python, pacotes instalados, etc.), você pode querer considerar chamar o script através de um pequeno wrapper HTTP ou um container separado em vez de executá-lo diretamente dentro do container do n8n. Dessa forma você não está poluindo o ambiente de runtime do n8n e seus scripts permanecem independentemente testáveis a partir da sua IDE sem tocar no n8n.
1 curtida
Sim, essa configuração pode funcionar, mas eu teria cuidado ao fazer git pull como parte de cada execução do workflow. Eu provavelmente atualizaria o repositório separadamente e depois deixaria o n8n executar um caminho de script fixo com Execute Command, como /scripts/my-task.py.
Se o script precisar de pacotes especiais, coloque-os na imagem/container do Docker em vez de instalá-los durante a execução do workflow. Isso mantém o n8n como o orquestrador em vez de fazer o workflow gerenciar suas próprias atualizações de código.
1 curtida
Obrigado a vocês dois pela contribuição!
Tenho duas perguntas de acompanhamento:
@nguyenthieutoan : meu executor Python está configurado em um contêiner sidecar junto ao que hospeda o n8n. É um bom lugar para executar os scripts ou isso também seria considerado como poluição do ambiente n8n?
@OMGItsDerek : qual seria o risco de fazer pull de um repositório como parte de cada execução de workflow?
Obrigado novamente, fico no aguardo de suas considerações!
Sim, o maior problema em fazer um git pull a cada execução de workflow é que as coisas podem ficar imprevisíveis muito rapidamente. Uma execução pode executar um código um pouco diferente da anterior sem você perceber. Você também pode se deparar com falhas aleatórias se Git/Gitea ou a rede estiverem temporariamente indisponíveis.
Outra coisa que eu teria cuidado é com concorrência. Se duas execuções de workflow acontecerem ao mesmo tempo e ambas tentarem fazer pull/atualizar o mesmo repositório, podem acontecer problemas estranhos dependendo de como os arquivos estão sendo usados.
Também dificulta a depuração porque quando algo quebra, você agora tem que perguntar “foi o workflow em si, ou o código mudou entre as execuções?”
Por isso eu normalmente manteria a implantação separada da execução. Eu deixaria o n8n apenas executar um caminho de script fixo e atualizar o repositório independentemente. Se você realmente quer atualizações automáticas, eu pelo menos registraria o SHA do commit para cada execução e garantiria que apenas um pull possa acontecer por vez.
1 curtida
Esses são pontos muito bons mesmo, obrigado!
Também me recomendaram uma integração com Github Actions. Alguém tem experiência com isso?
De qualquer forma, vou testar algumas coisas e depois aviso o que decidimos fazer.
A configuração de sidecar é na verdade ideal para isso - é exatamente a separação a que eu estava me referindo. Seu container n8n cuida da orquestração, seu container Python cuida da execução, e não há vazamento de runtime entre os dois. Você chama o sidecar via HTTP ou Execute Command (se estiverem na mesma rede Docker), e cada lado permanece independentemente testável. Para integração com GitHub Actions, isso funciona também, mas é mais adequado para pipelines CI/CD do que para execução de scripts sob demanda dentro de um workflow.
2 curtidas