4 ms·

I mean that node (not js) dashboard to build pipelines and make things look logical instead of writing 4 lines of bash. I'm not a fan of anything that adds comp

I mean that node (not js) dashboard to build pipelines and make things look logical instead of writing 4 lines of bash. I'm not a fan of anything that adds complexity. ArgoCD/WF/ALL ARGO... is just a pretty dashboard over cli tooling. ./deploy.sh <repo>@<version> <pod-name> This is the contract you should focus on. Whatever you need to make ./deploy.sh do this, do it.

psYchotic 3y ago
Isn't ArgoCD more of a GitOps tool? The pretty UI is mostly secondary to its main purpose for me, which is to keep the declarative "truth" in source control, and have ArgoCD be the control loop that keeps the cluster in sync with that truth. Accidentally nuked namespace? No worries, ArgoCD's (or whatever alternative, like flux) got your back!
- rrrix1 3y ago
  Exactly this. The critical difference being who deploys and when/how your resources are deployed - a human, or a machine. Having git be the source of truth of your production environment is a blessing and a curse which is directly related to the maturity of the deployment system. If you have low confidence in your deployments (as in, you don't deploy very often and don't have full e2e tests & monitoring), GitOps is nightmarishly scary compared to classic, battle tested Ops team CLI scripts.
- gabereiser 3y ago
  I don’t accidentally do anything in production. Sorry. Nor do my teams or any developers who have access to my clouds. These kinds of failures don’t happen in my world. You will not have a mutable environment outside of data storage. Period. Nuke all you want, it will repair and redeploy itself.
Klugistiono 3y ago
Have you ever used ArgoCD? No one EVER should run deploy.sh like how you propose it. ArgoCD abstracts away access to a k8s cluster (login through dex). It has strategies of how to deploy k8s resources like through retry, replace (which you would need to write manually in your deploy.sh). It gives you debug output for your deploy process (yes thats a thing, you do not assume every deploy just works). ArgoCD also can and should be used to reference secerts from secret store like vault. And it gives you a history/audit.
- withinboredom 3y ago
  And fuck-us-all if you go on vacation. In a small business (read: startup), `deploy.sh` is all you should have. When you go on vacation and it breaks, I just need to read a bit of bash/python/php/whatever-script-you-use.lang and fix the broken stuff.
  - Klugistiono 3y ago
    I introduced ArgoCD to a project with 20 teams and the acceptance from developers was very high. What they had befor was a terraform based pipeline (i would argue similiar to a deploy.sh) and they struggled with those scripts hard. ArgoCD with dex is easily integrated in your auth system and you don't need to write some scripts to handle issues like login errors, timeouts etc. I have seen plenty of bash scripts which do exactly what they should do with 0 error handling and it was always a pain in the ass to analyse and fix those scripts.
- gabereiser 3y ago
  I used it at a Fortune 500. I’ve used it at a Fortune 100. I’ve used it in a small startup. I stand by my statement. It solves problems self inflicted due to crappy cloud architecture and mutable environments. Running a simple deploy script means your DevOps pipelines and cloud are mature enough to handle rollbacks, failures, blue/green deployments, and any migrations applied after a data snapshot (whatever that looks like in your architecture).
  - Klugistiono 3y ago
    Very weird that you have such an strong opinion of having some self written deploy script over a argocd setup. ArgoCD is super easy to setup, has a declarative setup and is a great platform tool. I introduced it to big systems and i really can't imagine how we would struggle if we would deploy those infra components with some bash scripts. Could you be more specific? Like assume you have some monitoring stack (kube-stack or grafana etc.) and either as a helm chart or as something else: What do you do when a CRD needs to be replaced? You write it in your deploy.sh script through some bash magic? Handling error cases in there? What do you do when you want to see what you have deployed? Like checking if your test setup is rolled back? You always use kubectl to check some helm values? Or do you always annotate all pods with git commits which you then c&p? A basic ArgoCD declarative setup takes perhaps a few hours if you do it for the first time, than you can give teams access to namespaces, they have log access, exec access if you provide a platform that is, in my opinion, quite a big advantage over just letting them use kubectl. Most developers i know do struggle with kubectl. And for my own infra ( i also even setup argocd at home ) the dev cycle is much faster for me. What "crappy cloud architecture" problem are you talking about specificly argocd apparently solves? How do you test components? Like we have a test cluster and everyone uses argocd to just switch to a dev branch for a few days while testing. This works really well and you can switch back to main in argocd. And due to Argocd App Def you can even see all apps out of sync due to testing.

