Skip to content

Commit

Permalink
docs(website): fix broken links (#1426)
Browse files Browse the repository at this point in the history
Signed-off-by: Philip Miglinci <pmig@glasskube.eu>
  • Loading branch information
pmig authored Nov 26, 2024
1 parent b5aca6b commit 4db8755
Show file tree
Hide file tree
Showing 24 changed files with 83 additions and 86 deletions.
40 changes: 20 additions & 20 deletions website/blog/2023-12-14-5-helm-shortcomings/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -22,17 +22,17 @@ If you never heard about Helm before, in a nutshell it is:

> A framework for packaging Kubernetes resources (apps) to charts, publish them and let them easily be installed via a command line interface.

The goal of this post is *not* to hate on the smart and talented people who built helm, but maybe we can kindle a productive and healthy discussion about where we need to go as the DevOps industry to stay relevant in the coming years. But to fully understand the following, I think it is important to understand what developments lead us to where we are today.
So, before we start, let's quickly dive into the history of Helm.
The goal of this post is *not* to hate on the smart and talented people who built helm, but maybe we can kindle a productive and healthy discussion about where we need to go as the DevOps industry to stay relevant in the coming years. But to fully understand the following, I think it is important to understand what developments lead us to where we are today.
So, before we start, let's quickly dive into the history of Helm.

In 2015, a company called Deis created Helm, a package manager for Kubernetes.
Deis is now part of Azure Kubernetes Service but the original project still exists as [Helm Classic](https://github.com/helm/helm-classic). At the same time, Google had a project called *Kubernetes Deployment Manager*, which was similar to [Google Deployment Manager](https://cloud.google.com/deployment-manager/docs) but for Kubernetes resources, rather than GCS resources.
In 2015, a company called Deis created Helm, a package manager for Kubernetes.
Deis is now part of Azure Kubernetes Service but the original project still exists as [Helm Classic](https://github.com/helm/helm-classic). At the same time, Google had a project called *Kubernetes Deployment Manager*, which was similar to [Google Deployment Manager](https://cloud.google.com/deployment-manager/docs) but for Kubernetes resources, rather than GCS resources.

At the beginning of 2016, the two projects decided to merge, which resulted in the release of [Helm v2](https://v2.helm.sh/) later that year.
At the beginning of 2016, the two projects decided to merge, which resulted in the release of [Helm v2](https://v2.helm.sh/) later that year.
Helm v2 consists of a client and server component (Helm and tiller, respectively), where the latter was the continuation of the original Kubernetes Deployment Manager project.
Tiller was designed to handle deployment states to make it easier for multiple users to use Helm without interfering with each other.

In 2018, Helm [launched](https://helm.sh/blog/intro-helm-hub/) the Helm Hub as a central place to discover charts which are otherwise found in distributed repositories.
In 2018, Helm [launched](https://helm.sh/blog/intro-helm-hub/) the Helm Hub as a central place to discover charts which are otherwise found in distributed repositories.
Helm Hub was [rebranded](https://helm.sh/blog/helm-hub-moving-to-artifact-hub/) to [Artifact Hub](https://artifacthub.io/) in 2020.

With the release of Kubernetes 1.6, which had Role Based Access Control (RBAC) enabled by default, production deployments of helm became more difficult, because of the many security policies that were required by tiller.
Expand All @@ -54,11 +54,11 @@ To combat this major design flaw, chart developers have come up with several str
* Creating separate sub-charts just for CRDs

An alternative way to overcome this shortcoming is to not invoke helm commands directly, but rather use a CI/CD solution, like [Flux](https://github.com/fluxcd/flux2).
Flux provides a setting to automatically update CRDs during a helm upgrade, but it is [off by default](https://fluxcd.io/flux/components/helm/api/v2beta2/#helm.toolkit.fluxcd.io/v2beta2.CRDsPolicy).
Flux provides a setting to automatically update CRDs during a helm upgrade, but it is [set to only 'create' CRDs and don't update them](https://fluxcd.io/flux/components/helm/api/v2/#helm.toolkit.fluxcd.io/v2.CRDsPolicy).

### 2. Helm dependency management

The way to specify a dependency in a helm chart is to reference it as a sub-chart.
The way to specify a dependency in a helm chart is to reference it as a sub-chart.
This method can work great for tightly coupled dependencies that you might want to install separately or as part of another chart, but it has some weaknesses that are important to understand:

* Sub-charts are **always installed in the same namespace** as the primary release and there is no way to change this.
Expand All @@ -78,7 +78,7 @@ So far, we discussed problems that affect you as a chart user.
But what does the situation look like for chart developers?

Well, let's start by creating a new chart.
This can be achieved by calling `helm create your-chart`.
This can be achieved by calling `helm create your-chart`.
I invite you to quickly open a terminal, run this command and go through all the files it creates.
As I'm sure you will agree, it's… a *lot*.
I still remember the moment when I wanted to create my first helm chart and saw the results of this command thinking, “this can't be right.”
Expand Down Expand Up @@ -110,12 +110,12 @@ total 4,0K
-rw-r--r--. 1 kosmoz kosmoz 388 7. Dez 13:23 test-connection.yaml
```

In total, `helm create` generates 10 files in different sub-directories and it is not immediately apparent which ones of those are actually essential for a chart and which ones are just example code.
I once complained about this to a DevOps engineer who had already created dozens of charts and they laughed and said:
In total, `helm create` generates 10 files in different sub-directories and it is not immediately apparent which ones of those are actually essential for a chart and which ones are just example code.
I once complained about this to a DevOps engineer who had already created dozens of charts and they laughed and said:

> “The first step in creating a chart is running `helm create`. The second is deleting 90% of the results.”
Really? That's the best we can do?
Really? That's the best we can do?
Okay, let's accept that and say you figured out the structure of your new chart.
Now, you probably want to add some resources.
Of course, you can just drop your existing YAML files into the chart's `templates` directory, but you're probably interested in using some parameters from your `values.yaml` in your resources.
Expand All @@ -137,13 +137,13 @@ metadata:
{{- end }}
```

Now, I know what you're thinking:
Now, I know what you're thinking:

> That doesn't look like the YAML I know!
> That doesn't look like the YAML I know!
> What is ' `include`, `toYaml` and `nindent` and what's up with all the `-` and `{{` and `|`?
It's true, although helm template files use the file name extension for YAML, they are actually just templates.
Helm templates are based on the Go template language which is very flexible and powerful but doesn't really know anything about YAML or Kubernetes.
It's true, although helm template files use the file name extension for YAML, they are actually just templates.
Helm templates are based on the Go template language which is very flexible and powerful but doesn't really know anything about YAML or Kubernetes.
That's why it's necessary to call lots of these conversion functions inside the template files.

As a result many popular charts end up with template files that contain more template language stuff than actual YAML.
Expand All @@ -155,16 +155,16 @@ Now, let's go back to something that's a little more tangible for you as a helm
As a Kubernetes application developer who writes resources as YAML files, you are probably used to having rich support in your development environment, including strict schema validation and super comprehensive autocomplete.
Creating a `values.yaml` file for a chart release is a little different.
See, there is no general schema for what goes and doesn't go inside a `values.yaml` file.
Thus, your development environment cannot help you beyond basic YAML syntax highlighting.
Thus, your development environment cannot help you beyond basic YAML syntax highlighting.
The only way to verify if your `values.yaml` file is valid is to run it through helm and see what happens.
Using `helm template` allows you to render these helm templates which detects possible errors in the configuration file.

A lot of chart developers want to give users the possibility to fine tune most aspects of final deployment.
As a result, the number of possibilities for configuration is often unreasonably large and complicated, mimicking the actual resources they want to create, but without any schema validation!
As a result, the number of possibilities for configuration is often unreasonably large and complicated, mimicking the actual resources they want to create, but without any schema validation!

### 5. Inability to interact with the Kubernetes API

We already discussed 4 shortcomings of helm, but in my opinion the biggest downside of helm is this:
We already discussed 4 shortcomings of helm, but in my opinion the biggest downside of helm is this:
A helm release is strictly a one-shot operation.
Once a helm release is successfully installed, helm's job is done.
But here's the thing: **Installing an application is usually not the hard part, maintaining an installation and keeping it running is**.
Expand Down Expand Up @@ -208,7 +208,7 @@ protected fun getDefaultAnnotations(primary: P, context: Context<P>): Map<String
CloudProvider.aws -> awsDefaultAnnotations
CloudProvider.gardener -> gardenerDefaultAnnotations
else -> getCertManagerDefaultAnnotations(context) + ingressNginxDefaultAnnotations
```
```

## Conclusion

Expand Down
4 changes: 2 additions & 2 deletions website/blog/2024-02-01-technical-preview/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -66,7 +66,7 @@ flowchart BT

### Challenges that need to be solved

We already covered some our upcoming features in our [public roadmap](https://glasskube.dev/roadmap), but I would also like to take this opportunity to shortly speak about broader challenges.
We already covered some our upcoming features in our [public roadmap](/roadmap), but I would also like to take this opportunity to shortly speak about broader challenges.

#### Kubernetes version compatibility

Expand Down Expand Up @@ -104,7 +104,7 @@ packages are kept up-to-date and secure throughout multiple Kubernetes version u

## Getting started

Follow our [Getting Started guide](https://glasskube.dev/docs/getting-started/install) if you want to try Glasskube for yourself and install your first package.
Follow our [Getting Started guide](/docs/getting-started/install) if you want to try Glasskube for yourself and install your first package.

<Install/>

Expand Down
2 changes: 1 addition & 1 deletion website/blog/2024-02-08-cncf-landscape/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -44,7 +44,7 @@ These tools help streamline Kubernetes development and operations, offering dive
## Accepted in just 7 days after the launch

The pull request [#3735](https://github.com/cncf/landscape/pull/3735) got accepted just 7 days after the released of our first
[technical preview](https://glasskube.dev/blog/technical-preview/) of [Glasskube](https://glasskube.dev).
[technical preview](/blog/technical-preview/) of [Glasskube](https://glasskube.dev).

Glasskube was accepted into the CNCF landscape category due to its ability to effectively address the critical challenges
within application definition and image build, underscoring its importance in streamlining Package Management on Kubernetes.
Expand Down
2 changes: 1 addition & 1 deletion website/blog/2024-02-12-open-command/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -74,7 +74,7 @@ glasskube bootstrap

## Getting started

Follow our [Getting Started guide](https://glasskube.dev/docs/getting-started/install) if you want to try Glasskube for yourself and install your first package.
Follow our [Getting Started guide](/docs/getting-started/install) if you want to try Glasskube for yourself and install your first package.

<Install/>

Expand Down
2 changes: 1 addition & 1 deletion website/blog/2024-02-27-release-package-updates/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -85,7 +85,7 @@ glasskube bootstrap

## Getting started

Follow our [Getting Started guide](https://glasskube.dev/docs/getting-started/install) if you want to try Glasskube for yourself and install your first package.
Follow our [Getting Started guide](/docs/getting-started/install) if you want to try Glasskube for yourself and install your first package.

<Install/>

Expand Down
8 changes: 4 additions & 4 deletions website/blog/2024-03-22-release-0.1.0/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -37,8 +37,8 @@ Watch our release video to get an overview of what has changed:

### Dependency management 🔗

Building on the package installation features shipped in the previous weeks, we now offer an in-built way of managing
and installing the dependencies used by your desired package. Now package maintainers can define the appropriate dependencies, for
Building on the package installation features shipped in the previous weeks, we now offer an in-built way of managing
and installing the dependencies used by your desired package. Now package maintainers can define the appropriate dependencies, for
each Glasskube supported package as well as recommending the range of suitable dependency versions, this way ensuring that packages are always
compatible to accompanying dependency.

Expand All @@ -47,7 +47,7 @@ Package dependencies will show on the installation drop down in the GUI. They wi
### Dark Mode 🕶️

Great news, we shipped the "must-have" feature any OSS project can't survive without, `Dark Mode`. Glasskube's dark mode is linked to the display mode
defined on your local system. Access your system preferences menu and try it out!
defined on your local system. Access your system preferences menu and try it out!

![Dark Mode](https://github.com/glasskube/glasskube/assets/38757612/60320d36-6790-47b2-840c-c56beb3e9c41)

Expand Down Expand Up @@ -82,7 +82,7 @@ glasskube bootstrap --latest

## Getting started

Follow our [Getting Started guide](https://glasskube.dev/docs/getting-started/install) if you want to try Glasskube for yourself and install your first package.
Follow our [Getting Started guide](/docs/getting-started/install) if you want to try Glasskube for yourself and install your first package.

<Install/>

Expand Down
4 changes: 2 additions & 2 deletions website/blog/2024-05-20-devops/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ In the words of [Adam Jacob](https://twitter.com/adamhjk)
> “The problem isn’t that we haven’t optimized each individual part of the system enough. We’ve built more efficient tooling at every step. But the way the whole system is put together? The experience of using it? That’s basically identical to how it was in 2009, and it’s the reason we’re stuck.“.
**Siloes still exist, handoffs are error-prone and collaboration on many occasions is quite forced and rigid.** Anybody who has worked as a DevOps engineer for any length of time will have a long list of things they think their organization gets wrong and will often have equally low amount of faith in their organization’s capacity to do anything about it.
Adam, a veteran DevOps practitioner, has even called for [a second wave DevOps](https://www.systeminit.com/blog-second-wave-devops) which goes further than trivially improving tools and invites us to think outside of the box, challenge the established rules, and see what’s on the other side.
Adam, a veteran DevOps practitioner, has even called for [a second wave DevOps](https://www.systeminit.com/blog-second-wave-devops/) which goes further than trivially improving tools and invites us to think outside of the box, challenge the established rules, and see what’s on the other side.

Speaking of DevOps practitioners, who are these people? How and why does one become one?

Expand Down Expand Up @@ -132,7 +132,7 @@ To create it though we are going to have to think outside of the box.
### A second wave of DevOps might be one the way

Thankfully there are many restless and nonconforming people who contribute to the constant improvement of methodologies, processes, and tooling in the DevOps space.
Some might say that a formal [movement](https://www.systeminit.com/blog-second-wave-devops) of rethinking what DevOps could be is already emerging and that’s pretty exciting.
Some might say that a formal [movement](https://www.systeminit.com/blog-second-wave-devops/) of rethinking what DevOps could be is already emerging and that’s pretty exciting.

### The more generalists and tinkerers, the better

Expand Down
2 changes: 1 addition & 1 deletion website/blog/2024-07-02-quickwit/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -89,7 +89,7 @@ Additionally, Quickwit seamlessly integrates with OpenTelemetry using gRPC and H
- _RESTful API_

## Want to install Quickwit via Glasskube?
Follow the [installation guide](https://glasskube.dev/guides/quickwit/).
Follow the [installation guide](/guides/quickwit/).

---

Expand Down
4 changes: 2 additions & 2 deletions website/blog/2024-08-07-gitops-template/index.mdx
Original file line number Diff line number Diff line change
Expand Up @@ -18,7 +18,7 @@ However, what if there was an easier way? Our new GitOps template is designed to

If you’re reading this, you likely already appreciate the benefits of GitOps and have a solid understanding of Kubernetes. However, until recently, there hasn’t been an elegant, standardized process for managing the packages installed in your Kubernetes clusters. That’s why we built one.

Let’s put it to the test. With this template, ArgoCD, CloudNativePG and a simple bookmarking web app will be installed using the [Glasskube](https://glasskube.dev/) Package Manager and they’ll receive upgrades through a Renovate integration via pull requests. This future-proof setup is easy to maintain and ensures your clusters stay up-to-date effortlessly.
Let’s put it to the test. With this template, ArgoCD, CloudNativePG and a simple bookmarking web app will be installed using the [Glasskube](/) Package Manager and they’ll receive upgrades through a Renovate integration via pull requests. This future-proof setup is easy to maintain and ensures your clusters stay up-to-date effortlessly.

### The next logical extension for infrastructure IaC

Expand Down Expand Up @@ -73,7 +73,7 @@ minikube start -p glasskube
### Install the Glasskube CLI

Make sure to have at least Glasskube version 0.16.0 [installed](https://glasskube.dev/docs/getting-started/install/) locally. If you don’t, you can simply run:
Make sure to have at least Glasskube version 0.16.0 [installed](/docs/getting-started/install/) locally. If you don’t, you can simply run:

```
brew install glasskube/tap/glasskube
Expand Down
Loading

0 comments on commit 4db8755

Please sign in to comment.