Docker improvements

[s0r00t]

I am managing a PeerTube instance through the docker-compose stack.
During the setup, I have found many issues plaguing the stack that made it more difficult to setup than, say, Mastodon (which I think is a good reference).

After meeting @rigelk @ PSES 2018, we've considered two major issues affecting the docker-compose PeerTube setup :

• the stack is bloated and very confusing
• the documentation is unclear

To be more precise, what I consider are issues :

• The stack should not include a reverse proxy, because in production Docker apps are ran in front of a reverse-proxy managed by the sysadmin.
• The environment variables are poorly documented and should only be managed in the .env file. (as Mastodon does with .env.production)
• The docker-compose.yml could be tracked by Git in a clearer way? The current way of setting it up (curl + making folders) makes me fear future updates.
• Not sure whether that's already the case, but the maintenance tools should be available inside the PeerTube container.
• There should be another way to get/reset the root password, other than reading the startup logs.

Thanks for considering this issue. Running PeerTube through Docker is a great way to advertise it.
I am not a Docker expert, please correct me if anything I said is mistaken or invalid.

[rigelk]

@kaiyou @djmaze @Chocobozzz @Dryusdan do you have an opinion on this?

[djmaze]

Well, I did not have a look at how this evolved for quite some time. Looking at the current state I agree there are several issues where things differ from my current compose / swarm best practices:

• Although traefik is my favorite as well, the reverse proxy should not be part of the application stack, so people can use their own ones. As far as I can see, there is no special configuration for Peertube inside the traefik configuration file. So maybe the traefik service could just be moved to a separate compose file while commenting out the traefik labels inside the main compose file. The documentation could then be split accordingly.
• I think the main reason the environment variables are explicitely referenced in the compose file, instead of using the env_file option directly, is the traefik.frontend.rule which needs to be interpolated. Maybe just use the env_file option and leave out all variables from the compose file except the one for traefik?
• Using subfolders instead of named docker volumes is probably a matter of taste. Personally, I completely switched to named volumes since a) handling file ownership & permissions inside subfolder volumes is messy b) it is easier to backup all volumes in a central place and c) using named volumes allows easily switching to a different storage backend if desired. This is particularly interesting with Docker swarm deployments.
• +1 on having a cleaner method of getting the root password. Maybe write it to a (private) directory inside the container? Alternatively, allow setting via an env variable on startup.

[s0r00t]

maybe the traefik service could just be moved to a separate compose file while commenting out the traefik labels inside the main compose file.

What do you think about KISS-ing it and just removing all references to traefik ? Or just include a sample configuration file (like what's done with nginx).

Maybe just use the env_file option and leave out all variables from the compose file except the one for traefik?

+1.

Using subfolders instead of named docker volumes is probably a matter of taste.

I don't really have an opinion on that, however, considering that other projects are not using them, maybe it would be simpler to keep using bind-mount volumes.

+1 on having a cleaner method of getting the root password. Maybe write it to a (private) directory inside the container? Alternatively, allow setting via an env variable on startup.

I think there could be a JS script to do that, and we'd just have to docker exec it to get our fresh new root password.

[rigelk]

+1 on having a cleaner method of getting the root password. Maybe write it to a (private) directory inside the container? Alternatively, allow setting via an env variable on startup.

I think there could be a JS script to do that, and we'd just have to docker exec it to get our fresh new root password.

It already exists here. Maybe we could make an alias for it though.

[djmaze]

What do you think about KISS-ing it and just removing all references to traefik ? Or just include a sample configuration file (like what's done with nginx).

The case is a bit different since we need to set labels on the peertube container. That could be provided as an docker-compose.override.yml like this:

# docker-compose.traefik.override.yml
version: 3.3

services:
  reverse_proxy:
    # ...

  peertube:
    labels:
      traefik.enable: "true"
      traefik.frontend.rule: "Host:${PEERTUBE_WEBSERVER_HOSTNAME}"
      traefik.port: "9000"

[andreaspeters]

Maybe you are interesting in using our peertube dockerimage.
https://git.aventer.biz/AVENTER/docker-peertube

There is no database inside, no systemd, no webserver. Just the peertube nodejs process in a nice alpine environment.

[kaiyou]

Since I wrote most of the provided docker-compose.yml: it was definitely not intended to be the reference Compose file but an example instead. I definitely agree that using it as download and fire stack is less than ideal.

If we are going toward a fire and forget solution for distributing a Docker configuration, I definitely agree with:

• providing an .env file;
• removing any proxy details from the config file, or provide multiple commented examples.

To be quite honnest, I wrote a very first version for the Debian production Dockerfile and keep maintaining it, but I had a look at the latest from this repository and I am horrified at the mess it has become. Maybe some cleanup is required.

[Chocobozzz]

The stack should not include a reverse proxy, because in production Docker apps are ran in front of a reverse-proxy managed by the sysadmin.

Just comment the reverse proxy section in the docker compose template. We could comment it by default and then we'll have issues by people who can't get it to work. It's difficult to satisfy everyone but I have more confidence in people who have a docker infrastructure to adapt the docker compose with their reverse proxy that the opposite.

The environment variables are poorly documented and should only be managed in the .env file. (as Mastodon does with .env.production)

They are now

The docker-compose.yml could be tracked by Git in a clearer way? The current way of setting it up (curl + making folders) makes me fear future updates.

It's just a template, so I don't think it should be tracked by git. Like the nginx template for example

Not sure whether that's already the case, but the maintenance tools should be available inside the PeerTube container.

I did not try but I think they work

There should be another way to get/reset the root password, other than reading the startup logs.

Related to #189