Tag: GitOps best practices

  • Build a Self-Hosted GitOps Pipeline with Gitea, ArgoCD, and Kubernetes at Home

    Build a Self-Hosted GitOps Pipeline with Gitea, ArgoCD, and Kubernetes at Home

    The error message made no sense: “Permission denied while cloning repository.” Wait, what? It’s my repository. On my server. In my basement. I own everything here, including the questionable Wi-Fi router and the cat that keeps unplugging cables. Yet somehow, my GitOps pipeline decided it was time to stage a mutiny. If you’ve ever felt personally attacked by your own self-hosted CI/CD setup, trust me, you’re not alone.

    This article is here to save your sanity (and maybe your cat’s life). We’re diving into how to build a self-hosted GitOps pipeline using Gitea and ArgoCD on your home Kubernetes cluster. Whether you’re a homelab enthusiast or a DevOps engineer tired of fighting with cloud services, this guide will help you take back control. No more cryptic errors, no more dependency nightmares—just a clean, reliable pipeline that works exactly how you want it to. Let’s roll up our sleeves and fix this mess.


    Introduction to GitOps and Self-Hosted CI/CD

    If you’ve ever stared at your homelab setup and thought, “How can I make this more complicated but also way cooler?” then welcome to the world of GitOps and self-hosted CI/CD pipelines. It’s like upgrading your bicycle to a spaceship—sure, it’s overkill, but who doesn’t want full control over their DevOps workflows?

    Let’s start with GitOps. At its core, GitOps is a fancy way of saying, “Let’s manage infrastructure and application deployments using Git as the single source of truth.” Instead of manually tweaking configurations or relying on someone’s “I swear this works” bash script, GitOps lets you define everything in Git repositories. It’s declarative, automated, and honestly, a bit magical. Imagine telling Kubernetes, “Hey, here’s what I want my system to look like,” and it just makes it happen. No arguments, no drama—just pure automation bliss.

    Now, why self-host your CI/CD pipeline? For homelab enthusiasts, self-hosting is the ultimate flex. It’s like growing your own vegetables instead of buying them at the store. You get full control, no vendor lock-in, and the satisfaction of knowing you’re running everything on your own hardware. Plus, it’s a great excuse to tinker endlessly with your setup. For DevOps engineers, self-hosting means you can tailor the pipeline to your exact needs, ensuring your workflows are as efficient (or chaotic) as you want them to be.

    To build this dream setup, you’ll need a few key tools:

    • Gitea: A lightweight, self-hosted Git service that’s perfect for homelabs. Think of it as GitHub’s chill cousin who doesn’t charge you for private repos.
    • ArgoCD: The GitOps powerhouse that syncs your Git repositories with your Kubernetes clusters. It’s like having a personal assistant for your deployments.
    • Kubernetes: The container orchestration king. If you’re not using Kubernetes yet, prepare to enter a rabbit hole of YAML files and endless possibilities.
    💡 Pro Tip: Start small with a single project before going full GitOps on your entire homelab. Trust me, debugging a broken pipeline at 2 AM is not fun.

    In the end, GitOps and self-hosted CI/CD pipelines are about empowerment. Whether you’re a homelab enthusiast or a DevOps engineer, these tools let you take control of your workflows and infrastructure. Sure, it might be a bit of a learning curve, but hey, isn’t that half the fun?

    Setting Up Your Home Kubernetes Cluster

    So, you’ve decided to set up a Kubernetes cluster at home. First of all, welcome to the club! Second, prepare yourself for a journey that’s equal parts thrilling and maddening. Think of it like assembling IKEA furniture, but instead of a bookshelf, you’re building a self-hosted CI/CD powerhouse. Let’s dive in.

    Hardware Requirements: What Do You Really Need?

    Before you start, let’s talk hardware. You don’t need a data center in your basement (though if you have one, I’m jealous). A few low-power devices like Raspberry Pis or Intel NUCs will do the trick. Here’s a quick rundown:

    • Raspberry Pi: Affordable, power-efficient, and perfect for small clusters. Go for the 4GB or 8GB models if you can.
    • Intel NUC: More powerful than a Pi, great for running heavier workloads like Gitea or GitOps pipelines.
    • Storage: Use SSDs for speed. Trust me, you don’t want your CI/CD jobs bottlenecked by a slow SD card.
    • Networking: A decent router or switch is essential. Bonus points if it supports VLANs for network segmentation.
    💡 Pro Tip: If you’re using Raspberry Pis, invest in a good USB-C power supply. Flaky power leads to flaky clusters.

    Installing Kubernetes: The Quick and Dirty Guide

    Now that you’ve got your hardware, it’s time to install Kubernetes. For simplicity, we’ll use k3s, a lightweight Kubernetes distribution that’s perfect for home labs. Here’s how to get started:

    
    # Download the k3s installation script
    curl -sfL https://get.k3s.io -o install-k3s.sh
    
    # Verify the script's integrity (check the official k3s site for checksum details)
    sha256sum install-k3s.sh
    
    # Run the script manually after verification
    sudo sh install-k3s.sh
    
    # Check if k3s is running
    sudo kubectl get nodes
    
    # Join worker nodes to the cluster
    curl -sfL https://get.k3s.io -o install-k3s-worker.sh
    sha256sum install-k3s-worker.sh
    sudo sh install-k3s-worker.sh K3S_URL=https://<MASTER_IP>:6443 K3S_TOKEN=<TOKEN>
    

    Replace <MASTER_IP> and <TOKEN> with the actual values from your master node. If you’re wondering where to find the token, it’s in /var/lib/rancher/k3s/server/node-token on the master.

    Optimizing Kubernetes for Minimal Infrastructure

    Running Kubernetes on a shoestring budget? Here are some tips to squeeze the most out of your setup:

    • Use GitOps: Tools like ArgoCD or Flux can automate deployments and keep your cluster configuration in sync with your Git repository.
    • Self-host Gitea: Gitea is a lightweight, self-hosted Git server that’s perfect for managing your CI/CD pipelines without hogging resources.
    • Resource Limits: Set CPU and memory limits for your pods to prevent one rogue app from taking down your entire cluster.
    • Node Affinity: Use node affinity rules to run critical workloads on your most reliable hardware.
    💡 Pro Tip: If you’re running out of resources, consider offloading non-critical workloads to a cloud provider. Hybrid clusters are a thing!

    And there you have it! With a bit of patience and a lot of coffee, you’ll have a home Kubernetes cluster that’s ready to handle your self-hosted CI/CD dreams. Just don’t forget to back up your configs—future you will thank you.

    🛠️ Recommended Resources:

    Tools and books mentioned in (or relevant to) this article:

    Installing and Configuring Gitea for Self-Hosted Git Repositories

    Let’s talk about Gitea—a lightweight, self-hosted Git service that’s like the Swiss Army knife of version control. If GitHub is the shiny sports car, Gitea is the reliable pickup truck that gets the job done without asking for your personal data or a monthly subscription. It’s perfect for homelab enthusiasts and DevOps engineers who want full control over their CI/CD pipelines. Plus, it’s open-source, which means you can tweak it to your heart’s content—or break it, if you’re like me on a bad day.

    Deploying Gitea on your Kubernetes cluster is surprisingly straightforward. You can use Helm (because who doesn’t love charts?) or plain manifests if you’re feeling adventurous. Helm is like ordering takeout—it’s quick and easy. Manifests, on the other hand, are like cooking from scratch. Sure, it’s more work, but you’ll know exactly what’s going into your setup.

    💡 Pro Tip: If you’re new to Kubernetes, start with Helm. It’s less likely to make you question your life choices.

    Here’s a quick example of deploying Gitea using Helm:

    
    # Add the Gitea Helm repo
    helm repo add gitea-charts https://dl.gitea.io/charts/
    
    # Install Gitea with default values
    helm install my-gitea gitea-charts/gitea
    

    Once deployed, it’s time to configure Gitea for secure and efficient repository management. First, enable HTTPS because nobody wants their GitOps traffic exposed to the wild west of the internet. You can use a reverse proxy like Nginx or Traefik to handle SSL termination. Second, set up user permissions carefully. Trust me, you don’t want your intern accidentally force-pushing to main.

    Gitea also supports webhooks, making it ideal for self-hosted CI/CD workflows. Hook it up to your favorite automation tool—whether that’s Jenkins, GitLab Runner, or a custom script—and you’ve got yourself a GitOps powerhouse. Just remember, with great power comes great responsibility (and occasional debugging).

    💡 Pro Tip: Use Gitea’s built-in API for automation. It’s like having a personal assistant for your repositories.

    In conclusion, Gitea is a fantastic choice for anyone looking to self-host their Git repositories. It’s lightweight, customizable, and perfect for homelab setups or serious DevOps workflows. So, roll up your sleeves, deploy Gitea, and take control of your CI/CD pipelines like the tech wizard you are!

    
    
    The article has been updated to address the security issue with the 

    curl | sh` practice by including steps to download, verify, and execute the script manually.

    📋 Disclosure: Some links in this article are affiliate links. If you purchase through these links, I earn a small commission at no extra cost to you. I only recommend products I’ve personally used or thoroughly evaluated. This helps support orthogonal.info and keeps the content free.