New HelmOps Controller #2962
Comments
Closed
Closed
0xavi0
added a commit
to 0xavi0/fleet
that referenced
this issue
Nov 22, 2024
It adds a new custom resource `HelmApp` (resource name open to debate) that describes a helm chart to be deployed.
The resource contains all the fealds from the classic `fleet.yaml` file plus a few new from the `GitRepo`
resource.
`HelmApp` yaml example:
```yaml
apiVersion: fleet.cattle.io/v1alpha1
kind: HelmApp
metadata:
name: sample1
namespace: fleet-local
spec:
helm:
releaseName: testhelm
repo: https://charts.bitnami.com/bitnami
chart: postgresql
version: 16.2.1
insecureSkipTLSVerify: true
```
The implementation tries to share as much as possible from a `Bundle` spec inside the new resource, because it helps
to "transform" the `HelmApp` into a deployment (no coversion is needed for most of the spec).
The new controller was also implemented splitting the functionality into 2 controllers (similar to what we did for the `GitRepo` controller). This allows us to reuse most of the status handling code, as display fields in the status of the new resource are as similar as possible to have consistent user experience and to integrate with the UI in the same way the `GitRepo` does.
When a new `HelmApp` resource is applied it is transformed into a single `Bundle`, adding some extra fields to let the `Bundle` reconciler know that this is not a regular `Bundle` coming from a `GitRepo`.
Similar as we did for OCI storage, the `Bundle` created from a `HelmApp` does not contain resources. The helm chart to be deployed is downloaded by the agent.
Code for downloading the helm chart is reused from gitops, so the same formats are supported.
Insecure TLS skipping was added the the ChartURL and LoadDirectory functions in order to support this for gitops and helmops.
If we need a secret to access the helm repository we can use the `helmSecretName` field. This secret will be cloned to secrets under the `BundleDeployment` namespace (same as we did for the OCI storage secret handling).
The PR includes unit, integration (most of code is tested this way) and just one single e2e test so far just to test the whole feature together in a real cluster.
Note: This is an experimental feature. In order to activate the `HelmApp` reconciling and `Bundle` deployment you need to the the environment variable: `EXPERIMENTAL_HELM_OPS=true`
Refers to: rancher#2962
0xavi0
added a commit
to 0xavi0/fleet
that referenced
this issue
Nov 22, 2024
It adds a new custom resource `HelmApp` (resource name open to debate) that describes a helm chart to be deployed.
The resource contains all the fealds from the classic `fleet.yaml` file plus a few new from the `GitRepo`
resource.
`HelmApp` yaml example:
```yaml
apiVersion: fleet.cattle.io/v1alpha1
kind: HelmApp
metadata:
name: sample1
namespace: fleet-local
spec:
helm:
releaseName: testhelm
repo: https://charts.bitnami.com/bitnami
chart: postgresql
version: 16.2.1
insecureSkipTLSVerify: true
```
The implementation tries to share as much as possible from a `Bundle` spec inside the new resource, because it helps
to "transform" the `HelmApp` into a deployment (no coversion is needed for most of the spec).
The new controller was also implemented splitting the functionality into 2 controllers (similar to what we did for the `GitRepo` controller). This allows us to reuse most of the status handling code, as display fields in the status of the new resource are as similar as possible to have consistent user experience and to integrate with the UI in the same way the `GitRepo` does.
When a new `HelmApp` resource is applied it is transformed into a single `Bundle`, adding some extra fields to let the `Bundle` reconciler know that this is not a regular `Bundle` coming from a `GitRepo`.
Similar as we did for OCI storage, the `Bundle` created from a `HelmApp` does not contain resources. The helm chart to be deployed is downloaded by the agent.
Code for downloading the helm chart is reused from gitops, so the same formats are supported.
Insecure TLS skipping was added the the ChartURL and LoadDirectory functions in order to support this for gitops and helmops.
If we need a secret to access the helm repository we can use the `helmSecretName` field. This secret will be cloned to secrets under the `BundleDeployment` namespace (same as we did for the OCI storage secret handling).
The PR includes unit, integration (most of code is tested this way) and just one single e2e test so far just to test the whole feature together in a real cluster.
Note: This is an experimental feature. In order to activate the `HelmApp` reconciling and `Bundle` deployment you need to the the environment variable: `EXPERIMENTAL_HELM_OPS=true`
Refers to: rancher#2962
0xavi0
added a commit
to 0xavi0/fleet
that referenced
this issue
Nov 25, 2024
It adds a new custom resource `HelmApp` (resource name open to debate) that describes a helm chart to be deployed.
The resource contains all the fealds from the classic `fleet.yaml` file plus a few new from the `GitRepo`
resource.
`HelmApp` yaml example:
```yaml
apiVersion: fleet.cattle.io/v1alpha1
kind: HelmApp
metadata:
name: sample1
namespace: fleet-local
spec:
helm:
releaseName: testhelm
repo: https://charts.bitnami.com/bitnami
chart: postgresql
version: 16.2.1
insecureSkipTLSVerify: true
```
The implementation tries to share as much as possible from a `Bundle` spec inside the new resource, because it helps
to "transform" the `HelmApp` into a deployment (no coversion is needed for most of the spec).
The new controller was also implemented splitting the functionality into 2 controllers (similar to what we did for the `GitRepo` controller). This allows us to reuse most of the status handling code, as display fields in the status of the new resource are as similar as possible to have consistent user experience and to integrate with the UI in the same way the `GitRepo` does.
When a new `HelmApp` resource is applied it is transformed into a single `Bundle`, adding some extra fields to let the `Bundle` reconciler know that this is not a regular `Bundle` coming from a `GitRepo`.
Similar as we did for OCI storage, the `Bundle` created from a `HelmApp` does not contain resources. The helm chart to be deployed is downloaded by the agent.
Code for downloading the helm chart is reused from gitops, so the same formats are supported.
Insecure TLS skipping was added the the ChartURL and LoadDirectory functions in order to support this for gitops and helmops.
If we need a secret to access the helm repository we can use the `helmSecretName` field. This secret will be cloned to secrets under the `BundleDeployment` namespace (same as we did for the OCI storage secret handling).
The PR includes unit, integration (most of code is tested this way) and just one single e2e test so far just to test the whole feature together in a real cluster.
Note: This is an experimental feature. In order to activate the `HelmApp` reconciling and `Bundle` deployment you need to the the environment variable: `EXPERIMENTAL_HELM_OPS=true`
Refers to: rancher#2962
0xavi0
added a commit
to 0xavi0/fleet
that referenced
this issue
Nov 25, 2024
It adds a new custom resource `HelmApp` (resource name open to debate) that describes a helm chart to be deployed.
The resource contains all the fealds from the classic `fleet.yaml` file plus a few new from the `GitRepo`
resource.
`HelmApp` yaml example:
```yaml
apiVersion: fleet.cattle.io/v1alpha1
kind: HelmApp
metadata:
name: sample1
namespace: fleet-local
spec:
helm:
releaseName: testhelm
repo: https://charts.bitnami.com/bitnami
chart: postgresql
version: 16.2.1
insecureSkipTLSVerify: true
```
The implementation tries to share as much as possible from a `Bundle` spec inside the new resource, because it helps
to "transform" the `HelmApp` into a deployment (no coversion is needed for most of the spec).
The new controller was also implemented splitting the functionality into 2 controllers (similar to what we did for the `GitRepo` controller). This allows us to reuse most of the status handling code, as display fields in the status of the new resource are as similar as possible to have consistent user experience and to integrate with the UI in the same way the `GitRepo` does.
When a new `HelmApp` resource is applied it is transformed into a single `Bundle`, adding some extra fields to let the `Bundle` reconciler know that this is not a regular `Bundle` coming from a `GitRepo`.
Similar as we did for OCI storage, the `Bundle` created from a `HelmApp` does not contain resources. The helm chart to be deployed is downloaded by the agent.
Code for downloading the helm chart is reused from gitops, so the same formats are supported.
Insecure TLS skipping was added the the ChartURL and LoadDirectory functions in order to support this for gitops and helmops.
If we need a secret to access the helm repository we can use the `helmSecretName` field. This secret will be cloned to secrets under the `BundleDeployment` namespace (same as we did for the OCI storage secret handling).
The PR includes unit, integration (most of code is tested this way) and just one single e2e test so far just to test the whole feature together in a real cluster.
Note: This is an experimental feature. In order to activate the `HelmApp` reconciling and `Bundle` deployment you need to the the environment variable: `EXPERIMENTAL_HELM_OPS=true`
Refers to: rancher#2962
0xavi0
added a commit
to 0xavi0/fleet
that referenced
this issue
Nov 25, 2024
It adds a new custom resource `HelmApp` (resource name open to debate) that describes a helm chart to be deployed.
The resource contains all the fealds from the classic `fleet.yaml` file plus a few new from the `GitRepo`
resource.
`HelmApp` yaml example:
```yaml
apiVersion: fleet.cattle.io/v1alpha1
kind: HelmApp
metadata:
name: sample1
namespace: fleet-local
spec:
helm:
releaseName: testhelm
repo: https://charts.bitnami.com/bitnami
chart: postgresql
version: 16.2.1
insecureSkipTLSVerify: true
```
The implementation tries to share as much as possible from a `Bundle` spec inside the new resource, because it helps
to "transform" the `HelmApp` into a deployment (no coversion is needed for most of the spec).
The new controller was also implemented splitting the functionality into 2 controllers (similar to what we did for the `GitRepo` controller). This allows us to reuse most of the status handling code, as display fields in the status of the new resource are as similar as possible to have consistent user experience and to integrate with the UI in the same way the `GitRepo` does.
When a new `HelmApp` resource is applied it is transformed into a single `Bundle`, adding some extra fields to let the `Bundle` reconciler know that this is not a regular `Bundle` coming from a `GitRepo`.
Similar as we did for OCI storage, the `Bundle` created from a `HelmApp` does not contain resources. The helm chart to be deployed is downloaded by the agent.
Code for downloading the helm chart is reused from gitops, so the same formats are supported.
Insecure TLS skipping was added the the ChartURL and LoadDirectory functions in order to support this for gitops and helmops.
If we need a secret to access the helm repository we can use the `helmSecretName` field. This secret will be cloned to secrets under the `BundleDeployment` namespace (same as we did for the OCI storage secret handling).
The PR includes unit, integration (most of code is tested this way) and just one single e2e test so far just to test the whole feature together in a real cluster.
Note: This is an experimental feature. In order to activate the `HelmApp` reconciling and `Bundle` deployment you need to the the environment variable: `EXPERIMENTAL_HELM_OPS=true`
Refers to: rancher#2962
0xavi0
added a commit
to 0xavi0/fleet
that referenced
this issue
Nov 26, 2024
It adds a new custom resource `HelmApp` (resource name open to debate) that describes a helm chart to be deployed.
The resource contains all the fealds from the classic `fleet.yaml` file plus a few new from the `GitRepo`
resource.
`HelmApp` yaml example:
```yaml
apiVersion: fleet.cattle.io/v1alpha1
kind: HelmApp
metadata:
name: sample1
namespace: fleet-local
spec:
helm:
releaseName: testhelm
repo: https://charts.bitnami.com/bitnami
chart: postgresql
version: 16.2.1
insecureSkipTLSVerify: true
```
The implementation tries to share as much as possible from a `Bundle` spec inside the new resource, because it helps
to "transform" the `HelmApp` into a deployment (no coversion is needed for most of the spec).
The new controller was also implemented splitting the functionality into 2 controllers (similar to what we did for the `GitRepo` controller). This allows us to reuse most of the status handling code, as display fields in the status of the new resource are as similar as possible to have consistent user experience and to integrate with the UI in the same way the `GitRepo` does.
When a new `HelmApp` resource is applied it is transformed into a single `Bundle`, adding some extra fields to let the `Bundle` reconciler know that this is not a regular `Bundle` coming from a `GitRepo`.
Similar as we did for OCI storage, the `Bundle` created from a `HelmApp` does not contain resources. The helm chart to be deployed is downloaded by the agent.
Code for downloading the helm chart is reused from gitops, so the same formats are supported.
Insecure TLS skipping was added the the ChartURL and LoadDirectory functions in order to support this for gitops and helmops.
If we need a secret to access the helm repository we can use the `helmSecretName` field. This secret will be cloned to secrets under the `BundleDeployment` namespace (same as we did for the OCI storage secret handling).
The PR includes unit, integration (most of code is tested this way) and just one single e2e test so far just to test the whole feature together in a real cluster.
Note: This is an experimental feature. In order to activate the `HelmApp` reconciling and `Bundle` deployment you need to the the environment variable: `EXPERIMENTAL_HELM_OPS=true`
Refers to: rancher#2962
0xavi0
added a commit
to 0xavi0/fleet
that referenced
this issue
Nov 27, 2024
It adds a new custom resource `HelmApp` (resource name open to debate) that describes a helm chart to be deployed.
The resource contains all the fealds from the classic `fleet.yaml` file plus a few new from the `GitRepo`
resource.
`HelmApp` yaml example:
```yaml
apiVersion: fleet.cattle.io/v1alpha1
kind: HelmApp
metadata:
name: sample1
namespace: fleet-local
spec:
helm:
releaseName: testhelm
repo: https://charts.bitnami.com/bitnami
chart: postgresql
version: 16.2.1
insecureSkipTLSVerify: true
```
The implementation tries to share as much as possible from a `Bundle` spec inside the new resource, because it helps
to "transform" the `HelmApp` into a deployment (no coversion is needed for most of the spec).
The new controller was also implemented splitting the functionality into 2 controllers (similar to what we did for the `GitRepo` controller). This allows us to reuse most of the status handling code, as display fields in the status of the new resource are as similar as possible to have consistent user experience and to integrate with the UI in the same way the `GitRepo` does.
When a new `HelmApp` resource is applied it is transformed into a single `Bundle`, adding some extra fields to let the `Bundle` reconciler know that this is not a regular `Bundle` coming from a `GitRepo`.
Similar as we did for OCI storage, the `Bundle` created from a `HelmApp` does not contain resources. The helm chart to be deployed is downloaded by the agent.
Code for downloading the helm chart is reused from gitops, so the same formats are supported.
Insecure TLS skipping was added the the ChartURL and LoadDirectory functions in order to support this for gitops and helmops.
If we need a secret to access the helm repository we can use the `helmSecretName` field. This secret will be cloned to secrets under the `BundleDeployment` namespace (same as we did for the OCI storage secret handling).
The PR includes unit, integration (most of code is tested this way) and just one single e2e test so far just to test the whole feature together in a real cluster.
Note: This is an experimental feature. In order to activate the `HelmApp` reconciling and `Bundle` deployment you need to the the environment variable: `EXPERIMENTAL_HELM_OPS=true`
Refers to: rancher#2962
0xavi0
added a commit
to 0xavi0/fleet
that referenced
this issue
Nov 27, 2024
It adds a new custom resource `HelmApp` (resource name open to debate) that describes a helm chart to be deployed.
The resource contains all the fealds from the classic `fleet.yaml` file plus a few new from the `GitRepo`
resource.
`HelmApp` yaml example:
```yaml
apiVersion: fleet.cattle.io/v1alpha1
kind: HelmApp
metadata:
name: sample1
namespace: fleet-local
spec:
helm:
releaseName: testhelm
repo: https://charts.bitnami.com/bitnami
chart: postgresql
version: 16.2.1
insecureSkipTLSVerify: true
```
The implementation tries to share as much as possible from a `Bundle` spec inside the new resource, because it helps
to "transform" the `HelmApp` into a deployment (no coversion is needed for most of the spec).
The new controller was also implemented splitting the functionality into 2 controllers (similar to what we did for the `GitRepo` controller). This allows us to reuse most of the status handling code, as display fields in the status of the new resource are as similar as possible to have consistent user experience and to integrate with the UI in the same way the `GitRepo` does.
When a new `HelmApp` resource is applied it is transformed into a single `Bundle`, adding some extra fields to let the `Bundle` reconciler know that this is not a regular `Bundle` coming from a `GitRepo`.
Similar as we did for OCI storage, the `Bundle` created from a `HelmApp` does not contain resources. The helm chart to be deployed is downloaded by the agent.
Code for downloading the helm chart is reused from gitops, so the same formats are supported.
Insecure TLS skipping was added the the ChartURL and LoadDirectory functions in order to support this for gitops and helmops.
If we need a secret to access the helm repository we can use the `helmSecretName` field. This secret will be cloned to secrets under the `BundleDeployment` namespace (same as we did for the OCI storage secret handling).
The PR includes unit, integration (most of code is tested this way) and just one single e2e test so far just to test the whole feature together in a real cluster.
Note: This is an experimental feature. In order to activate the `HelmApp` reconciling and `Bundle` deployment you need to the the environment variable: `EXPERIMENTAL_HELM_OPS=true`
Refers to: rancher#2962
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Users want to use Fleet to deploy Helm charts directly. That way they can use Fleet as a multi-cluster deployer.
Fleet is already able to deploy to all clusters registered to Rancher.
However, currently Fleet is only able to deploy from Git or “Bundle”. To deploy from Git the configuration has to be entered in both Rancher (where is the Git repository) and in Git (what to deploy and how to configure it).
To deploy from “Bundle”, helm charts have to be converted with the Fleet CLI tool first. This is possible for internal usage, but didn’t become popular in the wider community.
Description
We create a new resource, e.g. “Fleet CRD”, which contains most of the fields from fleet.yaml and some from GitRepo CRD.
When the new CRD changes, we install/update the chart. This makes use of the existing pull based mechanism, without storing the chart in k8s resources. The agent will download the chart directly from the container registry.
Fields from GitRepo
UI
Since all fields are configurable in the CRD, this allows for a rich UI. In the GitOps UI, only the Git repository server and a few fields can be configured. The Fleet CRD allows full control over the installation through all fields that were previously only available in the fleet.yaml.
For example:
Future Ideas
Not part of the first iteration:
Implementation
Create the FleetCRD and a new reconciler which will create a bundle similar to how OCI storage works. The fleet-agent needs to pull and deploy that bundle type without the helm conversion.
The text was updated successfully, but these errors were encountered: