diff --git a/docs/gitbook/README.md b/docs/gitbook/README.md index 2d1b58ce..9e1d8e51 100644 --- a/docs/gitbook/README.md +++ b/docs/gitbook/README.md @@ -8,7 +8,7 @@ description: Flagger is a progressive delivery Kubernetes operator Flagger implements a control loop that gradually shifts traffic to the canary while measuring key performance indicators like HTTP requests success rate, requests average duration and pods health. Based on analysis of the **KPIs** a canary is promoted or aborted, and the analysis result is published to **Slack** or **MS Teams**. -![Flagger overview diagram](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-overview.png) +![Flagger overview diagram](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-canary-overview.png) Flagger can be configured with Kubernetes custom resources and is compatible with any CI/CD solutions made for Kubernetes. Since Flagger is declarative and reacts to Kubernetes events, it can be used in **GitOps** pipelines together with Flux CD or JenkinsX. diff --git a/docs/gitbook/install/flagger-install-on-eks-appmesh.md b/docs/gitbook/install/flagger-install-on-eks-appmesh.md index 685bec7f..fa4b8575 100644 --- a/docs/gitbook/install/flagger-install-on-eks-appmesh.md +++ b/docs/gitbook/install/flagger-install-on-eks-appmesh.md @@ -114,7 +114,7 @@ helm repo add flagger https://flagger.app Install Flagger's Canary CRD: ```yaml -kubectl apply -f https://raw.githubusercontent.com/weaveworks/flagger/master/artifacts/flagger/crd.yaml +kubectl apply -f https://raw.githubusercontent.com/fluxcd/flagger/main/artifacts/flagger/crd.yaml ``` Deploy Flagger in the _**appmesh-system**_ namespace: diff --git a/docs/gitbook/install/flagger-install-on-google-cloud.md b/docs/gitbook/install/flagger-install-on-google-cloud.md index a3fab0ef..a1dc342e 100644 --- a/docs/gitbook/install/flagger-install-on-google-cloud.md +++ b/docs/gitbook/install/flagger-install-on-google-cloud.md @@ -2,7 +2,7 @@ This guide walks you through setting up Flagger and Istio on Google Kubernetes Engine. -![GKE Cluster Overview](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-gke-istio.png) +![GKE Cluster Overview](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-gke-istio.png) ## Prerequisites @@ -205,12 +205,12 @@ jetstack/cert-manager ## Istio Gateway TLS setup -![Istio Let's Encrypt](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/istio-cert-manager-gke.png) +![Istio Let's Encrypt](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/istio-cert-manager-gke.png) Create a generic Istio Gateway to expose services outside the mesh on HTTPS: ```bash -REPO=https://raw.githubusercontent.com/weaveworks/flagger/master +REPO=https://raw.githubusercontent.com/fluxcd/flagger/main kubectl apply -f ${REPO}/artifacts/gke/istio-gateway.yaml ``` @@ -346,7 +346,7 @@ helm repo add flagger https://flagger.app Install Flagger's Canary CRD: ```yaml -kubectl apply -f https://raw.githubusercontent.com/weaveworks/flagger/master/artifacts/flagger/crd.yaml +kubectl apply -f https://raw.githubusercontent.com/fluxcd/flagger/main/artifacts/flagger/crd.yaml ``` Deploy Flagger in the `istio-system` namespace with Slack notifications enabled: diff --git a/docs/gitbook/install/flagger-install-on-kubernetes.md b/docs/gitbook/install/flagger-install-on-kubernetes.md index 61437716..d66e8cd3 100644 --- a/docs/gitbook/install/flagger-install-on-kubernetes.md +++ b/docs/gitbook/install/flagger-install-on-kubernetes.md @@ -17,7 +17,7 @@ helm repo add flagger https://flagger.app Install Flagger's Canary CRD: ```yaml -kubectl apply -f https://raw.githubusercontent.com/weaveworks/flagger/master/artifacts/flagger/crd.yaml +kubectl apply -f https://raw.githubusercontent.com/fluxcd/flagger/main/artifacts/flagger/crd.yaml ``` Deploy Flagger for Istio: diff --git a/docs/gitbook/tutorials/appmesh-progressive-delivery.md b/docs/gitbook/tutorials/appmesh-progressive-delivery.md index 7310d6b4..2bc5a5ff 100644 --- a/docs/gitbook/tutorials/appmesh-progressive-delivery.md +++ b/docs/gitbook/tutorials/appmesh-progressive-delivery.md @@ -270,7 +270,7 @@ When the canary analysis starts, Flagger will call the pre-rollout webhooks befo During the analysis the canary’s progress can be monitored with Grafana. The App Mesh dashboard URL is [http://localhost:3000/d/flagger-appmesh/appmesh-canary?refresh=10s&orgId=1&var-namespace=test&var-primary=podinfo-primary&var-canary=podinfo](http://localhost:3000/d/flagger-appmesh/appmesh-canary?refresh=10s&orgId=1&var-namespace=test&var-primary=podinfo-primary&var-canary=podinfo). -![App Mesh Canary Dashboard](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/flagger-grafana-appmesh.png) +![App Mesh Canary Dashboard](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/flagger-grafana-appmesh.png) You can monitor all canaries with: @@ -285,7 +285,7 @@ prod backend Failed 0 If you’ve enabled the Slack notifications, you should receive the following messages: -![Flagger Slack Notifications](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/slack-canary-notifications.png) +![Flagger Slack Notifications](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/slack-canary-notifications.png) ## Automated rollback @@ -337,13 +337,13 @@ Canary failed! Scaling down podinfo.test If you’ve enabled the Slack notifications, you’ll receive a message if the progress deadline is exceeded, or if the analysis reached the maximum number of failed checks: -![Flagger Slack Notifications](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/slack-canary-failed.png) +![Flagger Slack Notifications](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/slack-canary-failed.png) ## A/B Testing Besides weighted routing, Flagger can be configured to route traffic to the canary based on HTTP match conditions. In an A/B testing scenario, you'll be using HTTP headers or cookies to target a certain segment of your users. This is particularly useful for frontend applications that require session affinity. -![Flagger A/B Testing Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-abtest-steps.png) +![Flagger A/B Testing Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-abtest-steps.png) Edit the canary analysis, remove the max/step weight and add the match conditions and iterations: diff --git a/docs/gitbook/tutorials/canary-helm-gitops.md b/docs/gitbook/tutorials/canary-helm-gitops.md index 9e901a5a..f27355c2 100644 --- a/docs/gitbook/tutorials/canary-helm-gitops.md +++ b/docs/gitbook/tutorials/canary-helm-gitops.md @@ -30,7 +30,7 @@ You can find the chart source [here](https://github.com/stefanprodan/flagger/tre Create a test namespace with Istio sidecar injection enabled: ```bash -export REPO=https://raw.githubusercontent.com/weaveworks/flagger/master +export REPO=https://raw.githubusercontent.com/fluxcd/flagger/main kubectl apply -f ${REPO}/artifacts/namespaces/test.yaml ``` @@ -77,7 +77,7 @@ When the `frontend-primary` deployment comes online, Flagger will route all traf Open your browser and navigate to the frontend URL: -![Podinfo Frontend](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/demo-frontend.png) +![Podinfo Frontend](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/demo-frontend.png) Now let's install the `backend` release without exposing it outside the mesh: @@ -101,7 +101,7 @@ frontend Initialized 0 2019-02-12T17:50:50Z Click on the ping button in the `frontend` UI to trigger a HTTP POST request that will reach the `backend` app: -![Jaeger Tracing](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/demo-frontend-jaeger.png) +![Jaeger Tracing](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/demo-frontend-jaeger.png) We'll use the `/echo` endpoint \(same as the one the ping button calls\) to generate load on both apps during a canary deployment. @@ -159,7 +159,7 @@ Promotion completed! Scaling down frontend.test You can monitor the canary deployment with Grafana. Open the Flagger dashboard, select `test` from the namespace dropdown, `frontend-primary` from the primary dropdown and `frontend` from the canary dropdown. -![Flagger Grafana Dashboard](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/demo-frontend-dashboard.png) +![Flagger Grafana Dashboard](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/demo-frontend-dashboard.png) Now trigger a canary deployment for the `backend` app, but this time you'll change a value in the configmap: @@ -217,7 +217,7 @@ Copying backend.test template spec to backend-primary.test Promotion completed! Scaling down backend.test ``` -![Flagger Grafana Dashboard](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/demo-backend-dashboard.png) +![Flagger Grafana Dashboard](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/demo-backend-dashboard.png) If the number of failed checks reaches the canary analysis threshold, the traffic is routed back to the primary, the canary is scaled to zero and the rollout is marked as failed. @@ -235,7 +235,7 @@ If you've enabled the Slack notifications, you'll receive an alert with the reas Instead of using Helm CLI from a CI tool to perform the install and upgrade, you could use a Git based approach. GitOps is a way to do Continuous Delivery, it works by using Git as a source of truth for declarative infrastructure and workloads. In the [GitOps model](https://www.weave.works/technologies/gitops/), any change to production must be committed in source control prior to being applied on the cluster. This way rollback and audit logs are provided by Git. -![Helm GitOps Canary Deployment](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-flux-gitops.png) +![Helm GitOps Canary Deployment](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-flux-gitops.png) In order to apply the GitOps pipeline model to Flagger canary deployments you'll need a Git repository with your workloads definitions in YAML format, a container registry where your CI system pushes immutable images and an operator that synchronizes the Git repo with the cluster state. diff --git a/docs/gitbook/tutorials/contour-progressive-delivery.md b/docs/gitbook/tutorials/contour-progressive-delivery.md index 5cd7a6f1..bc6a250d 100644 --- a/docs/gitbook/tutorials/contour-progressive-delivery.md +++ b/docs/gitbook/tutorials/contour-progressive-delivery.md @@ -2,7 +2,7 @@ This guide shows you how to use [Contour](https://projectcontour.io/) ingress controller and Flagger to automate canary releases and A/B testing. -![Flagger Contour Overview](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-contour-overview.png) +![Flagger Contour Overview](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-contour-overview.png) ## Prerequisites @@ -213,7 +213,7 @@ Note that you should be using HTTPS when exposing production workloads on intern Flagger implements a control loop that gradually shifts traffic to the canary while measuring key performance indicators like HTTP requests success rate, requests average duration and pod health. Based on analysis of the KPIs a canary is promoted or aborted. -![Flagger Canary Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-steps.png) +![Flagger Canary Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-canary-steps.png) A canary deployment is triggered by changes in any of the following objects: @@ -271,7 +271,7 @@ test podinfo Progressing 15 2019-12-20T14:05:07Z If you’ve enabled the Slack notifications, you should receive the following messages: -![Flagger Slack Notifications](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/slack-canary-notifications.png) +![Flagger Slack Notifications](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/slack-canary-notifications.png) ## Automated rollback @@ -323,13 +323,13 @@ Canary failed! Scaling down podinfo.test If you’ve enabled the Slack notifications, you’ll receive a message if the progress deadline is exceeded, or if the analysis reached the maximum number of failed checks: -![Flagger Slack Notifications](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/slack-canary-failed.png) +![Flagger Slack Notifications](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/slack-canary-failed.png) ## A/B Testing Besides weighted routing, Flagger can be configured to route traffic to the canary based on HTTP match conditions. In an A/B testing scenario, you'll be using HTTP headers or cookies to target a certain segment of your users. This is particularly useful for frontend applications that require session affinity. -![Flagger A/B Testing Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-abtest-steps.png) +![Flagger A/B Testing Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-abtest-steps.png) Edit the canary analysis, remove the max/step weight and add the match conditions and iterations: diff --git a/docs/gitbook/tutorials/crossover-progressive-delivery.md b/docs/gitbook/tutorials/crossover-progressive-delivery.md index 566c8639..4f0b21d3 100644 --- a/docs/gitbook/tutorials/crossover-progressive-delivery.md +++ b/docs/gitbook/tutorials/crossover-progressive-delivery.md @@ -213,7 +213,7 @@ After the boostrap, the podinfo deployment will be scaled to zero and the traffi Flagger implements a control loop that gradually shifts traffic to the canary while measuring key performance indicators like HTTP requests success rate, requests average duration and pod health. Based on analysis of the KPIs a canary is promoted or aborted, and the analysis result is published to Slack. -![Flagger Canary Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-steps.png) +![Flagger Canary Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-canary-steps.png) A canary deployment is triggered by changes in any of the following objects: @@ -278,7 +278,7 @@ kubectl port-forward --namespace test svc/flagger-grafana 3000:80 The Envoy dashboard URL is [http://localhost:3000/d/flagger-envoy/envoy-canary?refresh=10s&orgId=1&var-namespace=test&var-target=podinfo](http://localhost:3000/d/flagger-envoy/envoy-canary?refresh=10s&orgId=1&var-namespace=test&var-target=podinfo) -![Envoy Canary Dashboard](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/flagger-grafana-appmesh.png) +![Envoy Canary Dashboard](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/flagger-grafana-appmesh.png) You can monitor all canaries with: @@ -293,7 +293,7 @@ prod backend Failed 0 2019-10-02T17:05:07Z If you’ve enabled the Slack notifications, you should receive the following messages: -![Flagger Slack Notifications](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/slack-canary-notifications.png) +![Flagger Slack Notifications](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/slack-canary-notifications.png) ## Automated rollback @@ -345,5 +345,5 @@ Canary failed! Scaling down podinfo.test If you’ve enabled the Slack notifications, you’ll receive a message if the progress deadline is exceeded, or if the analysis reached the maximum number of failed checks: -![Flagger Slack Notifications](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/slack-canary-failed.png) +![Flagger Slack Notifications](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/slack-canary-failed.png) diff --git a/docs/gitbook/tutorials/gloo-progressive-delivery.md b/docs/gitbook/tutorials/gloo-progressive-delivery.md index d5a32300..797594dc 100644 --- a/docs/gitbook/tutorials/gloo-progressive-delivery.md +++ b/docs/gitbook/tutorials/gloo-progressive-delivery.md @@ -2,7 +2,7 @@ This guide shows you how to use the [Gloo Edge](https://gloo.solo.io/) ingress controller and Flagger to automate canary deployments. -![Flagger Gloo Ingress Controller](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-gloo-overview.png) +![Flagger Gloo Ingress Controller](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-gloo-overview.png) ## Prerequisites @@ -184,7 +184,7 @@ podinfo Initialized 0 2019-05-17T08:09:51Z Flagger implements a control loop that gradually shifts traffic to the canary while measuring key performance indicators like HTTP requests success rate, requests average duration and pod health. Based on analysis of the KPIs a canary is promoted or aborted, and the analysis result is published to Slack. -![Flagger Canary Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-steps.png) +![Flagger Canary Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-canary-steps.png) Trigger a canary deployment by updating the container image: diff --git a/docs/gitbook/tutorials/istio-ab-testing.md b/docs/gitbook/tutorials/istio-ab-testing.md index d3ae98d7..23990066 100644 --- a/docs/gitbook/tutorials/istio-ab-testing.md +++ b/docs/gitbook/tutorials/istio-ab-testing.md @@ -4,7 +4,7 @@ This guide shows you how to automate A/B testing with Istio and Flagger. Besides weighted routing, Flagger can be configured to route traffic to the canary based on HTTP match conditions. In an A/B testing scenario, you'll be using HTTP headers or cookies to target a certain segment of your users. This is particularly useful for frontend applications that require session affinity. -![Flagger A/B Testing Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-abtest-steps.png) +![Flagger A/B Testing Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-abtest-steps.png) ## Prerequisites diff --git a/docs/gitbook/tutorials/istio-progressive-delivery.md b/docs/gitbook/tutorials/istio-progressive-delivery.md index d5c8239f..99d1af63 100644 --- a/docs/gitbook/tutorials/istio-progressive-delivery.md +++ b/docs/gitbook/tutorials/istio-progressive-delivery.md @@ -2,7 +2,7 @@ This guide shows you how to use Istio and Flagger to automate canary deployments. -![Flagger Canary Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-steps.png) +![Flagger Canary Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-canary-steps.png) ## Prerequisites @@ -158,7 +158,7 @@ kubectl apply -f ./podinfo-canary.yaml When the canary analysis starts, Flagger will call the pre-rollout webhooks before routing traffic to the canary. The canary analysis will run for five minutes while validating the HTTP metrics and rollout hooks every minute. -![Flagger Canary Process](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-hpa.png) +![Flagger Canary Process](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-canary-hpa.png) After a couple of seconds Flagger will create the canary objects: @@ -293,7 +293,7 @@ Events: ## Traffic mirroring -![Flagger Canary Traffic Shadowing](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-traffic-mirroring.png) +![Flagger Canary Traffic Shadowing](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-canary-traffic-mirroring.png) For applications that perform read operations, Flagger can be configured to drive canary releases with traffic mirroring. Istio traffic mirroring will copy each incoming request, sending one request to the primary and one to the canary service. The response from the primary is sent back to the user and the response from the canary is discarded. Metrics are collected on both requests so that the deployment will only proceed if the canary metrics are within the threshold values. diff --git a/docs/gitbook/tutorials/kubernetes-blue-green.md b/docs/gitbook/tutorials/kubernetes-blue-green.md index 8cff2a4b..be1dff78 100644 --- a/docs/gitbook/tutorials/kubernetes-blue-green.md +++ b/docs/gitbook/tutorials/kubernetes-blue-green.md @@ -4,7 +4,7 @@ This guide shows you how to automate Blue/Green deployments with Flagger and Kub For applications that are not deployed on a service mesh, Flagger can orchestrate Blue/Green style deployments with Kubernetes L4 networking. When using a service mesh blue/green can be used as specified [here](../usage/deployment-strategies.md). -![Flagger Blue/Green Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-bluegreen-steps.png) +![Flagger Blue/Green Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-bluegreen-steps.png) ## Prerequisites diff --git a/docs/gitbook/tutorials/linkerd-progressive-delivery.md b/docs/gitbook/tutorials/linkerd-progressive-delivery.md index f85b51b2..6c7fb92c 100644 --- a/docs/gitbook/tutorials/linkerd-progressive-delivery.md +++ b/docs/gitbook/tutorials/linkerd-progressive-delivery.md @@ -2,7 +2,7 @@ This guide shows you how to use Linkerd and Flagger to automate canary deployments. -![Flagger Linkerd Traffic Split](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-linkerd-traffic-split.png) +![Flagger Linkerd Traffic Split](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-linkerd-traffic-split.png) ## Prerequisites @@ -139,7 +139,7 @@ After the boostrap, the podinfo deployment will be scaled to zero and the traffi Flagger implements a control loop that gradually shifts traffic to the canary while measuring key performance indicators like HTTP requests success rate, requests average duration and pod health. Based on analysis of the KPIs a canary is promoted or aborted, and the analysis result is published to Slack. -![Flagger Canary Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-steps.png) +![Flagger Canary Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-canary-steps.png) Trigger a canary deployment by updating the container image: @@ -361,7 +361,7 @@ When using an ingress controller, the Linkerd traffic split does not apply to in Besides weighted routing, Flagger can be configured to route traffic to the canary based on HTTP match conditions. In an A/B testing scenario, you'll be using HTTP headers or cookies to target a certain segment of your users. This is particularly useful for frontend applications that require session affinity. -![Flagger Linkerd Ingress](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-nginx-linkerd.png) +![Flagger Linkerd Ingress](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-nginx-linkerd.png) Edit podinfo canary analysis, set the provider to `nginx`, add the ingress reference, remove the max/step weight and add the match conditions and iterations: diff --git a/docs/gitbook/tutorials/nginx-progressive-delivery.md b/docs/gitbook/tutorials/nginx-progressive-delivery.md index 42b9ac33..6539a97f 100644 --- a/docs/gitbook/tutorials/nginx-progressive-delivery.md +++ b/docs/gitbook/tutorials/nginx-progressive-delivery.md @@ -2,7 +2,7 @@ This guide shows you how to use the NGINX ingress controller and Flagger to automate canary deployments and A/B testing. -![Flagger NGINX Ingress Controller](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-nginx-overview.png) +![Flagger NGINX Ingress Controller](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-nginx-overview.png) ## Prerequisites @@ -182,7 +182,7 @@ Flagger implements a control loop that gradually shifts traffic to the canary wh indicators like HTTP requests success rate, requests average duration and pod health. Based on analysis of the KPIs a canary is promoted or aborted, and the analysis result is published to Slack or MS Teams. -![Flagger Canary Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-steps.png) +![Flagger Canary Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-canary-steps.png) Trigger a canary deployment by updating the container image: @@ -365,7 +365,7 @@ Besides weighted routing, Flagger can be configured to route traffic to the cana In an A/B testing scenario, you'll be using HTTP headers or cookies to target a certain segment of your users. This is particularly useful for frontend applications that require session affinity. -![Flagger A/B Testing Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-abtest-steps.png) +![Flagger A/B Testing Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-abtest-steps.png) Edit the canary analysis, remove the max/step weight and add the match conditions and iterations: diff --git a/docs/gitbook/tutorials/skipper-progressive-delivery.md b/docs/gitbook/tutorials/skipper-progressive-delivery.md index 994f0739..adde932f 100644 --- a/docs/gitbook/tutorials/skipper-progressive-delivery.md +++ b/docs/gitbook/tutorials/skipper-progressive-delivery.md @@ -2,7 +2,7 @@ This guide shows you how to use the [Skipper ingress controller](https://opensource.zalando.com/skipper/kubernetes/ingress-controller/) and Flagger to automate canary deployments. -![Flagger Skipper Ingress Controller](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-skipper-overview.png) +![Flagger Skipper Ingress Controller](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-skipper-overview.png) ## Prerequisites @@ -192,7 +192,7 @@ ingress.networking.k8s.io/podinfo-canary Flagger implements a control loop that gradually shifts traffic to the canary while measuring key performance indicators like HTTP requests success rate, requests average duration and pod health. Based on analysis of the KPIs a canary is promoted or aborted, and the analysis result is published to Slack or MS Teams. -![Flagger Canary Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-steps.png) +![Flagger Canary Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-canary-steps.png) Trigger a canary deployment by updating the container image: diff --git a/docs/gitbook/tutorials/traefik-progressive-delivery.md b/docs/gitbook/tutorials/traefik-progressive-delivery.md index fbf022f5..5722ce87 100644 --- a/docs/gitbook/tutorials/traefik-progressive-delivery.md +++ b/docs/gitbook/tutorials/traefik-progressive-delivery.md @@ -174,7 +174,7 @@ traefikservice.traefik.containo.us/podinfo Flagger implements a control loop that gradually shifts traffic to the canary while measuring key performance indicators like HTTP requests success rate, requests average duration and pod health. Based on analysis of the KPIs a canary is promoted or aborted, and the analysis result is published to Slack or MS Teams. -![Flagger Canary Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-steps.png) +![Flagger Canary Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-canary-steps.png) Trigger a canary deployment by updating the container image: diff --git a/docs/gitbook/usage/alerting.md b/docs/gitbook/usage/alerting.md index ed92af78..646e56d0 100644 --- a/docs/gitbook/usage/alerting.md +++ b/docs/gitbook/usage/alerting.md @@ -15,11 +15,11 @@ helm upgrade -i flagger flagger/flagger \ Once configured with a Slack incoming **webhook**, Flagger will post messages when a canary deployment has been initialised, when a new revision has been detected and if the canary analysis failed or succeeded. -![Slack Notifications](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/slack-canary-notifications.png) +![Slack Notifications](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/slack-canary-notifications.png) A canary deployment will be rolled back if the progress deadline exceeded or if the analysis reached the maximum number of failed checks: -![Slack Notifications](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/slack-canary-failed.png) +![Slack Notifications](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/slack-canary-failed.png) Flagger can be configured to send notifications to Microsoft Teams: @@ -30,9 +30,9 @@ helm upgrade -i flagger flagger/flagger \ Similar to Slack, Flagger alerts on canary analysis events: -![MS Teams Notifications](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/flagger-ms-teams-notifications.png) +![MS Teams Notifications](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/flagger-ms-teams-notifications.png) -![MS Teams Notifications](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/flagger-ms-teams-failed.png) +![MS Teams Notifications](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/flagger-ms-teams-failed.png) ## Canary configuration diff --git a/docs/gitbook/usage/deployment-strategies.md b/docs/gitbook/usage/deployment-strategies.md index 2b42bbbe..7f47f7da 100644 --- a/docs/gitbook/usage/deployment-strategies.md +++ b/docs/gitbook/usage/deployment-strategies.md @@ -23,7 +23,7 @@ A canary analysis is triggered by changes in any of the following objects: Flagger implements a control loop that gradually shifts traffic to the canary while measuring key performance indicators like HTTP requests success rate, requests average duration and pod health. Based on analysis of the KPIs a canary is promoted or aborted. -![Flagger Canary Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-canary-steps.png) +![Flagger Canary Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-canary-steps.png) The canary analysis runs periodically until it reaches the maximum traffic weight or the failed checks threshold. @@ -156,7 +156,7 @@ We would have steps \(canary weight : primary weight\): For frontend applications that require session affinity you should use HTTP headers or cookies match conditions to ensure a set of users will stay on the same version for the whole duration of the canary analysis. -![Flagger A/B Testing Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-abtest-steps.png) +![Flagger A/B Testing Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-abtest-steps.png) You can enable A/B testing by specifying the HTTP match conditions and the number of iterations. If Flagger finds a HTTP match condition, it will ignore the `maxWeight` and `stepWeight` settings. @@ -278,7 +278,7 @@ curl -b 'canary=always' http://app.example.com For applications that are not deployed on a service mesh, Flagger can orchestrate blue/green style deployments with Kubernetes L4 networking. When using Istio you have the option to mirror traffic between blue and green. -![Flagger Blue/Green Stages](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-bluegreen-steps.png) +![Flagger Blue/Green Stages](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-bluegreen-steps.png) You can use the blue/green deployment strategy by replacing `stepWeight/maxWeight` with `iterations` in the `analysis` spec: diff --git a/docs/gitbook/usage/monitoring.md b/docs/gitbook/usage/monitoring.md index 15dc10e7..209003ba 100644 --- a/docs/gitbook/usage/monitoring.md +++ b/docs/gitbook/usage/monitoring.md @@ -12,7 +12,7 @@ helm upgrade -i flagger-grafana flagger/grafana \ The dashboard shows the RED and USE metrics for the primary and canary workloads: -![Canary Dashboard](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/screens/grafana-canary-analysis.png) +![Canary Dashboard](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/screens/grafana-canary-analysis.png) ## Logging diff --git a/docs/gitbook/usage/webhooks.md b/docs/gitbook/usage/webhooks.md index 24c0939e..92aa36fa 100644 --- a/docs/gitbook/usage/webhooks.md +++ b/docs/gitbook/usage/webhooks.md @@ -122,7 +122,7 @@ For workloads that are not receiving constant traffic Flagger can be configured Flagger comes with a load testing service based on [rakyll/hey](https://github.com/rakyll/hey) that generates traffic during analysis when configured as a webhook. -![Flagger Load Testing Webhook](https://raw.githubusercontent.com/weaveworks/flagger/master/docs/diagrams/flagger-load-testing.png) +![Flagger Load Testing Webhook](https://raw.githubusercontent.com/fluxcd/flagger/main/docs/diagrams/flagger-load-testing.png) First you need to deploy the load test runner in a namespace with sidecar injection enabled: