Cloud resource configuration method, device, equipment and computer readable storage medium

Abstract

The application provides a cloud resource configuration method, device and equipment and a computer readable storage medium. The method comprises: obtaining a to-be-processed script described using a domain-specific language (DSL); the to-be-processed script comprises a statement for describing resource configuration information corresponding to a target cloud resource and a topology relationship between resources; performing statement analysis on the to-be-processed script to obtain the resource configuration information corresponding to the target cloud resource and the topology relationship between resources, generating a target configuration file based on the resource configuration information and the topology relationship between resources, generating at least one infrastructure as code (IaC) file according to the target configuration file, and executing the at least one IaC file to complete the automatic deployment of the target cloud resource. The above method can effectively improve the configuration efficiency of the cloud resource.

Description

Technical Field

[0001] This application relates to the field of cloud resource configuration technology, and more particularly to a cloud resource configuration method, apparatus, device, and computer-readable storage medium. Background Technology

[0002] Infrastructure as Code (IaC) refers to the technology of describing, deploying, and maintaining computing infrastructure in the form of code. It allows for the definition and automation of infrastructure creation, configuration, and updates through the writing of executable code, achieving sustainable delivery and repeatability. With the rapid development of cloud computing technology, more and more enterprises are adopting multi-cloud strategies, leveraging the different advantages offered by multiple cloud service providers to meet complex business needs. However, significant differences exist in the technical specifications, application programming interfaces (APIs), and resource management methods between different cloud platforms. Developers need to write independent code for each cloud platform to deploy cloud computing infrastructure, making configuration management in multi-cloud environments complex and inefficient, easily leading to cross-platform inconsistencies, and thus increasing operational risks. Summary of the Invention

[0003] This application provides a method, apparatus, device, and computer-readable storage medium for configuring cloud resources, which can effectively improve the configuration efficiency of cloud resources.

[0004] Firstly, this application provides a method for configuring cloud resources. This method includes: obtaining a script to be processed described using a domain-specific language (DSL), the script containing statements describing resource configuration information and topological relationships between resources corresponding to a target cloud resource. Here, the resource configuration information may include a resource type identifier and attribute information associated with the resource type identifier. The resource type identifier can be used to indicate the resource type of the target cloud resource and the target cloud platform corresponding to the target cloud resource. The attribute information can be used to define the relevant configuration of the target cloud resource, and the topological relationships between resources can be used to describe the order of creation, configuration, and use of different resources. It is evident that by using the resource type identifier in the resource configuration information to indicate the resource type and cloud platform, infrastructure deployment for any cloud resource can be achieved, enabling the DSL script to have cross-cloud platform portability. Furthermore, by using the attribute information and topological relationships between resources in the resource configuration information, the topological relationships between cloud resources provided by multiple cloud platforms can be defined, thereby achieving unified management of multiple cloud platforms. This solves the problem of developers needing to write independent code for different cloud resources or different cloud platforms, reduces cross-platform inconsistencies, and effectively improves the management and configuration efficiency of cloud resources. Furthermore, the script to be processed is parsed to obtain the resource configuration information and topological relationships between the target cloud resources. A target configuration file is then generated based on this information, and at least one infrastructure (IaC) file is generated from the target configuration file. Finally, at least one IaC file is executed to complete the automated deployment of the target cloud resources. In this application, by introducing a DSL into the cloud resource domain—that is, defining cloud infrastructure through a DSL—the configuration process of cloud infrastructure can be abstracted into easily understood declarative statements. This makes the configuration of cloud infrastructure more concise and intuitive. Moreover, because the syntax and semantics of DSL are closer to cloud infrastructure, the redundancy and complexity of general-purpose programming languages ​​are reduced, improving code readability and maintainability. Additionally, since IaC files may not express business logic, but the script to be processed still retains this logic, the target configuration file generated based on the resource configuration information and topological relationships in the script also retains this logic. Therefore, when generating at least one infrastructure (IaC) file from the target configuration file, developers no longer need to describe the business logic through comments or external documentation, improving the deployment efficiency of cloud resources.

[0005] In one possible implementation, the above-mentioned statement parsing of the script to be processed to obtain resource configuration information and topological relationships between resources corresponding to the target cloud resources includes: obtaining a tag sequence based on the script to be processed, and constructing an abstract syntax tree corresponding to the script to be processed based on the tag sequence. The abstract syntax tree is a tree-like representation of the abstract syntactic structure of the corresponding script to be processed, and resource configuration information and topological relationships between resources are obtained based on the abstract syntax tree. In this application, the hierarchical relationships formed between nodes in the abstract syntax tree can intuitively and clearly reflect the logical relationships and syntactic structure in the script to be processed, thereby enabling the acquisition of resource configuration information and topological relationships between resources.

[0006] In one possible implementation, the resource configuration information includes a resource type identifier and attribute information associated with the resource type identifier. After obtaining the tag sequence based on the script to be processed and constructing an abstract syntax tree corresponding to the script based on the tag sequence, the method further includes: validating the abstract syntax tree, and upon successful validation, determining the target cloud resource and the target cloud platform matching the target cloud resource based on the resource type indicated by the resource type identifier. The resource type identifier indicates the resource type of the target cloud resource and the target cloud platform corresponding to the target cloud resource; the target cloud resource includes computing resources, network resources, or storage resources. In this application, by validating the abstract syntax tree, it is possible to detect whether the script to be processed conforms to the coding specifications, thereby improving the fault tolerance rate of subsequent conversion from the script to IaC files, and thus improving the accuracy of cloud resource deployment.

[0007] In one possible implementation, when the target cloud resource includes computing resources, the attribute information includes at least one of instance specifications, image identifier, and security group rules. When the target cloud resource includes network resources, the attribute information includes at least one of address and domain name resolution information. When the target cloud resource includes storage resources, the attribute information includes at least one of storage type, storage capacity, and encryption information. In this application, the configuration of various types of cloud resources can be defined through attribute information, enriching the types and configurations of cloud resource deployment.

[0008] In one possible implementation, the above-mentioned generation of a target configuration file based on resource configuration information and inter-resource topology relationships, and generation of at least one IaC file based on the target configuration file, includes: calling a configuration template corresponding to the target cloud resource based on the target cloud platform, mapping attribute information and inter-resource topology relationships to the configuration template to generate the target configuration file. Further, the business logic contained in the target configuration file can be obtained, and at least one IaC file corresponding to the target configuration file can be generated based on the business logic, wherein the business logic includes at least one of conditional statements and loops. In this application, since the script to be processed defined by the DSL can contain business logic, the target configuration file generated based on resource configuration information and inter-resource topology relationships still retains the business logic. This solves the problem of developers describing business logic through comments or external documentation when generating at least one infrastructure (IaC) file based on the target configuration file, thus improving the deployment efficiency of cloud resources.

[0009] In one possible implementation, mapping attribute information and resource topology relationships to a configuration template includes: locating parameter variables contained in the attribute information and resource topology relationships from the configuration template based on the attribute information and resource topology relationships, and assigning values ​​to the parameter variables based on the attribute information and resource topology relationships. In this application, parameter variables enable dynamic parameter transfer, allowing for the assignment of values ​​to parameter variables based on different cloud resources to meet the different needs of cloud resources for attribute information and resource topology relationships, thus improving the flexibility and applicability of cloud resource configuration.

[0010] In one possible implementation, the aforementioned resource topology includes resource dependencies, which specify the deployment order of target cloud resources. Executing at least one IaC file to automate the deployment of the target cloud resources includes: obtaining parallel dependencies from the resource dependencies and deploying the target cloud resources according to the parallel dependencies using at least one IaC file. In this application, deploying target cloud resources through parallel dependencies included in the resource topology reduces deployment time and improves deployment efficiency.

[0011] Secondly, in one possible implementation, this application provides a cloud resource configuration apparatus, comprising: an acquisition module for acquiring a script to be processed described using a DSL (Specific Language Definition). The script to be processed contains statements describing resource configuration information and topological relationships between resources corresponding to a target cloud resource. A generation module is used to parse the script to obtain the resource configuration information and topological relationships between resources corresponding to the target cloud resource, generate a target configuration file based on the resource configuration information and topological relationships, and generate at least one infrastructure (IaC) file based on the target configuration file. A deployment module is used to execute at least one IaC file to complete the automated deployment of the target cloud resource. In this application, cloud infrastructure is defined using a script to be processed written using a DSL, making cloud infrastructure configuration simpler and more intuitive. Furthermore, because the syntax and semantics of the DSL are closer to cloud infrastructure, it reduces the redundancy and complexity of general-purpose programming languages, improving code readability and maintainability. By using resource configuration information and topological relationships between resources, infrastructure deployment for any cloud resource can be achieved, as well as cross-platform deployment of cloud resources. This enables unified management of multiple cloud platforms, reduces cross-platform inconsistencies, and effectively improves the management and configuration efficiency of cloud resources.