psYchotic 3y ago

Isn't ArgoCD more of a GitOps tool? The pretty UI is mostly secondary to its main purpose for me, which is to keep the declarative "truth" in source control, and have ArgoCD be the control loop that keeps the cluster in sync with that truth. Accidentally nuked namespace? No worries, ArgoCD's (or whatever alternative, like flux) got your back!

rrrix1 3y ago
Exactly this. The critical difference being who deploys and when/how your resources are deployed - a human, or a machine. Having git be the source of truth of your production environment is a blessing and a curse which is directly related to the maturity of the deployment system. If you have low confidence in your deployments (as in, you don't deploy very often and don't have full e2e tests & monitoring), GitOps is nightmarishly scary compared to classic, battle tested Ops team CLI scripts.
gabereiser 3y ago
I don’t accidentally do anything in production. Sorry. Nor do my teams or any developers who have access to my clouds. These kinds of failures don’t happen in my world. You will not have a mutable environment outside of data storage. Period. Nuke all you want, it will repair and redeploy itself.

Klugistiono 3y ago

Have you ever used ArgoCD? No one EVER should run deploy.sh like how you propose it. ArgoCD abstracts away access to a k8s cluster (login through dex). It has strategies of how to deploy k8s resources like through retry, replace (which you would need to write manually in your deploy.sh). It gives you debug output for your deploy process (yes thats a thing, you do not assume every deploy just works). ArgoCD also can and should be used to reference secerts from secret store like vault. And it gives you a history/audit.

withinboredom 3y ago
And fuck-us-all if you go on vacation. In a small business (read: startup), `deploy.sh` is all you should have. When you go on vacation and it breaks, I just need to read a bit of bash/python/php/whatever-script-you-use.lang and fix the broken stuff.
- Klugistiono 3y ago
  I introduced ArgoCD to a project with 20 teams and the acceptance from developers was very high. What they had befor was a terraform based pipeline (i would argue similiar to a deploy.sh) and they struggled with those scripts hard. ArgoCD with dex is easily integrated in your auth system and you don't need to write some scripts to handle issues like login errors, timeouts etc. I have seen plenty of bash scripts which do exactly what they should do with 0 error handling and it was always a pain in the ass to analyse and fix those scripts.
gabereiser 3y ago
I used it at a Fortune 500. I’ve used it at a Fortune 100. I’ve used it in a small startup. I stand by my statement. It solves problems self inflicted due to crappy cloud architecture and mutable environments. Running a simple deploy script means your DevOps pipelines and cloud are mature enough to handle rollbacks, failures, blue/green deployments, and any migrations applied after a data snapshot (whatever that looks like in your architecture).
- Klugistiono 3y ago
  Very weird that you have such an strong opinion of having some self written deploy script over a argocd setup. ArgoCD is super easy to setup, has a declarative setup and is a great platform tool. I introduced it to big systems and i really can't imagine how we would struggle if we would deploy those infra components with some bash scripts. Could you be more specific? Like assume you have some monitoring stack (kube-stack or grafana etc.) and either as a helm chart or as something else: What do you do when a CRD needs to be replaced? You write it in your deploy.sh script through some bash magic? Handling error cases in there? What do you do when you want to see what you have deployed? Like checking if your test setup is rolled back? You always use kubectl to check some helm values? Or do you always annotate all pods with git commits which you then c&p? A basic ArgoCD declarative setup takes perhaps a few hours if you do it for the first time, than you can give teams access to namespaces, they have log access, exec access if you provide a platform that is, in my opinion, quite a big advantage over just letting them use kubectl. Most developers i know do struggle with kubectl. And for my own infra ( i also even setup argocd at home ) the dev cycle is much faster for me. What "crappy cloud architecture" problem are you talking about specificly argocd apparently solves? How do you test components? Like we have a test cluster and everyone uses argocd to just switch to a dev branch for a few days while testing. This works really well and you can switch back to main in argocd. And due to Argocd App Def you can even see all apps out of sync due to testing.