Cloud service deployment

Abstract

The present disclosure provides a cloud service deployment method, a system, a device, a product, and a medium. The method comprises: sending a key update request regarding a deployment environment to a cloud service management and control system, so as to trigger the cloud service management and control system to update a key for a cloud service provider specified by the key update request; storing an updated key acquired by the cloud service management and control system for the cloud service provider; and the cloud service deployment system using the updated key to pull the deployment environment corresponding to a cloud service. Accordingly, the continued validity of keys for cloud service providers can be ensured on the basis of the key update mechanism provided in the embodiments of the present application. Thus, when supplementary deployment needs to be performed for a cloud service, this ensures that a cloud service deployment system is able to use a valid key to pull a required deployment environment in an unimpeded manner, thereby completing supplementary deployment. This effectively addresses the problem of deployment barriers in cloud service deployment systems impeding supplementary deployment.

Description

Cloud service deployment Technical Field

[0001] This disclosure relates to the field of cloud service technology, and more specifically, to cloud service deployment. Background Technology

[0002] Cloud service providers can offer a variety of cloud services, each with its own deployment platform. Cloud service providers can host these deployment platforms on a cloud service management system, which can create dedicated namespaces for service providers to ensure the isolation of deployment platforms between different service providers.

[0003] Currently, the cloud service management system can assign temporary keys to each cloud service provider and use the corresponding temporary keys to manage the cloud service deployment system's access permissions to the deployment platform when cloud services need to be deployed, so as to complete the deployment of cloud services.

[0004] However, based on this cloud service deployment method, deployment permissions need to be verified when the cloud service deployment system pulls the deployment carrier, which brings deployment obstacles to the cloud service deployment system and results in insufficient deployment flexibility. Summary of the Invention

[0005] This embodiment provides a cloud service deployment method, system, device, product, and medium to address deployment obstacles in cloud service deployment systems.

[0006] This embodiment provides a cloud service deployment method applicable to a cloud service deployment system, comprising: sending a key update request for the deployment carrier to a cloud service management system to trigger the cloud service management system to update the key for the cloud service provider targeted by the key update request, wherein the key is used to verify deployment permissions; storing the updated key obtained by the cloud service management system for the cloud service provider; and, when it is necessary to supplement the deployment of any cloud service provided by the cloud service provider, using the updated key to retrieve the deployment carrier corresponding to the cloud service to complete the supplementary deployment.

[0007] This embodiment provides a cloud service deployment method applicable to a cloud service management system, comprising: receiving a key update request for a deployment carrier sent by a cloud service deployment system; updating the key for the cloud service provider targeted by the key update request to obtain an updated key, the key being used to verify deployment permissions; and providing the updated key to the cloud service deployment system so that, when the cloud service deployment system needs to perform supplementary deployment of any cloud service provided by the cloud service provider, it can use the updated key to retrieve the deployment carrier corresponding to the cloud service to complete the supplementary deployment.

[0008] This embodiment provides a cloud service processing system, including: a cloud service deployment system and a cloud service management system; the cloud service deployment system is used to send a key update request for the deployment carrier to the cloud service management system; and to store the updated key obtained by the cloud service management system for the cloud service provider, the key being used to verify deployment permissions; and, when supplementary deployment of any cloud service provided by the cloud service provider is required, to use the updated key to retrieve the deployment carrier corresponding to the cloud service to complete the supplementary deployment; the cloud service management system is used to update the key for the cloud service provider targeted by the key update request; and to provide the obtained updated key to the cloud service deployment system.

[0009] This application embodiment also provides a cloud service deployment system, including: a request sending unit, configured to send a key update request for a deployment carrier to a cloud service management system, thereby triggering the cloud service management system to update the key for the cloud service provider targeted by the key update request, the key being used to verify deployment permissions; a key storage unit, configured to store the updated key obtained by the cloud service management system for the cloud service provider; and a deployment carrier retrieval unit, configured to use the updated key to retrieve the deployment carrier corresponding to the cloud service when supplementary deployment of any cloud service provided by the cloud service provider is required, in order to complete the supplementary deployment.

[0010] This application embodiment also provides a cloud service management system, including: a request receiving unit, used to receive a key update request for a deployment carrier sent by a cloud service deployment system; a key update unit, used to update the key for the cloud service provider targeted by the key update request, to obtain an updated key, the key being used to verify deployment permissions; and a key return unit, used to provide the updated key to the cloud service deployment system, so that when the cloud service deployment system needs to perform supplementary deployment of any cloud service provided by the cloud service provider, it can use the updated key to pull the deployment carrier corresponding to the cloud service to complete the supplementary deployment.

[0011] This application also provides a computing device, including a memory and a processor; the memory is used to store one or more computer instructions; the processor is coupled to the memory and is used to execute the one or more computer instructions to perform the aforementioned cloud service deployment method.

[0012] This application also provides a computer-readable storage medium that, when the computer instructions are executed by one or more processors, causes the one or more processors to perform the aforementioned cloud service deployment method.

[0013] This application also provides a computer program product, including a computer program, wherein when the computer program is executed by a processor, the processor performs the aforementioned cloud service deployment method.

[0014] In this embodiment, the cloud service deployment system sends a key update request for the deployment carrier to the cloud service management system, triggering the cloud service management system to update the key for the cloud service provider targeted by the key update request. The key is used to verify deployment permissions. The cloud service deployment system can store the updated key obtained by the cloud service management system for the cloud service provider. When supplementary deployment of any cloud service provided by the cloud service provider is required, the cloud service deployment system can use the updated key to retrieve the corresponding deployment carrier for the cloud service to complete the supplementary deployment. Therefore, based on the key update mechanism proposed in this embodiment, the continued validity of the key for the cloud service provider can be guaranteed. This ensures that when supplementary deployment of a cloud service is required, the cloud service deployment system can use a valid key to retrieve the required deployment carrier without obstacles, thereby completing the supplementary deployment. This effectively solves the deployment obstacles of the cloud service deployment system and improves the deployment flexibility of cloud services. Attached Figure Description

[0015] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0016] Figure 1 is a schematic diagram of the structure of a cloud service processing system provided in an exemplary embodiment of this application;

[0017] Figure 2 is a schematic diagram of the optional implementation logic of a cloud service deployment scheme provided by an exemplary embodiment of this application;

[0018] Figure 3 is an interactive flowchart of a cloud service deployment scheme provided by an exemplary embodiment of this application;

[0019] Figure 4 is a flowchart illustrating a cloud service deployment method provided in another exemplary embodiment of this application;

[0020] Figure 5 is a flowchart illustrating another cloud service deployment method provided in another exemplary embodiment of this application;

[0021] Figure 6 is a schematic diagram of the structure of a cloud service deployment system provided in another exemplary embodiment of this application;

[0022] Figure 7 is a schematic diagram of the structure of a cloud service management system provided in another exemplary embodiment of this application;

