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

chore: move current user guides of kusion to a new dir for cli #590

Merged
merged 2 commits into from
Jan 22, 2025
Merged
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
2 changes: 1 addition & 1 deletion docs/kusion/3-concepts/4-workspace.md
Original file line number Diff line number Diff line change
@@ -93,7 +93,7 @@ The `importedResources` block is designed to declare the import of existing clou

### secretStore

The `secretStore` field can be used to access the sensitive data stored in a cloud-based secrets manager. More details can be found in [here](../5-user-guides/4-secrets-management/1-using-cloud-secrets.md).
The `secretStore` field can be used to access the sensitive data stored in a cloud-based secrets manager. More details can be found in [here](../5-user-guides/1-using-kusion-cli/4-secrets-management/1-using-cloud-secrets.md).

### context

8 changes: 4 additions & 4 deletions docs/kusion/4-configuration-walkthrough/8-monitoring.md
Original file line number Diff line number Diff line change
@@ -8,7 +8,7 @@ As of version 0.11.0, Kusion supports integration with Prometheus by managing sc

For the monitoring configuration to work (more specifically, consumed by Prometheus), this requires the target cluster to have installed Prometheus correctly, either as a Kubernetes operator or a server/agent.

More about how to set up Prometheus can be found in the [Prometheus User Guide for Kusion](../user-guides/observability/prometheus)
More about how to set up Prometheus can be found in the [Prometheus User Guide for Kusion](../5-user-guides/1-using-kusion-cli/3-observability/1-prometheus.md)
:::

## Import
@@ -26,7 +26,7 @@ import monitoring as m

In addition to the KCL configuration file, there are also workspace-level configurations that should be set first. In an ideal scenario, this step is done by the platform engineers.

