Templates (Cloud-Based Automation Scripts)
Application Orchestration Service (AOS) templates are text files in YAML or JSON format. They describe the cloud objects that you want, including applications, resources, and services. AOS creates various cloud objects automatically from AOS templates.
Each automated process requires a descriptive language to control its execution flow. For example, a shell script (text file) describes how to automatically run commands. Similarly, an AOS template describes the process of creating and deleting cloud objects.
The following is an example execution logic of a shell script:
A shell script has the following features:
- A script is a text file.
- If a script is properly written, it can be reused.
An AOS template has the same execution logic as a shell script. The AOS service functions as the interpreter of AOS templates and executes actions according to templates. An AOS template can be considered as cloud automation standards.
A good shell script or function should have inputs, execution logic, and returned values. Likewise, a good template also should have Inputs, Orchestration, and Outputs. A good template eases knowledge transfer and sharing.
Elements (Cloud Objects)
Cloud objects can be cloud resources, services, or applications. Cloud resources are the most common cloud objects. AOS treats cloud objects as elements. A template is a collection of elements.
- Cloud resources: include the Elastic Cloud Server (ECS), Elastic Volume Service (EVS), Virtual Private Cloud (VPC), and Elastic IP (EIP).
- Cloud services: include the Distributed Cache Service (DCS) and Distributed Message Service (DMS).
- Cloud applications: include containerized applications on Cloud Container Engine (CCE) and microservices on Cloud Service Engine (CSE).
You need to set inputs to create any cloud object. After a cloud object is created, a result is displayed. The following figure uses an ECS (VM) as an example.
Inputs (Properties)
Inputs, also called parameters, are conditions for creating a cloud object. The parameters required by a cloud object are determined by the characteristics of the object. Some objects require many parameters, for example, VMs. Some objects can be created with a few parameters or without parameters, for example, Object Storage Service (OBS) buckets. Some input parameters are complex and consist of multiple basic parameters, for example, network attributes of VMs.
The syntax is as follows:
Cloud object (element): description: description of the cloud object properties: # Parameters of the cloud object Property 1: # Parameter 1 Property 2: # Parameter 2 Property...: # Parameter...
Orchestration (Elements)
If elements are initialized just one by one according to the order in which they are arranged, no orchestration is required. AOS supports orchestration of elements with complex dependencies between them. The initialization (input) of an element depends on the result (output) of another element. Such a relationship can be specified by using an AOS template.
In an AOS template, you can specify the output of any element as the input of another element. The initialization process can be controlled freely, which is called orchestration. Only orchestration can meet various automation requirements.
An AOS template is the collection of objects that you want to orchestrate. To be more specific, an AOS template is a collection of objects that you want to control during the initialization process.
The relationship between elements is classified into two types: dependency and inclusion.
- Dependency relationship: The input of an element depends on the output of another element. If element A depends on element B, element A can be created only after element B is successfully created.
- Inclusion relationship: An element is a part of another element. If element A contains element B, element B can be created only after element A is successfully created.
Outputs (Return Values)
Outputs are the results returned after a cloud object is successfully created. The returned results of a cloud object are determined by the characteristics of the object. Some objects have many results, and some objects have few results.
The output of a cloud object is used in the following two scenarios. Generally, it is used together with the get_attribute built-in function.
- The output is used as an input of another cloud object.
- The output is used as the result of the entire stack.
The syntax is as follows:
# Result of another ECS. The service name is Service. value: {get_attribute: [ecs, Service, ports, 0, nodePort]}
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.