How do you take the ad-scrubbing Pi-Hole and turn it into a globally available app? Quickly and simply with Fly and in this article, we’ll show you how.
A Pi-Hole could be the hero of your web connection. It blocks advertising at the roots; the DNS roots that is. By setting up your own Pi-Hole, you can tip all your local network’s requests for known advertising domains down it.
What is Pi-Hole?
Think of Pi-Hole as a firewall for popups, overlays, banners and other mental focus-stealing and bandwidth-eating advertising. Unlike a firewall which filters through all your traffic, Pi-Hole does its work by acting as your DNS server with a difference, a database of advertising and tracking hosts and domains.
When a machine queries the Pi-Hole DNS for something that matches one of the entries in the database, Pi-Hole politely doesn’t resolve it and returns a dummy address. Ads that are served from ad providers just can’t load, while embedded ads are blocked from downloading their assets. Even dynamically inserted ads get caught by this technique.
Once you start stuffing things in your Pi-Hole, you’ll wish you could take it with you everywhere.
Pi-Hole at Home
The typical Pi-Hole is running on the eponymous single-board computer, tucked away somewhere on the home network. There are a lot of good reasons to do that. For example, a Pi-Hole can also be a DHCP server for your network. That means it can automatically give out its address for DNS resolution to all your laptops, phones, aging desktops, smart TVs, and Amazon surveillance devices, practically configuring all your home devices to use it.
But then that makes it somewhat hard to take on the road with you, even if you are the most organized road warrior to ride the roads. You stop at a coffee shop and then the next hour is spent connecting the Pi-Hole to the diner Wi-Fi and reconfiguring it for its new environment and, well, you aren’t going to get a lot of browsing done.
Of course, you only need to point your DNS at the Pi-Hole and if you have a server at home which is running Pi-Hole, you could just point your mobile devices at that and vanish those ads. To make that easier, the diggers of the Pi-Hole have packaged it up as a Docker image that you can run on a machine on the edge of your network. There’s also a guide for configuring it with a VPN to make things easier.
Pi-Hole The Planet!
Remember traveling? We do, and we also remember that the further you go from home, the further you are from your home server. And that means latency. And we hate latency at Fly. Physics dictates though that distance means latency and given how many DNS lookups a modern browser or app could be doing, that all mounts up.
Ah, you say, I have a cunning plan; I will run my Pi-Hole in a datacenter somewhere on a singular server. And so you might, but all you are changing then is that the latency depends on the distance between you and the datacenter, rather than the distance between you and your home.
What we need is a Pi-Hole that is everywhere.
A global Pi-Hole to keep you free from adverts and your connection free from the bandwidth hogs would be wonderful but how could you build it?
Well, imagine you had a global edge network connected to dozens of data centers around the world. You could deploy Pi-Hole as an edge application to that network and get the benefits of automatically low latency and global availability. Fly’s network is a global edge network with data centers around the world… so we built a global Pi-Hole using it.
Seasoned Fly users will know that DNS uses UDP, a sister protocol of TCP and a protocol which has not been supported on Fly to date. Well, don’t tell anyone, but we have UDP support in beta so building a global Pi-Hole was a great way to give this a workout.
From Pi-Hole to Fli-Hole
Getting Pi-Hole ready for global filtering doesn’t require any changes to Pi-Hole itself. We even use the official Pi-Hole Docker image for Fly deployment. Here’s our Dockerfile:
FROM pihole/pihole:latest
ENV INTERFACE eth0
ENV DNSMASQ_LISTENING ALL
It simply takes that image and sets environment variables for which interface to listen on, and to allow DNSMasq (a component of Pi-Hole) to listen on all subnets for DNS traffic.
The other part of the configuration is the fly.toml file which defines how our application should be deployed to the Fly platform. You generate the core of this file with the command fly init and when asked, let it generate a name, use the Dockerfile builder and set the internal port to 80.
There’s just one final addition needed, an extra [[services]] section that looks like this:
[[services]]
internal_port = 53
protocol = "udp"
[[services.ports]]
port = "53"
This routes external UDP traffic on port 53 to the application’s internal port 53.
That’s nearly all the configuration done. The last step is to set the password on Pi-Hole’s web interface. This is picked up from an environment variable WEBPASSWORD. Fly’s secrets are passed to running applications as environment variables, so the secure way to set this is to run:
fly secrets set WEBPASSWORD="horse-battery-staple"
Obviously, substituting in your own password as needed.
The Fli-Hole is now ready to deploy. Run:
fly deploy
And Fly will place an instance of Fli-Hole in a region close to where you are running the commands. If you want to check out the App dashboard, run:
fly open /admin
Which will open the dashboard. From there you can log in, using the password you set in secrets, to look at the other settings and logs gathered by Pi-Hole.
Going Regional
Now, you could deploy Fli-Hole to every Fly region on the planet, but that’s not the smart way of doing it. Say you were traveling, in an entirely hypothetical sense of course, to Europe. All you need to do is run:
fly regions add fra
And that would add the Frankfurt data center and associated region to the pool and start routing nearby traffic through there. Now you are ready to go on a European vacation with your Pi-Hole. If you were in the UK, for example, then the edge network would send your requests to Fra, via the UK’s edge nodes, for the fastest response.
It’s worth pointing out these instances of Pi-Hole have no persistence or sharing of settings. Each one is an independent Pi-Hole. It’s a strength and an easily mitigated weakness; just update the Dockerfile to change settings and configuration files and redeploy the application to get permanent global updates.
Through the Fli-Hole
What we’ve shown here is how quick it can be to configure an application to run on the Fly platform, from taking a Docker image off the shelf, connecting it to the web and UDP, setting configuration and secrets, and then sending it out into the world. You may not need a Pi-Hole everywhere, but your next big app might need to be everywhere at the drop of a hat.