Device management method and platform, and physical machine and storage medium

Abstract

Provided in the embodiments of the present disclosure are a device management method and platform, and a physical machine and a storage medium. The method comprises: a device management platform creating a control component and a virtual machine in a hosted target physical machine, wherein the virtual machine can be delivered to a user; during the process of the user using the virtual machine, the user also generating a control instruction for the virtual machine or a container corresponding thereto; and the control component receiving the control instruction and responding to same, so as to control an operating state of the virtual machine or an operating state of the container, wherein the virtual machine operates in a VPC, and the container is created when the user uses the virtual machine and operates in a container network. It can be seen that a control component in a physical machine can receive a control instruction in respect of a virtual machine and a container which are in different network environments, such that networks where the virtual machine and the container are located are located in the same management domain, that is, unified management over the virtual machine and the container is realized.

Description

[0001] Device Management Method, Platform, Physical Host, and Storage Medium This disclosure claims priority to Chinese patent application No. 202410021674.3, filed with the Patent Office of the People's Republic of China on January 5, 2024, entitled "Device Management Method, Platform, Physical Host, and Storage Medium," the entire contents of which are incorporated herein by reference. Technical Field This disclosure relates to the field of communications technology, and more particularly to a device management method, platform, physical host, and storage medium. Background Server hosting, also known as hosting, is a service offered by Internet Data Center (IDC) service providers or cloud service providers that allows users to host their own physical hosts in the service provider's computer room. Since the service provider can monitor the user's network and devices in real time, the service provider can also create a virtual machine (VM) within the physical host hosted in the service provider's computer room. When a user wants to use their own host, the virtual host can be provided to the user in place of the physical host without moving the user's own physical host. The user can also create containers with different functions based on the virtual host to meet their specific needs. Furthermore, during the use of the virtual host, the user may need to manage the virtual host and the corresponding containers. Therefore, achieving unified management of virtual hosts and containers has become a pressing issue. SUMMARY OF THE INVENTION In view of this, embodiments of the present disclosure provide a device management method, platform, physical host, and storage medium for achieving unified management of virtual hosts and containers in different networks. In a first aspect, embodiments of the present disclosure provide a device management method, comprising: creating a control component in a target physical host hosted by a hosting delivery platform; creating a virtual host delivered to the user in the target physical host, where the control component controls the virtual host or its corresponding container based on received control instructions. The virtual host runs in a virtual private cloud (VPC), and the container is created by the user and runs in a container network.In a second aspect, embodiments of the present disclosure provide a device management platform, comprising: a hosting sub-platform and a delivery sub-platform; the hosting sub-platform is configured to store configuration information of hosted candidate physical hosts; the delivery sub-platform is configured to determine a target physical host from the candidate physical hosts based on the configuration information; create a control component in the target physical host; and create a virtual host in the target physical host, which is delivered to a user, so that the virtual host, based on control instructions received by the control component, controls the virtual host or a container corresponding to the virtual host. The virtual host runs in a virtual private cloud (VPC), and the container is created by the user and runs in a container network. In a third aspect, embodiments of the present disclosure provide a physical host, comprising: the physical host is hosted by the device management platform; the physical host includes: a control component and a virtual host running on the physical host; the control component and the virtual host are created by the device management platform; the virtual host delivered to the user runs in a virtual private cloud (VPC); the control component is configured to receive control instructions; and control the running status of the virtual host or the container corresponding to the virtual host. The container is created by the user and runs in a container network. In a fourth aspect, embodiments of the present disclosure provide a physical host, comprising: a memory configured to store one or more computer instructions, wherein the one or more computer instructions, when executed by the processor, implement the device management method described in the first aspect. The electronic device may further include a communication interface for communicating with other devices or communication systems. In a fifth aspect, embodiments of the present disclosure provide a non-transitory machine-readable storage medium, wherein the non-transitory machine-readable storage medium stores executable code. When the executable code is executed by the processor of the electronic device, the processor is enabled to implement at least the device management method described in the first aspect. In a sixth aspect, embodiments of the present disclosure provide a computer program, which, when executed in a computer, causes the computer to implement the device management method described in the first aspect. In the device management method provided in embodiments of the present disclosure, a device management platform can create a control component and a virtual host in a hosted target physical host. The virtual host can be delivered to a user. Furthermore, during the use of the delivered virtual host, the user can create a container corresponding to the virtual host to meet their own usage needs. Users can also generate control instructions for virtual hosts or containers, and the control component can receive and respond to the control instructions to control the running status of the virtual hosts or containers.The virtual host runs in a virtual private cloud (VPC). The container corresponding to the virtual host is created by the user when using the virtual host and runs in the container network. Therefore, the control component set up in the physical host can receive control instructions for virtual hosts or containers in different networks. This unifies the networks where the virtual hosts and containers reside under a single management domain, enabling unified management of both. Furthermore, compared to hardware-based control devices, software-based control components can also reduce the management costs of virtual hosts and containers. BRIEF DESCRIPTION OF THE DRAWINGS To more clearly illustrate the embodiments of the present disclosure or the technical solutions in the prior art, the following briefly introduces the drawings required for the embodiments or the description of the prior art. Obviously, the drawings described below represent some embodiments of the present disclosure. Those skilled in the art can derive other drawings based on these drawings without inventive effort. Figure 1 is a schematic diagram of the structure of a device management platform provided in an embodiment of the present disclosure; Figure 2 is a schematic diagram of the communication process between hosts provided in an embodiment of the present disclosure; Figure 3 is a schematic diagram of the process of hosting, delivering, and using a virtual host provided in an embodiment of the present disclosure; Figure 4 is a flow chart of a device management method provided in an embodiment of the present disclosure; Figure 5 is a flow chart of another device management method provided in an embodiment of the present disclosure; Figure 6 is a schematic diagram of the structure of a physical host provided in an embodiment of the present disclosure; Figure 7 is a schematic diagram of the structure of another physical host provided in an embodiment of the present disclosure; Figure 8 is a schematic diagram of the process of data acquisition by a virtual host provided in an embodiment of the present disclosure; Figure 9 is a schematic diagram of the structure of a device management apparatus provided in an embodiment of the present disclosure; and Figure 10 is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS To further clarify the objectives, technical solutions, and advantages of the embodiments of the present disclosure, the technical solutions of the embodiments of the present disclosure will be described clearly and completely below in conjunction with the accompanying drawings. It should be understood that the described embodiments represent only a portion of the embodiments of the present disclosure, and are not intended to be exhaustive. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without inventive effort are intended to fall within the scope of protection of the present disclosure. The terminology used in the embodiments of the present disclosure is for the purpose of describing specific embodiments only and is not intended to limit the present disclosure. As used in the embodiments of the present disclosure and the appended claims, the singular forms "a," "an," "the," and "the" are intended to include the plural forms. Unless the context clearly indicates otherwise, "a plurality" generally includes at least two, but does not exclude the inclusion of at least one.It should be understood that the term "and / or" as used herein is merely a description of an association relationship between associated objects, indicating that three possible relationships exist. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone. Furthermore, the character " / " herein generally indicates that the associated objects are in an "or" relationship. Depending on the context, the phrases "if" and "if" as used herein can be interpreted as "upon..." or "when..." or "in response to determining..." or "in response to identifying." Similarly, depending on the context, the phrases "if it is determined" or "if (a stated condition or event) is identified" can be interpreted as "upon determination," "in response to determining," "upon identifying (a stated condition or event)," or "in response to identifying (a stated condition or event)." It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display) referred to in this disclosure are all information and data authorized by the user or fully authorized by all parties. The collection, use, and processing of the relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse. It should also be noted that the terms "include," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a product or system comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such product or system. Without further limitation, elements defined by the phrase "comprising a..." do not preclude the presence of other identical elements in the product or system comprising the elements. The following detailed description of some embodiments of the present disclosure is provided in conjunction with the accompanying drawings. The following embodiments and features may be combined unless there is a conflict between the embodiments. Furthermore, the sequence of steps in the following method embodiments is provided as an example and is not a strict limitation. As described in the background art, a user's own physical host can be hosted by a service provider such as an IDC service provider or a cloud service provider. This user's own physical host is also the device that needs to be hosted. Optionally, the user may have at least one physical host that needs to be hosted.Users can still use physical hosts already hosted by a service provider. However, given the inconvenience of physical hosts being portable, if a user wishes to use a hosted physical host, the service provider can first create a virtual host within the hosted physical host and deliver this virtual host to the user in place of the physical host for easy use. Since the virtual host has the same computing power as the physical host, it can also meet the user's needs. The physical host hosting and delivery processes described above can be collectively referred to as device management, and this management can be implemented by a management platform maintained by the service provider. Figure 1 is a schematic diagram of the structure of a device management platform provided in an embodiment of the present disclosure. As shown in Figure 1, the platform may include a hosting sub-platform and a delivery sub-platform. In various embodiments of the present disclosure, a user's own physical host already hosted by the hosting sub-platform may be referred to as a candidate physical host. The candidate physical host may run in a VPC. As will be readily understood, the hosting sub-platform is used to host the candidate physical host. The delivery sub-platform can identify at least one candidate physical host as the target physical host based on user needs, and create a virtual host therein to deliver this virtual host to the user. Regarding the hosting process: the user can trigger a hosting request on the interface provided by the hosting sub-platform. This hosting request can include configuration information for the candidate physical host to be hosted. Optionally, this configuration information can include basic information such as the physical host's Basic Input Output System (BIOS), machine model, and operating system version. In response to the hosting request, the hosting sub-platform can store the configuration information in the hosting request, thereby completing the online hosting process. This configuration information can also be associated with the physical host as a tag. Once the candidate physical host arrives at the service provider's computer room, the hosting of the candidate physical host is finally completed. Regarding the delivery process: when the user wishes to use the hosted physical host, the user can further trigger the delivery operation on the interface provided by the delivery sub-platform. In response to this operation, the delivery sub-platform may determine a target physical host that meets the user's requirements from among the candidate physical hosts based on their respective configuration information. The delivery sub-platform may then further create a virtual host within the target physical host, which is ultimately delivered to the user as a response to the delivery operation. The target physical host also includes a control component created by the delivery sub-platform. Optionally, the virtual host may be a cloud server (ECS). oOptionally, the user's requirements for a physical host can be expressed as user requirement information included in a provisioning request. This user requirement information can include configuration information for the physical host required by the user. The provisioning request is generated when the user triggers a provisioning operation. During the use of a virtual host after provisioning, the user can also trigger an operation on the virtual host to create a container corresponding to the virtual host. Containers of different types and functions can meet different user needs, either individually or in combination. Optionally, the containers corresponding to the virtual host can include standard containers running in the isolated environment of the virtual host or secure containers running in the runtime environment provided by the target physical host. In other words, secure containers run directly on the physical host, while standard containers run on top of the virtualization layer of the virtual host. Optionally, the secure container can be a lightweight RunDo container based on a virtualization isolation sandbox. The container corresponding to the virtual host can run in a container network, while the virtual host can run in a VPC, meaning that the two run in different networks. The container network is the network within the container, enabling communication between containers. During the use of a virtual host, the operating status of the virtual host or container can be controlled, for example, by shutting down the virtual host or closing or creating at least one container. Leveraging the forwarding capabilities of the control component in the physical host, the control component can receive control commands issued to virtual hosts or containers in different networks. The control component responds to these commands to control the operating status of the virtual host or container. In this embodiment, the hosting sub-platform in the device management platform can store configuration information for candidate physical hosts. The delivery sub-platform in the device management platform can determine a target physical host from the managed candidate physical hosts and further create a control component and a virtual host on this target physical host. This virtual host can then be delivered to the user. After the virtual host is delivered, the user can create a container corresponding to the virtual host to meet their specific needs. The user can also issue control commands to the virtual host or container, and the control component can receive and respond to these commands to control the operating status of the virtual host or container. The virtual host runs in a VPC, and the corresponding container runs in a container network. As can be seen, the control component installed in the physical host can receive control instructions for virtual hosts or containers in different networks. This unifies the networks where virtual hosts and containers reside under a single management domain, enabling unified management of both. Furthermore, compared to hardware-based control devices, software-based control components can also reduce the management costs of virtual hosts and containers.The technical effects that can be achieved by the platform, physical host, and method provided in the above and following embodiments of the present disclosure can also be understood in conjunction with the following content:

