pmig

Good question, the Glasskube package manager is an alternative to Helm. As Distr is the management / distribution layer the layer connecting the deployment target to the ISV. On the deployment target the software gets installed via docker-compose, Helm or - in future - with the Glasskube Package Manager. The features don't really overlap they complement each other.

Thanks!

> I've been through the docs and could find if there's a way to deploy a git repo, or a tar file, that contains the docker compose file instead if copy pasting.

We are currently developing a GitHub Action utilizing our SDK to upload latest releases (and provide paths to the docker-compose file).

> What about env variables?

These are high up in our backlog and we are looking for initial partners to specify them with. We thought about using end-to-end encryption for env variables.

What would be an example for an endpoint?

> `docker compose up` Yes currently this all what the agent does. We assume that most applications handle upgrades inside their applications and not on an infrastructure level. Do you have an exact upgrade case in mind?

Regarding the vendor and the customer portal, we want to enable both options. A deployment can either be managed by the vendor or by the customer. Some customers want to control when they want to perform upgrades and set certain variables or helm values themselves. In other cases it is fine if the ISV does all the management.

This is also what might be configurable in the future.

Thanks again, let us know if you know how can improve Distr. All feedback is welcome.

I actually didn't hear about jenkins-x before. Why did it never took off?

This custom resource will be reconciled by olm, so you need to setup olm [1] first. Also the OLM UI is only backed into OpenShift.

[1] https://operatorhub.io/how-to-install-an-operator

A deeper integration into Argo CD (similar as how helm is integrated) will be needed to in order to display all status conditions.

I don't think that idea of gitops is broken if the glasskube package controller and all custom resources are versioned you will always lead to a reproducible result.

> Can we benefit your project in a more limited but agentless way?

We are building a central package repository with a lot of ci / cd testing infrastrucutre to increase quality of kubernetes packages in general: https://github.com/glasskube/packages

Instead of using the Terraforms Helm provider, you can simply install the Glasskube package controller and provision package custom resource definitions via Flux. This is also how we manage our internal clusters.

I recommend giving Glasskube a try with Minikube locally and join our Discord to interact with the community.

If you are not on open-shift olm and the operator hub is quite an overkill. I wrote a more detailed explanation on our website: https://glasskube.dev/docs/comparisons/olm/

Tldr.: If you are already using open shift, make use of the operator hub, else glasskube is the more lightweight and simpler solution with similar concepts.

Teams can also build applications with the apps of apps pattern with Argo CD or Flux kustomizations. They both feature concepts of dependencies. But these packages can then not published and shared between different clusters and organization that don't share a git repository.

A package manager for a software stack the does not change that often (a) can move managed services like databases, message queues or even more complex obseravbility tools inside the cluster with the same convenience of a manage service.

If your setup become more complex and changes often (b) a I would recommend breaking it up into smaller pieces.

For both scenarios it makes sense to use git to keep track of revision and previous states of your Kubernetes cluster and incorporate review processes with pull requests.

There are multiple reasons and limitations with current tooling that we want to overcome.

We have abstracted all packages as custom resources and have a controller that reconciles these resources to (1) enable drift detection. Additionally, we use admission controllers (2) to validate dependencies and package configurations before they are applied to the cluster, while also working with custom resources to store and update the status of installed packages.

I just setup a argo cd autopilot repository https://github.com/pmig/argocd-autopilot as a comparison. Autopilot gives you a great opinionated scaffold for internal applications.

Our template already includes update automations with the renovate integration and easier integration of third party applications.

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.

Yes, you can get started by executing this commands.

Our bootstrap git sub command is similar to argo cd autopliot. I give it a try right now to be able to better state differences and follow up on this question.

Thanks for your input. Glasskube is used as the package manager in the template. We highlighted it in the initial comment, but I agree we could have also added it in the title.

Thanks for the feedback. I agree that setting up a blank ArgoCD is pretty simple. But installing applications and keeping ArgoCD up to date is where we saw a lot of challenges. On a sidenote: Why would it be hard to justify a dependency on Glasskube?

I personally see less and less Makefiles in newer projects, but I also never saw a repository migrating away from a Makefile as it probably has many usages across different use cases like CI / CD and local build tooling.

