Nowadays everyone knows about Prometheus, but there are few people that1 dig deeper in its core functionalities, such as the storage of the data. However, it is a critical point because it can be a performance contender as much as a liability since you often base your whole alerting on the metrics that are stored in this TSDB (Time Series DataBase). For periods of retention that are more than a simple buffer we talk about Long Term Storage or in short “LTS”.
Cloud-init is a great way to initialize machines on cloud providers and it’s pretty straightforwardly supported everywhere.
As I mentioned in a previous post, I use argoCD as a tool in my CD pipeline for my GKE clusters at $DAYJOB. But it’s not the only tool that composes it. I’ve been using keel alongside argoCD to complement it. Let’s see how those 2 articulate and make our delivery fast and smooth
At $DAYJOB I’ve been setting up an argoCD instance to build the continuous deployment pipeline and so far it’s been pretty slick.
It’s super easy and fast to create metrics in the GCP console, especially in the rush of debugging. Unfortunately, if you want them to be available in another project (let’s say you have foo-dev and foo-prod projects) for later use then you have to recreate them. And for this you want them to be in your IaC repository.
GCP, and in particular its components GCE has a nice feature to run containers directly on a VM, without the need to spin up a GKE cluster or to provision a machine by yourself. It leverages the use of Container Optimized OS maintained by google.
This little post is to show how to get the public IP of your client/visitor when using the nginx-ingress on EKS. I’ve been reading a lot of things on this topic in the last days, with many different things said. My problem was simple : how to filter out the incoming traffic, IP based, for some of my kubernetes exposed services. For example, I wanted to restrict access to the development version of an API to only a bunch of trusted IPs
Because maintaining a jenkins server is not necessarily what feels rewarding, especially when it come to create more and more jobs that look the same. Fortunately, if you have read my previous post you will know that it is possible to use the “Job DSL” to remove the harness of this. But, even using the DSL, things can go what seems repetitive and boring.
A while ago, Jenkins introduced the Jenkinsfile, which is a file that lives in your project repository and allows to define your CI tests directly here. But there is no magic here : you need to define a job that will scan the repo for changes and all. This is a repetitive task, prone to error and time consuming for the “little value” it brings.
I’ve been using Jenkins and the bits described below for a while now : from years to month, depending of which part you speak. It all works on the open source version anyone can use. I am not partial to this CI server, I just wanted to share the things that made my life easier over time. Things that will be described here and in next post are not my own only, but something we worked onto, my colleague Jonathan and I.
Recently I have been working on creating a docker image containing dnsControl. I wanted to minimize the size of the image, and use the feature of go producing a single binary. Nothing fancy here, you can find lots of links about it.
This is the follow-up of my previous post regarding hindsight experimentations and discovery
This one is fairly easy, since it uses the lua sandbox extensions for ES. I ended up with the following run/output/es.cfg config
I have been recently introduced to hindsight by beorn and since I found that the learning curve was a bit steep I thought this blog migration would be a nice occasion to share some sort of “field notes”. This is by no mean a “hello world” for hindsight, a best practices or anything that should be considered as a tutorial. The goal is to share some feedback and help newcomers like me to avoid being stuck on some basic steps. I really do think that the hindsight documentation could be improved for beginners, but that’s not the point here.
This site has been left abandonned for something like 5 years and I did not wish to have to maintain a wordpress anymore. So I exported it and I am now using Hugo to render it. There may be updates soon, since I am thinking to write about stuff I am tinkering with.
Baptiste Daroussin did an incredible job on FreeBSD with the new packages system, named PkgNG. It brings modern workflow, options and shiny features that were needed for a long time. Say goodbye to painfully long upgrades.
It’s been a while since my last post here, and I have updated my cuisine dashboard yesterday so here is a little follow up on what’s new in it.