Dockerize robot runtime

[seth-rah]

Dockerize a prepared robot environment

Requires that you've already set up all your configuration / secrets / database files beforehand

I wanted an easy way to restart robot daily in case the session expires using cron, and running robot in a docker-daemon was my way of going about it, seemed like a waste to just keep the configuration to myself

[zephyrtronium]

I typically don't use Docker, so I'm relying on friends for feedback here, but overall I think this is a good idea. I meant to eventually include an example systemd unit file that would show another approach to something like this, but it slipped my mind – filed #84. (And, as I mentioned on #76, I still plan to make changes soon which will substantially change some parts of setup. Probably sometime this week I will be making incompatible changes to the config file structure.)

[seth-rah]

@zephyrtronium I've been thinking of adding the docker-compose.yml back, but maybe just renaming it as a docker-compose.example.yaml maybe for simplicity sake to show the file imports that would be expected

Or do you think it's better without?

[topi314]

When doing COPY . . it copies everything. For that reason I recommend you add a .dockerignore. It works the same way a .gitignore and declares what folders/files should not be copied by docker.
Stuff you can/should ignore:

• README.md
• .github/
• .gitignore
• example.toml
• COPYING

By ignoring those files/folders the cache doesn't get invalidated when they change

[zephyrtronium]

Thanks for keeping on this while I've been quiet.

I can't speak for what @zephyrtronium wants, but ideally you wouldnt need to build your own image and instead can just pull it from either dockerhub or ghcr for each commit/release.

I think if we put a Dockerfile in the repo, it probably should be for the purpose of publishing to a container registry via CI/CD. The Dockerfile now isn't trivial, but it's ultimately still just "build it the normal way, then run it the normal way;" it's probably what a relatively advanced user would write themselves if they wanted to containerize Robot. So, I don't feel a strong need to have it in the repo itself if not for eventual CI/CD; putting it e.g. in the wiki with a link from the README would be fine. That said, I don't know the costs or detriments of publishing to a container registry. (Is there a self-hosted container registry I could put on my home server for this, maybe?)

To be clear, I'm saying that I intend to look into publishing a container. I really appreciate your work here @seth-rah, and I want to do what I can to make the best possible use of it.

With that in mind, I have a few questions:

• Will this Dockerfile need substantial changes from its current form to support publishing to a container registry?
• Should Robot provide the option to take the config path from a $ROBOT_CONFIG environment variable if not passed on the command line?
• If I use this Dockerfile, how can I specify -log-format=json? Should we also provide environment variables for controlling logs? (I'd rather avoid doing that.)
• How can I use the other subcommands, like robot speak -tag=bocchi?

[seth-rah]

Thanks for keeping on this while I've been quiet.

I can't speak for what @zephyrtronium wants, but ideally you wouldnt need to build your own image and instead can just pull it from either dockerhub or ghcr for each commit/release.

I think if we put a Dockerfile in the repo, it probably should be for the purpose of publishing to a container registry via CI/CD. The Dockerfile now isn't trivial, but it's ultimately still just "build it the normal way, then run it the normal way;" it's probably what a relatively advanced user would write themselves if they wanted to containerize Robot. So, I don't feel a strong need to have it in the repo itself if not for eventual CI/CD; putting it e.g. in the wiki with a link from the README would be fine. That said, I don't know the costs or detriments of publishing to a container registry. (Is there a self-hosted container registry I could put on my home server for this, maybe?)

To be clear, I'm saying that I intend to look into publishing a container. I really appreciate your work here @seth-rah, and I want to do what I can to make the best possible use of it.

With that in mind, I have a few questions:

* Will this Dockerfile need substantial changes from its current form to support publishing to a container registry?

* Should Robot provide the option to take the config path from a $ROBOT_CONFIG environment variable if not passed on the command line?

* If I use this Dockerfile, how can I specify `-log-format=json`? Should we also provide environment variables for controlling logs? (I'd rather avoid doing that.)

* How can I use the other subcommands, like `robot speak -tag=bocchi`?

1. So in its current state this builds robot completely, although in a very barebones state that yearns for the config when it starts. The container will effectively die immediately if no config was provided.
   1.1 You'll need to mount robots config, and all the files specified in the config that are being used as a volume.
   1.1.1 The tmi_refresh is something that's generated inside of the container when it starts up and reads the config, the person starting the container would need to check the logs on first run to access the link for twitch to activate robot.
   1.2 I reckon someone would want to mount in the database as a volume along with the configs / keys so that it's not potentially lost by an accidental deletion of the container.
   1.3 Options do exist for setting up your own docker registry, and if you want to use a public one the option is available, but it's been a long time since I pushed an image to a public registry, and there were some restrictions.
2. So this was something me and @topi314 were discussing, but it does complicate the Dockerfile a bit when doing this Dockerize robot runtime #82 (comment) . The commit is still in the history that does allow feeding in the config directory when starting up Robot. 2a26094 . Topi did mention you could override the startup command and potentially feed in your own configuration file that way, but I'm not familiar with this.
3. I think this relates to docker itself and requiring you to pass an argument when starting up the container. https://docs.docker.com/engine/logging/drivers/json-file/
4. So robots docker container in runtime is effectively a linux kernel using the alpine image.
   4.1 https://docs.docker.com/reference/cli/docker/container/exec/ should allow you to feed commands to the container as you would have used in another environment.
   4.2 Alternatively you can use commands like docker exec -it robot_1 sh to gain access to the host machine to see the file structure and initiate commands from directly inside the container, like opening a new terminal on a host machine.

It's worth noting my docker knowledge is not perfect, my use cases have been quite primitive in the past and mostly just being used for hobbies and a little bit at work, so @topi314 might be able to shed light on any mistakes I might have made with my explanations.

[topi314]

I honestly recommend to just publish it to the github container repo (ghcr.io), it's integrated into github and very easy to use. There are selfhostable alternatives too.

• the Dockerfile in it's current state works perfectly fine to be published into a container registry.
  I assumed from the start that this was the intention.

• This is totally up to you, in my opinion it's not needed since file paths aren't usually an issue inside containers and you could overwrite it by overwriting the CMD

• You can set the flags as following:

services:
  robot:
    ...
    command: -config /robot.toml -log-format=json
    ...

• You can use the other subcommands like this:

services:
  robot:
    ...
    command: -config /robot.toml speak -tag=bocchi
    ...

edit: not sure how the sub commands work, do you call them at bot runtime? or startup?

[zephyrtronium]

Thanks!