Posts

As an addendum to my previous post on giving yourself an IPv6 address using wireguard, I wanted to show how, if you are lucky enough to have a IPv4 range before the “great IPv4 exhaustion”, you can assign those addresses to clients using wireguard. Several consumer, prosumer, and enterprise cloud hosts, allow you to advertise your IP range for your cloud servers. Some of these providers are OVH, Vultr, and Equinix Metal, but like last time, I suggest you look into OVH due to their predictable costs around bandwidth, as well you don’t need to configure a BGP connection with them which makes setup much less work. ...

After many years of asking, my Internet Service Provider (ISP) still doesn’t support IPv6; the same goes for many other ISPs. This is a problem for many reasons, the first being the exhaustion of IPv4 addresses, leading some ISPs to implement “Carrier-Grade NAT” (CGN), where many customers share the same address—the second being that it is getting more and more expensive for small websites to have their own dedicated IPv4 addresses, including cloud providers instituting a cost to have an address. The obvious solution would be for all ISPs to start supporting IPv6, but sadly, this requires effort on the part of ISPs, and the problem isn’t known to many of their customers, so the easy path for them is to keep status-quo. ...

In my ever-ending quest to do things that are probably not the best idea that aren’t a part of a usual use-case, I wanted to see if I could run a docker daemon on Fly.io. Even though you can think of Fly.io as a “container”-service hosting platform, it’s actually using Firecracker micro-VMs to run your service. They (“transmogrify”)[https://fly.io/blog/docker-without-docker/] Docker images into the micro-VMs they run. This means, it’s much easier to run a docker daemon, as you don’t need to worry about the implications of running the docker daemon inside of a docker container. ...

Namespace.so is a service that provides ephemeral instances (Linux, and macOS) for you to use, primarily used for CI/CD workflows. Similar to Fly.io, it’s another way to not have to manage servers. I’m currently using it to run some of my CI/CD workflows, but I want to play around with it in other ways. One, would to potentially make it a run-on-demand nixpkgs builder, similar to how I have with Fly.io, but with Fly.io I need to manage the instances myself, whereas Namespace will terminate instances after a set period of time. This reduces the monthly hosting spend. ...

Now that we are able to synch TLS certs and the Caddy configuration across various points-of-prescense, we now need to ensure that Caddy will only request certificates for approved names. As we are doing this for Gitea Pages, we won’t know what the domain names are in advanced and will have to create a validation service to handle this. This approach can also be abstracted to any SaaS that provides the ability for customers to bring their own domain. ...

In the previous post we discussed how to provision, and keep TLS certs in synch across multiple Caddy instances. In this post we will look at how to dynamically create and distribute Caddy configuration to multiple nodes using Hashicorp’s Nomad. Similar to other orchestrations tools such as Kubernetes, Nomad allows you to schedule and run containers, and non-containerized applications, across many servers with a standardized configuration. Using nomad, we can manage multiple servers, in many datacentres, to create those Points of Presence (PoPs) for our CDN we discussed in our previous post. We will create configuration that will run Caddy on each edge node, and generate configuration dynamically to act as a reverse proxy based on the applications that nomad is also running. ...

A service I enjoy using, and write about often, is fly.io, as it lets me have compute on demand, without having to worry about provisioning and managing it an entire server. Editors Note: This was a fun experiment, but you are likely better off using a managed service such as nixbuild.net for anything even resembling a production use case. One of my latest use cases for it, is to offload building of nixpkgs from my low powered laptop, to a remote builder on fly where I can provision as many resources as I need, for as short of a period of time as needed. ...

As a part of building a Content Delivery Network (CDN) for Gitea Pages, I’m documenting my process to share my experience with others. The reason I’m building one from scratch, rather than using a pre-built solution like Amazon CloudFront, is the potential need for many unique TLS certificates. From past experience, I’ve learned that there are limits to how many certificates you can have on a single CloudFront distribution. This is the first post in a series that will document the process of building a CDN from scratch. ...

Carl Sagan once said, “If you wish to make an apple pie from scratch, you must first invent the universe.” In the world of software, creating a reproducible build environment is the universe you need to invent. This post will walk you through using Nix in tandem with Gitea Actions to make that universe a reality for your projects. I am an enthusiastic user of Nix and am a maintainer of several packages. I appreciate the reproducibility of the binaries it offers across different systems and its rapid update cycle. ...

Watchtower is an excellent tool for keeping your containers up to date. It’s a process that runs on a schedule and checks for new versions of your containers, and if it finds one, it pulls the new image and recreates the container with the latest image. It’s built for Docker, and it works great for Docker. But what about Kubernetes? Keel, a Kubernetes operator, also achieves what Watchtower can do but can automate Helm, DaemonSet, StatefulSet & Deployment updates. It also has a friendly UI to see the status of the updates it is managing. ...