Cloud-native network element automation delivery method, system, device, equipment and medium

Abstract

The embodiment of the disclosure provides a cloud native network element automatic delivery method, system, device, equipment and medium, which relates to the field of emerging information technology. The technical scheme of the embodiment of the disclosure comprises: a scheduling framework receives each target deployment task sent by a delivery platform, wherein each target deployment task is used to request execution of one of deployment processes for deploying a cloud native network element. Then, the scheduling framework finds a target SDK corresponding to each target deployment task based on a preset correspondence relationship between the deployment task and the software development kit (SDK), and calls the target SDK to trigger the target SDK to execute the deployment process. Each SDK is used to execute one of the deployment processes for deploying the cloud native network element. Thus, the development and maintenance difficulty of the delivery platform is reduced.

Description

Technical Field

[0001] This disclosure relates to the field of emerging information technology, and in particular to a method, system, device, equipment and medium for automated delivery of cloud-native network elements. Background Technology

[0002] Cloud-native network elements are deployed in the infrastructure. By using an automated delivery platform to automate the delivery of cloud-native network elements, the delivery process can be simplified.

[0003] Currently, automated delivery platforms involve multiple deployment processes when deploying cloud-native network elements. Each deployment process requires the use of deployment tools, but different deployment tools have significantly different implementation and invocation methods. Therefore, it is necessary to develop deployment plugins adapted to specific deployment tools to achieve interface between the delivery platform and the deployment tools. However, the capabilities provided by the deployment tools themselves are insufficient to complete a single deployment process, necessitating the configuration of deployment steps within the delivery platform to complement these tools. Because the delivery platform needs to simultaneously control multiple deployment processes and implement the deployment steps within each process, its development and maintenance are highly complex. Summary of the Invention

[0004] The purpose of this disclosure is to provide a method, system, apparatus, device, and medium for automated delivery of cloud-native network elements, thereby reducing the development and dimensional complexity of the delivery platform. The specific technical solution is as follows:

[0005] In a first aspect, embodiments of this disclosure provide a cloud-native network element automated delivery method, applied to a scheduling framework, the method comprising:

[0006] Each target deployment task is sent by the delivery platform and is used to request the execution of one of the deployment processes for deploying cloud-native network elements.

[0007] For each target deployment task, based on the preset correspondence between deployment tasks and software development kits (SDKs), the target SDK corresponding to the target deployment task is found, and the target SDK is invoked to trigger the target SDK to execute the deployment process; wherein, each SDK is used to execute one of the deployment processes for deploying cloud-native network elements.

[0008] In some embodiments of this disclosure, the step of invoking the target SDK to trigger the target SDK to execute the deployment process includes:

[0009] The target SDK's preparation and deployment interface is invoked, triggering the target SDK to perform preparatory work before executing the target deployment process;

[0010] Receive the preparation completion information returned by the target SDK, the preparation completion information indicating that the preparation work has been completed;

[0011] The execution deployment interface of the target SDK is invoked to trigger the target SDK to execute the target deployment process;

[0012] Receive deployment completion information returned by the target SDK, which indicates that the target deployment process has been completed.

[0013] In some embodiments of this disclosure, after receiving deployment completion information returned by the target SDK, the method further includes:

[0014] The configuration and inspection interface of the target SDK is invoked, triggering the target SDK to check the execution result of the target deployment process;

[0015] Receive the check completion information returned by the target SDK, which indicates that the configuration and check of the target deployment process have been completed.

[0016] In some embodiments of this disclosure, the target SDK is a first SDK for installing an operating system or computing virtualization; the step of calling the target SDK's preparation deployment interface to trigger the target SDK to process preparatory work before executing the target deployment process includes:

[0017] The first SDK is called to send operating system configuration parameters to the first SDK via the preparation deployment interface. This triggers the first SDK to call the ipmitool plugin to enable the pre-boot execution environment PXE mode of the specified server, and calls the cobbler plugin to write the operating system configuration parameters into the cobbler tool. The operating system configuration parameters are the configuration parameters required to install the operating system on the specified server where the cloud-native network element is located.

[0018] The step of calling the execution deployment interface of the target SDK to trigger the target SDK to execute the target deployment process includes:

[0019] The execution deployment interface of the first SDK is invoked, triggering the first SDK to call the ipmitool plugin to restart the specified server;

[0020] The step of calling the configuration and inspection interface of the target SDK to trigger the target SDK to check the execution result of the target deployment process includes:

[0021] The configuration and inspection interface of the first SDK is invoked, triggering the first SDK to perform a configuration check on the specified server.

[0022] In some embodiments of this disclosure, the target SDK is a second SDK for installing OpenStack; the step of calling the target SDK's preparation deployment interface to trigger the target SDK to perform preparatory work before executing the target deployment process includes:

[0023] The second SDK's deployment preparation interface is invoked to send OpenStack configuration parameters to the second SDK, triggering the second SDK to call the kolla-ansible plugin to write the OpenStack configuration parameters into the specified configuration file of kolla-ansible; wherein, the OpenStack configuration parameters are the configuration parameters required to deploy OpenStack on the specified server where the cloud-native network element is located;

[0024] The step of calling the execution deployment interface of the target SDK to trigger the target SDK to execute the target deployment process includes:

[0025] The second SDK's execution deployment interface is invoked, triggering the second SDK to call the kolla-ansible plugin to clean up the containers in the specified server, pull the specified containers for the specified server, and deploy OpenStack in the specified server;

[0026] The step of calling the configuration and inspection interface of the target SDK to trigger the target SDK to check the execution result of the target deployment process includes:

[0027] The configuration and inspection interface of the second SDK is invoked, which triggers the second SDK to call the kolla-ansible plugin to verify the deployed OpenStack.

[0028] In some embodiments of this disclosure, the target SDK is a third SDK for deploying Kubernetes; the step of calling the target SDK's preparation deployment interface to trigger the target SDK to perform preparatory work before executing the target deployment process includes:

[0029] The third SDK's deployment preparation interface is invoked to send Kubernetes deployment parameters to the third SDK, triggering the third SDK to call the OpenStack interface. Based on the Kubernetes deployment parameters, a virtual machine is started on a specified server, and a container is deployed in the virtual machine. The virtual machine is used to host Kubernetes, and the Kubernetes deployment parameters are the configuration parameters required to deploy Kubernetes in the virtual machine.

[0030] The step of calling the execution deployment interface of the target SDK to trigger the target SDK to execute the target deployment process includes:

[0031] The third SDK's execution deployment interface is invoked to trigger the deployment of the kubelet and kubectl components by the third SDK, and the kubelet component is invoked to deploy the Kubernetes Master node in the virtual machine, or the kubelet component is invoked to add the virtual machine to the Kubernetes Worker node;

[0032] The step of calling the configuration and inspection interface of the target SDK to trigger the target SDK to check the execution result of the target deployment process includes:

[0033] The configuration and inspection interface of the third SDK is invoked, which triggers the third SDK to call the kubectl component to check whether Kubernetes in the virtual machine is working properly.

[0034] In some embodiments of this disclosure, the target SDK is a fourth SDK used to launch cloud-native network elements; the step of calling the target SDK's preparation deployment interface to trigger the target SDK to process preparatory work before executing the target deployment process includes:

