Faça deploy de Discord bot na Nodion

Faça deploy de Discord bot passo a passo

1. Leia o token a partir do ambiente Nunca faça commit do token do bot. Leia-o a partir de uma variável de ambiente, aqui com discord.py; com discord.js é client.login(process.env.DISCORD_TOKEN). bot.py

   import os
   
   import discord
   
   intents = discord.Intents.default()
   client = discord.Client(intents=intents)
   
   
   @client.event
   async def on_ready():
       print(f"Logged in as {client.user}")
   
   
   client.run(os.environ["DISCORD_TOKEN"])

2. Adicione um Procfile com uma linha worker Um bot em Python precisa de um requirements.txt com discord.py. Um bot em Node.js usa worker: node bot.js, discord.js no package.json e um lockfile incluído no commit; para um bot em TypeScript com um passo de build, um Dockerfile é o caminho mais simples. Não inclua uma linha web:: o bot não tem servidor web. Procfile

   worker: python bot.py

3. Crie a aplicação e guarde o token Crie uma aplicação a partir do seu repositório GitHub, GitLab, Bitbucket ou Gitea na região EU Central. No separador Environment, adicione DISCORD_TOKEN e marque-o como secreto: depois de guardado, o valor já não pode ser lido.
4. Adicione o processo worker e desative o processo web As linhas do Procfile não criam processos por si só. No separador Processes, adicione um processo chamado worker sem porta e com o comando vazio, para que execute a entrada do Procfile com esse nome. Depois, defina web com 0 instâncias ou elimine-o: um bot nunca responde ao health check HTTP de que o web precisa.
5. Faça deploy novamente Se fez o primeiro deploy antes de adicionar o worker, faça deploy novamente. O worker conta como em execução assim que arranca, sem verificação HTTP, e os logs de runtime mostram o bot a iniciar sessão.

A ter em conta

• Uma instância nova uma vez por diaOs processos continuam em execução e não entram em suspensão. Em cada deploy e cerca de uma vez por dia, a Nodion substitui cada instância por uma nova: a nova arranca antes de a antiga receber SIGTERM. O seu bot tem de se ligar corretamente ao arrancar, e durante um breve momento as duas cópias podem estar online. Com um volume local associado, não há substituição diária, e num deploy a instância antiga termina antes de a nova arrancar.
• Mantenha uma única instânciaExecute o worker com uma única instância. Duas cópias de um bot respondem duas vezes a cada mensagem, e o Telegram só permite uma ligação de long polling por token.
• Guarde os dados fora da instânciaOs ficheiros que o bot escreve, como uma base de dados SQLite, desaparecem quando a instância é substituída. Guarde o estado em PostgreSQL ou Valkey na mesma região, ou num volume.
• Bots com webhooksOs bots que recebem webhooks, como os bots do Telegram em modo webhook ou os bots do Discord com um Interactions Endpoint URL, são aplicações web normais: são executados como web, escutam em PORT e respondem com 2xx ou 3xx no caminho do health check.

O que a Nodion gere por si

• Deploys sem downtime Faça push para o seu branch e a Nodion cria uma nova release. O tráfego só muda quando as novas instâncias passam no health check; se uma release falhar, a que está em execução mantém-se. Em vez disso, as aplicações com um volume local são reiniciadas, porque o disco pertence a uma única instância.
• Bases de dados junto à aplicação PostgreSQL, pgvector, MySQL, Valkey e ClickHouse geridos, na mesma região. As bases de dados associadas chegam como DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Pré-visualizações por pull request Ative as pré-visualizações e cada pull request do seu repositório passa a ter uma aplicação própria, com URL próprio e bases de dados novas e vazias, criada automática ou manualmente. Os forks e os pull requests de bots são ignorados.
• Workers, cron jobs e escalabilidade Execute workers como processos adicionais da mesma aplicação, agende tarefas no separador Cron e escale cada processo até 16 instâncias.
• Etapa de release Com buildpacks, uma linha release: do Procfile é executada a cada novo build. As aplicações com Dockerfile, bem como os redeploys ou rollbacks para uma imagem anterior, usam um comando de release definido na própria aplicação, que também tem prioridade sobre a linha do Procfile. Nos sites estáticos, a etapa de release é executada numa imagem que contém apenas os ficheiros gerados pelo build.
• Logs e métricas Logs de build, release e runtime, além de métricas de CPU, memória, disco e rede de cada instância, no dashboard.
• Domínios e HTTPS Um hostname atribuído por omissão com HTTPS desde o primeiro deploy; os seus próprios domínios recebem certificados automaticamente.

Discord bot na Nodion: perguntas e respostas