[0012] In one possible implementation, the generation module includes: a processing unit, configured to obtain a tag sequence based on the script to be processed, and construct an abstract syntax tree corresponding to the script to be processed based on the tag sequence. The abstract syntax tree is a tree-like representation of the abstract syntactic structure of the corresponding script to be processed. An acquisition unit is configured to obtain resource configuration information and topological relationships between resources based on the abstract syntax tree. The abstract syntax tree is a tree-like representation of the abstract syntactic structure of the corresponding script to be processed; therefore, the abstract syntax tree can reflect resource configuration information and topological relationships between resources. In this application, the hierarchical relationships formed between nodes in the abstract syntax tree can intuitively and clearly reflect the logical relationships and syntactic structure in the script to be processed, thereby enabling the acquisition of resource configuration information and topological relationships between resources in the script to be processed.

[0013] In one possible implementation, the generation module further includes a verification unit, configured to verify the abstract syntax tree and, upon successful verification, determine the target cloud resource and the target cloud platform matching the target cloud resource based on the resource type indicated by the resource type identifier. The resource type identifier indicates the resource type of the target cloud resource and the corresponding target cloud platform, where the target cloud resource includes computing resources, network resources, or storage resources. In this application, by verifying the abstract syntax tree, it is possible to detect whether the script to be processed conforms to the coding specifications, thereby improving the fault tolerance rate of subsequent conversion from the script to be processed into an IaC file, and ultimately improving the accuracy of deploying cloud resources.

[0014] In one possible implementation, when the target cloud resource includes computing resources, the attribute information includes at least one of instance specifications, image identifier, and security group rules; when the target cloud resource includes network resources, the attribute information includes at least one of address and domain name resolution information; when the target cloud resource includes storage resources, the attribute information includes at least one of storage type, storage capacity, and encryption information. In this application, the configuration of various types of cloud resources can be defined through attribute information, enriching the types and configurations of cloud resource deployment.

[0015] In one possible implementation, the above-mentioned generation module further includes: a mapping unit, used to call a configuration template corresponding to the target cloud resources based on the target cloud platform, and map attribute information and resource topology relationships to the configuration template to generate a target configuration file. The generation unit is used to obtain the business logic contained in the target configuration file and generate at least one IaC file corresponding to the target configuration file based on the business logic, wherein the business logic includes at least one of conditional statements and loops. In this application, since the script to be processed defined by the DSL can contain business logic, the target configuration file generated based on resource configuration information and resource topology relationships still retains the business logic. This solves the problem of developers describing business logic through comments or external documentation when generating at least one infrastructure (IaC) file based on the target configuration file, thus improving the deployment efficiency of cloud resources.

[0016] Thirdly, embodiments of this application provide a computer device, including a memory and a processor. The memory stores a computer program, and the processor invokes the computer program to execute the method provided in the first aspect.

[0017] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a computer device, implements the method provided in the first aspect. Attached Figure Description

[0018] Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application;

[0019] Figure 2 This is a flowchart illustrating a cloud resource configuration method provided in an embodiment of this application;

[0020] Figure 3 This is another flowchart illustrating the cloud resource configuration method provided in this application embodiment;

[0021] Figure 4 This is an abstract syntax tree provided in the embodiments of this application;

[0022] Figure 5 This is a schematic diagram of the structure of the cloud resource configuration device provided in the embodiments of this application;

[0023] Figure 6 This is a schematic diagram of the structure of the computer device provided in the embodiments of this application. Detailed Implementation

[0024] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0025] The following explanations will first clarify some of the terms used in this disclosure to facilitate the understanding of this disclosure by those skilled in the art, and then, in conjunction with the accompanying drawings, will provide a further detailed description of the implementation of the technical solution of this application.

[0026] Cloud computing platform: Also known as a cloud platform, it is an internet-based computing service model that provides various cloud resources (such as computing resources, storage resources, and software services) to users via the network. It enables dynamic allocation and elastic scaling of resources, eliminating the need for users to purchase and maintain expensive hardware; they can simply rent the corresponding services according to their needs. Cloud platforms are typically managed and maintained by cloud service providers, and users can access and use cloud services anytime, anywhere through various terminal devices (such as computers, mobile phones, and tablets).

[0027] Cloud services generally refer to services provided by cloud service providers to users or customers on demand (e.g., via a subscription model), consisting of systems and cloud infrastructure. Typically, the servers and systems that make up the cloud infrastructure are separate from the customer's own on-premises servers and systems. Therefore, users can utilize cloud services provided by cloud service providers without having to purchase separate hardware and software resources for the services. Cloud services offer users simple, scalable access to applications and computing resources without requiring users to invest in the infrastructure used to provide those services.

[0028] Infrastructure as Code (IaC) refers to the practice of defining, configuring, and managing cloud infrastructure as code. Its core idea is to treat cloud infrastructure as software code, implemented through version control and automation tools. Cloud infrastructure is a collective term for server hardware, storage resources, network devices, and application software used to build cloud-based applications. The hardware and software components of cloud infrastructure ensure seamless implementation of cloud computing models for organizations.

[0029] IaC tools are a software development practice that transforms traditional cloud infrastructure management tasks into code, enabling the configuration, deployment, and management of cloud infrastructure through programmatic automation. The core idea behind these tools is to treat cloud infrastructure as part of the software, defining version control through writing and maintaining code, and using consistent automated workflows to create and manage infrastructure resources throughout their entire lifecycle. For example, it allows developers to write executable scripts using descriptive programming languages ​​to automatically deploy, update, and maintain cloud resources.

[0030] In-house configuration (IaC) files are documents that manage and configure cloud infrastructure through code rather than manual processes. They are typically written in declarative languages ​​to ensure consistency across different environments and prevent human error. These IaC files allow users to easily copy, share, and version-control infrastructure configurations, achieving automation and consistency. The syntax used to describe IaC files usually depends on the requirements of the target cloud platform; different cloud platforms support different file formats, such as YAML, JSON, and XML.

[0031] A domain-specific language (DSL) is a computer language designed for a specific application domain. Unlike general-purpose programming languages ​​(such as C and Java), DSLs are tailored to solve problems in a specific domain. They typically offer greater expressiveness and development efficiency, describing domain-specific objects, rules, and operational methods in an extremely efficient manner. Compared to general-purpose languages, they significantly reduce the difficulty of understanding and using them while greatly improving development efficiency.

[0032] Declarative statements are a type of programming language used to declare facts, rules, or goals. Their core focus is on describing "what to do" rather than "how to do it," and they don't concern themselves with the specific steps or algorithmic details required to achieve these goals. Unlike imperative languages, which require detailed specification of each step of a task, declarative languages ​​focus more on expressing the intent of the problem and allow the language implementation to handle the details automatically.

[0033] Please see Figure 1 , Figure 1 This is a schematic diagram of a network architecture provided in an embodiment of this application. Figure 1 As shown, the system architecture may include server 10 and terminal cluster 20. Terminal cluster 20 may include terminal devices 200, 201, 202, ..., 20n. Server 10 may be an independent physical server, a server cluster composed of multiple physical servers, or a distributed system. It may also be a server providing basic cloud computing services such as cloud databases, cloud services, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. Optionally, when server 10 is a server cluster, a single server in the cluster may be called a node. Nodes can be connected via local area networks, high-speed interconnects, remote direct memory access (RDMA), distributed shared memory, etc. The server cluster may include hardware resources (such as servers, storage, central processing units (CPUs)) and service resources (such as software, integrated development environments).

[0034] The terminal devices (including terminal devices 200, 201, 202, ..., 20n) can be smartphones, tablets, laptops, desktop computers, handheld computers, wearable devices (such as smartwatches, smart bracelets, etc.), smart TVs, smart vehicles, and other smart terminals. The specific form of the terminal device is not limited in the embodiments of this application.

[0035] In this application, server 10 can establish communication connections with each terminal device in terminal cluster 20, and the terminal devices in terminal cluster 20 can also establish communication connections with each other. In other words, server 10 can establish communication connections with each terminal device in terminal device 200, terminal device 201, terminal device 202, ..., terminal device 20n. For example, terminal device 200 can establish a communication connection with server 10. Terminal device 200 can establish a communication connection with terminal device 201, and terminal device 200 can establish a communication connection with terminal device 202. The communication connection method is not limited; it can be established directly or indirectly through wired communication or wireless communication, etc., depending on the actual application scenario. This application does not impose any restrictions on this method.

[0036] In existing cloud resource configuration methods, such as Figure 1Each terminal device in the terminal cluster 20 shown can obtain the IaC file used by server 10 to describe the infrastructure of cloud resources, and send the IaC file to server 10 to instruct server 10 to configure the cloud resources. In this way, the terminal device can obtain the cloud resources provided by server 10 and configure the infrastructure of the cloud resources. However, since the cloud services provided by each cloud platform are different, and users configure the infrastructure of different cloud resources differently, developers often need to customize the infrastructure according to the actual business situation. In other words, developers need to write independent IaC files for each set of cloud resources. This requires a lot of manpower and time, and the maintenance cost is also high. Moreover, in the case of multiple cloud platforms, it is not convenient to uniformly manage the configuration of cloud resources, and it is also easy to cause cross-platform inconsistencies, thereby increasing the operational risks. Furthermore, many IaC tools are only compatible with specific cloud platforms. For example, when the cloud platform is Amazon Web Services (AWS), server 10 needs to have AWS Cloud Formation tools provided by Amazon installed; when the cloud platform is Microsoft, server 10 needs to have Azure Resource Manager (ARM) installed; and when the cloud platform is Google, server 10 needs to have Google Cloud Deployment Manager (CDM) installed. Even though Terraform supports multiple cloud platforms, it requires developers to not only learn and master writing IaC files using HashiCorp Configuration Language (HCL), but also to manually handle the differences between different cloud platforms, resulting in a lack of standardization and maintainability.

[0037] In view of this, embodiments of this application provide a method for configuring cloud resources. By defining a DSL script specific to cloud resource infrastructure management, the complex configuration process of IaC files is abstracted into a series of easily understandable declarative statements. These statements can directly describe the infrastructure status of cloud resources required by developers, such as the type, quantity, attributes of cloud resources, and the relationships between them. They can also ensure the consistency of infrastructure in different cloud environments, realize unified management of multi-cloud platforms, and improve resource configuration efficiency.

[0038] Please see Figure 2 , Figure 2 This is a flowchart illustrating a cloud resource configuration method provided in an embodiment of this application. It should be understood that the cloud resource configuration method provided in this application can be implemented by... Figure 1 The terminal devices shown can be executed, or they can be... Figure 1 The server 10 shown can be executed, and can also be... Figure 1 The interaction between the terminal devices and server 10 shown is not limited here. For ease of understanding, this application uses a terminal device as an example for illustration, that is, using... Figure 1 The following description uses terminal device 200 as an example. The embodiments of this application can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, and software development. Figure 2 In the cloud resource configuration method shown, each step of the cloud resource configuration method can be derived from the above. Figure 1 The terminal device 200 in the middle is used to execute, such as Figure 2 As shown, the configuration method for this cloud resource may include at least the following steps S101-S103.

[0039] Step S101: Obtain the script to be processed described using a domain-specific language (DSL); the script to be processed contains statements describing the resource configuration information and topological relationships between resources corresponding to the target cloud resources.

[0040] Specifically, the terminal device 200 can obtain a script to be processed, which may contain multiple statements describing resource configuration information and topological relationships between resources corresponding to the target cloud resources. These statements may be defined using a DSL (Specific to Cloud Infrastructure Management) definition (referred to as a DSL script), that is, defining the cloud infrastructure through declarative statements that describe the resource configuration information and topological relationships between resources corresponding to the target cloud resources. The target cloud resources may include computing resources, network resources, or storage resources. Here, computing resources may include the Central Processing Unit (CPU), Graphics Processing Unit (GPU), or virtual machine resources required by the cloud resources. Optionally, the aforementioned CPU, GPU, and other resources may also be requested in the form of virtual machines or cloud instances. Network resources may include routers, switches, and load balancers, and storage resources may include block storage, file storage, or object storage. Optionally, storage resources may also include Random Access Memory (RAM), Read-Only Memory (ROM), Content-Addressable Memory (CAM), etc. It should be understood that the embodiments of this application do not limit the resource type of the target cloud resource, nor do they limit computing resources, network resources, or storage resources; the specific type can be determined according to the actual application scenario. The resource configuration information may include a resource type identifier and attribute information associated with the resource type identifier. The resource type identifier can be used to indicate the resource type of the target cloud resource and the target cloud platform corresponding to the target cloud resource. For example, the resource type identifier can adopt the naming rule <target cloud platform>_<resource type>. For instance, when the target cloud resource is a computing resource, such as the Elastic Compute Cloud (EC2) provided by AWS, the resource type identifier can be...<aws_ec2> When the target cloud resource is a network resource, such as a Virtual Private Cloud (VPC) provided by AWS, the resource type identifier can be...<aws_vpc> When the target cloud resource is a storage resource, such as Elastic BlockStore (EBS) provided by AWS, the resource type identifier can be...<aws_ebs> As can be seen, by defining resource type identifiers, the resource types of cloud platforms and cloud resources can be distinguished, making it easier for developers to locate and find them. At the same time, resource type identifiers can also be used to avoid resource conflicts, making the code easier to maintain.

[0041] In some feasible implementations, attribute information can be generated by developers at the development management platform and can include build artifacts generated during software development, as well as other information used to configure the target cloud resource, such as certificates and keys associated with the target cloud resource. When the target cloud resource is a computing resource, the attribute information associated with the computing resource can include at least one of instance specifications, image identifiers, and security group rules. Instance specifications can be used to indicate the instance's configuration, such as parameters related to CPU, memory, and storage. An image identifier (image identity document, also known as an image ID) is a unique identifier for an image. An image is a file storage format that contains all the content required by the computing resource, including runtime code, libraries, environment variables, and configuration files. Security group rules can include a list of security groups, which can contain multiple security groups. These security groups act as virtual firewalls with stateful inspection and packet filtering capabilities. They can filter packets entering and leaving the cloud server and are an important means of network security isolation. By defining security group rules, inbound and outbound traffic to cloud resources within the security group can be controlled to achieve access control and network security protection for cloud resources. For example, taking EC2, whose computing resources are provided by the AWS cloud platform, as an example, the statement described using DSL can be seen in the following code:

[0042] # Declaratively define cloud infrastructure topology (identifier: cloud_infra)

[0043] cloud_infra "web_app" do

[0044] #Example 1. Computational Resource Definition

[0045] aws_ec2 "web_server"{

[0046] instance_type="t3.micro" # Attribute information: instance type

[0047] ami = "ami-0abc123" # Attribute information: mirror identifier

[0048] security_groups = ["sg-web"] # Attribute information: List of security groups

[0049] }

[0050] Wherein, `cloud_infra` can be an identifier defining the cloud infrastructure, `web_app` can be the resource name of the cloud resource, `aws_ec2` can be a resource type identifier, indicating that it is an EC2 provided by AWS, `"web_server"` can be the name of the computing resource, `aws_ec2"web_server"` can be the web server using an EC2 instance, `instance_type="t3.micro"` can be the instance specification using a t3.micro instance provided by AWS, and `ami = "ami-0abc123"` can be the image identifier "ami-0abc123". Here, `security_groups = ["sg-web"]` can be used to represent a list of security groups. It should be understood that the above-mentioned EC2 and its associated attribute information provided by the AWS cloud platform are only one example among many, and this application does not limit the attribute information associated with computing resources.

[0051] When the target cloud resource includes network resources, the attribute information may include at least one of address and domain name resolution information. Here, the network address can be an Internet Protocol address (IP address), which can be used to identify network devices. The domain name resolution information may include the domain name resolution method, such as converting the domain name to an IP address through the Domain Name System (DNS), Dynamic Host Configuration Protocol (DHCP), or Windows Internet Name Service (WINS). For example, taking a VPC provided by the AWS cloud platform as an example, the statement described using DSL can be seen in the following code:

[0052] #Example 2. Network Resource Definition

[0053] aws_vpc "vpc_network"{

[0054] cidr_block="10.6.0.0 / 16" # Attribute information: IP address range

[0055] enable_dns_hostnames = true # Property information: Enable DNS resolution

[0056] }

[0057] Here, `aws_vpc` is a resource type identifier, indicating a VPC provided by AWS. `vpc_network` represents the name of the network resource. `aws_vpc "vpc_network"` indicates that the VPC network uses an EC2 instance. `cidr_block ="10.6.0.0 / 16"` represents the IP address range, and `enable_dns_hostnames = true` indicates that DNS resolution is used for domain names. It should be understood that the above-mentioned VPCs and associated attribute information provided by the AWS cloud platform are only one example among many, and this application does not limit the attribute information associated with network resources.

[0058] When the target cloud resource includes storage resources, the attribute information may include at least one of storage type, storage capacity, and encryption information. Here, storage type may include block storage, file storage, or object storage, storage capacity refers to the amount of binary information the storage device can hold, and encryption information can be used to confirm whether encryption of the cloud resource is initiated. For example, taking EBS provided by the AWS cloud platform as an example, the statement described using a DSL can be seen in the following code:

[0059] #Example 3. Storage Resource Definition

