I’ve been aware of pi-hole for a while now, but never bothered with it because I do most web browsing on a laptop where browser extensions like uBlock origin are good enough. However, with multiple streaming services starting to insert adds into my paid subscriptions, I’m looking to upgrade to a network blocker that will also cover the apps on my smart TV.

I run most of my self hosted services on a proxmox server, so I’d like something that’ll run as an LXC container or a VM. I’m also vaguely aware that various competing applications have come out since pi-hole first gained popularity. Is pi-hole still the best thing going, or are there better options?

  • khorak@lemmy.dbzer0.com
    link
    fedilink
    English
    arrow-up
    2
    ·
    11 months ago

    I wasn’t intending on doing this, instead opting to install Pi-hole, Log2Ram, UFW, and the… other… softwares directly to the OS for simplicity. Why would one set up a Pi-hole et al in a containers instead of directly?

    So there are many reasons, and this is something I nowadays almost always do. But keep in mind that some of us have used Docker for our applications at work for over half a decade now. Some of these points might be relevant to you, others might seem or be unimportant.

    • The first and most important thing you gain is a declarative way to describe the environment (OS, dependencies, environment variables, configuration).
    • Then there is the packaging format. Containers are a way to package an application with its dependencies, and distribute it easily through the docker hub (or other registries). Redeploying is a matter of running a script and specifying the image and the tag (never use latest) of the image. You will never ask yourself again “What did I need to do to install this again? Run some random install.sh script off a github URL?”.
    • Networking with docker is a bit hit and miss, but the big thing about it is that you can have whatever software running on any port inside the container, and expose it on another port on the host. Eg two apps run on port :8080 natively, and one of them will fail to start due to the port being taken. You can keep them running on their preferred ports, but expose one on 18080 and another on 19080 instead.
    • You keep your host simple and empty of installed software and packages. Less of a problem with apps that come packaged as native executables, but there are languages out there which will require you to install a runtime to be able to start the app. Think .NET, Java but there is also Python out there which requires you to install it on the host and have the versions be compatible (there are virtual environments for that but im going into too much detail already).

    Basically I have a very simple host setup with only a few packages installed. Then I would remotely configure and start up my containers, expose ports etc. And I can cleanly define where my configuration is, back up only that particular folder for example and keep the rest of the setup easy to redeploy.