Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use CAPI capability of Flux's HelmRelease to install apps into target cluster #226

Merged
merged 4 commits into from
Aug 29, 2024
Merged
Show file tree
Hide file tree
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions config/dev/deployment.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -15,3 +15,4 @@ spec:
worker:
amiID: ami-02f3416038bdb17fb
instanceType: t3.small
installApps: true
11 changes: 11 additions & 0 deletions templates/aws-standalone-cp/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,11 @@
## Install applications into Target Cluster

To install applications into the target cluster created using Cluster API (CAPI) upon creation, a Flux `HelmRelease` object is to be made such that its `.spec.KubeConfig` references the kubeconfig of the target cluster.

**Reference:** https://fluxcd.io/flux/components/helm/helmreleases/#remote-clusters--cluster-api

This chart/template already defines the following applications under `templates/apps` which can be be installed into the target cluster by setting `.Values.installApps=true`:
1. cert-manager
2. nginx-ingress

**Important:** The Flux objects added to `templates/apps` to install custom applications must have the `hmc.mirantis.com/managed: "true"` label to be reconciled by HMC.
Schnitzel marked this conversation as resolved.
Show resolved Hide resolved
42 changes: 42 additions & 0 deletions templates/aws-standalone-cp/templates/apps/cert-manager.yaml
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Schnitzel @wahabmk Do we want to keep it as an example just for one template? If not, I think we'd better separate it as a subchart and inject it into all of our templates.

Copy link
Contributor Author

@wahabmk wahabmk Aug 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is a good idea to separate out the YAML for installing custom apps and injecting it into all HMC templates. We could do it either:

  1. By creating hmc/templates/apps folder with the app YAMLs (nginx, cert-manager, etc) and extending the templates-generate make target to copy the YAML files from hmc/templates/apps/ into each HMC template under hmc/templates/<template-name>/templates/apps/. This way we won't have to manage and version a separate helm chart for the apps (if that is desirable).
  2. Or we could make a separate Helm chart (perhaps library chart) with the app YAMLs and include it as a versioned subchart dependency into each HMC template.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm ok with having it right now inside a specific template without a subchart or anything. We're are doing this first version really to just to proof that we can install helmcharts into a target cluster from a template. So lets get it in as we have it here.

The whole thing of having helmcharts installed across all clusters will come with the extended version of State Management that Martin and I are working on defining.

Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
{{- if .Values.installApps }}
apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
name: cert-manager
labels:
hmc.mirantis.com/managed: "true"
spec:
interval: 24h
url: https://charts.jetstack.io
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
name: {{ include "cluster.name" . }}-cert-manager
labels:
hmc.mirantis.com/managed: "true"
spec:
chart:
metadata:
labels:
hmc.mirantis.com/managed: "true"
spec:
chart: cert-manager
version: "v1.12.3"
sourceRef:
kind: HelmRepository
name: cert-manager
install:
createNamespace: true
remediation:
retries: -1
interval: 10m
kubeConfig:
secretRef:
name: {{ include "cluster.name" . }}-kubeconfig
releaseName: cert-manager
targetNamespace: cert-manager
storageNamespace: cert-manager
values:
installCRDs: true
{{- end }}
36 changes: 36 additions & 0 deletions templates/aws-standalone-cp/templates/apps/nginx-ingress.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,36 @@
{{- if .Values.installApps }}
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: OCIRepository
metadata:
name: nginx-ingress
labels:
hmc.mirantis.com/managed: "true"
spec:
interval: 24h
url: oci://ghcr.io/nginxinc/charts/nginx-ingress
ref:
semver: "1.3.2"
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
name: {{ include "cluster.name" . }}-nginx-ingress
labels:
hmc.mirantis.com/managed: "true"
spec:
targetNamespace: nginx-ingress
storageNamespace: nginx-ingress
kubeConfig:
secretRef:
name: {{ include "cluster.name" . }}-kubeconfig
interval: 10m
chartRef:
kind: OCIRepository
name: nginx-ingress
install:
createNamespace: true
remediation:
retries: -1
values:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Schnitzel @wahabmk Do we want to allow overrides for some/all values? I think it also makes sense to allow enabling/disabling of those releases.

Copy link
Contributor Author

@wahabmk wahabmk Aug 26, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to allow overrides for some/all values?

I am leaning towards the opinion that we should not control what value overrides to allow/disallow for these apps. Reason being that if we want these HMC templates to be publicly available, anybody should be able to override these values (as per their needs) to values other than what we have used or unused as default.

I think it also makes sense to allow enabling/disabling of those releases.

Agreed

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea agree we should let the customer overwrite anything they want (especially in this current iteration). In the future we might have tighter managed templates by mirantis that will not allow any changes, but here it's ok.

fullnameOverride: nginx-ingress
{{- end }}
4 changes: 4 additions & 0 deletions templates/aws-standalone-cp/values.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -44,3 +44,7 @@ worker:
# K0s parameters
k0s:
version: v1.30.2+k0s.0

# Optionally install apps defined under
# templates/apps into target cluster
installApps: false
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we make this by default true? I think its just easier to demo.
Also let's rename installApps to installBeachHeadServices which is the term we want to use for these type of applications

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wahabmk Oh also, can we rename the folder templates/apps to templates/beachheadservices