Move stray Progressive Delivery text to related page (#3923)

* Move stray PD text to related page * Update progressive-delivery-flagger-install.mdx Update link * Update website/docs/progressive-delivery/progressive-delivery-flagger-install.mdx Co-authored-by: Yiannis <[email protected]> * Updates Delivery dashboard * Replaces !'s with dashes * Adds necessary yaml for UI login * Adds line in intro page about browser support * Adds line breaks attempt number two * Fixing the line breaks round three * Fixing icons * Update website/docs/progressive-delivery/progressive-delivery-flagger-install.mdx Co-authored-by: Yiannis <[email protected]> --------- Co-authored-by: Yiannis <[email protected]>
weaveworks · Sep 1, 2023 · 17e51da · 17e51da
1 parent 8564a2f
commit 17e51da
Show file tree

Hide file tree

Showing 4 changed files with 169 additions and 4 deletions.
diff --git a/website/docs/intro-weave-gitops.mdx b/website/docs/intro-weave-gitops.mdx
@@ -30,6 +30,8 @@ Want to learn more about how [Weave GitOps Enterprise](./enterprise/getting-star
 Get in touch with [email protected] to discuss your needs.
 :::
 
+Weave GitOps works on any Chromium-based browser (Chrome, Opera, Microsoft Edge), Safari, and Firefox. We only support the latest and prior two versions of these browsers.
+
 To give Weave GitOps a test drive, we recommend checking out the Open Source version and its [UI](./open-source/getting-started/ui-OSS.mdx), then deploying an application. Let's take a closer look at the features it offers you, all for free.
 
 ### Weave GitOps Open Source Features

diff --git a/website/docs/open-source/getting-started/ui-OSS.mdx b/website/docs/open-source/getting-started/ui-OSS.mdx
@@ -42,6 +42,17 @@ Next, [open the dashboard](http://localhost:9001/) and login using either the [e
 
    ![Weave GitOps login screen](/img/dashboard-login.png)
 
+The label of the OIDC button on the login screen is configurable via a feature flag environment variable.
+This can give your users a more familiar experience when logging in.
+
+Adjust the configuration in the Helm `values.yaml` file or the `spec.values` section of the Weave GitOps `HelmRelease` resource:
+
+```yaml
+envVars:
+  - name: WEAVE_GITOPS_FEATURE_OIDC_BUTTON_LABEL
+    value: "Login with ACME"
+```
+
 ## The Applications View
 
 Upon login you're taken to the Applications view, which allows you to quickly understand the state of your deployments and shows summary information from [`Kustomization`](https://fluxcd.io/flux/components/kustomize/kustomization/) and [`HelmRelease`](https://fluxcd.io/flux/components/helm/helmreleases/) objects. You can apply dark mode using the toggle switch in the top right corner.

diff --git a/website/docs/progressive-delivery/progressive-delivery-flagger-install.mdx b/website/docs/progressive-delivery/progressive-delivery-flagger-install.mdx
@@ -13,7 +13,9 @@ Built upon the core tenets of continuous integration and continuous delivery (CI
 
 [Flagger](https://docs.flagger.app/) is a progressive delivery operator for Kubernetes and part of the Flux family of open source projects. It reduces the risk of introducing new software versions and automates production releases to improve your time to delivery. Flagger implements deployment strategies—canary releases, A/B testing, Blue/Green mirroring—using a service mesh (App Mesh, Istio, Linkerd, Kuma, Open Service Mesh) or an ingress controller (Contour, Gloo, NGINX, Skipper, Traefik, APISIX) for traffic routing. For release analysis, Flagger can query Prometheus, InfluxDB, Datadog, New Relic, CloudWatch, Stackdriver, or Graphite. For alerting it uses Slack, MS Teams, Discord, and Rocket. Using Flux allows us to manage our cluster applications in a declarative way through changes in a Git repository.
 
-If you're using Weave GitOps Enterprise, the Applications > Delivery view of the UI provides an "at a glance" view so that you can understand the status of your progressive delivery rollouts across a fleet of connected clusters. This removes the cognitive overhead of having to know which objects to query and where they are located. You can also drill down into each rollout to understand its status and configuration, and view near-to-realtime data on any summary or details page. Lastly, it includes a flagger-nginx [Profile](https://docs.gitops.weave.works/docs/next/cluster-management/profiles/) to help you quickly get started without having to configure a service mesh.
+Weave GitOps Enterprise integrates with Flagger in order to provide a view on progressive delivery deployments. This includes the ability to view all the resources that Flagger manages during its operation. The default ClusterRole `gitops-canaries-reader` includes the minimum permissions necessary for a user to be able to view canary object details, metric template object details and canary related events. 
+
+The WGE UI's Applications > Delivery view provides an "at a glance" view so that you can understand the status of your progressive delivery rollouts across a fleet of connected clusters. This removes the cognitive overhead of having to know which objects to query and where they are located. You can also drill down into each rollout to understand its status and configuration, and view near-to-realtime data on any summary or details page.
 
 ![Applications Delivery view](/img/dashboard-applications-delivery.png)
 
@@ -26,11 +28,15 @@ How to use WGE's progressive delivery offering:
 - view objects from any cluster/namespace that you have the appropriate permissions for, and nothing else
 - if you choose, enable the progressive delivery feature through a feature flag
 
-Supported deployment strategies include: 
-![canary release icon](/img/canary.svg)  **Canary Release**: the user gradually shifts traffic to
-a new version of an application and assesses performance—either promoting the release or abandoning it, based on performance.  
+Supported deployment strategies include:
+
+![canary release icon](/img/canary.svg)  **Canary Release**: the system gradually shifts traffic to
+a new version of an application and assesses performance—either promoting the release or abandoning it, based on performance.
+
 ![a b testing icon](/img/ab.svg)  **A/B Testing**: uses HTTP headers or cookies to ensure users remain on the same version of an application during a canary analysis.
+
 ![blue green testing icon](/img/blue-green.svg)  **Blue/Green**: Traffic is switched from the current application to a new version based on the success of testing.
+
 ![blue green mirroring icon](/img/mirroring.svg)  **Blue/Green with Traffic Mirroring**: sends copies of incoming requests to the new version of an application. The user receives the response from the current application and the other is discarded. The new version is promoted only if metrics are healthy.
 
 This guide uses Flux manifests to install Flagger and [Linkerd](https://github.com/linkerd), a [CNCF](https://www.cncf.io/) project and service mesh for Kubernetes and beyond. We will walk you through a full end-to-end scenario where you will:
@@ -363,6 +369,152 @@ flagger-7d456d4fc7-knf2g      1/1     Running   0          4m
 loadtester-855b4d77f6-scl6r   1/1     Running   0          4m
 ```
 
+## Custom Resources Generated by Flagger
+
+When Flagger is configured to integrate with a service mesh such as Linkerd or Istio for the rollout, this ClusterRole needs to be extended so that it can read the additional service mesh resources that Flagger generates. To display service mesh- or ingress-related resources, we require `spec.provider` to be set in each canary resource. 
+
+The following table provides a list of all the custom resources that Flagger generates grouped by provider:
+
+| Provider          | API Group                 | Resource        |
+| ---               | ---                       | ---             |
+| AppMesh           | appmesh.k8s.aws           | virtualnode     |
+|                   | appmesh.k8s.aws           | virtualrouter   |
+|                   | appmesh.k8s.aws           | virtualservice  |
+| Linkerd           | split.smi-spec.io         | trafficsplit    |
+| Istio             | networking.istio.io       | destinationrule |
+|                   | networking.istio.io       | virtualservice  |
+| Contour           | projectcontour.io         | httpproxy       |
+| Gloo              | gateway.solo.io           | routetable      |
+|                   | gloo.solo.io              | upstream        |
+| Nginx             | networking.k8s.io         | ingress         |
+| Skipper           | networking.k8s.io         | ingress         |
+| Traefik           | traefik.containo.us       | traefikservice  |
+| Open Service Mesh | split.smi-spec.io         | trafficsplit    |
+| Kuma              | kuma.io                   | trafficroute    |
+| GatewayAPI        | gateway.networking.k8s.io | httproute       |
+
+For example, the following manifest shows how `gitops-canaries-reader` has been extended to allow the user for viewing TrafficSplit resources when Linkerd is used:
+
+<details><summary>Expand to see example canary reader RBAC</summary>
+
+```yaml title="gitops-canaries-reader.yaml"
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: gitops-canaries-reader
+rules:
+- apiGroups:
+  - flagger.app
+  resources:
+  - canaries
+  - metrictemplates
+  verbs:
+  - get
+  - list
+- apiGroups:
+  - ""
+  resources:
+  - events
+  verbs:
+  - get
+  - watch
+  - list
+# Additional permissions for Linkerd resources are added below
+- apiGroups:
+  - split.smi-spec.io
+  resources:
+  - trafficsplits
+  verbs:
+  - get
+  - list
+```
+
+</details>
+
+## Setting up Remote Cluster Permissions
+
+In order to view canaries in a remote cluster from the management cluster, you need to consider the following:
+- The service account used to access the remote cluster needs to be able to list namespaces and custom resource definitions in the given cluster. It additionally needs to be able to impersonate users and groups.
+- The user or group that logs in to the management cluster, needs appropriate permissions to certain resources of the remote cluster.
+
+For example, applying the following manifest on remote clusters, ensures that the `wego-admin` user will be able to view canary information from within the Weave GitOps Enterprise UI on the management cluster:
+
+<details><summary>Expand to see example of remote cluster canary reader</summary>
+
+```yaml title="remote-cluster-service-user-rbac.yaml"
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: user-groups-impersonator
+rules:
+  - apiGroups: [""]
+    resources: ["users", "groups"]
+    verbs: ["impersonate"]
+  - apiGroups: [""]
+    resources: ["namespaces"]
+    verbs: ["get", "list"]
+  - apiGroups: ["apiextensions.k8s.io"]
+    resources: ["customresourcedefinitions"]
+    verbs: ["get", "list"]
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: impersonate-user-groups
+subjects:
+  - kind: ServiceAccount
+    name: remote-cluster-01  # Service account created in remote cluster
+    namespace: default
+roleRef:
+  kind: ClusterRole
+  name: user-groups-impersonator
+  apiGroup: rbac.authorization.k8s.io
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: canary-reader
+rules:
+  - apiGroups: [""]
+    resources: [ "events", "services" ]
+    verbs: [ "get", "list", "watch" ]
+  - apiGroups: [ "apps" ]
+    resources: [ "*" ]
+    verbs: [ "get", "list" ]
+  - apiGroups: [ "autoscaling" ]
+    resources: [ "*" ]
+    verbs: [ "get", "list" ]
+  - apiGroups: [ "flagger.app" ]
+    resources: [ "canaries", "metrictemplates"]
+    verbs: [ "get", "list", "watch" ]
+  - apiGroups: [ "helm.toolkit.fluxcd.io" ]
+    resources: [ "helmreleases" ]
+    verbs: [ "get", "list" ]
+  - apiGroups: [ "kustomize.toolkit.fluxcd.io" ]
+    resources: [ "kustomizations" ]
+    verbs: [ "get", "list" ]
+  - apiGroups: [ "source.toolkit.fluxcd.io" ]
+    resources: [ "buckets", "helmcharts", "gitrepositories", "helmrepositories", "ocirepositories" ]
+    verbs: [ "get", "list" ]
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: read-canaries
+subjects:
+- kind: User
+  name: wego-admin    # User logged in management cluster, impersonated via service account
+  apiGroup: rbac.authorization.k8s.io
+roleRef:
+  kind: ClusterRole
+  name: canary-reader
+  apiGroup: rbac.authorization.k8s.io
+```
+
+</details>
+
+You may need to add more users/groups to the `read-canaries` ClusterRoleBinding to ensure additional users can view canary information from within the Weave GitOps Enterprise UI.
+
 ## Deploy a Canary Release
 
 To demonstrate the progressive rollout of an application, we'll use a tiny sample web app called

diff --git a/website/static/img/dashboard-applications-delivery.png b/website/static/img/dashboard-applications-delivery.png