[0035] The fourth SDK's deployment preparation interface is invoked to send vector packets to the fourth SDK to process the VPP's startup configuration parameters, triggering the fourth SDK to write the startup configuration parameters into the VPP's startup script. The VPP is used to carry cloud-native network elements, and the startup configuration parameters are the configuration parameters required to start the VPP in the virtual machine where the cloud-native network element is located.

[0036] The step of calling the execution deployment interface of the target SDK to trigger the target SDK to execute the target deployment process includes:

[0037] The fourth SDK's execution deployment interface is invoked to trigger the fourth SDK to start a specified number of containers in the Kubernetes deployed in the virtual machine running on the specified server according to the startup configuration parameters, and to invoke Ligato according to the startup configuration parameters so that Ligato can configure the VPP;

[0038] The step of calling the configuration and inspection interface of the target SDK to trigger the target SDK to check the execution result of the target deployment process includes:

[0039] The configuration and inspection interface of the fourth SDK is invoked, which triggers the fourth SDK to call the preparation interface of Ligato to check whether vpp and Ligato are working properly.

[0040] In some embodiments of this disclosure, after finding the target SDK corresponding to the target deployment task, the method further includes: starting the target SDK;

[0041] After invoking the target SDK to trigger the deployment process of the target SDK, the method further includes:

[0042] Obtain the processing logs of the target SDK;

[0043] Based on the processing logs, check whether the target SDK has executed errors;

[0044] If an error is detected in the target SDK, stop the target SDK.

[0045] In some embodiments of this disclosure, after invoking the target SDK to trigger the target SDK to execute the deployment process, the method further includes:

[0046] Obtain the processing logs of the target SDK to get the processing progress of the target SDK for the target deployment process;

[0047] The processing progress of the target deployment process is sent to the delivery platform so that the delivery platform can display the processing progress of the target deployment process.

[0048] Secondly, this disclosure provides a cloud-native network element automated delivery method, applied to a delivery platform, the method comprising:

[0049] Receive deployment requests submitted by users, the deployment requests being used to request the deployment of cloud-native network elements;

[0050] Determine the deployment process for each target included in deploying the cloud-native network element;

[0051] For each target deployment process, a target deployment task is sent to the scheduling framework to request the execution of the target deployment process. This allows the scheduling framework to find the target SDK corresponding to each target deployment task based on the preset correspondence between deployment tasks and software development kits (SDKs), and to call each target SDK. Each SDK is used to execute one of the deployment processes for deploying cloud-native network elements.

[0052] Thirdly, this disclosure provides a cloud-native network element automated delivery system, the system comprising:

[0053] A delivery platform for performing the method described in the second aspect;

[0054] A scheduling framework for executing the methods described in any of the first aspects.

[0055] Fourthly, this disclosure provides a cloud-native network element automated delivery device applied to a scheduling framework, the device comprising:

[0056] The receiving module is used to receive each target deployment task sent by the delivery platform. Each target deployment task is used to request the execution of one of the deployment processes for deploying cloud-native network elements.

[0057] The calling module is used to find the target SDK corresponding to each target deployment task received by the receiving module based on the preset correspondence between the deployment task and the software development kit (SDK), and call the target SDK to trigger the target SDK to execute the deployment process; wherein, each SDK is used to execute one of the deployment processes for deploying cloud-native network elements.

[0058] In some embodiments of this disclosure, the calling module is specifically used for:

[0059] The target SDK's preparation and deployment interface is invoked, triggering the target SDK to perform preparatory work before executing the target deployment process;

[0060] Receive the preparation completion information returned by the target SDK, the preparation completion information indicating that the preparation work has been completed;

[0061] The execution deployment interface of the target SDK is invoked to trigger the target SDK to execute the target deployment process;

[0062] Receive deployment completion information returned by the target SDK, which indicates that the target deployment process has been completed.

[0063] In some embodiments of this disclosure, the calling module is further configured to:

[0064] After receiving the deployment completion information returned by the target SDK, the configuration and inspection interface of the target SDK is called to trigger the target SDK to check the execution result of the target deployment process;

[0065] Receive the check completion information returned by the target SDK, which indicates that the configuration and check of the target deployment process have been completed.

[0066] In some embodiments of this disclosure, the target SDK is a first SDK for installing an operating system or computing virtualization, and the calling module is specifically used for:

[0067] The first SDK is called to send operating system configuration parameters to the first SDK via the preparation deployment interface. This triggers the first SDK to call the ipmitool plugin to enable the pre-boot execution environment PXE mode of the specified server, and calls the cobbler plugin to write the operating system configuration parameters into the cobbler tool. The operating system configuration parameters are the configuration parameters required to install the operating system on the specified server where the cloud-native network element is located.

[0068] The execution deployment interface of the first SDK is invoked, triggering the first SDK to call the ipmitool plugin to restart the specified server;

[0069] The configuration and inspection interface of the first SDK is invoked, triggering the first SDK to perform a configuration check on the specified server.

[0070] In some embodiments of this disclosure, the target SDK is a second SDK for installing OpenStack, and the calling module is specifically used for:

[0071] The second SDK's deployment preparation interface is invoked to send OpenStack configuration parameters to the second SDK, triggering the second SDK to call the kolla-ansible plugin to write the OpenStack configuration parameters into the specified configuration file of kolla-ansible; wherein, the OpenStack configuration parameters are the configuration parameters required to deploy OpenStack on the specified server where the cloud-native network element is located;

[0072] The second SDK's execution deployment interface is invoked, triggering the second SDK to call the kolla-ansible plugin to clean up the containers in the specified server, pull the specified containers for the specified server, and deploy OpenStack in the specified server;

[0073] The configuration and inspection interface of the second SDK is invoked, which triggers the second SDK to call the kolla-ansible plugin to verify the deployed OpenStack.

[0074] In some embodiments of this disclosure, the target SDK is a third SDK for deploying Kubernetes; the calling module is specifically used for:

[0075] The third SDK's deployment preparation interface is invoked to send Kubernetes deployment parameters to the third SDK, triggering the third SDK to call the OpenStack interface. Based on the Kubernetes deployment parameters, a virtual machine is started on a specified server, and a container is deployed in the virtual machine. The virtual machine is used to host Kubernetes, and the Kubernetes deployment parameters are the configuration parameters required to deploy Kubernetes in the virtual machine.

[0076] The third SDK's execution deployment interface is invoked to trigger the deployment of the kubelet and kubectl components by the third SDK, and the kubelet component is invoked to deploy the Kubernetes Master node in the virtual machine, or the kubelet component is invoked to add the virtual machine to the Kubernetes Worker node;

[0077] The configuration and inspection interface of the third SDK is invoked, which triggers the third SDK to call the kubectl component to check whether Kubernetes in the virtual machine is working properly.

[0078] In some embodiments of this disclosure, the target SDK is a fourth SDK for launching cloud-native network elements; the calling module is specifically used for:

[0079] The fourth SDK's deployment preparation interface is invoked to send vector packets to the fourth SDK to process the VPP's startup configuration parameters, triggering the fourth SDK to write the startup configuration parameters into the VPP's startup script. The VPP is used to carry cloud-native network elements, and the startup configuration parameters are the configuration parameters required to start the VPP in the virtual machine where the cloud-native network element is located.

[0080] The fourth SDK's execution deployment interface is invoked to trigger the fourth SDK to start a specified number of containers in the Kubernetes deployed in the virtual machine running on the specified server according to the startup configuration parameters, and to invoke Ligato according to the startup configuration parameters so that Ligato can configure the VPP;

[0081] The configuration and inspection interface of the fourth SDK is invoked, which triggers the fourth SDK to call the preparation interface of Ligato to check whether vpp and Ligato are working properly.

[0082] In some embodiments of this disclosure, the apparatus further includes:

[0083] The startup module is used to start the target SDK after the target SDK corresponding to the target deployment task is found;

[0084] The acquisition module is used to acquire the processing logs of the target SDK after the target SDK is invoked to trigger the deployment process of the target SDK;

[0085] The inspection module is used to check whether the target SDK has executed errors based on the processing logs;

[0086] The stop module is used to stop the target SDK if an execution error is detected.

[0087] In some embodiments of this disclosure, the apparatus further includes:

[0088] The acquisition module is used to acquire the processing log of the target SDK after the target SDK is called to trigger the target SDK to execute the deployment process, and to obtain the processing progress of the target SDK on the target deployment process;

[0089] The sending module is used to send the processing progress of the target deployment process to the delivery platform, so that the delivery platform can display the processing progress of the target deployment process.

[0090] Fifthly, this disclosure provides a cloud-native network element automated delivery device, applied to a delivery platform, the device comprising:

[0091] The receiving module is used to receive deployment requests submitted by users, the deployment requests being used to request the deployment of cloud-native network elements;

[0092] The determination module is used to determine each target deployment process included in deploying the cloud-native network element;

[0093] The sending module is used to send a target deployment task to the scheduling framework for each target deployment process determined by the determining module, requesting the execution of the target deployment process. This allows the scheduling framework to find the target SDK corresponding to each target deployment task based on the preset correspondence between deployment tasks and software development kits (SDKs), and to call each target SDK. Each SDK is used to execute one of the deployment processes for deploying cloud-native network elements.

[0094] In a sixth aspect, embodiments of this disclosure provide an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus;

[0095] Memory, used to store computer programs;

[0096] When a processor executes a program stored in memory, it implements the steps of the cloud-native network element automated delivery method as described in either the first or second aspect.

[0097] In a seventh aspect, embodiments of this disclosure provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the cloud-native network element automated delivery method as described in either the first or second aspect.

[0098] Eighthly, embodiments of this disclosure also provide a computer program product containing instructions that, when run on a computer, cause the computer to execute the cloud-native network element automated delivery method described in either the first or second aspect.

[0099] Beneficial effects of the embodiments disclosed herein:

[0100] The cloud-native network element automated delivery method, system, apparatus, device, and medium provided in this disclosure involve a delivery platform issuing target deployment tasks to a scheduling framework. Each target deployment task requests the execution of one of the target deployment processes for deploying a cloud-native network element. Subsequently, the scheduling framework, based on a preset correspondence between multiple deployment tasks and SDKs, locates the target SDK corresponding to each target deployment task and invokes each target SDK to execute a target deployment process. Since each deployment process is executed by one SDK, the delivery platform does not need to consider the specific execution process of each deployment process, thus reducing the development and dimensionality complexity of the delivery platform.

[0101] Of course, implementing any product or method of this disclosure does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

[0102] To more clearly illustrate the technical solutions in the embodiments of this disclosure or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other embodiments can be obtained based on these accompanying drawings.

[0103] Figure 1 This is an exemplary schematic diagram illustrating the automated delivery process of cloud-native network elements in related technologies;

[0104] Figure 2 This is a schematic diagram of the structure of a cloud-native network element automated delivery system provided in an embodiment of the present disclosure;

[0105] Figure 3 A flowchart of a cloud-native network element automated delivery method provided in this disclosure embodiment;

[0106] Figure 4 A flowchart of another cloud-native network element automated delivery method provided in this disclosure embodiment;

[0107] Figure 5 This is an exemplary schematic diagram illustrating the interaction process between a scheduling framework and an SDK provided in an embodiment of this disclosure.

[0108] Figure 6 A schematic diagram of another cloud-native network element automated delivery system provided in this embodiment of the disclosure;

[0109] Figure 7 A flowchart of another cloud-native network element automated delivery method provided in this disclosure embodiment;

[0110] Figure 8 This is a schematic diagram of the structure of a cloud-native network element automated delivery device provided in an embodiment of the present disclosure;

[0111] Figure 9 A schematic diagram of another cloud-native network element automated delivery device provided in this embodiment of the disclosure;

[0112] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0113] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those skilled in the art based on this disclosure are within the scope of protection of this disclosure.

[0114] See Figure 1 In typical cloud-native network element delivery scenarios, automated delivery platforms need to use deployment tools to deploy cloud-native network elements. Each deployment tool requires calling its corresponding plugin through the tool access layer. These deployment tools include: cobbler, Ligato, rancher, ipmitool, and kolla-ansible. Correspondingly, the plugins for these tools include: cobbler plugin, Ligato plugin, rancher plugin, ipmitool plugin, and kolla-ansible plugin.

[0115] Among them, Cobbler is a tool for quickly setting up network installation environments. Ligato is a control plane management system based on the vector packet processor (VPP). Rancher is a management tool for Kubernetes, which manages containerized applications across multiple hosts in a cloud platform. ipmitool is an Intelligent Platform Management Interface (IPMI) management tool; kolla-ansible is a deployment tool for OpenStack, a cloud computing management tool.

[0116] In the conventional deployment of cloud-native network elements, besides necessary physical environment configurations such as powering on physical machines, the configuration process involves multiple steps, including installing the operating system and starting virtual machines. However, the capabilities provided by the deployment tools themselves are insufficient to complete a deployment process. A deployment process may require the use of multiple deployment tools, necessitating the configuration of deployment steps in the delivery platform to complement these tools. Because the delivery platform needs to simultaneously consider the control of multiple deployment processes and the implementation of deployment steps within each process, the coupling between process control and step control within the delivery platform is high, resulting in poor scalability and significantly increasing the difficulty of developing and maintaining the delivery platform.

[0117] To reduce the development and complexity of the delivery platform, this disclosure provides an automated delivery method for cloud-native network elements. This method is applied to a cloud-native network element automated delivery system, such as... Figure 2 As shown, the system includes a delivery platform 201 and a scheduling framework 202.

[0118] Delivery platform 201 is used to issue deployment tasks to scheduling framework 202.

[0119] The scheduling framework 202 is used to invoke the Software Development Kit (SDK) to complete the deployment task.

[0120] Combination Figure 2 The cloud-native network element automated delivery method provided in this disclosure is applied to... Figure 2 The scheduling framework in, such as Figure 3 As shown, the method includes the following steps:

[0121] S301: Receive each target deployment task sent by the delivery platform.