[0060] aws_ebs "data_volume"{

[0061] volume_type="gp3" # Attribute information: storage type

[0062] volume_size= 50 #Attribute information: Storage capacity (6B)

[0063] encrypted = true # Property information: Enable encryption

[0064] }

[0065] Wherein, aws_ebs is the resource type identifier, indicating that it is an EBS provided by AWS; "data_volume" indicates that the storage resource is a data volume; aws_ebs "data_volume" indicates that the data volume uses an EBS provided by AWS; volume_type="gp3" indicates that it is stored using a gp3 type storage volume; volume_size = 50 indicates the storage capacity of the gp3; and encrypted=true indicates that the data stored in the gp3 is encrypted. It should be understood that the above-mentioned EBS provided by the AWS cloud platform and its associated attribute information are only one example among many, and this application does not limit the attribute information associated with storage resources.

[0066] It is understood that the above "#Example 1. Computing Resource Definition", "#Example 2. Network Resource Definition" and "#Example 3. Storage Resource Definition" can be in the same DSL script, and the computing resources, network resources and storage resources in "#Example 1. Computing Resource Definition", "#Example 2. Network Resource Definition" and "#Example 3. Storage Resource Definition" can also be replaced with computing resources, network resources and storage resources provided by other cloud platforms. This application embodiment does not impose any restrictions here.

[0067] In some feasible implementations, resource topology relationships can be used to describe the order in which different resources are created, configured, and used. For example, resource topology relationships can describe the dependency order between computing resources, network resources, storage resources, etc. This configuration ensures that all necessary prerequisite resources have been configured before configuring the current resource or the current task phase. By explicitly defining topology relationships, it can be ensured that cloud infrastructure operates according to expected logic, avoiding failures caused by missing dependencies or incorrect ordering. Resource topology relationships can include resource dependencies, which can be used to define the order in which resources are created or destroyed. Here, resource dependencies can be represented using the `depends_on` field, such as `depends_on "<target resource>" => "<dependent resource>"`. For example, a database must depend on a storage volume; that is, the database service needs to mount the storage volume before storing data. For example, taking the above "#Example 1. Computing Resource Definition", "#Example 2. Network Resource Definition", and "#Example 3. Storage Resource Definition" as examples, the DSL statements for the resource dependencies of the three can be seen in the following code:

[0068] #Example 4. Topology Dependency Declaration

[0069] #Note: Declare web_server as dependent on vpc_network

[0070] depends on "aws_ec2.web_server" =>"aws_vpc.vpc_network"

[0071] #Note: data_volume is mounted to web_server via block_devices.

[0072] aws_ec2.web_server.block_devices = [aws_ebs.data_volume]

[0073] end

[0074] In the above example 1. Computing resource definition, web_server depends on vpc_network in example 2. Network resource definition, and data_volume in example 3. Storage resource definition needs to be mounted to web_server through block_devices.

[0075] Optionally, the topological relationships between resources may also include connectivity relationships or logical associations. Connectivity relationships can be used to describe the physical or logical connections between resources, while logical associations can be used to express the relevance of resources at the business level. For example, the connection between a load balancer and a backend server, and the connection between a subnet and a routing table, can both be considered connectivity relationships. In this case, the load balancer needs to distribute traffic to multiple backend virtual machines, and the subnet needs to be associated with the routing table to control network traffic paths. As another example, the connection between a web application and a database, and the connection between a monitoring system and all resources, can be considered logical associations. In this case, the web server needs to access the database service to process user requests, and the monitoring system needs to collect logs and metrics from all critical resources. It should be understood that the embodiments of this application do not limit the type of topological relationship between resources, and the specific type can be determined according to the actual application scenario.

[0076] For common cloud resources such as VPC, EC2, databases, and security groups, there are usually corresponding preset resource templates. These templates contain all the necessary cloud resource definitions and attributes, and may also include variable identifiers. Developers can inject parameters into these templates according to their actual needs. In some feasible implementations, the terminal device 200 can obtain a preset resource template corresponding to the target cloud resource. This template may contain variable identifiers, which developers can replace with actual parameter values ​​to generate a script to be processed. The preset resource template can be a script described using a DSL, containing the basic structure and configuration of the cloud infrastructure, and can be used to quickly deploy common cloud infrastructure configurations. The aforementioned variable identifiers can be the resource name, size, version, network configuration, etc. Therefore, by setting preset resource templates, when a matching preset resource template exists for the target cloud resource, it can be quickly obtained, and parameters can be injected into the template to generate a script to be processed, reducing time costs and improving the configuration efficiency of cloud resources. Optionally, the terminal device 200 may be equipped with a development management platform. The development management platform can display an interactive interface for configuring cloud resources. Developers can select a preset resource template that matches the target cloud resource in the interactive interface, and can also adjust or modify variable identifiers in the interactive interface. Then, according to actual needs, parameters are injected into the preset resource template to generate a script to be processed.

[0077] It should be understood that defining cloud infrastructure through a DSL—that is, defining resource configuration information and the topological relationships between resources—allows the configuration process of cloud infrastructure to be abstracted into easily understandable declarative statements. This makes cloud infrastructure configuration simpler and more intuitive. Furthermore, the syntax and semantics of DSLs are closer to the cloud infrastructure domain, reducing the redundancy and complexity of general-purpose programming languages ​​and improving code readability and maintainability. In addition, the resource type identifier in the resource configuration information indicates the resource type and cloud platform, enabling the deployment of infrastructure for any cloud resource. This gives DSL scripts cross-cloud platform portability. Moreover, the attribute information and topological relationships between resources in the resource configuration information can define the topological relationships between cloud resources provided by various cloud platforms, thereby achieving unified management of multiple cloud platforms. This solves the problem of developers needing to write independent code for different cloud resources or platforms, reduces cross-platform inconsistencies, and effectively improves the management and configuration efficiency of cloud resources.

[0078] Step S102: Parse the script to be processed to obtain the resource configuration information and topological relationship between the target cloud resources, generate the target configuration file based on the resource configuration information and topological relationship between the resources, and generate at least one infrastructure code (IaC) file based on the target configuration file.

[0079] Specifically, the terminal device 200 can obtain a token sequence based on the script to be processed and construct an abstract syntax tree (AST) corresponding to the script based on the token sequence. The AST is a tree-like representation of the abstract syntactic structure of the script to be processed. Further, the terminal device 200 can obtain resource configuration information and topological relationships between resources based on the AST. Here, the parsing of the script to be processed (i.e., the DSL script) can include lexical analysis and syntax analysis. Lexical analysis converts the DSL script into a series of tokens, which are the basic building blocks of a language. Lexical analysis can identify and classify different tokens so that subsequent syntax analysis can parse the structure of the DSL script. Syntax analysis can construct an abstract syntax tree (AST) based on the token sequence obtained from lexical analysis. The AST represents the hierarchical structure and syntactic rules of the DSL script and is a tree-like representation of the abstract syntactic structure of the corresponding DSL script. Based on the AST, the resource configuration information and topological relationships between the target cloud resources can be analyzed.

[0080] Optionally, the lexical analysis and syntax analysis processes described above can be abstracted into lexical analysis modules and syntax analysis modules, respectively, and integrated into the DSL parser. See also... Figure 3 , Figure 3 This is another flowchart illustrating the cloud resource configuration method provided in this application embodiment. For example... Figure 3 As shown, the DSL script can contain statements describing resource configuration information and topological relationships between resources corresponding to the target cloud resources. The terminal device 200 can parse the DSL script using a DSL parser to obtain the resource configuration information and topological relationships between resources corresponding to the target cloud resources, and generate a target configuration file based on the resource configuration information and topological relationships between resources. For ease of understanding, the following code will explain the process of the DSL parser parsing the DSL script.

[0081] cloud infrastructure "web_app" do

[0082] aws_ec2 "web_server"{

[0083] instance_type="t3.micro" # Attribute information: instance type

[0084] ami = "ami-0abc123" # Attribute information: mirror identifier

[0085] security_groups = ["sg-web"] # Attribute information: List of security groups

[0086] }

[0087] end

[0088] The lexical analysis module in the DSL parser scans the DSL script from left to right and outputs a token sequence. This token sequence can be composed of lexical units, which can include lexical units (i.e., their corresponding types). Lexical units are character sequences with independent semantics, covering keywords, identifiers (variables), constants, operators, etc. Specifically, the token sequences corresponding to the aforementioned DSL scripts can be found in Table 1.

[0089] Table 1

[0090]

[0091] Furthermore, the syntax analysis module in the DSL contactor can construct an AST based on the tag sequence in Table 1, as detailed in [reference needed]. Figure 4 , Figure 4 This is an abstract syntax tree provided in the embodiments of this application. For example... Figure 4 As shown, the AST is a tree-like representation of a DSL script. This is an intermediate representation where each node in the AST represents a syntactic element in the DSL script, such as an expression, statement, or declaration. This tree structure represents the hierarchical structure and syntactic rules of the DSL script. Therefore, resource configuration information and the topological relationships between resources in a DSL script can be obtained from the AST.