[0002] 1. In practice, control instructions for virtual hosts running in a VPC or containers running in a container network can be generated by different management tools. This means that control of objects running in the container network and the VPC needs to be performed separately. For example, container orchestration tools such as Kubernetes and Docker Swarm can be used to control the running status of containers, while management tools such as Secure Shell (SSH) can be used to control the running status of virtual hosts. When the virtual host is specifically an ECS server, the aforementioned management tools are actually server management tools. However, when using the various embodiments of the present disclosure, when the container corresponding to the virtual host is a secure container, the control component may receive control instructions generated by the server management tool to control the running status of the entire virtual host. In response to these control instructions, the control component controls the running status of all secure containers corresponding to the virtual host as a whole, performing batch control on their running status. Thus, by leveraging the control component's forwarding capabilities, the running status of secure containers can be controlled using both container orchestration tools and virtual host management tools, thereby enriching the management methods for secure containers and achieving dual management of secure containers.

[0003] 2. In practice, the secure containers corresponding to virtual hosts offer greater security. Therefore, multiple virtual hosts can be created on a single physical host and leased to multiple users, thus achieving multi-tenancy. The various embodiments provided herein enable unified management of virtual hosts and containers while also enabling multi-tenancy of physical hosts.

[0004] 3. In practice, in addition to using their own physical hosts, users can also rent virtual hosts provided by a service provider's own physical hosts. If the physical host does not have the control component mentioned in the various embodiments of this disclosure, the user's own physical host and the virtual host rented from the service provider can only be connected via a dedicated line, which occupies more network segments and wastes network resources. However, when the physical host is equipped with a control component, since the virtual hosts created on the user's own physical host and the virtual hosts rented from the service provider are both located in the VPC, network segment usage can be reduced, thereby improving network resource utilization. This section can also be understood in conjunction with Figure 2. In addition to the configuration information mentioned in the embodiment shown in Figure 1, the user requirement information in the delivery request can optionally include various functional information, such as communication functions and storage functions. After receiving the delivery request, the delivery sub-platform can create corresponding sub-components based on the functional information in the request. These sub-components can constitute the control component. The sub-components in the control component can specifically include a forwarding sub-component for implementing communication functions and a detection sub-component for detecting the operating status of the physical host. Optionally, subcomponents in the control component may also include a storage driver for implementing storage functions. Specifically, when the user requirement information includes functional information corresponding to a communication function, the control component may optionally include a forwarding subcomponent for implementing the communication function. This forwarding subcomponent may specifically manifest as a virtual switch, which can also be considered a high-performance virtual switch (HVS) service. The forwarding subcomponent may be used to receive control instructions for containers or virtual hosts. The control instructions received by the forwarding subcomponent may optionally include container creation instructions, which may be generated after the delivery subplatform delivers the virtual host to the user. Optionally, the control instructions may also include state control instructions, which may be generated by the user using a container orchestration tool or other management tool during the operation of the virtual host and container. State control instructions for the container may be generated using a container orchestration tool; when the virtual host is an ECS server, control instructions for the ECS server may be generated using a server management tool. Optionally, the container creation instructions, operating status control instructions, and other instructions received by the control component created by the delivery sub-platform can be considered control plane instructions generated by the physical host. Thus, by configuring the control component, the processing of control plane instructions can be transferred to the component, thereby achieving the transfer of control plane instructions as a load.The control component has the same functions as a Microserver on Chip (MoC). This control component can be considered a software-implemented MoC card, i.e., a virtual MoC card. When the user requirement information includes functional information corresponding to a storage function, the user requirement information may also optionally include a data storage method. Specifically, data storage methods may include network storage and local storage. The delivery sub-platform may also create a virtual host that meets the requirements based on this data storage method. If the data storage method in the user requirement information is network storage, the control component created by the delivery sub-platform may also include a storage driver for implementing the storage function. Using the storage driver in the control component, a network storage device may be mounted for the virtual host created by the delivery sub-platform. The network storage device may store the virtual host's system data and user data. The container may then generate a data acquisition request in response to a user operation, respond to the data acquisition request, and then use the storage driver to access the network storage device mounted on the virtual host, thereby obtaining the target data corresponding to the data acquisition request from the network storage device. Regarding mounting a network storage device, specifically, after the delivery sub-platform creates a storage driver, this driver can serve as a cloud disk driver to establish communication between the virtual host and the network storage device. Users can then directly retrieve target data from the network storage device after generating a data retrieval request. Optionally, the network storage device can be a cloud disk. A cloud disk can also be considered an Elastic Block Storage (EBS) service. The cloud disk can be in the same or a different VPC as the virtual host. If the data storage method specified in the user requirement information is local storage, the delivery sub-platform can create a virtual host that includes a local storage device. This local storage device can store the virtual host's system data and user data. In this embodiment, the delivery sub-platform can create control components and virtual hosts that meet the user's requirements based on the different dimensions of the user requirement information, thereby enabling the hosting and delivery of physical hosts. Furthermore, in this embodiment, compared to hardware-based control devices such as the MoC card mentioned above, using software-based control components can reduce the management costs of virtual hosts and containers. According to the description in the embodiment shown in FIG. 1 , the delivery sub-platform can determine a target physical host from candidate physical hosts, and further create a virtual host in the target physical host.To determine the target physical host, the hosting sub-platform may optionally already store the configuration information of each candidate physical host. The delivery sub-platform can then, in response to a delivery request, compare the configuration information contained in the delivery request with the configuration information of each candidate physical host to determine the physical host with matching configuration information as the target physical host. This configuration information matching process is also the process of matching TAG information. In practice, given that virtual hosts must be able to function normally, the target physical host determination process may also refer to the operating status of the candidate physical hosts to avoid determining an abnormally operating physical host as the target physical host. Based on the operating status data of the candidate physical hosts, the delivery sub-platform can first identify a normally operating physical host among the candidate physical hosts. Then, the configuration information is compared among these normally operating physical hosts to determine the target physical host. The operating status of the physical host can be collected by the detection sub-component within the control component. This sub-component can also be considered a Python Node Controller (PYNC). In this embodiment, by matching configuration information, the delivery sub-platform can ensure that virtual hosts are created on physical hosts that meet user requirements, thereby ensuring that the virtual hosts ultimately delivered to users meet user requirements. Based on the descriptions of the above embodiments, the management platform's hosting and delivery of physical hosts, as well as the user's use of virtual hosts, can include the following stages: Planning Stage: Users can provide configuration information for candidate physical hosts through the hosting sub-platform, which then stores this configuration information. This stage is also known as the online hosting stage. Procurement Stage: The service provider delivers the candidate physical hosts that the user requires to be hosted to its own computer room. Installation Stage: The service provider performs system installation, system quality inspection, and equipment stress testing on the candidate physical hosts. Deployment Stage: In response to a user-triggered delivery operation on the delivery sub-platform, a target physical host is determined from the candidate physical hosts based on the user's requirements, and a control component is created on this target physical host. The subcomponents contained in the control component correspond to the user's requirements. During the delivery phase, the hosting sub-platform determines whether the target host's configuration matches the user's requirements based on the configuration information of the candidate physical hosts stored on the hosting sub-platform. A virtual host is then created for the user on the target host. During the usage phase, the user can create a container on this virtual host as needed. When the control component creates the container, it also creates a corresponding virtual network card for the container, enabling the container to communicate with external devices through this virtual network card.Optionally, the virtual network card is essentially a virtual network interface, such as an elastic network card (ELN1 interface). The creation and use process of the virtual network card can be described in the following embodiments. The above process can also be understood in conjunction with FIG3. It should be noted that, according to the description in the above embodiments, subcomponents in the control component can be created according to user needs. In practice, the forwarding subcomponent and the detection subcomponent are essential components of the control component. The detection subcomponent is used to collect physical host operating status data to determine whether the physical host is operating normally. During the deployment phase, the control component including the forwarding subcomponent and the detection subcomponent can be installed in the candidate physical host. The forwarding subcomponent and the detection subcomponent are automatically started after the physical host is powered on. During the delivery phase, the target physical host can be determined based on the user requirement information in the delivery request, and other components such as a storage driver can be added to the control component included in the target physical host based on this user requirement information. The working process of the delivery subplatform in the device management platform can also be described from a process perspective. FIG4 is a flow chart of a device management method provided in an embodiment of the present disclosure. The method provided in the embodiment of the present disclosure can be executed by the delivery sub-platform in the device management platform. As shown in FIG4 , the method may include the following steps:

[0005] At step 5101, a control component is created in a target physical host hosted by a hosting delivery platform.

[0006] In step 5102, a virtual host delivered to the user is created on the target physical host. The control component controls the virtual host or its corresponding container based on received control instructions. The virtual host runs in the virtual private cloud (VPC), and the container is created by the user and runs in the container network. In response to the user triggering a delivery operation on the delivery sub-platform, the delivery sub-platform creates the control component on the target physical host. Simultaneously, it can also create a virtual host on the target physical host. During the use of the virtual host, the user can first create a container corresponding to the virtual host. The container runs in the container network, and the virtual host runs in the VPC. Based on the created container, the user can also issue control instructions for virtual hosts or containers running in different networks. These control instructions can be received and responded to by the control component, ultimately achieving control over the running status of the virtual host or container. The specific implementation methods and technical effects achieved by each step of this embodiment can be found in the relevant descriptions of the above embodiments and will not be elaborated here. In this embodiment, the delivery sub-platform can create the control component and virtual host on the target physical host, and the virtual host can be delivered to the user. During the use of a virtual host after delivery, users can create containers corresponding to the virtual host. Users can also issue control instructions for virtual hosts or containers running on different networks. The control component can receive and respond to these control instructions to control the running status of the virtual host or container. Thus, the control component installed in the physical host can receive control instructions for virtual hosts or containers on different networks. This unifies the networks where virtual hosts and containers reside within the same management domain, enabling unified management of virtual hosts and containers across different networks. Furthermore, compared to hardware-based control devices, software-based control components can also reduce virtual host and container management costs. Optionally, based on user requirements, the control component can include the various subcomponents mentioned above. The subcomponents included in the control component correspond to the user requirements. The functions provided by the various subcomponents can be found in the description of the relevant embodiments above and will not be further elaborated here. Optionally, for virtual hosts created by the delivery sub-platform, the storage driver in the control component can be used to mount a network storage device or create a local storage device for the virtual host based on user requirements. The specific mounting process can be found in the description of the above embodiments and will not be repeated here. Furthermore, the storage device configuration ensures the normal operation of the virtual host, allowing users to access local or network data through the storage device. The specific data acquisition process can be found in the description of the following embodiments.As described in the above platform embodiment, the target physical host can be at least one of the candidate physical hosts hosted by the user. The delivery platform can also determine the target physical host according to the embodiment shown in FIG5 . FIG5 is a flow chart of another device management method provided in an embodiment of the present disclosure. As shown in FIG5 , the method may include the following steps:

[0007] 5201. In response to a user's delivery request, obtain configuration information of an alternative physical host on a hosting delivery platform.

[0008] At step 5202, among the candidate physical hosts, a physical host whose configuration information matches the user's required information is determined as the target physical host. In response to a delivery request triggered by the user on the delivery sub-platform, the configuration information of the candidate physical hosts stored on the device management platform is obtained and matched with the user's required information in the delivery request, thereby obtaining a target physical host that meets the user's requirements. Optionally, the operational status of the candidate physical hosts may also be referenced during the determination of the target physical host. The delivery sub-platform may receive operational status data of the candidate physical hosts. Based on the operational status data, a normally operating physical host is determined among the candidate physical hosts. Then, among the normally operating physical hosts, a physical host whose configuration information matches the required information is determined as the target physical host.

[0009] 5203. Create a control component in a target physical host hosted by the hosting delivery platform.

[0010] At step 5204, a virtual host delivered to the user is created on the target physical host. The control component controls the virtual host or its corresponding container based on the received control instructions. The virtual host runs in the virtual private cloud (VPC), and the container is created by the user and runs in the container network. The specific implementation of steps S203 through S204 can be found in the detailed description of the relevant steps in the embodiment shown in FIG4 and will not be repeated here. The specific process for determining the target physical host, as well as the functions and creation methods of the various subcomponents in the control component, can also be understood in conjunction with the above embodiments and will not be repeated here. In this embodiment, the target physical host is determined by considering both user requirements and the operating status of the physical host. This ensures that the target physical host operates normally and meets user requirements, and ultimately ensures that the virtual host delivered to the user also meets user requirements. Furthermore, any details not described in this embodiment can be found in the relevant descriptions of the above embodiments and will not be repeated here. The specific structure of the physical host hosted by the hosting sub-platform will be described below. FIG6 is a schematic structural diagram of a physical host provided in an embodiment of the present disclosure. The managed physical host may include a control component and a virtual host running on the physical host. The control component and virtual host are created by the device management platform, and the virtual host runs in a VPC. The physical host in this embodiment can be any of the candidate physical hosts mentioned in the above embodiments, such as the target physical host. The virtual host and control component in the physical host are created by the delivery sub-platform within the device management platform. The virtual host is delivered to the user. During the use of the virtual host, the control instructions received by the control component may optionally include container creation instructions. This instruction may be generated immediately after the virtual host is delivered. The user can trigger an operation on the virtual host to generate a container creation instruction. The virtual host responds to the container creation instruction and creates a container corresponding to the virtual host. As described in the embodiment shown in Figure 1, the container can be a regular container running in the isolated environment of the virtual host or a secure container running in the physical host's operating environment. The virtual host may be specifically represented as an ECSO. Optionally, the control instructions received by the control component may also include state control instructions. A container orchestration tool can generate a state control instruction for at least one container, or a server management tool can generate a state control instruction for a virtual host or all containers within a virtual host. In response to the state control instruction, the control component can control the running state of a single container, or the running state of an entire virtual host or all containers within a virtual host.In this embodiment, a physical host may include a virtual host and a control component created by the delivery sub-platform within the device management platform. After the virtual host within the physical host is delivered to a user, the user can generate control instructions for the virtual host or its corresponding container. The control component can receive and respond to these control instructions to control the running status of the virtual host or container. The virtual host runs within a VPC, and the corresponding container runs within a container network. Thus, the control component within the physical host can receive control instructions for virtual hosts or containers in different networks, unifying the networks where the virtual hosts and containers reside under a single management domain, thus achieving unified management of both. Furthermore, compared to hardware-based control devices, software-based control components can also reduce the management costs of virtual hosts and containers. Figure 7 is a schematic diagram of the structure of another physical host provided by an embodiment of the present disclosure. Optionally, the control component within the physical host may specifically include a forwarding sub-component. During actual use of the virtual host, the forwarding sub-component can receive container creation instructions, status control instructions, and other instructions mentioned in the above embodiments. Optionally, the forwarding sub-component can also receive user-generated data retrieval requests. The data retrieved by the user can be system data or user data of the virtual host in the storage device, or data from another network. The storage device can be a network storage device or a local storage device. Regarding data retrieval, in one scenario, the user wants to retrieve data from another network. Optionally, this other network can be a different VPC than the virtual host or a public network. Specifically, the user can trigger a data retrieval operation on a container. In response to this operation, the container can generate a data retrieval request. The forwarding subcomponent can receive this data retrieval request via the virtual network card (VNIC) corresponding to the container and forward it to the gateway of the VPC network where the virtual host resides, which then forwards the data retrieval request to the other network. Optionally, after receiving the container creation instruction forwarded by the forwarding subcomponent, the virtual container can further invoke the forwarding subcomponent, which in response to the invocation creates a virtual network card corresponding to the container. Optionally, during the virtual network card creation process, the forwarding subcomponent can also assign routing information to the VPC gateway where the virtual host resides, and forward the data retrieval request to the gateway of the VPC where the virtual host resides according to this routing information. In another scenario, a user wants to retrieve data from a network storage device. Optionally, the control component may also include a storage driver. After the container generates a data retrieval request, the container may use the storage driver to access the network storage device mounted on the virtual host, thereby obtaining the target data corresponding to the data retrieval request from the network storage device.Optionally, the network storage device can be a cloud disk. In another scenario, a user wants to retrieve data from a local storage device. Optionally, the physical component also includes a local storage device, such as a disk. After the container generates a data retrieval request, it can directly access the local storage device to obtain the target data corresponding to the data retrieval request. It should be noted that, in practice, a physical host typically has a local storage device, and a network storage device can be mounted to the virtual host based on user needs. When a network storage device is not mounted, the virtual host's system data and user data are stored in the local storage device. When a network storage device is mounted, the virtual host's system data can be stored in the network storage device. The above process of retrieving data from a network storage device or other network can also be understood in conjunction with FIG8 . Optionally, the forwarding subcomponent also has traffic control capabilities. Based on the bandwidth of the virtual network card, if the number of control instructions and / or data retrieval instructions generated within a period of time exceeds a preset threshold, that is, the traffic exceeds the bandwidth of the virtual network card, the forwarding subcomponent can discard the instructions. Optionally, the command can be redirected based on the priority or type of the instruction. Optionally, the control component may further include a detection subcomponent for detecting the operating status of virtual hosts and / or containers. In this embodiment, the control component may further include multiple subcomponents to enable the control component to control the operating status of virtual hosts and containers in different networks. The control component may also facilitate data transmission between containers and other devices. Furthermore, for matters not described in detail in this embodiment, reference may be made to the relevant descriptions in the above embodiments and will not be repeated here. Furthermore, regarding the platforms and physical hosts provided in the above embodiments, the hosting, delivery, and use of the physical hosts can also be understood in conjunction with the following. Assume that the hosting sub-platform hosts 100 physical hosts of model ABC, operating system version OS5, and 100 physical hosts of model XYZ, operating system version OS3. These 200 physical hosts are all candidate physical hosts, and the model and operating system version of each physical host can be stored as a tag for that physical host in the hosting sub-platform. Each of these hosted physical hosts can be installed with a control component, which may include basic components such as a forwarding subcomponent and a detection subcomponent. When a user makes a delivery request to the delivery subplatform, the request may include the following: 5 machines of model ABC, operating system version 0S5.The delivery subsystem can then match the tags in the user's requirement information with the tags of the candidate physical hosts in the hosting subplatform to obtain five target physical hosts that meet the user's requirements. The delivery subsystem can also create virtual hosts within these five target physical hosts. Furthermore, if the data storage method specified in the user's requirement information is network storage, the storage driver in the control component can be used to establish communication between the target physical host and the corresponding network disk, essentially mounting the corresponding network disk on the target physical host. This virtual host with the mounted network disk can then be delivered to the user. Furthermore, the delivery subsystem can also create a storage driver in the control component based on the user's requirement information. During the use of the virtual host after delivery, when a user creates a container corresponding to the virtual host, the control component can also create a corresponding virtual network card for the container. Using this virtual network card, the container can retrieve data from other networks or network storage devices. Furthermore, during the use of the virtual host, the user can issue operation status control commands for the virtual host or container. The forwarding subcomponent in the control component is responsible for receiving these commands, ultimately controlling the operation status of the virtual host or container. In addition, for details not described in this embodiment, please refer to the relevant descriptions in the above embodiments and will not be repeated here. The following describes in detail the device management apparatus of one or more embodiments of the present disclosure. Those skilled in the art will appreciate that these device management apparatuses can be configured using commercially available hardware components through the steps taught in this solution. Figure 8 is a schematic structural diagram of a device management apparatus provided in an embodiment of the present disclosure. As shown in Figure 8, the apparatus may include: a component creation module 11 for creating a control component in a target physical host hosted by a hosting delivery platform; a host creation module 12 for creating a virtual host delivered to a user in the target physical host, so that the control component controls the virtual host or a container corresponding to the virtual host according to received control instructions. The virtual host runs in a virtual private cloud (VPC), and the container is created by the user and runs in a container network. Optionally, the component creation module 11 is configured to obtain user requirement information in response to a user's delivery request; create a subcomponent corresponding to the user requirement information in the target physical host, and use the subcomponent to form the control component. Optionally, the apparatus further includes: a host determining module 13, configured to obtain configuration information of candidate physical hosts on the device management platform in response to the delivery request; and determine, among the candidate physical hosts, a physical host whose configuration information matches the user requirement information as the target physical host.Optionally, the host determination module 13 is further configured to receive operating status data of the candidate physical hosts; determine a normally operating physical host among the candidate physical hosts based on the operating status data; and determine, among the normally operating physical hosts, a physical host whose configuration information matches the requirement information as the target physical host. Optionally, the component creation module 11 is configured to create the control component including a storage driver based on the user requirement information, so that the storage driver mounts a network storage device for the virtual host created in the target physical host. The apparatus shown in FIG9 can execute the method of the embodiments shown in FIG4 and FIG5 . For portions not described in detail in this embodiment, reference is made to the relevant description of the embodiments shown in FIG4 and FIG5 . The execution process and technical effects of this technical solution are described in the embodiments shown in FIG4 and FIG5 , and will not be further elaborated here. In one possible design, the device management method provided in the above embodiments can be applied to an electronic device. As shown in FIG10 , the electronic device may include a processor 31 and a memory 32. Memory 32 is used to store a program that supports the electronic device in executing the device management method provided in the embodiments shown in Figures 4 and 5 above. Processor 31 is configured to execute the program stored in memory 32. The program includes one or more computer instructions. When executed by first processor 31, the one or more computer instructions can implement the following steps: creating a control component in a target physical host hosted by a hosting delivery platform; creating a virtual host delivered to a user in the target physical host, so that the control component controls the virtual host or a container corresponding to the virtual host according to the received control instructions. The virtual host runs in a virtual private cloud (VPC), and the container is created by the user and runs in a container network. Optionally, processor 31 is further used to execute all or part of the steps in the embodiments shown in Figures 4 and 5 above. The electronic device may also include a communication interface 33 for communicating with other devices or communication systems. In addition, embodiments of the present disclosure provide a computer storage medium for storing computer software instructions used by the electronic device, including the program for executing the device management method shown in Figures 4 and 5 above. In addition, the embodiments of the present disclosure further provide a computer program. When the computer program is executed in a computer, it causes the computer to execute the programs involved in the device management method shown in FIG. 4 to FIG. 5 .Finally, it should be noted that the above embodiments are merely illustrative of the technical solutions of the present disclosure and are not intended to limit the present disclosure. Although the present disclosure has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they may modify the technical solutions described in the aforementioned embodiments or replace some of the technical features therein with equivalents. However, such modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present disclosure.