[0122] Each target deployment task requests the execution of one of the target deployment processes for deploying cloud-native network elements. For example, the deployment process for deploying cloud-native network elements includes: 1. Installing an operating system or computing virtualization; 2. Installing OpenStack and starting a virtual machine; 3. Deploying Kubernetes in the virtual machine; 4. Starting the cloud-native network element service in Kubernetes.

[0123] In this embodiment of the disclosure, for the overall process of deploying cloud-native network elements, which includes various target deployment processes, the delivery platform can send the target deployment task corresponding to the first target deployment process to the scheduling framework in the order of the target deployment processes. After the scheduling framework determines that the target deployment task has been completed, it notifies the delivery platform that the execution is complete. Then, the delivery platform sends the target deployment task corresponding to the next target deployment process to the scheduling framework, until all target deployment processes are completed, so as to ensure that the target deployment processes can be executed in sequence.

[0124] If there are multiple target deployment processes that can be executed in parallel, the delivery platform can send the target deployment tasks corresponding to each of these multiple target deployment processes to the scheduling framework at the same time, so that the scheduling framework can process these multiple target deployment processes simultaneously, thereby improving the efficiency of deploying cloud-native network elements.

[0125] The target deployment task issued by the delivery platform to the scheduling framework may also include the address of the specified server where the cloud-native network element to be deployed is located, so that the scheduling framework can send the address to the target SDK to deploy the cloud-native network element on the specified server.

[0126] S302. For each target deployment task, based on the preset correspondence between deployment tasks and software development kits (SDKs), find the target SDK corresponding to the target deployment task.

[0127] The scheduling framework can be configured with an SDK corresponding to each deployment task, and the deployment task can be represented by a task identity document (ID). For example, the task ID can be 001 or 002.

[0128] Each SDK is used to execute one of the deployment processes for deploying cloud-native network elements. When executing the deployment process, the SDK can use the deployment tool to perform the deployment by calling the corresponding plugin. The SDK can also be configured with deployment steps that are paired with the deployment tool.

[0129] S303. Call the target SDK to trigger the target SDK to execute the deployment process.

[0130] The cloud-native network element automated delivery method provided in this disclosure involves a delivery platform issuing target deployment tasks to a scheduling framework. Each target deployment task requests the execution of one of the target deployment processes for deploying a cloud-native network element. Subsequently, the scheduling framework, based on a pre-defined correspondence between multiple deployment tasks and SDKs, locates the target SDK corresponding to each target deployment task and invokes each target SDK to execute a target deployment process. Since each deployment process is executed by a single SDK, the delivery platform does not need to consider the specific execution process of each deployment process, thus reducing the development and dimensional complexity of the delivery platform.

[0131] In some embodiments of this disclosure, each SDK can provide a callable interface, and the scheduling framework can trigger the SDK to execute the deployment process by calling the SDK's interface.

[0132] See Figure 4 The method by which the scheduling framework in S303 above calls the target SDK to trigger the target SDK to execute the deployment process can be implemented as follows:

[0133] S3031. Call the target SDK's preparation and deployment interface to trigger the target SDK to perform preparatory work before executing the target deployment process.

[0134] Optionally, when calling the deployment preparation interface, the scheduling framework can also send relevant parameters required for the preparation work to the target SDK through the deployment preparation interface.

[0135] S3032. Receive the preparation completion information returned by the target SDK. The preparation completion information indicates that the preparation work has been completed.

[0136] After completing the preparatory work before executing the target deployment process, the target SDK returns a preparation completion message to the scheduling framework to notify the scheduling framework that the preparation work is complete.

[0137] S3033. Call the target SDK's execution deployment interface to trigger the target SDK to execute the target deployment process.

[0138] Optionally, when calling the execution deployment interface, the scheduling framework can also send relevant parameters required to execute the target deployment process to the target SDK through the execution deployment interface.

[0139] S3034. Receive deployment completion information returned by the target SDK. The deployment completion information indicates that the target deployment process has been completed.

[0140] After completing the target deployment process, the target SDK returns deployment completion information to the scheduling framework to notify the scheduling framework that the target deployment process is complete.

[0141] In addition to providing deployment preparation and execution interfaces, each SDK can also provide configuration and inspection interfaces. These interfaces allow the scheduling framework to perform supplementary configuration and inspect the execution results of the target deployment process. See also Figure 4 Following S3034 above, the scheduling framework can also perform the following steps:

[0142] S3035. Call the configuration and inspection interface of the target SDK to trigger the target SDK to check the execution result of the target deployment process.

[0143] Optionally, when calling the configuration and inspection interfaces, the scheduling framework can also send relevant parameters required for supplementary configuration and verification to the target SDK through the configuration and inspection interfaces. The relevant parameters sent by the scheduling framework to the target SDK in S3031, S3033, and S3035 can be obtained from the deployment tasks issued by the delivery platform. The delivery platform can obtain these relevant parameters from the deployment requests submitted by users, or obtain the default relevant parameters, etc.

[0144] S3036. Receive the check completion information returned by the target SDK. The check completion information indicates that the configuration and check of the target deployment process have been completed.

[0145] After completing the configuration and checks, the target SDK returns a check completion message to the scheduling framework to notify the scheduling framework that it has completed the check on the execution result of the target deployment process.

[0146] In this embodiment of the disclosure, the scheduling framework declares a preparation deployment interface, an execution deployment interface, and a configuration and inspection interface for each SDK in order to handle the three stages of the target deployment process. If an error occurs in any stage, the interface of the next stage can be stopped, making the execution of the target deployment process more controllable.

[0147] The following section provides a detailed explanation of the three stages involved in configuring cloud-native network elements on a specified server for each deployment process:

[0148] For the first SDK used to install an operating system or virtualize computing:

[0149] During the deployment preparation phase, the first SDK's deployment preparation interface is called to send operating system configuration parameters to the first SDK. This prompts the first SDK to invoke the ipmitool plugin to enable the Preboot Execution Environment (PXE) mode on the specified server. Then, the first SDK invokes the cobbler plugin to write the operating system configuration parameters into the cobbler tool. These operating system configuration parameters are those required to install the operating system on the specified server where the cloud-native network element resides.

[0150] For example, operating system configuration parameters include: operating system name, Internet Protocol (IP) address, operating system username and password, and time zone.

[0151] When the first SDK is used to implement compute virtualization, the operating system configuration parameters may also include the configuration parameters required to implement compute virtualization.

[0152] During the deployment phase, the first SDK's deployment interface is called, triggering the first SDK to call the ipmitool plugin to use the ipmitool tool to restart the specified server.

[0153] During the configuration and inspection phase, the configuration and inspection interface of the first SDK is invoked, enabling the first SDK to perform configuration checks on the specified server. These configuration checks include performing additional configurations on the specified server, such as configuring the IP address of the network interface card on the specified server, and performing operating system configuration checks by logging into the specified server via Secure Shell (SSH).

[0154] For the second SDK used to install OpenStack:

[0155] During the deployment preparation phase, the deployment preparation interface of the second SDK is called to send OpenStack configuration parameters to the second SDK, which then calls the kolla-ansible plugin to write the OpenStack configuration parameters into the specified configuration file of kolla-ansible.