[0092] In some feasible implementations, after obtaining the Abstract Syntax Tree (AST), the terminal device 200 can further verify the AST and, upon successful verification, determine the target cloud resource and the target cloud platform matching the target cloud resource based on the resource type indicated by the resource type identifier. The resource type identifier indicates the resource type of the target cloud resource and the target cloud platform corresponding to it.

[0093] In specific implementation, after generating the AST, semantic analysis can be performed on the AST to verify it. Semantic analysis checks the semantic accuracy of the DSL script, ensuring it conforms to programming language specifications. This includes, but is not limited to, symbol checking, type checking, scope analysis, error detection, and semantic rule verification. If the DSL script contains non-compliant issues, error or warning messages can be generated. Optionally, the above semantic analysis process can also be abstracted into a semantic analysis module and integrated into the DSL parser. The terminal device 200 can perform semantic analysis on the AST through the semantic analysis module in the DSL parser. When non-compliant issues exist in the DSL script, the semantic analysis module can generate error or warning messages. When the DSL script conforms to the specifications, i.e., when verification is successful, the terminal device 200 can determine the target cloud resource and the target cloud platform matching the target cloud resource based on the resource type indicated by the resource type identifier. For example, as... Figure 4 As shown, based on the node containing "Resource: aws_ec2" in the AST, the target cloud resource is EC2, and the target cloud platform is AWS. Therefore, by validating the AST, we can detect whether the DSL script conforms to the coding standards, thereby improving the fault tolerance of the subsequent conversion from the DSL script to the IaC file, and ultimately improving the accuracy of cloud resource deployment.

[0094] In some feasible implementations, when the semantic analysis module in the DSL parser detects non-compliant issues in the DSL script, the terminal device 200 can optimize the DSL script using techniques such as constant folding, dead code elimination, and loop optimization to reduce the runtime and resource consumption of the generated code. Optionally, the above optimization process can also be abstracted into a code optimization module and integrated into the DSL parser. The code optimization module can optimize the generated intermediate representation (usually an abstract syntax tree or intermediate code) to improve the performance and efficiency of the program.

[0095] Furthermore, the terminal device 200 can invoke the configuration template corresponding to the target cloud resource based on the target cloud platform, mapping attribute information and resource topology relationships to the configuration template to generate a target configuration file. Here, the configuration template corresponding to the target cloud resource can be pre-set; it can contain attributes related to the target cloud resource, but the specific parameters of these attributes are not set. For example, when the target cloud resource is a GPU resource, the configuration template can contain the instance specifications, image identifiers, or security group rules of the GPU resource, but the specific parameters of these instance specifications, image identifiers, or security group rules are not set.

[0096] Specifically, the terminal device 200 can match the attribute information and resource topology relationships in the AST with the attributes in the configuration template, mapping the parameter values ​​contained in the attribute information and resource topology relationships to the configuration template to generate a target configuration file. The target configuration file can use a key-value pair data format, such as JSON or YAML. Therefore, the process of mapping attribute information and resource topology relationships to the configuration template can be viewed as a data format conversion of the AST, that is, converting the AST into a key-value pair data format.

[0097] Optionally, the process of mapping attribute information and resource topology relationships to a configuration template to generate a target configuration file can also be abstracted into a code generation module and integrated into the DSL parser. This code generation module can convert the AST (Abstract Syntax Tree) after lexical and syntactic analysis into target code. Here, for example... Figure 3 As shown, the target code can be a target configuration file, meaning that the terminal device 200 can convert any DSL script into a target configuration file through the DSL parser.

[0098] In addition to specific parameter values, DSL scripts can also contain parameter variables. That is, the attribute information and resource topology relationships in the DSL script can carry parameter variables and their corresponding parameter values. Therefore, these parameter variables can be assigned values ​​when generating the target configuration file. Optionally, the terminal device 200 can use a DSL parser to locate the parameter variables contained in the attribute information and resource topology relationships from the configuration template, and assign values ​​to the parameter variables based on the attribute information and resource topology relationships. Here, since parameter variables exist in the DSL script, the terminal device 200 can locate the parameter variables and assign values ​​to them according to the parameter values ​​carried in the attribute information and resource topology relationships during the mapping of attribute information and resource topology relationships to the configuration template, thereby generating the final target configuration file. It should be understood that parameter variables enable dynamic parameter transfer, allowing parameter variables to be assigned values ​​based on different cloud resources to meet the needs of different cloud resources for attribute information and resource topology relationships, improving the flexibility and applicability of cloud resource configuration.

[0099] DSL scripts can include, but are not limited to, declarative statements and logical statements. Logical statements can be used to describe business logic, such as if / else conditional statements and for loop statements. Therefore, the AST constructed from the DSL script also expresses the business logic; in other words, the target configuration file obtained from the AST also contains business logic. However, some IaC tools cannot support business logic. For example, Terraform itself does not support conditional statements, loop statements, or other business logic. Therefore, the target configuration file containing business logic cannot be directly used by the IaC tool and needs to be processed to generate an IaC file compatible with the IaC tool. Here, the target configuration file can be considered an intermediate file in the process of converting the DSL script into an IaC file. In some feasible implementations, the terminal device 200 can obtain the business logic contained in the target configuration file and generate at least one IaC file corresponding to the target configuration file based on the business logic. The business logic includes at least one of conditional statements and loops. Here, the IaC file can also adopt a key-value pair data format, such as JSON or YAML. However, the main difference between the IaC file and the target configuration file is that the IaC file cannot express business logic, while the target configuration file can contain business logic. For ease of understanding, the following explanation will use business logic as conditional statements and loop statements. The DSL script can be found in the following code:

[0100] #Example 5. DSL script with business logic

[0101] cluster "gpu_training" do

[0102] # Adjust resource allocation based on time period

[0103] if time.hour.between?(9, 17) # Working hours (9:00-17:00)

[0104] target_capacity = 15

[0105] max_price = 0.4

[0106] else # Non-working hours

[0107] target_capacity = 5

[0108] max_price = 0.2

[0109] end

[0110] # Create 3 groups of GPU nodes in a loop

[0111] for i in 1..3 do

[0112] aws_spot_fleet "gpu_nodes_#{i}" do

[0113] target_capacity = target_capacity / 3 # Distribute evenly among groups

[0114] instance_type = "p3.8xlarge"

[0115] max_price = max_price

[0116] interruption_handler = "terminate"

[0117] end

[0118] end

[0119] end

[0120] In Example 5, a DSL script with business logic, the business logic consists of conditional statements (i.e., if statements) and loop statements (i.e., for loops). "if time.hour.between?(9, 17)" indicates the working hours are from 9:00 to 17:00. "target_capacity" represents the target memory of the requested GPU, and "max_price" represents the price cap. According to Example 5, when the condition of working hours from 9:00 to 17:00 is true, a GPU with a target memory of 15 and a price cap of 0.4 is requested; when the condition of working hours from 9:00 to 17:00 is false, a GPU with a target memory of 5 and a price cap of 0.2 is requested. The for loop executes the steps of creating three groups of GPU nodes to evenly distribute GPU resources across the three groups. When the condition that the working hours are from 9:00 to 17:00 is true, GPUs with a target memory of 15 and a price cap of 0.4 are evenly distributed across 3 GPU nodes. When the condition that the working hours are from 9:00 to 17:00 is false, GPUs with a target memory of 5 and a price cap of 0.2 are evenly distributed across 3 GPU nodes. It is evident that the above-mentioned if conditional statements and for loops can allocate more resources to GPUs during the 9:00 to 17:00 time period. Understandably, business logic can define business requirements and processes to configure cloud resources with different functions, thus meeting the configuration needs of various cloud resources.

[0121] It should be understood that since the AST is a tree-like representation of the DSL script, the target configuration file obtained through the AST also contains the business logic of the DSL script. The target configuration file generated from "#Example 5. DSL script with business logic" can be seen in the following code:

[0122] #Example 6. Target configuration file with business logic

[0123] CLUSTER "gpu_training":

[0124] # Time-based conditional logic block

[0125] IF_BLOCK:

[0126] CONDITION: "time.hour.between?(9, 17)"

[0127] THEN_BLOCK:

[0128] - target_capacity: 15

[0129] - max_price: 0.4

[0130] ELSE_BLOCK:

[0131] - target_capacity: 5

[0132] - max_price: 0.2

[0133] # Create resources in a loop

[0134] FOR_BLOCK:

[0135] LOOP: "i in 1..3"

[0136] BODY:

[0137] - RESOURCE "aws_spot_fleet":

