docs: wip

docs/examples/terraform-layer.yaml

@@ -0,0 +1,15 @@
+apiVersion: config.terraform.padok.cloud/v1alpha1
+kind: TerraformLayer
+metadata:
+  name: my-layer
+  namespace: burrito-project
+spec:
+  branch: main
+  path: terraform
+  remediationStrategy:
+    autoApply: false
+  repository:
+    name: my-repository
+    namespace: burrito-project
+  terraform:
+    version: 1.3.1

docs/examples/terraform-repository.yaml

@@ -0,0 +1,8 @@
+apiVersion: config.terraform.padok.cloud/v1alpha1
+kind: TerraformRepository
+metadata:
+  name: my-repository
+  namespace: burrito-project
+spec:
+  repository:
+    url: https://github.com/padok-team/burrito-examples

docs/examples/values-simple.yaml

@@ -0,0 +1,17 @@
+config:
+  burrito:
+    controller:
+      timers:
+        driftDetection: 10m # run drift detection every 10 minutes
+        onError: 10s # wait 10 seconds before retrying on error
+        waitAction: 1m # wait 1 minute before retrying on locked layer
+        failureGracePeriod: 30s # set a grace period of 30 seconds before retrying on failure (increases exponentially with the amount of failed retries)
+    datastore:
+      storage:
+        mock: true # use a mock storage for the datastore (useful for testing, not recommended for production)
+tenants:
+  - namespace:
+      create: true
+      name: "burrito-project"
+    serviceAccounts:
+    - name: burrito-runner

docs/faq.md

