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.

Sign up for GitHub

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
+93 −0
Merged

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

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
9311595
Use CAPI capability of Flux's HelmRelease to install apps into target…
wahabmk Aug 22, 2024
8206e8c
Make installation into target cluster optional via .Values.installApps
wahabmk Aug 26, 2024
0859873
Enable installation of apps into target cluster true for dev
wahabmk Aug 27, 2024
a5de0c3
Rename installApps to installBeachHeadServices
wahabmk Aug 27, 2024
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
11 changes: 11 additions & 0 deletions templates/aws-standalone-cp/README.md
View file
Open in desktop
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` to be installed into the target cluster:
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
40 changes: 40 additions & 0 deletions templates/aws-standalone-cp/templates/apps/cert-manager.yaml
View file
Open in desktop
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 •
edited
Loading

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,40 @@
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"
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 automatic upgrades here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah good point. I should remove the >= and just pin it to a specific version.

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 not have auto updates, let's pin it.

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
34 changes: 34 additions & 0 deletions templates/aws-standalone-cp/templates/apps/nginx-ingress.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
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 •
edited
Loading

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