Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

📖 149 update docs for use in docsscscommunity #150

Merged
merged 6 commits into from
Aug 22, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -1,8 +1,8 @@
# Configuring a Cluster Stack
# Getting started

A [Cluster Stack](https://github.com/SovereignCloudStack/cluster-stacks) is full template of a Kubernetes cluster. A Cluster Stack can be configured on every provider that supports Cluster API.

The Cluster Stack Operator facilitates using Cluster Stacks by automating all steps that users would have to do manually given they have a Cluster API management cluster.
The Cluster Stack Operator facilitates using Cluster Stacks by automating all steps that users would have to do manually given they have a Cluster API management cluster.

The csctl helps to generate all files and build node images based on provided scripts in a format that the Cluster Stack Operator can use.

Expand All @@ -18,7 +18,7 @@ You should must have the following content inside your directory:
- node-image directory (optional): the directory containing config and associated scripts to build node images


## Configuring csctl
## Configuring csctl
The configuration of csctl has to be specified in the `csctl.yaml`. It needs to follow this structure:

```yaml
Expand All @@ -32,22 +32,8 @@ config:
config:
```

The apiVersion specifies the version of this configuration. Currently, there is only the version `csctl.clusterstack.x-k8s.io/v1alpha1`.
The apiVersion specifies the version of this configuration. Currently, there is only the version `csctl.clusterstack.x-k8s.io/v1alpha1`.

Furthermore, the Kubernetes version in the format "v<major>.<minor>.<patch>" (e.g. 1.27.5) has to be specified as well as the name that should be given to the Cluster Stack.
Furthermore, the Kubernetes version in the format 'v<major>.<minor>.<patch>' (e.g. 1.27.5) has to be specified as well as the name that should be given to the Cluster Stack.

Depending on your plugin, there might be a provider-specific configuration.


## Templating the versions

There are three different versions in a Cluster Stack that can be templated by `csctl`:

```markdown
- << .ClusterAddonVersion >>
- << .ClusterClassVersion >>
- << .NodeImageVersion >>
```
If you want to specify one of these versions in your Helm chart or other configuration files, then use the one of the above mentioned templated versions.

To reference your node images, you will also need << .NodeImageRegistry >>.
14 changes: 8 additions & 6 deletions docs/how_to_use_csctl.md
Original file line number Diff line number Diff line change
@@ -1,15 +1,17 @@
> Obsolete, content moved to overview.md and quickstart.md for use in docs.scs.community

# Using csctl


## What does csctl do?
## What does csctl do?

As a user, you can create clusters based on Cluster Stacks with the help of the Cluster Stack Operator. The operator needs certain files, e.g. to apply the required Helm charts, and to get the necessary information about the versions in the cluster stack.

In order to not generate these files manually, this CLI tool takes a certain pre-defined directory structure, in which users can configure all necessary Helm charts and build scripts for node images, and generates the assets that the Cluster Stack Operator can process.

Therefore, this tool can be used to configure Cluster Stacks and to test them with the Cluster Stack Operator. It can also be used to release stable releases of Cluster Stacks that can be published for a broader community.

## Different modes of csctl
## Different modes of csctl

The csctl has multiple modes that can be used for different use cases.

Expand Down Expand Up @@ -51,7 +53,7 @@ commit: f252304eb013014b35f8a91abf1f61aff2062601
If you don't see a version there, then something has gone wrong. Re-check above steps and open an issue if it still does not work!


If you're using `gh` CLI then you can also use the following to download it.
If you're using `gh` CLI then you can also use the following to download it.
```bash
$ gh release download -p csctl_0.0.2_linux_amd64 -R SovereignCloudStack/csctl
```
Expand All @@ -61,10 +63,10 @@ $ gh release download -p csctl_0.0.2_linux_amd64 -R SovereignCloudStack/csctl
The most important subcommand is `create`. This command takes a path to the directory where you configured your Cluster Stack and generates the necessary files in the output directory via the `--output` flag:

```bash
$ csctl create <path-to-cluster-stack-configuration-directory> --output <path-to-output-directory>
$ csctl create <path-to-cluster-stack-configuration-directory> --output <path-to-output-directory>
```

You can specify your node image registry with the flag `--node-image-registry`. The plugin of your provider will update the node images in the respective container registry.
You can specify your node image registry with the flag `--node-image-registry`. The plugin of your provider will update the node images in the respective container registry.

You can use the `--mode` flag to specify the mode you want to use.

Expand All @@ -74,4 +76,4 @@ For example:
$ csctl create <path-to-cluster-stack-directory> --output <path-to-output-directory> --mode hash --node-image-registry <url-of-registry>
```

You have to be authenticated to your cloud provider and container registry to which you want to upload the node images.
You have to be authenticated to your cloud provider and container registry to which you want to upload the node images.
30 changes: 30 additions & 0 deletions docs/overview.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,30 @@
# Overview

## Introduction

The [Cluster Stack Operator](https://github.com/SovereignCloudStack/cluster-stack-operator) facilitates the usage of [Cluster Stacks](https://github.com/SovereignCloudStack/cluster-stacks) by automating all steps that can be automated. It takes Cluster Stacks release assets that consist mainly of two Helm charts, one to deploy in the management cluster, the other one to deploy in the workload clusters, as well as provider-specific node image (build) information.

Users can take existing releases of Cluster Stacks and the operator and will be able to create clusters easily.

This project facilitates building node image artifacts and release assets that can be used with the Cluster Stack Operator.

## What does csctl do?

As a user, you can create clusters based on Cluster Stacks with the help of the Cluster Stack Operator. The operator needs certain files, e.g. to apply the required Helm charts, and to get the necessary information about the versions in the cluster stack.

In order to not generate these files manually, this CLI tool takes a certain pre-defined directory structure, in which users can configure all necessary Helm charts and build scripts for node images, and generates the assets that the Cluster Stack Operator can process.

Therefore, this tool can be used to configure Cluster Stacks and to test them with the Cluster Stack Operator. It can also be used to release stable releases of Cluster Stacks that can be published for a broader community.

## Features of csctl
1. Testing and quick iterations
csctl is created with a single focus of building Cluster Stacks and testing them with Cluster Stack Operator quickly. This tool helps in doing quick iterations and facilitates testing Cluster Stacks.

2. Versioning
When configuring Cluster Stacks, it is necessary to put versions in the configuration, e.g. to version a Helm chart or node images. This process is facilitated by the csctl through its own templating and mechanism to generate the right version, based on the content hash (for testing) or on a previous version (stable or beta channel). Users only have to use the right templating and the csctl will do all the versioning automatically.

3. Plugin mechanism for providers
The plugin mechanism of csctl allows providers to implement all provider-specific steps that are needed for this provider. This can contain a fully automated building and uploading process for node images, which can be referenced in the Cluster Stack (using the templating logic for versioning).

4. Automated testing of Cluster Stacks
The csctl enables automated testing of Cluster Stacks if integrated in a CI process that first builds all necessary files as well as node images (if needed) and then uses them to create a workload cluster based on the Cluster Stack.
62 changes: 62 additions & 0 deletions docs/quickstart.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,62 @@
# Quickstart

## Installation
To download `csctl` there are two ways.
Go to https://github.com/SovereignCloudStack/csctl/releases/latest and then click on the binary. The name of the binary looks similar to this `csctl_0.0.3_linux_amd64.tar.gz` for Linux amd64 architecture.

This will download the binary in your `~/Downloads` directory. Use the following commands to move it to your PATH.
```bash
tar xvzf ~/Downloads/csctl_<version>_linux_amd64.tar.gz
chmod u+x ~/Downloads/csctl
sudo mv ~/Downloads/csctl /usr/local/bin/csctl
```

Alternative way of installing the binary is to use `[gh](https://github.com/cli/cli)` command line tool.
Use the following command to download the latest binary from GitHub.
```bash
gh release download -p 'csctl_<version>_linux_amd64.tar.gz' -R SovereignCloudStack/csctl
tar xvzf csctl_<version>_linux_amd64.tar.gz
chmod u+x csctl
sudo mv ./csctl /usr/local/bin/csctl
```
For darwin based systems, the steps are similar, you'll have to choose darwin based binaries instead of linux one mentioned above. You'll also need to update your destination directory.

## Creating Cluster Stacks

The most important subcommand is `create`. This command takes a path to the directory where you configured your Cluster Stack and generates the necessary files in the output directory via the `--output` flag:

```bash
$ csctl create <path-to-cluster-stack-configuration-directory> --output <path-to-output-directory>
```

You can specify your node image registry with the flag `--node-image-registry`. The plugin of your provider will update the node images in the respective container registry.

You can use the `--mode` flag to specify the mode you want to use.

For example:

```bash
$ csctl create <path-to-cluster-stack-directory> --output <path-to-output-directory> --mode hash --node-image-registry <url-of-registry>
```

You have to be authenticated to your cloud provider and container registry to which you want to upload the node images.

## Different modes of csctl

The csctl has multiple modes that can be used for different use cases.

### Hash mode

This mode is the most used one, as it allows quick iterations and testing of a cluster stack. It takes the hash of the content of the cluster stack and generates a semver version on this. You can combine it with the `custom` channel of Cluster Stack Operator and test your Cluster Stacks easily!

### Stable mode

This mode checks for existing releases of cluster stacks and versions your cluster stack accordingly. If you have an existing release of "v1", then it would use "v2" for the new one. It also checks whether the node images and cluster addons have changed or not and will only update the versions if something actually changed.

### Beta mode

Similar to stable mode, but for a beta release channel. It versions according to "v0-beta.1", etc.

### Custom mode

The custom mode can be used to define your own version. You can input any semver version and your cluster stack will be versioned accordingly.
Loading