<?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>Gitops on Eliorion blog</title><link>https://eliorion.github.io/My-blog/tags/gitops/</link><description>Recent content in Gitops on Eliorion blog</description><generator>Hugo</generator><language>en</language><lastBuildDate>Wed, 27 May 2026 09:00:00 +0200</lastBuildDate><atom:link href="https://eliorion.github.io/My-blog/tags/gitops/index.xml" rel="self" type="application/rss+xml"/><item><title>Secrets in Git Without Fear: SOPS + AGE</title><link>https://eliorion.github.io/My-blog/11---posts/2026-05-27---mve-itguard-secrets/</link><pubDate>Wed, 27 May 2026 09:00:00 +0200</pubDate><guid>https://eliorion.github.io/My-blog/11---posts/2026-05-27---mve-itguard-secrets/</guid><description>&lt;h2 id="the-problem-every-project-has"&gt;The Problem Every Project Has&lt;/h2&gt;
&lt;p&gt;Every project that deploys to a real server has secrets. Tokens, passwords, API keys — values that should not be publicly visible but that the application needs to run.&lt;/p&gt;
&lt;p&gt;The GitOps approach makes this harder to ignore. If Git is the single source of truth and all configuration lives in the repository, where do the secrets go? Committing them in plaintext is an obvious mistake. Leaving them outside Git means the repository is no longer the complete source of truth — some knowledge lives only in someone&amp;rsquo;s head or in a separate system.&lt;/p&gt;</description></item><item><title>GitOps Without Kubernetes: Docker Compose + GitHub Actions</title><link>https://eliorion.github.io/My-blog/11---posts/2026-05-25---mve-itguard-gitops/</link><pubDate>Mon, 25 May 2026 09:00:00 +0200</pubDate><guid>https://eliorion.github.io/My-blog/11---posts/2026-05-25---mve-itguard-gitops/</guid><description>&lt;h2 id="gitops-is-a-principle-not-a-tool"&gt;GitOps Is a Principle, Not a Tool&lt;/h2&gt;
&lt;p&gt;When people talk about GitOps, Kubernetes quickly enters the conversation. FluxCD, ArgoCD, Helm — the ecosystem is rich, and the tooling handles a lot of the heavy lifting. The platform continuously watches the repository and reconciles the cluster state to match what Git declares.&lt;/p&gt;
&lt;p&gt;But the underlying principle has nothing to do with Kubernetes specifically. GitOps is simpler than that: &lt;strong&gt;Git is the single source of truth. No change happens outside of Git. Automation applies what Git declares.&lt;/strong&gt;&lt;/p&gt;</description></item><item><title>First GitOps implementation</title><link>https://eliorion.github.io/My-blog/11---posts/2026-02-26---first-gitops-implementation/</link><pubDate>Wed, 04 Mar 2026 09:38:10 +0100</pubDate><guid>https://eliorion.github.io/My-blog/11---posts/2026-02-26---first-gitops-implementation/</guid><description>&lt;h2 id="kubecraft-course"&gt;&lt;strong&gt;KubeCraft Course&lt;/strong&gt;&lt;/h2&gt;
&lt;p&gt;After completing the first Kubernetes course, where I deployed a basic K3s cluster on Rancher Desktop, I moved to the next level: a homelab course focused on building a fully GitOps-based K3s cluster on a Debian VM, hosting real self-hosted applications exposed to the internet.&lt;/p&gt;
&lt;h3 id="what-to-expect-at-the-end"&gt;&lt;strong&gt;What to Expect at the End?&lt;/strong&gt;&lt;/h3&gt;
&lt;p&gt;The final goal is to deploy a self-hosted &lt;strong&gt;Linkding&lt;/strong&gt; application accessible from the internet using a custom domain name.&lt;/p&gt;</description></item></channel></rss>