[0138] NAME: "gpu_nodes_#{i}"

[0139] PROPERTIES:

[0140] - target_capacity: "target_capacity / 3" # Distribute evenly among groups

[0141] - instance_type: "p3.8xlarge"

[0142] - max_price: "max_price"

[0143] - interruption_handler: "terminate"

[0144] As shown in "#Example 6. Target Configuration File with Business Logic" above, the target configuration file can be in JSON format and still contains the business logic from the DSL script, such as if conditional statements and for loops. Here, IF_BLOCK is a control structure in programming that determines the execution path of the program based on conditional statements. CONDITION is the condition for IF_BLOCK; CONDITION: "time.hour.between?(9, 17)" can indicate that the condition is working hours from 9:00 to 17:00. If the condition is true, the code block in IF_BLOCK (such as THEN_BLOCK) is executed; otherwise, the statement in ELSE_BLOCK is executed. FOR_BLOCK can create 3 groups of GPU nodes in a loop and evenly distribute the allocated GPU resources across the 3 groups of GPU nodes. Here, since "#Example 6. Target Configuration File with Business Logic" contains two sets of business logic (i.e., if conditional statements and for loops), at least two IaC files will be generated based on the business logic. For ease of description, the following example uses the condition that the working hours are between 9:00 and 17:00 as true. See the code below for details:

[0145] #Example 7. IaC file corresponding to Example 6

[0146] {

[0147] "cluster": "gpu_training",

[0148] "condition": "time.hour.between?(9, 17)",

[0149] "resources": [

[0150] {

[0151] "type": "aws_spot_fleet",

[0152] "name": "gpu_nodes_1",

[0153] "properties": {

[0154] "target_capacity": 5,

[0155] "instance_type": "p3.8xlarge",

[0156] "max_price": 0.4,

[0157] "interruption_handler": "terminate"

[0158] }

[0159] },

[0160] {

[0161] "type": "aws_spot_fleet",

[0162] "name": "gpu_nodes_2",

[0163] "properties": { "target_capacity": 5,

[0164] "instance_type": "p3.8xlarge",

[0165] "max_price": 0.4,

[0166] "interruption_handler": "terminate"

[0167] }

[0168] },

[0169] {

[0170] "type": "aws_spot_fleet",

[0171] "name": "gpu_nodes_3",

[0172] "properties": {

[0173] "target_capacity": 5,

[0174] "instance_type": "p3.8xlarge",

[0175] "max_price": 0.4,

[0176] "interruption_handler": "terminate"

[0177] }

[0178] } ]

[0179] }

[0180] As shown in "#Example 7. IaC file corresponding to Example 6", the IaC file does not express business logic, but directly declares resource configuration. For example, when working hours are from 9:00 to 17:00, a GPU with a target memory of 15 and a price cap of 0.4 can be directly requested through the IaC file, and this GPU with a target memory of 15 and a price cap of 0.4 can be evenly distributed across 3 GPU node groups, that is, GPU node 1 "gpu_nodes_1", GPU node 2 "gpu_nodes_2", and GPU node 3 "gpu_nodes_3" are allocated the same GPU resources. It should be understood that when working hours are not from 9:00 to 17:00, a GPU with a target memory of 5 and a price cap of 0.2 can be directly requested through the IaC file, and this GPU with a target memory of 5 and a price cap of 0.2 can be evenly distributed across 3 GPU node groups, that is, GPU node 1 "gpu_nodes_1", GPU node 2 "gpu_nodes_2", and GPU node 3 "gpu_nodes_3" are allocated the same GPU resources. Here, when the condition of working hours from 9:00 to 17:00 is true, there is one IaC file. The three groups of GPU nodes also correspond to three IaC files. Since the three groups of GPUs are allocated the same resources, the three IaC files generated according to the business logic are also the same.

[0181] In some feasible implementations, when the DSL script does not contain business logic, the target configuration file obtained from the DSL script also does not contain business logic, and thus the target configuration file can be directly used by the IaC tool. In other words, the target configuration file obtained from a DSL script without business logic can be regarded as an IaC file. For example, see the following code:

[0182] #Example 8. DSL script with business logic

[0183] # Define an elastic GPU cluster

[0184] cluster "gpu_training" do

[0185] #Spot instance configuration (cost optimization)

[0186] aws_spot fleet "gpu_nodes" {

[0187] target capacity = 10# Number of target instances

[0188] instance _type ="p3.8xlarge# GPU model"

[0189] max_price=0.3 # Bidding cap (USD / hour)

[0190] interruption handler="terminate" # Terminates the instance after an interruption

[0191] }

[0192] The above "#Example 8 DSL script with business logic" does not contain business logic. Therefore, the target configuration file obtained from the above "#Example 6 DSL script with business logic" also does not contain business logic and can be directly used by the IaC tool.

[0193] In some feasible implementations, the process of generating at least one IaC file corresponding to the target configuration file based on business logic can be completed by an IaC generator, such as... Figure 3 As shown, the IaC generator can operate independently of the DSL parser. Alternatively, the IaC generator can also be integrated into the DSL parser; this is not a limitation.

[0194] It should be understood that by performing lexical and syntactic analysis on DSL scripts, they can be abstracted into a syntax tree. The hierarchical relationships between nodes in the AST (Abstract Syntax Tree) can intuitively and clearly reflect the logical relationships and syntactic structure of the DSL script, such as resource configuration information and topological relationships between resources. Furthermore, validating the AST can improve the fault tolerance rate of converting DSL scripts to IaC files, thereby improving the accuracy of IaC deployment. The target configuration file obtained from the DSL script still retains the business logic. Therefore, when generating IaC files based on the business logic of the target configuration file, the problem of developers needing to describe the business logic through comments or external documentation is solved, improving the deployment efficiency of cloud resources. In addition, the process of converting DSL scripts to IaC files provided in this application embodiment can also be integrated into the development workflow, enabling developers to easily convert DSL scripts to IaC files. This can be achieved by building plugins, tools, or integrating into the development environment, improving development efficiency, simplifying code writing in the cloud infrastructure field, and thus improving development efficiency and code quality.

[0195] Step S103: Execute at least one IaC file to complete the automated deployment of the target cloud resources.

[0196] Specifically, such as Figure 3As shown, cloud resources can be deployed by executing IaC files using IaC tools. For example, terminal device 200 can run cloud resource deployment commands to call cloud resource interfaces based on at least one IaC file and create target cloud resources on the target cloud platform. The cloud resource creation commands are commands from the IaC tool used to trigger the cloud resource creation process. These commands interact with the cloud service provider's API based on the parameters defined in the IaC file. Taking Terraform as an example, these files typically have a ".tf" extension. Running the Terraform creation command `terraform apply` causes Terraform to call the AWS cloud platform's API based on the generated IaC file, obtaining the cloud infrastructure required for the target cloud resource (e.g., creating VPCs, EC2 instances, RDS database instances, and security group rules). Based on the information obtained from the API, Terraform deploys the cloud infrastructure of the target cloud resource on the AWS cloud platform. Here, the Terraform `terraformapply` command is a core command of Terraform, used to apply the resource status defined in the IaC file to the actual cloud environment. When this command is executed, Terraform reads the configuration file, generates an execution plan, and calls the corresponding cloud service API to create or update resources, returning success or failure information to the developer. Cloud service providers offer APIs that allow Infrastructure as Code tools to interact with cloud services to create and manage cloud resources. Once an Infrastructure as Code tool (such as Terraform) determines the state of the required resources based on the configuration file, it will create new resources or modify existing resources to match the definitions in the configuration file via the cloud platform's API.

