<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Posts on CloudCat Digital</title>
    <link>https://cloudcat.digital/posts/</link>
    <description>Recent content in Posts on CloudCat Digital</description>
    <image>
      <title>CloudCat Digital</title>
      <url>https://cloudcat.digital/images/logo_text_small_cloudcat_digital.webp</url>
      <link>https://cloudcat.digital/images/logo_text_small_cloudcat_digital.webp</link>
    </image>
    <generator>Hugo -- 0.148.1</generator>
    <language>en</language>
    <lastBuildDate>Mon, 06 Jul 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://cloudcat.digital/posts/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Retiring WordPress: a byte-identical migration to Hugo and GitHub Pages</title>
      <link>https://cloudcat.digital/posts/wp_to_hugo_static_migration/</link>
      <pubDate>Mon, 06 Jul 2026 00:00:00 +0000</pubDate>
      <guid>https://cloudcat.digital/posts/wp_to_hugo_static_migration/</guid>
      <description>How we moved a WordPress site off AWS onto Hugo and GitHub Pages without visitors noticing — capture, verify byte-for-byte, cut over DNS, and stop paying for an ALB.</description>
    </item>
    <item>
      <title>System Administrator Appreciation Day</title>
      <link>https://cloudcat.digital/posts/sysadmin_day/</link>
      <pubDate>Fri, 25 Jul 2025 00:00:00 +0000</pubDate>
      <guid>https://cloudcat.digital/posts/sysadmin_day/</guid>
      <description>&lt;p&gt;&lt;img alt=&#34;System Administrator Appreciation Day&#34; loading=&#34;lazy&#34; src=&#34;https://cloudcat.digital/images/System_Administrator_Appreciation_Day.jpg&#34;&gt;&lt;/p&gt;
&lt;p&gt;On the last Friday of July (this year, July 25, 2025), we celebrate System Administrator Appreciation Day to honour these silent guardians of our digital world.&lt;/p&gt;
&lt;p&gt;Sending good vibes and a massive high‑five to all the sudo scientists pulling on‑call rotations and hanging out in those late‑night Slack channels, keeping the world online. You’re the heartbeat of every business out there 😻&lt;/p&gt;
&lt;p&gt;ref: &lt;a href=&#34;https://sysadminday.com/&#34;&gt;https://sysadminday.com/&lt;/a&gt;&lt;/p&gt;</description>
    </item>
    <item>
      <title>Cluster Autoscaler VS Karpenter</title>
      <link>https://cloudcat.digital/posts/autoscaler_vs_karpenter/</link>
      <pubDate>Sun, 26 Jan 2025 00:00:00 +0000</pubDate>
      <guid>https://cloudcat.digital/posts/autoscaler_vs_karpenter/</guid>
      <description>&lt;p&gt;&lt;img alt=&#34;microservices_vs_serverless&#34; loading=&#34;lazy&#34; src=&#34;https://cloudcat.digital/images/microservices_vs_serverless.jpg&#34;&gt;&lt;/p&gt;
&lt;h1 id=&#34;proposal-migration-from-cluster-autoscaler-to-karpenter-for-eks-cluster&#34;&gt;Proposal: Migration from Cluster Autoscaler to Karpenter for EKS Cluster&lt;/h1&gt;
&lt;h2 id=&#34;overview&#34;&gt;Overview&lt;/h2&gt;
&lt;p&gt;The most common approach to scaling Kubernetes clusters in AWS is to use &lt;strong&gt;Cluster Autoscaler (CA)&lt;/strong&gt;, which automatically adjusts the number of nodes based on pod resource requirements. However, CA has limitations when managing mixed-instance Auto Scaling Groups (ASG), leading to inefficiencies in scaling down nodes. To address these issues, we propose migrating to &lt;strong&gt;Karpenter&lt;/strong&gt;, a Kubernetes-based node provisioning solution that offers advanced features like direct EC2 provisioning and customizability.
This document outlines the technical steps, pros and cons, and migration plan for transitioning from &lt;strong&gt;Cluster Autoscaler (CA)&lt;/strong&gt; to &lt;strong&gt;Karpenter&lt;/strong&gt; in an EKS environment. The change aims to address inefficiencies in scaling down mixed-instance Auto Scaling Groups (ASG) and improve provisioning flexibility by leveraging Karpenter’s advanced capabilities.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Building a wordpress-as-a-service platform on AWS with Terraform</title>
      <link>https://cloudcat.digital/posts/aws_hosting_wp/</link>
      <pubDate>Wed, 08 Jan 2025 00:00:00 +0000</pubDate>
      <guid>https://cloudcat.digital/posts/aws_hosting_wp/</guid>
      <description>A practical guide to hosting a PHP blog on AWS using Terraform. Automate infrastructure, manage certificates, secure and scale.</description>
    </item>
    <item>
      <title>Hashicorp Vault Client Optimization</title>
      <link>https://cloudcat.digital/posts/vault_client_optimization/</link>
      <pubDate>Thu, 26 Dec 2024 00:00:00 +0000</pubDate>
      <guid>https://cloudcat.digital/posts/vault_client_optimization/</guid>
      <description>&lt;p&gt;&lt;img alt=&#34;Hashicorp Vault&#34; loading=&#34;lazy&#34; src=&#34;https://cloudcat.digital/images/vault.jpg&#34;&gt;&lt;/p&gt;
