:Rules for using different configurations to deploy an application across multiple clusters

Rule 1: Change the number of replicated pods created by a Deployment

Use the following YAML template to change the number of replicated pods to five for the Deployment that you want to deploy in the managedcluster-cd**** cluster.

Example

apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
  name: cluster-beijing
  namespace: demo
type: topology
properties:
  # Specify the cluster to which you want to deploy the application. 
  clusters: ["managedcluster-cd****"]
---
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
  name: override-replic-beijing
  namespace: demo
# Specify the configuration that is used to override the base configuration. 
type: override
properties:
  components:
  # Reference the component that is defined in the Application object by specifying the name of the component. Then, you can specify the Kubernetes resources that you want to override in the component. 
  - name: "demo"
    # Specify the type of configuration that you want to override. In this example, set the type to scaler and change the number of replicated pods created by the Deployment to five. 
    traits:
    - type: scaler
      properties:
        replicas: 5
---
apiVersion: core.oam.dev/v1alpha1
kind: Workflow
metadata:
  name: deploy-demo
  namespace: demo
steps:
  - type: deploy
    name: deploy-beijing
    properties:
      # Specify the override configuration and the cluster to which the override configuration is applied in the workflow. 
      policies: ["override-replic-beijing", "cluster-beijing"]
---
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  annotations:
    app.oam.dev/publishVersion: version1
  name: demo
  namespace: demo
spec:
  # Define a component. 
  components:
    - name: demo
      type: ref-objects
      properties:
        objects:
          - apiVersion: apps/v1
            kind: Deployment
            name: demo
  # Specify the workflow that is used to deploy the Kubernetes object with the override configuration. 
  workflow:
    ref: deploy-demo

How to override configurations

To change the number of replicated pods created by the Deployment, you must specify the following information:

• components: Define a component in the Application object, reference the component, and specify the Kubernetes objects that you want to override in the component.

  Note

  The override configuration applies only to the first Kubernetes object that you specified in the component.

• traits: Specify the configuration that is used to override the base configuration by using ACK One. This parameter helps simplify the procedure for overriding configurations. In this example, the type is set to scaler to change the number of replicated pods created by the Deployment.

  Parameter	Description
  traits. type: scaler	The type parameter in the traits section specifies the type of configuration that you want to override.
  traits. properties. replicas	This parameter specifies the number of replicated pods created by a Deployment.

• Destination cluster: In the steps parameter of the Workflow object, specify the Policy object that contains the override configuration and the Policy object that contains the destination cluster. This way, you can use the workflow to deploy the Kubernetes object with the override configuration to the destination cluster.

Rule 2: Change the container image of a Deployment

Use the following YAML template to change the container image of a Deployment.

Example

apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
  name: override-image-beijing
  namespace: demo
type: override
properties:
  components:
  - name: "demo"
    # Specify the type of configuration that you want to override. In this example, set the type to container-image and change the container image of a Deployment. 
    traits:
    - type: container-image
      properties:
        containerName: demo
        image: registry.cn-hangzhou.aliyuncs.com/acs/rollouts-demo:green
        imagePullPolicy: Always

Parameter description

Rule 3: Modify the command of a container in a Deployment

Use the following YAML template to modify the command of a container in a Deployment.

Example

apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
  name: override-command
  namespace: demo
type: override
properties:
  components:
  - name: "demo"
    # Specify the type of configuration that you want to override. In this example, set the type to command and modify the command of a container in a Deployment. 
    traits:
    - type: command
      properties:
        containerName: demo
        # Override the command parameter in the container. 
        command: ["demo-command", "demo-parameter1", "demo-parameter2"]
        # Override the args parameter in the container. 
        args: ["demo-parameter1", "demo-parameter2"]
        # Add arguments. 
        addArgs: ["new-parameter1"]
        # Delete arguments. 
        delArgs: ["parameter1-to-delete"]

Parameter description

Rule 4: Modify the environment variables of a container in a Deployment

Use the following YAML template to modify the environment variables of a container in a Deployment.

Example

apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
  name: override-command
  namespace: demo
type: override
properties:
  components:
  - name: "demo"
    # Specify the type of configuration that you want to override. In this example, set the type to env and modify the environment variables of a container in a Deployment. 
    traits:
    - type: env
      properties:
        containerName: demo
        # Add new environment variables. If you add an environment variable whose name is the same as the name of an existing environment variable, the value of the existing environment variable is overridden. 
        env:
          key_first: value_first
          key_second: value_second
        # Delete environment variables from the env parameter of a container. 
        unset: ["ENV1"]

Parameter description

Rule 5: Modify resource parameters by using JSON Patch

Use the following YAML template to modify resource parameters by using JSON Patch.

Example

apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
  name: override-json-path
  namespace: demo
type: override
properties:
  components:
  - name: "demo"
    # Specify the type of configuration that you want to override. In this example, set the type to json-patch and modify the parameters of the resource by using JSON Patch. 
    traits:
    - type: json-patch
      properties:
        operations:
          # The op: add operation allows you to add a parameter to the resource. In this example, a label is added. 
          - op: add
            path: "/metadata/labels/label-to-add-key"
            value: label-to-add-key-value
          # The op: replace operation allows you to change the value of a parameter of the resource. In this example, the value of an existing label is changed. 
          - op: replace
            path: "/metadata/labels/label-to-replace-key"
            value: label-modified-value
          # The op: remove operation allows you to delete a parameter from the resource. In this example, an existing label is deleted. 
          - op: remove
            path: "/metadata/labels/label-to-remove-key"

Parameter description

Rule 6: Modify resource parameters by using JSON Merge

If you use JSON Patch to modify resource parameters, you must specify the value of each parameter that you want to modify. This operation is time-consuming and complex when you need to modify a large number of resource parameters. In this case, you can use JSON Merge to simplify the configuration.

Use the following YAML template to modify resource parameters in the ConfigMaps of different clusters by using JSON Patch.

Example

#Create a ConfigMap on the Fleet instance. 
apiVersion: v1
kind: ConfigMap
metadata:
  name: demo
  namespace: demo
data:
  confg-not-override: "not-override"
  confg-to-override: "value"
  config-file-to-override: |
    {
      "feature-parameters": {
        "key1": "value1",
        "key2": "value2",
      }
    }
  config-to-delete: "to-delete"

---
#Create an override policy. 
apiVersion: core.oam.dev/v1alpha1
kind: Policy
metadata:
  name: override-configmap
  namespace: demo
type: override
properties:
  components:
  - name: "demo"
    #Specify the type of configuration that you want to override. In this example, set the type to json-merge-patch. json-merge-patch allows you to modify resources by defining resource objects in properties and merging the defined resource objects with the base resource objects. 
    traits:
    - type: json-merge-patch
      properties:
        #The first level of the resource that you want to modify. 
        data:
          #Modify the value of confg-to-override. 
          confg-to-override: "value-override"
          #Add config-to-add. 
          config-to-add: "to-add"
          #Modify the content of config-file-to-override. 
          config-file-to-override: |
            {
              "feature-parameters": {
                "key1": "value1-override",
                "key2": "value2-override",
              }
            }
          #Delete config-to-delete. 
          config-to-delete: null

---
#The modified resource. 
apiVersion: v1
kind: ConfigMap
metadata:
  name: demo
  namespace: demo
data:
  #confg-not-override remains unchanged. 
  confg-not-override: "not-override"
  confg-to-override: "value-override"
  config-file-to-override: |
    {
      "feature-parameters": {
        "key1": "value1-override",
        "key2": "value2-override",
      }
    }

Parameter description