Automatic deployment upgrading method and system based on cloud platform

Abstract

The invention provides an automatic deployment upgrading method and system based on a cloud platform. After an upgrading command is received, a to-be-upgraded host set is determined and sorted according to available areas, an upgrading task record is generated for each host in a host operation log table, the task state is initialized to be ready, and the pushing frequency is 0. When the number of the tasks in progress does not reach the concurrence upper limit, the tasks of the available hosts are pushed to the flow processing module, and if acceptance succeeds, the tasks are set to be in progress, and the pushing frequency is updated. And periodically screening the ready tasks by the timed task, and performing compensation pushing according to an ascending order of pushing times. The process processing module carries out host state pre-verification on the task, if a host is available, a maintenance mode is entered, upgrade package downloading, service updating and script upgrading are executed, and write-back is successful or failed after finishing; failure may automatically retry and support visual retry or cancel.

Description

Technical Field

[0001] This invention belongs to the field of cloud computing platform operation and maintenance and automated deployment technology, and in particular relates to an automated deployment and upgrade method and system based on a cloud platform. Background Technology

[0002] In cloud platform delivery and daily operation and maintenance, component upgrades of hosts such as management nodes and compute nodes are frequent. Existing upgrade methods mostly rely on manual script distribution or individual node-by-node operations, which typically suffer from the following problems: First, upgrade tasks lack unified task records and status management, making it difficult to track upgrade progress and failure reasons; second, batch upgrades lack concurrency limits, easily triggering too many upgrade actions simultaneously, causing resource jitter or business migration risks; third, when encountering network jitter, packet download failures, or service restart failures, manual retrying is often required, resulting in low overall efficiency and a high risk of omissions; fourth, the lack of effective differentiation between maintenance hosts and available hosts may lead to non-compliant operations or upgrade conflicts. Therefore, an automated upgrade solution that is executable, traceable, compensable, and allows for manual intervention is needed. Summary of the Invention

[0003] In view of this, the present invention aims to propose an automated deployment and upgrade method and system based on a cloud platform, so as to at least solve one of the problems in the background art.

[0004] To achieve the above objectives, the technical solution of the present invention is implemented as follows: An automated deployment and upgrade method based on a cloud platform includes: Receive upgrade command and determine the set of hosts to be upgraded, and sort the set of hosts by availability zone; Delete the existing upgrade task record corresponding to the host set in the host operation log table, and build an upgrade task record for each host. The upgrade task record includes at least the host identifier, task status and push count. The initial task status is ready and the push count is 0. When the number of records in the log table with the task status "in progress" has not reached the preset limit, upgrade task records with the host status "available" are selected in the sorting order and the upgrade task is pushed to the process processing module. When the process processing module accepts the task, it sets the corresponding task status to "in progress" and updates the push count to 1. When it does not accept the task, it keeps the task status as "ready" and records the error reason. Compensation pushes are triggered periodically. Upgrade task records with a ready status are sorted in ascending order by the number of pushes. Pushes are made sequentially and the push count is incremented by 1 when the number of records has not reached the preset limit. The process processing module first performs a pre-verification on the accepted upgrade tasks. If the target host is under maintenance, the task is rejected. If it is in an available state, the upgrade process is executed and the log table is asynchronously written back after completion, updating the task status to success or failure.

[0005] Furthermore, the sorting by availability zone includes: first sorting by availability zone identifier, and then sorting by host identifier within the same availability zone; the set of hosts to be upgraded is obtained by filtering the node range, host range and / or version identifier carried in the upgrade command.

[0006] Furthermore, the upgrade task record in the host operation log table also includes at least one of the following: target version identifier, upgrade package identifier, creation time, update time, acceptance result identifier, error reason field, and callback result field.

[0007] Furthermore, the task status includes at least ready, in progress, successful, and failed; wherein, the change of task status from ready to in progress is triggered by the process processing module accepting the upgrade task, and the change of task status from in progress to successful or failed is triggered by the asynchronous write-back after the process processing module ends.

