What is Glasskube?
Glasskube is a package manager created to address the limitations of using manifests. If you're a DevOps Engineer, you've likely felt frustrated with applying helm charts and manifests.
Updating applications deployed via Helm charts can sometimes be challenging. Helm doesn't provide a straightforward mechanism for updating certain aspects of your deployment, potentially leading to manual intervention or complex workarounds. That's where Glasskube comes in. Glasskube has you covered whether you like using a UI or CLI to easily install packages. Glasskube eases the installation and takes care of dependency management.
Checkout Glasskube on github.
Adding packages to Glasskube:
Glasskube is a relatively new tool that has been open-sourced on GitHub. More and more packages are being integrated into it by the team. If you are a package maintainer or a developer, you are welcome to add your package to Glasskube.
Let's see how to add your package to Glasskube step by step:
Fork the glasskube/packages repository.
Clone the forked repository to your local machine.
git clone https://github.com/yourfork/packages.git
- Change the directory to packages.
cd packages
- To add your package you need to create a directory with the name of the package. Then create a versions.yaml file inside it. The versions.yaml has all the version available and the latestVersion/stableVersion of the package.
packages/
[your-new-package]/
versions.yaml
[version-of-package]/
package.yaml
Template of versions.yaml
latestVersion: v1.14.2+1
versions:
- version: v1.13.3+1
- version: v1.14.2+1
- Create the files
packages/[your-new-package]/versions.yaml
mkdir your-new-package
touch your-new-package/versions.yaml
Once created the versions.yaml add all the available versions and latest version to it.
For every version in the versions.yaml there need to be separate directory with package.yaml
which contains the configuration of the package.
Basic template of package.yaml
# yaml-language-server: $schema=https://glasskube.dev/schemas/v1/package-manifest.json
name: "your-package-name"
shortDescription: Short description of the package
longDescription: >-
Long description of the package
iconUrl: "[iconurl of the package usually stored in github]"
helm:
repositoryUrl: "[yaml manifest of the package]"
chartName: "[name of the chart]"
chartVersion: "[version of the chart]"
references:
- label: "ArtifactHub"
url: "https://artifacthub.io/packages/[your-package]"
The package.yaml configuration depends on your package make sure to configure other things that are necessary for successful installation of the package.
- To index the package in UI and make it accessible, add your package details to
index.yaml
Testing Package Installation:
Now the package has been added to the packages, now we need to install it through glasskube.
Requirements:
Caddy
A Cluster (Minikube)
- Install Caddy in your system and setup a local web server in your repository.
~$ cd packages
~/packages$ caddy file-server --listen :9090 --root .
Modify Glasskube to use your local webserver as repository:
Fork and clone the glasskube/glasskube repository and in your local repository open
internal/repo/interface.go
, replace the repoURL inDefaultClient
withhttp://localhost:9090/packages/
Start the packageOperator locally using
make install webhook cert run
While the operator is running, open a new terminal window and install your package.
You can also use the UI if prefer (launch the UI using
go run ./cmd/glasskube serve
)go run ./cmd/glasskube install [your-new-package]
Note for Developers/Contributors:
If the packageOperator is running correctly Glasskube shouldn't ask for bootstrap, if that happens cancel the installation and run
make install webhook cert run
again. Theglasskube bootstrap
andmake install webhook cert run
aren't compatible so avoid using bootstrap in development.Once the package is installed and everything works as intended commit, push and make a PR.
My experience in adding my first package to Glasskube
Each package differs in its installation configuration and the package.yaml may differ for each package and sometimes even for the different versions of a same package. Below is the package.yaml configuration of sealed-secrets controller which has been integrated to Glasskube and available for installation.
# yaml-language-server: $schema=https://glasskube.dev/schemas/v1/package-manifest.json
name: "sealed-secrets"
shortDescription: A Kubernetes controller and tool for one-way encrypted Secrets
longDescription:
To use this package, install the [kubeseal](https://github.com/bitnami-labs/sealed-secrets#kubeseal) application.
Use kubeseal with the `--controller-namespace=sealed-secrets-system` flag.
For more information, check out the [official documentation](https://github.com/bitnami-labs/sealed-secrets#usage).
iconUrl: "https://avatars.githubusercontent.com/u/34656521"
defaultNamespace: "sealed-secrets-system"
helm:
repositoryUrl: "https://bitnami-labs.github.io/sealed-secrets/"
chartName: "sealed-secrets"
chartVersion: "v2.15.3+1"
values:
fullnameOverride: "sealed-secrets-controller"
references:
- label: "ArtifactHub"
url: "https://artifacthub.io/packages/helm/bitnami/sealed-secrets"
For the successful installation of sealed-secrets a fullnameOverride
field has been set. So, it really depends on the package and this blog covers a basic guidelines for the package integration.
Glasskube has a great team which supports new contributors and helps them out. With the help of the Glasskube team I added Sealed-Secrets controller to Glasskube. Thanks to Jake Page, Jakob Steiner, Christoph Enne also the Co-Founders Philip Miglinci and Louis Weston for their amazing support in the community.