kcl-lang · Peefy · Oct 8, 2023 · Oct 8, 2023
diff --git a/docs/user_docs/guides/working-with-konfig/1-overview.md b/docs/user_docs/guides/working-with-konfig/1-overview.md
@@ -2,6 +2,7 @@
 id: overview
 sidebar_label: Overview
 ---
+
 # Konfig Overview
 
 In KCL, it is recommended to uniformly manage all configurations and model libraries in the way of **configuration library**, that is, to store not only KCL definitions of the abstract model itself, but also various types of configurations, such as application operation and maintenance configuration, policy, etc. The configuration is recommended to be hosted in various VCS systems to facilitate configuration rollback and drift check. The best practice code of the configuration repository is Konfig, and the repository is hosted in [Github](https://github.com/kcl-lang/konfig)。

diff --git a/docs/user_docs/guides/working-with-konfig/2-structure.md b/docs/user_docs/guides/working-with-konfig/2-structure.md
@@ -2,42 +2,17 @@
 id: structure
 sidebar_label: Structure
 ---
+
 # Konfig Structure
 
 This article mainly explains the directory and code structure of the Konfig repository.
 
-## Overview
-
-```bash
-.
-├── .github             # CI Scripts
-├── Makefile            # Building and testing scripts
-├── README.md           # Documents
-├── appops              # Application configuration. This folder is used to place KCL operation and maintenance configuration of all applications
-│   ├── clickhouse-operator
-│   ├── code-city
-│   ├── guestbook
-│   ├── http-echo
-│   └── nginx-example
-├── base                # Models
-│   ├── examples        # Examples
-│   │   ├── monitoring  # Monitoring example
-│   │   ├── native      # Kubernetes resource example
-│   │   ├── provider    # Basic resource configuration example such as Terraform resource
-│   │   └── server      # Server example.
-│   └── pkg
-│       ├── kusion_kubernetes   # Kubernetes domain models
-│       ├── kusion_models       # Core models
-│       ├── kusion_prometheus   # Prometheus domain models
-│       └── kusion_provider     # Basic resource models such as Terraform resource
-└── kcl.mod             # The KCL module declaration file
-```
-
 ## Core Model
 
-The core model library is generally named `kusion_models`, mainly including front-end model, back-end model, renderer, etc. The directory structure is:
+The core model library is generally named `models`, mainly including front-end model, back-end model, renderer, etc. The directory structure is:
 
 ```bash
+models
 ├── commons         # Common models
 ├── kube            # Cloud-native resource core models
 │   ├── backend         # Back-end models
@@ -60,38 +35,3 @@ The core model library is generally named `kusion_models`, mainly including fron
 │   └── utils
 └── metadata        # Common metadata
 ```
-
-## Project and Stack
-
-![](/img/docs/user_docs/concepts/project-stack.png)
-
-Project and Stack are logical isolation concepts used to organize the Konfig.
-
-### Project
-
-Any folder that contains the file `project.yaml` will be regarded as a Project, and the `project.yaml` is used to describe the metadata of this Project like `name` and `tenant`. Projects must have clear business semantics and must belong to a tenant. Users can map an application or an operation scenario to a Project.
-
-### Stack
-
-Like Project, any folder that contains the file `stack.yaml` will be regarded as a Stack and `stack.yaml` is used to describe the metadata of this Stack. Stack is a set of `.k` files that represents the smallest operation unit that can be configured and deployed individually. It tends to represent different stages in the CI/CD process, such as dev, gray, prod, etc.
-
-### Relationship between Project and Stack
-
-A Project contains one or more Stacks, and a Stack must belong to and can only belong to one Project. Users can interpret the meaning of Project and Stack according to their own needs and flexibly organize the Konfig structure. We provide the following example as a best practice according to our experiences:
-
-```bash
-appops/nginx-example
-├── README.md       # Project readme
-├── base            # common configurations for all stacks
-│   └── base.k      
-├── dev             # dev stack 
-│   ├── ci-test     # CI test configs
-│   │   ├── settings.yaml       # test data 
-│   │   └── stdout.golden.yaml  # expected test result
-│   ├── kcl.yaml    # kcl config
-│   ├── main.k      
-│   └── stack.yaml  # Stack metadata
-└── project.yaml    # Project metadata
-```
-
-The Project represents an application and Stack represents different environments of this application, such as dev, pre, prod, etc. Common configurations can be stored in a `base` directory under this Project.
diff --git a/docs/user_docs/guides/working-with-konfig/3-quick-start.md b/docs/user_docs/guides/working-with-konfig/3-quick-start.md
@@ -23,7 +23,7 @@ This guide requires you to have a basic understanding of Kubernetes. If you are
 
 Before we start, we need to complete the following steps:
 
-1. Install KCL - See [Download and Install](/docs/user_docs/getting-started/install) for more details.
+1. Install [kpm](https://kcl-lang.io/docs/user_docs/guides/package-management/installation)
 
 2. Clone the [Konfig repo](https://github.com/kcl-lang/konfig.git)
 
@@ -37,10 +37,10 @@ git clone https://github.com/kcl-lang/konfig.git && cd konfig
 
 The programming language of the project is KCL, not JSON/YAML which Kubernetes recognizes, so it needs to be compiled to get the final output.
 
-Enter stack dir `appops/nginx-example/dev` and compile:
+Enter stack dir `examples/appops/nginx-example/dev` and compile:
 
 ```bash
-cd appops/nginx-example/dev && kcl
+cd appops/nginx-example/dev && kpm run
 ```
 
 The output YAML is:
@@ -49,23 +49,23 @@ The output YAML is:
 apiVersion: apps/v1
 kind: Deployment
 metadata:
-  name: nginx-exampledev
-  namespace: nginx-example
+  name: sampleappprod
+  namespace: sampleapp
 spec:
   replicas: 1
   selector:
     matchLabels:
-      app.kubernetes.io/name: nginx-example
-      app.kubernetes.io/env: dev
-      app.kubernetes.io/instance: nginx-example-dev
-      app.kubernetes.io/component: nginx-exampledev
+      app.kubernetes.io/name: sampleapp
+      app.kubernetes.io/env: prod
+      app.kubernetes.io/instance: sampleapp-prod
+      app.k8s.io/component: sampleappprod
   template:
     metadata:
       labels:
-        app.kubernetes.io/name: nginx-example
-        app.kubernetes.io/env: dev
-        app.kubernetes.io/instance: nginx-example-dev
-        app.kubernetes.io/component: nginx-exampledev
+        app.kubernetes.io/name: sampleapp
+        app.kubernetes.io/env: prod
+        app.kubernetes.io/instance: sampleapp-prod
+        app.k8s.io/component: sampleappprod
     spec:
       containers:
       - image: nginx:1.7.8
@@ -86,23 +86,23 @@ spec:
 apiVersion: v1
 kind: Namespace
 metadata:
-  name: nginx-example
+  name: sampleapp
 ---
 apiVersion: v1
 kind: Service
 metadata:
-  name: nginx-example
-  namespace: nginx-example
+  name: nginx
+  namespace: sampleapp
 spec:
   ports:
   - nodePort: 30201
     port: 80
     targetPort: 80
   selector:
-    app.kubernetes.io/name: nginx-example
-    app.kubernetes.io/env: dev
-    app.kubernetes.io/instance: nginx-example-dev
-    app.kubernetes.io/component: nginx-exampledev
+    app.kubernetes.io/name: sampleapp
+    app.kubernetes.io/env: prod
+    app.kubernetes.io/instance: sampleapp-prod
+    app.k8s.io/component: sampleappprod
   type: NodePort
 ```
 
@@ -112,8 +112,6 @@ After compiling, we can see three resources:
 - A `Namespace` with the name `nginx-example`
 - A `Service` with the name `nginx-example`
 
-The above completes the configuration and takes effect. Later, we can use the command `kubectl apply` to apply and check the actual status of resources. This guide will not elaborate.
-
 ### 2. Modification
 
 The `image` attribute in the `Server` model is used to declare the application's container image. We can modify the `image` value in `base/main.k` to modify or upgrade the image:

diff --git a/...plugin-content-docs/current/user_docs/guides/working-with-konfig/2-structure.md b/...plugin-content-docs/current/user_docs/guides/working-with-konfig/2-structure.md
@@ -2,42 +2,17 @@
 id: structure
 sidebar_label: 工程结构
 ---
-# Konfig 工程结构
-
-本文主要解释 Konfig 配置大库的目录和代码结构
 
-## 整体结构
+# Konfig 工程结构
 
-```bash
-.
-├── .github             # CI 脚本
-├── Makefile            # 通过 Makefile 封装常用命令
-├── README.md           # 配置大库说明
-├── appops              # 应用运维目录，用来放置所有应用的 KCL 运维配置
-│   ├── clickhouse-operator
-│   ├── code-city
-│   ├── guestbook
-│   ├── http-echo
-│   └── nginx-example
-├── base                # 模型库
-│   ├── examples        # 样例代码
-│   │   ├── monitoring  # 监控配置样例
-│   │   ├── native      # Kubernetes 资源配置样例
-│   │   ├── provider    # 基础资源配置样例
-│   │   └── server      # 云原生应用运维配置模型样例
-│   └── pkg
-│       ├── kusion_kubernetes   # Kubernetes 底层模型库
-│       ├── kusion_models       # 核心模型库
-│       ├── kusion_prometheus   # Prometheus 底层模型库
-│       └── kusion_provider     # 基础资源 底层模型库
-└── kcl.mod             # 大库配置文件，通常用来标识大库根目录位置以及大库所需依赖
-```
+本文主要解释 Konfig 配置库的目录和代码结构
 
 ## 核心模型库结构
 
-核心模型库一般命名为 kusion_models，主要包含前端模型、后端模型、Mixin、渲染器等，目录结构为：
+核心模型库命名为 `models`，主要包含前端模型、后端模型、Mixin、渲染器等，目录结构为：
 
 ```bash
+models
 ├── commons         # 基础资源核心模型库
 ├── kube            # 云原生资源核心模型库
 │   ├── backend         # 后端模型
@@ -60,37 +35,3 @@ sidebar_label: 工程结构
 │   └── utils           # 工具方法
 └── metadata        # 通用元数据模型
 ```
-
-## Project 和 Stack 结构
-
-![](/img/docs/user_docs/concepts/project-stack.png)
-
-Project 和 Stack 是用于组织 Konfig 的逻辑隔离概念。
-
-### Project
-
-任何包含文件 "project.yaml" 的文件夹都将被视为一个 Project，"project.yaml" 用于描述此 Project 的元数据，如 "name" 和 "tenant" 等。项目必须具有明确的业务语义，用户可以将应用程序或运维场景映射到项目。
-
-### Stack
-
-与Project一样，包含文件 "stack.yaml" 的任何文件夹都将被视为一个 Stack，"stack.yaml" 用于描述此 Stack 的元数据。Stack 是一组 KCL 文件，表示可以单独配置和部署的最小操作单元，它通常代表 CI/CD 过程中的不同阶段。
-
-### Project 与 Stack 之间的关系
-
-一个 Project 包含一个或多个 Stack，Stack 必须属于且只能属于一个 Project。用户可以根据自己的需要解释 Project 和 Stack 的含义，并灵活组织 Konfig 结构。根据我们的经验，我们提供以下示例作为最佳实践：
-
-```bash
-├── README.md       # Project 介绍文件
-├── base            # 各环境通用配置
-│   └── base.k      # 通用 KCL 配置
-├── dev             # 环境特有配置
-│   ├── ci-test     # 测试目录
-│   │   ├── settings.yaml       # 测试数据
-│   │   └── stdout.golden.yaml  # 测试期望结果
-│   ├── kcl.yaml    # 多文件编译配置，是 KCL 编译的入口
-│   ├── main.k      # 当前环境 KCL 配置
-│   └── stack.yaml  # Stack 配置文件
-└── project.yaml    # Project 配置文件
-```
-
-Project 通常表示一个应用程序，Stack 表示该应用程序的不同环境的配置，例如 dev、pre 和 prod 等。通用配置可以存储在该 Project 下的 "base" 目录中。
diff --git a/...ugin-content-docs/current/user_docs/guides/working-with-konfig/3-quick-start.md b/...ugin-content-docs/current/user_docs/guides/working-with-konfig/3-quick-start.md
@@ -23,9 +23,9 @@ sidebar_label: 快速开始
 
 在开始之前，我们需要做以下准备工作：
 
-1. 安装 KCL, 详情信息请参阅[下载和安装](/docs/user_docs/getting-started/install)。
+1. 安装 [kpm](https://kcl-lang.io/docs/user_docs/guides/package-management/installation)
 
-2. 下载开源 Konfig 大库，仓库地址: [https://github.com/kcl-lang/konfig.git](https://github.com/kcl-lang/konfig.git)
+2. 下载开源 Konfig 库，仓库地址: [https://github.com/kcl-lang/konfig.git](https://github.com/kcl-lang/konfig.git)
 
 ```shell
 git clone https://github.com/kcl-lang/konfig.git && cd konfig
@@ -37,10 +37,10 @@ git clone https://github.com/kcl-lang/konfig.git && cd konfig
 
 Konfig 的编程语言是 KCL，不是 Kubernetes 认识的 JSON/YAML，因此还需要编译得到最终输出。
 
-进入到项目的 Stack 目录（`appops/nginx-example/dev`）并执行编译：
+进入到项目的 Stack 目录（`examples/appops/nginx-example/dev`）并执行编译：
 
 ```bash
-cd appops/nginx-example/dev && kcl
+cd examples/appops/nginx-example/dev && kpm run
 ```
 
 可以获得如下 YAML 输出:
@@ -49,23 +49,23 @@ cd appops/nginx-example/dev && kcl
 apiVersion: apps/v1
 kind: Deployment
 metadata:
-  name: nginx-exampledev
-  namespace: nginx-example
+  name: sampleappprod
+  namespace: sampleapp
 spec:
   replicas: 1
   selector:
     matchLabels:
-      app.kubernetes.io/name: nginx-example
-      app.kubernetes.io/env: dev
-      app.kubernetes.io/instance: nginx-example-dev
-      app.kubernetes.io/component: nginx-exampledev
+      app.kubernetes.io/name: sampleapp
+      app.kubernetes.io/env: prod
+      app.kubernetes.io/instance: sampleapp-prod
+      app.k8s.io/component: sampleappprod
   template:
     metadata:
       labels:
-        app.kubernetes.io/name: nginx-example
-        app.kubernetes.io/env: dev
-        app.kubernetes.io/instance: nginx-example-dev
-        app.kubernetes.io/component: nginx-exampledev
+        app.kubernetes.io/name: sampleapp
+        app.kubernetes.io/env: prod
+        app.kubernetes.io/instance: sampleapp-prod
+        app.k8s.io/component: sampleappprod
     spec:
       containers:
       - image: nginx:1.7.8
@@ -86,23 +86,23 @@ spec:
 apiVersion: v1
 kind: Namespace
 metadata:
-  name: nginx-example
+  name: sampleapp
 ---
 apiVersion: v1
 kind: Service
 metadata:
-  name: nginx-example
-  namespace: nginx-example
+  name: nginx
+  namespace: sampleapp
 spec:
   ports:
   - nodePort: 30201
     port: 80
     targetPort: 80
   selector:
-    app.kubernetes.io/name: nginx-example
-    app.kubernetes.io/env: dev
-    app.kubernetes.io/instance: nginx-example-dev
-    app.kubernetes.io/component: nginx-exampledev
+    app.kubernetes.io/name: sampleapp
+    app.kubernetes.io/env: prod
+    app.kubernetes.io/instance: sampleapp-prod
+    app.k8s.io/component: sampleappprod
   type: NodePort
 ```
 
@@ -112,8 +112,6 @@ spec:
 - 一个 name 为 nginx-example 的 Namespace
 - 一个 name 为 nginx-example 的 Service
 
-以上就完成了配置生效，后续可以使用 `kubectl apply` 等命令下发并检查资源的实际状态，本文不在赘述。
-
 ### 2. 配置修改
 
 Server 模型中的 image 属性用于声明应用的业务容器镜像，我们可以修改 base/main.k 中的 image 的值进行镜像修改或升级:
@@ -194,4 +192,4 @@ spec:
 
 ## 小结
 
-本文主要介绍了如何使用 KCL 语言与其相对应的 Konfig 库，完成一个运行在 Kubernetes 中的 Long-Running 应用的部署。
+本文主要介绍了如何使用 KCL 语言与其相对应的 Konfig 库，完成一个运行在 Kubernetes 中的 Long-Running 服务应用的部署。