[0008] Furthermore, the preset upper limit includes at least one of the following: an upper limit M for the number of tasks in progress and an upper limit N for the number of tasks pushed in a single push; when the upper limit M for the number of tasks in progress and / or the upper limit N for the number of tasks pushed in a single push are reached, the push action of the current batch is terminated.

[0009] Furthermore, the timed trigger compensation push is periodically triggered; each time it is triggered, the target record is selected and pushed sequentially from the upgrade task records where the task status is ready and the host status is available, in ascending order of push count and in combination with the sorting.

[0010] Furthermore, the cycle is 5 minutes; for upgrade task records where compensation push acceptance fails, the task status is kept as ready, and the reason for acceptance failure is written in the error reason field.

[0011] Furthermore, the pre-verification includes: reading the host status of the target host; rejecting the upgrade task and returning a reason for rejection when the target host is under maintenance; and accepting the upgrade task when the target host is in an available state.

[0012] Furthermore, the upgrade process includes: putting the target host into maintenance mode and setting the maintenance level to medium risk, prohibiting virtual machine services from being scheduled to the target host; downloading the upgrade package; updating the upgrade service; executing the upgrade script; and putting the target host out of maintenance mode and restoring the host status to availability.

[0013] Furthermore, when the upgrade process fails, the process processing module automatically retryes the same upgrade task three times; if the retry still fails after three attempts, the upgrade task is marked as failed and a notification to the operations and maintenance personnel is triggered to intervene.

[0014] Furthermore, on the page provided by the visual operation module, operations and maintenance personnel can choose to retry a failed upgrade task to trigger the process processing module to continue execution; when operations and maintenance personnel choose to cancel the operation, the upgrade task is terminated and the target host status is restored to available.

[0015] Furthermore, the asynchronous write-back includes: the process processing module sends a success or failure callback to the upgrade request receiving module when the upgrade task ends, and updates the task status of the corresponding upgrade task record to success or failure; in the compensation push scenario, the process processing module also sends a success or failure callback to the timed task processing module and updates the corresponding upgrade task record.

[0016] Furthermore, this solution discloses an automated deployment and upgrade system based on a cloud platform, including: an upgrade request receiving module, a scheduled task processing module, a process processing module, and a visualization operation module; wherein, the upgrade request receiving module is used to receive upgrade commands, filter hosts to be upgraded, generate upgrade task records in a ready state in the host operation log table, and execute the push; the scheduled task processing module is used to perform periodic compensation pushes on upgrade task records in a ready state; the process processing module is used to pre-verify the pushed upgrade tasks, execute the upgrade process, and asynchronously write back the upgrade results to update the host operation log table; the visualization operation module is used to display the upgrade task status and provide retry and cancellation operation entry points.

[0017] Furthermore, the process processing module includes a pre-verification submodule, an upgrade execution submodule, and a process end callback submodule; the pre-verification submodule is used to determine whether the target host is under maintenance or available; the upgrade execution submodule is used to drive the target host into maintenance mode, download the upgrade package, update the upgrade service, execute the upgrade script, and exit maintenance mode; the process end callback submodule is used to output the upgrade success / failure result and update the host operation log table.

[0018] Furthermore, this solution discloses a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the method described thereon.

[0019] Compared with existing technologies, the automated deployment and upgrade method and system based on a cloud platform described in this invention has the following advantages: (1) The present invention records information such as host identifier, task status, and number of pushes through the host operation log table, so that the batch upgrade process has the ability to be queried and replayed at the task level, which makes it easier to locate the failure stage and cause. (2) By setting a concurrent upper limit on the number of ongoing tasks and controlling the number of pushes per push, this invention can reduce the impact of batch upgrades on platform resources and business scheduling. (3) The present invention uses a timed compensation push mechanism to push tasks in the ready state again according to the number of pushes, thereby reducing task delays caused by instantaneous order failures or concurrency limitations and improving the overall completion rate. (4) The process processing module of this invention performs a pre-verification of the host status before acceptance, and enters maintenance mode and prohibits business scheduling during the upgrade, thereby reducing upgrade conflicts and operational risks; (5) This invention incorporates exception handling into a unified process by automatically retrying failures and using the retry / cancel entry on the visual page, thereby reducing the cost of repeated manual operations and improving upgrade stability and maintenance efficiency. Attached Figure Description