Claims

Claims 1. A physical host, which is hosted by a device management platform, and the physical host includes: A control component and virtual hosts running in the physical host, the control component and the virtual hosts are created by the device management platform, and the virtual hosts delivered to the user run in a virtual private cloud (VPC); the control component is used to receive control instructions; and control the running status of the virtual machine host or the container corresponding to the virtual host, and the container is created by the user and runs in a container network.

2. The host according to claim 1, wherein the control instruction includes a container creation instruction; the control component includes: A forwarding sub-component, which is used to receive the container creation instruction; The virtual host is used to create a container in response to the container creation instruction, and the container includes the secure container running in the running environment provided by the target physical host and / or the container running in the isolation environment where the virtual host is located.

3. The host according to claim 1 or 2, wherein the control instruction includes a status control instruction; the virtual machine host includes a cloud server; the control component includes: A forwarding sub-component, which is used to receive the status control instruction generated by the container orchestration tool for the container or the status control instruction generated by the server management tool for the cloud server.

4. The host according to claim 2, wherein the forwarding sub-component is used to, after receiving the container creation instruction, in response to the call of the virtual host to the forwarding sub-component, create a virtual network card corresponding to the container; use the virtual network card corresponding to the container to receive the data acquisition request generated by the container; and forward the data acquisition request to the gateway of the VPC where the virtual host is located, so that the gateway forwards the data acquisition request to other networks.

