If you are running Discord bots through docker, but you are not using https://portainer.io to either create or manage your stacks and containers, you should start now!
For the Brackeys Community Discord we’ve been transferring from using a singular bot to do everything, to multiple bots with a single purpose, this prevents our Discord application to hit rate limits when bot usage is high and makes it easier to manage parts of our bot set up, without having to touch unrelated bots.
Along with this change we’ve started using Docker to separate the bots from the host system, and now we’re deploying these bots completely using Portainer.
Portainer lets us deploy bots, while only having the volumes for the container on the host server.
By creating a new stack we can add a new bot right from it’s Github repository and only having a built image and it’s volumes exist on the host itself. This also allows us to set it up in such a way, that with every push to the repository, the image is rebuild with the changes on Github.
Using portainer, other staff members get access to the docker actions, for just these bots. No SSH required.
By either creating a user, or a team of users, you get tighter control over who gets access to what container on your host server. Keeping some to only administrators? Sure, some to only a team? No problem, accessible by everyone with a user? If that’s what you need, it’s possible.
By giving more staff members access to the containers of the bots, they can try and debug what is going wrong if the person hosting the bots, isn’t available. Meaning that if there is downtime, it has the potential of being much shorter.
Portainer only has to grab the docker-compose configuration from the correct branch, docker-compose does the rest.
We have set it up in such a way that the branch that Portainer looks at for the docker-compose configuration file, is a branch with only this configuration file. And through the configuration in docker-compose, the image is built based on the correct branch:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
version: '3.9'
services:
cloak:
container_name: Cloak
build: https://github.com/BrackeysBot/Cloak.git#main
volumes:
- type: bind
source: /var/log/brackeysbot/cloak
target: /app/logs
- type: bind
source: /etc/brackeysbot/cloak
target: /app/data
restart: always
environment:
- DISCORD_TOKEN=${DISCORD_TOKEN}
As you can see the build step looks at the Github repository, and more specifically the main branch, the rest is handled for us.
Easily pass environment variables.
By using Portainer to deploy our stack we no longer have struggle with .env files, or passing them in the correct command. All we need to do, is pass the environment variables to the stack, and they’ll be automatically fed to the docker-compose config, based on it’s name. However, if needed, we could also pass a .env file to the stack in Portainer.
In conclusion, Portainer increases the speed and simplifies the process in which we can deploy new bots, handles updating them for us. And gives us greater control over what is and what isn’t happening.
Get started with Portainer now and simplify your deployment!
Update 2023-03-03:
If your repository is private, you will have to authenticate yourself for access. Using a separate docker branch set up might not work in this case, as docker would not be authenticated for Github to grab the files to build the image from. Simply using the branch all the files are on together with authentication through Portainer will work fine in that case.