@@ -1,26 +1 @@
-# Overview
-
-## What is burrito?
-
-**Burrito** is a TACoS (**T**erraform **A**utomation **Co**llaboration **S**oftware) Kubernetes Operator.
-
-![demo](assets/demo/demo.gif)
-
-## Why burrito?
-
-[`terraform`](https://www.terraform.io/) is a tremendous tool to manage your infrastructure in IaC.
-However, it lacks built-in solutions for managing [state drift](https://developer.hashicorp.com/terraform/tutorials/state/resource-drift).
-
-Additionally, configuring a CI/CD pipeline for Terraform can be challenging and often varies depending on the selected tools
-
-Finally, currently, there is no easy way to navigate your Terraform state to truly understand the modifications it undergoes when running `terraform apply`.
-
-`burrito` aims to tackle those issues by:
-
-- Planning continuously your Terraform code and run applies if needed
-- Offering an out of the box PR/MR integration so you do not have to write CI/CD pipelines for Terraform ever again
-- Showing your state's modifications in a simple Web UI
-
-## Getting started
-
-Follow our [getting started guide](./getting-started.md). Further user oriented [documentation](./user-guide/) is provided for additional features.
+# TODO - FAQ

docs/getting-started/iac-drift-detection.md

@@ -1 +1,174 @@
-# TODO - IAC Drift Detection tutorial
+# Burrito Drift Detection
+
+Drift detection is the core feature of Burrito. It allows you to monitor the drift between your Terraform state and your infrastructure in real-time.
+Burrito continuously plans your Terraform code by launching runner pods that will download the Terraform code, plan it, and store the result in its datastore.
+
+## Exercise
+
+Follow the steps below to set up Burrito on a local cluster and start planning your Terraform code automatically.
+
+### Set up a local cluster
+
+1. Install [kind](https://kind.sigs.k8s.io/docs/user/quick-start/), [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) and [helm](https://helm.sh/docs/intro/install/).
+2. Create a new kind cluster:
+
+```bash
+kind create cluster
+```
+
+3. Install Burrito with Helm as described in the [installation guide](../installation/with-helm.md).
+
+```bash
+helm upgrade --install burrito oci://ghcr.io/padok-team/charts/burrito -n burrito-system -f https://raw.githubusercontent.com/padok-team/burrito/main/docs/examples/values-simple.yaml
+```
+
+With this command, you installed burrito with the following configuration:
+
+```yaml
+config:
+  burrito:
+    controller:
+      timers:
+        driftDetection: 10m # run drift detection every 10 minutes
+        onError: 10s # wait 10 seconds before retrying on error
+        waitAction: 1m # wait 1 minute before retrying on locked layer
+        failureGracePeriod: 30s # set a grace period of 30 seconds before retrying on failure (increases exponentially with the amount of failed retries)
+    datastore:
+      storage:
+        mock: true # use a mock storage for the datastore (useful for testing, not recommended for production)
+tenants:
+  - namespace:
+      create: true
+      name: "burrito-project"
+```
+
+Burrito should be up and running in the `burrito-system` namespace.
+
+```bash
+kubectl get pods -n burrito-system
+
+Output:
+NAME                                   READY   STATUS    RESTARTS   AGE
+burrito-controllers-6945797c5d-kjfl2   1/1     Running   0          2m00s
+burrito-datastore-94d999f54-kbg9z      1/1     Running   0          2m00s
+burrito-server-764f75766b-qw5nx        1/1     Running   0          2m00s
+```
+
+### Connect Burrito to some Terraform code
+
+You will use the [example Terraform code](https://github.com/padok-team/burrito-examples) that we have prepared for you.
+This repository contains simple Terraform and Terragrunt with local random-pets resources that you can use to test Burrito.
+
+1. Create a TerraformRepository resource in the `burrito-system` namespace:
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/padok-team/burrito/main/docs/examples/terraform-repository.yaml
+```
+
+Here is the content of the `TerraformRepository` and `TerraformLayer` resources that you have created
+
+```yaml
+apiVersion: config.terraform.padok.cloud/v1alpha1
+kind: TerraformRepository
+metadata:
+  name: my-repo
+  namespace: burrito-project
+spec:
+  repository:
+    url: git@github.com:padok-team/burrito-examples.git
+```
+
+2. Create a `TerraformLayer` resource in the `burrito-system` namespace, referencing the `TerraformRepository` you just created. For now, the autoApply is set to false, so the layer will only plan the Terraform code and not apply it.
+
+```bash
+kubectl apply -f https://raw.githubusercontent.com/padok-team/burrito/main/docs/examples/terraform-layer.yaml
+```
+
+```yaml
+apiVersion: config.terraform.padok.cloud/v1alpha1
+kind: TerraformLayer
+metadata:
+  name: my-layer
+  namespace: burrito-project
+spec:
+  branch: main
+  path: terraform
+  remediationStrategy:
+    autoApply: false
+  repository:
+    name: my-repository
+    namespace: burrito-project
+  terraform:
+    version: 1.3.1
+```
+
+3. Check that your Terraform code is being planned by Burrito:
+
+```bash
+kubectl get pods -n burrito-project
+```
+
+Output:
+
+```bash
+NAME                   READY   STATUS      RESTARTS   AGE
+my-layer-apply-xntrg   0/1     Completed   0          82s
+```
+
+4. The `TerraformLayer` should have been updated with the result of the plan. You can check the status of the `TerraformLayer` directly by querying the `TerraformLayer` resource, or by checking the burrito UI.
+
+```bash
+kubectl get tfl -n burrito-project
+```
+
+Output:
+
+```bash
+NAME       STATE         REPOSITORY      BRANCH   PATH        LAST RESULT
+my-layer   ApplyNeeded   my-repository   main     terraform   Plan: 3 to create, 0 to update, 0 to delete
+```
+
+```bash
+kubectl port-forward svc/burrito-server -n burrito-system 8080:80
+```
+
+![Burrito drift example](../assets/demo/drift-example.png)
+
+5. Activate the autoApply feature by updating the `TerraformLayer` resource:
+
+```bash
+kubectl patch tfl my-layer -n burrito-project --type merge --patch '{"spec":{"remediationStrategy":{"autoApply":true}}}'
+```
+
+6. Check that the Terraform code was applied:
+
+```bash
+kubectl get pods -n burrito-project
+```
+
+Output:
+
+```bash
+NAME                   READY   STATUS      RESTARTS   AGE
+my-layer-apply-bxlcr   0/1     Completed   0          54s
+my-layer-plan-jv86k    0/1     Completed   0          7m22s
+```
+
+```bash
+kubectl get tfl -n burrito-project
+```
+
+Output:
+
+```bash
+NAME       STATE   REPOSITORY      BRANCH   PATH        LAST RESULT
+my-layer   Idle    my-repository   main     terraform   Apply Successful
+```
+
+### Conclusion
+
+You have successfully set up Burrito on a local cluster and planned your Terraform code automatically. You can now monitor the drift between your Terraform state and your infrastructure in real-time.
+
+## Next steps
+
+- Learn how to [configure a PR/MR workflow](../pr-mr-workflow.md)

docs/getting-started/index.md

@@ -0,0 +1,7 @@
+# Getting started
+
+Follow the 3 steps below to get started with Burrito:
+
+- [IaC Drift detection](./iac-drift-detection.md): Quickly set up Burrito and start monitoring Terraform state drift.
+- [PR/MR plan/apply Workflow](./pr-mr-workflow.md): Configure Burrito to automatically plan and apply Terraform code on PR/MR.
+- [UI Overview](./ui-overview.md): Learn how to navigate the Burrito UI.

docs/installation/with-helm.md

@@ -0,0 +1,60 @@
+# Install burrito with Helm
+
+## Requirements
+
+- Installed [kubectl](https://kubernetes.io/docs/tasks/tools/install-kubectl/) command-line tool
+- Installed [helm](https://helm.sh/docs/intro/install/) command-line tool **(version v3.8.0 and further)**
+- Have access to a Kubernetes cluster
+
+## 1. Basic installation
+
+!!! info
+    Our Helm chart is published in an [OCI-based registry](https://helm.sh/docs/topics/registries/) (ghcr.io). You must use Helm v3.8.0 or above.
+
+```bash
+helm install burrito oci://ghcr.io/padok-team/charts/burrito -n burrito-system --create-namespace
+```
+
+This will create a new namespace, `burrito-system`, where the burrito core components will live.
+
+You can change the chart's version with any version available on [our Chart registry](https://github.com/padok-team/burrito/pkgs/container/charts%2Fburrito).
+
+## 2. Burrito Helm configuration
+
+The Burrito configuration is managed through Helm values files, which can be overridden at installation time.
+
+You can find the default values of the Burrito Helm chart by running:
+
+```bash
+helm show values oci://ghcr.io/padok-team/charts/burrito
+```
+
+The [source code](https://github.com/padok-team/burrito/tree/main/deploy/charts/burrito) and [values file](https://github.com/padok-team/burrito/blob/main/deploy/charts/burrito/values.yaml) of the chart is available on [burrito GitHub repository](https://github.com/padok-team/burrito).
+
+
+Here is an example of a simple burrito Helm values file that you can use to bootstrap your installation:
+
+```yaml
+config:
+  burrito:
+    controller:
+      timers:
+        driftDetection: 10m # run drift detection every 10 minutes
+        onError: 10s # wait 10 seconds before retrying on error
+        waitAction: 1m # wait 1 minute before retrying on locked layer
+        failureGracePeriod: 30s # set a grace period of 30 seconds before retrying on failure (increases exponentially with the amount of failed retries)
+    datastore:
+      storage:
+        mock: true # use a mock storage for the datastore (useful for testing, not recommended for production)
+tenants:
+  - namespace:
+      create: true
+      name: "burrito-project"
+    serviceAccounts:
+    - name: burrito-runner
+      annotations:
+        iam.gke.io/gcp-service-account: burrito@company-project.iam.gserviceaccount.com # example: use GKE Workload Identity to have access to GCP infrastructure
+```
+
+!!! info
+    Learn more about these values in the chart's [README file](https://github.com/padok-team/burrito/tree/main/deploy/charts/burrito/README.md) and [Multi-tenant architecture](../operator-manual/multi-tenant-architecture.md).