Define approach/pattern for quickstart guides and docs

[catmo-syntasso]

We want to create quick-start videos and docs showing how people can use Kratix in common cloud providers. We may want to scale this out as we hear about different types of clouds being used, so we should have a consistent pattern for this content.

Context: https://www.notion.so/syntasso/Quick-starts-for-Cloud-c29fe365fff644ad9eeb11eedd91aa64?pvs=4 Key purpose of these videos from doc:

• Customers can follow along and deploy Kratix in the major cloud providers
  • Fewer customers ask us how to deploy Kratix to the cloud
• CA have more resources they can share with prospects to get started with Kratix

Tasks

• [x] Define docs template structure
• [x] Define core steps for the videos
• e.g. Quick intro to Kratix, pre-requisites in your cloud, installing kratix, installing a promise, requesting a resource
• [x] Define the look and feel of any cards/slides in the video (chat to @danielbryantuk about this one and the one above)

[aclevername]

Docs

Prior art

Today our quick-start guide for kratix is:

1. Install cert-manager
2. Install Kratix and Flux
   • this includes minio, because its designed to be single cluster all in-one
3. Install configure Kratix and Flux (destinations, statestore, kustomizations)
4. Install a promise to test it works

Our full installation guide for multi-cluster is:

1. Create platform cluster if doesn't exist, no guidance on how apart from KinD
2. Install cert-manager
3. Install Kratix
4. Setup statestore, 3 options:
   • minio in cluster (only works on KinD, not useful)
   • gitea in cluster (only works on KinD, not useful)
   • Custom where we link to our generic docs on configuring kratix with the details of a git repo/bucket. we leave it up to them to create it
5. Create worker cluster if it doesn't exist, no guidance on how apart from KinD
6. Install Flux on worker
7. Configure flux to read from statestore
8. Register worker as destination
9. Check canary namespace exists as health check

Of all of these, none of them are cloud provider specific unless we want to:

• recommend they use the cloud providers available statestore
  • GCP- GCS Bucket (GCP has no self-hosted git provider, they deprecated it lol)
  • AWS- S3 Bucket or CodeCommit
  • Azure- Azure Devops Repo (Azure buckets isn't a thing)
• Document how to create a cluster for the cloud provider
  • terrible idea

Docs Proposal

We keep the format of our existing multi cluster documentation, remove the KinD bias and make cloud appear first-class (even if very little changes between them):

1. Create a new sidebar section for installation and list each cloud provider (EKS/AKS/GKE) as an option plus our current KinD clusters (call it local or something more generic)
2. Add some callouts where possible in the cloud provider pages, e.g.:
   • link to AWS basic getting started on creating a cluster docs
   • links to creating s3 bucket/cloud commit repo for the statestore
   • how to let Kratix authenticate with the bucket/cloud commit repo, pointing at our existing docs and maybe showing an example
   • how to let flux authenticate with bucket/cloud commit repo, pointing to existing flux docs

To reduce duplication of text use markdown partials to segment the sections of the docs that are the same so they can be re-used across all pages. For example we have a cert-manager partial that we write once and reuse across pages, we can achieve something very similar for the installation doc sections

[aclevername]

Video

Prior art

We don't have anything like this

Proposal

As documented in comment before, there isn't really anything cloud provider specific with the exception of using a statestore provided by the cloud. For the sake of this video being a more compelling use case of kratix I think it makes sense to use Github and not the cloud provider. We could not do this and instead show the creation of an azure devops repo/s3 bucket/gcs bucket, but that just isn't good and anybody with any gitops knowledge will find it weird.

I think the videos should all be the same, with the exception of:

1. Video starts showing the cloud provider console, show the clusters (platform and worker) exists in console
2. Show a brief look at the cloud provider docs used to create it, e.g. show them this page for a couple of second and link to it in the video
3. Setup terminal to make it clear we are using a cloud provider cluster, e.g.
4. Reference back console where possible through-out the demo, e.g. show GKE pods overview:
5. At the end lets install a cloud provider specific promise and show it working, e.g. s3-bucket promise

Thats it. The rest is following along with our existing documentation for installing/configuring kratix and flux.

Script

1. Show console with platform/worker cluster
2. Briefly show docs/tool used to create cluster (e.g. eksctl)
3. Show terminal, with PS1 set to show the cluster name making it clear which cloud provider
4. Install cert-manager
5. Install Kratix
6. If possible show console (e.g. GKE has support for seeing pods, unsure on EKS/AKS)
7. Setup setup Github Repo as statestore
   • Talk about how you could use the cloud specific tool (e.g. s3 buckets)- show console and our docs
8. Install Flux on worker
9. Configure flux to read from statestore
10. Register worker as destination
11. Check canary namespace exists as health check
12. Install cloud-specific promise
13. Request it
14. Show thing being created in the console

[aclevername]

Pending the chat with @danielbryantuk until Monday

[aclevername]

chatted with @danielbryantuk, going to do a storyboard about what the video should be and decide on how much editing we want to do

[aclevername]

skipping story boarding for now, we might come back to it later after recording the first draft