Currently Glasskube only supports wrapping and patching Helm Charts and plain manifests. As Helm chart creation has its quirks (https://glasskube.dev/blog/5-helm-shortcomings/) creating native Glasskube packages is high up on our road map. Our main priorities are:

- Well defined package structure - Comprehensive but scaleable configuration options - Integration with existing typed configuration options & dependencies - Support for in Code and optional dependencies - Tooling that will package a Glasskube packages and generate manifests

We would also appreciate your vote on our GitHub discussion.

Currently Glasskube only supports wrapping and patching Helm Charts and plain manifests. As Helm chart creation has its quirks (https://glasskube.dev/blog/5-helm-shortcomings/) creating native Glasskube packages is high up on our road map.

Our main priorities are:

- Well defined package structure - Comprehensive but scaleable configuration options - Integration with existing typed configuration options & dependencies - Support for in Code and optional dependencies - Tooling that will package a Glasskube packages and generate manifests

We would also appreciate your vote on our GitHub discussion.

Yes we do, in fact you can find the exact comparison here: https://glasskube.dev/docs/comparisons/helm/

Our demo is more end user focused. You can find more information about our configuration options in our package configuration documentation: https://glasskube.dev/docs/design/package-config/

So whats your take on https://github.com/stripe/skycfg do you also have experience with it?

Introducing complexity is always something that needs to be introduced carefully. It makes things harder if you introduce it to early, but everything will break in a big bang if you introduce it too late.

Nowadays you can also start with a light weight MQ like Rabbit MQ and decouple your service just into a hand full components. This will set you up for scalability without introducing massive overheads.

In end it is also always a knowledge game. How experienced are you or how much time are you willing to invest into learning and understanding a technology.

We started similar to Homebrew with putting packages inside our "core" Glasskube package repository (https://github.com/glasskube/packages) where all updates are centrally stored and tested by our CI / CD workflows so users can enjoy tested and seamless upgrades. Users can of course host their private repositories (and packages) but we want to provide an opinionated set of packages ourselves.

Building them for different Kubernetes version or environments is something we also already thought about and need to happen at some time to bake more configuration into to the build step.

The problem with contributing Glasskube to the CNCF atm would be that we would also need to contribute our Logo and trade mark. Something which we currently not willing to do. We look as Grafana as a successful example that did not contribute their core product to the CNCF and is still widely adopted.

Packages available in the public Glasskube repo are configured in a way to make sure changes in CRDs get applied (either via Manifest or the helm-controller)

We will update the docs though.

That's an interesting analogy, but I thinks it's a stretch.

This is actually a problem we want to focus on with Glasskube Cloud (https://glasskube.cloud/) where our glasskube[bot] will comment on your GitOps Pull request with an exact diff of resources that will get changed across all connected clusters. This diff will be performed by controller running inside your cluster.

Think of it as codecov analysis, but just for resource changes.

Helm (also in combination with terraform) is a client side tool for deploying charts to your cluster.

Glasskube on the other hand is a package manger where you can find look up, install and configure packages via a cli and UI and overcome some of the shortcomings of Helm.

Thanks for clarifying your inputs.

> This misses the point, what we need is something more like Terraform, which has a way to get dynamic information from resource values that are assigned by the system. One such example would be the secret that the postgres operator generates for connecting in the api server that needs access.

It is also already possible to inject values from secrets during runtime. You can for example create a Glasskube package that has a dependency on cnpg and add a `cluster.yaml` to your package and then dynamically patch the connection string (or credentials) from it to your deployment.

See the "ValueFrom" section of our configuration documentation for the exact inner workings: https://glasskube.dev/docs/design/package-config/

ArgoCD is a great tool to sync the state from your GitOps repository to your cluster and helps by visualizing the installed resources and showcase potentials errors.

It is often used by developers to get a glimpse of the state of core application of a company without cluster access.

Glasskube focuses on the packages your core application depends on. Managing the life cycle of these infrastructure components, testing updates and providing upgrading paths. You can still put Glasskube packages into your GitOps repo and sync them via ArgoCD into the cluster. Our PackageController will do the rest.