[0156] The OpenStack configuration parameters are the configuration parameters required to deploy OpenStack on the specified server where the cloud-native network element resides. For example, OpenStack configuration parameters include the OpenStack version, management IP, virtualization technology name, and whether to use external storage.

[0157] During the deployment phase, the second SDK's deployment interface is called, triggering the second SDK to call the kolla-ansible plugin to use kolla-ansible's destroy function to clean up containers that should not exist on the specified server, use kolla-ansible's pull function to pull the required specified containers for the specified server, and then use kolla-ansible's deploy function to deploy OpenStack on the specified server.

[0158] During the configuration and inspection phase, the configuration and inspection interface of this SDK is called, which triggers the second SDK to call the kolla-ansible plugin to use the kolla-ansible post-deploy function to verify the deployed OpenStack.

[0159] For third-party SDKs used to deploy Kubernetes:

[0160] During the deployment preparation phase, the deployment preparation interface of the third SDK is called to send Kubernetes deployment parameters to the third SDK. This triggers the third SDK to call the OpenStack interface, which then starts a virtual machine on the specified server based on the Kubernetes deployment parameters and deploys containers within the virtual machine. The virtual machine is used to host Kubernetes, and the Kubernetes deployment parameters are the configuration parameters required to deploy Kubernetes within the virtual machine.

[0161] During the deployment phase, the third SDK's deployment interface is called, triggering the deployment of the kubelet and kubectl components. Then, the kubelet component is called to use kubeadm init to deploy the Kubernetes Master node in the virtual machine, or the kubelet component is called to use kubeadm join to join the virtual machine to the Kubernetes Worker node.

[0162] During the configuration and inspection phase, the configuration and inspection interface of the third SDK is called, triggering the third SDK to call the kubectl component to use kubectl get nodes to check whether the Kubernetes in the virtual machine is working properly. kubectl is a command-line tool for Kubernetes.

[0163] For the fourth SDK used to launch cloud-native network element services:

[0164] During the deployment preparation phase, the deployment preparation interface of the fourth SDK is called to send the VPP startup configuration parameters to the fourth SDK, triggering the fourth SDK to write the VPP startup configuration parameters into the VPP startup script.

[0165] VPP is used to host cloud-native network elements, and its startup configuration parameters are the configuration parameters required to start VPP in the virtual machine where the cloud-native network element resides. For example, the startup configuration parameters include: VPP instance name, Peripheral Component Interconnect (PCI) address of the DataPlane Development Kit (DPDK) network card, and VPP plugins, etc.

[0166] During the deployment phase, the fourth SDK's deployment interface is invoked, triggering the fourth SDK to start a specified number of containers (Pods) in the Kubernetes environment running on the specified server, according to the startup configuration parameters. These Pods are used to host Ligato+VPP. For example, the specified number is 3. The fourth SDK then calls the Ligato interface according to the startup configuration parameters, allowing Ligato to automatically configure the VPP. This includes configuring the IP address of the VPP interface and the bridge to which the interface is connected.

[0167] During the configuration and inspection phase, the configuration and inspection interface of the fourth SDK is called, which triggers the fourth SDK to call the Ligato readiness interface. The data returned by this interface is used to check whether vpp and Ligato are working properly.

[0168] It should be noted that the above four SDKs are merely examples provided in this disclosure. The scheduling framework may also be configured with SDKs for executing other deployment processes, and this disclosure does not impose any specific limitations on this.

[0169] In traditional delivery platforms, it is necessary to configure the overall deployment process for each type of cloud-native network element separately. However, some deployment processes are common to different overall deployment processes, resulting in a large amount of redundant code in the delivery platform.

[0170] In this embodiment, the overall deployment process is broken down into various deployment steps, each implemented by a separate SDK. This achieves full decoupling between the deployment steps and reduces redundant code. The delivery platform does not need to concern itself with the implementation logic of each SDK, making it easy to iterate and update, and providing good scalability and maintainability, thereby improving the efficiency of deploying cloud-native network elements.

[0171] Moreover, since the deployment processes are decoupled from each other, the execution logic of each deployment process is developed and maintained by the corresponding SDK, which allows the development and maintenance of each SDK to focus on a single deployment process, thereby achieving standardized design.

[0172] In some embodiments of this disclosure, after finding the target SDK corresponding to the target deployment task in S302 above, the library calling framework can also start the target SDK by executing the target SDK's startup script.

[0173] Furthermore, after the S303 call to the target SDK triggers the deployment process, the scheduling framework can also obtain the target SDK's processing logs and check for execution errors based on these logs. If an execution error is detected, the target SDK is stopped by executing its stop script.

[0174] The target SDK's processing logs include deployment logs and environment monitoring logs. The deployment logs record every operation completed by the target SDK and the execution result of each operation, indicating whether each operation was successful. The environment monitoring logs include the target SDK's monitoring results of the deployed object's environment. For example, the environment monitoring logs include the number of virtual machines that can be connected normally.

[0175] Optionally, after stopping the target SDK, you can also restart the target SDK to re-execute the target deployment process.

[0176] In this embodiment, the scheduling framework monitors the target SDK's processing logs to track its handling of the target deployment process. Upon encountering an error, the framework promptly stops the target SDK's execution, preventing further errors and improving deployment efficiency. Furthermore, this embodiment enables monitoring and management of the SDK's execution process, making the deployment of cloud-native network elements more controllable.

[0177] In some embodiments of this disclosure, after the scheduling framework calls the target SDK in S303 to trigger the target SDK to execute the deployment process, it can also obtain the target SDK's processing logs to get the target SDK's processing progress for the target deployment process. Then, it sends the processing progress of the target deployment process to the delivery platform so that the delivery platform can display the processing progress of the target deployment process.

[0178] As described above, the processing log includes every operation completed by the target SDK. The scheduling framework can determine the processing progress of the target SDK based on all the required operations and the completed operations. This progress is then sent to the delivery platform so that users can view the deployment progress of the cloud-native network element through the platform.

[0179] See Figure 5 In this embodiment, the scheduling framework can implement SDK instance management, deployment process control, and progress monitoring functions. Each SDK can implement SDK runtime environment management, SDK deployment process implementation, and log recording functions.

[0180] The SDK instance management function includes registering, discovering, starting, and stopping the SDK.

[0181] SDK registration includes receiving the SDK and its configuration file, and storing the SDK's identifier along with the identifier of the deployment task executed by the SDK. SDK discovery involves finding the corresponding SDK using the deployment task identifier. SDK startup involves executing the SDK's startup script after the SDK is found. SDK shutdown involves executing the SDK's shutdown script after the overall deployment process has successfully completed or failed. Correspondingly, SDK runtime environment management includes starting and stopping the SDK.

[0182] The deployment process control function controls the three phases of each deployment process: preparation for deployment, execution of deployment, and configuration and inspection. In the preparation for deployment phase, the scheduling framework calls the SDK's preparation for deployment interface to enable the SDK to complete the deployment preparation work. In the execution of deployment phase, the scheduling framework calls the SDK's execution of deployment interface to enable the SDK to perform the deployment work. In the configuration and inspection phase, the scheduling framework calls the SDK's configuration and inspection interface to enable the SDK to complete supplementary configuration and inspection.