5. The host according to claim 4, wherein the forwarding sub-component is used to allocate routing information to the virtual network card corresponding to the container; and forward the data acquisition request to the gateway according to the routing information.

6. The host according to claim 4 or 5, wherein the control component further comprises: The storage driver of the network storage device; The storage driver is used to mount the network storage device for the virtual host; The container is used to generate the data acquisition request; Use the storage driver to access the network storage device mounted by the virtual host to obtain the target data corresponding to the data acquisition request.

7. The host according to claim 4 or 5, wherein the physical host further includes a local storage device; the container is used to generate a data acquisition request; and access the local storage device to obtain the target data corresponding to the data acquisition request.

8. The host according to any one of claims 1 to 7, wherein the control component further comprises: A detection sub-component, which is used to detect the running status of the virtual machine host and / or the container corresponding to the virtual host.

9. A device management method, comprising: Create a control component in the target physical host hosted by the hosting and delivery platform; Create a virtual host delivered to the user in the target physical host, so that the control component controls the virtual host or the container corresponding to the virtual host according to the received control instruction, the virtual host runs in a virtual private cloud (VPC), and the container is created by the user and runs in a container network.

10. The method according to claim 9, wherein the creating the control component comprises: In response to the delivery request of the user, obtain the user requirement information in the delivery request; Create a sub-component corresponding to the user requirement information in the target physical host, so that the control component is composed of the sub-components.

