How to install PeerTube using Docker

PeerTube is one of the social-networking systems that forms part of the so-called Fediverse. Whereas Mastodon is a micro-blogging system much like Twitter, and diaspora* is similar to Facebook, PeerTube is a video-sharing system similar to YouTube. The critical differences about all of these systems compared to their better-known commercial counterparts are that (1) they are decentralized, so that no one person or organization controls them; and (2) they are federated, so they all intercommunicate. This second point is somewhat like the FidoNet or ProLine BBSs of old, with the important difference that the communication happens in real time.

This guide is based on @mrmarkuz’ guide on installing PeerTube (How to install PeerTube on Nethserver), but using Docker instead to avoid messing with dependencies for anything else that might be on your Neth system. It largely follows the PeerTube docs, but with a few adaptations.

Preliminary

Your PeerTube instance will be in its own virtual host, so you’ll need to decide on a name for it. Once you’ve given it a name, it will be very difficult to change later, so put some thought into choosing a name you’ll likely be happy with for some time. Make whatever DNS entries are needed, and make sure you have a TLS certificate covering that name (either by generating a new cert for just that name, or by adding that name to your existing default cert).

Install nethserver-docker and docker-compose

yum install nethserver-docker
curl -L "https://github.com/docker/compose/releases/download/1.28.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
chmod +x /usr/local/bin/docker-compose

Install PeerTube

mkdir -p /opt/peertube
cd /opt/peertube
curl https://raw.githubusercontent.com/chocobozzz/PeerTube/develop/support/docker/production/docker-compose.yml > docker-compose.yml
curl https://raw.githubusercontent.com/Chocobozzz/PeerTube/develop/support/docker/production/.env > .env

nano docker-compose.yml

  • Comment out the webserver and certbot sections
  • In the peertube: section, uncomment the line with port 9000, and edit it to “9001:9000”
    • Portainer uses port 9000, so this seemed to be a conflict.

nano .env

  • Replace <MY POSTGRES USERNAME>and <MY POSTGRES PASSWORD> with the database user and a secure password, respectively. This username and password can be anything you choose.
  • Replace <MY DOMAIN> with whatever FQDN will point to this instance
  • Replace <MY EMAIL ADDRESS> with, well, your email address
  • Uncomment the lines PEERTUBE_WEBSERVER_PORT=80 and PEERTUBE_WEBSERVER_HTTPS=false, and change them to port 443 and true, respectively.

Start PeerTube with docker-compose up.

In a separate terminal, in the same directory, run docker-compose logs peertube | grep -A1 root to get your randomly-generated default root password. Save this password.

Add PeerTube to the aqua network: docker network connect aqua peertube_peertube_1

Test

Browse to $NETHSERVER_IP:9001, and see if you get the PeerTube page. You won’t be able to log in here, but you should see the page. If so, it should be good. Stop the instance with Ctrl-C.

Reverse proxy

wget https://gist.githubusercontent.com/mrmarkuz/de99f0ef59ef7d1716504c710801d4a4/raw/31f742103ad1dfec94408537b34b6d595b902def/peertube.conf -P /etc/httpd/conf.d/

Edit this file:

  • Change the two ServerName directives to the hostname you’ve chosen above
  • If you have obtained a cert just for that hostname, edit the SSLCertificateFile and related directives to point to that cert
  • Near the end of the file (lines 111 and 114), edit the RewriteRule and ProxyPass directives to specify port 9001, rather than 9000

Restart Apache with systemctl restart httpd, and restart PeerTube with docker-compose up -d.

Conclusion

Now you can browse to your instance at the name you’ve chosen, log in as root with the password generated password you noted above, change that password, create users, and otherwise configure your instance. Enjoy!

2 Likes

It works with disabled firewall (shorewall clear).

It seems this is the relevant firewall reject log entry:

Jan 28 14:33:43 testserver kernel: Shorewall:INPUT:REJECT:IN=br-9233968d0f85 OUT= PHYSIN=vethbc9ee58 MAC=blabla SRC=172.18.0.42 DST=172.18.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=TCP SPT=9000 DPT=59406 WINDOW=28960 RES=0x00 ACK SYN URGP=0

I need to check more, maybe it’s enough to have same ports (9001:9001), there’s a way to change the config or we may need a firewall rule


Confirmed.

I think I’d favor the firewall rule–the more we can leave the PeerTube configuration at its default, the more maintainable it’s likely to be.

Edit: I’m pretty sure we’d also need a rule to open port 1935 to the outside, to allow live streaming. I just haven’t gotten there yet.

1 Like

After connecting peertube_peertube_1 container to the aqua network the reverse proxy worked.

You may set it with portainer or command line:

docker network connect aqua peertube_peertube_1

I noticed that shorewall opens the ports for running containers but maybe it needs to be restarted to apply the new container ports.

signal-event firewall-adjust

Fully agree.

Yes, I need to look into peertube livestreaming first, never used it. I don’t know if we could use a reverse proxy (websocket) or a maybe port forward so in “worst” case we need a custom template firewall rule.

I understand it’s new with PeerTube 3. From what I can see, it doesn’t use HTTP or WebSockets, so I’m not at all sure it would be amenable to being behind a reverse proxy.

1 Like

Any chance to have a ‘real install’ on NethServer (as opposed to a docker install)? Although, since containers seems to be something that is to stay, it might be good to stay on this way of installing services