[0023] Figure 8 is a schematic diagram of the structure of a computing device provided in another exemplary embodiment of this application. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0025] Before proceeding with a detailed description of the technical solutions provided in the various embodiments of this application, the following is a brief explanation of several technical concepts involved in this application.

[0026] A cloud service deployment system can be understood as a cloud computing cluster used to deploy cloud services. A cloud service deployment system typically includes a control plane and a data plane. The data plane hosts the service instances deployed for the cloud service, while the control plane orchestrates and manages these service instances. Service instances can be implemented in various forms, such as cloud servers, containers, or virtual machines, and are not limited here.

[0027] A cloud service management system can be understood as a cloud integration platform used to manage various cloud services on the cloud. Users can manage various software services subscribed to on the cloud through the cloud service management system, and cloud service providers can deploy and manage cloud services on the cloud through the cloud service management system.

[0028] As described in the background section, cloud service management systems can assign temporary keys to various cloud service providers and use these temporary keys to manage the cloud service deployment system's access to the deployment platform when cloud services need to be deployed, thereby completing the deployment of the cloud service. However, based on this cloud service deployment method, the cloud service deployment system needs to verify deployment permissions when pulling the deployment platform, which introduces deployment obstacles for the cloud service deployment system.

[0029] Therefore, this embodiment proposes a cloud service deployment scheme to address deployment obstacles in cloud service deployment systems.

[0030] The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0031] Figure 1 is a schematic diagram of the structure of a cloud service processing system provided in an exemplary embodiment of this application. Referring to Figure 1, the system includes a cloud service deployment system and a cloud service management system.

[0032] In this embodiment, the type of cloud service deployment system is not limited. The type of cloud service deployment system will vary depending on the type of service instance to be deployed. For example, when the service instance to be deployed is a container, the cloud service deployment system in this embodiment can be a container deployment system, such as the Kubernetes-based cloud container service system (Alibaba Cloud Container Service for Kubernetes, ACK), etc. No further examples will be given here.

[0033] In this embodiment, a cloud service provider can provide one or more cloud services, and the deployment carrier required to deploy different cloud services is different.

[0034] The deployment carrier can be understood as the various resources and files required for deploying cloud services. This embodiment does not limit the type of deployment carrier; the type of deployment carrier varies depending on the type of service instance to be deployed. For example, if a user needs to deploy a cloud service based on a service instance such as an Elastic Compute Service (ECS), the deployment carrier can be an Elastic Compute Service (ECS) image; if a user needs to deploy a cloud service based on a service instance such as a container, the deployment carrier can be a container image. Further examples of deployment carrier types are not provided here.

[0035] In this embodiment, the cloud service deployment system can provide the necessary infrastructure and operating environment for the cloud service based on the deployment carrier. Therefore, when a cloud service needs to be deployed, the cloud service deployment system in this embodiment can retrieve the deployment carrier corresponding to the cloud service and create a service instance corresponding to the cloud service based on the deployment carrier, thereby deploying the cloud service.

[0036] As mentioned earlier, the cloud service management system in this embodiment can be used to manage various cloud services on the cloud. During the research process, the inventors discovered that some cloud service management systems currently provide deployment carrier repositories. As the name suggests, a deployment carrier repository is a storage system used to store deployment carriers for cloud service providers. Based on this, cloud service providers can host various deployment carriers they provide in the deployment carrier repository.

[0037] For example, a deployment carrier repository can also be implemented as a special cloud service, such as the Alibaba Cloud Container Registry (ACR). ACR has container image hosting capabilities, which facilitates the management of cloud services corresponding to container images by cloud service management systems. Further examples of deployment carrier repository product implementations will not be provided here.

[0038] Furthermore, since the cloud service management system needs to provide management services for multiple cloud service providers, the deployment carriers of these providers will be hosted in the same deployment carrier repository. To ensure isolation between different cloud service providers, the cloud service management system currently adopts a one-cloud-service-venue-per-venue approach, isolating and hosting deployment carriers for different cloud service providers in the deployment carrier repository. Based on this, cloud service providers can host the deployment carriers corresponding to their cloud services in the corresponding namespaces. This ensures that deployment carriers of the same cloud service provider reside in the same namespace, thereby preventing interference between deployment carriers of different cloud service providers and facilitating access control and management of the deployment carrier repository based on namespaces. Namespaces can be created based on the cloud service provider's identity information; for example, if the cloud service provider's identity identifier is uid1, then the namespace created for that cloud service provider can be named uid1.

[0039] Figure 2 is a schematic diagram of an optional implementation logic of a cloud service deployment scheme provided by an exemplary embodiment of this application. Referring to Figure 2, two namespaces are exemplified in the deployment carrier repository provided by the cloud service management system. Each namespace corresponds to a cloud service provider and is named according to the identity information of the corresponding cloud service provider. That is, namespace uid1 corresponds to cloud service provider uid1. Namespace uid1 stores deployment carrier 1 and deployment carrier 2 of cloud service provider uid1, and namespace uid2 stores deployment carrier 3 and deployment carrier 4 of cloud service provider uid2.

[0040] During their research, the inventors also discovered that, currently, to ensure the security of deployment platforms, deployment platform repositories assign temporary keys to deployment platforms from different cloud service providers to verify deployment permissions. In other words, when deploying a cloud service, the correct temporary key is required to retrieve the necessary deployment platform and complete the cloud service deployment.

[0041] Currently, the deployment carrier repository provides the temporary keys allocated by the cloud service provider to the cloud service management system. The cloud service management system can then deploy cloud services based on these temporary keys. However, these temporary keys have an expiration date, which the cloud service management system is unaware of. This means that when the cloud service management system performs a one-time deployment of a cloud service, the temporary keys used can successfully pass the verification of the deployment carrier repository, allowing it to retrieve the required deployment carrier without difficulty. However, if subsequent re-deployments of the cloud service are needed, the deployment carrier repository will prohibit the retrieval of the relevant deployment carriers due to the expired temporary keys. This results in the cloud service deployment system being unable to retrieve the required keys during re-deployments, causing the re-deployment to fail.

[0042] To address this, this embodiment proposes a key update mechanism: the cloud service deployment system can leverage the cloud service management system to update the keys for cloud service providers in a timely manner, thereby ensuring that the cloud service deployment system can maintain valid keys for cloud service providers. In this way, when supplementary deployment of cloud services is required, the cloud service deployment system can use the valid key to retrieve the corresponding deployment platform for the cloud service, thus completing the supplementary deployment without obstacles.

[0043] In this embodiment, supplementary deployment can be understood as follows: after a cloud service has been deployed once, if it is necessary to expand the number of service instances for the cloud service, then more service instances need to be deployed for that cloud service. As mentioned earlier, the creation of service instances depends on the deployment carrier. Therefore, during the supplementary deployment phase, the cloud service deployment system needs to pull the deployment carrier to create more service instances for the cloud service.

