The Q is a Discord bot, a wildly overengineered Rust monorepo, a probably-not-necessary set of Protobuf tools, and most importantly the culmination of years of “we should have a Discord bot that _____” messages in the group chat. It doesn’t do anything particularly useful but it does do quite a few fun things, and by the gods it looks good doing ‘em.
There are several ways to run The Q. It can be used as a binary or built as a
container, and it also comes packaged with a complementary docker-compose.yml
to get log ingest and a dashboard with Grafana and Loki.
To build just the binary for the bot, run:
$ cargo build --release --bin the-qThe executable will be located at target/release/the-q and ready for action.
To build a containerized version of the bot and tag it with the-q:latest,
run:
$ docker build --target bot -t the-q/latest .(You can replace docker with podman if you so desire.)
Running the container is a little trickier than simply running the binary, but still straightforward, as described below.
Starting the services defined in docker-compose.yml will build the container
automatically, so no initial setup is required. However, if you would like to
perform the build step separately, simply run the following:
$ docker-compose buildOnce installed the bot can simply be started by running the executable or
container and providing a Discord API token. This can be done as
a command-line argument or as an environment variable (including within a .env
file). To see all available command-line flags (and their corresponding
environment variables) run the-q --help.
To load the Discord API token into the bot’s environment, create a file named
.env.local and add the following to it, replacing MY_API_KEY with your
actual API token:
DISCORD_TOKEN=MY_API_KEYIf you don't yet have an API token, check out Discord's getting started tutorial for info on how to create a bot user and add it to your servers.
If you built The Q as a standalone binary, then starting the bot is as simple
as running target/release/the-q.
NOTE: .env, .env.prod, and .env.local must be within the current
working directory when you run the executable, otherwise the bot will silently
skip loading them.
The containerized version of the bot will automatically run the binary inside
the container if the container is run with no arguments. The .env and
.env.prod files from the repository are built into the container, and loading
.env.local can be done with the --env-file flag like so:
$ docker run --env-file .env.local the-qIf you wish to pass command-line arguments to the container, you must invoke the binary directly:
$ docker run the-q bin/the-q --my-flagsTo provision the Grafana container, you will need to pass two environment
variables to docker-compose: GF_USER and GF_PASSWD. These can be passed
to docker-compose any number of ways, but as an example the repository
provides a shell script compose.sh that loads them from a file. To use the
script, create a file directly inside the repository root named
.env.compose and add the following to it:
GF_USER=admin
GF_PASSWD=adminBe sure to replace admin with a secure username and password. Then, simply
invoke the script to run docker-compose:
$ ./compose.sh up -d