[0020] The accompanying drawings, which form part of this invention, are used to provide a further understanding of the invention. The illustrative embodiments of the invention and their descriptions are used to explain the invention and do not constitute an undue limitation of the invention. In the drawings: Figure 1 This is a schematic diagram of the upgrade timing as described in an embodiment of the present invention; Figure 2 This is a schematic diagram of the host upgrade architecture described in an embodiment of the present invention; Figure 3 This is a schematic diagram of the upgrade process described in an embodiment of the present invention. Detailed Implementation

[0021] It should be noted that, unless otherwise specified, the embodiments and features described in the present invention can be combined with each other.

[0022] In the description of this invention, it should be understood that the terms "center," "longitudinal," "lateral," "upper," "lower," "front," "rear," "left," "right," "vertical," "horizontal," "top," "bottom," "inner," and "outer," etc., indicating orientations or positional relationships based on the orientations or positional relationships shown in the accompanying drawings, are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation, and therefore should not be construed as a limitation of the invention. Furthermore, the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first," "second," etc., may explicitly or implicitly include one or more of that feature. In the description of this invention, unless otherwise stated, "a plurality of" means two or more.

[0023] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art will understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0024] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0025] In this embodiment, the cloud platform includes at least an upgrade request receiving module for receiving upgrade instructions, a scheduled task processing module for periodic compensation scheduling, a process processing module for executing the upgrade process, and a visualization operation module for operation and maintenance intervention. These modules can be deployed on the same management node or distributed across multiple management nodes, and interact via RPC / message queues / HTTP callbacks, etc. The resource scope managed by the cloud platform can be organized hierarchically by Region-Availability Zone-Node / Host. Host status includes at least two categories: Available and Under Maintenance. A maintenance level of Medium Risk indicates that virtual machine services are prohibited from being scheduled to the target host during the upgrade process, in order to reduce the risk of disruption to online services during the upgrade.

[0026] I. Design of Host Operation Log Table and Task State Machine To ensure the upgrade process is traceable and recoverable, this embodiment maintains a host operation log table (also known as an upgrade task table) in the cloud platform to record the upgrade task status and push / acceptance / callback information for each host. Each upgrade task record in the host operation log table includes at least: task identifier (task_id), host identifier (host_id), target version (version_id), task status (status), and push count (push_count); the task status includes at least: ready, in progress, successful, and failed (optionally, also includes canceled). In some implementations, the upgrade task record may also include: availability zone identifier (az_id), creation time (create_time), update time (update_time), last push time (last_push_time), acceptance result (accept_flag), error reason (error_msg) / error code (error_code), automatic retries (retry_count), callback result (callback_flag), operator ID (operator_id), and request identifier (request_id), for subsequent statistics and problem localization.

[0027] Through the above-mentioned task state machine and log field design, the upgrade process can be transformed from "human experience plus manual recording" to "process observability and traceability centered on task records". When an anomaly occurs, the failure stage, failure cause and retry count can be located based on the log fields, thereby reducing troubleshooting costs and providing implementation support for demonstrating "process traceability and robustness" in subsequent reviews.

[0028] II. Processing flow of the upgrade request receiving module (first triggering link) When operations and maintenance personnel issue an upgrade command on the cloud platform, the upgrade request receiving module receives the upgrade command and determines the range of hosts to be upgraded. The upgrade command may include at least: a target version identifier, a target Region / node range or a host range (optionally, it may also include upgrade window, concurrency threshold configuration, etc.). The upgrade request receiving module can execute the following steps: 1) Host Set Filtering and Sorting: Filter all hosts under a node that need to be upgraded from resource management / asset information to form a set of hosts to be upgraded; sort the hosts to be upgraded according to availability zone. In some implementations, the sorting rule can be "first sort by availability zone identifier, then sort by host identifier" to make the push order deterministic and reproducible, facilitating playback and auditing.