[0183] The progress monitoring function retrieves deployment logs and environment monitoring logs recorded by the SDK through its logging function. The deployment logs record the operations completed by the SDK, while the environment monitoring logs include the SDK's monitoring results of the deployed object's environment. The progress monitoring function also monitors the progress based on the retrieved logs, obtaining the SDK's processing progress and whether execution has failed. This ensures that SDK execution failures are detected promptly, allowing the deployment process control function to stop the SDK in a timely manner. The progress monitoring function can also send the monitored SDK processing progress to the delivery platform.

[0184] See Figure 6 The following describes the components of the cloud-native network element automated delivery system provided in this embodiment:

[0185] The delivery platform issues deployment tasks to the scheduling framework.

[0186] The scheduling framework enables SDK instance management, deployment process control, and progress monitoring. It also includes an SDK library, where SDKs are managed and scheduled uniformly. The SDK library contains SDKs developed for multiple scenarios, each executing a specific deployment process.

[0187] The SDK instance management function includes registering, discovering, starting, and stopping the SDK.

[0188] The deployment process control function is used to control the three stages of each deployment process.

[0189] The progress monitoring function is used to obtain the SDK's execution deployment logs and environment monitoring logs, and based on the obtained logs, it monitors the SDK's processing progress and whether execution has failed. This allows SDK execution failures to be detected in a timely manner, enabling the deployment process control function to stop the SDK promptly. The progress monitoring function can also send the monitored SDK processing progress to the delivery platform.

[0190] The SDK in the scheduling framework uses deployment tools to complete the deployment process, which requires the use of a tool access layer. The tool access layer includes a deployment tool plugin library and custom scripts for calling the deployment tools. The deployment tool plugin library includes plugins such as cobbler, Ligato, rancher, ipmitool, and kolla-ansible.

[0191] Correspondingly, various deployment tools include: cobbler, Ligato, rancher, ipmitool, and kolla-ansible, etc.

[0192] As can be seen, the scheduling framework includes a control layer and an implementation layer. The implementation layer, namely the SDK library, implements each deployment task, while the control layer implements the SDK instance management function, deployment process control function, and progress monitoring function, thereby achieving the separation of control and implementation and improving the maintainability of the scheduling framework.

[0193] Based on the same inventive concept, this disclosure also provides a cloud-native network element automated delivery method, which is applied to a delivery platform, such as... Figure 7 As shown, the method includes the following steps:

[0194] S701. Receive deployment requests submitted by users. These deployment requests are used to request the deployment of cloud-native network elements.

[0195] S702. Determine the deployment process for each target included in deploying cloud-native network elements.

[0196] S703. For each target deployment process, a target deployment task is sent to the scheduling framework to request the execution of that target deployment process. This allows the scheduling framework to find the target SDK corresponding to each target deployment task based on the preset correspondence between deployment tasks and SDKs, and then call each target SDK. Each SDK is used to execute one of the deployment processes for deploying cloud-native network elements.

[0197] The cloud-native network element automated delivery method provided in this disclosure involves a delivery platform issuing target deployment tasks to a scheduling framework. Each target deployment task requests the execution of one of the target deployment processes for deploying a cloud-native network element. Subsequently, the scheduling framework, based on a pre-defined correspondence between multiple deployment tasks and SDKs, locates the target SDK corresponding to each target deployment task and invokes each target SDK to execute a target deployment process. Since each deployment process is executed by a single SDK, the delivery platform does not need to consider the specific execution process of each deployment process, thus reducing the development and dimensional complexity of the delivery platform.

[0198] For the specific implementation methods of the cloud-native network element automated delivery method applied to the delivery platform, please refer to the relevant description of the cloud-native network element automated delivery method applied to the scheduling framework mentioned above, which will not be repeated here.

[0199] Based on the same inventive concept, this disclosure provides a cloud-native network element automated delivery device, applied to a scheduling framework, such as... Figure 8 As shown, the device includes: a receiving module 801 and a calling module 802;

[0200] The receiving module 801 is used to receive each target deployment task sent by the delivery platform. Each target deployment task is used to request the execution of one of the deployment processes for deploying cloud-native network elements.

[0201] The calling module 802 is used to find the target SDK corresponding to each target deployment task received by the receiving module 801 based on the preset correspondence between the deployment task and the software development kit (SDK), and call the target SDK to trigger the target SDK to execute the deployment process; wherein, each SDK is used to execute one of the deployment processes for deploying cloud-native network elements.

[0202] In some embodiments of this disclosure, module 802 is invoked specifically for:

[0203] Call the target SDK's deployment preparation interface to trigger the target SDK to perform preparatory work before executing the target deployment process;

[0204] Receive the preparation completion message returned by the target SDK. The preparation completion message indicates that the preparation work has been completed.

[0205] Call the target SDK's execution deployment interface to trigger the target SDK to execute the target deployment process;

[0206] Receive deployment completion information returned by the target SDK. The deployment completion information indicates that the target deployment process has been completed.

[0207] In some embodiments of this disclosure, the calling module 802 is further configured to:

[0208] After receiving the deployment completion information returned by the SDK, the configuration and inspection interface of the target SDK is called to trigger the target SDK to check the execution result of the target deployment process;

[0209] Receive the check completion information returned by the target SDK. The check completion information indicates that the configuration and check of the target deployment process have been completed.

[0210] In some embodiments of this disclosure, the target SDK is a first SDK used for installing an operating system or computing virtualization, and module 802 is specifically used for:

[0211] The system calls the first SDK's preparation deployment interface to send operating system configuration parameters to the first SDK, triggering the first SDK to call the ipmitool plugin to enable the pre-boot execution environment PXE mode of the specified server, and calls the cobbler plugin to write the operating system configuration parameters into the cobbler tool; where the operating system configuration parameters are the configuration parameters required to install the operating system on the specified server where the cloud-native network element is located.

[0212] Call the execution deployment interface of the first SDK to trigger the first SDK to call the ipmitool plugin to restart the specified server;

[0213] Call the configuration and check interface of the first SDK to trigger the first SDK to perform configuration checks on the specified server.

[0214] In some embodiments of this disclosure, the target SDK is a second SDK for installing OpenStack, and module 802 is specifically used for:

[0215] The second SDK's deployment preparation interface is called to send OpenStack configuration parameters to the second SDK, triggering the second SDK to call the kolla-ansible plugin to write the OpenStack configuration parameters into the specified configuration file of kolla-ansible; where the OpenStack configuration parameters are the configuration parameters required to deploy OpenStack on the specified server where the cloud-native network element is located;

[0216] The second SDK's execution deployment interface is called, which triggers the second SDK to call the kolla-ansible plugin to clean up the containers on the specified server, pull the specified containers for the specified server, and deploy OpenStack on the specified server;

[0217] The configuration and inspection interface of the second SDK is invoked, which triggers the second SDK to call the kolla-ansible plugin to verify the deployed OpenStack.

[0218] In some embodiments of this disclosure, the target SDK is a third SDK for deploying Kubernetes; module 802 is specifically used for:

