gitops-template

n through our Minikube-based CI workflows before they get published—similar to how the Homebrew core tap works. We’ve just introduced readiness checks for manifest-based deployments and utilize the flux-helm-controller to wait for a Helm release to succeed. Dependencies are resolved by our package controller. These dependencies can either be cluster-scoped (installed in the recommended namespace, e.g., operators wird CRDs) or namespace-scoped components of a package (e.g., a database or Redis cache). In such cases, we will prefix resources with the dependent package name to ensure multiple packages can use the same dependencies without naming conflicts (we use Kustomize on a virtual filesystem for this). Glasskube packages can currently be Helm charts (from an OCI or Helm repository) or manifests, which are mostly built using Kustomize’s overlay approach. Since neither the overlay approach (using Kustomize) nor Helm’s limited templating functionality will help us and other Kubernetes users scale to more complex packages, we are considering creating a more programmatic approach to package creation, similar to Timoni. Currently, KCL is our frontrunner (https://github.com/glasskube/glasskube/discussions/1018), as it already integrates well with the Kubernetes ecosystem. We would appreciate if you give our GitOps template a try. It also works work existing Kubernetes clusters if just want to use GitOps for some applications. Just make sure that the argocd and glasskube-system namespaces are not yet in use. See: https://github.com/glasskube/gitops-template/

just need to create your own repository from our template and bootstrap it with a single command. This will include: - ArgoCD for GitOps - Kube-Prometheus-Stack for Monitoring - Postgres Operator (Cloud Native PG) - Glasskube for package management - Renovate for updates via pull request Additionally, we deployed Shiori (https://github.com/go-shiori/shiori) as a simple application that requires a Postgres database. This is meant as an example application you can replace with your application you want to deploy to Kubernetes. I also created a walk-through demo video explaining the setup steps in more detail: https://www.youtube.com/watch?v=Xbs2Tq-dgbI Sometimes, you may need to manually refresh the App of Apps inside ArgoCD to ensure that the other apps appear in the cluster. In addition, we will work on the following features in the future: - Support private repositories from the beginning. At the moment the repository needs to be public during bootstrapping. The visibility can be marked as private afterwards. (You will also need to manually configure your personal access token in ArgoCD) - Improve the Renovate integration, so we don’t need the custom regex matcher and can upgrade the glasskube manifest. Feel free to comment what is still missing or what you would do differently?