After installing and setting up all the different pieces of our CI/CD pipeline, we still need to do a bit of work to make sure that this process is as automated as possible, as is working in tandem to our benefit. This post is mostly about that.

Ingress and SSL

Even though cilium was installed in our system, we still need to configure the different environments to use it as its ingress, as well as configuring a load balancer and certificate manager. Thankfully these are all relatively straight-forward tasks. Let us start with the load balancer, which is going to be metallb. This is achieved by installing the following manifest: kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.15.2/config/manifests/metallb-native.yaml. Feel free to download it beforehand to double check its contents. After that is done and all the pods and services are up and running, we create the file metallb-config.yaml with the following contents:

After what I have done in the previous post, the next step is to start building our infrastructure. For that, I will be using a few tools, namely: building a Kubernetes cluster, harnessing the power of k3s and kustomize, both of which greatly simplify the creation and configuration of the cluster and the different environments; and Argo CD as our continuous delivery tool that’s k8s native. All of this, of course, will be greatly enhanced by our already existing Git forge, and all the configuration files used are made available on the gitops-demo-config repository - this wouldn’t be a GitOps pipeline otherwise.

This is going to be a series of posts about a learning journey on what it takes to build a GitOps pipeline, with the added constraint that I’m going to be self-hosting all of the necessary parts to achieve this. On one hand, it’s bound to be a great exercise to put together disjointed pieces of knowledge I already had; and on the other, it serves as a way to document the journey for people that might be interested in knowing how such a thing is possible.

Perhaps one of the most pressing issues of our days is the (lack of) control we have over our online presence. Being spied on became the default expectation, and the lengths that this has gone to is sometimes hard to believe. Even a few months ago, it was revealed that a novel tracking method had been discovered in Meta’s Android application (Facebook and Instagram), as well as Yandex’s, were exploiting the loopback interface to be able to track your habits - looks like there’s no boundaries, physical or moral, that these companies won’t overstep. I’m focusing on this particular incident not only because it’s relatively recent, but also because it goes to show that this is a veritable whack-a-mole game; we were supposed to have dealt with the correlation between web browsing and app activity, but the tech giants found yet another way to go around it.

In the aftermath of the AWS outage, there’s a lot of talk about how the Internet has been taken hostage by this specific provider, and how the internet is not decentralized anymore. While it doesn’t seem like this is necessarily wrong - after all, the recent outage, and all AWS outages for that matter, seem to take down a sizeable portion of the internet - it’s both misguided and ignores the deeper problems at play here.