Don't use shortcodes for {{% ref "xxx" %}}

Author: codablock

content/en/blog/2022-05-11-introducing-kluctl-and-flux.md

@@ -12,7 +12,7 @@ tags:
 {{% alert context="warning" %}}
 Please note that the information in this blog post is outdated. Kluctl does
 not integrate into Flux anymore and instead provides an independent
-[Kluctl Controller]({{< ref "docs/gitops" >}}).
+[Kluctl Controller]({{% ref "docs/gitops" %}}).
 {{% /alert %}}
 
 We're very happy to announce that Kluctl can from now on be used together with [Flux](https://fluxcd.io/). This
@@ -44,17 +44,17 @@ fashion as [Kustomizations](https://fluxcd.io/docs/components/kustomize/kustomiz
 
 Each KluctlDeployment specifies a source object
 (e.g. a [GitRepository](https://fluxcd.io/docs/components/source/gitrepositories/)),
-the [target]({{< ref "docs/kluctl/kluctl-project/targets" >}}) to be deployed and some information on how
+the [target]({{% ref "docs/kluctl/kluctl-project/targets" %}}) to be deployed and some information on how
 to handle kubeconfigs. The controller then regularly reconciles the deployment, meaning that it will invoke
-[kluctl deploy]({{< ref "docs/kluctl/commands/deploy" >}}) whenever a change is detected in the deployment.
+[kluctl deploy]({{% ref "docs/kluctl/commands/deploy" %}}) whenever a change is detected in the deployment.
 
-Sounds great? Then take a look at [this]({{< ref "docs/gitops" >}}) very simple example
+Sounds great? Then take a look at [this]({{% ref "docs/gitops" %}}) very simple example
 <div class="center">
 <iframe src="https://giphy.com/embed/xjEmbSLychDd6JQFo0" width="480" height="480" frameBorder="0" class="giphy-embed" allowFullScreen></iframe><p><a href="https://giphy.com/gifs/disneychannelofficial-disney-channel-disneychannel-amphibia-xjEmbSLychDd6JQFo0">via GIPHY</a></p>
 </div>
 
 ## Kustomize/Helm vs Kluctl
-If you've already read through the [Kluctl documentation]({{< ref "docs" >}}), you've probably noticed
+If you've already read through the [Kluctl documentation]({{% ref "docs" %}}), you've probably noticed
 that Kluctl internally uses Kustomize and Helm extensively.
 
 This might raise the question: Why not use plain Kustomize and/or Helm if Flux is already involved?
@@ -69,7 +69,7 @@ same deployment, including the necessary configuration to let them talk to each
 To see how different a Kluctl deployment is compared to classic Kustomize/Helm + Flux, you can compare the
 [flux2-kustomize-helm-example](https://github.com/fluxcd/flux2-kustomize-helm-example) and the
 [Kluctl Microservices Demo](https://github.com/kluctl/kluctl-examples/tree/main/microservices-demo/3-templating-and-multi-env)
-([here]({{< ref "docs/tutorials/microservices-demo">}}) is tutorial for the demo).
+([here]({{% ref "docs/tutorials/microservices-demo" %}}) is tutorial for the demo).
 
 ## Native multi-env support
 Kluctl allows you to natively create deployment projects that can be deployed multiple times to different
@@ -79,7 +79,7 @@ way you like. For example, you could change the `local` target to set all replic
 support applications (e.g. monitoring infrastructure).
 
 This is possible in plain Kustomize as well, but requires you to solve it without the concept of
-[targets]({{< ref "docs/kluctl/kluctl-project/targets" >}}) and without templating. In Kustomize, multi-env
+[targets]({{% ref "docs/kluctl/kluctl-project/targets" %}}) and without templating. In Kustomize, multi-env
 deployments must be solved with [overlays](https://kubernetes.io/docs/tasks/manage-kubernetes-objects/kustomization/#bases-and-overlays),
 which does not necessary align with how you prefer your project structure.
 

content/en/blog/2022-05-16-rethinking-kubernetes-configuration-management.md

@@ -174,7 +174,7 @@ and GitOps. This means you can deploy to a playground environment from your loca
 other deployments, adhering to the GitOps principles.
 
 ## Learning Kluctl
-If you want to learn about Kluctl, go to [kluctl.io]({{< ref "" >}}) and read the documentation. Best is actually
+If you want to learn about Kluctl, go to [kluctl.io]({{% ref "/" %}}) and read the documentation. Best is actually
 to start with the Microservices Demo Tutorial, as it tries to introduce you to the Kluctl concepts step by step.
 
 After you’ve finished the tutorial, you should be able to understand how projects are structured, how Kustomize and

content/en/blog/2022-06-03-multi-env-flux.md

@@ -17,7 +17,7 @@ images:
 {{% alert context="warning" %}}
 Please note that the information in this blog post is outdated. Kluctl does
 not integrate into Flux anymore and instead provides an independent
-[Kluctl Controller]({{< ref "docs/gitops" >}}).
+[Kluctl Controller]({{% ref "docs/gitops" %}}).
 {{% /alert %}}
 
 Most projects that have server-side components usually need to be deployed multiple times, at least if you don't want to
@@ -50,7 +50,7 @@ disable advanced monitoring on "dev" environments and enable mocking services as
 
 There are multiple tools available that allow you to implement a multi-env/multi-cluster deployment that is completely
 automated and completely "as code". Helm and Kustomize are currently the first tools that will pop up when you try to
-look for such tools. As written in my [previous blog post]({{< ref "blog/2022-05-16-rethinking-kubernetes-configuration-management" >}}),
+look for such tools. As written in my [previous blog post]({{% ref "blog/2022-05-16-rethinking-kubernetes-configuration-management" %}}),
 I believe that these tools are the best option for the things that they do very good, but a sub-optimal choice when it
 comes to configuration management.
 
@@ -59,15 +59,15 @@ a solution that is as easy to learn and use and so flexible at the same time.
 
 ## Fully working multi-env example
 
-I suggest to open the [microservices demo]({{< ref "docs/tutorials/microservices-demo" >}})
+I suggest to open the [microservices demo]({{% ref "docs/tutorials/microservices-demo" %}})
 in another tab and look into it at least briefly (especially the third part). I will from now on pick stuff from this
 tutorial as examples in this blog post.
 
 ## Targets in Kluctl
 
 Kluctl works with the concept of "targets". A target is a named configuration that acts as the entry point for every
 further configuration required for your environment. As an example, look at the targets from
-[.kluctl.yaml]({{< ref "docs/kluctl/kluctl-project" >}}) of the microservices demo:
+[.kluctl.yaml]({{% ref "docs/kluctl/kluctl-project" %}}) of the microservices demo:
 
 ```yaml
 targets:
@@ -129,7 +129,7 @@ deployments:
 ```
 
 I hope the above snippets give you a feeling about how multi-env deplyoments can be solved via Kluctl. As already
-mentioned, I suggest to read through the [microservices demo]({{< ref "docs/tutorials/microservices-demo" >}})
+mentioned, I suggest to read through the [microservices demo]({{% ref "docs/tutorials/microservices-demo" %}})
 tutorial to get an even better understanding. The first two parts will describe some Kluctl basics while the third
 part enters multi-env deployments.
 
@@ -148,7 +148,7 @@ developer is done with the changes, GitOps can take over on the another (e.g. "t
 Even for "prod", which in the above scenario is GitOps managed, can benefit from the possibility to run Kluctl from
 your local machine. Running a "kluctl diff -t prod" before promoting to "prod" can prevent some scary surprises.
 
-Kluctl implements GitOps via the [flux-kluctl-controller]({{< ref "blog/2022-05-11-introducing-kluctl-and-flux" >}}).
+Kluctl implements GitOps via the [flux-kluctl-controller]({{% ref "blog/2022-05-11-introducing-kluctl-and-flux" %}}).
 It allows to create `KluctlDeployment` objects which refer to your Kluctl
 project (which relies in Git) and the target to be deployed.
 
@@ -237,7 +237,7 @@ As an alternative, you can have a central Flux (+flux-kluctl-controller) install
 This can be achieved with the help of the spec.kubeconfig and spec.serviceAccountName
 field of the `KluctlDeployment` object.
 
-Also, as the examples stem from the [microservices demo]({{< ref "docs/tutorials/microservices-demo" >}}), they
+Also, as the examples stem from the [microservices demo]({{% ref "docs/tutorials/microservices-demo" %}}), they
 use the `kind-kind` context names. In a more realistic setup, you would use the real cluster/context names here. This
 also assumes that all developers will then use the same context names to refer to the same clusters. If this is honored,
 you gain 100% compatibility between the GitOps based deployments and CLI based deployments.

content/en/blog/2022-11-17-templating-and-diffs-with-kustomize.md

@@ -59,20 +59,20 @@ But...Kustomize doesn't support templating, right?
 
 ## Bringing templating to Kustomize
 
-[Kluctl]({{< ref "" >}}) builds a large set of its features and promised advantages on top of
-[templating]({{< ref "docs/kluctl/templating" >}}). The
-[Kustomize integration]{{< ref "docs/kluctl/deployments/kustomize" >}} also allows templating in all
+[Kluctl]({{% ref "/" %}}) builds a large set of its features and promised advantages on top of
+[templating]({{% ref "docs/kluctl/templating" %}}). The
+[Kustomize integration]({{% ref "docs/kluctl/deployments/kustomize" %}}) also allows templating in all
 involved resources, including the `kustomization.yaml` itself and all referenced manifests.
 
 Configuration can be provided in different ways:
-1. Via [CLI arguments]({{< ref "docs/kluctl/commands/common-arguments#project-arguments" >}}), e.g. `--arg` or `--args-from-file`.
-2. Via [Targets]({{< ref "docs/kluctl/kluctl-project/targets#args" >}}), meaning that you can define named targets with fixed args.
-3. Via [vars]({{< ref "docs/kluctl/deployments/deployment-yml#vars-deployment-project" >}}) in Kluctl deployments.
-4. Via [Environment variables]({{< ref "docs/kluctl/commands/environment-variables#environment-variables-as-arguments" >}}) (through `KLUCTL_ARG_XXX`).
+1. Via [CLI arguments]({{% ref "docs/kluctl/commands/common-arguments#project-arguments" %}}), e.g. `--arg` or `--args-from-file`.
+2. Via [Targets]({{% ref "docs/kluctl/kluctl-project/targets#args" %}}), meaning that you can define named targets with fixed args.
+3. Via [vars]({{% ref "docs/kluctl/deployments/deployment-yml#vars-deployment-project" %}}) in Kluctl deployments.
+4. Via [Environment variables]({{% ref "docs/kluctl/commands/environment-variables#environment-variables-as-arguments" %}}) (through `KLUCTL_ARG_XXX`).
 
 In this blog post, we'll focus on the first option for simplicity. The second and third options are much more
-powerful, but require more boilerplate to set up a [Kluctl project]({{< ref "docs/kluctl/kluctl-project" >}})
-and [Kluctl deployments]({{< ref "docs/kluctl/deployments/deployment-yml" >}}). The first option also works with
+powerful, but require more boilerplate to set up a [Kluctl project]({{% ref "docs/kluctl/kluctl-project" %}})
+and [Kluctl deployments]({{% ref "docs/kluctl/deployments/deployment-yml" %}}). The first option also works with
 plain Kustomize deployments, which is what I'm going to demonstrate.
 
 Whatever option is used, all "args" are then available in every place by simply using
@@ -103,7 +103,7 @@ Thanks for using kind! 😊
 ```
 
 Ensure that you are on the correct Kubernetes context by calling `kubectl config current-context` and verify that it
-points to `kind-kind`. Without using [Kluctl Targets]({{< ref "docs/kluctl/kluctl-project/targets" >}}) with
+points to `kind-kind`. Without using [Kluctl Targets]({{% ref "docs/kluctl/kluctl-project/targets" %}}) with
 fixed contexts, Kluctl behaves the same as any other tool in the Kubernetes space when it comes to the current context,
 meaning that you have to watch out to not deploy to prod by accident! :)
 
@@ -295,7 +295,7 @@ $ kluctl deploy -a entry_replicas=3 -a hat_enabled=false
 ```
 
 If you deploy with a hat and then with `hat_enabled=false`, Kluctl will not delete/prune the previously deployed hat.
-If you want to have pruning support, you must create a [Kluctl deployment]({{< ref "docs/kluctl/deployments" >}})
+If you want to have pruning support, you must create a [Kluctl deployment]({{% ref "docs/kluctl/deployments" %}})
 with `commonLabels` enabled, so that Kluctl knows how to identify related objects.
 
 ## Using vars files instead of arguments
@@ -322,18 +322,18 @@ $ kluctl diff --args-from-file=prod-args.yaml
 ```
 
 Based on that, you can easily implement multi-environment deployments. This is however still a poor-mans solution to
-multi-environment deployments, with the use of [Kluctl projects]({{< ref "docs/kluctl/kluctl-project" >}})
-being the better solution. Said Kluctl projects allow you to define named [targets]({{< ref "docs/kluctl/kluctl-project/targets" >}})
+multi-environment deployments, with the use of [Kluctl projects]({{% ref "docs/kluctl/kluctl-project" %}})
+being the better solution. Said Kluctl projects allow you to define named [targets]({{% ref "docs/kluctl/kluctl-project/targets" %}})
 which are fixed in their configuration, so that you only have to invoke `kluctl deploy -t test` without needing to
 know what the internal details are.
 
 ## What's next?
 
 This article has shown how Kluctl can be used on simple/plain Kustomize deployments. The next thing you should consider
-is using [Kluctl projects]({{< ref "docs/kluctl/kluctl-project" >}}) and
-[Kluctl deployments]({{< ref "docs/kluctl/deployments" >}}) around your Kustomize deployments. It will allow you
+is using [Kluctl projects]({{% ref "docs/kluctl/kluctl-project" %}}) and
+[Kluctl deployments]({{% ref "docs/kluctl/deployments" %}}) around your Kustomize deployments. It will allow you
 to have much more flexible and powerful ways of configuration management. It will also allow you to use the GitOps style
 [flux-kluctl-controller](https://github.com/kluctl/flux-kluctl-controller).
 
-Upcoming blog posts will show why the [Helm Integration]({{< ref "docs/kluctl/deployments/helm" >}}) is a good
+Upcoming blog posts will show why the [Helm Integration]({{% ref "docs/kluctl/deployments/helm" %}}) is a good
 thing with many advantages and also describe why one would choose Kluctl over plain Helm.

content/en/blog/2022-12-28-template-controller.md

@@ -15,7 +15,7 @@ images:
 ![image](/images/blog/template-controller.jpg)
 
 This blog post serves two purposes. The first one is to announce and present the 
-[Template Controller]({{< ref "docs/template-controller" >}}) ([Source](https://github.com/kluctl/template-controller)).
+[Template Controller]({{% ref "docs/template-controller" %}}) ([Source](https://github.com/kluctl/template-controller)).
 The second purpose is to demonstrate it by setting up a simple GitOps based Kubernetes deployment with dynamic preview
 environments.
 
@@ -27,18 +27,18 @@ from a list of generators (e.g. Git) and an `Application` template.
 
 The Template Controller uses a different approach, making it more flexible and independent of the GitOps system being
 used. It uses arbitrary Kubernetes objects as inputs and allows to create templated objects of any kind 
-(e.g. a Flux Helm Release or a [KluctlDeployment]({{< ref "docs/gitops/spec/v1beta1/kluctldeployment" >}})).
+(e.g. a Flux Helm Release or a [KluctlDeployment]({{% ref "docs/gitops/spec/v1beta1/kluctldeployment" %}})).
 This makes the controller very extensible, as any type of input can be implemented with the help of additional
 controllers which are not necessarily part of the project.
 
 When specifying the input objects, you'd also specify which part of the object to use as input. This is done by
 specifying a [JSON Path](https://goessner.net/articles/JsonPath/) that select the subfield of the object to use, e.g.
-`status.result` for a [GitProjector]({{< ref "docs/template-controller/spec/v1alpha1/gitprojector" >}}) or
+`status.result` for a [GitProjector]({{% ref "docs/template-controller/spec/v1alpha1/gitprojector" %}}) or
 `data` for a ConfigMap.
 
-The Template Controller implements this functionality through the [ObjectTemplate]({{< ref "docs/template-controller/spec/v1alpha1/objecttemplate" >}})
+The Template Controller implements this functionality through the [ObjectTemplate]({{% ref "docs/template-controller/spec/v1alpha1/objecttemplate" %}})
 CRD. As the name implies, it also uses a templating engine, which is identical to the one used in
-[Kluctl]({{< ref "docs/kluctl/templating" >}}), with the `ObjectTemplate's` input matrix available as
+[Kluctl]({{% ref "docs/kluctl/templating" %}}), with the `ObjectTemplate's` input matrix available as
 global variables.
 
 ## Preparation
@@ -143,7 +143,7 @@ when a pull request introduces changes that need to be tested before these are m
 In a GitOps-based setup, one would need to create the relevant custom resources per preview environment, for example
 a [Flux Kustomization](https://fluxcd.io/flux/components/kustomize/kustomization/),
 [Flux HelmRelease](https://fluxcd.io/flux/components/helm/helmreleases/) or a
-or [KluctlDeployment]({{< ref "docs/gitops/spec/v1beta1/kluctldeployment" >}}). The underlying GitOps controller
+or [KluctlDeployment]({{% ref "docs/gitops/spec/v1beta1/kluctldeployment" %}}). The underlying GitOps controller
 would then take over and perform the actual deployment.
 
 In the following examples we will concentrate on using `KluctlDeployments`. Changing it to use `Kustomizations` or
@@ -155,7 +155,7 @@ be described in the next chapters.
 ## Linking Preview Environments to Branches
 You can, for example, link Git branches to preview environments, so that for each new branch a preview environment is
 created, with configuration being read from a yaml file inside the branch. This can be achieved by using a
-[GitProjector]({{< ref "docs/template-controller/spec/v1alpha1/gitprojector" >}}), which will periodically
+[GitProjector]({{% ref "docs/template-controller/spec/v1alpha1/gitprojector" %}}), which will periodically
 clone the configured Git repository, scan for matching branches and files and project the result into the `GitProjector`
 status. The status is then available as matrix input inside the `ObjectTemplate`.
 
@@ -235,7 +235,7 @@ spec:
 Please note the use of templating variables and filters inside the actual template under `spec.templates`. Each template
 will be rendered once per matrix input, which in this case means once per branch. The templates can use the current
 matrix input in the form of a variable, accessible via `matrix.<name>`, e.g. `matrix.git` in this case. Please read
-the documentation of [GitProjector]({{< ref "docs/template-controller/spec/v1alpha1/gitprojector" >}}) to figure
+the documentation of [GitProjector]({{% ref "docs/template-controller/spec/v1alpha1/gitprojector" %}}) to figure
 out what is available in `matrix.git`, which is basically just a copy of the individual `status.result` list items.
 
 ## One Preview Environment per pull requests
@@ -244,8 +244,8 @@ be useful if you want to report the status of your preview environment to the pu
 commit status when the deployment turns green or red. One might also want to post complex status comments, for example
 the result of the deployment in the form of structured and beautiful diff.
 
-To achieve this, you can use the [ListGithubPullRequests]({{< ref "docs/template-controller/spec/v1alpha1/listgithubpullrequests" >}})
-or the [ListGitlabMergeRequests]({{< ref "docs/template-controller/spec/v1alpha1/listgitlabmergerequests" >}})
+To achieve this, you can use the [ListGithubPullRequests]({{% ref "docs/template-controller/spec/v1alpha1/listgithubpullrequests" %}})
+or the [ListGitlabMergeRequests]({{% ref "docs/template-controller/spec/v1alpha1/listgitlabmergerequests" %}})
 custom resource, which are also provided by the Template Controller.
 
 Consider the following example: