21–30 of 51 posts
Is this when you don't require availability
Is this when you don't require availability
You may or may not be joking, but gitops has been the cause of outages for us in quite a few instances. I have been unable to stress what a terrible idea arbitrarily pulling and applying from git is. I am unable to stress it because that's the overwhelming way that many k8s setups are done, so clearly they cannot be wrong.
For other stuff I just use another version of the action to deploy files using Tailscale SSH: https://github.com/FarisZR/tailscale-ssh-deploy
Is this when you don't require availability
You may or may not be joking, but gitops has been the cause of outages for us in quite a few instances. I have been unable to stress what a terrible idea arbitrarily pulling and applying from git is. I am unable to stress it because that's the overwhelming way that many k8s setups are done, so clearly they cannot be wrong.
Is this when you don't require availability
You may or may not be joking, but gitops has been the cause of outages for us in quite a few instances. I have been unable to stress what a terrible idea arbitrarily pulling and applying from git is. I am unable to stress it because that's the overwhelming way that many k8s setups are done, so clearly they cannot be wrong.
Outages after deploying are then just the effect.
Earlier quoted context omitted.
You may or may not be joking, but gitops has been the cause of outages for us in quite a few instances. I have been unable to stress what a terrible idea arbitrarily pulling and applying from git is. I am unable to stress it because that's the overwhelming way that many k8s setups are done, so clearly they cannot be wrong.
I'm unsure what the alternative is. Even without gitops people do the same hand labour with the commandline, so why is GitOps specifically bad?
Bottom line is: GitOps means the source of truth is Git and automation makes sure to avoid drifts. You still have to have a rollout strategy and schedule that makes sense for your usecase.
Earlier quoted context omitted.
I'm unsure what the alternative is. Even without gitops people do the same hand labour with the commandline, so why is GitOps specifically bad?
If you use something like ArgoCD (and maybe also Argo Rollouts) you can do the diffing from Git automatically but either put a manual validation step where you have a chance to review the diff or implement some gradual rollout strategy. Also, it's probably wise to use a branch/tagging strategy and not read from head. Bottom line is: GitOps means the source of truth is Git and automation makes sure to avoid drifts. Yo…
THIS.
Earlier quoted context omitted.
You may or may not be joking, but gitops has been the cause of outages for us in quite a few instances. I have been unable to stress what a terrible idea arbitrarily pulling and applying from git is. I am unable to stress it because that's the overwhelming way that many k8s setups are done, so clearly they cannot be wrong.
I'm unsure what the alternative is. Even without gitops people do the same hand labour with the commandline, so why is GitOps specifically bad?
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 have never seemed that nice for me. It's perhaps kinda useful for third party stuff. But for your own applications, where you need to actually build the docker image and then either manually bump the tag or have some rube goldberg machinery committing to your repos, it just seems annoying.
Wanna see the state / source of truth? Use kubectl (or some other tool), we have this whole cluster just for keeping track of the state. Wanna see how/why/by who something was deployed? Look at the CI/CD tooling history.
Earlier quoted context omitted.
I'm unsure what the alternative is. Even without gitops people do the same hand labour with the commandline, so why is GitOps specifically bad?
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…
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 ser…