[0044] Referring to Figure 1, based on the key update mechanism proposed in this embodiment, the cloud service deployment system can send a key update request to the cloud service management system. After receiving the key update request, the cloud service management system can obtain the updated key for the cloud service provider targeted by the key update request.

[0045] It is understood that the cloud service management system does not proactively perform key updates. In this embodiment, the key update operation is driven by a key update request sent by the cloud service deployment system to obtain the updated key. Here, the timing of sending the key update request is not limited, nor is the triggering method used to trigger the key update request further limited. An optional implementation method for triggering the key update request will be proposed later.

[0046] This embodiment does not limit the implementation method used by the cloud service management system to obtain the updated key for the cloud service provider. In one optional implementation: The exemplary mechanism mentioned above, where the deployment carrier repository provided by the cloud service management system issues temporary keys, can be adopted. Based on this, after receiving a key update request, the cloud service management system can request the deployment carrier repository to issue a new key for the cloud service provider targeted by the key update request. In this way, the cloud service management system can obtain the required updated key from the deployment carrier repository. As shown in Figure 2, when the cloud service management system receives a key update request, it can trigger the deployment carrier repository to regenerate a temporary key for the corresponding cloud service. The deployment carrier repository then feeds back this temporary key to the cloud service management system as the updated key for that cloud service provider. That is, the cloud service management system can obtain the required updated key by calling the deployment carrier repository.

[0047] It is worth noting that, optionally, in this embodiment, the cloud service management system can also respond to the key update request sent in this embodiment using other implementation methods. For example, the cloud service management system can autonomously manage the keys. In this way, after receiving the key update request, the cloud service management system can autonomously allocate the updated key to the corresponding cloud service provider and synchronize it to the deployment carrier system. Here, no further examples are given of the implementation method of the cloud service management system responding to the key update request; it is sufficient to ensure that the cloud service management system can return the required updated key to the cloud service deployment system in this embodiment.

[0048] In practical applications, all deployment platforms provided by a cloud service provider can share the same key. Of course, different keys can also be issued for different deployment platforms provided by the same cloud service provider. This embodiment does not limit this.

[0049] Referring again to Figure 1, based on the key update mechanism proposed in this embodiment, the cloud service deployment system can store the updated key after receiving it from the cloud service management system.

[0050] In this embodiment, the method and location of storing the key in the cloud service deployment system are not limited. The key can be stored according to its usage scenario or importance. Several exemplary storage schemes will be provided later.

[0051] In this step, the cloud service deployment system can use an overwrite approach, replacing the old key with the updated key. This allows the cloud service deployment system to iteratively store keys for the cloud service provider, thereby ensuring the validity of the stored keys.

[0052] Based on this, and using the key update mechanism provided in this embodiment, permission support can be provided to the cloud service deployment system during the supplementary deployment phase. This ensures that the cloud service deployment system can successfully retrieve the required deployment carrier using a valid key, thus completing the supplementary deployment of the cloud service. Here, the method by which the cloud service deployment system retrieves the deployment carrier is not limited; an optional implementation method for retrieving the deployment carrier will be proposed later.

[0053] In summary, as described above, in this embodiment, the cloud service deployment system sends a key update request for the deployment carrier to the cloud service management system, triggering the cloud service management system to update the key for the cloud service provider targeted by the key update request. The key is used to verify deployment permissions. The cloud service deployment system stores the updated key obtained by the cloud service management system for the cloud service provider. When supplementary deployment of any cloud service provided by the cloud service provider is required, the cloud service deployment system uses the updated key to retrieve the corresponding deployment carrier for the cloud service to complete the supplementary deployment. Therefore, based on the key update mechanism proposed in this embodiment, the continued validity of the key for the cloud service provider can be guaranteed. Thus, when supplementary deployment of cloud services is required, the cloud service deployment system can use the required valid key to enable it to retrieve the necessary deployment carrier without obstacles, thereby completing the supplementary deployment. This effectively solves the deployment obstacles of the cloud service deployment system.

[0054] In the embodiments described above or below, key update requests can be issued in various ways. One optional implementation is provided below.

[0055] This optional implementation proposes that the cloud service deployment system may include dedicated key update components enabled for different cloud service providers. Based on this, the cloud service deployment system can utilize each enabled key update component to initiate a key update request separately.

[0056] This optional implementation proposes an "isolated update" design concept. The cloud service deployment system can isolate the key update process for different cloud service providers by launching different key update components for different cloud servers. In other words, each key update component corresponds to one cloud service provider.

[0057] Accordingly, the cloud service deployment system can initiate key update requests to the cloud service management system through different enabled key update components, thereby enabling key updates for different cloud service providers. This allows for the isolation of the key update process for different cloud service providers within the cloud service deployment system. Furthermore, since the key update process for each cloud service provider is independent, even if one key update component is attacked, it will not affect the key update process for other cloud service providers, effectively reducing the risk of information leakage.

[0058] In the above or following embodiments, based on the aforementioned isolated update design concept, various triggering methods can be used to trigger the key update component to issue a key update request. Figure 3 is an interactive flowchart of a cloud service deployment scheme provided by an exemplary embodiment of this application. The following, in conjunction with Figure 3, provides an optional triggering method.

[0059] The optional triggering method proposes that the cloud service deployment system can use any enabled key update component to periodically send key update requests for the deployment carrier to the cloud service management system.

[0060] In other words, a timed triggering mechanism can be used to trigger each key update component to issue a key update request.

[0061] Understandably, the timed triggering mechanism is an automatic triggering mechanism. Based on this mechanism, each key update component can continuously send key update requests to the cloud service management system according to a preset cycle, so that the cloud service management system can continuously and automatically update the keys, reduce errors caused by manual operation, and thus keep the keys in a valid state.

[0062] A preferred implementation of the aforementioned timed triggering mechanism could be as follows: In the cloud service deployment system, a timed triggering task can be created for the key update component, and an update cycle is defined in the timed triggering task; The cloud service deployment system uses the key update component to execute the timed triggering task, so as to send a key update request for the deployment carrier to the cloud service management system at regular intervals according to the update cycle.

[0063] As mentioned earlier, in a cloud service deployment system, the key update process for different cloud service providers is independent of each other. Therefore, the update cycle set for different cloud service providers can be different. Here, the update cycle can be set according to the specific application scenario. The update cycle is usually shorter than the key expiration time to trigger the key update request in a timely manner, and no restrictions are imposed here.

[0064] In this preferred implementation, scheduled tasks can be created based on Kubernetes CronJob resources. A Kubernetes CronJob resource can be understood as a resource object in Kubernetes used to trigger tasks according to a predetermined schedule. Besides the update cycle, other information can be configured in the scheduled task, such as key identifiers and deployment carrier description information such as the name and location of the deployment carrier. The following is an example of a YMAL file used to create a scheduled task:

