Live data from Hacker News

GitOpper: GitOps Without Kubernetes

github.com

31–40 of 51 posts

Re: GitOpper: GitOps Without Kubernetes

#31

Earlier quoted context omitted.

When I started out with Kubernetes Gitops hadn't really gained any momentum. We just used normal CI/CD pipeline tooling. For our own apps the pipeline simply built the docker image, pushed it, and then ran kubectl apply. No manual labour, no magic. For third party stuff (like helm charts for ELK or whatever) it was the same but with helm cli/kubectl, without building the image. I don't know why really, but gitops hav…

Isn't what you did also gitOps, except that it's push based and not pull based?

What's really a True Scotsman? But I wouldn't really say so, no. I think [0] represent what I would consider a gitops pushed based approach, the way we did it differed in two main ways:

- (1) We didn't have any "environment repository". The manifest files were in the same repository as the application code

- (2) Perhaps more importantly: The manifest files did not _exactly_ represent what was deployed. We had a template-variable in the Deployment yaml file, where the Github action substituted the tag that had just been built. To see which version was deployed you either had to look in the cluster, or the Github Action logs.

[0]: https://www.gitops.tech/#push-based-deployments

Re: GitOpper: GitOps Without Kubernetes

#32
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?

Re: GitOpper: GitOps Without Kubernetes

#34

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?

You aren't missing anything. It's just marketing so GitHub/Gitlab stay in the main conversation when DevOps comes up.

Re: GitOpper: GitOps Without Kubernetes

#35

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?

To be specific GitOps covers the Ops/DevOps around git. So MRs / RBAC for git all the way through CI to CD. I've seen some stretch it to cover VDI equivalents as well.

Basically large orgs ditched all their ops people a while ago to focus on integrated teams, and now its marketable to seperate it out again a new set of terms have come round to help orgs pretend they didn't make mistakes.

The term DevSecOps really grinds my gears, gitops I'm more ok with, but still...

Re: GitOpper: GitOps Without Kubernetes

#36

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?

[deleted]

Re: GitOpper: GitOps Without Kubernetes

#37

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?

To be specific GitOps covers the Ops/DevOps around git. So MRs / RBAC for git all the way through CI to CD. I've seen some stretch it to cover VDI equivalents as well. Basically large orgs ditched all their ops people a while ago to focus on integrated teams, and now its marketable to seperate it out again a new set of terms have come round to help orgs pretend they didn't make mistakes. The term DevSecOps really gri…

[flagged]

Re: GitOpper: GitOps Without Kubernetes

#38

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?

You're half wrong. The term was invented by Weaveworks, a company which no longer exists, but it's main product, FluxCD and the GitOps toolkit it is based on, lives on as a CNCF project. There never was and still is not any requirement that you use Github or Gitlab as your Git server to use this or any other GitOps product I'm aware of.

I guess you're more 75% wrong because the second statement is still half wrong. Depending on the product you're using, it can work via webhook if the Git server supports doing that, but predominantly GitOps tooling relies upon polling, so you won't necessarily get a deployment immediately going a git push. You'll get it whenever the next poll happens.

Also, FluxCD was created specifically for Kubernetes, which is why a product announcement like this is worded the way it is. It worked by storing Kubernetes custom resource manifests in a Git repo, typically for Helm charts or Kustomize "kustomization" definitions. Roughly the entire point of this was bringing Kubernetes conventions up to par with what was already common for deployment with configuration management tooling that relied upon server-stored configuration as code. I don't think Weaveworks or anyone else involved was under the impression they were the first to ever have this idea. But I also don't believe (but admittedly don't know) that it was particularly easy in 2017 to use Puppet to manage application deployments in Kubernetes. FluxCD also runs in Kubernetes itself, so you don't need any external infrastructure to do this.

Maybe this makes it less weird? Multi-container orchestration nearly a decade ago was a fairly immature ecosystem, so they adopted ideas from configuration management of server fleets. Not all change in the world is greenfield innovation that comes absolutely out of nowhere.

Re: GitOpper: GitOps Without Kubernetes

#39
post #8

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…

I found this odd too. It reminded me of a book I read ages ago, sci-fi fantasy where there is a species that is very long-lived but they have a finite memory. Maybe if your memory is a year or two long then GitOps would seem to mean k8s deployments automatically out of git, rather than all the other things. (I think it was by C.S Friedman but I don't remember which one)

Perhaps you are thinking of the My Little Pony fanfiction "Alicorn Time" by author AlicornPriest. https://www.fimfiction.net/story/298141/alicorn-time

Re: GitOpper: GitOps Without Kubernetes

#40
post #13

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.

Ehh, I think the capistrano model of deployments is a pretty good 'bare minimum' of features without tooling. Basically, just use a rolling symlink of timestamped deploys:

  releases/
    release-2024-01-01
    release-2024-01-02
    release-2024-01-07
  current -> releases/release-2024-01-07
Make a new one on a new deploy, and only update the symlink on success. Rollback is changing the symlink. Pause is just cancelling the scp. Auth is just linux accounts. Its a simple model.
Post reply on HN