In the event that they do not exist for you or your organization, e.g. if you are an individual developer, you can either do it yourself or use the [default values](#default-values) provided by the KusionStack team. The steps to do this yourself can be found in the [Prometheus User Guide for Kusion](../user-guides/observability/prometheus#setting-up-workspace-configs).
In the event that they do not exist for you or your organization, e.g. if you are an individual developer, you can either do it yourself or use the [default values](#default-values) provided by the KusionStack team. The steps to do this yourself can be found in the [Prometheus User Guide for Kusion](../5-user-guides/1-using-kusion-cli/3-observability/1-prometheus.md#setting-up-workspace-configs).

:::info

@@ -87,7 +87,7 @@ Note that numbered ports only work when your Prometheus is not running as an ope

Neither `path` and `port` are required fields if Prometheus runs as an operator. If omitted, `path` defaults to `/metrics`, and `port` defaults to the container port or service port, depending on which resource is being monitored. If Prometheus does not run as an operator, both fields are required.

Scraping scheme, interval and timeout are considered platform-managed configurations and are therefore managed as part of the [workspace configurations](../user-guides/observability/prometheus#setting-up-workspace-configs).
Scraping scheme, interval and timeout are considered platform-managed configurations and are therefore managed as part of the [workspace configurations](../5-user-guides/1-using-kusion-cli/3-observability/1-prometheus.md#setting-up-workspace-configs).

More details about how the Prometheus integration works can be found in the [design documentation](https://github.com/KusionStack/kusion/blob/main/docs/prometheus.md).

@@ -99,4 +99,4 @@ If no workspace configurations are found, the default values provided by the Kus
- Scraping scheme defaults to http
- Defaults to NOT running as an operator

If any of the default values does not meet your need, you can change them by [setting up the workspace configuration](../user-guides/observability/prometheus#setting-up-workspace-configs).
If any of the default values does not meet your need, you can change them by [setting up the workspace configuration](../5-user-guides/1-using-kusion-cli/3-observability/1-prometheus.md#setting-up-workspace-configs).
Original file line number Diff line number Diff line change
@@ -11,7 +11,7 @@ This tutorial will demonstrate how to deploy a WordPress application with Kusion

## Prerequisites

- Install [Kusion](../../2-getting-started/1-install-kusion.md).
- Install [Kusion](../../../2-getting-started/1-install-kusion.md).
- Install [kubectl CLI](https://kubernetes.io/docs/tasks/tools/#kubectl) and run a [Kubernetes](https://kubernetes.io/) or [k3s](https://docs.k3s.io/quick-start) or [k3d](https://k3d.io/v5.4.4/#installation) or [MiniKube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node) cluster.
- Prepare a cloud service account and create a user with at least **VPCFullAccess** and **RDSFullAccess** related permissions to use the Relational Database Service (RDS). This kind of user can be created and managed in the Identity and Access Management (IAM) console of the cloud vendor.
- The environment that executes `kusion` needs to have connectivity to terraform registry to download the terraform providers.
@@ -125,7 +125,7 @@ kusion workspace show
The `workspace.yaml` is a sample configuration file for workspace management, including `MySQL` module configs. Workspace configurations are usually declared by **Platform Engineers** and will take effect through the corresponding stack.

:::info
More details about the configuration of Workspace can be found in [Concepts of Workspace](../../3-concepts/4-workspace.md).
More details about the configuration of Workspace can be found in [Concepts of Workspace](../../../3-concepts/4-workspace.md).
:::

## Create Project And Stack
Original file line number Diff line number Diff line change
@@ -123,7 +123,7 @@ tree
```

:::info
More details about the directory structure can be found in [Project](../../3-concepts/1-project/1-overview.md) and [Stack](../../3-concepts/2-stack/1-overview.md).
More details about the directory structure can be found in [Project](../../../3-concepts/1-project/1-overview.md) and [Stack](../../../3-concepts/2-stack/1-overview.md).
:::

### Update And Review Configuration Codes
Original file line number Diff line number Diff line change
@@ -6,7 +6,7 @@ id: deploy-application

This guide shows you how to use Kusion CLIs to complete the deployment of an application running in Kubernetes.
We call the abstraction of application operation and maintenance configuration as `AppConfiguration`, and its instance as `Application`.
It is essentially a configuration model that describes an application. The complete definition can be seen [here](../../reference/modules/developer-schemas/app-configuration).
It is essentially a configuration model that describes an application. The complete definition can be seen [here](../../../6-reference/2-modules/1-developer-schemas/app-configuration.md).

In production, the application generally includes minimally several k8s resources:

@@ -31,7 +31,7 @@ Before we start, we need to complete the following steps:
1、Install Kusion

We recommend using HomeBrew(Mac), Scoop(Windows), or an installation shell script to download and install Kusion.
See [Download and Install](../../getting-started/install-kusion) for more details.
See [Download and Install](../../../2-getting-started/1-install-kusion.md) for more details.

2、Running Kubernetes cluster

@@ -44,7 +44,7 @@ This guide is to deploy an app using Kusion, relying on the Kusion CLI and an ex

### Initializing workspace configuration

In version 0.10.0, we have introduced the new concept of [workspaces](../../concepts/workspace), which is a logical layer whose configurations represent an opinionated set of defaults, often appointed by the platform team. In most cases workspaces are represented with an "environment" in traditional SDLC terms. These workspaces provide a means to separate the concerns between the **application developers** who wish to focus on business logic, and a group of **platform engineers** who wish to standardize the applications on the platform.
In version 0.10.0, we have introduced the new concept of [workspaces](../../../3-concepts/4-workspace.md), which is a logical layer whose configurations represent an opinionated set of defaults, often appointed by the platform team. In most cases workspaces are represented with an "environment" in traditional SDLC terms. These workspaces provide a means to separate the concerns between the **application developers** who wish to focus on business logic, and a group of **platform engineers** who wish to standardize the applications on the platform.

Driven by the discipline of Platform Engineering, management of the workspaces, including create/updating/deleting workspaces and their configurations should be done by dedicated platform engineers in a large software organizations to facilitate a more mature and scalable collaboration pattern.

@@ -120,7 +120,7 @@ The project directory has the following files that are automatically generated:
In general, the `.k` files are the KCL source code that represents the application configuration, and the `.yaml` is the static configuration file that describes behavior at the project or stack level.

:::info
See [Project](../../concepts/project/overview) and [Stack](../../concepts/stack/overview) for more details about Project and Stack.
See [Project](../../../3-concepts/1-project/1-overview.md) and [Stack](../../../3-concepts/2-stack/1-overview.md) for more details about Project and Stack.
:::

The `kusion init` command will create a demo quickstart application, we may update the `dev/kcl.mod` and `dev/main.k` later.
@@ -189,7 +189,7 @@ cd simple-service/dev && kusion preview
```

:::tip
For instructions on the kusion command line tool, execute `kusion -h`, or refer to the tool's online [documentation](../../reference/commands).
For instructions on the kusion command line tool, execute `kusion -h`, or refer to the tool's online [documentation](../../../6-reference/1-commands/index.md).
:::

## Applying
Original file line number Diff line number Diff line change
@@ -8,9 +8,9 @@ Kusion now offers advanced customized health checks leveraging the power of `KCL

## Prerequisites

Please refer to the [prerequisites](deploy-application#prerequisites) in the guide for deploying an application.
Please refer to the [prerequisites](1-deploy-application.md#prerequisites) in the guide for deploying an application.

The example below also requires you to have [initialized the project](deploy-application#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](deploy-application#kclmod) under the stack directory.
The example below also requires you to have [initialized the project](1-deploy-application.md#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](1-deploy-application.md#kclmod) under the stack directory.

## Defining a Health Policy

@@ -191,4 +191,4 @@ Ensure that the resource meets the conditions defined in your health policy.

Customized health checks provides a powerful way to ensure your Kubernetes resources are in the desired state before considering an `apply` operation complete. By defining health policies, you can automate the validation of your resources and ensure they meet specific criteria before being considered healthy. By leveraging KCL, you can create sophisticated health check logic tailored to your specific `project` needs.

For more details on KCL and its syntax, refer to the [KCL documentation](../../4-configuration-walkthrough/2-kcl-basics.md).
For more details on KCL and its syntax, refer to the [KCL documentation](../../../4-configuration-walkthrough/2-kcl-basics.md).
Original file line number Diff line number Diff line change
@@ -6,17 +6,17 @@ id: container

You can manage container-level configurations in the `AppConfiguration` model via the `containers` field (under the `workload` schema). By default, everything defined in the `containers` field will be treated as application containers. Sidecar containers will be supported in a future version of kusion.

For the full `Container` schema reference, please see [here](../../reference/modules/developer-schemas/workload/service#schema-container) for more details.
For the full `Container` schema reference, please see [here](../../../6-reference/2-modules/1-developer-schemas/workload/service.md#schema-container) for more details.

## Pre-requisite

Please refer to the [prerequisites](deploy-application#prerequisites) in the guide for deploying an application.
Please refer to the [prerequisites](1-deploy-application.md#prerequisites) in the guide for deploying an application.

The example below also requires you to have [initialized the project](deploy-application#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](deploy-application#kclmod) under the stack directory.
The example below also requires you to have [initialized the project](1-deploy-application.md#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](1-deploy-application.md#kclmod) under the stack directory.

## Managing Workspace Configuration

In the last guide, we introduced a step to [initialize a workspace](deploy-application#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there.
In the last guide, we introduced a step to [initialize a workspace](1-deploy-application.md#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there.

However, if you (or the platform team) would like to set default values for the workloads to standardize the behavior of applications in the `dev` workspace, you can do so by updating the `~/dev.yaml`:

@@ -40,7 +40,7 @@ The workspace configuration need to be updated with the command:
kusion workspace update dev -f ~/dev.yaml
```

For a full reference of what can be configured in the workspace level, please see the [workspace reference](../../reference/modules/workspace-configs/workload/service).
For a full reference of what can be configured in the workspace level, please see the [workspace reference](../../../6-reference/2-modules/2-workspace-configs/workload/service.md).

## Example

@@ -89,7 +89,7 @@ import network as n

## Apply

Re-run steps in [Applying](deploy-application#applying), new container configuration can be applied.
Re-run steps in [Applying](1-deploy-application.md#applying), new container configuration can be applied.

```
$ kusion apply
Original file line number Diff line number Diff line change
@@ -8,17 +8,17 @@ You can determine how to expose your service in the `AppConfiguration` model via

Unless explicitly defined, each of the ports exposed is by default exposed privately as a `ClusterIP` type service. You can expose a port publicly by specifying the `public` field in the `Port` schema. At the moment, the implementation for publicly access is done via Load Balancer type service backed by cloud providers. Ingress will be supported in a future version of kusion.

For the `Port` schema reference, please see [here](../../reference/modules/developer-schemas/workload/service#schema-port) for more details.
For the `Port` schema reference, please see [here](../../../6-reference/2-modules/1-developer-schemas/workload/service.md#schema-port) for more details.

## Prerequisites

Please refer to the [prerequisites](deploy-application#prerequisites) in the guide for deploying an application.
Please refer to the [prerequisites](1-deploy-application.md#prerequisites) in the guide for deploying an application.

The example below also requires you to have [initialized the project](deploy-application#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](deploy-application#kclmod) under the stack directory.
The example below also requires you to have [initialized the project](1-deploy-application.md#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](1-deploy-application.md#kclmod) under the stack directory.

## Managing Workspace Configuration

In the first guide in this series, we introduced a step to [initialize a workspace](deploy-application#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there.
In the first guide in this series, we introduced a step to [initialize a workspace](1-deploy-application.md#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there.

However, if you (or the platform team) would like to set default values for the services to standardize the behavior of applications in the `dev` workspace, you can do so by updating the `~/dev.yaml`:

@@ -40,7 +40,7 @@ The workspace configuration need to be updated with the command:
kusion workspace update dev -f ~/dev.yaml
```

For a full reference of what can be configured in the workspace level, please see the [workspace reference](../../reference/modules/workspace-configs/networking/network).
For a full reference of what can be configured in the workspace level, please see the [workspace reference](../../../6-reference/2-modules/2-workspace-configs/networking/network.md).

## Example

@@ -92,7 +92,7 @@ The code above changes the service port to expose from `80` in the last guide to

## Applying

Re-run steps in [Applying](deploy-application#applying), new service configuration can be applied.
Re-run steps in [Applying](1-deploy-application.md#applying), new service configuration can be applied.

```
$ kusion apply
Original file line number Diff line number Diff line change
@@ -6,17 +6,17 @@ id: image-upgrade

You can declare the application's container image via `image` field of the `Container` schema.

For the full `Container` schema reference, please see [here](../../reference/modules/developer-schemas/workload/service#schema-container) for more details.
For the full `Container` schema reference, please see [here](../../../6-reference/2-modules/1-developer-schemas/workload/service.md#schema-container) for more details.

## Pre-requisite

Please refer to the [prerequisites](deploy-application#prerequisites) in the guide for deploying an application.
Please refer to the [prerequisites](1-deploy-application.md#prerequisites) in the guide for deploying an application.

The example below also requires you to have [initialized the project](deploy-application#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](deploy-application#kclmod) under the stack directory.
The example below also requires you to have [initialized the project](1-deploy-application.md#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](1-deploy-application.md#kclmod) under the stack directory.

## Managing Workspace Configuration

In the first guide in this series, we introduced a step to [initialize a workspace](deploy-application#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there.
In the first guide in this series, we introduced a step to [initialize a workspace](1-deploy-application.md#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there.

## Example

@@ -40,7 +40,7 @@ Everything else in `main.k` stay the same.

## Applying

Re-run steps in [Applying](deploy-application#applying), update image is completed.
Re-run steps in [Applying](1-deploy-application.md#applying), update image is completed.

```
$ kusion apply
Original file line number Diff line number Diff line change
@@ -6,17 +6,17 @@ id: resource-spec

You can manage container-level resource specification in the `AppConfiguration` model via the `resources` field (under the `Container` schema).

For the full `Container` schema reference, please see [here](../../reference/modules/developer-schemas/workload/service#schema-container) for more details.
For the full `Container` schema reference, please see [here](../../../6-reference/2-modules/1-developer-schemas/workload/service.md#schema-container) for more details.

## Prerequisites

Please refer to the [prerequisites](deploy-application#prerequisites) in the guide for deploying an application.
Please refer to the [prerequisites](1-deploy-application.md#prerequisites) in the guide for deploying an application.

The example below also requires you to have [initialized the project](deploy-application#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](deploy-application#kclmod) under the stack directory.
The example below also requires you to have [initialized the project](1-deploy-application.md#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](1-deploy-application.md#kclmod) under the stack directory.

## Managing Workspace Configuration

In the first guide in this series, we introduced a step to [initialize a workspace](deploy-application#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there.
In the first guide in this series, we introduced a step to [initialize a workspace](1-deploy-application.md#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there.

## Example

@@ -47,7 +47,7 @@ Everything else in `main.k` stay the same.

## Applying

Re-run steps in [Applying](deploy-application#applying), resource scaling is completed.
Re-run steps in [Applying](1-deploy-application.md#applying), resource scaling is completed.

```
$ kusion apply
Original file line number Diff line number Diff line change
@@ -8,13 +8,13 @@ You can set up operational rules in the `AppConfiguration` model with the `opsru

## Prerequisites

Please refer to the [prerequisites](deploy-application#prerequisites) in the guide for deploying an application.
Please refer to the [prerequisites](1-deploy-application.md#prerequisites) in the guide for deploying an application.

The example below also requires you to have [initialized the project](deploy-application#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](deploy-application#kclmod) under the stack directory.
The example below also requires you to have [initialized the project](1-deploy-application.md#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](1-deploy-application.md#kclmod) under the stack directory.

## Managing Workspace Configuration

In the first guide in this series, we introduced a step to [initialize a workspace](deploy-application#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there.
In the first guide in this series, we introduced a step to [initialize a workspace](1-deploy-application.md#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there.

However, if you (or the platform team) would like to set default values for the opsrule to standardize the behavior of applications, you can do so by updating the `~/dev.yaml`.
Note that the platform engineers should set the default workload to [Kusion Operation CollaSet](https://github.com/KusionStack/operating) and installed the Kusion Operation controllers properly, the `opsrules` module will generate a [PodTransitionRule](https://www.kusionstack.io/docs/operating/manuals/podtransitionrule) instead of updating the `maxUnavailable` value in the deployment:
@@ -79,7 +79,7 @@ helloworld: ac.AppConfiguration {

## Applying

Re-run steps in [Applying](deploy-application#applying), resource scaling is completed.
Re-run steps in [Applying](1-deploy-application.md#applying), resource scaling is completed.

## Validation

Original file line number Diff line number Diff line change
@@ -8,13 +8,13 @@ The guides above provide examples on how to configure workloads of the type `ser

## Prerequisites

Please refer to the [prerequisites](deploy-application#prerequisites) in the guide for scheduling a job.
Please refer to the [prerequisites](1-deploy-application.md#prerequisites) in the guide for scheduling a job.

The example below also requires you to have [initialized the project](deploy-application#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](deploy-application#kclmod) under the stack directory.
The example below also requires you to have [initialized the project](1-deploy-application.md#initializing) using the `kusion workspace create` and `kusion init` command, which will create a workspace and also generate a [`kcl.mod` file](1-deploy-application.md#kclmod) under the stack directory.

## Managing Workspace Configuration

In the first guide in this series, we introduced a step to [initialize a workspace](deploy-application#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there. Alternatively, if you have updated your workspace config in the previous guides, no changes need to be made either.
In the first guide in this series, we introduced a step to [initialize a workspace](1-deploy-application.md#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there. Alternatively, if you have updated your workspace config in the previous guides, no changes need to be made either.

However, if you (or the platform team) would like to set default values for the workloads to standardize the behavior of applications in the `dev` workspace, you can do so by updating the `~/dev.yaml`:

@@ -37,7 +37,7 @@ The workspace configuration need to be updated with the command:
kusion workspace update dev -f ~/dev.yaml
```

For a full reference of what can be configured in the workspace level, please see the [workspace reference](../../reference/modules/workspace-configs/workload/job).
For a full reference of what can be configured in the workspace level, please see the [workspace reference](../../../6-reference/2-modules/2-workspace-configs/workload/job.md).

## Example

@@ -86,7 +86,7 @@ You can find the full example in here in the [konfig repo](https://github.com/Ku

## Applying

Re-run steps in [Applying](deploy-application#applying) and schedule the job. Your output might look like one of the following:
Re-run steps in [Applying](1-deploy-application.md#applying) and schedule the job. Your output might look like one of the following:

If you are starting from scratch, all resources are created on the spot:

Original file line number Diff line number Diff line change
@@ -8,21 +8,21 @@ The guides above provide examples on how to configure workloads and accessories

However, in some specific scenario, users may also have the need to directly use Kusion to apply and manage the raw Kubernetes manifest YAML files, such as taking over some existing resources and deploying CRD (CustomResourceDefinition), or other special resources.

To help users directly apply raw K8s manifests, the KusionStack community has provided the [k8s_manifest](../../6-reference/2-modules/1-developer-schemas/k8s_manifest/k8s_manifest.md) Kusion Module.
To help users directly apply raw K8s manifests, the KusionStack community has provided the [k8s_manifest](../../../6-reference/2-modules/1-developer-schemas/k8s_manifest/k8s_manifest.md) Kusion Module.

:::info
The module definition and implementation, as well as the example can be found at [here](https://github.com/KusionStack/catalog/tree/main/modules/k8s_manifest).
:::

## Prerequisites

Please refer to the [prerequisites](deploy-application#prerequisites) in the guide for deploying an application.
Please refer to the [prerequisites](1-deploy-application.md#prerequisites) in the guide for deploying an application.

The example below also requires you to have [initialized the project](deploy-application#initializing) using the `kusion workspace create`, `kusion project create`, `kusion stack create` command, which will create a workspace and project, and also generate a [kcl.mod](deploy-application#kclmod) file under the stack directory.
The example below also requires you to have [initialized the project](1-deploy-application.md#initializing) using the `kusion workspace create`, `kusion project create`, `kusion stack create` command, which will create a workspace and project, and also generate a [kcl.mod](1-deploy-application.md#kclmod) file under the stack directory.

## Managing Workspace Configuration

In the first guide in this series, we introduced a step to [initialize a workspace](deploy-application#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there. Alternatively, if you have updated your workspace config in the previous guides, no changes need to be made either.
In the first guide in this series, we introduced a step to [initialize a workspace](1-deploy-application.md#initializing-workspace-configuration) with an empty configuration. The same empty configuration will still work in this guide, no changes are required there. Alternatively, if you have updated your workspace config in the previous guides, no changes need to be made either.

However, if you (or the platform team) would like to set some default paths for the raw K8s manifest YAML files to standardize the behavior of applications in the `dev` workspace, you can do so by updating the `dev.yaml` with the following config block:

Original file line number Diff line number Diff line change
@@ -25,9 +25,9 @@ If you are not familiar with the relevant concepts, please refer to the links be
:::

## Pre-requisite
Please refer to the [prerequisites](../working-with-k8s/deploy-application#prerequisites) in the guide for deploying an application.
Please refer to the [prerequisites](../2-working-with-k8s/1-deploy-application.md#prerequisites) in the guide for deploying an application.

The example below also requires you to have [initialized the project](../working-with-k8s/deploy-application#initializing) using the `kusion init` command, which will generate a [`kcl.mod` file](../working-with-k8s/deploy-application#kclmod) under the project directory.
The example below also requires you to have [initialized the project](../2-working-with-k8s/1-deploy-application.md#initializing) using the `kusion init` command, which will generate a [`kcl.mod` file](../2-working-with-k8s/1-deploy-application.md#kclmod) under the project directory.

## Setting up your own Prometheus

@@ -137,7 +137,7 @@ If you are running a non-local cluster, you can try to expose it via another way

## Setting up workspace configs

Since v0.10.0, we have introduced the concept of [workspaces](../../3-concepts/4-workspace.md), whose configurations represent the part of the application behaviors that platform teams are interested in standardizing, or the ones to eliminate from developer's mind to make their lives easier.
Since v0.10.0, we have introduced the concept of [workspaces](../../../3-concepts/4-workspace.md), whose configurations represent the part of the application behaviors that platform teams are interested in standardizing, or the ones to eliminate from developer's mind to make their lives easier.

In the case of setting up Prometheus, there are a few things to set up on the workspace level:

@@ -221,7 +221,7 @@ In the example above, a project with the name `helloworld` will have the monitor

You cannot have the same project appear in two projectSelectors.

For a full reference of what can be configured in the workspace level, please see the [workspace reference](../../reference/modules/workspace-configs/monitoring/prometheus).
For a full reference of what can be configured in the workspace level, please see the [workspace reference](../../../6-reference/2-modules/2-workspace-configs/monitoring/prometheus.md).

## Updating the workspace config

Original file line number Diff line number Diff line change
@@ -10,9 +10,9 @@ Kusion provides out-of-the-box support to reference existing external secrets ma

## Prerequisites

Please refer to the [prerequisites](../working-with-k8s/deploy-application#prerequisites) in the guide for deploying an application.
Please refer to the [prerequisites](../2-working-with-k8s/1-deploy-application.md#prerequisites) in the guide for deploying an application.

The example below also requires you to have [initialized the project](../working-with-k8s/deploy-application#initializing) using the `kusion init` command, which will generate a [`kcl.mod` file](../working-with-k8s/deploy-application#kclmod) under the project directory.
The example below also requires you to have [initialized the project](../2-working-with-k8s/1-deploy-application.md#initializing) using the `kusion init` command, which will generate a [`kcl.mod` file](../2-working-with-k8s/1-deploy-application.md#kclmod) under the project directory.

Additionally, you also need to configure the obtained AccessKey and SecretKey as environment variables:

@@ -25,7 +25,7 @@ export AWS_SECRET_ACCESS_KEY="oE/xxxx" # replace it with your SecretKey

## Setting up workspace

Since v0.10.0, we have introduced the concept of [workspaces](../../3-concepts/4-workspace.md), whose configurations represent the part of the application behaviors that platform teams are interested in standardizing, or the ones to eliminate from developer's mind to make their lives easier.
Since v0.10.0, we have introduced the concept of [workspaces](../../../3-concepts/4-workspace.md), whose configurations represent the part of the application behaviors that platform teams are interested in standardizing, or the ones to eliminate from developer's mind to make their lives easier.

In the case of setting up cloud secrets manager, platform teams need to specify which secrets management solution to use and necessary information to access on the workspace level.

Original file line number Diff line number Diff line change
@@ -6,7 +6,7 @@ id: collaborate-with-github-actions

In this article, we will introduce how to use Kusion CLI in combination with GitHub Actions to achieve team collaboration in production practice.

Adopting the concept of separation of concerns, we divide the staff involved in application delivery and operation into two groups: **Platform Engineers (PEs)** and **Developers (Devs)**. As the builders of the Internal Developer Platform (IDP), platform engineers are primarily responsible for creating the [storage backend](../../3-concepts/7-backend.md) for the Kusion CLI in team collaborative scenarios (e.g. AWS S3 or Alicloud OSS), developing custom reusable [Kusion modules](../../3-concepts/3-module/1-overview.md), and creating and maintaining standardized platform configurations in [workspace](../../3-concepts/4-workspace.md). While application developers can focus on writing the application business logic and the configuration codes, self-serving the application delivery and operation by triggering the automated CI/CD pipelines. [GitHub Actions](https://github.com/features/actions) is such a CI/CD platform, and by customizing [GitHub Actions workflow](https://docs.github.com/en/actions/using-workflows), the pipeline such as building, testing, and deploying will be executed automatically.
Adopting the concept of separation of concerns, we divide the staff involved in application delivery and operation into two groups: **Platform Engineers (PEs)** and **Developers (Devs)**. As the builders of the Internal Developer Platform (IDP), platform engineers are primarily responsible for creating the [storage backend](../../../3-concepts/7-backend.md) for the Kusion CLI in team collaborative scenarios (e.g. AWS S3 or Alicloud OSS), developing custom reusable [Kusion modules](../../../3-concepts/3-module/1-overview.md), and creating and maintaining standardized platform configurations in [workspace](../../../3-concepts/4-workspace.md). While application developers can focus on writing the application business logic and the configuration codes, self-serving the application delivery and operation by triggering the automated CI/CD pipelines. [GitHub Actions](https://github.com/features/actions) is such a CI/CD platform, and by customizing [GitHub Actions workflow](https://docs.github.com/en/actions/using-workflows), the pipeline such as building, testing, and deploying will be executed automatically.

In the following sections, we will demonstrate the specific workflow from the perspectives of both PEs and Devs with the sample workflows from our [konfg](https://github.com/KusionStack/konfig) and [catalog](https://github.com/KusionStack/catalog) repository.

@@ -70,7 +70,7 @@ So far, PE has almost completed the fundamental work for setting up the IDP.
### Setup Kusion Storage Backend
In order to get the available modules of the workspace and validate the generated [spec](../../3-concepts/6-spec.md), developers need to communicate with PEs to obtain the AK/SK (usually with **Read-Only** permission), bucket name, and the endpoint to access the remote storage backend. And similar to the PEs, developers can set up the backend configs with the following commands.
In order to get the available modules of the workspace and validate the generated [spec](../../../3-concepts/6-spec.md), developers need to communicate with PEs to obtain the AK/SK (usually with **Read-Only** permission), bucket name, and the endpoint to access the remote storage backend. And similar to the PEs, developers can set up the backend configs with the following commands.
```shell
# please replace the env with actual AK/SK
@@ -84,7 +84,7 @@ kusion config set backends.current oss_test

### Create and Update Project and Stack

Next, developers can create and update the [Project](../../3-concepts/1-project/1-overview.md) and [Stack](../../3-concepts/2-stack/1-overview.md) configurations with `kusion project` and `kusion stack` command.
Next, developers can create and update the [Project](../../../3-concepts/1-project/1-overview.md) and [Stack](../../../3-concepts/2-stack/1-overview.md) configurations with `kusion project` and `kusion stack` command.

```shell
# create a new project named quickstart
Original file line number Diff line number Diff line change
@@ -123,7 +123,7 @@ As for how the AI application use the LLM service provided by the `inference` mo

Which model used in the application is transparent, and you only need to provide the `prompt` parameter to the request address. Of course, you can directly modify the model and other configuration items in the `main.k` file and update the deployment resources by `kusion apply`.

There are also some optional configuration items in the `inference` module for adjusting the LLM service, whose details can be found [here](../../6-reference/2-modules/1-developer-schemas/inference/inference.md).
There are also some optional configuration items in the `inference` module for adjusting the LLM service, whose details can be found [here](../../../6-reference/2-modules/1-developer-schemas/inference/inference.md).

## Deployment

3 changes: 3 additions & 0 deletions docs/kusion/5-user-guides/1-using-kusion-cli/_category_.json
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
{
"label": "Using Kusion CLI"
}
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
{
"label": "Cloud Resources"
}
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
{
"label": "Kubernetes"
}
Original file line number Diff line number Diff line change
@@ -0,0 +1,3 @@
{
"label": "Using Kusion Server"
}