From b31a3b363f7ed36a037d8c35c93a142304a8bd51 Mon Sep 17 00:00:00 2001 From: Stefan Prodan Date: Sat, 17 Nov 2018 14:09:58 +0200 Subject: [PATCH 1/9] Update chart readme - remove helm-op git flags - fix typos - set example repo to weaveworks/flux-get-started - use the same git URL format everywhere --- chart/flux/README.md | 37 ++++++++++++++----------------------- 1 file changed, 14 insertions(+), 23 deletions(-) diff --git a/chart/flux/README.md b/chart/flux/README.md index 8cd5ff180..5edf00a26 100755 --- a/chart/flux/README.md +++ b/chart/flux/README.md @@ -14,10 +14,10 @@ a [Kubernetes](http://kubernetes.io) cluster using the [Helm](https://helm.sh) p ### Kubernetes -Kubernetes >= v1.9 is recommended. Kubernetes v1.8 (the first to support +Kubernetes >= v1.10 is recommended. Kubernetes v1.8 (the first to support Custom Resources) appears to have problems with repeated application of custom resources (see https://github.com/kubernetes/kubernetes/issues/53379). -This means fluxd can fail to apply changes to FluxHelmRelease resources. +This means fluxd can fail to apply changes to HelmRelease resources. ### Helm @@ -27,24 +27,20 @@ until it can find one. # Git repo - - One repo containing both desired release state information and Charts + - One repo containing desired release state information and Charts themselves. - - Release state information in the form of Custom Resources manifests is - located under a particular path ("releaseconfig" by default; can be - overriden). - - Charts are colocated under another path ("charts" by default; can be - overriden). Charts are subdirectories under the charts path. + - Charts are collocated under another path ("charts" by default; can be + overridden). Charts are subdirectories under the charts path. - Custom Resource namespace reflects where the release should be done. Both the Helm release and its corresponding Custom Resource will live in this namespace. - - Example of a test repo: https://github.com/weaveworks/flux-helm-test + - Example of a test repo: https://github.com/weaveworks/flux-get-started ## Installation We put together a simple [Get Started guide](../../site/helm-get-started.md) which takes about 5-10 minutes to follow. -You will have a fully working Flux installation deploying workloads to your -cluster. +You will have a fully working Flux installation deploying workloads to your cluster. ## Installing Flux using Helm @@ -60,7 +56,7 @@ helm repo add weaveworks https://weaveworks.github.io/flux ```sh $ helm install --name flux \ ---set git.url=ssh://git@github.com/weaveworks/flux-example \ +--set git.url=git@github.com:weaveworks/flux-get-started \ --namespace flux \ weaveworks/flux ``` @@ -69,6 +65,7 @@ weaveworks/flux ```sh helm install --name flux \ +--set git.url=git@github.com:weaveworks/flux-get-started \ --set token=YOUR_WEAVE_CLOUD_SERVICE_TOKEN \ --namespace flux \ weaveworks/flux @@ -78,7 +75,7 @@ weaveworks/flux ```sh $ helm install --name flux \ ---set git.url=ssh://git@github.com/weaveworks/flux-helm-test \ +--set git.url=git@github.com:weaveworks/flux-get-started \ --set helmOperator.create=true \ --namespace flux \ weaveworks/flux @@ -117,7 +114,7 @@ using an alternate mechanism. helm install \ --name flux \ --set helmOperator.create=true \ - --set git.url="ssh://git@${YOUR_GIT_HOST}:weaveworks/flux-helm-test.git" \ + --set git.url="git@${YOUR_GIT_HOST}:weaveworks/flux-get-started" \ --set-string ssh.known_hosts="${KNOWN_HOSTS}" \ --namespace flux \ chart/flux @@ -133,7 +130,7 @@ using an alternate mechanism. helm install \ --name flux \ --set helmOperator.create=true \ - --set git.url="ssh://git@${YOUR_GIT_HOST}:weaveworks/flux-helm-test.git" \ + --set git.url="git@${YOUR_GIT_HOST}:weaveworks/flux-get-started" \ --set-file ssh.known_hosts=/tmp/flux_known_hosts \ --namespace flux \ chart/flux @@ -212,12 +209,6 @@ The following tables lists the configurable parameters of the Weave Flux chart a | `helmOperator.chartsSyncInterval` | Interval at which to check for changed charts | `3m` | `helmOperator.chartsSyncTimeout` | Timeout when checking for changed charts | `1m` | `helmOperator.extraEnvs` | Extra environment variables for the Helm operator pod | `[]` -| `helmOperator.git.url` | URL of git repo with Helm charts | `git.url` -| `helmOperator.git.branch` | Branch of git repo to use for Helm charts | `master` -| `helmOperator.git.chartsPath` | Path within git repo to locate Helm charts (relative path) | `charts` -| `helmOperator.git.pollInterval` | Period at which to poll git repo for new commits | `git.pollInterval` -| `helmOperator.git.timeout` | Duration after which git operations time out | `git.timeout` -| `helmOperator.git.secretName` | Kubernetes secret with the SSH private key | None | `helmOperator.logReleaseDiffs` | Helm operator should log the diff when a chart release diverges (possibly insecure) | `false` | `helmOperator.tillerNamespace` | Namespace in which the Tiller server can be found | `kube-system` | `helmOperator.tls.enable` | Enable TLS for communicating with Tiller | `false` @@ -232,7 +223,7 @@ Specify each parameter using the `--set key=value[,key=value]` argument to `helm ```sh $ helm upgrade --install --wait flux \ ---set git.url=ssh://git@github.com/stefanprodan/podinfo \ +--set git.url=git@github.com:stefanprodan/k8s-podinfo \ --set git.path=deploy/auto-scaling,deploy/local-storage \ --namespace flux \ weaveworks/flux @@ -244,6 +235,6 @@ Update Weave Flux version with: ```sh helm upgrade --reuse-values flux \ ---set image.tag=1.7.1 \ +--set image.tag=1.8.1 \ weaveworks/flux ``` From 6eac2dbc0930f55fcf8a137dfc13f1d4f6e39a2a Mon Sep 17 00:00:00 2001 From: Stefan Prodan Date: Sat, 17 Nov 2018 14:38:18 +0200 Subject: [PATCH 2/9] Fix links in Helm integration doc --- site/helm-integration.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/site/helm-integration.md b/site/helm-integration.md index b27fd5ab6..d56c3ec00 100644 --- a/site/helm-integration.md +++ b/site/helm-integration.md @@ -65,9 +65,9 @@ with a `chart:` section like this: ```yaml spec: chart: - git: git@github.com:weaveworks/flux + git: git@github.com:weaveworks/flux-get-started ref: master - path: charts/flux + path: charts/ghost ``` In this case, the git repo will be cloned, and the chart will be @@ -286,7 +286,7 @@ values: ### Using annotations to control updates to HelmRelease resources -You can use the [same annotations](./using.md#using-annotations) in +You can use the [same annotations](./fluxctl.md#using-annotations) in the `HelmRelease` as you would for a Deployment or other workload, to control updates and automation. For the purpose of specifying filters, the container name is either `chart-image` (if at the top From 0d3ce71d917e4ed5636c311f8f44fbb6c91aa4a9 Mon Sep 17 00:00:00 2001 From: Stefan Prodan Date: Sat, 17 Nov 2018 14:39:25 +0200 Subject: [PATCH 3/9] Update annotations example to match flux-get-started --- site/fluxctl.md | 38 ++++++++++++++++++++------------------ 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/site/fluxctl.md b/site/fluxctl.md index 25cddcfd9..b498398fb 100644 --- a/site/fluxctl.md +++ b/site/fluxctl.md @@ -566,39 +566,41 @@ configured using fluxctl. Here's a simple but complete deployment file with annotations: ``` -apiVersion: extensions/v1beta1 +apiVersion: apps/v1 kind: Deployment metadata: - name: k8s-mon - namespace: admin + name: podinfo + namespace: demo + labels: + app: podinfo annotations: flux.weave.works/automated: "true" - flux.weave.works/tag.k8s-mon: glob:master-* + flux.weave.works/tag.podinfod: semver:~1.3 spec: - replicas: 1 - strategy: - rollingUpdate: - maxUnavailable: 0 - maxSurge: 50% + selector: + matchLabels: + app: podinfo template: metadata: labels: - app: k8s-mon + app: podinfo spec: containers: - - name: k8s-mon - image: index.docker.io/larktech/k8s-mon:master-c00edf01 - - imagePullSecrets: - - name: myregistrykey - + - name: podinfod + image: stefanprodan/podinfo:1.3.2 + ports: + - containerPort: 9898 + name: http + command: + - ./podinfo + - --port=9898 ``` Things to notice: 1. The annotations are made in `metadata.annotations`, not in `spec.template.metadata`. -2. The `flux.weave.works/tag.`... references the container name `k8s-mon`--this will change based on your container name. If you have multiple containers you would have multiple lines like that. -3. The value for the `flux.weave.works/tag.`... annotation should includes the filter pattern type, in this case `glob`. +2. The `flux.weave.works/tag.`... references the container name `podinfod`, this will change based on your container name. If you have multiple containers you would have multiple lines like that. +3. The value for the `flux.weave.works/tag.`... annotation should includes the filter pattern type, in this case `semver`. Annotations can also be used to tell Flux to temporarily ignore certain manifests using `flux.weave.works/ignore: "true"`. Read more about this in the [FAQ](faq.md#can-i-temporarily-make-flux-ignore-a-deployment). From 50785d8e620f2b174f3a50e8cc0d591d3dcd7a17 Mon Sep 17 00:00:00 2001 From: Stefan Prodan Date: Sat, 17 Nov 2018 14:41:58 +0200 Subject: [PATCH 4/9] Update Helm get started docs with flux-get-started repo - remove GKE node constraint since it doesn't apply anymore --- site/helm-get-started.md | 59 +++++++++++++++------------------------- 1 file changed, 22 insertions(+), 37 deletions(-) diff --git a/site/helm-get-started.md b/site/helm-get-started.md index 1de8616d6..8b2016d2a 100644 --- a/site/helm-get-started.md +++ b/site/helm-get-started.md @@ -19,19 +19,6 @@ You will need to have Kubernetes set up. To get up and running fast, you might want to use `minikube` or `kubeadm`. Any other Kubernetes setup will work as well though. -When using a cluster in the cloud (e.g. GKE), use nodes with at least 2 CPU's. -When using nodes with only 1 CPU (like `n1-standard-1`), an upgrade -may be stuck with not enough CPU resources. This issue usually manifests itself -in the form of pods hanging in the PENDING state, which looks something like: - -```sh -$ kubectl describe pod/helloworld-... | tail -3 -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Warning FailedScheduling 3m (x37 over 13m) default-scheduler 0/2 nodes are available: 2 Insufficient cpu. -``` - Download Helm: - On MacOS: @@ -71,7 +58,7 @@ helm repo add weaveworks https://weaveworks.github.io/flux In this next step you install Weave Flux using `helm`. Simply - 1. Fork [flux-helm-test](https://github.com/weaveworks/flux-helm-test) + 1. Fork [flux-get-started](https://github.com/weaveworks/flux-get-started) on Github and 1. Install Weave Flux and its Helm Operator by specifying your fork URL: @@ -82,10 +69,9 @@ In this next step you install Weave Flux using `helm`. Simply - Using a public git server from `bitbucket.com`, `github.com` or `gitlab.com`: ```sh - helm install --name flux \ + helm upgrade -i flux \ --set helmOperator.create=true \ - --set git.url=ssh://git@github.com/YOURUSER/flux-helm-test \ - --set helmOperator.git.chartsPath=charts \ + --set git.url=git@github.com:YOURUSER/flux-get-started \ --namespace flux \ weaveworks/flux ``` @@ -102,7 +88,7 @@ impatient, run the following command and see the pod creation process. ```sh -watch kubectl get pods --all-namespaces +watch kubectl -n flux get pods ``` You will notice that `flux` and `flux-helm-operator` will start @@ -110,7 +96,7 @@ turning up in the `flux` namespace. ## Giving write access -For the real benefits of GitOps, Flux will need acccess to your +For the real benefits of GitOps, Flux will need access to your git repository to update configuration if necessary. To facilitate that you will need to add a deploy key to your fork of the repository. @@ -119,8 +105,7 @@ This is pretty straight-forward as Flux generates a SSH key and logs the public key at startup. Find the SSH public key with: ```sh -FLUX_POD=$(kubectl get pods --namespace flux -l "app=flux,release=flux" -o jsonpath="{.items[0].metadata.name}") -kubectl -n flux logs $FLUX_POD | grep identity.pub | cut -d '"' -f2 +kubectl -n flux logs deployment/flux | grep identity.pub | cut -d '"' -f2 ``` In order to sync your cluster state with git you need to copy the @@ -132,33 +117,36 @@ click on **Add deploy key**, give it a name, check **Allow write access**, paste the Flux public key and click **Add key**. (Or replace `YOURUSER` with your Github ID in this url: -`https://github.com/YOURUSER/flux-helm-test/settings/keys/new` and +`https://github.com/YOURUSER/flux-get-started/settings/keys/new` and paste the key there.) Once Flux has confirmed access to the repository, it will start -deploying the workloads of `flux-helm-test`. After a while you +deploying the workloads of `flux-get-started`. After a while you will be able to see the Helm releases listed like so: ```sh -helm list --namespace test +helm list --namespace demo ``` ## Committing a small change -`flux-helm-test` is a very simple example in which two services -(mongodb and mariadb) are deployed. Here we will simply update the +`flux-get-started` is a simple example in which three services +(mongodb, redis and ghost) are deployed. Here we will simply update the version of mongodb to a newer version to see if Flux will pick this up and update our cluster. -The easiest way is to update your fork of `flux-helm-test` and +The easiest way is to update your fork of `flux-get-started` and change the `image` argument. -Replace `YOURUSER` in `https://github.com/YOURUSER/flux-helm-test/edit/master/releases/mongodb_release.yaml` +Replace `YOURUSER` in `https://github.com/YOURUSER/flux-get-started/edit/master/releases/mongodb.yaml` with your Github ID, open the URL in your browser, edit the file, -change the `image:` line to the following: +change the `tag:` line to the following: ```yaml - image: bitnami/mongodb:3.7.9-r13 + values: + image: + repository: bitnami/mongodb + tag: 4.0.2 ``` Commit the change to your `master` branch. It will now get @@ -171,23 +159,20 @@ kubectl -n flux logs deployment/flux -f ``` The default sync frequency for Flux using the Helm chart is -30 seconds. This can be tweaked easily. By observing the logs +five minutes. This can be tweaked easily. By observing the logs you can see when the change landed in the cluster. -## Confirm the change landed - -To access our webservice and check out its welcome message, simply -run: +Confirm the change landed with: ```sh -kubectl describe -n test deployment.apps/mongodb-database-mongodb | grep Image +kubectl describe -n demo deployment/mongodb | grep Image ``` ## Conclusion As you can see, the actual steps to set up Flux, get our app deployed, give Flux access to it and see modifications land are -very straight-forward and are a quite natural work-flow. +very straight-forward and are a quite natural workflow. # Next From 8c540b42d65f0f5dbdd946294814275247e199de Mon Sep 17 00:00:00 2001 From: Stefan Prodan Date: Sat, 17 Nov 2018 14:49:18 +0200 Subject: [PATCH 5/9] Update Flux get started docs with flux-get-started repo - remove GKE node constraint since it doesn't apply anymore --- site/get-started.md | 28 ++++++++-------------------- 1 file changed, 8 insertions(+), 20 deletions(-) diff --git a/site/get-started.md b/site/get-started.md index 9a29f315d..c99dd6b3a 100644 --- a/site/get-started.md +++ b/site/get-started.md @@ -19,19 +19,6 @@ You will need to have Kubernetes set up. For a quick local test, you can use `minikube` or `kubeadm`. Any other Kubernetes setup will work as well though. -When using a cluster in the cloud (e.g. GKE), use nodes with at least 2 CPU's. -When using nodes with only 1 CPU (like `n1-standard-1`), an upgrade -may be stuck with not enough CPU resources. This issue usually manifests itself -in the form of pods hanging in the PENDING state, which looks something like: - -```sh -$ kubectl describe pod/helloworld-... | tail -3 -Events: - Type Reason Age From Message - ---- ------ ---- ---- ------- - Warning FailedScheduling 3m (x37 over 13m) default-scheduler 0/2 nodes are available: 2 Insufficient cpu. -``` - ### A Note on GKE with RBAC enabled > If working on e.g. GKE with RBAC enabled, you will need to add a clusterrolebinding: @@ -64,7 +51,7 @@ $EDITOR deploy/flux-deployment.yaml ``` In our example we are going to use -[flux-example](https://github.com/weaveworks/flux-example). If you +[flux-get-started](https://github.com/weaveworks/flux-get-started). If you want to use that too, be sure to create a fork of it on Github and add the git URL to the config file above. @@ -105,19 +92,19 @@ click on **Add deploy key**, give it a name, check **Allow write access**, paste the Flux public key and click **Add key**. (Or replace `YOURUSER` with your Github ID in this url: -`https://github.com/YOURUSER/flux-example/settings/keys/new` and +`https://github.com/YOURUSER/flux-get-started/settings/keys/new` and paste the key there.) ## Committing a small change In this example we are using a simple example of a webservice and change its configuration to use a different message. The easiest -way is to edit your fork of `flux-example` and change the `msg` argument. +way is to edit your fork of `flux-get-started` and change the `PODINFO_UI_COLOR` env var to `blue`. Replace `YOURUSER` in -`https://github.com/YOURUSER/flux-example/blob/master/helloworld-deploy.yaml` +`https://github.com/YOURUSER/flux--get-started/blob/master/workloads/podinfo-dep.yaml` with your Github ID), open the URL in your browser, edit the file, -change the argument value and commit the file. +change the env var value and commit the file. You can check out the Flux logs with: @@ -135,10 +122,11 @@ To access our webservice and check out its welcome message, simply run: ```sh -kubectl port-forward deployment/helloworld 8080:80 & -curl localhost:8080 +kubectl -n demo port-forward deployment/podinfo 9898:9898 & ``` +Open your browser and navigate to `http://localhost:9898`. + ## Conclusion As you can see, the actual steps to set up Flux, get our app From a57430b575f11f27b454562cab07994c3c26558b Mon Sep 17 00:00:00 2001 From: Stefan Prodan Date: Sun, 18 Nov 2018 12:08:56 +0200 Subject: [PATCH 6/9] Remove git flags from helm-op docs --- site/helm-operator.md | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/site/helm-operator.md b/site/helm-operator.md index 7f0148fd2..e5c925b3b 100644 --- a/site/helm-operator.md +++ b/site/helm-operator.md @@ -1,13 +1,12 @@ # Flux Helm Operator The Helm operator deals with Helm Chart releases. The operator watches for -changes of Custom Resources of kind FluxHelmRelease. It receives Kubernetes +changes of Custom Resources of kind HelmRelease. It receives Kubernetes Events and acts accordingly, installing, upgrading or deleting a Chart release. ## Setup and configuration helm-operator requires setup and offers customization though a multitude of flags. -(TODO: change the flags to reflect reality) |flag | default | purpose | |------------------------|-------------------------------|---------| @@ -24,15 +23,10 @@ helm-operator requires setup and offers customization though a multitude of flag |--tiller-tls-tls-cert-path |`/etc/fluxd/helm/tls.crt` | Path to certificate file used to communicate with the Tiller server. | |--tiller-tls-tls-ca-cert-path | | Path to CA certificate file used to validate the Tiller server. Required if tiller-tls-verify is enabled. | |--tiller-tls-hostname | | The server name used to verify the hostname on the returned certificates from the Tiller server. | -| | | **Git repo & key etc.**| -|--git-url | | URL of git repo with Helm Charts; e.g., `ssh://git@github.com/weaveworks/flux-example`| -|--git-branch | `master` | Branch of git repo to use for Kubernetes manifests| -|--git-charts-path | `charts` | Path within git repo to locate Kubernetes Charts (relative path)| | | | **repo chart changes** (none of these need overriding, usually) | |--git-timeout | `20 seconds` | duration after which git operations time out | |--git-poll-interval | `5 minutes` | period at which to poll git repo for new commits| |--chartsSyncInterval | 3*time.Minute | Interval at which to check for changed charts.| -|--chartsSyncTimeout | 1*time.Minute | Timeout when checking for changed charts.| | | | **k8s-secret backed ssh keyring configuration**| |--k8s-secret-volume-mount-path | `/etc/fluxd/ssh` | Mount location of the k8s secret storing the private SSH key| |--k8s-secret-data-key | `identity` | Data key holding the private SSH key within the k8s secret| From 60dc37429a5f61762851ad4e286a7a18c6cdd8dc Mon Sep 17 00:00:00 2001 From: Stefan Prodan Date: Sun, 18 Nov 2018 12:24:57 +0200 Subject: [PATCH 7/9] Remove resolved issues from FAQ --- site/faq.md | 30 +++++------------------------- 1 file changed, 5 insertions(+), 25 deletions(-) diff --git a/site/faq.md b/site/faq.md index d7d81809e..b28ea59e4 100644 --- a/site/faq.md +++ b/site/faq.md @@ -213,23 +213,13 @@ happen: - Flux just hasn't fetched the image metadata yet. This may be the case if you've only just started using a particular image in a workload. - Flux can't get suitable credentials for the image repository. At - present, it looks at `imagePullSecret`s attached to workloads (but - not to service accounts; see - [weaveworks/flux#1043](https://github.com/weaveworks/flux/issues/1043)), - and a Docker config file if you mount one into the fluxd container + present, it looks at `imagePullSecret`s attached to workloads, + service accounts and a Docker config file if you mount one into the fluxd container (see the [command-line usage](./daemon.md)). - Flux doesn't know how to obtain registry credentials for ECR. A workaround is described in [weaveworks/flux#539](https://github.com/weaveworks/flux/issues/539#issuecomment-394588423) - - Flux doesn't yet understand what to do with image repositories that - have images for more than one architecture; see - [weaveworks/flux#741](https://github.com/weaveworks/flux/issues/741). At - present there's no workaround for this, if you are not in control - of the image repository in question (or you are, but you need to - have multi-arch manifests). - - Flux doesn't yet examine `initContainer`s when cataloguing the - images used by workloads. See - [weaveworks/flux#702](https://github.com/weaveworks/flux/issues/702) + - Flux excludes images with no suitable manifest (linux amd64) in manifestlist - Flux doesn't yet understand image refs that use digests instead of tags; see [weaveworks/flux#885](https://github.com/weaveworks/flux/issues/885). @@ -416,7 +406,7 @@ Flux doesn't delete resources, there is an [issue](https://github.com/weaveworks In order to delete a Helm release first remove the file from Git and afterwards run: ```yaml -kubectl delete fluxhelmrelease/my-release +kubectl delete helmrelease/my-release ``` The Flux Helm operator will receive the delete event and will purge the Helm release. @@ -428,7 +418,7 @@ You need to use the `helm delete --purge` option only then Flux will be able rei ### I've uninstalled Flux and all my Helm releases are gone. Why is that? -On `FluxHelmRelease` CRD deletion, Kubernetes will remove all `FluxHelmRelease` CRs triggering a Helm purge for each release created by Flux. +On `FluxHelmRelease` CRD deletion, Kubernetes will remove all `HelmRelease` CRs triggering a Helm purge for each release created by Flux. To avoid this you have to manually delete the Flux Helm Operator with `kubectl -n flux delete deployment/flux-helm-operator` before running `helm delete flux`. ### I have a dedicated Kubernetes cluster per environment and I want to use the same Git repo for all. How can I do that? @@ -436,14 +426,4 @@ To avoid this you have to manually delete the Flux Helm Operator with `kubectl - For each cluster create a Git branch in your config repo. When installing Flux set the Git branch using `--set git.branch=cluster-name` and set a unique label for each cluster `--set git.label=cluster-name`. -### I have a dedicated Git repo for my Helm charts. How can I point Flux Helm Operator to it? -When installing Flux with Helm you can override the Operator Git settings using `--set helmOperator.git.url=`. - -If you are using GitHub you need to create a SSH key for Helm Operator: - -* generate a SSH key named identity: `ssh-keygen -q -N "" -f ./identity` -* create a Kubernetes secret: `kubectl -n flux create secret generic helm-ssh --from-file=./identity` -* delete the private key: `rm ./identity` -* add `./identity.pub` as a read-only deployment key in your GitHub repo where the charts are -* set the secret name with `--set helmOperator.git.secretName=helm-ssh` From 82569d862232269d91e5d1c7e30b8ff2f589a9f6 Mon Sep 17 00:00:00 2001 From: Stefan Prodan Date: Mon, 19 Nov 2018 17:14:21 +0000 Subject: [PATCH 8/9] Add the GitHub username replacement after forking - fix typos - add back the git timeout and poll interval --- chart/flux/README.md | 18 +++++++++++------- site/get-started.md | 2 +- site/helm-get-started.md | 9 ++++----- 3 files changed, 16 insertions(+), 13 deletions(-) diff --git a/chart/flux/README.md b/chart/flux/README.md index 5edf00a26..a0af473ba 100755 --- a/chart/flux/README.md +++ b/chart/flux/README.md @@ -27,10 +27,8 @@ until it can find one. # Git repo - - One repo containing desired release state information and Charts - themselves. - - Charts are collocated under another path ("charts" by default; can be - overridden). Charts are subdirectories under the charts path. + - One repo containing desired release state information and Charts themselves. + - Charts are co-located under another path or can be referenced from Helm repositories. - Custom Resource namespace reflects where the release should be done. Both the Helm release and its corresponding Custom Resource will live in this namespace. @@ -52,7 +50,9 @@ Add the weaveworks repo: helm repo add weaveworks https://weaveworks.github.io/flux ``` -#### To install the chart with the release name `flux`: +#### To install the chart with the release name `flux` + +Replace `weaveworks/flux-get-started` with your own git repository and run helm install: ```sh $ helm install --name flux \ @@ -107,6 +107,7 @@ using an alternate mechanism. ```sh YOUR_GIT_HOST=your_git_host.example.com + YOUR_GIT_USER=your_git_user KNOWN_HOSTS='domain ssh-rsa line1 domain ecdsa-sha2-line2 domain ssh-ed25519 line3' @@ -114,7 +115,7 @@ using an alternate mechanism. helm install \ --name flux \ --set helmOperator.create=true \ - --set git.url="git@${YOUR_GIT_HOST}:weaveworks/flux-get-started" \ + --set git.url="git@${YOUR_GIT_HOST}:${YOUR_GIT_USER}/flux-get-started" \ --set-string ssh.known_hosts="${KNOWN_HOSTS}" \ --namespace flux \ chart/flux @@ -126,11 +127,12 @@ using an alternate mechanism. ```sh YOUR_GIT_HOST=your_git_host.example.com + YOUR_GIT_USER=your_git_user helm install \ --name flux \ --set helmOperator.create=true \ - --set git.url="git@${YOUR_GIT_HOST}:weaveworks/flux-get-started" \ + --set git.url="git@${YOUR_GIT_HOST}:${YOUR_GIT_USER}/flux-get-started" \ --set-file ssh.known_hosts=/tmp/flux_known_hosts \ --namespace flux \ chart/flux @@ -206,6 +208,8 @@ The following tables lists the configurable parameters of the Weave Flux chart a | `helmOperator.tag` | Helm operator image tag | `` | `helmOperator.pullPolicy` | Helm operator image pull policy | `IfNotPresent` | `helmOperator.updateChartDeps` | Update dependencies for charts | `true` +| `helmOperator.git.pollInterval` | Period at which to poll git repo for new commits | `git.pollInterval` +| `helmOperator.git.timeout` | Duration after which git operations time out | `git.timeout` | `helmOperator.chartsSyncInterval` | Interval at which to check for changed charts | `3m` | `helmOperator.chartsSyncTimeout` | Timeout when checking for changed charts | `1m` | `helmOperator.extraEnvs` | Extra environment variables for the Helm operator pod | `[]` diff --git a/site/get-started.md b/site/get-started.md index c99dd6b3a..5753cd154 100644 --- a/site/get-started.md +++ b/site/get-started.md @@ -102,7 +102,7 @@ change its configuration to use a different message. The easiest way is to edit your fork of `flux-get-started` and change the `PODINFO_UI_COLOR` env var to `blue`. Replace `YOURUSER` in -`https://github.com/YOURUSER/flux--get-started/blob/master/workloads/podinfo-dep.yaml` +`https://github.com/YOURUSER/flux-get-started/blob/master/workloads/podinfo-dep.yaml` with your Github ID), open the URL in your browser, edit the file, change the env var value and commit the file. diff --git a/site/helm-get-started.md b/site/helm-get-started.md index 8b2016d2a..9db2d62f6 100644 --- a/site/helm-get-started.md +++ b/site/helm-get-started.md @@ -28,8 +28,7 @@ Download Helm: ``` - On Linux: - - Download the [latest - release](https://github.com/kubernetes/helm/releases/latest), + - Download the [latest release](https://github.com/kubernetes/helm/releases/latest), unpack the tarball and put the binary in your `$PATH`. Now create a service account and a cluster role binding for Tiller: @@ -59,9 +58,9 @@ helm repo add weaveworks https://weaveworks.github.io/flux In this next step you install Weave Flux using `helm`. Simply 1. Fork [flux-get-started](https://github.com/weaveworks/flux-get-started) - on Github and - 1. Install Weave Flux and its Helm Operator by specifying your fork - URL: + on Github and replace the `weaveworks` with your GitHub username in + [here](https://github.com/weaveworks/flux-get-started/blob/master/releases/ghost.yaml#L13) + 1. Install Weave Flux and its Helm Operator by specifying your fork URL: *Just make sure you replace `YOURUSER` with your GitHub username in the command below:* From e25f0144985ca108a66bdb77ceafe51d20c88659 Mon Sep 17 00:00:00 2001 From: Michael Bridgen Date: Mon, 19 Nov 2018 18:02:37 +0000 Subject: [PATCH 9/9] Apply suggestions from code review Co-Authored-By: stefanprodan --- chart/flux/README.md | 4 ++-- site/faq.md | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/chart/flux/README.md b/chart/flux/README.md index a0af473ba..1096861ce 100755 --- a/chart/flux/README.md +++ b/chart/flux/README.md @@ -27,8 +27,8 @@ until it can find one. # Git repo - - One repo containing desired release state information and Charts themselves. - - Charts are co-located under another path or can be referenced from Helm repositories. + - One repo containing cluster config (i.e., Kubernetes YAMLs) and zero or more git repos containing Charts themselves. + - Charts can be co-located with config in the git repo, or be from Helm repositories. - Custom Resource namespace reflects where the release should be done. Both the Helm release and its corresponding Custom Resource will live in this namespace. diff --git a/site/faq.md b/site/faq.md index b28ea59e4..cacdd00f3 100644 --- a/site/faq.md +++ b/site/faq.md @@ -418,7 +418,7 @@ You need to use the `helm delete --purge` option only then Flux will be able rei ### I've uninstalled Flux and all my Helm releases are gone. Why is that? -On `FluxHelmRelease` CRD deletion, Kubernetes will remove all `HelmRelease` CRs triggering a Helm purge for each release created by Flux. +On `HelmRelease` CRD deletion, Kubernetes will remove all `HelmRelease` resources triggering a Helm purge for each release created by Flux. To avoid this you have to manually delete the Flux Helm Operator with `kubectl -n flux delete deployment/flux-helm-operator` before running `helm delete flux`. ### I have a dedicated Kubernetes cluster per environment and I want to use the same Git repo for all. How can I do that?