[0219] The third SDK's deployment preparation interface is called to send Kubernetes deployment parameters to the third SDK, triggering the third SDK to call the OpenStack interface. Based on the Kubernetes deployment parameters, a virtual machine is started on the specified server and a container is deployed in the virtual machine. The virtual machine is used to host Kubernetes, and the Kubernetes deployment parameters are the configuration parameters required to deploy Kubernetes in the virtual machine.

[0220] Calling the execution deployment interface of the third SDK triggers the deployment of the kubelet and kubectl components by the third SDK, and calls the kubelet component to deploy the Kubernetes Master node in the virtual machine, or calls the kubelet component to add the virtual machine to the Kubernetes Worker node;

[0221] The configuration and inspection interface of the third SDK is called, which triggers the third SDK to call the kubectl component to check whether Kubernetes in the virtual machine is working properly.

[0222] In some embodiments of this disclosure, the target SDK is a fourth SDK used to launch cloud-native network elements; the calling module 802 is specifically used for:

[0223] The fourth SDK's preparation deployment interface is called to send vector packets to the fourth SDK to process the VPP's startup configuration parameters, triggering the fourth SDK to write the startup configuration parameters into the VPP's startup script. The VPP is used to carry cloud-native network elements, and the startup configuration parameters are the configuration parameters required to start the VPP in the virtual machine where the cloud-native network element is located.

[0224] The fourth SDK's execution deployment interface is called, triggering the fourth SDK to start a specified number of containers in the Kubernetes deployed on the virtual machine running on the specified server according to the startup configuration parameters, and calling Ligato according to the startup configuration parameters so that Ligato can configure the VPP;

[0225] The configuration and inspection interface of the fourth SDK is called, which triggers the fourth SDK to call the preparation interface of Ligato to check whether vpp and Ligato are working properly.

[0226] In some embodiments of this disclosure, the device further includes:

[0227] The startup module is used to start the target SDK after finding the target SDK corresponding to the target deployment task;

[0228] The acquisition module is used to obtain the processing logs of the target SDK after the target SDK is called to trigger the target SDK to execute the deployment process;

[0229] The inspection module is used to check whether the target SDK has executed errors based on the processing logs;

[0230] The stop module is used to stop the target SDK if an execution error is detected.

[0231] In some embodiments of this disclosure, the device further includes:

[0232] The acquisition module is used to obtain the processing logs of the target SDK after calling the target SDK to trigger the target SDK to execute the deployment process, and to obtain the processing progress of the target SDK for the target deployment process.

[0233] The sending module is used to send the processing progress of the target deployment process to the delivery platform, so that the delivery platform can display the processing progress of the target deployment process.

[0234] Fifthly, embodiments of this disclosure provide a cloud-native network element automated delivery device, applied to a delivery platform, such as... Figure 9 As shown, the device includes: a receiving module 901, a determining module 902, and a transmitting module 903;

[0235] The receiving module 901 is used to receive deployment requests submitted by users, which are used to request the deployment of cloud-native network elements.

[0236] Module 902 is used to determine each target deployment process included in the deployment of cloud-native network elements;

[0237] The sending module 903 is used to send a target deployment task to the scheduling framework for each target deployment process determined by the determining module 902, requesting the execution of the target deployment process. This allows the scheduling framework to find the target SDK corresponding to each target deployment task based on the preset correspondence between deployment tasks and software development kits (SDKs), and to call each target SDK. Each SDK is used to execute one of the deployment processes for deploying cloud-native network elements.

[0238] This disclosure also provides an electronic device, such as... Figure 10 As shown, it includes a processor 1001, a communication interface 1002, a memory 1003, and a communication bus 1004, wherein the processor 1001, the communication interface 1002, and the memory 1003 communicate with each other through the communication bus 1004.

[0239] Memory 1003 is used to store computer programs;

[0240] When the processor 1001 executes the program stored in the memory 1003, it implements the method steps executed by the scheduling framework or delivery platform in the above method embodiments.

[0241] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0242] The communication interface is used for communication between the aforementioned electronic devices and other devices.

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

[0244] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0245] In another embodiment provided in this disclosure, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements the steps of any of the above-described cloud-native network element automated delivery methods.

[0246] In yet another embodiment provided in this disclosure, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the cloud-native network element automated delivery methods described in the above embodiments.

[0247] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this disclosure are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., a solid-state disk (SSD)).

[0248] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0249] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device and system embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0250] The above description is merely a preferred embodiment of this disclosure and is not intended to limit the scope of protection of this disclosure. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this disclosure are included within the scope of protection of this disclosure.

Claims

1. A method for automated delivery of cloud-native network elements, characterized in that, Applied to a scheduling framework, the method includes: The delivery platform receives each target deployment task sent by the delivery platform. Each target deployment task is used to request the execution of one of the deployment processes for deploying cloud-native network elements. The delivery platform simultaneously sends multiple target deployment processes corresponding to each target deployment task to the scheduling framework, so that the scheduling framework can process the multiple target deployment processes simultaneously. For each target deployment task, based on the preset correspondence between deployment tasks and software development kits (SDKs), the target SDK corresponding to the target deployment task is found, and the target SDK is called to trigger the target SDK to execute the deployment process. Each SDK is used to execute one of the deployment processes for deploying cloud-native network elements. When executing the deployment process, the SDK uses the deployment tool to perform the deployment by calling the plugin corresponding to the deployment tool. The SDK is also configured with deployment steps that are paired with the deployment tool.

2. The method according to claim 1, characterized in that, The step of invoking the target SDK to trigger the deployment process of the target SDK includes: The target SDK's preparation and deployment interface is invoked, triggering the target SDK to perform preparatory work before executing the target deployment process; Receive the preparation completion information returned by the target SDK, the preparation completion information indicating that the preparation work has been completed; The execution deployment interface of the target SDK is invoked to trigger the target SDK to execute the target deployment process; Receive deployment completion information returned by the target SDK, which indicates that the target deployment process has been completed.

3. The method according to claim 2, characterized in that, After receiving the deployment completion information returned by the target SDK, the method further includes: The configuration and inspection interface of the target SDK is invoked, triggering the target SDK to check the execution result of the target deployment process; Receive the check completion information returned by the target SDK, which indicates that the configuration and check of the target deployment process have been completed.

4. The method according to claim 3, characterized in that, The target SDK is a first SDK used for installing an operating system or computing virtualization; The invocation of the target SDK's preparation deployment interface triggers the target SDK to perform preparatory work before executing the target deployment process, including: The first SDK is called to send operating system configuration parameters to the first SDK via the preparation deployment interface. This triggers the first SDK to call the ipmitool plugin to enable the pre-boot execution environment PXE mode of the specified server, and calls the cobbler plugin to write the operating system configuration parameters into the cobbler tool. The operating system configuration parameters are the configuration parameters required to install the operating system on the specified server where the cloud-native network element is located. The step of calling the execution deployment interface of the target SDK to trigger the target SDK to execute the target deployment process includes: The execution deployment interface of the first SDK is invoked, triggering the first SDK to call the ipmitool plugin to restart the specified server; The step of calling the configuration and inspection interface of the target SDK to trigger the target SDK to check the execution result of the target deployment process includes: The configuration and inspection interface of the first SDK is invoked, triggering the first SDK to perform a configuration check on the specified server.

