<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Jon's Devlog</title><link>https://bouligny.dev/</link><description>Recent content on Jon's Devlog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 29 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://bouligny.dev/index.xml" rel="self" type="application/rss+xml"/><item><title>About Jonathan Bouligny</title><link>https://bouligny.dev/about/</link><pubDate>Tue, 29 Sep 2026 00:00:00 +0000</pubDate><guid>https://bouligny.dev/about/</guid><description>&lt;p&gt;I am a &lt;strong&gt;Platform and Infrastructure Engineer&lt;/strong&gt; based in Austin, Texas, with 6+ years of experience designing, automating, and operating enterprise Linux platforms at &lt;strong&gt;Red Hat&lt;/strong&gt; and &lt;strong&gt;Lockheed Martin&lt;/strong&gt;.&lt;/p&gt;&#10;&lt;p&gt;I hold the &lt;strong&gt;Red Hat Certified Architect (RHCA) in Ansible&lt;/strong&gt; credential and specialize in building deterministic, reproducible systems from the bare hypervisor up using &lt;strong&gt;Terraform, Ansible, Kubernetes (k3s/OpenShift), and GitOps (Argo CD)&lt;/strong&gt;.&lt;/p&gt;&#10;&lt;hr&gt;&#10;&lt;h2 id="what-im-building-now-fleet-platform"&gt;What I&amp;rsquo;m Building Now: Fleet Platform&lt;/h2&gt;&#10;&lt;p&gt;My current flagship engineering project is &lt;strong&gt;&lt;a href="https://bouligny.dev/fleet-platform/"&gt;fleet-platform&lt;/a&gt;&lt;/strong&gt;—a fully reproducible, GitOps-managed Kubernetes platform deployed on a self-hosted 3-node Proxmox cluster (40 cores, 157 GB RAM).&lt;/p&gt;</description></item><item><title>Phase 2, Part 1: cert-manager, Rate Limits, and the Restore Race</title><link>https://bouligny.dev/fleet-platform/phase-02-part-01-cert-manager-rate-limits-restore-race/</link><pubDate>Tue, 29 Sep 2026 00:00:00 +0000</pubDate><guid>https://bouligny.dev/fleet-platform/phase-02-part-01-cert-manager-rate-limits-restore-race/</guid><description>&lt;blockquote&gt;&#10;&lt;p&gt;&lt;strong&gt;Note on Build Chronology&lt;/strong&gt;: &lt;em&gt;This devlog was started mid-flight during the cert-manager &amp;amp; ingress milestone. Foundational build logs for Phase 0 (two-node k3s bootstrap) and Phase 1 (Proxmox/Terraform/Ansible) are currently being backfilled.&lt;/em&gt;&lt;/p&gt;&#10;&lt;/blockquote&gt;&#10;&lt;h2 id="cert-manager"&gt;cert-manager&lt;/h2&gt;&#10;&lt;p&gt;Setting up cert-manager was pretty easy with a Helm chart. I did spend a lot of time on this step but it was mostly googling and figuring out what to do about bootstrap secrets which I detail below. The most interesting thing I learned was part of the values file, specifically &lt;code&gt;installCRDs&lt;/code&gt; (or &lt;code&gt;crds.enabled&lt;/code&gt;, depending on chart version). CRDs, Custom Resource Definitions, are objects that teach the Kubernetes API server about new kinds of resources, like &lt;code&gt;Certificate&lt;/code&gt; and &lt;code&gt;ClusterIssuer&lt;/code&gt;. They&amp;rsquo;re not backed by Go directly, they&amp;rsquo;re schema definitions, and a controller (cert-manager&amp;rsquo;s own pod, running Go code) is what actually watches for objects of that kind and acts on them. So a CRD without its controller running is just an inert schema. The controller is the operator, the CRD is the vocabulary it teaches the cluster.&lt;/p&gt;</description></item></channel></rss>