[0065] Based on the aforementioned YAML file, a scheduled task (i.e., the aforementioned Kubernetes CronJob resource) can be created using the declarative API mechanism supported by the cloud service deployment system. Here, `apiVersion` describes the version of the API group in Kubernetes; `batch / v1` refers to version v1 within the `batch` group, which can be understood as an interface group within the API group. `kind:CronJob` describes the resource type to be created as a CronJob. `metadata` describes the metadata of the CronJob. For example, if the CronJob name is set to `refresh-secret-cronjob` and the update rule `schedule: "** / 2***"`, it indicates that the update cycle is 2 hours. The fields in `"** / 2***"` can represent seconds, minutes, hours, dates, months, and days of the week, respectively. With a 2-hour update cycle, the key update component will send a key update request every 2 hours. `jobTemplate` defines the template for the Job object created when the CronJob is executed. The Job ensures that the key update component can successfully complete the scheduled task. `refresh-secret-serviceaccount` describes the operations that the scheduled task needs to perform. The key update component comprises multiple containers, which can execute scheduled tasks. `refresh-secret` describes the container name, and `compute-nest-registry.cn-hangzhou.cr.aliyuncs.com / public / auto-refresh-secret:v1` describes the location of the deployment carrier the container needs to pull, where `auto-refresh-secret` is the deployment carrier name. `SECRET_NAME` is a defined environment variable related to the key, with a value of `computenestrepo`, used to import the key identifier corresponding to the key to be updated in the scheduled task. `restartPolicy:OnFailure` describes the container's restart policy, meaning that the container needs to be restarted if it exits abnormally.

[0066] Accordingly, the cloud service deployment system creates a scheduled trigger task for the key update component to send key update requests to the cloud service management system at regular intervals, thereby triggering the cloud service management system to change the key periodically. This reduces the complexity of manual operation and improves the deployment efficiency of deploying cloud services using the updated key.

[0067] It is worth noting that, in addition to the timed triggering mechanism mentioned in the optional triggering methods above, other triggering methods can also be used in this embodiment to send key update requests to the cloud service management system. For example, a passive triggering mechanism, that is, when the cloud service provider / user initiates a triggering event, a key update request regarding the deployment carrier is passively sent to the cloud service management system. No further examples or explanations will be provided here.

[0068] In the above or following embodiments, based on the aforementioned design concept of isolated updates, various implementation methods can be used to send key update requests to the cloud service management system. The following, with reference to Figure 3, provides one optional implementation method.

[0069] In this optional implementation, it is proposed that: the cloud service deployment system uses any enabled key update component to send a key update request, which does not yet carry cloud service provider identity information, to the management unit used to manage the key update components; the management unit adds the identification information corresponding to the key update component to the key update request and forwards it to the cloud service management system; for the cloud service management system, the cloud service provider to which the key update component belongs can be determined based on the identification information.

[0070] As mentioned earlier, the cloud service deployment system includes multiple key update components, each corresponding to a cloud service provider. In this optional implementation design, the key update components do not need to be aware of the cloud service provider they serve. The key update requests issued by the key update components do not carry the cloud service provider's identity information. This ensures that even if the key update component is attacked, the attacker cannot tamper with the cloud service provider targeted by the key update request, and therefore cannot use the keys of other cloud service providers without authorization. This prevents the key update component from becoming a vulnerability for unauthorized access to the deployment platform.

[0071] As mentioned earlier, the cloud service management system needs to update the keys for the cloud service provider targeted by the key update request. Therefore, the cloud service management system needs to be able to identify the target cloud service provider from the key update request. In this optional implementation, the key update request issued by the key update component does not carry cloud service provider identity information. Therefore, this implementation proposes that identification information can be added to the key update request by the management unit to assist the cloud service management system in identifying the target cloud service provider.

[0072] The management unit can be understood as an existing management tool used to manage the key update component, such as ECS Cloud Assistant, etc., without further examples here. The management unit can be deployed internally within the cloud service deployment system as a functional component. Alternatively, it can be deployed externally as an independent cloud service; the deployment location of the management unit is not limited here, nor will further examples be provided. It is worth noting that the management unit used here is neutral and secure, and the identification information it provides is tamper-proof. Because the identification information on the management unit cannot be tampered with, adding identification information to the key update request through the management unit can objectively describe the targeted cloud service provider. Thus, even if the key update component is attacked, it will not affect the cloud service provider targeted by the key update request.

[0073] As can be seen, the identification information corresponding to the key update component cannot be tampered with. Therefore, it is safe to add the identification information corresponding to the key update component to the key update request through the management unit. This can provide secure reference information for the cloud service management system to determine the cloud service provider to which the key update request is targeted.

[0074] In this optional implementation, the key update request issued by the key update component does not carry the cloud service provider's identity information. This weakens the decisive influence of the key update component on the key update process, thereby preventing malicious users from tampering with the cloud service provider targeted by the key update request by attacking the key update component, and thus avoiding the risk of unauthorized access to the deployment carrier.

[0075] As mentioned earlier, in this optional implementation, the cloud service management system can determine the cloud service provider to which the key update component belongs based on the identification information. To this end, a further implementation scheme is proposed for this optional implementation: the cloud service management system can, with the help of the immutable information in the tag system, reconstruct the cloud service provider to which the key update request is targeted based on the aforementioned identification information carried in the key update request.

[0076] In this further implementation: the cloud service management system can determine the target service instance where the key update component resides based on the identification information; the cloud service management system queries the tag information corresponding to the target service instance from the tag system, and the tag information describes the target cloud service to which the target service instance belongs; the cloud service management system determines the cloud service provider corresponding to the target cloud service, which is then used as the cloud service provider to which the key update component belongs. Here, the target service instance can be a cloud server (Elastic Compute Service, ECS), or a virtual machine, or other types.

[0077] The tagging system is an operations and maintenance service used for group-based management and control in the cloud. It records tag information for service instances of various cloud services. This tag information describes group attributes associated with each service instance, including but not limited to environment tags and operating system tags. These attributes are used to categorize the tagged service instances into the corresponding management groups, enabling group-based management and control of service instances. The tag information also includes identity descriptions such as the service instance identifier, its location, and the cloud service it belongs to. These identity descriptions are objective and immutable. In this optional implementation, the cloud service information contained in the tag information is used to assist the cloud service management system in locating the cloud service provider.

[0078] As mentioned earlier, the management unit has added the identification information corresponding to the key update component to the key update request. This identification information indicates the target service instance where the key update component resides. Based on this, in this further implementation, the cloud service management system can locate the target service instance where the key update component resides based on the identification information of the key update component. The cloud service management system can then use a tagging system to find the tag information associated with the target service instance and locate the target cloud service to which the target service instance belongs from the tag information. On this basis, the cloud service management system can determine the specific cloud service provider corresponding to the target cloud service, which is the cloud service provider targeted by the key update request.

