Tagged: devops

Recently I got to be an admin over a few hosts. These hosts were all CentOS-based and in terrible shape. Missing repos, different versions, weird software installed on them. It turns out administrators cloned the VMs, and as time passed, they updated some of them, leaving some behind.

Having event deduplication is a game-changer for several reasons, that finally made the operator writing possible. Let's have a look.

I had an interesting discussion today that I think is worth writing about. I mentioned having a problem with having a very fat component in a system since integration tests usually become a nightmare. The idea was raised that architecture should not be driven by integration tests, but rather by customer requirements and value. While at face value, this seems intuitively correct, is that so?

What happens when we might receive many events, but only need to process the last one? For example, in a Kubernetes operator, where events from a custom resource keep streaming in, we want to process only the custom resource's last state. This approach is called event deduplication. Before we created a whole scaffolding around in BPMN, that would wait using locks and manually track the events. Using this is prone to problems that we'll analyze and see the bundled solution offered by Adhesive.

As I already mentioned, I wasn't too happy about the currently available DNS operators out there that integrate with let's encrypt. What I wanted was one that works right of the box, and allows me to add new Ingress objects, and magically generate their TLS certificates. I'm going to break down in a small mini-series of articles on how I ended up implementing it.

As I already mentioned, I wasn't too happy about the currently available DNS operators out there that integrate with let's encrypt. What I wanted was one that works right of the box, and allows me to add new Ingress objects, and magically generate their TLS certificates. I'm going to break down in a small mini-series of articles on how I ended up implementing it.

When creating containers, having multiple layers dramatically reduces the time of development. Unfortunately, having a bunch of layers is a bad practice. So how do we reconcile the two? Simple, by compiling the Dockerfiles with docker-optimizer.

If you already have some containerized infrastructure running with docker-compose, or just plain docker containers that are provisioned by a config management tool, you definitely want to switch to Kubernetes. Here's how I did it.

When having a critical long running task, it's imperative we get immediate feedback on things that run longer than they are allowed. With the new Timer boundary events, that's trivial to model.

Having the adhesive build process as code it's a nice feature to have. In combination with containers it makes the source code the only truth on how the build is being performed. But that still means we have a dependency now on the build system itself. So how do we get rid of it? We're going to containerize the local build system.