Docker Improvements

[jamesmeneghello]

I have some time coming up over the holidays and quite a lot of experience in Docker / Kubernetes. Is there any interest in improving Docker support in the project? There are quite a few things that could be improved:

• Environment variable handling (while it's undergone some changes lately) could be streamlined a lot
• Using multi-stage builds to combine development/production containers and slim down the prod container further (incl. the changes made today)
• Improving the compose file for development (allowing development to occur directly in the containers)
• Providing k8s manifests for deployments

I'd be more than happy to take this on and maintain it into the future, but any feedback or suggestions or pain points would be great as to project direction! :)

[Chocobozzz]

Hi,

I would suggest that you create your own repository that we can link in the documentation website (for unofficial k8s support).

Regarding the dev docker file, I wanted to delete it since I don't have time to maintain the workflow. And since we now have gitpod that works, I don't think it's really interesting to keep it.

[dirkkelly]

@Chocobozzz Just wanted to chime in here, the reason I've been in the docs lately is because I'm trying to get started so that I can provide development support.

I've given Gitpod a go and it was great for getting a feel for the project. However I'm really looking for a way to develop without relying on a third party private hosted service, especially as I am often working on an Australian internet connection.

Additionally I'm trying to get a manageable and scalable production instance together and would prefer to have this running on k8s rather than bespoke built and maintained servers.

Is it possible we could consider keeping docker support in the this repository if we were able to show consistent support and maintenance for it?

[Nutomic]

Regarding the dev docker file, I wanted to delete it since I don't have time to maintain the workflow.

@Chocobozzz I dont think there is anything wrong with having other contributors maintain the Docker configuration.

[Chocobozzz]

Is it possible we could consider keeping docker support in the this repository if we were able to show consistent support and maintenance for it?

Yep, no pb

I dont think there is anything wrong with having other contributors maintain the Docker configuration.

Sure

[kimsible]

I explore PeerTube code and I wonder why a docker build based on debian buster is not proposed for the master branch ?

I mean, if I'm not wrong the HLS support is only avalaible on ffmpeg >= 4.1 , so on debian buster.

The master branch has a debian stretch build with ffmpeg 3.

I saw you worked on this PR : #2324

Is there any features / bugs which prevent from merging it on master (from a feature branch) ?

[Chocobozzz]

The master branch is up to date with the latest release, so it will be updated when we'll release PeerTube 2.1 (stable)

[kimsible]

Thanks @Chocobozzz, I created a docker build with buster and the latest release on master branch https://hub.docker.com/layers/kimsible/peertube/latest-buster/images/sha256-e0fec694171bb2b072cf96809d622c2df3b456448ad3621f1efe3c1102e9a8e8

But I'm not sure HLS works correctly, is it fully implemented with the actual latest realease (2.0) ?

Otherwise, where do you need help to improve that part (docker) ?

[Nutomic]

@kimsible You should try the Docker image from develop branch:

https://github.com/Chocobozzz/PeerTube/blob/develop/support/docker/production/Dockerfile.buster

[kimsible]

Thanks @Nutomic but that one is not suitable for production. I tested it and there are some bugs / issues.
The one I created is based on this Dockerfile but built with the latest stable version on master : https://github.com/kimsible/docker-peertube/blob/master/Dockerfile.latest-buster

[onlyjob]

I would like to see Docker/compose replaced with Buildah. Buildah can produce Docker compatible image in userspace without root privileges. Also Docker is drifting to obsolescence so we should be preparing to replace it with (superior) Podman.

[kimsible]

Hi, I proposed some improvements for the documentation and the /support/docker/production/.env example file : #2494

[kimsible]

According to the changes proposed in #2494, we could put traefik config ./docker-volume/config as traefik.toml is provided by the docker image.

Also I wonder if linking acme.json to traefik docker volume is really usefull in any case ?

That way, no ./docker-volume/traefik directory and ./docker-volume/traefik/acme.json would be to create before configuring .env.

@Chocobozzz do you see some cons to proceed that way ?

[Chocobozzz]

I prefer to keep things like they are if it's just cosmetic and that does not hurt. Docker support is already taking too much of my time.

[kimsible]

Docker support is already taking too much of my time.

Maybe, docker-compose.yml and .env production files shouldn't be provided by the repo.
The documentation could bring some exemples and details the environnment variables.