[0079] Accordingly, the cloud service management system can use the tagging system to find the cloud service provider targeted by the key update request. Since the tag information in the tagging system cannot be modified by malicious users, the process of determining the cloud service provider through the tagging system is secure, thereby ensuring the accuracy of the cloud service provider found by the cloud service management system.

[0080] In summary, based on the above description, by leveraging the immutable information provided by the aforementioned management unit and tagging system, the target cloud service provider can be objectively described in the key update request without the key update component being aware of it. In this way, even if a malicious user attacks the key update component, they will not be able to tamper with the cloud service provider targeted by the key update request, thereby effectively ensuring the security of the cloud service provider's keys and avoiding the risk of unauthorized access to the deployment platform.

[0081] It is understandable that, besides the optional implementation methods described above that utilize other units to depict cloud service providers, other implementation methods can also be used to send key update requests to the cloud service management system. For example, the cloud service deployment system can directly add the cloud service provider's identity information to the key update component, so that the key update component can directly send key update requests carrying the cloud service provider's identity information to the cloud service management system. The cloud service management system can also determine the cloud service provider to which the key update component belongs. Further examples of implementation methods will not be provided here.

[0082] In the above or following embodiments, various implementation methods can be used to pull the deployment carrier corresponding to the required cloud service during the supplementary deployment phase. One optional implementation method is provided below.

[0083] In this optional implementation, it is proposed that: in response to a supplementary deployment request for any cloud service provided by a cloud service provider, the cloud service deployment system looks up the target key stored by the cloud service provider. The target key is the last updated key obtained by the cloud service provider. The cloud service deployment system uses the target key to pull the deployment carrier corresponding to the cloud service to complete the supplementary deployment.

[0084] The supplementary deployment request can be issued by a user who needs to supplement the cloud service deployment. This user can be a tenant renting the cloud service, or the cloud service deployment system can autonomously discover the supplementary deployment need and generate a supplementary deployment request to trigger the supplementary deployment phase. There are no restrictions on who initiates the supplementary deployment request. Accordingly, a supplementary deployment request is used to instruct the supplementary deployment of a specific cloud service. Optionally, the information carried in the supplementary deployment request may include, but is not limited to, the cloud service's identification information and the specifications of the service instance to be supplemented, etc., without further examples.

[0085] In this optional implementation, an exemplary search scheme for finding the target key is provided: the cloud service deployment system can determine the target cloud service provider to which the supplementary deployment request belongs based on the relationship between the cloud service and the cloud service provider; determine the target key identifier corresponding to the target cloud service provider based on the association between the cloud service provider and the key identifier; and use the key stored under the target key identifier as the target key.

[0086] In this exemplary search scheme, the cloud service deployment system maintains the aforementioned relationships between cloud services and cloud service providers, as well as the associations between cloud service providers and key identifiers. Furthermore, the cloud service deployment system can use key identifiers as indexes to store keys for cloud service providers. Therefore, in this exemplary query scheme, the cloud service deployment system can progressively find the target key required for the supplementary deployment request based on the maintained relationships and associations.

[0087] Accordingly, the cloud service deployment system can accurately find the target key required for supplementary deployment. Moreover, due to the continued validity of the target key, this ensures that the cloud service deployment system can successfully pass the deployment permission verification when pulling the deployment carrier during the supplementary deployment phase, thereby successfully pulling the required deployment carrier and completing the supplementary deployment.

[0088] In the above or following embodiments, various implementation methods can be used to store the updated key obtained by the cloud service management system for the cloud service provider. One optional implementation method is provided below.

[0089] In this optional implementation, it is proposed that: the cloud service deployment system can receive a request response returned by the cloud service management system in response to the key update request. The request response includes the updated key and the target key identifier corresponding to the updated key. The cloud service deployment system stores the updated key in the key storage space associated with the target key identifier. The key storage space associated with the target key identifier is created when the cloud service deployment system first receives a request response pointing to the target key identifier.

[0090] As can be seen, since each cloud service provider has a different key, the cloud service deployment system can allocate corresponding key storage space for different cloud service providers to distinguish their updated keys. The key storage space can be named using the key identifier corresponding to the cloud service provider. When the cloud service deployment system first obtains the key identifier sent by the cloud service management system, it can create the corresponding key storage space based on that key identifier, thereby isolating the updated keys from different cloud service providers. In an optional implementation, the updated key can be stored in the key storage space in a secure (secret) manner. A secret can be understood as a security mechanism used to specially encode the data to be stored and then store the encoded result in a designated storage space to improve data storage security. Here, the updated key is the data to be stored under this security mechanism. Thus, the updated key is equivalent to being encrypted during storage, thereby improving the security of the key during storage.

[0091] Of course, the above storage methods are only optional. In addition, the updated key can also be stored in other locations, such as cloud databases. No further examples will be given here.

[0092] Furthermore, in this optional implementation, the timed triggering task mentioned in the previous embodiments is continued. This timed triggering task includes functional logic for performing key storage. Environment variables are also set in this functional logic to introduce the key identifier corresponding to the key that needs to be updated. Based on this, after receiving the request response from the cloud service management system regarding the key update request, the cloud service deployment system can parse the request response to obtain the key identifier provided by the cloud service management system and configure the key identifier into the environment variables in the timed triggering task. In this way, the cloud service deployment system can execute the functional logic for performing key storage in the timed triggering task, and determine which stored key needs to be updated according to the key identifier configured in the environment variables.

[0093] As described above, the cloud service deployment system can configure the key identifier in real time based on environment variables in the scheduled task and feedback from the cloud service management system. This guides the cloud service deployment system to accurately store the updated key. Since environment variables can be dynamically configured, the key identifier corresponding to the required updated key can be accurately transmitted to the cloud service deployment system without modifying the code in the scheduled task, effectively improving the flexibility of the key update process.

[0094] Accordingly, by setting key identifiers based on environment variables, the cloud service deployment system can avoid directly adding the corresponding key information to the scheduled tasks, thereby reducing the risk of key leakage based on scheduled tasks. It can also distinguish the key storage space corresponding to different cloud service providers based on key identifiers, and thus isolate different keys.

[0095] Figure 4 is a flowchart illustrating a cloud service deployment method provided in an exemplary embodiment of this application. This method can be executed by a cloud service deployment system, the product form of which can be a service cluster or a standalone server, etc. Referring to Figure 4, the method may include: Step S401: Sending a key update request for the deployment carrier to a cloud service management system to trigger the cloud service management system to update the key for the cloud service provider targeted by the key update request. The key is used to verify deployment permissions; Step S402: Storing the updated key obtained by the cloud service management system for the cloud service provider; Step S403: When supplementary deployment of any cloud service provided by the cloud service provider is required, using the updated key to retrieve the deployment carrier corresponding to the cloud service to complete the supplementary deployment.

[0096] In an optional embodiment, step S401 may include: initiating key update requests using each of the enabled key update components.

