I have 2 months of furlough, and I'd like to improve my Python (and other) skills and, for once, start and finish a project. For once I've decided to pick a project which will actually both interest and benefit myself.<p>I wrote a simple chat bot to manage xp/levels/roles, amongst various other things, in a Discord server for a popular community. I've since used the same bot in other communities, but it just runs as a clone of a Python repo for each bot, using supervisord on a Digital Ocean VPS. Each bot also has its own developer 'app' within the Discord environment and associated tokens, which is getting cumbersome to manage.<p>As I've got time to focus on it, I'd like to create a singular bot, with a web UI to manage it, with a very long term end goal of maybe competing with other services like Mee6, but a shorter term goal of making it easy for me to easily add the bot to new communities and configure it - without config + manual steps over SSH.<p>It's quite niche, but if anyone has any similar experience, I'd be eager to hear any opinions. For example: My first instinct based upon my work experience was a Docker container per bot, but from testing, as far as I can see I need a single instance which handles all servers if I want to use one developer 'app' like Mee6 or Dyno.<p>Any hints/links or similar welcome.
Docker alone would not add automatic scalability. You'd need to add an orchestration layer.<p>Seems like your current bot would be fine in multiple servers if you added an additional server argument to each of the i/o's.<p>Don't overthink it.
You can certainly run more than one Discord server on a single running instance of the bot. That's probably more code, but you could run the web server as part of the same process. I would generally discourage that though, because then you can have your bots DDoSed by just DDoSing your web server.<p>The easier incarnation is to store the Discord connection configs in a database. Make a web server and UI to manage the database (the Django admin panel is probably enough, which would make it low code). Then have the web server manage an orchestration layer by pulling configs from the database. The easy solution is probably to have your web server write out supervisord config files templated from the data in the database, and then send reload signals to supervisord. The more difficult option there would be to write your own process management layer (probably not worth it, you're just rewriting supervisord at that point). Or you could maybe just pull in supervisord as a library and use it.<p>That solution is less resource efficient, but not at a "break the bank" level.
I have a discord bot running in our FortressOne discord. It keeps track of who is in what server and spams the channel with that information. It requires some short term persistence so it runs across two containers, one with the application code and the other with redis. It takes hundreds of requests daily and sends many millions, seems to be very stable. <a href="https://github.com/FortressOne/qwtf-discord-bot" rel="nofollow">https://github.com/FortressOne/qwtf-discord-bot</a>
Why did you clone in the beginning? Why couldn't you have just on developer app send requests from multiple communities to one endpoint for your app?