diff --git a/docs/gitbook/tutorials/canary-helm-gitops.md b/docs/gitbook/tutorials/canary-helm-gitops.md index 9633c8bf..8e553d76 100644 --- a/docs/gitbook/tutorials/canary-helm-gitops.md +++ b/docs/gitbook/tutorials/canary-helm-gitops.md @@ -138,7 +138,7 @@ helm upgrade -i frontend flagger/podinfo/ \ --reuse-values \ --set canary.loadtest.enabled=true \ --set canary.helmtest.enabled=true \ ---set image.tag=1.4.1 +--set image.tag=1.7.1 ``` Flagger detects that the deployment revision changed and starts the canary analysis: @@ -283,17 +283,17 @@ metadata: namespace: test annotations: flux.weave.works/automated: "true" - flux.weave.works/tag.chart-image: semver:~1.4 + flux.weave.works/tag.chart-image: semver:~1.7 spec: releaseName: frontend chart: repository: https://stefanprodan.github.io/flagger/ name: podinfo - version: 2.0.0 + version: 2.3.0 values: image: repository: quay.io/stefanprodan/podinfo - tag: 1.4.0 + tag: 1.7.0 backend: http://backend-podinfo:9898/echo canary: enabled: true @@ -311,7 +311,7 @@ In the `chart` section I've defined the release source by specifying the Helm re In the `values` section I've overwritten the defaults set in values.yaml. With the `flux.weave.works` annotations I instruct Flux to automate this release. -When an image tag in the sem ver range of `1.4.0 - 1.4.99` is pushed to Quay, +When an image tag in the sem ver range of `1.7.0 - 1.7.99` is pushed to Quay, Flux will upgrade the Helm release and from there Flagger will pick up the change and start a canary deployment. Install [Weave Flux](https://github.com/weaveworks/flux) and its Helm Operator by specifying your Git repo URL: @@ -321,6 +321,7 @@ helm repo add weaveworks https://weaveworks.github.io/flux helm install --name flux \ --set helmOperator.create=true \ +--set helmOperator.createCRD=true \ --set git.url=git@github.com:/ \ --namespace flux \ weaveworks/flux @@ -343,9 +344,9 @@ launch the `frontend` and `backend` apps. A CI/CD pipeline for the `frontend` release could look like this: -* cut a release from the master branch of the podinfo code repo with the git tag `1.4.1` +* cut a release from the master branch of the podinfo code repo with the git tag `1.7.1` * CI builds the image and pushes the `podinfo:1.7.1` image to the container registry -* Flux scans the registry and updates the Helm release `image.tag` to `1.4.1` +* Flux scans the registry and updates the Helm release `image.tag` to `1.7.1` * Flux commits and push the change to the cluster repo * Flux applies the updated Helm release on the cluster * Flux Helm Operator picks up the change and calls Tiller to upgrade the release @@ -355,7 +356,7 @@ A CI/CD pipeline for the `frontend` release could look like this: * Based on the analysis result the canary deployment is promoted to production or rolled back * Flagger sends a Slack notification with the canary result -If the canary fails, fix the bug, do another patch release eg `1.4.2` and the whole process will run again. +If the canary fails, fix the bug, do another patch release eg `1.7.2` and the whole process will run again. A canary deployment can fail due to any of the following reasons: diff --git a/docs/gitbook/usage/linkerd-progressive-delivery.md b/docs/gitbook/usage/linkerd-progressive-delivery.md index 7d287311..fd0ba624 100644 --- a/docs/gitbook/usage/linkerd-progressive-delivery.md +++ b/docs/gitbook/usage/linkerd-progressive-delivery.md @@ -11,24 +11,13 @@ Flagger requires a Kubernetes cluster **v1.11** or newer and Linkerd **2.4** or Install Flagger in the linkerd namespace: ```bash -helm repo add flagger https://flagger.app - -helm upgrade -i flagger flagger/flagger \ ---namespace linkerd \ ---set metricsServer=http://linkerd-prometheus:9090 \ ---set meshProvider=linkerd +kubectl apply -k github.com/weaveworks/flagger//kustomize/linkerd ``` -Optionally you can enable Slack notifications: +Note that you'll need kubectl 1.14 or newer to run the above command. -```bash -helm upgrade -i flagger flagger/flagger \ ---reuse-values \ ---namespace linkerd \ ---set slack.url=https://hooks.slack.com/services/YOUR/SLACK/WEBHOOK \ ---set slack.channel=general \ ---set slack.user=flagger -``` +To enable Slack or MS Teams notifications, +see Flagger's [install docs](https://docs.flagger.app/install/flagger-install-on-kubernetes) for Kustomize or Helm options. ### Bootstrap @@ -46,17 +35,13 @@ kubectl annotate namespace test linkerd.io/inject=enabled Install the load testing service to generate traffic during the canary analysis: ```bash -helm upgrade -i flagger-loadtester flagger/loadtester \ ---namespace=test +kubectl apply -k github.com/weaveworks/flagger//kustomize/tester ``` Create a deployment and a horizontal pod autoscaler: ```bash -export REPO=https://raw.githubusercontent.com/weaveworks/flagger/master - -kubectl apply -f ${REPO}/artifacts/canaries/deployment.yaml -kubectl apply -f ${REPO}/artifacts/canaries/hpa.yaml +kubectl apply -k github.com/weaveworks/flagger//kustomize/podinfo ``` Create a canary custom resource for the podinfo deployment: @@ -223,7 +208,7 @@ Trigger another canary deployment: ```bash kubectl -n test set image deployment/podinfo \ -podinfod=quay.io/stefanprodan/podinfo:1.4.2 +podinfod=quay.io/stefanprodan/podinfo:1.7.2 ``` Exec into the load tester pod with: @@ -312,7 +297,7 @@ Trigger a canary deployment by updating the container image: ```bash kubectl -n test set image deployment/podinfo \ -podinfod=quay.io/stefanprodan/podinfo:1.4.3 +podinfod=quay.io/stefanprodan/podinfo:1.7.3 ``` Generate 404s: @@ -459,7 +444,7 @@ Trigger a canary deployment by updating the container image: ```bash kubectl -n test set image deployment/podinfo \ -podinfod=quay.io/stefanprodan/podinfo:1.5.0 +podinfod=quay.io/stefanprodan/podinfo:1.7.4 ``` Flagger detects that the deployment revision changed and starts the A/B testing: diff --git a/kustomize/podinfo/deployment.yaml b/kustomize/podinfo/deployment.yaml new file mode 100644 index 00000000..31670880 --- /dev/null +++ b/kustomize/podinfo/deployment.yaml @@ -0,0 +1,66 @@ +apiVersion: apps/v1 +kind: Deployment +metadata: + name: podinfo + labels: + app: podinfo +spec: + minReadySeconds: 5 + revisionHistoryLimit: 5 + progressDeadlineSeconds: 60 + strategy: + rollingUpdate: + maxUnavailable: 0 + type: RollingUpdate + selector: + matchLabels: + app: podinfo + template: + metadata: + annotations: + prometheus.io/scrape: "true" + labels: + app: podinfo + spec: + containers: + - name: podinfod + image: quay.io/stefanprodan/podinfo:1.7.0 + imagePullPolicy: IfNotPresent + ports: + - containerPort: 9898 + name: http + protocol: TCP + command: + - ./podinfo + - --port=9898 + - --level=info + - --random-delay=false + - --random-error=false + env: + - name: PODINFO_UI_COLOR + value: blue + livenessProbe: + exec: + command: + - podcli + - check + - http + - localhost:9898/healthz + initialDelaySeconds: 5 + timeoutSeconds: 5 + readinessProbe: + exec: + command: + - podcli + - check + - http + - localhost:9898/readyz + initialDelaySeconds: 5 + timeoutSeconds: 5 + resources: + limits: + cpu: 2000m + memory: 512Mi + requests: + cpu: 100m + memory: 64Mi diff --git a/kustomize/podinfo/hpa.yaml b/kustomize/podinfo/hpa.yaml new file mode 100644 index 00000000..9824ef1d --- /dev/null +++ b/kustomize/podinfo/hpa.yaml @@ -0,0 +1,18 @@ +apiVersion: autoscaling/v2beta1 +kind: HorizontalPodAutoscaler +metadata: + name: podinfo +spec: + scaleTargetRef: + apiVersion: apps/v1 + kind: Deployment + name: podinfo + minReplicas: 2 + maxReplicas: 4 + metrics: + - type: Resource + resource: + name: cpu + # scale up if usage is above + # 99% of the requested CPU (100m) + targetAverageUtilization: 99 diff --git a/kustomize/podinfo/kustomization.yaml b/kustomize/podinfo/kustomization.yaml new file mode 100644 index 00000000..9ef19b0f --- /dev/null +++ b/kustomize/podinfo/kustomization.yaml @@ -0,0 +1,5 @@ +namespace: test +resources: + - hpa.yaml + - deployment.yaml +