[0097] In an optional embodiment, the method may further include: sending a key update request, which does not yet carry cloud service provider identity information, to a management unit for managing key update components using any enabled key update component; adding the identification information corresponding to the key update component to the key update request through the management unit, and forwarding it to the cloud service management system, so that the cloud service management system can determine the cloud service provider to which the key update component belongs based on the identification information.

[0098] In an optional embodiment, the method may further include: using any enabled key update component to periodically send a key update request for the deployment carrier to the cloud service management system.

[0099] In an optional embodiment, the method may further include: creating a timed triggering task for the key update component, wherein the timed triggering task defines an update cycle; and using the key update component to execute the timed triggering task to periodically send a key update request for the deployment carrier to the cloud service management system according to the update cycle.

[0100] In an optional embodiment, step S402 may include: receiving a request response returned by the cloud service management system in response to the key update request, the request response including the updated key and a target key identifier corresponding to the updated key; storing the updated key in a key storage space associated with the target key identifier; wherein the key storage space associated with the target key identifier is created when a request response pointing to the target key identifier is first received.

[0101] In an optional embodiment, step S403 may include: in response to a supplementary deployment request for any cloud service provided by the cloud service provider, finding a target key stored by the cloud service provider, wherein the target key is the last updated key obtained by the cloud service provider; and using the target key to retrieve the deployment carrier corresponding to the cloud service to complete the supplementary deployment.

[0102] In an optional embodiment, the method may further include: determining the target cloud service provider to which the supplementary deployment request pertains based on the affiliation between the cloud service and the cloud service provider; determining the target key identifier corresponding to the target cloud service provider based on the association between the cloud service provider and the key identifier; and using the key stored under the target key identifier as the target key.

[0103] Figure 5 is a flowchart illustrating a cloud service deployment method provided in an exemplary embodiment of this application. This method can be executed by a cloud service management system. Referring to Figure 5, the method may include: Step S501: Receiving a key update request for a deployment carrier sent by a cloud service deployment system; Step S502: Updating the key for the cloud service provider targeted by the key update request to obtain an updated key, the key being used to verify deployment permissions; Step S503: Providing the updated key to the cloud service deployment system so that, when the cloud service deployment system needs to perform supplementary deployment of any cloud service provided by the cloud service provider, it can use the updated key to retrieve the deployment carrier corresponding to the cloud service to complete the supplementary deployment.

[0104] In an optional embodiment, step S502 may include: parsing the identification information corresponding to the key update component from the key update request, wherein the cloud service deployment system includes dedicated key update components enabled for different cloud service providers, and the key update request issued by the key update component does not yet carry cloud service provider identity information, and the identification information is added to the key update request by a management unit for managing the key update component; determining the cloud service provider to which the key update component belongs based on the identification information, as the cloud service provider targeted by the key update request; and updating the key for the cloud service provider.

[0105] In an optional embodiment, the method may further include: determining the target service instance where the key update component is located based on the identification information; querying the tag information corresponding to the target service instance from the tag system, wherein the tag information describes the target cloud service to which the target service instance belongs; and determining the cloud service provider corresponding to the target cloud service as the cloud service provider to which the key update component belongs.

[0106] The deployment process of the cloud service described above is described below with reference to Figure 3. This process is mainly implemented through the cloud service deployment system, cloud service management system, management unit, tag system and deployment carrier repository. The specific process is described as follows.

[0107] S301: The cloud service deployment system sends a key update request to the management unit.

[0108] S302: The management unit sends a key update request carrying the identification information corresponding to the key update component to the cloud service management system.

[0109] S303: The cloud service management system queries the tag information corresponding to the target service instance where the key update component is located from the tag system.

[0110] S304: The cloud service management system determines the cloud service provider to which the key update component belongs based on the identification information.

[0111] S305: The cloud service management system obtains the updated key corresponding to the cloud service provider from the deployment carrier repository.

[0112] S306: The cloud service management system will return the updated key to the management unit.

[0113] S307: The management unit returns the updated key to the cloud service deployment system.

[0114] S308: Cloud service deployment system storage update key.

[0115] As can be seen from the above description, the technical solution of this application has the following advantages.

[0116] (1) In this embodiment, a key update component is added to the cloud service deployment system. The key update component continuously triggers key update requests according to the timed triggering task, thereby continuously renewing the key according to the key update request to ensure that the key is in a valid state.

[0117] (2) In this embodiment, the security of key update and cloud service deployment stages is ensured by the tag information of the tag system and the identification information of the key update component added by the management unit. This prevents malicious users from maliciously tampering with the identity information of the cloud service provider in order to unauthorizedly pull the deployment carrier corresponding to the cloud service provided by the cloud service provider.

[0118] It is worth noting that the technical details of the above embodiments of the cloud service deployment method can be found in the relevant descriptions of the cloud service deployment system in the foregoing embodiments. To save space, they will not be repeated here, but this should not cause any loss to the scope of protection of this application.

[0119] Referring to Figure 6, which is a schematic diagram of a cloud service deployment system provided in an exemplary embodiment of this application, the system includes: a request sending unit 60, a key storage unit 61, and a deployment carrier retrieval unit 62; wherein: the request sending unit 60 is used to send a key update request for the deployment carrier to the cloud service management system, so as to trigger the cloud service management system to update the key for the cloud service provider targeted by the key update request, and the key is used to verify deployment permissions; the key storage unit 61 is used to store the updated key obtained by the cloud service management system for the cloud service provider; the deployment carrier retrieval unit 62 is used to retrieve the deployment carrier corresponding to the cloud service using the updated key when it is necessary to supplement the deployment of any cloud service provided by the cloud service provider, so as to complete the supplementary deployment.

[0120] In an optional embodiment, the cloud service deployment system includes dedicated key update components enabled for different cloud service providers. Each key update component includes a request sending unit 60 and a key storage unit 61. When the request sending unit 60 sends a key update request about the deployment carrier to the cloud service management system, it can specifically be used to: initiate key update requests respectively using each enabled key update component.

[0121] In an optional embodiment, when the request sending unit 60 initiates a key update request using any of the enabled key update components, it can also be used to: send a key update request that does not yet carry cloud service provider identity information to the management unit used to manage the key update components using any of the enabled key update components; through the management unit, add the identification information corresponding to the key update component to the key update request, and forward it to the cloud service management system, so that the cloud service management system can determine the cloud service provider to which the key update component belongs based on the identification information.

[0122] In an optional embodiment, when the request sending unit 60 initiates a key update request using any of the enabled key update components, it can also be used to: periodically send key update requests regarding the deployment carrier to the cloud service management system using any of the enabled key update components.

[0123] In an optional embodiment, when the request sending unit 60 periodically sends a key update request for the deployment carrier to the cloud service management system using any enabled key update component, it can also be used to: create a timed trigger task for the key update component, wherein the timed trigger task defines an update cycle; and execute the timed trigger task using the key update component to periodically send a key update request for the deployment carrier to the cloud service management system according to the update cycle.

