Konubinix' opinionated web of thoughts

Gitops

Fleeting

Like IaC, but for everything related to ops.

With gitops, the infrastructure reflects what is in git. Therefore, you have the history/control/diff of your infrastructure with zero cost.

You have a code repository within which the dev can do whatever they want. Then, you have the ops repository with much more control. There can be automated PR from the CI of the dev repository to the ops repository, but manual control is often preferred.

It is one implementation of devops, where a SCM is the sole interface between dev and ops (see the misconception of making the dev and ops know all the things of DEV + OPS).

using Git as the single source of truth for system state

— https://www.harness.io/blog/gitops

all of it should come from the central plane of source control

— https://www.harness.io/blog/gitops

d’une bonne pratique DevOps qui s’appuie sur Git en tant que source de référence unique et que mécanisme de contrôle pour créer, mettre à jour et supprimer l’architecture du système

— https://www.atlassian.com/fr/git/tutorials/gitops

pratique consistant à utiliser les pull requests Git pour vérifier et déployer automatiquement les modifications de l’infrastructure système

— https://www.atlassian.com/fr/git/tutorials/gitops

takes DevOps best practices used for application development such as version control, collaboration, compliance, and CI/CD, and applies them to infrastructure automation

— https://about.gitlab.com/topics/gitops/

GitOps is not a single product, plugin, or platform. There is no one-size-fits-all answer to this question, as the best way for teams to put GitOps into practice will vary depending on the specific needs and goals of the team

— https://about.gitlab.com/topics/gitops/

using a dedicated GitOps repository for all team members to share configurations and code

— https://about.gitlab.com/topics/gitops/

automating the deployment of code changes

— https://about.gitlab.com/topics/gitops/

setting up alerts to notify the team when changes occur

— https://about.gitlab.com/topics/gitops/

When new code is merged, the CI/CD pipeline enacts the change in the environment

— https://about.gitlab.com/topics/gitops/

GitOps repose sur l’utilisation de référentiels Git comme unique source de vérité pour distribuer l’infrastructure en tant que code

— https://www.redhat.com/fr/topics/devops/what-is-gitops

remove the configuration drift

push based or pull based?

In ALL the videos I have watched about gitops, they indicated that the main source of configuration drift is when someone gets into the system and makes some changes manually.

They indicate that this explains the need to have a pull based model, that will restore the system automatically without waiting for the next CI trigger to run.

Yet, I think that if the ops can easily reproducibly run the push based command, they would be nudged into using it rather than going and fixing stuff live.

To me, the incentive to modify the env in live is a symptom of the ci automation drift and should be addressed instead of adding a tool to hide it.

Doing so, the person running the command should still think about pushing per change. Right? So that makes the pull model more secure?

I don’t think so. If someone went to the prod to fix something manually, I think that this person would not accept that the fix would be reverted automatically after 3 minutes and therefore the fix reverted as well. In that case, it seems sensible to bet that this person will also disable the pull based automation. Thus, to be honest we should consider that this person has the same probabilities of forgetting to enable the pull based flow that the one that forgot to push per changes in the previous example.

In that case, forgetting to push the fix won’t disable the automatic flow, while in the pull based flow, someone would need to explicitly check and realize that it was disabled.

Also, in the push based flow scenario, the person doing the fix would be more likely to see the dirty git status and push per change in the future, whereas in the pull based scenario no trace of this change would remain.

In conclusion, I think that we tend to overestimate the value in the pull based model and underestimate the one of the push based one. Both are great and have great advantages and the awesome aspects of the pull based flow should not shadow the great aspects of the push based one.

deal with secrets

sealed secrets

generates a (private key/public key) in the production cluster. You have to export the public key to encrypt the secrets in the git repository.

Cloud Native Live: Crossplane - GitOps-based Infrastructure as Code through Kubernetes API - YouTube

  • External reference:

    talks about the fact that gitops is mostly about using git and only git as single interface (and source of truth) for all ops related stuff.

    He uses crossplane to specify the whole infrastructure in kubernetes manifest. The stuff we could write in terraform and run manually can be declared as CRD in kubernetes, automatically synced using argo CD from a git repository and automatically applied using crossplane.

with kubernetes

storing manifests in git is not enough to claim doing gitopsh

one repo for deploy and dev

Demonstrations show gitops with argo CD in a way that supposedly show its advantages.

But what I see is a new automatic commit for every push in the main branch, which is less than ideal.

To me, this makes sense when they the main branch contains only the commits to deploy, or if this repository is not dedicated to dev. Otherwise, the dev commits will be drawn in the noise of automatic commits.

difference between dev repo and deploy repo

Some resources make clearer that there are two kinds of repos with different commit habits and merge rules

By listening to those, I understand that that gitops is about having one git repository as database for storing the desired state of the ops, because git has the characteristics that we like : auditability, fine control, immutability, easy to rollback.

gitops tools are focused on looking at this git repository and applying this desired state. It is like real time infrastructure as code.

To do so, we need a separate deploy repository, because security rules, the use of the commit history (a lot of automatic commits in the deploy repo) will not be the same at all.

Using the same repository for both will most likely pollute the dev repository with a lot of automatic commit and make it barely readable.

Notes linking here