[0197] In some feasible implementations, after generating the IaC file, a repository can be created in a code management service platform. A code management service platform is a system that records historical changes to files or projects, allowing users to view historical versions of files, compare differences between versions, and roll back to a previous version when needed. Common version control systems include GitLab, GitHub, self-hosted Git servers, and Subversion (SVN). The code management service platform can be used to access or modify historical versions of files, adding the generated IaC file and its status information to the repository created within the platform. Here, the status information may include the IaC file version. Taking GitHub as an example, a new repository is created on GitHub to store all IaC files (such as Terraform's .tf files) and their historical versions. Simultaneously, the status information of these IaC files is submitted to the repository created on GitHub, generating a unique version identifier for each. This version identifier allows developers to easily view the specific details of each change and to revert to a previous version when needed. In this embodiment, developers can access and modify historical versions of configuration files, facilitating backtracking and auditing.

[0198] In some feasible implementations, the topological relationships between resources may include resource dependencies, which can be used to specify the deployment order of target cloud resources. During the process of executing at least one IaC file to automate the deployment of target cloud resources, the terminal device 200 can obtain parallel dependencies from the resource dependencies and deploy the target cloud resources according to the parallel dependencies by executing at least one IaC file. For example, if the resource dependencies between resources A, B, C, and D are such that resource C depends on resource B, resource B depends on resource A, and resource C depends on resource D, meaning the deployment order is resource A, resource B, resource C, and resource D needs to be deployed before resource C, then the resource dependency between resources A and D is a parallel dependency. Therefore, during resource deployment, the terminal device 200 can identify the parallel dependency between resources A and D using IaC tools and deploy resources A and D according to the parallel dependencies. Then, resource B is deployed after resource A is deployed, and finally, resource C is deployed after resources B and D are deployed. As can be seen, by adjusting the priority of resources through the above parallel dependencies (such as increasing the priority of resource D so that resources A and D can be deployed in parallel), multiple parallel deployments can be achieved, reducing the deployment time of resources and improving the deployment efficiency of resources.

[0199] In some feasible implementations, terminal device 200 can transmit at least one IaC file to server 10 to execute the IaC file using an IaC tool mounted on server 10 to automate the deployment of target cloud resources. During the deployment of target cloud resources using IaC tools, resource circular dependencies may occur due to inter-resource dependencies. For example, the creation of resource A may depend on resource B, the creation of resource B may depend on resource C, and the creation of resource C may depend on resource A. This results in a complete closed loop of dependencies between the three resources, making it impossible to start resource deployment from any single resource. To break this closed-loop resource circular dependency, the resource priority can be adjusted using the topological relationships between resources. For example, when resource B has the highest priority, resources can be deployed in the order of resource B, resource A, and resource C. In this way, the closed-loop resource circular dependency can be broken, improving the success rate and efficiency of resource deployment.

[0200] It should be understood that defining cloud infrastructure through a DSL (Specific Module for Defining Cloud Infrastructure), i.e., defining resource configuration information and inter-resource topology relationships through DSL scripts, is applicable to multi-platform scenarios. Specifically, the resource type identifier in the resource configuration information indicates the resource type and cloud platform, distinguishing arbitrary cloud resources provided by different cloud platforms. Furthermore, the attribute information and inter-resource topology relationships in the resource configuration information define the topology relationships between cloud resources provided by various cloud platforms, giving DSL scripts cross-platform portability. This achieves unified management across multiple cloud platforms, solving the problem of developers needing to write independent code for different cloud resources or platforms, reducing cross-platform inconsistencies, and effectively improving the management and configuration efficiency of cloud resources. Simultaneously, since the target configuration file generated based on the resource configuration information and inter-resource topology relationships still retains business logic, developers no longer need to describe the business logic through comments or external documentation when generating IaC files based on the business logic of the target configuration file, improving the deployment efficiency of cloud resources. Additionally, in the process of automating the deployment of target cloud resources, the parallel dependencies included in the inter-resource topology relationships can be used to deploy the target cloud resources, reducing deployment time and improving deployment efficiency.

[0201] Based on the same inventive concept, this disclosure also provides a cloud resource configuration device, as shown in the following embodiments. Since the principle of this cloud resource configuration device embodiment in solving the problem is similar to that of the above method embodiments, the implementation of this cloud resource configuration device embodiment can refer to the implementation of the above method embodiments, and repeated details will not be described again. It should be understood that the above cloud resource configuration device can be a computer program (including program code) running on a computer device, for example, the cloud resource configuration device is an application software; the cloud resource configuration device can be used to execute the corresponding steps in the method provided in the embodiments of this application. Please refer to... Figure 5 , Figure 5 This is a schematic diagram of the cloud resource configuration device provided in an embodiment of this application. Figure 5 As shown, the cloud resource configuration device 30 may include: an acquisition module 301, a generation module 302, and a deployment module 303.

[0202] The acquisition module 301 is used to acquire a script to be processed described using DSL; the script to be processed contains statements describing resource configuration information and topological relationships between resources corresponding to the target cloud resources;

[0203] The generation module 302 is used to parse the script to be processed to obtain the resource configuration information and the topological relationship between the resources corresponding to the target cloud resources, and generate a target configuration file based on the resource configuration information and the topological relationship between the resources, and generate at least one infrastructure code IaC file according to the target configuration file;

[0204] Deployment module 303 is used to execute at least one IaC file to complete the automated deployment of the target cloud resources.

[0205] According to the above Figure 2 The corresponding implementation, Figure 2 The implementation method described in steps S101 to S103 of the cloud resource configuration method shown can be derived from... Figure 5 The various modules of the cloud resource configuration device 30 shown are executed. For example, the above... Figure 2 The implementation method described in step S101 of the cloud resource configuration method shown can be executed by the acquisition module 301, the implementation method described in step S102 can be executed by the generation module 302, and the implementation method described in step S103 can be executed by the deployment module 303. The implementation methods executed by the acquisition module 301, generation module 302, and deployment module 303 are as described above. Figure 2 The implementation methods provided for each step in the corresponding embodiments will not be repeated here.

[0206] In some feasible implementations, the generation module 302 includes:

[0207] The processing unit 3021 is used to obtain a tag sequence based on the script to be processed, and to construct an abstract syntax tree corresponding to the script to be processed based on the tag sequence; the abstract syntax tree is a tree-like representation of the abstract syntax structure of the corresponding script to be processed.

[0208] The acquisition unit 3022 is used to obtain resource configuration information and topological relationships between resources based on the abstract syntax tree.

[0209] In some feasible implementations, the aforementioned resource configuration information includes a resource type identifier and attribute information associated with the resource type identifier, and the aforementioned generation module 302 further includes:

[0210] The verification unit 3023 is used to verify the abstract syntax tree and, upon successful verification, determine the target cloud resource and the target cloud platform that matches the target cloud resource based on the resource type identifier.

[0211] The resource type identifier is used to indicate the resource type of the target cloud resource and the target cloud platform corresponding to the target cloud resource. The target cloud resource includes computing resources, network resources, or storage resources.

[0212] In some feasible implementations, when the target cloud resources include computing resources, the attribute information includes at least one of instance specifications, image identifier, and security group rules; when the target cloud resources include network resources, the attribute information includes at least one of address and domain name resolution information; when the target cloud resources include storage resources, the attribute information includes at least one of storage type, storage capacity, and encryption information.

[0213] In some feasible implementations, the generation module 302 includes:

[0214] The mapping unit 3024 is used to call the configuration template corresponding to the target cloud resources based on the target cloud platform, and map the attribute information and the topological relationship between resources to the configuration template to generate the target configuration file;

[0215] The generation unit 3025 is used to obtain the business logic contained in the target configuration file and generate at least one IaC file corresponding to the target configuration file according to the business logic, wherein the business logic includes at least one of judgment and loop.

[0216] In some feasible implementations, the mapping unit 3024 is also used to locate the parameter variables contained in the attribute information and resource topology relationship from the configuration template based on the attribute information and resource topology relationship, and to assign values ​​to the parameter variables based on the attribute information and resource topology relationship.

[0217] In some feasible implementations, the above-mentioned topological relationship between resources includes resource dependencies, which are used to specify the deployment order of the target cloud resources; the above-mentioned deployment module 303 is also used to obtain parallel dependencies from the resource dependencies and execute at least one IaC file to deploy the target cloud resources according to the parallel dependencies.

[0218] It should be noted that the examples and application scenarios implemented by the above modules and corresponding steps are the same, but are not limited to the content disclosed in the above method embodiments. It should also be noted that the above modules, as part of the cloud resource configuration device 30, can be executed in a computer system such as a set of computer-executable instructions.

[0219] In the embodiments of this application, the above Figure 5 The modules in the cloud resource configuration device 30 shown can be individually or entirely merged into one or more other modules, or some of the modules can be further divided into multiple functionally smaller modules. This achieves the same operation without affecting the technical effects of the embodiments of this application. The above modules are based on logical function division. In practical applications, the function of one module can be implemented by multiple modules, or the function of multiple modules can be implemented by one module. In other feasible implementations of this application, the cloud resource configuration device 30 may also include other modules. In practical applications, these functions can also be implemented with the assistance of other modules, and can be implemented collaboratively by multiple modules. No restrictions are placed here.

[0220] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of the computer device provided in an embodiment of this application. Figure 6 As shown, the computer device 40 may include at least one processor 400, at least one memory 401, and at least one network interface 402. The computer device 40 may also include at least one communication bus 403 and at least one transceiver 404. The communication bus 403 is used to enable communication between these components. The processor 400, at least one memory 401, and at least one network interface 402 can communicate with each other via the communication bus 403. The communication bus 403 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus 403 may be divided into an address bus, a data bus, a control bus, etc.

[0221] The processor 400 is used to execute computer programs, which may employ instruction sets based on architectures such as x86, Arm, RISC, MIPS, and SSE. The processor 400 can be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it can also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0222] The memory 401 may include RAM or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory 401 may also be at least one storage device located remotely from the aforementioned processor 400.