&lt;h1 id=&#34;optimizing-vault-costs-with-serviceaccount_name-for-identity-aliases&#34;&gt;Optimizing Vault Costs with &lt;code&gt;serviceaccount_name&lt;/code&gt; for Identity Aliases&lt;/h1&gt;
&lt;p&gt;Hashicorp Vault SaaS bills on client usage, and a client is everything from a user to a machine. More on this &lt;a href=&#34;https://developer.hashicorp.com/vault/docs/concepts/client-count&#34;&gt;here&lt;/a&gt;. The problem is that when a developer removes a chart and redeploys it, vault will count the Kubernetes ServiceAccount as a distinct new app, which isn&amp;rsquo;t quite true, because it&amp;rsquo;s the same app we had before and we were billed for.&lt;/p&gt;</description>
    </item>
    <item>
      <title>A Beginner&#39;s Guide to DNS</title>
      <link>https://cloudcat.digital/posts/domain_name_servers_guide/</link>
      <pubDate>Sun, 26 May 2024 00:00:00 +0000</pubDate>
      <guid>https://cloudcat.digital/posts/domain_name_servers_guide/</guid>
      <description>&lt;p&gt;&lt;img alt=&#34;DNS&#34; loading=&#34;lazy&#34; src=&#34;https://cloudcat.digital/images/dns2.jpg&#34;&gt;&lt;/p&gt;
&lt;h3 id=&#34;a-beginners-guide-to-dns---from-domain-purchase-to-establishing-your-online-presence&#34;&gt;A Beginner&amp;rsquo;s Guide to DNS - From Domain Purchase to Establishing Your Online Presence&lt;/h3&gt;
&lt;h4 id=&#34;the-common-query-what-happens-after-buying-a-domain&#34;&gt;The Common Query: What Happens After Buying a Domain?&lt;/h4&gt;
&lt;p&gt;As an IT professional with a sysadmin background and cloud infrastructure focus, I often get DNS-related
questions from programmers and colleagues who are just starting out with their own websites.
One common confusion that arises post-purchase is about the role and setup of DNS hosting. This post
aims to clarify these concepts, using my own experience with setting up &lt;code&gt;https://cloudcat.digital&lt;/code&gt;
as a practical example.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Integrating Helm Hooks with HashiCorp Vault for Cloud Migrations</title>
      <link>https://cloudcat.digital/posts/helm_hooks_manage_secrets/</link>
      <pubDate>Sun, 12 May 2024 00:00:00 +0000</pubDate>
      <guid>https://cloudcat.digital/posts/helm_hooks_manage_secrets/</guid>
      <description>&lt;p&gt;&lt;img alt=&#34;helm_hooks&#34; loading=&#34;lazy&#34; src=&#34;https://cloudcat.digital/images/helm_hooks.jpg&#34;&gt;&lt;/p&gt;
&lt;h2 id=&#34;managing-secrets-in-kubernetes-with-helm-and-hashicorp-vault&#34;&gt;Managing Secrets in Kubernetes with Helm and HashiCorp Vault&lt;/h2&gt;
&lt;p&gt;In the dynamic landscape of cloud migrations, securely and efficiently managing application
configurations, particularly secrets, is a critical task. This article explores a practical scenario
where an organization is migrating its applications from on-premises infrastructure to Amazon EKS,
using HashiCorp Vault&amp;rsquo;s CSI driver to handle secrets. Here, we&amp;rsquo;ll dive into the challenges and solutions
of using environment variables to access these secrets—a common yet sensitive practice—and provide a
step-by-step guide to implementing robust solutions using Helm hooks.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Embracing Open Container Initiative for Helm Charts</title>
      <link>https://cloudcat.digital/posts/oci_charts/</link>
      <pubDate>Sun, 28 Apr 2024 00:00:00 +0000</pubDate>
      <guid>https://cloudcat.digital/posts/oci_charts/</guid>
      <description>&lt;p&gt;&lt;img alt=&#34;containers&#34; loading=&#34;lazy&#34; src=&#34;https://cloudcat.digital/images/containers.jpg&#34;&gt;&lt;/p&gt;