[0124] In an optional embodiment, when storing the updated key obtained by the cloud service management system for the cloud service provider, the key storage unit 61 can also be used to: receive a request response returned by the cloud service management system in response to the key update request, the request response including the updated key and a target key identifier corresponding to the updated key; store the updated key in a key storage space associated with the target key identifier; wherein the key storage space associated with the target key identifier is created when a request response pointing to the target key identifier is first received.

[0125] In an optional embodiment, when the deployment carrier retrieval unit 62 needs to perform supplementary deployment for any cloud service provided by the cloud service provider, it uses the updated key to retrieve the deployment carrier corresponding to the cloud service to complete the supplementary deployment. Specifically, it can be used to: respond to a supplementary deployment request for any cloud service provided by the cloud service provider, find the target key stored by the cloud service provider, the target key being the last updated key obtained by the cloud service provider; and use the target key to retrieve the deployment carrier corresponding to the cloud service to complete the supplementary deployment.

[0126] In an optional embodiment, when the deployment carrier retrieval unit 62 searches for the target key stored by the cloud service provider, it can also be used to: determine the target cloud service provider to which the cloud service targeted by the supplementary deployment request belongs based on the relationship between the cloud service and the cloud service provider; determine the target key identifier corresponding to the target cloud service provider based on the association between the cloud service provider and the key identifier; and use the key stored under the target key identifier as the target key.

[0127] Referring to Figure 7, which is a schematic diagram of a cloud service management system provided in an exemplary embodiment of this application, the system includes: a request receiving unit 70, a key updating unit 71, and a key returning unit 72; wherein: the request receiving unit 70 is used to receive a key update request for the deployment carrier sent by the cloud service deployment system; the key updating unit 71 is used to update the key for the cloud service provider targeted by the key update request, and obtain the updated key, which is used to verify deployment permissions; the key returning unit 72 is used to provide the updated key to the cloud service deployment system, so that when the cloud service deployment system needs to supplement the deployment of any cloud service provided by the cloud service provider, it can use the updated key to pull the deployment carrier corresponding to the cloud service to complete the supplementary deployment.

[0128] In an optional embodiment, when updating the key for the cloud service provider targeted by the key update request, the key update unit 71 may specifically be used to: parse the identification information corresponding to the key update component from the key update request; wherein the cloud service deployment system includes dedicated key update components enabled for different cloud service providers; the key update request issued by the key update component does not yet carry cloud service provider identity information; the identification information is added to the key update request by a management unit for managing the key update component; based on the identification information, determine the cloud service provider to which the key update component belongs, as the cloud service provider targeted by the key update request; and update the key for the cloud service provider.

[0129] In an optional embodiment, when determining the cloud service provider to which the key update component belongs based on the identification information, the key update unit 71 can also be used to: determine the target service instance where the key update component is located based on the identification information; query the tag information corresponding to the target service instance from the tag system, wherein the tag information describes the target cloud service to which the target service instance belongs; and determine the cloud service provider corresponding to the target cloud service, as the cloud service provider to which the key update component belongs.

[0130] Referring to Figure 1, which is a schematic diagram of the structure of a cloud service processing system provided in an exemplary embodiment of this application, the system includes: a cloud service deployment system and a cloud service management system; wherein: the cloud service deployment system is used to send a key update request for the deployment carrier to the cloud service management system; store the updated key obtained by the cloud service management system for the cloud service provider, the key being used to verify deployment permissions; and, when supplementary deployment of any cloud service provided by the cloud service provider is required, use the updated key to pull the deployment carrier corresponding to the cloud service to complete the supplementary deployment; the cloud service management system is used to update the key for the cloud service provider targeted by the key update request; and provide the obtained updated key to the cloud service deployment system.

[0131] The cloud service processing system further includes a management unit; the cloud service deployment system includes dedicated key update components enabled for different cloud service providers, and when the cloud service deployment system sends a key update request for the deployment carrier to the cloud service management system, it is used to: use any of the enabled key update components to send a key update request, which does not yet carry cloud service provider identity information, to the management unit used to manage the key update components; the management unit is used to: add the identification information corresponding to the key update component to the key update request and forward it to the cloud service management system; the cloud service management system is used to: determine the cloud service provider to which the key update component belongs based on the identification information, and use it as the cloud service provider to which the key update request is targeted.

[0132] It is worth noting that the technical details of the above-mentioned embodiments of the cloud service deployment system can be referred to the relevant descriptions in the foregoing embodiments. To save space, they will not be repeated here, but this should not cause any loss to the scope of protection of this application.

[0133] Figure 8 is a schematic diagram of a computing device provided in an exemplary embodiment of this application. As shown in Figure 8, the computing device includes a memory 80 and a processor 81.

[0134] Memory 80 is used to store computer programs and can be configured to store various other data to support operation on the computing device. Examples of this data include instructions for any application or method operating on the computing device, contact data, phone book data, messages, pictures, videos, etc.

[0135] The memory 80 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0136] The processor 81, coupled to the memory 80, is used to execute the computer program in the memory 80 to implement the cloud service deployment method corresponding to the aforementioned cloud service management system or cloud service deployment system.

[0137] Furthermore, as shown in Figure 8, the computing device also includes other components such as a power supply component 82. Figure 8 only schematically shows some of the components and does not imply that the computing device includes only the components shown in Figure 8.

[0138] Accordingly, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed, can perform the steps that can be executed by the computing device described in the above embodiments.

[0139] Accordingly, this application also provides a computer program product, wherein the computer program contained herein, when executed, can perform the steps that can be executed by the computing device described above in the above embodiments.

[0140] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0141] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0142] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0143] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0144] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0145] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0146] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0147] It should also be noted that 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 limitation, 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.

[0148] 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, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, 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.

[0149] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A cloud service deployment method, applicable to a cloud service deployment system, comprising: Send a key update request for the deployment carrier to the cloud service management system to trigger the cloud service management system to update the key for the cloud service provider to which the key update request is directed. The key is used to verify deployment permissions. The cloud service management system stores the updated key obtained by the cloud service provider. If it is necessary to supplement the deployment of any cloud service provided by the cloud service provider, the updated key is used to pull the deployment carrier corresponding to the cloud service to complete the supplementary deployment.

2. The method of claim 1, wherein, The cloud service deployment system includes dedicated key update components enabled for different cloud service providers, which send key update requests regarding the deployment carrier to the cloud service management system, including: Each enabled key update component initiates a key update request.

3. The method of claim 2, wherein, Initiate a key update request using any of the enabled key update components, including: Use any enabled key update component to send a key update request that does not yet carry cloud service provider identity information to the management unit used to manage the key update component; The management unit adds the identification information corresponding to the key update component to the key update request and forwards it to the cloud service management system, so that the cloud service management system can determine the cloud service provider to which the key update component belongs based on the identification information.

