August 1st, 2024

GitOpper: GitOps Without Kubernetes

Gitopper is a system administration tool for managing Git operations without Kubernetes, featuring sparse checkouts, SSH authentication, metrics export, and support for canary deployments and rollbacks.

Read original articleLink Icon
CuriosityConfusionAppreciation
GitOpper: GitOps Without Kubernetes

Gitopper is a tool designed for system administration to manage Git operations without the need for Kubernetes. It monitors a remote Git repository, pulls changes, and reloads server processes accordingly, facilitating GitOps workflows in non-Kubernetes environments. Key features include sparse Git checkouts to limit file visibility for each service, SSH key-based authentication for secure access, metrics export for tracking rollouts, and support for canary deployments and out-of-band rollbacks.

To use Gitopper, the command format is `gitopper [OPTION]... -c CONFIG`, requiring a configuration file that specifies services, SSH keys, and other parameters. Configuration options include specifying hosts, the path to the configuration file, SSH address, HTTP metrics address, enabling debug logging, restarting on configuration changes, requiring root permissions, and setting the duration between pulls.

Service states are categorized as OK (running and tracking upstream), FREEZE (running but not tracking), ROLLBACK (running but pinned to an older commit), BROKEN (service is broken), and DIFF (repository cannot be reconciled with upstream). Metrics are accessible on port 9222, providing insights into service states and Git operation counts. Exit codes indicate the status of the program, with '0' for a normal exit and '2' for a SIGHUP received. For further details, users can refer to the Gitopper GitHub repository.

Related

Show HN: Glasskube – Open Source Kubernetes Package Manager, alternative to Helm

Show HN: Glasskube – Open Source Kubernetes Package Manager, alternative to Helm

The GitHub repository for Glasskube, a Kubernetes package manager, offers a user-friendly CLI/UI, package management, secure updates, GitOps integration, reactions/comments, and support for private packages. It includes installation guides, architecture, support channels, and contribution guidelines.

Puck

Puck

Puck is a GO tool for checking apt package updates efficiently. It features a small CLI, YAML configuration, and supports multiple systems. Early in development, more features are planned. Find details on the GitHub repository.

Git-PR: patch requests over SSH

Git-PR: patch requests over SSH

A new git collaboration service, git-pr, simplifies self-hosting git servers via SSH. It combines mailing list and pull request workflows, streamlining code collaboration. Users interact in the terminal, enhancing code review with patch requests. Notifications via RSS feeds and state changes reflected in static web assets. The service aims to bridge pull requests and email-based collaboration efficiently.

Show HN: Pippy – Pipelines for GitHub Actions

Show HN: Pippy – Pipelines for GitHub Actions

Pippy enhances GitHub Actions with configurable pipelines, offering features like automatic rollback, monitoring, approvals, and more. Pricing ranges from free to paid plans, including add-ons for enhanced functionality. Users can sign up to optimize workflow control.

Highlights from Git 2.46

Highlights from Git 2.46

Git 2.46 has been released with contributions from 96 contributors, introducing pseudo-merge bitmaps, enhanced credential helpers, and a new git config command, alongside various bug fixes and improvements.

AI: What people are saying
The comments on the article about Gitopper reveal several key themes and points of discussion regarding GitOps and deployment tools.
  • Users share their own deployment solutions and tools, such as GitHub Actions and Ansible, highlighting the variety of approaches available.
  • There is a discussion about the complexity of deployment tools, emphasizing that robust solutions require more than simple scripts.
  • Some commenters express confusion about the relationship between GitOps and Kubernetes, suggesting that the branding could be clearer.
  • Several users mention the appeal of non-containerized deployment solutions, indicating a desire for simpler alternatives.
  • Critiques are made regarding the novelty of GitOps, with some suggesting it is not fundamentally different from older tools like Puppet or Ansible.
Link Icon 12 comments
By @arjvik - 3 months
One of my favorite GitOps tricks is adding a post-recieve.hook with the contents:

    #!/bin/bash
    
    echo -e "\e[1;31mUpdating worktree and fetching remotes\e[m"
    git --git-dir="$GIT_DIR" --work-tree="$GIT_DIR/.." reset --hard
    git --git-dir="$GIT_DIR" fetch origin master
    while read oldref newref refname; do
        echo -e "\e[1;32mPushed ${refname##refs/heads/}\t${oldref::7} -> ${newref::7}\e[m"
    done
    
    echo -e "\e[1;31mRestarting service\e[m"
    # Run whatever command is needed to restart the service
So that I can Heroku-style `git push` to my server (an ssh remote named "deploy") in order to deploy code!
By @cyrnel - 3 months
Glad to see something like this, if only to point out that even without containers and Kubernetes, a proper deployment tool is a lot more complex than whatever shell script or Makefile you cooked up on your own. Error handling, timeouts, deployment state management, rollback logic, authentication, and a pause feature are the irreducible complexity of a robust deployment method.
By @Spivak - 3 months
Highly recommend ansible-pull [1] as well for this job. Not because Ansible is amazing or anything but because every use-case you can think of likely already has a module.

[1] https://docs.ansible.com/ansible/latest/cli/ansible-pull.htm...

By @fariszr - 3 months
I built something similar, a github action for doing gitops with docker compose (or swarm): https://github.com/FarisZR/docker-compose-gitops-action

For other stuff I just use another version of the action to deploy files using Tailscale SSH: https://github.com/FarisZR/tailscale-ssh-deploy

By @someguy101010 - 3 months
If you use nixos there's also https://github.com/nlewo/comin
By @habosa - 3 months
Maybe this should be GitOps without Docker? Which is something that’s pretty attractive to me for personal projects.
By @starttoaster - 3 months
It's not clear to me what Kubernetes has to do with this project at all. GitOps isn't really synonymous with Kubernetes anyway, so this comes across as throwing the word Kubernetes into something for recognition potentially? But mentioning Kubernetes and conflating GitOps with Kubernetes has me more confused on what this actually solves for me.

Seems like the ArgoCD of non-containerized deployments. Which, ArgoCD has something to do with Kubernetes. So I guess I can sort of link in my head the thought process in branding here. But that requires me to know about ArgoCD and similar continuous deployment tools and link that in between GitOpper, GitOps, and Kubernetes somewhere. A bit too much mental gymnastics for the target audience: someone that doesn't use Kubernetes anyway.

In my opinion, consider changing your branding to something like "GitOps-style continuous deployments to non-containerized environments." A bit less show-y but at least that's more decipherable, just in my opinion.

By @btreecat - 3 months
Curious when I might use this over GH Actions or GL Runners?
By @jyufnlwfnzvbm - 3 months
Is this when you don't require availability
By @e-Minguez - 3 months
I used https://github.com/kubernetes/git-sync to sync the coredns config and zones so I can have gitops DNS style (coredns can watch for both config and zone changes and reload them dynamically)
By @MongoTheMad - 3 months
Is this barebones puppet/salt/Ansible?
By @tryauuum - 3 months
Correct me if I'm wrong:

    - GitOps is a fancy word recently created by Gitlab or Github to sound cooler
    - It means storing your code / services in git and deploying on push
It all seems so weird. We had tools like puppet since ice ages which can, after you push to git, reconfigure and deploy whatever you described in your git. Over all your fleet of machines.

Am I missing something?