From b7b1adefb9e33999bb930cd841f6c80f41540d01 Mon Sep 17 00:00:00 2001 From: Jared Watts Date: Mon, 8 Apr 2024 12:15:50 +0200 Subject: [PATCH] Update README steps for install and local development Signed-off-by: Jared Watts --- Makefile | 1 - README.md | 108 ++++++++++-------- build | 2 +- .../provider-config/provider-incluster.yaml | 2 +- examples/sample/release.yaml | 2 +- 5 files changed, 62 insertions(+), 53 deletions(-) diff --git a/Makefile b/Makefile index 2a8f2ea..1274779 100644 --- a/Makefile +++ b/Makefile @@ -33,7 +33,6 @@ GOLANGCILINT_VERSION = 1.55.2 # ==================================================================================== # Setup Kubernetes tools -UP_VERSION = v0.21.0 UP_CHANNEL = stable KIND_NODE_IMAGE_TAG ?= v1.24.0 USE_HELM3 = true diff --git a/README.md b/README.md index b2b4580..582c3a6 100644 --- a/README.md +++ b/README.md @@ -5,11 +5,12 @@ # provider-helm `provider-helm` is a Crossplane Provider that enables deployment and management -of Helm Releases on Kubernetes clusters typically provisioned by Crossplane: +of Helm Releases on Kubernetes clusters typically provisioned by Crossplane, and +has the following functionality: -- A `Provider` resource type that only points to a credentials `Secret`. -- A `Release` resource type that is to manage Helm Releases. -- A managed resource controller that reconciles `Release` objects and manages Helm releases. +- A `Release` resource type to manage Helm Releases. +- A managed resource controller that reconciles `Release` objects and manages + Helm releases. ## Install @@ -18,70 +19,79 @@ so using the Crossplane CLI in a Kubernetes cluster where Crossplane is installed: ```console -kubectl crossplane install provider crossplanecontrib/provider-helm:master +crossplane xpkg install provider xpkg.upbound.io/crossplane-contrib/provider-helm:v0.17.0 ``` -You may also manually install `provider-helm` by creating a `Provider` directly: +Then you will need to create a `ProviderConfig` that specifies the credentials +to connect to the Kubernetes API. This is commonly done within a `Composition` +by storing a `kubeconfig` into a secret that the `ProviderConfig` references. An +example of this approach can be found in +[`configuration-aws-eks`](https://github.com/upbound/configuration-aws-eks/blob/release-0.7/apis/composition.yaml#L427-L452). -```yaml -apiVersion: pkg.crossplane.io/v1 -kind: Provider -metadata: - name: provider-helm -spec: - package: "crossplanecontrib/provider-helm:master" +### Quick start + +An alternative, that will get you started quickly, is to reuse existing +credentials from within the control plane. + +First install `provider-helm` with [additional +configuration](./examples/provider-config/provider-incluster.yaml) to bind its +service account to an existing role in the cluster: + +```console +kubectl apply -f ./examples/provider-config/provider-incluster.yaml +``` + +Then simply create a +[`ProviderConfig`](./examples/provider-config/provider-config-incluster.yaml) +that uses an `InjectedIdentity` source: + +```console +kubectl apply -f ./examples/provider-config/provider-config-incluster.yaml +``` + +`provider-helm` will then be installed and ready to use within the cluster. You +can now create `Release` resources, such as [sample +release.yaml](examples/sample/release.yaml). + +```console +kubectl create -f examples/sample/release.yaml ``` ## Design -See [the design document](https://github.com/crossplane/crossplane/blob/master/design/one-pager-helm-provider.md). +See [the design +document](https://github.com/crossplane/crossplane/blob/master/design/one-pager-helm-provider.md). ## Developing locally -Start a local development environment with Kind where `crossplane` is installed: - -``` -make local-dev -``` +**Pre-requisite:** A Kubernetes cluster with Crossplane installed -Run controller against the cluster: +To run the `provider-helm` controller against your existing local cluster, +simply run: -``` +```console make run ``` -Since controller is running outside of the Kind cluster, you need to make api server accessible (on a separate terminal): +Since the controller is running outside of the local cluster, you need to make +the API server accessible (on a separate terminal): -``` +```console sudo kubectl proxy --port=8081 ``` -### Testing in Local Cluster - -1. Prepare provider config for local cluster: - 1. If helm provider running in cluster (e.g. provider installed with crossplane): - - ``` - SA=$(kubectl -n crossplane-system get sa -o name | grep provider-helm | sed -e 's|serviceaccount\/|crossplane-system:|g') - kubectl create clusterrolebinding provider-helm-admin-binding --clusterrole cluster-admin --serviceaccount="${SA}" - kubectl apply -f examples/provider-config/provider-config-incluster.yaml - ``` - 1. If provider helm running outside of the cluster (e.g. running locally with `make run`) - - ``` - KUBECONFIG=$(kind get kubeconfig --name local-dev | sed -e 's|server:\s*.*$|server: http://localhost:8081|g') - kubectl -n crossplane-system create secret generic cluster-config --from-literal=kubeconfig="${KUBECONFIG}" - kubectl apply -f examples/provider-config/provider-config-with-secret.yaml - ``` - -1. Now you can create `Release` resources with provider reference, see [sample release.yaml](examples/sample/release.yaml). +Then we must prepare a `ProviderConfig` for the local cluster (assuming you are +using `kind` for local development): - ``` - kubectl create -f examples/sample/release.yaml - ``` +```console +KUBECONFIG=$(kind get kubeconfig | sed -e 's|server:\s*.*$|server: http://localhost:8081|g') +kubectl -n crossplane-system create secret generic cluster-config --from-literal=kubeconfig="${KUBECONFIG}" +kubectl apply -f examples/provider-config/provider-config-with-secret.yaml +``` -### Cleanup +Now you can create `Release` resources with this `ProviderConfig`, for example +[sample release.yaml](examples/sample/release.yaml). -``` -make local.down -``` +```console +kubectl create -f examples/sample/release.yaml +``` \ No newline at end of file diff --git a/build b/build index 75a9fe3..cdee006 160000 --- a/build +++ b/build @@ -1 +1 @@ -Subproject commit 75a9fe3ae6b6de82c5f7ddc6a267617940f16b83 +Subproject commit cdee00685cfc90fce40d3f6a5eb9c8f044edbaa3 diff --git a/examples/provider-config/provider-incluster.yaml b/examples/provider-config/provider-incluster.yaml index af441a3..9a33af8 100644 --- a/examples/provider-config/provider-incluster.yaml +++ b/examples/provider-config/provider-incluster.yaml @@ -3,7 +3,7 @@ kind: Provider metadata: name: provider-helm spec: - package: xpkg.upbound.io/crossplane-contrib/provider-helm:v0.16.0 + package: xpkg.upbound.io/crossplane-contrib/provider-helm:v0.17.0 runtimeConfigRef: apiVersion: pkg.crossplane.io/v1beta1 kind: DeploymentRuntimeConfig diff --git a/examples/sample/release.yaml b/examples/sample/release.yaml index c668236..13b6237 100644 --- a/examples/sample/release.yaml +++ b/examples/sample/release.yaml @@ -8,7 +8,7 @@ spec: chart: name: wordpress repository: https://charts.bitnami.com/bitnami - version: 15.2.5 ## To use devlopment versions, set ">0.0.0-0" + version: 15.2.5 ## To use development versions, set ">0.0.0-0" # pullSecretRef: # name: museum-creds # namespace: default