Sure; that’s the guide I linked to above. My concern is that the versions of NPM, Postgres, etc. all seem to have fairly specific requirements, and those don’t match other things that also often run on Neth. Putting it into a container keeps that stuff separate, so the dependencies for PeerTube don’t mess with the dependencies for anything else.

Doing this and then rebooting results in the instance still working behind the reverse proxy. But it’s also accessible by IP:9001, which I’m not sure is desirable. Right now, I’m just testing it on a test VM without outside access, so I’m not sure if it’d be accessible on a “red” interface.

Other things I’m noticing:

  • Transcoding takes forever. True, it’s a long video I uploaded, but it’s been working on transcoding for several hours. I guess that’s good news and bad about transcoding into multiple resolutions.
  • Right now, video playback isn’t working. I can click on a video, but I just get this:
  • It imports YouTube videos by URL, and that seems to work well and quickly. Looks like it will import from other sites as well (I think I saw it will import anything that youtube-dl will, which is a lot).
  • My channel is being designated as dan_channel@hostname:80. I’m not sure where the :80 comes from, and I’m also not sure it’s a good thing–after all, HTTPS is on port 443


The big issue, of course, is that playback isn’t working–definitely need to track down what’s going on there.

I had similar experience with live video. It worked in a way that peertube gets a stream and the live video is started and stopped if I stop the stream. I used OBS for streaming as mentioned in the peertube documentation.
But I never saw a running video, just the loading circle forever as you reported.

I added a custom firewall rule because I saw entries in firewall log, in this case I copied the example mysql rule fragment (this could be optimized like using an own fragment)

mkdir -p /etc/e-smith/templates-custom/etc/shorewall/rules/
cp /etc/e-smith/templates/etc/shorewall/rules/65aqua /etc/e-smith/templates-custom/etc/shorewall/rules/
nano /etc/e-smith/templates-custom/etc/shorewall/rules/65aqua

Added following line:

ACCEPT aqua $FW tcp - 9000

After that I had no new entries regarding peertube in firewall.log anymore.

It’s autoconfigured and allowed from green because the ports are used in docker.

I hope it’s just a cosmetic issue.

Maybe it’s from the .env configuration:

PEERTUBE_WEBSERVER_PORT=80

I’m going to test some more the next days


I’m not sure if it’s relevant, but the ones I’ve tried have been static video files that I uploaded to my instance.

Usually static files shouldn’t be a problem at all and playing videos worked with the native installed peertube so I think there’s a problem with the docker version and the video playback.
I must admit that I tested without certificate and real hostname which may be an issue too.

I’ve found this can be mitigated, somewhat, by this setting under VOD transcoding:
image

Otherwise, it defaults to taking only one core. With “auto” and an otherwise mostly-idle server, it’s using all cores. But still, it’s a slow process–granted I’m running my Proxmox host on old hardware (Xeon X5650s), but with four cores on that VM and SSD storage, it’s still taking ~6x real time to transcode videos (i.e., about an hour for a ten-minute video).

@danb35

Not only old hardware
 But transcoding makes BIG usage of a GPU when available, and that’s kinda hard on a VM
 It IS possible eg with a PCI or whatever and hardware passthru, then the VM can use the GPU. But you can’t easily migrate unless all Proxmox are also equipped with the Grafik / GPU card in the same slot


Like OpenVPN on a CPU without AESNI - it works, but you’re not winning the record!

My 2 cents
Andy


and since I only have one PCIe slot in each of my three nodes, and that’s being occupied by my 10G NIC, I guess I just wait. This isn’t necessarily critical, but it’s something to be aware of for anyone who’d be using this.

@danb35

One of those cases where a modest, but current, cheap Notebook can run circles around really powerful hardware, just because of the GPU


My 2 cents
Andy

Indeed it was, and also the playback issue. With the port set to 443 and HTTPS set to true, both issues are resolved–the channel name on my test instance shows simply as dan_channel, and playback starts right away. I’ve made a few edits to the steps above to reflect this and a few other changes, it should be usable at this point.

Edit: Seems this also addresses the problem I was having looking for themes and plugins.

1 Like

Great, live streaming is working now too.

Would it help if you use an APU (CPU with integrated graphics) instead of a CPU without one? Especially the AMD APU’s have quite decent GPU performance.

@robb

Hi Robb

Depends what’s on the market available
 My clients want a “bought” server, from a brand name, and not a no name or self put together box


And most servers (still) come with Intel CPUs. Some do have AMD, but there is much less choice


And even then, you’re giving up on flexibility. The VM can only run decently on Hardware with those CPUs (APUs), and not just anywhere.

To me, it seems that specialized Machines for eg Transcoding, Terminal Servers for CAD / Video Cutting / DICOM will be offloaded to “specialized” hardware. This could be a seperate Hypervisor (Or Cluster of Hypervisors) for the GPU intensive stuff.

Other VMs like ERP / Database / other less Graphics intensive stuff will run on “normal” Server hardware Hypervisors.

My 2 cents
Andy

PS:

This is so someone else can handle the issue / problem, if I come under a truck or something

OK with me!

@robb reports that PeerTube 3.1 was released yesterday. If you’ve been running 3.0 following this guide, upgrading is simple, following the docs:

cd /opt/peertube
docker-compose pull
docker-compose down -v
docker-compose up -d

And then re-add it to the aqua network with docker network connect aqua peertube_peertube_1

4 Likes