[0029] 2) Clean up existing tasks and initialize tasks: Filter historical upgrade task records in the host operation log table by host range (or request_id), and delete or invalidate existing upgrade tasks to avoid multiple conflicting task records on the same host; then create an upgrade task record for each host to be upgraded, initialize the task status to ready, and set push_count to 0 (optionally, also initialize retry_count to 0, error_code to empty, etc.).

[0030] 3) Concurrency Limit Judgment and Push Scheduling: The upgrade request receiving module reads the number of records with a task status of "in progress" (in_progress_cnt) from the host operation log table and compares it with the preset concurrency limit M. When in_progress_cnt reaches M, the current push is stopped and the module waits for subsequent compensation scheduling. When in_progress_cnt does not reach M, target hosts are selected sequentially from the upgrade task records with a task status of "ready" according to the aforementioned sorting rules, and only records with a host status of "available" are pushed. To control the impact of a single push, in some implementations, a maximum limit N for the number of pushes in a single push can be set to ensure that the number of pushes in a single push does not exceed N.

[0031] 4) Acceptance Result Recording: After the upgrade request receiving module pushes the upgrade task to the process processing module, it updates the log based on the acceptance response from the process processing module: If the acceptance is successful, the task status of the corresponding upgrade task record is updated to "in progress," and push_count is updated to 1 (or push_count is incremented by 1); if the acceptance fails, the task status remains "ready," and the error reason / error code is written, while last_push_time is updated. This "acceptance immediately sets it to "in progress" approach ensures consistent statistical standards for concurrency threshold judgment, preventing uncontrolled concurrency.

[0032] 5) Asynchronous Callback Update: After the upgrade process is completed, the process processing module asynchronously sends a callback to the upgrade request receiving module. The upgrade request receiving module updates the corresponding upgrade task record to success or failure based on the callback result (optionally, callback time, failure stage, etc. are written). Through asynchronous callback and table-writing mechanisms, a closed loop of "request—acceptance—execution—writeback" can be formed on the management side.

[0033] Through the above design, the upgrade request receiving module breaks down the upgrade command into a "controllable task sequence at the host level" and uses the concurrency limit M and the single push limit N to constrain the upgrade impact. At the same time, by "pushing only to available hosts and adding error reasons to the table", it can avoid hosts being accidentally triggered to upgrade during maintenance and provide clear filtering conditions for subsequent automatic compensation scheduling.

[0034] III. Compensation Scheduling Process of the Scheduled Task Processing Module (Second Trigger Link) To prevent tasks from remaining in the ready state for extended periods due to short-term concurrency limits, momentary network jitter, or order failures, this embodiment employs a scheduled task processing module for periodic compensation pushes. The scheduled task processing module executes every preset period T (e.g., 5 minutes), and the processing steps are as follows: 1) Filter candidate tasks: Select upgrade task records with a ready status from the host operation log table to form a candidate list; in some implementations, further filtering can be performed to retain only records with a host status of available in order to reduce invalid pushes.

[0035] 2) Sort by push count: Sort the candidate list in ascending order by push_count; when push_count is the same, it can be sorted by availability zone and host identifier for stable sorting. The strategy of sorting by push count in ascending order can prioritize "tasks that have not been fully tried", which is more conducive to improving the overall completion rate in batch upgrade scenarios and reduces the probability that individual tasks will occupy push opportunities for a long time due to frequent failures.

[0036] 3) Concurrency limit judgment: Read the number of currently ongoing tasks in_progress_cnt and compare it with the concurrency limit M; if M has been reached, end this round of compensation; if M has not been reached, proceed to the push step.

[0037] 4) Compensation Push and Table Submission: Select candidate records in order of sorting results (optionally limit the number of pushes per round to no more than N) and push the upgrade task to the process processing module; for records with successful order acceptance, update the task status to in progress and increment push_count by 1; for records with failed order acceptance, keep the task status as ready and write the error reason / error code, while incrementing push_count by 1 or keeping it unchanged (both can be implemented as optional, the former is more convenient for quantifying the "number of attempts").

[0038] 5) Result callback: The process processing module executes the upgrade process for the compensation push accepted task and calls back the scheduled task processing module or uniformly calls back to the upgrade request receiving module after the completion; after the callback, the log is updated to success or failure.

[0039] By using timed compensation scheduling, upgrade tasks in the ready state can be automatically advanced without increasing manual intervention from operations and maintenance personnel. This avoids task delays caused by "single push acceptance failure / concurrency overload", thereby improving the robustness and completion rate of the overall upgrade process.

[0040] IV. Pre-verification and Upgrade Execution Flow (Execution Link) of the Process Processing Module The process processing module is used to accept, pre-verify, execute, and callback upgrade tasks. To ensure the consistency of host status during the upgrade process, this embodiment preferably adopts the method of "double verification at acceptance plus atomic status update": the process processing module reads the target host status when accepting the order and performs a consistency verification when the task status is set to in progress, avoiding concurrent execution caused by duplicate pushes.

[0041] 1) Pre-verification: After receiving an upgrade task, the process processing module reads the current status of the target host. If the target host is under maintenance, the task is rejected and a rejection reason is returned (e.g., "The host is under maintenance, upgrade is prohibited"), and subsequent upgrade steps are not executed. If the target host is available, the task is accepted successfully and the upgrade process begins. In some implementations, after successful acceptance, the process processing module updates the task status of the corresponding upgrade task record to "in progress" and can write the accept_flag and acceptance timestamp to accurately count concurrent usage.

[0042] 2) Entering Maintenance Mode and Disabling Scheduling: For successfully accepted tasks, the process module drives the target host into maintenance mode and sets the maintenance level to medium risk, disabling virtual machine services from being scheduled to the target host. This step is used to isolate scheduling behavior during the upgrade process, reducing the impact on service load during the execution of the upgrade script, thereby reducing resource jitter or upgrade failures caused by service migration / scheduling.

[0043] 3) Download Upgrade Package and Integrity Verification (Optional): The process module downloads the upgrade package corresponding to the target version from a preset software repository or mirror repository. In some implementations, the upgrade package can be verified (e.g., verifying the hash or signature). If the verification fails, the upgrade is terminated and a failure reason is returned to avoid uncontrollable upgrades caused by erroneous packages.

[0044] 4) Upgrade Service Update and Script Execution: The process handling module updates the upgrade service and executes the upgrade script. The upgrade script may include at least the following steps: component replacement, configuration update, service restart, and basic health check; if any step fails, the failure stage and error reason are recorded.

[0045] 5) Exiting maintenance mode and restoring status: When the upgrade script is completed and the health check is passed, the process processing module drives the target host to exit maintenance mode and restore the host status to available. If the upgrade fails, in some implementations, "exit maintenance / state restoration" or a rollback strategy is executed before restoring the host to available status to avoid the host being in maintenance for a long time and causing resource unavailability.

[0046] 6) Automatic Retry and Manual Intervention: When the upgrade process fails, the process handling module can automatically retry a preset number of times R (e.g., 3 times). Retrying can use a fixed interval or a backoff interval (e.g., waiting for Δt after each failure before retrying, with Δt increasing progressively), and the retry_count and the reason for failure are recorded in the log table. If the upgrade still fails after R retries, the process handling module triggers a notification for operations personnel to intervene (e.g., through an alarm or work order). This mechanism can automatically recover from common transient failures (network jitter, image fetch timeout, service startup contention, etc.), reducing repetitive manual operations.

[0047] 7) Process End Callback: When the process processing module succeeds in upgrading or ultimately fails, it reports the result to the upgrade request receiving module and / or the scheduled task processing module via a callback, carrying the task identifier, host identifier, final status, and error reason (if failure). The receiving party updates the upgrade task record accordingly to indicate success or failure. Through the callback loop, the execution plane result can be reliably mapped back to the management plane task record, achieving end-to-end traceability.

