update blog & cli folder docs for MDX3 (#1315)

Signed-off-by: Arhell <arhell333@gmail.com>

blog/2022-03-01-kubevela-generate-top-50-popular-resources-of-aws-using-100-lines-of-code.md

@@ -287,9 +287,9 @@ vela def init {ModuleName} --type component --provider {providerName} --git {git
 
 Several items to be filled in the instruction are passed in from the parsed Module structure.
 
-* gitURL: 	{Module.Attributes.Source}.git
+* gitURL: 	\{Module.Attributes.Source\}.git
 * description: If there are elements in `Included` which have the same ID with relationship.latest-version.ID, set the description as the corresponding description in `Included` elements, otherwise set the description as providerName+ModuleName. 
-* yamlFileName：terraform-{providerName}-{Module.Attributes.Name}.yaml
+* yamlFileName：terraform-\{providerName\}-\{Module.Attributes.Name\}.yaml
 
 
 

blog/2022-05-30-abstraction-kubevela.md

@@ -20,10 +20,13 @@ Let's start the journey by using the [Kubernetes StatefulSet](https://kubernetes
 
 Save the YAML example of StatefulSet in the official document locally and name it as `my-stateful.yaml`, then execute command as below:
 
+```
 	 vela def init my-stateful -t component --desc "My StatefulSet component." --template-yaml ./my-stateful.yaml -o my-stateful.cue
+```
 
 View the generated "my-stateful.cue" file:
 
+```
 	$ cat my-stateful.cue
 	"my-stateful": {
 		annotations: {}
@@ -50,6 +53,8 @@ View the generated "my-stateful.cue" file:
 		parameter: {}
 	}
 
+```
+
 Modify the generated file as follows:
 
 1. The example of the official StatefulSet website is a composite component composed of two objects `StatefulSet` and `Service`. According to KubeVela [Rules for customize component](https://kubevela.io/docs/platform-engineers/components/custom-component), in composite components, one of the resources such (StatefulSet in our example) need to be represented by the `template.output` field as a core workload, and other auxiliary objects are represented by `template.outputs`, so we make some adjustments and all the automatically generated output and outputs are switched.
@@ -57,11 +62,14 @@ Modify the generated file as follows:
 
 After modification, you can use `vela def vet` to do format check and verification.
 
+```
 	$ vela def vet my-stateful.cue
 	Validation succeed.
+```
 
 The file after two steps of changes is as follows:
 
+```
 	$ cat my-stateful.cue
 	"my-stateful": {
 		annotations: {}
@@ -129,22 +137,28 @@ The file after two steps of changes is as follows:
 		}
 		parameter: {}
 	}
+```
 
 Install ComponentDefinition into the Kubernetes cluster:
 
+```
 	$ vela def apply my-stateful.cue
 	ComponentDefinition my-stateful created in namespace vela-system.
+```
 
 You can see that a `my-stateful` component  via `vela components` command:
 
+```
 	$ vela components
 	NAME       	NAMESPACE  	WORKLOAD                             	DESCRIPTION
 	...
 	my-stateful	vela-system	statefulsets.apps                    	My StatefulSet component.
 	... 
+```
 
 When you put this customized component into `Application`, it looks like:
 
+```
 	cat <<EOF | vela up -f -
 	apiVersion: core.oam.dev/v1beta1
 	kind: Application
@@ -155,7 +169,7 @@ When you put this customized component into `Application`, it looks like:
 	    - name: my-component
 	      type: my-stateful
 	EOF
-
+```
 
 
 ## Define Customized Parameters For Component
@@ -167,7 +181,7 @@ In this example, we expose the following parameters to the user:
 * Image name, allowing users to customize the image
 * Instance name, allowing users to customize the instance name of the generated StatefulSet object and Service object
 
-
+```
 		... # Omit other unmodified fields
 		template: {
 			output: {
@@ -207,11 +221,14 @@ In this example, we expose the following parameters to the user:
 				name: string
 			}
 		}
+```
 
 After modification, use `vela def apply` to install to the cluster:
 
+```
 	$ vela def apply my-stateful.cue
 	ComponentDefinition my-stateful in namespace vela-system updated.
+```
 
 Then as a platform builder, you have finished your setup. Let's see what's the developer experience now.
 
@@ -230,6 +247,7 @@ my-stateful                     ComponentDefinition     vela-system My StatefulS
 ...snip...
 ```
 
+```
 	$ vela show my-stateful
 	# Properties
 	+----------+-------------+--------+----------+---------+
@@ -238,6 +256,7 @@ my-stateful                     ComponentDefinition     vela-system My StatefulS
 	| name     |             | string | true     |         |
 	| image    |             | string | true     |         |
 	+----------+-------------+--------+----------+---------+
+```
 
 Updating the ComponentDefinition will not affect existing Applications. It will take effect only after updating the Applications next time.
 
@@ -362,7 +381,7 @@ In our example above, the field `name` in the properties and the field `name` of
 
 Just modify the definition file (my-stateful.cue) as the following 
 
-
+```
 	... # Omit other unmodified fields
 	template: {
 		output: {
@@ -379,6 +398,7 @@ Just modify the definition file (my-stateful.cue) as the following
 			image: string
 		}
 	}
+```
 
 Then deploy the changes by the following:
 
@@ -419,6 +439,7 @@ The customized process works the same with the component, they both use CUE but
 
 There're already some built-in traits after KubeVela installed. The operator can use `vela traits` to view, the traits marked with `*` are general traits, which can operate on common Kubernetes resource objects.
 
+```
 	$ vela traits
 	NAME                    	NAMESPACE  	APPLIES-TO      	CONFLICTS-WITH	POD-DISRUPTIVE	DESCRIPTION
 	annotations             	vela-system	*               	              	true          	Add annotations on K8s pod for your workload which follows
@@ -432,9 +453,11 @@ There're already some built-in traits after KubeVela installed. The operator can
 	sidecar                 	vela-system	*               	              	true          	Inject a sidecar container to K8s pod for your workload
 	                        	           	                	              	              	which follows the pod spec in path 'spec.template'.
 	...snip...
+```
 
 Taking sidecar as an example, you can check the usage of sidecar:
 
+```
 	$ vela show sidecar
 	# Properties
 	+---------+-----------------------------------------+-----------------------+----------+---------+
@@ -454,9 +477,11 @@ Taking sidecar as an example, you can check the usage of sidecar:
 	| path |             | string | true     |         |
 	| name |             | string | true     |         |
 	+------+-------------+--------+----------+---------+
+```
 
 Use the sidecar directly to inject a container, the application description is as follows:
 
+```
 	apiVersion: core.oam.dev/v1beta1
 	kind: Application
 	metadata:
@@ -473,6 +498,7 @@ Use the sidecar directly to inject a container, the application description is a
 	        properties:
 	          name: my-sidecar
 	          image: saravak/fluentd:elastic
+```
 
 Deploy and run the application, and you can see that a fluentd sidecar has been deployed and running in the StatefulSet.
 

docs/cli/vela_addon_push.md

@@ -8,13 +8,13 @@ uploads an addon package to ChartMuseum
 
 Uploads an addon package to ChartMuseum.
 
-Two arguments are needed <addon directory/package> and <name/URL of ChartMuseum>.
+Two arguments are needed \<addon directory/package\> and \<name/URL of ChartMuseum\>.
 
-The first argument <addon directory/package> can be:
+The first argument \<addon directory/package\> can be:
 	- your conventional addon directory (containing metadata.yaml). We will package it for you.
 	- packaged addon (.tgz) generated by 'vela addon package' command
 
-The second argument <name/URL of ChartMuseum> can be:
+The second argument \<name/URL of ChartMuseum\> can be:
 	- registry name (helm type). You can add your ChartMuseum registry using 'vela addon registry add'.
 	- ChartMuseum URL, e.g. http://localhost:8080
 

docs/cli/vela_completion_bash.md

@@ -9,7 +9,7 @@ generate autocompletions script for bash
 Generate the autocompletion script for Vela for the bash shell.
 
 To load completions in your current shell session:
-$ source <(vela completion bash)
+$ source \<(vela completion bash)
 
 To load completions for every new session, execute once:
 Linux:

docs/cli/vela_completion_zsh.md

@@ -9,10 +9,10 @@ generate autocompletions script for zsh
 Generate the autocompletion script for Vela for the zsh shell.
 
 To load completions in your current shell session:
-$ source <(vela completion zsh)
+$ source \<(vela completion zsh)
 
 To load completions for every new session, execute once:
-$ vela completion zsh > "${fpath[1]}/_vela"
+$ vela completion zsh > "$\{fpath[1]\}/_vela"
 
 
 ```

docs/cli/vela_ql.md

@@ -7,7 +7,7 @@ Show result of executing velaQL.
 ### Synopsis
 
 Show result of executing velaQL, use it like:
-		vela ql --query "inner-view-name{param1=value1,param2=value2}"
+		vela ql --query "inner-view-name\{param1=value1,param2=value2\}"
 		vela ql --file ./ql.cue
 
 ```

docs/cli/vela_uischema.md

@@ -24,7 +24,7 @@ Manage UI schema for addons.
 ### SEE ALSO
 
 
-* [vela uischema apply](vela_uischema_apply.md)	 - apply <ui schema file/dir path>
+* [vela uischema apply](vela_uischema_apply.md)	 - apply \<ui schema file/dir path\>
 
 #### Go Back to [CLI Commands](vela.md) Homepage.
 

docs/cli/vela_uischema_apply.md

@@ -2,7 +2,7 @@
 title: vela uischema apply
 ---
 
-apply <ui schema file/dir path>
+apply \<ui schema file/dir path\>
 
 ### Synopsis