5. The method according to claim 3, characterized in that, The target SDK is a second SDK used to install OpenStack; the invocation of the target SDK's preparation deployment interface triggers the target SDK to perform preparatory work before executing the target deployment process, including: The second SDK's deployment preparation interface is invoked to send OpenStack configuration parameters to the second SDK, triggering the second SDK to call the kolla-ansible plugin to write the OpenStack configuration parameters into the specified configuration file of kolla-ansible; wherein, the OpenStack configuration parameters are the configuration parameters required to deploy OpenStack on the specified server where the cloud-native network element is located; The step of calling the execution deployment interface of the target SDK to trigger the target SDK to execute the target deployment process includes: The second SDK's execution deployment interface is invoked, triggering the second SDK to call the kolla-ansible plugin to clean up the containers in the specified server, pull the specified containers for the specified server, and deploy OpenStack in the specified server; The step of calling the configuration and inspection interface of the target SDK to trigger the target SDK to check the execution result of the target deployment process includes: The configuration and inspection interface of the second SDK is invoked, which triggers the second SDK to call the kolla-ansible plugin to verify the deployed OpenStack.

6. The method according to claim 3, characterized in that, The target SDK is a third-party SDK used for deploying Kubernetes; the invocation of the target SDK's preparation deployment interface triggers the target SDK to perform preparatory work before executing the target deployment process, including: The third SDK's deployment preparation interface is invoked to send Kubernetes deployment parameters to the third SDK, triggering the third SDK to call the OpenStack interface. Based on the Kubernetes deployment parameters, a virtual machine is started on a specified server, and a container is deployed in the virtual machine. The virtual machine is used to host Kubernetes, and the Kubernetes deployment parameters are the configuration parameters required to deploy Kubernetes in the virtual machine. The step of calling the execution deployment interface of the target SDK to trigger the target SDK to execute the target deployment process includes: The third SDK's execution deployment interface is invoked to trigger the deployment of the kubelet and kubectl components by the third SDK, and the kubelet component is invoked to deploy the Kubernetes Master node in the virtual machine, or the kubelet component is invoked to add the virtual machine to the Kubernetes Worker node; The step of calling the configuration and inspection interface of the target SDK to trigger the target SDK to check the execution result of the target deployment process includes: The configuration and inspection interface of the third SDK is invoked, triggering the third SDK to call the kubectl component to check whether Kubernetes in the virtual machine is working properly.

7. The method according to claim 3, characterized in that, The target SDK is a fourth SDK used to launch cloud-native network elements; the step of calling the target SDK's preparation and deployment interface, triggering the target SDK to process preparatory work before executing the target deployment process, includes: The fourth SDK's deployment preparation interface is invoked to send vector packets to the fourth SDK to process the VPP's startup configuration parameters, triggering the fourth SDK to write the startup configuration parameters into the VPP's startup script. The VPP is used to carry cloud-native network elements, and the startup configuration parameters are the configuration parameters required to start the VPP in the virtual machine where the cloud-native network element is located. The step of calling the execution deployment interface of the target SDK to trigger the target SDK to execute the target deployment process includes: The fourth SDK's execution deployment interface is invoked to trigger the fourth SDK to start a specified number of containers in the Kubernetes deployed in the virtual machine running on the specified server according to the startup configuration parameters, and to invoke Ligato according to the startup configuration parameters so that Ligato can configure the VPP; The step of calling the configuration and inspection interface of the target SDK to trigger the target SDK to check the execution result of the target deployment process includes: The configuration and inspection interface of the fourth SDK is invoked, which triggers the fourth SDK to call the preparation interface of Ligato to check whether vpp and Ligato are working properly.

8. The method according to claim 1, characterized in that, After finding the target SDK corresponding to the target deployment task, the method further includes: starting the target SDK; After invoking the target SDK to trigger the deployment process of the target SDK, the method further includes: Obtain the processing logs of the target SDK; Based on the processing logs, check whether the target SDK has executed errors; If an error is detected in the target SDK, stop the target SDK.

9. The method according to any one of claims 1-8, characterized in that, After invoking the target SDK to trigger the deployment process of the target SDK, the method further includes: Obtain the processing logs of the target SDK to get the processing progress of the target SDK for the target deployment process; The processing progress of the target deployment process is sent to the delivery platform so that the delivery platform can display the processing progress of the target deployment process.

10. A method for automated delivery of cloud-native network elements, characterized in that, Applied to a delivery platform, the method includes: Receive deployment requests submitted by users, the deployment requests being used to request the deployment of cloud-native network elements; Determine the multiple target deployment processes involved in deploying the cloud-native network elements; Simultaneously, a request is sent to the scheduling framework to execute the target deployment tasks corresponding to each of the multiple target deployment processes. This allows the scheduling framework to locate the target SDK corresponding to each target deployment task based on the preset correspondence between deployment tasks and software development kits (SDKs), and to call each target SDK to process the multiple target deployment processes simultaneously. Each SDK is used to execute one of the deployment processes for deploying cloud-native network elements. When executing the deployment process, the SDK uses the deployment tool to perform the deployment by calling the corresponding plugin. The SDK is also configured with deployment steps that are paired with the deployment tool.

11. A cloud-native network element automated delivery system, characterized in that, The system includes: A delivery platform for performing the method of claim 10; A scheduling framework for performing the method described in any one of claims 1-9.

12. A cloud-native network element automated delivery device, characterized in that, Applied to a scheduling framework, the device includes: The receiving module is used to receive each target deployment task sent by the delivery platform. Each target deployment task is used to request the execution of one of the deployment processes for deploying cloud-native network elements. The delivery platform simultaneously sends multiple target deployment processes corresponding to each target deployment task to the scheduling framework, so that the scheduling framework can process the multiple target deployment processes simultaneously. The calling module is used to find the target SDK corresponding to each target deployment task received by the receiving module based on the preset correspondence between the deployment task and the software development kit (SDK), and call the target SDK to trigger the target SDK to execute the deployment process; wherein, each SDK is used to execute one of the deployment processes for deploying cloud-native network elements. When executing the deployment process, the SDK uses the deployment tool to perform deployment by calling the plugin corresponding to the deployment tool. The SDK is also configured with deployment steps that are paired with the deployment tool.

13. A cloud-native network element automated delivery device, characterized in that, Applied to a delivery platform, the device includes: The receiving module is used to receive deployment requests submitted by users, the deployment requests being used to request the deployment of cloud-native network elements; The determination module is used to determine multiple target deployment processes included in deploying the cloud-native network element; The sending module is used to simultaneously send target deployment tasks corresponding to the multiple target deployment processes to the scheduling framework, so that the scheduling framework can find the target SDK corresponding to each target deployment task based on the preset correspondence between deployment tasks and software development kits (SDKs), and call each target SDK to process the multiple target deployment processes simultaneously. Each SDK is used to execute one of the deployment processes for deploying cloud-native network elements. When executing the deployment process, the SDK uses the deployment tool to perform deployment by calling the corresponding plugin of the deployment tool. The SDK is also configured with deployment steps that are paired with the deployment tool.

14. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the steps of the method according to any one of claims 1-9 or 10.

15. 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 steps of the method described in any one of claims 1-9 or 10.

Images