[0048] V. Display and Control Logic of the Visual Operation Module (Operations and Maintenance Intervention Link) The visualization module provides operations and maintenance personnel with a real-time display and control interface for upgrade tasks, displaying at least: statistics on hosts to be upgraded, statistics on hosts undergoing upgrades, host upgrade progress, single-host upgrade task status, and error reasons. In some implementations, the visualization module provides the following control capabilities: 1) Retry: When a host task fails and requires manual repair of the underlying environment before continuing, operations personnel can trigger a "Retry" operation on the page. This operation can generate a new retry instruction or reset the corresponding task record to ready / retry, thereby re-entering the push link of the upgrade request receiving module or the scheduled task processing module. This provides a clear entry point for "manual repair plus process continuation," preventing inconsistent operations by personnel bypassing the platform.

[0049] 2) Cancel: When the environment is incompatible or the upgrade needs to be manually completed by maintenance personnel, the maintenance personnel can trigger the "Cancel" operation on the page; after cancellation, the platform terminates the automatic upgrade process of the host and restores the host status to available (if necessary, first exit maintenance mode and remove the prohibition on scheduling). In some implementations, the task status can be set to canceled and the cancellation reason and operator can be written for auditing purposes.

[0050] By using a visual "display, retry, and cancel" mechanism, unavoidable human intervention can be incorporated into the platform's unified process control, reducing information loss and process breakpoints caused by decentralized operations across multiple platforms.

[0051] VI. Example Scenario (Taking E7113 version upgrade as an example) Taking the E7113 version upgrade as an example: A Region has three Availability Zones, each with 10 hosts. Of these, 3 hosts are under maintenance and 7 are available. After the operations personnel issue an upgrade request, the upgrade request receiving module retrieves 30 hosts that meet the upgrade requirements; deletes the existing upgrade operation logs for these 30 hosts; sorts the 30 hosts by Availability Zone; initializes the operation logs and adds 30 new upgrade task records, all initially in a ready state. At this point, there are 21 available hosts, and the number of tasks in progress in the host operation log table is 0. Assuming the maximum number of pushes per session (N) is 5 and the concurrency limit (M) is not triggered, the upgrade request receiving module first pushes 5 available host tasks to the process processing module and updates its `push_count` to 1. The process processing module pre-verifies that all target hosts are in an available state, successfully receives the order, updates the corresponding task status to "in progress," and executes the upgrade. After the process ends, it calls back to the upgrade request receiving module to update the operation log status to "success" or "failure." Meanwhile, the scheduled task processing module executes every 5 minutes, pushing tasks that are still ready and whose host status is available in ascending order of push_count to compensate for the failure. This ensures that subsequent tasks can continue to advance even when concurrency is at full capacity or there is a momentary order failure. After the process is completed, the task status is updated to success or failure via a callback. If an individual host upgrade fails, the process processing module will automatically retry three times. If it still fails, it will notify the operations and maintenance department to intervene. After the operations and maintenance department repairs the issue, users can click "Retry" on the visualization page to continue execution, or click "Cancel" to restore the host to an available state if a manual upgrade is needed.

[0052] VII. Optional parameters and additional technical features that can be used for subsequent limitations In some implementations, the following parameters and limitations can be set: the concurrency limit M is an integer from 10 to 200; the maximum number of pushes per session N is an integer from 1 to 20; the timed compensation period T is 1 to 10 minutes; the number of automatic retries R is 1 to 5; the retry waiting interval Δt is 10 to 300 seconds and can adopt a gradually increasing backoff strategy; the task status includes not only ready, in progress, successful, and failed, but also canceled; the upgrade task record includes not only push_count, but also last_push_time, error_code, error_msg, retry_count, request_id, and operator_id fields; the sorting rule for compensation pushes is "push_count ascending order plus availability zone sorting plus host identifier sorting"; the process processing module performs idempotency verification on the same task_id for repeated pushes, and directly rejects or returns the accepted / completed result when the task is already in progress or successful, to avoid concurrent repeated upgrades on the same host. The above parameters and additional features can all serve as alternative limiting points for subsequently incorporating the features of the embodiments into the claims, so as to enhance the distinctiveness and defensibility of this application relative to the prior art.