[0223] like Figure 6 As shown, the memory 401, which is a computer storage medium, may include an operating system 4010, a network communication module 4011, a user interface module 4012, and a device control application program 4013.

[0224] exist Figure 6 In the computer device 40 shown, the network interface 402 provides network communication functionality; while the transceiver 404 and processor 400 can be used to call the device control application stored in the memory 401 for application. Figure 1 Any terminal device in the terminal cluster 20 shown can be used to achieve:

[0225] Obtain the script to be processed, which is described using a domain-specific language (DSL). The script to be processed contains statements that describe the resource configuration information and topological relationships between the resources corresponding to the target cloud resources.

[0226] The script to be processed is parsed to obtain the resource configuration information and topological relationship between the target cloud resources, and a target configuration file is generated based on the resource configuration information and topological relationship between the resources. At least one infrastructure code (IaC) file is generated based on the target configuration file.

[0227] Execute at least one IaC file to complete the automated deployment of the target cloud resources.

[0228] It should be understood that the computer device 40 described in the embodiments of this application can perform the foregoing... Figure 2 The description of the cloud resource configuration method in the corresponding embodiments can also be executed as described above. Figure 5 The description of the cloud resource configuration device in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0229] Furthermore, it should be noted that this application embodiment also provides a computer-readable storage medium, which stores a computer program executed by the cloud resource configuration device mentioned above. When the processor executes the computer program, it can execute the aforementioned... Figure 2 The description of the cloud resource configuration method in the corresponding embodiments is already provided, and therefore will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated.

[0230] More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, RAM, ROM, erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0231] For technical details not disclosed in the embodiments of the computer-readable storage medium involved in this application, please refer to the description of the method embodiments of this application. As an example, a computer program may be deployed and executed on a computer device, or executed on multiple computer devices located in one location, or executed on multiple computer devices distributed in multiple locations and interconnected through a communication network. Multiple computer devices distributed in multiple locations and interconnected through a communication network can form a communication system.

[0232] Furthermore, it should be noted that this application also provides a computer program product, which may include a computer program that can be stored in a computer-readable storage medium. The processor of a computer device reads the computer program from the computer-readable storage medium, and the processor can execute the computer program, enabling the computer device to execute the aforementioned... Figure 2 The description of the cloud resource configuration method in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated. For technical details not disclosed in the computer program product embodiments related to this application, please refer to the description of the method embodiments of this application.

[0233] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The storage medium can be a magnetic disk, optical disk, ROM, or RAM, etc.

[0234] The term "comprising," and any variations thereof, in the specification, claims, and drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, apparatus, product, or device that includes a series of steps or units is not limited to the steps or modules listed, but may optionally include steps or modules not listed, or may optionally include other steps or units inherent to such processes, methods, apparatus, products, or devices.

[0235] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this application.

[0236] The methods and related apparatus provided in this application are described with reference to the method flowcharts and / or structural diagrams provided in this application. Specifically, each block of the method flowcharts and / or structural diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, can be implemented by a computer program. These computer program instructions are provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing device to create a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing device, generate instructions for implementing the process. Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1 The computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 A schematic diagram of one or more processes and / or structures. Figure 1The functions specified in one or more boxes. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable apparatus for implementing the process. Figure 1 A process or multiple processes and / or structures illustrate the steps of the functions specified in one or more boxes.

[0237] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A method for configuring cloud resources, characterized in that, The method includes: Obtain the script to be processed described using a domain-specific language (DSL); the script to be processed contains statements describing resource configuration information and topological relationships between resources corresponding to the target cloud resources; The script to be processed is parsed to obtain the resource configuration information and the topological relationship between the resources corresponding to the target cloud resource. The configuration template corresponding to the target cloud resource is called to map the resource configuration information and the topological relationship between the resources into the configuration template to generate a target configuration file. The business logic contained in the target configuration file is obtained, and at least one IaC file corresponding to the target configuration file is generated according to the business logic. The business logic includes at least one of judgment and loop. When there are two sets of business logic, there are at least two IaC files. Execute at least one IaC file to complete the automated deployment of the target cloud resource.

2. The method according to claim 1, characterized in that, The step of parsing the script to be processed to obtain the resource configuration information and the topological relationship between the resources corresponding to the target cloud resources includes: A tag sequence is obtained based on the script to be processed, and an abstract syntax tree corresponding to the script to be processed is constructed based on the tag sequence; the abstract syntax tree is a tree-like representation of the abstract syntax structure of the corresponding script to be processed. The resource configuration information and the topological relationships between resources are obtained based on the abstract syntax tree.

3. The method according to claim 2, characterized in that, The resource configuration information includes a resource type identifier and attribute information associated with the resource type identifier; after obtaining the tag sequence based on the script to be processed and constructing an abstract syntax tree corresponding to the script to be processed based on the tag sequence, the method further includes: The abstract syntax tree is validated, and if the validation is successful, the target cloud resource and the target cloud platform matching the target cloud resource are determined according to the resource type identifier. The target cloud platform is used to call the configuration template corresponding to the target cloud resource. The resource type identifier is used to indicate the resource type of the target cloud resource and the target cloud platform corresponding to the target cloud resource. The target cloud resource includes computing resources, network resources, or storage resources.

4. The method according to claim 3, characterized in that, When the target cloud resource includes the computing resource, the attribute information includes at least one of instance specification, image identifier, and security group rules; when the target cloud resource includes the network resource, the attribute information includes at least one of address and domain name resolution information; when the target cloud resource includes the storage resource, the attribute information includes at least one of storage type, storage capacity, and encryption information.

5. The method according to claim 4, characterized in that, The step of mapping the resource configuration information and the topological relationship between resources to the configuration template includes: Based on the attribute information and the topological relationship between resources, the parameter variables contained in the attribute information and the topological relationship between resources are located from the configuration template, and values ​​are assigned to the parameter variables based on the attribute information and the topological relationship between resources.

6. The method according to claim 5, characterized in that, The resource topology includes resource dependencies, which specify the deployment order of the target cloud resources; executing the at least one IaC file to complete the automated deployment of the target cloud resources includes: Obtain parallel dependencies from the resource dependencies, and deploy the target cloud resources by executing the at least one IaC file according to the parallel dependencies.

7. A cloud resource configuration device, characterized in that, The device includes: The acquisition module is used to acquire the script to be processed described using DSL; the script to be processed contains statements describing the resource configuration information and the topological relationship between resources corresponding to the target cloud resources; The generation module is used to parse the script to be processed to obtain the resource configuration information and the topological relationship between the resources corresponding to the target cloud resources, and generate a target configuration file based on the resource configuration information and the topological relationship between the resources, and generate at least one infrastructure code (IaC) file based on the target configuration file; The deployment module is used to execute the at least one IaC file to complete the automated deployment of the target cloud resources; The generation module further includes: The mapping unit is used to call the configuration template corresponding to the target cloud resource based on the target cloud platform, and map the resource configuration information and the topological relationship between the resources to the configuration template to generate the target configuration file; The generation unit is used to obtain the business logic contained in the target configuration file and generate at least one IaC file corresponding to the target configuration file according to the business logic. The business logic includes at least one of judgment and loop. When there are two sets of business logic, there are at least two IaC files.

8. The apparatus according to claim 7, characterized in that, The generation module includes: The processing unit is configured to obtain a tag sequence based on the script to be processed, and construct an abstract syntax tree corresponding to the script to be processed based on the tag sequence; the abstract syntax tree is a tree-like representation of the abstract syntax structure of the corresponding script to be processed. The acquisition unit is used to obtain the resource configuration information and the topological relationship between the resources based on the abstract syntax tree.

9. The apparatus according to claim 8, characterized in that, The resource configuration information includes a resource type identifier and attribute information associated with the resource type identifier; the generation module further includes: The verification unit is used to verify the abstract syntax tree, and when the verification is successful, to determine the target cloud resource and the target cloud platform matching the target cloud resource according to the resource type identifier; the target cloud platform is used to call the configuration template corresponding to the target cloud resource; The resource type identifier is used to indicate the resource type of the target cloud resource and the target cloud platform corresponding to the target cloud resource. The target cloud resource includes computing resources, network resources, or storage resources.

10. The apparatus according to claim 9, characterized in that, When the target cloud resource includes the computing resource, the attribute information includes at least one of instance specification, image identifier, and security group rules; when the target cloud resource includes the network resource, the attribute information includes at least one of address and domain name resolution information; when the target cloud resource includes the storage resource, the attribute information includes at least one of storage type, storage capacity, and encryption information.

11. A computer device, characterized in that, It includes a memory and a processor; the memory is used to store a computer program, and the processor is used to execute the computer program to implement the method as described in any one of claims 1 to 6.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 6.

Images