We are going to build our self-hosted HA SeedBox forQbittorrent, one of the most popular decentralized network protocols in the world.

Introduction

You may have noticed that whenever the topic of aP2P network comes up during a conversation, it is giving rise to some kind of allusion to topics that refer to piracy or undesirable content being shared without control. Ultimately, technology is not to blame for misuse, but despite the fact that it is a decentralized network, the network traffic can be blocked byISPs.

Nice to have:

• A little more in-depth knowledge about a SeedBox
• Werf, the viable Helm Replacement
• A Kubernetes cluster where we can create deployments
• Terminal based UI to interact with your Kubernetes cluster
• What is a NAS server?

Prepare the scenario

You've probably already played theKubernetes game and know what it's all about, but if not, I highly recommend you to discover the best container manager in the world and play with it before.

You can take a look atthis public repository I have prepared to make available aHelm chart that can be customized to the needs that each of us have. I'm followingthis other guide as I write this to publish the repository as a chart package.

I almost forgot to mention that we need to have a NAS server accessible from the network of our Kubernetes cluster. I have my server configured on aRaspberry pi 3 where a HDD has been attached to it and has been published on the network by usingOpenmediavault.

> showmount-e 192.168.2.10# list exported pathsExport listfor192.168.2.10:/export                      192.168.2.0/24/export/home-lab-nas-runtime 192.168.2.0/24

Sadly the hardware used for the NAS server is a bottleneck, as the local network transfer speed works much faster than the USB 2.0 to which the disk is mounted.

First contact

At the time of writing thisWerf does not yet implement all of Helm's functionality, which is why the alternative itself contains a separateHelm installation to cover the actual missing implementations.

> helm versionversion.BuildInfo{Version:"v3.15.3", GitCommit:"3bb50bbbdd9c946ba9989fbe4fb4104766302a64", GitTreeState:"clean", GoVersion:"go1.22.5"}

> werf helm version                                                                                                                                                                                             version.BuildInfo{Version:"v3.14", GitCommit:"", GitTreeState:"", GoVersion:"go1.21.6"}

FortunatelyWerf implements theHelm specifications, so if you feel more comfortable using thehelm CLI you can continue doing so.

Installing the chart

We have to ways to do it. Both methods read the previously configured values ​​that best suit for my scenario, but you should modify them.

Feel free to edit the.helm/values.yaml file. You will primarily need to modify the volumes related section under the directory structure you have configured on your NAS server.

The chart parameters that can be modified has been documentedhere.

Werf converge (Recommended)

We can clone the chartgitrepository and deploy it in an orderly manner. The first joy thatwerf gives us is that it shows us a detailed output in real time about what is happening with the deployment. Withhelm this doesn't happen.

If no working path is specified, the default directory is.helm from which to attempt the deployment.

Nelm is the re-written implementation forhelm. Unfortunately this does not yet have a dedicated command, so the only way to use it is through thewerf command.

> werf converge--dev[±master ✓]Version: v2.6.4Using werf config render file: /tmp/werf-config-render-2521405566Starting release"qbittorrent"(namespace:"qbittorrent")Constructing releasehistoryConstructing chart treeProcessing resourcesConstructing new releaseConstructing new deploy planStarting trackingExecuting deploy plan┌ Progress status│ RESOURCE(→READY)                    STATE    INFO│ Deployment/qbittorrent               WAITING  Ready:0/1│  • Pod/qbittorrent-648fd97cd7-fbrcw  CREATED  Status:ContainerCreating│ Ingress/qbittorrent                  READY│ Service/qbittorrent                  READY└ Progress status┌ Progress status│ RESOURCE(→READY)                    STATE  INFO│ Deployment/qbittorrent               READY  Ready:1/1│  • Pod/qbittorrent-648fd97cd7-fbrcw  READY  Status:Running└ Progress status┌ Completed operations│ Create resource: Deployment/qbittorrent│ Create resource: Ingress/qbittorrent│ Create resource: Service/qbittorrent└ Completed operationsSucceeded release"qbittorrent"(namespace:"qbittorrent")Runningtime8.98 seconds

Helm install

Perhaps the most classic way to deploy an application is by usinghelm. I think there is nothing more to add here, except that comparing the level of detail that the previous option gives us, this option may bemore tedious if we need to debug possible errors.

> werf helm repo add home-lab-qbittorrent https://bounteous17.github.io/helm-chart-qbittorrent"home-lab-qbittorrent" has been added to your repositories> werf helm search repo home-lab-qbittorrent                                                                                                                                                                    NAME                                    CHART VERSION   APP VERSION     DESCRIPTION                home-lab-qbittorrent/qbittorrent        0.1.0           4.6.5-r0-ls334  A Helm chartforKubernetes> werf helminstallhome-lab-qbittorrent home-lab-qbittorrent/qbittorrentNAME: home-lab-qbittorrentLAST DEPLOYED: Sun Jul 28 11:18:36 2024NAMESPACE: defaultSTATUS: deployedREVISION: 1TEST SUITE: None

Let's make torrents eternal :)

Our application will be available under the ingress host that we have configured from theingress.host parameter.

You will have seen that in the.helm/values.yaml file ​​of this chartthese are the default values ​ configured to indicate in which OS path the data that we do not want to disappear if our container is restarted within the cluster should be stored.

Now that we havedata persistence assured, we will be able to access this NAS server from clients other than our cluster deployment to read the downloaded data.

If you are using a Linux machine as a second client to access the NAS volume with downloaded content, be sure to check outthis guide for optimal setup. Ultimately, the advantage of using this highly performing network protocol is that it is compatible with almost all operating systems.

Indeed, it would be really cool to set up aJellyfin server now and connect it to the network volume to enjoy the content from the couch ;)

I will be super happy to answer any questions (your skills doesn't matter, don't be afraid) and share with you solutions to any problems you may have encountered during this process.