Déployez Discord bot sur Nodion

Déployez Discord bot étape par étape

1. Lisez le token depuis l'environnement Ne commitez jamais le token du bot. Lisez-le depuis une variable d'environnement, ici avec discord.py ; avec discord.js, c'est 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. Ajoutez un Procfile avec une ligne worker Un bot Python a besoin d'un requirements.txt avec discord.py. Un bot Node.js utilise worker: node bot.js, discord.js dans package.json et un lockfile committé ; pour un bot TypeScript avec une étape de build, un Dockerfile est la voie la plus simple. N'ajoutez pas de ligne web: : le bot n'a pas de serveur web. Procfile

   worker: python bot.py

3. Créez l'app et enregistrez le token Créez une application depuis votre dépôt GitHub, GitLab, Bitbucket ou Gitea dans la région EU Central. Dans l'onglet Environment, ajoutez DISCORD_TOKEN et marquez-le comme secret : une fois enregistrée, la valeur ne peut plus être relue.
4. Ajoutez le processus worker et désactivez web Les lignes du Procfile ne créent pas de processus d'elles-mêmes. Dans l'onglet Processes, ajoutez un processus nommé worker sans port et avec une commande vide : il exécute alors l'entrée du Procfile qui porte ce nom. Passez ensuite web à 0 instance ou supprimez-le : un bot ne répond jamais au health check HTTP dont web a besoin.
5. Redéployez Si le premier déploiement a eu lieu avant que vous ajoutiez le worker, redéployez. Le worker est considéré comme en cours d'exécution dès son démarrage, sans contrôle HTTP, et les logs d'exécution montrent le bot qui se connecte.

Bon à savoir

• Une nouvelle instance une fois par jourLes processus tournent en continu et ne se mettent pas en veille. À chaque déploiement et environ une fois par jour, Nodion remplace chaque instance par une nouvelle : la nouvelle démarre avant que l'ancienne reçoive SIGTERM. Votre bot doit se connecter proprement au démarrage, et pendant un court instant les deux copies peuvent être en ligne. Avec un volume local rattaché, il n'y a pas de remplacement quotidien, et lors d'un déploiement l'ancienne instance s'arrête avant que la nouvelle démarre.
• Gardez une seule instanceFaites tourner le worker avec une seule instance. Deux copies d'un bot répondent deux fois à chaque message, et Telegram n'autorise qu'une connexion en long polling par token.
• Stockez les données hors de l'instanceLes fichiers écrits par le bot, comme une base de données SQLite, disparaissent au prochain remplacement de l'instance. Gardez l'état dans PostgreSQL ou Valkey dans la même région, ou sur un volume.
• Bots avec webhooksLes bots qui reçoivent des webhooks, comme les bots Telegram en mode webhook ou les bots Discord avec une Interactions Endpoint URL, sont des apps web normales : ils tournent comme web, écoutent sur PORT et répondent avec un 2xx ou un 3xx sur le chemin du health check.

Ce que Nodion gère pour vous

• Déploiements sans interruption Faites un push sur votre branche : Nodion construit une nouvelle release. Le trafic bascule lorsque les nouvelles instances réussissent leur health check ; si la release échoue, celle en cours reste active. Les apps avec un volume local redémarrent, car le disque appartient à une seule instance.
• Bases de données à côté de l'app PostgreSQL, pgvector, MySQL, Valkey et ClickHouse managés, dans la même région. Les bases de données rattachées arrivent sous forme de DATABASE_URL, REDIS_URL ou CLICKHOUSE_URL.
• Previews par pull request Activez les previews, et les pull requests de votre dépôt obtiennent leur propre app, avec sa propre URL et des bases de données neuves et vides, créées automatiquement ou à la main. Les pull requests issues de forks ou de bots sont ignorées.
• Workers, cron jobs et mise à l'échelle Exécutez les workers comme processus supplémentaires de la même app, planifiez des tâches dans l'onglet Cron et mettez chaque processus à l'échelle jusqu'à 16 instances.
• Étape de release Avec les buildpacks, une ligne release: du Procfile s'exécute à chaque nouveau build. Les apps Dockerfile, ainsi que les redéploiements ou les rollbacks vers une image antérieure, utilisent une commande de release définie sur l'app elle-même, qui prime aussi sur la ligne du Procfile. Sur les sites statiques, l'étape de release s'exécute dans une image qui ne contient que les fichiers générés par le build.
• Logs et métriques Logs de build, de release et d'exécution, ainsi que les métriques CPU, mémoire, disque et réseau de chaque instance, dans le dashboard.
• Domaines et HTTPS Un nom d'hôte par défaut avec HTTPS dès le premier déploiement, et des certificats automatiques pour vos propres domaines.

Discord bot sur Nodion : questions et réponses