<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>GitOps on Tom Meurs</title>
    <link>https://tommeurs.nl/en/categories/gitops/</link>
    <description>Recent content in GitOps on Tom Meurs</description>
    <generator>Hugo</generator>
    <language>en</language>
    <copyright>© Tom Meurs</copyright>
    <lastBuildDate>Sat, 03 May 2025 19:27:00 +0200</lastBuildDate>
    <atom:link href="https://tommeurs.nl/en/categories/gitops/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Drift Detection with ArgoCD: How to Know If Your Cluster Is Still in Sync</title>
      <link>https://tommeurs.nl/en/posts/argocd-drift-detection/</link>
      <pubDate>Sat, 03 May 2025 19:27:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/argocd-drift-detection/</guid>
      <description>&lt;p&gt;The whole pitch of GitOps is that Git is the source of truth. That promise holds right up until someone runs &lt;code&gt;kubectl edit&lt;/code&gt; on a deployment at 2am to stop an incident, a mutating webhook quietly rewrites a resource, or a half-finished sync leaves your cluster somewhere between what Git wanted and what it got. Now Git says one thing and the cluster does another, and nobody told you.&lt;/p&gt;&#xA;&lt;p&gt;That gap is configuration drift, and it is the part of GitOps people forget to defend. The good news: &lt;a href=&#34;https://argo-cd.readthedocs.io/&#34;&gt;ArgoCD&lt;/a&gt; already watches for it. The catch is that the defaults don&amp;rsquo;t do what you probably assume, and a few of them will bite you. This post walks from the simplest possible drift check up to the setup I actually run, one layer at a time. Stop wherever you have enough.&lt;/p&gt;</description>
    </item>
    <item>
      <title>App-of-Apps Pattern in ArgoCD: Scalable GitOps Architecture</title>
      <link>https://tommeurs.nl/en/posts/argocd-app-of-apps/</link>
      <pubDate>Mon, 21 Apr 2025 20:18:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/argocd-app-of-apps/</guid>
      <description>&lt;p&gt;My homelab started with one ArgoCD Application. Then a handful. The day I caught myself running &lt;code&gt;kubectl apply -f&lt;/code&gt; for the fifteenth time to register yet another Application, I knew I&amp;rsquo;d built the exact thing I was trying to avoid: manual steps I had to remember, in an order I had to remember, with no record of what should exist.&lt;/p&gt;&#xA;&lt;p&gt;The App-of-Apps pattern fixes that with one idea. You create a single root Application by hand, and it creates everything else. After a cluster wipe I can rebuild the whole thing with one &lt;code&gt;kubectl apply&lt;/code&gt;. That property is the entire reason I run it, and it&amp;rsquo;s the same reason I self-host in the first place: I want the repository to be the truth, not my memory.&lt;/p&gt;</description>
    </item>
    <item>
      <title>GitOps Disaster Recovery: Rebuilding Your Cluster from Git</title>
      <link>https://tommeurs.nl/en/posts/gitops-disaster-recovery/</link>
      <pubDate>Wed, 09 Apr 2025 19:52:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/gitops-disaster-recovery/</guid>
      <description>&lt;p&gt;For a couple of years my homelab cluster ran without much drama. Nodes came and went, workloads shifted around, and the worst I ever had to deal with was the occasional pod stuck in &lt;code&gt;CrashLoopBackOff&lt;/code&gt;. The kind of stable where you stop thinking about what happens if it all goes away.&lt;/p&gt;&#xA;&lt;p&gt;Then one evening I ran a &lt;code&gt;terraform destroy&lt;/code&gt; against the wrong workspace. By the time I noticed, the control plane was gone. Not degraded. Gone.&lt;/p&gt;</description>
    </item>
    <item>
      <title>ArgoCD vs Flux: When to Choose What</title>
      <link>https://tommeurs.nl/en/posts/argocd-vs-flux/</link>
      <pubDate>Fri, 28 Mar 2025 21:33:00 +0200</pubDate>
      <guid>https://tommeurs.nl/en/posts/argocd-vs-flux/</guid>
      <description>&lt;p&gt;&amp;ldquo;Should I use ArgoCD or &lt;span class=&#34;def&#34; tabindex=&#34;0&#34; data-def=&#34;The other GitOps engine next to ArgoCD. Controllers in the cluster reconcile from Git with no UI of its own, where ArgoCD leads with one.&#34;&gt;Flux&lt;/span&gt;&#xA;?&amp;rdquo;&lt;/p&gt;&#xA;&lt;p&gt;I get this question over coffee, in Slack, in PR comments, probably once a week. People want me to declare a winner so they can stop thinking about it and go build something.&lt;/p&gt;&#xA;&lt;p&gt;Here is my bias, up front, so you can weigh everything that follows: I run ArgoCD on my own clusters. I have a few years of it under my belt and I like it. That preference is going to leak through no matter how careful I am, so I am telling you now instead of pretending I am neutral.&lt;/p&gt;</description>
    </item>
    <item>
      <title>ArgoCD for Beginners: Your First GitOps Deployment</title>
      <link>https://tommeurs.nl/en/posts/argocd-beginners/</link>
      <pubDate>Sun, 16 Mar 2025 19:15:00 +0100</pubDate>
      <guid>https://tommeurs.nl/en/posts/argocd-beginners/</guid>
      <description>&lt;p&gt;Here is the thing I never want to do again: ask a cluster what it is running and not trust the answer. For years that was normal. Someone ran &lt;code&gt;kubectl apply&lt;/code&gt;, maybe from a laptop, maybe from a CI job nobody could find anymore, and the live state slowly drifted away from anything written down. When I switched to GitOps, that whole category of uncertainty disappeared. I push to Git, and the cluster converges to match. If I want to know what is deployed, I read a file.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
