Recently I was toying with the somewhat new GitHub feature that allows you to create a repository with the same name as your GitHub username and host in it a README.md file that then is displayed in your profile and visible to whoever visits your profile page. While this feature is good, it’s not too dynamic, but there are two things in our favour: a) GitHub Actions are free for public repositories and b) we can use the GitHub API to fetch information about our repositories, pull requests and more.
On August 2014 I made one of the most difficult choices of my life: I left my home country, my family, my friends and everything I knew to move to the United States. I arrived in Florida, and while Florida still speaks a lot of Spanish for a US State (not in a bad way, I’m not complaining! It made my life easier) it still took a bit of me to get used to this new culture.
Back in November 2022 I was browsign the then Twittosphere (now Exosphere?) when I ran across an interesting tweet from @manishrjain: What is happening? Caddy is 2x outperforming NGINX in my reverse proxy test 🚀 With Caddy, there's practically no difference in HTTPS vs HTTP performance. If legit, this is clearly a David vs Goliath story. @mholt6 — Manish R Jain (@manishrjain) November 23, 2022 It caught my attention, but not because of the claim that Caddy outperforms Nginx by 2x, but instead because often, when it comes to benchmarking and comparing technologies, especially when it comes to Servers, Internet and Network Requests, you could often overlook specific details.
With Hashicorp moving a bit away from their roots in the Open Source world and going into the more locked-in, don’t-compete-with-me kinda scenario, it’s hard not to start thinking whether you should be looking at jumping ship away from your massive Terraform setup. If you’re in that boat, where can you go? What are the alternatives to Terraform? In this article, I’ll provide some of my recommendations as to where to go, with some pros and cons on each option. While your mileage might greatly vary depending on your technical requirements and conditions, there won’t be a one-size-fits-all solution, so I’ll try to cover as many options as possible.
Recently I’ve been playing with a few different tools to make me more proficient when working with Kubernetes. Additionally, people that know me know I play lots of games – sinking more and more time into Destiny 2 – so I keep Windows as my daily desktop driver and even with all the grievances of WSL – including random loss of networking – I still use it as a daily driver to write code and do other work in a Linux environment while still retaining a Windows “desktop”.
We’ve all been there: we’re working on our next super-hyper-duper Kubernetes operator, we’re about to deploy it but we’re doing some local testing, so we create a ConfigMap or a Secret, we mount it to the Pod, launch our app and we see the entire directory is now gone, replaced with our ConfigMap or Secret’s contents. This post will show you how to mount a ConfigMap or Secret on a preexistent folder without deleting all its data. We’ll use the hypothetical case scenario that you’re working in your next static, pure HTML page – and of course, you do need Kubernetes to run that because reasons – so you’ll resort to using the Nginx image.
Working with service meshes is really an interesting concept and sells you the benefits of, well, the service mesh itself, mutual TLS, end-to-end encryption, and more. Unfortunately though, not everything is as straightforward as you might think. In fact, Istio’s own documentation page has a full section dedicated to “common issues”. These issues are not so evident if you come from an Ingress Controller world and you assume you would understand Istio using the same knowledge as you would have when using Ingress Controllers instead.
Here’s an interesting problem I ran into while doing some work a few days ago. I was working on a pipeline to deploy new resources using ArgoCD. Everything was going great until one of the Kubernetes resources was, in fact, a resource managed by a Kubernetes controller: that is, applying it will not create it, it will merely tell the controller to create it, eventually. In practical terms, during my time at Sourced Group, we’ve been working closely with Anthos and some of their applications, including Anthos Config Connector, a nifty little controller that allows you to declare Google Cloud resources as Kubernetes YAMLs, and have this Config Connector – or ACC for short – create them for you.
I know I’m not the first one to create this and, in fact, there are a plethora of options out there to use as of right now. Still, I wrote my own version of wait-for, and there are a few differences that make it to be a little more useful than the alternatives.
Hola! Uff, qué raro se siente escribir en un blog de nuevo. Después de un par de días de trabajo, he logrado recuperar el blog. Inicialmente, este blog usaba Hugo, pero por varios años de descuido – entendiendo que el último artículo que escribí fue en Enero del 2015, 7 años atrás! – no me fue posible recuperar la tecnología de fondo del blog. Si mal ni menos no recuerdo, el “motor” de Hugo era 0.33.x, el problema era que con las nuevas versiones, el template del blog dejó de funcionar.