<?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 DevOps &amp; Rock&#39;N&#39;Roll</title>
    <link>https://artazar.pages.dev/tags/gitops/</link>
    <description>Recent content in Gitops on DevOps &amp; Rock&#39;N&#39;Roll</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Wed, 19 Aug 2026 15:55:02 +0700</lastBuildDate>
    <atom:link href="https://artazar.pages.dev/tags/gitops/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Wrapping Kyverno policies into a chart you can actually tune</title>
      <link>https://artazar.pages.dev/blog/12-kyverno-policies-helm-chart/</link>
      <pubDate>Tue, 07 Jul 2026 00:08:30 +0000</pubDate>
      <guid>https://artazar.pages.dev/blog/12-kyverno-policies-helm-chart/</guid>
      <description>&lt;p&gt;Kyverno&amp;rsquo;s policy library is excellent and you should read it. It is also a directory of static YAML files, which means adopting it looks like copying twenty ClusterPolicy manifests into your GitOps repo and then editing them by hand, per cluster, forever.&lt;/p&gt;&#xA;&lt;p&gt;That works until the second cluster. Dev wants &lt;code&gt;audit&lt;/code&gt; where prod wants &lt;code&gt;enforce&lt;/code&gt;. The infra cluster needs the CRI socket policy relaxed because your monitoring agent legitimately mounts it. A new namespace needs to be excluded from the Flux label requirement. Each of these is a one-line change to a file that&amp;rsquo;s now duplicated across three repositories, and none of them are visible from a single place.&lt;/p&gt;</description>
    </item>
    <item>
      <title>A FluxCD repo layout that survives forty applications</title>
      <link>https://artazar.pages.dev/blog/08-fluxcd-repo-layout/</link>
      <pubDate>Tue, 05 May 2026 00:08:30 +0000</pubDate>
      <guid>https://artazar.pages.dev/blog/08-fluxcd-repo-layout/</guid>
      <description>&lt;p&gt;Every GitOps repository starts beautiful. One cluster, five apps, a flat &lt;code&gt;apps/&lt;/code&gt; directory, and a Kustomization that reconciles the lot. Then the second cluster appears. Then staging needs a different replica count. Then somebody needs their own namespace with their own RBAC and no access to anyone else&amp;rsquo;s. Six months later you are grepping through forty &lt;code&gt;kustomization.yaml&lt;/code&gt; files trying to work out why a change to a shared ConfigMap took down two environments.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Yet another Vault story</title>
      <link>https://artazar.pages.dev/blog/03-vault-my-experience/</link>
      <pubDate>Fri, 06 Oct 2023 00:08:30 +0000</pubDate>
      <guid>https://artazar.pages.dev/blog/03-vault-my-experience/</guid>
      <description>&lt;p&gt;One can find a million blog posts about various aspects of using Hashicorp Vault, this solution has truly received massive adoption. So now you don&amp;rsquo;t even question what you&amp;rsquo;re going to use as secrets storage, but the matter is more of &amp;ldquo;how&amp;rdquo;.&lt;/p&gt;&#xA;&lt;p&gt;Being a complete and inveterate gitops&amp;rsquo;er, one of my primary objectives is to store as much as I can in Git and to deploy that into Kubernetes. This brought me to the BanzaiCloud Bank Vaults solution bundle that allows you to achieve exactly this. It provides the ability to configure Vault as a Custom Resource and store all its primary settings on a repository. This is not very far from the official Helm chart deployment with their values, but BanzaiCloud give you a bit more:&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