&lt;h2 id=&#34;a-new-perspective-on-helm-charts&#34;&gt;A New Perspective on Helm Charts&lt;/h2&gt;
&lt;p&gt;Whale hello there (docker pun) DevOps enthusiasts! As someone who&amp;rsquo;s been navigating the waters of
AWS and Helm for years, I&amp;rsquo;ve largely relied on the tried-and-tested methods like ChartMuseum and S3
backends for managing Helm charts. Occasionally, I&amp;rsquo;ve also pulled charts directly from version control
when the stakes weren&amp;rsquo;t too high on audit trails, because it&amp;rsquo;s straightforward and gets the job done
when conditions allow.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Microservices VS Serverless</title>
      <link>https://cloudcat.digital/posts/microservices_vs_serverless/</link>
      <pubDate>Sun, 14 Apr 2024 00:00:00 +0000</pubDate>
      <guid>https://cloudcat.digital/posts/microservices_vs_serverless/</guid>
      <description>&lt;p&gt;&lt;img alt=&#34;microservices_vs_serverless&#34; loading=&#34;lazy&#34; src=&#34;https://cloudcat.digital/images/microservices_vs_serverless.jpg&#34;&gt;&lt;/p&gt;
&lt;p&gt;In the dynamic world of software architecture, the debate between microservices and serverless
functions (like AWS Lambda) is similar to the classic face-off between Ryu and Ken in the Street Fighter
world. Both have their strengths, their unique moves, and their situational advantages.
As developers, we&amp;rsquo;re often in the position to make a choice between the two, so let&amp;rsquo;s break down
the details in a clear, concise, and human manner.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Making Caching Work for You in CI</title>
      <link>https://cloudcat.digital/posts/github_self_hosted_caching/</link>
      <pubDate>Thu, 14 Mar 2024 00:00:00 +0000</pubDate>
      <guid>https://cloudcat.digital/posts/github_self_hosted_caching/</guid>
      <description>&lt;p&gt;&lt;img alt=&#34;fast_cat&#34; loading=&#34;lazy&#34; src=&#34;https://cloudcat.digital/images/cheetah.webp&#34;&gt;&lt;/p&gt;
&lt;h2 id=&#34;a-practical-guide-for-github-self-hosted-runners&#34;&gt;A Practical Guide for GitHub Self-Hosted Runners&lt;/h2&gt;
&lt;p&gt;Hey everyone, today let&amp;rsquo;s talk about something that can make a real difference in your CI pipelines:
effective caching. If you&amp;rsquo;ve been following along, you know we&amp;rsquo;ve explored using Docker registry mirror
before. In our last post, we talked about the context and challenge of CI cache in a dynamic and fully
scalable environment. Since our setup is like a revolving door with nodes coming and going based on
demand, holding onto a Docker cache is like trying to catch smoke with your bare hands.
So, when it comes to GitHub Actions self-hosted on EKS, especially with &lt;a href=&#34;https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/deploying-runner-scale-sets-with-actions-runner-controller&#34;&gt;scale sets&lt;/a&gt;,
caching needs a bit more attention.&lt;/p&gt;</description>
    </item>
    <item>
      <title>GitHub Actions, self-hosted runners with Scale-Sets tips and tricks</title>
      <link>https://cloudcat.digital/posts/github_self_hosted_dind/</link>
      <pubDate>Thu, 29 Feb 2024 00:00:00 +0000</pubDate>
      <guid>https://cloudcat.digital/posts/github_self_hosted_dind/</guid>
      <description>&lt;p&gt;&lt;img alt=&#34;gh actions on k8s&#34; loading=&#34;lazy&#34; src=&#34;https://cloudcat.digital/images/steamboat_willie.jpg&#34;&gt;&lt;/p&gt;
&lt;p&gt;As someone who&amp;rsquo;s spent a fair bit of time tinkering with CI/CD pipelines and automating infrastructure,
I&amp;rsquo;ve really started to see the value in GitHub Actions, particularly after moving away from Jenkins.
My journey took an exciting turn when I began experimenting with self-hosted GitHub Actions runners
on Kubernetes, using the summerwinds actions runner controller. Things got even more interesting when
I shifted to &lt;a href=&#34;https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/deploying-runner-scale-sets-with-actions-runner-controller&#34;&gt;scale-sets&lt;/a&gt;,
thanks to GitHub embracing the ARC project.&lt;/p&gt;</description>
    </item>
    <item>
      <title>DevOps and DevOps Accessories</title>
      <link>https://cloudcat.digital/posts/devops_and_accessories/</link>
      <pubDate>Sat, 10 Feb 2024 00:00:00 +0000</pubDate>
      <guid>https://cloudcat.digital/posts/devops_and_accessories/</guid>
      <description>&lt;p&gt;&lt;img alt=&#34;Hank Hill from King of the hill&#34; loading=&#34;lazy&#34; src=&#34;https://cloudcat.digital/images/hank_hill_propane.jpg&#34;&gt;&lt;/p&gt;
&lt;p&gt;Remember Hank Hill from &amp;ldquo;King of the Hill&amp;rdquo;? He was all about propane and propane accessories.
That&amp;rsquo;s kind of like me but with DevOps instead. And like Hank&amp;rsquo;s, my passion with computers started
in my childhood, in the &amp;rsquo;90s, a time when they were not just scarce but symbolized a window to a
whole new world for me. The first time I encountered a Commodore-like PC sparked a whole new level
of excitement and my fascination only grew as I discovered the magic of graphics and network
capabilities.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
