3 ms·

IIUC, it's basically "manage your Glasskube packages from Git, thanks to ArgoCD". The `glasskube install` command does a bunch of stuff that ends up as resourc

by linkdd 2y ago

IIUC, it's basically "manage your Glasskube packages from Git, thanks to ArgoCD". The `glasskube install` command does a bunch of stuff that ends up as resources in your Kubernetes cluster, that are then interpreted by the Glasskube operator. The "Gitops template" make use of ArgoCD and Git to do what `glasskube install` would have done.

pmig 2y ago
Thanks linkdd. Exactly Glasskube in "GitOps mode" will output these package custom resources as yaml so you can commit them to git and argo pulls these resources from git into the cluster.
hadlock 2y ago
Thanks. It sounds more like glasskube is a plugin for ArgoCD IIUC I am not super thrilled about critical applications like Argo getting a plethora of plugins, otherwise we end up looping back to Jenkins and plugin hell
- linkdd 2y ago
  Off-topic: To be honest, after trying almost all the CI/CD offerings out there, CircleCI, Github Actions, Gitlab CI, Travis, etc... I've started to believe that none of them actually did it better than Jenkins (despite all its flaws). On-topic: Glasskube isn't really an ArgoCD plugin as it can work standalone, but in 2024, can you really propose a package manager for k8s without having some integration with ArgoCD and GitOps in general? If you want to migrate, having interoperability between the tools can make the process smoother. And if you don't want to migrate and still benefit from a centralized, curated, audited repository of packages for Kubernetes so that your "Powered by ArgoCD" GitOps are easier to manage, that's what the GitOps template propose. In Debian, you can just `apt install <that big thing i don't want to write a deploy script for>`. Imagine doing that with the usual big operators you want in your cluster (cert-manager, a hashicorp vault operator, istio or nginx ingress controller or envoy or ...)
  - mtndew4brkfst 2y ago
    ArgoCD is not synonymous with GitOps (for Kube or in general) nor do they have a monopoly on effective implementation thereof. I certainly prefer FluxCD, myself.
    - hadlock 2y ago
      I've used both in production. FluxCD is fully batteries-included, but the UI (3rd party!) leaves a lot to be desired, and turns off a lot of developers, and as a result makes it difficult to get team buy-in ArgoCD is missing some critical systems, like how to tell when the underlying image needs updating. There are a number of ways to handle this but it's either a kludge, a plugin, or both. However, the UI is fantastic and very easy to pickup and understand, team buy-in is usually close to 100% I generally recommend starting with argo, and once the team/project/s have matured, migrate to FluxCD. Eventually you want to lock everyone out of the CD system, but initially people are skeptical and want to understand/watch everything work, especially during debug.

by linkdd 2y ago

pmig 2y ago

Thanks linkdd. Exactly Glasskube in "GitOps mode" will output these package custom resources as yaml so you can commit them to git and argo pulls these resources from git into the cluster.

hadlock 2y ago

Thanks. It sounds more like glasskube is a plugin for ArgoCD IIUC I am not super thrilled about critical applications like Argo getting a plethora of plugins, otherwise we end up looping back to Jenkins and plugin hell

linkdd 2y ago
Off-topic: To be honest, after trying almost all the CI/CD offerings out there, CircleCI, Github Actions, Gitlab CI, Travis, etc... I've started to believe that none of them actually did it better than Jenkins (despite all its flaws). On-topic: Glasskube isn't really an ArgoCD plugin as it can work standalone, but in 2024, can you really propose a package manager for k8s without having some integration with ArgoCD and GitOps in general? If you want to migrate, having interoperability between the tools can make the process smoother. And if you don't want to migrate and still benefit from a centralized, curated, audited repository of packages for Kubernetes so that your "Powered by ArgoCD" GitOps are easier to manage, that's what the GitOps template propose. In Debian, you can just `apt install <that big thing i don't want to write a deploy script for>`. Imagine doing that with the usual big operators you want in your cluster (cert-manager, a hashicorp vault operator, istio or nginx ingress controller or envoy or ...)
- mtndew4brkfst 2y ago
  ArgoCD is not synonymous with GitOps (for Kube or in general) nor do they have a monopoly on effective implementation thereof. I certainly prefer FluxCD, myself.
  - hadlock 2y ago
    I've used both in production. FluxCD is fully batteries-included, but the UI (3rd party!) leaves a lot to be desired, and turns off a lot of developers, and as a result makes it difficult to get team buy-in ArgoCD is missing some critical systems, like how to tell when the underlying image needs updating. There are a number of ways to handle this but it's either a kludge, a plugin, or both. However, the UI is fantastic and very easy to pickup and understand, team buy-in is usually close to 100% I generally recommend starting with argo, and once the team/project/s have matured, migrate to FluxCD. Eventually you want to lock everyone out of the CD system, but initially people are skeptical and want to understand/watch everything work, especially during debug.