4. The method of claim 2, wherein, Initiate a key update request using any of the enabled key update components, including: Using any of the enabled key update components, periodically send key update requests for the deployment carrier to the cloud service management system.

5. The method of claim 4, wherein, Using any of the enabled key update components, periodically send key update requests regarding the deployment carrier to the cloud service management system, including: For the key update component, a timed trigger task is created, wherein an update cycle is defined in the timed trigger task; The key update component is used to execute the timed triggering task, so as to send key update requests for the deployment carrier to the cloud service management system at regular intervals according to the update cycle.

6. The method of claim 1, wherein, In cases where supplementary deployment of any cloud service provided by the cloud service provider is required, the updated key is used to retrieve the deployment carrier corresponding to the cloud service to complete the supplementary deployment, including: In response to a supplemental deployment request for any cloud service provided by the cloud service provider, locate the target key stored by the cloud service provider, wherein the target key is the last updated key obtained by the cloud service provider; Using the target key, retrieve the deployment carrier corresponding to the cloud service to complete the supplementary deployment.

7. The method of claim 6, wherein, Locating the target key stored by the cloud service provider includes: Based on the affiliation between cloud services and cloud service providers, determine the target cloud service provider to which the supplementary deployment request belongs; Based on the association between cloud service providers and key identifiers, the target key identifier corresponding to the target cloud service provider is determined; The key stored under the target key identifier is used as the target key.

8. The method of claim 1, wherein, The cloud service management system stores the updated key obtained by the cloud service provider, including: Receive the request response returned by the cloud service management system in response to the key update request, wherein the request response contains the updated key and the target key identifier corresponding to the updated key; The updated key is stored in the key storage space associated with the target key identifier; The key storage space associated with the target key identifier is created when a request response pointing to the target key identifier is first received.

9. A cloud service deployment method, applicable to a cloud service management system, comprising: Receive a key update request for the deployment carrier from the cloud service deployment system; Update the key for the cloud service provider targeted by the key update request to obtain the updated key, which is used to verify deployment permissions; The updated key is provided to the cloud service deployment system so that, when the cloud service deployment system needs to supplement the deployment of any cloud service provided by the cloud service provider, it can use the updated key to pull the deployment carrier corresponding to the cloud service to complete the supplementary deployment.

10. The method of claim 9, wherein, Updating the key for the cloud service provider targeted by the key update request includes: The identification information corresponding to the key update component is parsed from the key update request. The cloud service deployment system includes dedicated key update components enabled for different cloud service providers. The key update request issued by the key update component does not yet carry the cloud service provider identity information. The identification information is added to the key update request by the management unit used to manage the key update component. Based on the identification information, the cloud service provider to which the key update component belongs is determined, and is used as the cloud service provider to which the key update request is directed; Update the key for the cloud service provider.

11. The method of claim 10, wherein, Based on the identification information, the cloud service provider to which the key update component belongs is determined, including: Based on the identification information, the target service instance where the key update component is located is determined; The tag information corresponding to the target service instance is retrieved from the tag system. The tag information describes the target cloud service to which the target service instance belongs. The cloud service provider corresponding to the target cloud service is determined as the cloud service provider to which the key update component belongs.

12. A cloud service processing system, comprising: Cloud service deployment system and cloud service management system; The cloud service deployment system is used to send a key update request for the deployment carrier to the cloud service management system; The cloud service management system stores the updated key obtained by the cloud service provider, and the key is used to verify deployment permissions; And in the event that it is necessary to supplement the deployment of any cloud service provided by the cloud service provider, the updated key is used to pull the deployment carrier corresponding to the cloud service to complete the supplementary deployment; The cloud service management system is used to update the key for the cloud service provider targeted by the key update request; and to provide the updated key to the cloud service deployment system.

13. The system of claim 12, further comprising: Management unit; The cloud service deployment system includes dedicated key update components enabled for different cloud service providers. When the cloud service deployment system sends a key update request for the deployment carrier to the cloud service management system, it is used to: send a key update request that does not yet carry cloud service provider identity information to the management unit that manages the key update components using any of the enabled key update components. The management unit is used to: add the identification information corresponding to the key update component to the key update request, and forward it to the cloud service management system; The cloud service management system is used to: determine the cloud service provider to which the key update component belongs based on the identification information, and use this as the cloud service provider to which the key update request is directed.

14. A cloud service deployment system, comprising: The request sending unit is used to send a key update request for the deployment carrier to the cloud service management system, so as to trigger the cloud service management system to update the key for the cloud service provider to which the key update request is targeted, and the key is used to verify deployment permissions; A key storage unit is used to store the updated key obtained by the cloud service management system for the cloud service provider; The deployment carrier retrieval unit is used to retrieve the deployment carrier corresponding to the cloud service using the updated key when it is necessary to supplement the deployment of any cloud service provided by the cloud service provider, so as to complete the supplementary deployment.

15. A cloud service management system, comprising: The request receiving unit is used to receive key update requests regarding the deployment carrier sent by the cloud service deployment system; The key update unit is used to update the key for the cloud service provider targeted by the key update request, and obtain the updated key, which is used to verify deployment permissions; The key return unit is used to provide the updated key to the cloud service deployment system, so that the cloud service deployment system can use the updated key to pull the deployment carrier corresponding to the cloud service to complete the supplementary deployment when it needs to supplement the deployment of any cloud service provided by the cloud service provider.

16. A computing device, comprising a memory and a processor; The memory is used to store one or more computer instructions; The processor is coupled to the memory and is configured to execute the one or more computer instructions for performing: Send a key update request for the deployment carrier to the cloud service management system to trigger the cloud service management system to update the key for the cloud service provider to which the key update request is directed. The key is used to verify deployment permissions. The cloud service management system stores the updated key obtained by the cloud service provider. If it is necessary to supplement the deployment of any cloud service provided by the cloud service provider, the updated key is used to pull the deployment carrier corresponding to the cloud service to complete the supplementary deployment.

17. The computing device of claim 16, wherein, The computing device is suitable for a cloud service deployment system, which includes dedicated key update components enabled for different cloud service providers. These components send key update requests regarding the deployment carrier to the cloud service management system, including: Each enabled key update component initiates a key update request.

18. The computing device of claim 17, wherein, Initiate a key update request using any of the enabled key update components, including: Use any enabled key update component to send a key update request that does not yet carry cloud service provider identity information to the management unit used to manage the key update component; The management unit adds the identification information corresponding to the key update component to the key update request and forwards it to the cloud service management system, so that the cloud service management system can determine the cloud service provider to which the key update component belongs based on the identification information.

19. A computer readable storage medium storing computer instructions, wherein, When the computer instructions are executed by one or more processors, the one or more processors perform the cloud service deployment method according to any one of claims 1-11.

20. A computer program product comprising a computer program, wherein, When a computer program is executed by a processor, the processor is caused to perform the cloud service deployment method according to any one of claims 1-11.

Images