[0053] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. An automated deployment and upgrade method based on a cloud platform, characterized in that, include: Receive upgrade command and determine the set of hosts to be upgraded, and sort the set of hosts by availability zone; Delete the existing upgrade task record corresponding to the host set in the host operation log table, and build an upgrade task record for each host. The upgrade task record includes at least the host identifier, task status and push count. The initial task status is ready and the push count is 0. When the number of records in the log table with the task status "in progress" has not reached the preset limit, upgrade task records with the host status "available" are selected in the sorting order and the upgrade task is pushed to the process processing module. When the process processing module accepts the task, it sets the corresponding task status to "in progress" and updates the push count to 1. When it does not accept the task, it keeps the task status as "ready" and records the error reason. Compensation pushes are triggered periodically. Upgrade task records with a ready status are sorted in ascending order by the number of pushes. Pushes are made sequentially and the push count is incremented by 1 when the number of records has not reached the preset limit. The process processing module first performs a pre-verification on the accepted upgrade tasks. If the target host is under maintenance, the task is rejected. If it is in an available state, the upgrade process is executed and the log table is asynchronously written back after completion, updating the task status to success or failure.

2. The method according to claim 1, characterized in that, The timed trigger compensation push is periodically triggered; each time it is triggered, the target record is selected and pushed sequentially from the upgrade task records where the task status is ready and the host status is available, in ascending order of push count and in combination with the sorting.

3. The method according to claim 2, characterized in that, The cycle is 5 minutes; for upgrade tasks that fail to receive compensation push notifications, the task status is kept as ready, and the reason for failure is written in the error reason field.

4. The method according to claim 1, characterized in that, The pre-verification includes: reading the host status of the target host; rejecting the upgrade task and returning the reason for rejection when the target host is under maintenance; and accepting the upgrade task when the target host is in an available state.

5. The method according to claim 1, characterized in that, The upgrade process includes: putting the target host into maintenance mode and setting the maintenance level to medium risk, prohibiting virtual machine services from being scheduled to the target host; downloading the upgrade package; updating the upgrade service; executing the upgrade script; and putting the target host out of maintenance mode and restoring the host status to availability.

6. The method according to claim 5, characterized in that, On the page provided by the visual operation module, maintenance personnel can choose to retry a failed upgrade task to trigger the process processing module to continue execution; when maintenance personnel choose to cancel the operation, the upgrade task will be terminated and the target host status will be restored to available.

7. The method according to claim 1, characterized in that, The asynchronous write-back includes: the process processing module sends a success or failure callback to the upgrade request receiving module when the upgrade task ends, and updates the task status of the corresponding upgrade task record to success or failure; in the compensation push scenario, the process processing module also sends a success or failure callback to the timed task processing module and updates the corresponding upgrade task record.

8. An automated deployment and upgrade system based on a cloud platform, characterized in that, include: The system comprises an upgrade request receiving module, a scheduled task processing module, a process processing module, and a visualization operation module. The upgrade request receiving module receives upgrade commands, filters hosts to be upgraded, generates upgrade task records in a ready state in the host operation log table, and executes the push. The scheduled task processing module performs periodic compensation pushes on upgrade task records in a ready state. The process processing module pre-verifies the pushed upgrade tasks, executes the upgrade process, and asynchronously writes back the upgrade results to update the host operation log table. The visualization operation module displays the upgrade task status and provides retry and cancellation operation entry points.

9. The system according to claim 8, characterized in that, The process processing module includes a pre-verification submodule, an upgrade execution submodule, and a process end callback submodule; The pre-verification submodule is used to determine whether the target host is under maintenance or available. The upgrade execution submodule is used to drive the target host into maintenance mode, download the upgrade package, update the upgrade service, execute the upgrade script, and exit maintenance mode. The process end callback submodule is used to output the upgrade success / failure result and update the host operation log table.

10. A computer-readable storage medium having a computer program stored thereon, the computer program, when executed by a processor, implementing the method as claimed in any one of claims 1 to 7.

Images