chore: Set latest docusaurus version (#224)

Made with ❤️️ by updatecli

Co-authored-by: updatecli-bot <[email protected]>

Author: github-actions[bot]

versioned_docs/version-0.12/architecture.md

@@ -0,0 +1,44 @@
+# Architecture
+
+Fleet has two primary components.  The Fleet controller and the cluster agents.  These
+components work in a two-stage pull model.  The Fleet controller will pull from git and the
+cluster agents will pull from the Fleet controller.
+
+## Fleet Controller
+
+The Fleet controller is a set of Kubernetes controllers running in any standard Kubernetes
+cluster.  The only API exposed by the Fleet controller is the Kubernetes API, there is no
+custom API for the fleet controller.
+
+## Cluster Agents
+
+One cluster agent runs in each cluster and is responsible for talking to the Fleet controller.
+The only communication from cluster to Fleet controller is by this agent and all communication
+goes from the managed cluster to the Fleet controller. The fleet manager does not initiate
+connections to downstream clusters. This means managed clusters can run in private networks and behind
+NATs. The only requirement is the cluster agent needs to be able to communicate with the
+Kubernetes API of the cluster running the Fleet controller. The one exception to this is if you use
+the [manager initiated](./cluster-registration.md#manager-initiated) cluster registration flow.  This is not required, but
+an optional pattern.
+
+The cluster agents are not assumed to have an "always on" connection.  They will resume operation as
+soon as they can connect. Future enhancements will probably add the ability to schedule times of when
+the agent checks in, as it stands right now they will always attempt to connect.
+
+## Security
+
+The Fleet controller dynamically creates service accounts, manages their RBAC and then gives the
+tokens to the downstream clusters. Clusters are registered by optionally expiring cluster registration tokens.
+The cluster registration token is used only during the registration process to generate a credential specific
+to that cluster. After the cluster credential is established the cluster "forgets" the cluster registration
+ token.
+
+The service accounts given to the clusters only have privileges to list `BundleDeployment` in the namespace created
+specifically for that cluster. It can also update the `status` subresource of `BundleDeployment` and the `status`
+subresource of it's `Cluster` resource.
+
+## Component Overview
+
+An overview of the components and how they interact on a high level.
+
+![Components](/img/FleetComponents.svg)

versioned_docs/version-0.12/bundle-add.md

@@ -0,0 +1,112 @@
+# Create a Bundle Resource
+
+Bundles are automatically created by Fleet when a `GitRepo` is created. In most cases `Bundles` should not be created
+manually by the user. If you want to deploy resources from a git repository use a
+[GitRepo](https://fleet.rancher.io/gitrepo-add) instead.
+
+If you want to deploy resources without a git repository follow this guide to create a `Bundle`.
+
+When creating a `GitRepo` Fleet will fetch the resources from a git repository, and add them to a Bundle.
+When creating a `Bundle` resources need to be explicitly specified in the `Bundle` Spec.
+Resources can be compressed with gz. See [here](https://github.com/rancher/rancher/blob/v2.7.3/pkg/controllers/provisioningv2/managedchart/managedchart.go#L149-L153)
+an example of how Rancher uses compression in go code.
+
+If you would like to deploy in downstream clusters, you need to define targets. Targets work similarly to targets in `GitRepo`.
+See [Mapping to Downstream Clusters](https://fleet.rancher.io/gitrepo-targets#defining-targets).
+
+The following example creates a nginx `Deployment` in the local cluster:
+
+```yaml
+kind: Bundle
+apiVersion: fleet.cattle.io/v1alpha1
+metadata:
+  # Any name can be used here
+  name: my-bundle
+  # For single cluster use fleet-local, otherwise use the namespace of
+  # your choosing
+  namespace: fleet-local
+spec:
+  resources:
+  # List of all resources that will be deployed
+  - content: |
+      apiVersion: apps/v1
+      kind: Deployment
+      metadata:
+        name: nginx-deployment
+        labels:
+          app: nginx
+      spec:
+        replicas: 3
+        selector:
+          matchLabels:
+            app: nginx
+        template:
+          metadata:
+            labels:
+              app: nginx
+          spec:
+            containers:
+              - name: nginx
+                image: nginx:1.14.2
+                ports:
+                  - containerPort: 80
+    name: nginx.yaml
+  targets:
+  - clusterName: local
+
+```
+
+## Targets
+
+The bundle can target multiple clusters. It uses the same [targeting as the GitRepo](gitrepo-targets#target-matching).
+Additional [customization options](gitrepo-targets#supported-customizations) can be specified per target:
+
+```yaml
+targets:
+- clusterSelector:
+    matchLabels:
+      env: dev
+  defaultNamespace: lab-1
+  helm:
+    values:
+      replicas: 1
+```
+
+## Limitations
+
+Helm options related to downloading the helm chart will be ignored. The helm chart is downloaded by the fleet-cli, which creates the bundles. The bundle has to contain all the resources from the chart. Therefore the bundle will ignore:
+
+* `spec.helm.repo`
+* `spec.helm.charts`
+
+You can't use a `fleet.yaml` in resources, it is only used by the fleet-cli to create bundles.
+
+The `spec.targetRestrictions` field is not useful, as it is an allow list for targets specified in `spec.targets`. It is not needed, since `targets` are explicitly given in a bundle and an empty `targetRestrictions` defaults to allow.
+
+## Convert a Helm Chart into a Bundle
+
+You can use the Fleet CLI to convert a Helm chart into a bundle.
+
+For example, you can download and convert the "external secrets" operator chart like this:
+```
+cat > targets.yaml <<EOF
+targets:
+- clusterSelector: {}
+EOF
+
+mkdir app
+cat > app/fleet.yaml <<EOF
+defaultNamespace: external-secrets
+helm:
+  repo: https://charts.external-secrets.io
+  chart: external-secrets
+EOF
+
+fleet apply --compress --targets-file=targets.yaml -n fleet-default -o - external-secrets app > eso-bundle.yaml
+
+kubectl apply -f eso-bundle.yaml
+```
+
+Make sure you use a cluster selector in `targets.yaml`, that matches all clusters you want to deploy to.
+
+The blog post on [Fleet: Multi-Cluster Deployment with the Help of External Secrets](https://www.suse.com/c/rancher_blog/fleet-multi-cluster-deployment-with-the-help-of-external-secrets/) has more information.