11. The method according to claim 10, before creating the control component, the method further includes: In response to the delivery request, obtain the configuration information of the alternative physical hosts on the device management platform; Among the alternative physical hosts, determine the physical host whose configuration information matches the user requirement information as the target physical host.

12. The method according to claim 11, wherein the method further comprises: Receive the operation status data of the alternative physical hosts; The determining, among the alternative physical hosts, the physical host whose configuration information matches the user requirement information as the target physical host includes: according to the operation status data, determine the physical hosts that are running normally among the alternative physical hosts; Among the physical hosts that are running normally, determine the physical host whose configuration information matches the requirement information as the target physical host.

13. The method according to any one of claims 10 to 12, wherein the creating the control component comprises: According to the user requirement information, create the control component including the storage driver, so that the storage driver mounts a network storage device for the virtual host created in the target physical host.

14. A device management platform, comprising: A hosting sub-platform and a delivery sub-platform; the hosting sub-platform is used to store the configuration information of the hosted alternative physical hosts; The delivery sub-platform is used to determine the target physical host among the alternative physical hosts according to the configuration information; In the target physical host, create a control component; Create a virtual host delivered to the user in the target physical host, so that the virtual host controls the virtual host or the container corresponding to the virtual host according to the control instructions received by the control component. The virtual host runs in a virtual private cloud (VPC), and the container is created by the user and runs in a container network.

15. A physical host, comprising: A memory and a processor; wherein, executable code is stored on the memory, and when the executable code is executed by the processor, the processor executes the device management method according to any one of claims 9 to 13.

16. A non-transitory machine-readable storage medium, on which executable code is stored. When the executable code is executed by a processor of an electronic device, the processor executes the device management method according to any one of claims 9 to 13.

17. A computer program, when the computer program is executed in a computer, causes the computer to execute the device management method according to any one of claims 9 to 13.

Images