Containerized service deployment method and device, equipment, storage medium and program product

Abstract

The invention provides a containerized service deployment method and device, equipment, a storage medium and a program product. Relates to the technical field of big data. The method comprises the following steps: acquiring a deployment model corresponding to a deployment request and a preset same source code bin, and analyzing the model to obtain a target environment identifier, a script execution switch state and a main service version tag; when the switch is started, acquiring a script file of a matched version from the code bin, analyzing execution demand information of the script file, and integrating to generate an initialized mirror image and storing the initialized mirror image; deploying a temporary service based on a mirror image, and controlling script execution through a distributed lock; according to the execution state, if success, releasing resources and triggering main service deployment, and if failure, giving an alarm and terminating the process. Full-process automatic management and control of the initialized scripts are realized, the scripts are consistent with business code versions, and execution logic is decoupled from a main service; multi-copy execution conflicts are effectively avoided, manual operation errors are reduced, and deployment efficiency and reliability are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of big data, and in particular to a containerized service deployment method and device, equipment, storage medium and program product. BACKGROUND

[0002] The rapid development of cloud native technology promotes the widespread application of microservice architecture, and containerized deployment becomes the core mode of enterprise application development and operation. In the service deployment process, the initialization script execution is a key link to ensure the normal start of the service, and the optimization of related technologies is of great significance to improve the deployment efficiency and reliability. The present application focuses on this technical field.

[0003] The existing initialization script execution scheme mainly falls into two categories: one needs to integrate script execution dependencies in the business code, and the script is triggered to run by the application start; the other executes the script through an independent initialization container before the main business container starts, realizing a certain degree of logical separation.

[0004] The existing technology has coupling or version mismatch problems between the initialization script execution and the business, and it is difficult to control the unique execution of the script in the multi-copy deployment scenario, resulting in low deployment efficiency and poor reliability. It is urgent to realize the decoupling of the script and the business, version synchronization and controllable execution optimization. SUMMARY

[0005] The embodiments of the present application provide a containerized service deployment method, device, equipment, storage medium and program product to improve the deployment efficiency and reliability.

[0006] In a first aspect, the embodiments of the present application provide a containerized service deployment method, comprising:

[0007] Obtaining a deployment model corresponding to a service deployment request and a preset same-origin code repository, the deployment model including core configuration of main service deployment, and the preset same-origin code repository storing business code and initialization scripts corresponding to version labels;

[0008] Analyzing the deployment model to obtain a target environment identifier, a script execution switch state and a main service version label;

[0009] When the script execution switch state is in an enabled state, obtaining a script file matching the main service version label from the preset same-origin code repository;

[0010] Obtaining corresponding execution requirement information by analyzing the script file, the execution requirement information including an interpreter, a client tool and a running environment;

[0011] Integrating the script file, the interpreter, the client tool and the running environment to generate an initialization image and storing it to a preset image repository;

[0012] deploy a temporary service based on the initialization image, and control the script execution of the temporary service through a distributed lock mechanism;

[0013] obtain a script execution state of the temporary service, release temporary service resources and trigger main service deployment if the script execution state is successful, and trigger an alarm and terminate the deployment process if the script execution state is failed.

[0014] In a possible implementation, the script file, the interpreter, the client tool and the running environment are integrated to generate the initialization image, including:

[0015] matching the running environment with a preset image resource library to obtain a base image layer;

[0016] deploying the interpreter and the client tool corresponding to the version specification of the interpreter and the functional parameters of the client tool in the base image layer and configuring environment variable mapping;

[0017] copying the script file to a preset executable directory of the base image layer, and configuring an image startup entry as a path of the script file;

[0018] loading metadata corresponding to a main service version label to the base image layer and then encapsulating to obtain the initialization image.

[0019] In a possible implementation, the control of the script execution of the temporary service through the distributed lock mechanism includes:

[0020] obtaining connection parameters of the distributed lock, the connection parameters including a service address, authentication information and lock timeout information;

[0021] initiating a locking request to the distributed lock through the connection parameters;

[0022] when the distributed lock is not occupied, the temporary service occupies the distributed lock and executes the script, and releases the lock after the execution is completed;

[0023] when the distributed lock is already occupied, the temporary service terminates the locking request and releases resources.

[0024] In a possible implementation, the deployment model is parsed to obtain a target environment identifier, a script execution switch state and a main service version label, including:

[0025] obtaining preset field identifiers corresponding to the target environment identifier, the script execution switch state and the main service version label, the preset field identifiers including an environment identifier, a switch identifier and a version identifier;

[0026] The target environment identifier, the script execution switch state and the main service version label are obtained by matching the environment identifier and the switch identifier with fields of an execution control module in the deployment model respectively.

[0027] The main service version label is obtained by matching the version identifier with a field of a version configuration module in the deployment model.

[0028] In a possible implementation, the method further includes:

[0029] A dynamic parameter corresponding to the target environment identifier is obtained, and the dynamic parameter is input into the temporary service to be deployed.

[0030] A script execution log of the temporary service is obtained and uploaded to a monitoring platform, and a stage result is obtained by analyzing the script execution log.

[0031] It is determined whether to trigger a subsequent script according to the stage result, and an execution state is obtained.

[0032] When the execution state is successful, resources of the temporary service are released, and the main service deployment is triggered.

[0033] When the execution state is failed, a multi-level alarm is triggered.

[0034] In a possible implementation, the method further includes:

[0035] Label configuration information required by the main service deployment is obtained.

[0036] It is determined according to a value of an initialization execution control field in the label configuration information.

[0037] If the value of the initialization execution control field is enabled, a script execution process is triggered.

[0038] If the value of the initialization execution control field is disabled, a script execution step is skipped, and a main service deployment process is directly executed.

[0039] In a second aspect, an embodiment of the present application provides a containerized service deployment apparatus, including:

[0040] An obtaining module is configured to obtain a deployment model corresponding to a service deployment request and a preset same-origin code repository, wherein the deployment model includes core configuration of main service deployment, and the preset same-origin code repository stores business code and initialization scripts corresponding to version labels.

[0041] An analyzing module is configured to analyze the deployment model to obtain a target environment identifier, a script execution switch state and a main service version label.

[0042] The acquisition module is further configured to acquire a script file matching the main service version label from the preset homologous code repository when the script execution switch state is an enabled state.

[0043] The analysis module is further configured to obtain corresponding execution requirement information by analyzing the script file, wherein the execution requirement information comprises an interpreter, a client tool, and a running environment.

[0044] The integration module is configured to integrate the script file, the interpreter, the client tool, and the running environment to generate an initialization image and store the initialization image in a preset image repository.

[0045] The deployment module is configured to deploy a temporary service based on the initialization image and control the temporary service to execute a script through a distributed lock mechanism.

[0046] The execution module is configured to acquire a script execution state of the temporary service, release temporary service resources and trigger main service deployment if the script execution state is successful, and trigger an alarm and terminate a deployment process if the script execution state is unsuccessful.

[0047] In a possible implementation, the integration module is specifically configured to:

[0048] match the running environment with a preset image repository to obtain a basic image layer;

[0049] deploy the interpreter and the client tool corresponding to the version specification of the interpreter and the functional parameters of the client tool in the basic image layer and configure environment variable mapping;

[0050] copy the script file to a preset executable directory of the basic image layer and configure an image startup entry as a path of the script file;

[0051] load metadata corresponding to the main service version label to the basic image layer and then encapsulate the basic image layer to obtain the initialization image.

[0052] In a possible implementation, the deployment module is specifically configured to:

[0053] acquire connection parameters of the distributed lock, wherein the connection parameters comprise a service address, authentication information, and lock timeout information;

[0054] initiate a locking request to the distributed lock through the connection parameters;

[0055] when the distributed lock is not occupied, the temporary service occupies the distributed lock and executes a script, and releases the lock after the execution is completed;

[0056] When the distributed lock has been occupied, the temporary service terminates the locking request and releases the resource.

[0057] In a possible implementation, the parsing module is specifically configured to:

[0058] obtain a preset field identifier corresponding to the target environment identifier, the script execution switch state, and the main service version label, the preset field identifier including an environment identifier, a switch identifier, and a version identifier;

[0059] obtain the target environment identifier and the script execution switch state by matching the environment identifier and the switch identifier with fields of an execution control module in the deployment model respectively;

[0060] obtain the main service version label by matching the version identifier with a field of a version configuration module in the deployment model.

[0061] In a possible implementation, the parsing module is further configured to:

[0062] obtain a dynamic parameter corresponding to the target environment identifier, and input the dynamic parameter into the temporary service to be deployed;

[0063] obtain a script execution log of the temporary service and upload the script execution log to a monitoring platform, and obtain a stage result by parsing the script execution log;

[0064] determine whether to trigger a subsequent script according to the stage result, and obtain an execution state;

[0065] when the execution state is successful, release a resource of the temporary service and trigger deployment of the main service;

[0066] when the execution state is failed, trigger multi-level alarm.

[0067] In a possible implementation, the deployment module is further configured to:

[0068] obtain label configuration information of a resource required by the main service for deployment;

[0069] determine according to a value of an initialization execution control field in the label configuration information;

[0070] if the value of the initialization execution control field is enabled, trigger a script execution process;

[0071] if the value of the initialization execution control field is disabled, skip the script execution step and directly execute a main service deployment process.

[0072] In a third aspect, an electronic device is provided, including a memory and a processor.

[0073] The memory stores computer-executable instructions;

[0074] The processor executes the computer-executable instructions stored in the memory, so that the processor executes the first aspect and / or various possible implementation manners of the first aspect.

[0075] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, the computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are executed by a processor to implement the first aspect and / or various possible implementation manners of the first aspect.

[0076] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, and the computer program is executed by a processor to implement the first aspect and / or various possible implementation manners of the first aspect.

[0077] The containerized service deployment method, device, equipment, storage medium and program product provided by the embodiments of the present application can store the business code and the initialization script in the same code warehouse and bind the versions, parse the environment identifier, the script switch and the main service version after obtaining the deployment requirement, extract the corresponding script when the switch is enabled, integrate the script and the running dependency to generate an image, deploy a temporary service based on the image and control the unique execution of the script by using a distributed lock, release the resources to deploy the main service after success, and terminate the alarm in case of failure; because the script and the business are homologous to realize the version synchronization, the temporary service carries out the execution to realize the business decoupling, the distributed lock avoids the conflict of multiple copies, reduces the manual intervention, and achieves the effects of improving the deployment efficiency and reliability. BRIEF DESCRIPTION OF DRAWINGS

[0078] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0079] Figure 1 A flowchart of a containerized service deployment method provided by the present application is shown in the figure;

[0080] Figure 2 A structure diagram of a containerized service deployment device provided by the present application is shown in the figure;

[0081] Figure 3 A structure diagram of an electronic device provided by the present application is shown in the figure.

[0082] Through the above-mentioned drawings, the specific embodiments of the present application have been shown, and more detailed descriptions will be given in the following. These drawings and textual descriptions are not intended to limit the scope of the concept of the present application by any means, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0083] The exemplary embodiments will be described in detail herein with reference to the attached drawings. In the following description, like reference numerals refer to like elements throughout the description. The following exemplary embodiments described herein represent illustrations only. They are not meant to be exhaustive or to limit the scope of the application to the embodiments described. On the contrary, they are intended to include all possible embodiments as detailed in the attached claims.

[0084] In the technical solutions of the present application, the collection, storage, use, processing, transmission, provision and disclosure of financial data or user data and other information comply with relevant laws and regulations and do not violate public order and good customs.

[0085] It should be noted that in the embodiments of the present application, some existing industry solutions such as software, components, models, etc. may be mentioned, which should be considered as exemplary, and the purpose is only to illustrate the feasibility of the implementation of the technical solutions of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0086] First, the terms involved in the present application are explained:

[0087] Containerized service deployment: refers to the process of encapsulating services and their dependent resources into standardized images based on container technology, and realizing the automatic deployment, running and management of services through a container orchestration platform;

[0088] Same source code repository: refers to storing business code and initialization scripts in the same code repository, establishing an associated mapping between the two through version tags, and realizing version synchronization management of the code storage carrier;

[0089] Deployment model: refers to a structured file that carries the core configuration of main service deployment, including target environment, resource requirements, version information, script execution control, etc. It provides standardized input for the deployment process;

[0090] Initialization script: refers to a specific script file that needs to be executed before service deployment, which is used to complete tasks such as database structure creation, environment configuration synchronization, dependent resource preparation, etc. It supports SQL, Shell, YAML, etc.

[0091] Temporary service: refers to a short-term running container instance based on an initialization image deployment, which is specifically used to execute initialization scripts and release resources after execution, and is physically isolated from the main business service;

[0092] Distributed lock: refers to a cross-instance resource contention control mechanism based on distributed coordination services (such as Redis, ZooKeeper (distributed coordination service)), which ensures that only one instance occupies the resource at the same time through atomic operations;

[0093] Initialization image: refers to a standardized image product conforming to the OCI (Open Container Initiative) specification, integrating initialization scripts, required interpreters, client tools, and running environments, providing a consistent execution environment for temporary services;

[0094] Target environment identifier: refers to a standardized identifier used to distinguish deployment scenarios (such as development, testing, and production), extracted from the deployment model, used for targeted matching of environment configurations and dynamic parameters;

[0095] Script execution switch state: refers to a state identifier in the deployment model that controls whether the initialization script is executed, taking values of enabled or disabled, serving as a trigger condition for script execution flow;

[0096] Main service version label: refers to a standardized identifier used to identify the version of the main service code, bound to the script version in the same source code repository, ensuring consistency between the script and the main service version;

[0097] Dynamic parameters: refers to individualized configuration parameters corresponding to the target environment, stored in a distributed configuration center, and transmitted to the temporary service through environment variable injection or configuration file mounting;

[0098] Monitoring platform: refers to a technical system with functions of log collection, analysis, storage, and visualization, used to receive script execution logs of temporary services, generate stage results, and execution status;

[0099] Resource label configuration information: refers to key-value pair metadata associated with main service deployment resources, including initialization execution control fields and other configurations, used to dynamically control script execution flow;

[0100] Application programming interface: refers to a standardized interface provided by the container orchestration platform, supporting operations such as permission authentication, resource query, and service deployment, providing a channel for interaction between the scheduling engine and the platform;

[0101] Return code: refers to the state code output by the container after script execution, following the container exit code standard, 0 indicating normal termination, and non-0 indicating abnormality, used to determine script execution results;

[0102] Scheduling engine: refers to the core component that coordinates the entire process of containerized service deployment, responsible for analyzing deployment models, triggering image building, deploying temporary services, monitoring execution status, and promoting main service deployment;

[0103] Pre-set image repository: refers to a warehouse that stores standardized base images, including system kernels, library files, and other underlying components for different running environments, providing a base image layer for initialization image construction.

[0104] In the prior art, the business code is integrated with the script execution logic or the independent initialization container executes the script, and there are technical problems that the business and the script have high coupling degree, the versions are prone to mismatch, and the script execution cannot be controlled to be unique in the multi-copy deployment scenario.

[0105] The containerized service deployment method provided in the application solves the key technical problems of the initialization script execution and the business coupling, the version inconsistency, and the multi-copy execution conflict in the containerized deployment by the technical means of managing the business code and the script through the homologous code warehouse, automatically building the initialization image, deploying the temporary service, and controlling the script execution by the distributed lock.

[0106] The technical solutions of the application and how the technical solutions of the application solve the above technical problems will be described in detail in specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes can not be described again in some embodiments. The embodiments of the application will be described below with reference to the drawings.

[0107] Figure 1 As shown in the flowchart of the containerized service deployment method provided in the application, Figure 1 the embodiment provides a containerized service deployment method, and the flow includes the following steps.

[0108] Step S101: Obtain a deployment model corresponding to a service deployment request and a preset homologous code warehouse, the deployment model includes core configurations of main service deployment, and the preset homologous code warehouse stores business code and initialization scripts corresponding to version labels.

[0109] Specifically, based on the data source unified management principle of service deployment, the deployment model serves as the configuration carrier of the main service deployment and carries core parameters such as environment and resources; the preset homologous code warehouse establishes an associated mapping between the business code and the initialization script through the version label, and uses the version control capability of the code warehouse to realize the synchronous management of the two.

[0110] The containerized service deployment method provided in the application provides standardized input for the subsequent deployment process, clearly defines the main service deployment benchmark and the script source, integrates the dispersed business and script resources into a unified data carrier, eliminates data islands, ensures the version association of the business code and the initialization script to be traceable, provides a data basis for subsequent version consistency verification, and avoids information disconnection caused by the storage separation of the script and the business code.

[0111] Step S102: Analyze the deployment model to obtain a target environment identifier, a script execution switch state, and a main service version label.

[0112] Specifically, according to the structured field definition of the deployment model, the key information is extracted by accurately matching the preset field identification (environment identification, switch identification, version identification) with the fields of the execution control module and the version configuration module in the model.

[0113] By screening the core parameters of the control script execution from the deployment model, the target deployment environment, the trigger condition of the script execution, and the main service version benchmark are determined, which provides a basis for subsequent process branch judgment. This effectively improves the accuracy and efficiency of the deployment model analysis, avoids invalid information interference, ensures that the judgment standard of the script execution control logic is clear and quantifiable, and reduces the analysis error.

[0114] Step S103: When the script execution switch state is in the enabled state, the script file matching the main service version label is obtained from the preset same source code repository.

[0115] Specifically, by taking the script execution switch state as the process branch trigger condition, based on the association rule of the main service version label and the script version in the code repository, the corresponding script file is pulled from the same source code repository through the version matching algorithm. The on-demand triggering of the script execution process is realized, ensuring that the version of the obtained script file strictly corresponds to the main service version, establishing the version binding relationship between the script and the main service. This avoids the blindness of script execution, ensures the version consistency of the script and the main service, eliminates the abnormal script execution caused by version mismatch, and improves the controllability of the deployment process.

[0116] Step S104: The execution requirement information corresponding to the script file is obtained by parsing the script file, and the execution requirement information includes the interpreter, the client tool, and the running environment.

[0117] Specifically, by using methods such as static syntax analysis and dependency recognition technology, the syntax structure and instruction call of the script file are parsed, and the required interpreter type and version, client tool function requirement, and running environment system parameters are extracted. This effectively determines the basic dependency conditions of script execution, provides accurate component list for the construction of the initialization image, ensures that the image contains complete supporting elements for script execution; avoids the lack or redundancy of dependent components during image construction, improves the pertinence of image construction, and lays the environmental foundation for stable execution of subsequent scripts.

[0118] Step S105: The script file, interpreter, client tool, and running environment are integrated to generate an initialization image and stored in a preset image repository.

[0119] Specifically, based on the layered construction of the container image, the matched running environment is used as the base image layer, and the interpreter, client tool, and script file are sequentially stacked. After configuring the image startup entry, the initialization image is encapsulated, and the image archiving is completed through the storage interface of the image repository.

[0120] The script and running dependency are integrated into a standardized mirror product, the consistency of the script execution environment is realized, the uniform management and calling of the mirror are realized through the mirror warehouse. The difference of the script execution environment is eliminated, the environment consistency of the script execution is improved, and the standardized storage of the mirror provides efficient resource support for subsequent temporary service deployment.

[0121] Step S106: deploying a temporary service based on the initialization mirror, and controlling the temporary service to execute a script through a distributed lock mechanism.

[0122] Specifically, the temporary service is deployed through the API interface of the container platform, the distributed lock mechanism is realized based on the Lease resource of Kubernetes, the lock resource is competed through atomic operation, it is ensured that only one temporary service obtains the lock and executes the script at the same time, the lock holder renews regularly, and the lease expires automatically and is released in an exception. The script execution is physically isolated from the main business container, the uniqueness of the script execution is controlled through the distributed lock, and the resource conflict caused by concurrent execution is avoided. The script execution is decoupled from the main service, the problem of repeated execution of the script in the multi-replica deployment scenario is solved, and the orderliness and data security of the script execution are ensured.

[0123] Step S107: obtaining the script execution state of the temporary service, if the script execution state is successful, releasing the temporary service resource and triggering the main service deployment, if the script execution state is failed, triggering the alarm and terminating the deployment process.

[0124] Specifically, the running state code and execution log of the temporary service are monitored in real time through the state feedback interface of the container platform, the state judgment rule is established, the state result is linked with the deployment process control logic, the resource release, the main service deployment or the alarm mechanism is triggered. The closed-loop control of the script execution process is realized, the deployment process is promoted or terminated according to the execution result, and the abnormal information is fed back in time. It is ensured that the main service deployment is started only after the script execution is successful, the abnormality is avoided, the alarm mechanism improves the problem response efficiency, and the reliability of the deployment process is ensured.

[0125] The containerized service deployment method provided by the embodiment of the application realizes the decoupling, version consistency and controllable execution of the script and the business in the containerized deployment through the version binding of the business and the script, the automatic construction of the mirror to encapsulate the execution environment, the decoupling and unique execution of the temporary service and the distributed lock, and the closed-loop control of the process through the state monitoring, and improves the deployment efficiency and reliability.

[0126] The embodiment details the process of integrating the script file, the interpreter, the client tool and the running environment to generate the initialization mirror in the above-mentioned embodiment, and the specific implementation mode of the process includes the following steps:

[0127] Step a1: match the running environment with the preset image resource library to obtain the basic image layer.

[0128] Specifically, the standardized basic image stored in the preset image resource library contains system kernels, library files and other underlying components of different running environments. By matching the system parameters, architecture types and other characteristics of the running environment with the image index in the resource library, the most suitable basic image layer is selected. When there is no matching result between the running environment and the image in the preset image resource library, a standardized alarm is triggered and the initialization image construction process is terminated, and the specific matching failure reason is returned.

[0129] By specifying the starting point of image construction, the redundancy and uncertainty caused by building from scratch are avoided; the complexity of image construction is reduced, and the underlying environment of different initialization images is ensured to have standardized characteristics, providing a consistent dependency foundation for the deployment of upper-layer components.

[0130] Step a2: according to the version specification of the interpreter and the functional parameters of the client tool, deploy the corresponding interpreter and client tool on the basic image layer and configure the environment variable mapping.

[0131] Specifically, according to the version specification of the interpreter and the functional parameters of the client tool, the corresponding components are pulled from the official source or private warehouse through the package management tool, and the component path, configuration parameters and other information are injected into the system runtime through the environment variable mapping mechanism, ensuring that the components can be called globally.

[0132] By constructing the complete dependent environment required by the script execution, the interpreter and the client tool are precisely deployed, eliminating the problem of mismatch between component version and function, so that the version and function of the dependent components in the image strictly match the script execution requirements. The standardized configuration of environment variables ensures the consistency of component calling, and improves the stability of script execution in the image.

[0133] Step a3: copy the script file to the preset executable directory of the basic image layer, and configure the image startup entry as the path of the script file.

[0134] Specifically, according to the specification structure of the container image file system, the preset executable directory has clear permission configuration and access path. The path migration of the script file is completed through the copy instruction, and the script path is set as the trigger entry of image startup through the instruction or command prompt of the command or script that specifies the command or script to be run when the container starts.

[0135] The storage location and execution trigger mode of the script in the image are specified, the direct association between image startup and script execution is established, the script can be called accurately, the automatic logic of automatically executing the target script when the image starts is realized, the path error of script calling is reduced by the standardized configuration of preset directory, and the controllability of script execution is improved.

[0136] Step a4: encapsulating after loading the metadata corresponding to the main service version label to the base image layer to obtain an initialization image.

[0137] Specifically, based on the image metadata management standard, the main service version label, the construction time, the script version and other information are injected into the image metadata area in the form of key-value pairs, and the image encapsulation tool is used to integrate the file systems and metadata of each layer to generate an image product conforming to the container specification. The version association identifier and the construction trace information are attached to the initialization image, the final integration of each component of the image is completed, the standardized image is formed, the initialization image is clearly associated with the main service version, the metadata provides a basis for the version management, tracing and verification of the image, and the standardized encapsulation ensures that the image can be deployed on the mainstream container platform.

[0138] The embodiment of the application realizes the environment consistency, dependency precision, execution controllability and version traceability of the initialization image by matching the running environment to determine the standardized base layer, precisely deploying dependent components and configuring environment variables, standardizing script storage and startup logic, and injecting version metadata for encapsulation, thereby providing reliable image support for stable deployment of temporary services.

[0139] The embodiment details the process of controlling the execution script of the temporary service through the distributed lock mechanism in the above embodiment, and the specific implementation manner of the process includes the following steps:

[0140] Step b1, obtain the connection parameters of the distributed lock, and the connection parameters include the service address, authentication information and lock timeout information.

[0141] Specifically, the distributed lock relies on independent service nodes such as Redis and ZooKeeper (distributed coordination service) to realize cross-instance resource competition control. The service address is used to locate the lock service node, the authentication information is used to ensure the safety of the lock operation through key or permission verification, and the lock timeout information is based on the service response threshold and the preset script execution time to avoid long-term occupation of the lock. An effective communication link is established between the temporary service and the lock service, the time boundary of the operation permission and the resource release is clear, the basic configuration parameters of the lock operation are provided, the precision and safety of the lock service connection are ensured, the timeout information provides a basis for automatic release of the lock in abnormal scenarios, and the lock service unreachable or resource leakage caused by missing configuration is avoided.

[0142] Step b2, initiate a lock request to the distributed lock through the connection parameters.

[0143] Specifically, based on the acquired connection parameters, a long-lived connection is established with the lock service via the Transmission Control Protocol (TCP). An atomic command (such as Redis's `SET NX EX` command) is used to initiate a lock request. This command simultaneously performs lock status determination and occupancy marking, avoiding gaps between judgment and execution under concurrent requests. The resource contention judgment logic of the lock service is triggered, ensuring consistency between lock status determination and occupancy through atomic operations. This prevents lock contention conflicts caused by concurrent requests, improves the atomicity and reliability of the lock request, avoids lock status disorder caused by traditional non-atomic operations, and ensures the accuracy of the lock request result.

[0144] Step b3: When the distributed lock is not occupied, the temporary service occupies the distributed lock and executes the script. After execution, the lock is released.

[0145] Specifically, the lock service determines lock occupancy status using key-value pair status indicators. If the lock is not occupied, the atomic command executes successfully, and the temporary service writes its own instance identifier to the lock value to complete the occupancy. During script execution, the lock timeout mechanism remains in effect, and resources are proactively released after execution via an atomic command that deletes the lock key. This ensures unique control over script execution, guaranteeing that only one temporary service executes the script at a time. The proactive release mechanism provides a channel for subsequent service nodes to compete for lock resources, resolving the issue of duplicate script execution in multi-replica deployment scenarios. Proactive release is more efficient than passive timeout release, reducing the time spent occupying lock resources.

[0146] Step b4: When the distributed lock is already in use, the temporary service terminates the lock request and releases the resources.

[0147] Specifically, when the lock service reports that the lock is already occupied (e.g., an atomic command returns a null value), the temporary service terminates the lock request according to preset logic, releases the CPU, memory and other computing resources it occupies through the container platform interface, and avoids entering the waiting queue to prevent resource waste.

[0148] By clearly defining the resource handling method after a lock contention failure, we can avoid temporary services from occupying resources for a long time while waiting for the lock to be released, simplify the lock contention process branches, reduce invalid resource occupation, improve cluster resource utilization, avoid resource tension caused by multiple instances waiting for the lock, and shorten the overall deployment time.

[0149] This invention achieves unique control of script execution by a temporary service by obtaining lock service configuration parameters to establish a secure connection, initiating a lock request with an atomic command, performing differentiated operations based on the lock state, and actively releasing lock resources after the script is completed. This ensures the orderly execution of the script in multi-replica deployment scenarios and improves the utilization efficiency and operational reliability of lock resources.

[0150] This embodiment provides a detailed explanation of the process in the above embodiments for parsing the deployment model to obtain the target environment identifier, script execution switch status, and main service version label. The specific implementation of this process includes the following steps:

[0151] Step c1: Obtain the preset field identifiers corresponding to the target environment identifier, script execution switch status, and main service version label. The preset field identifiers include the environment identifier, switch identifier, and version identifier.

[0152] Specifically, based on the structured design specifications of the deployment model, the preset field identifiers are standardized built-in fields of the deployment model. Following the structured schema specifications of container deployment configuration, the deployment model includes these three types of field identifiers when it is created. The field names, data types, and value ranges are all preset unified standards. Through the definition of metadata related to the target environment, script execution control, and main service version, the correspondence between the parsing target and the field identifiers is established, and the core benchmark for parsing is clarified.

[0153] This provides a unified identification basis for the analysis of the deployment model, eliminates the ambiguity of field identification, clarifies the field features corresponding to the key information that needs to be extracted, lays the foundation for subsequent accurate matching, enables the analysis process to have standardized judgment criteria, avoids analysis deviations caused by unclear field identification, and improves the feasibility of analysis logic.

[0154] Step c2 involves matching the environment identifier and switch identifier with the fields of the execution control module in the deployment model to obtain the target environment identifier and script execution switch status.

[0155] Specifically, the execution control module of the deployment model adopts a layered design, centrally storing control parameters such as environment configuration and execution switches. Through string full matching or structured field mapping algorithms, the preset environment identifiers and switch identifiers are compared with the fields within the module to achieve targeted extraction of target information.

[0156] By limiting the extraction range of environment identifiers and switch identifiers, interference from irrelevant fields is avoided, ensuring that the extracted information is directly related to the execution control logic. This solves the problem of low efficiency caused by a broad parsing range, improves the extraction accuracy of target environment identifiers and script execution switch states, clarifies the environmental benchmark and triggering conditions for subsequent script execution, and provides reliable data support for process branch judgment.

[0157] Step c3: The main service version label is obtained by matching the version identifier with the fields of the version configuration module in the deployment model.

[0158] Specifically, the version configuration module is an independent unit in the deployment model used to carry version management information. It performs key-value pair matching between a preset version identifier and the version metadata stored within the module, and uses structured field parsing technology to extract the corresponding version information. This enables targeted extraction of version information, ensuring that the extraction path for version tags is unique and clear, resolving the problem of version information being confused with other configuration information, guaranteeing the accuracy of main service version tag extraction, providing a precise version benchmark for subsequent retrieval of matching script files from the same source code repository, and ensuring consistency in version association.

[0159] This invention achieves standardization, accuracy, and efficiency in deployment model parsing by pre-setting standardized field identifiers, performing field matching by module, and extracting key configuration information by type, providing reliable core parameter support for subsequent processes of containerized service deployment.

[0160] In some alternative implementations, it also includes:

[0161] Step c41: Obtain the dynamic parameters corresponding to the target environment identifier and pass the dynamic parameters to the temporary service to be deployed.

[0162] Specifically, based on the association mapping between environment and configuration, dynamic parameters are stored in a distributed configuration center. The parameters are passed to the runtime of the temporary service by matching the target environment identifier with the index key of the configuration center and using container environment variable injection or configuration file mounting.

[0163] Provide personalized configurations for temporary services to adapt to the target environment, avoid environment adaptation problems caused by hard-coded parameters, clarify the benchmark of temporary service operation parameters, enable temporary services to quickly adapt to the operation requirements of different environments, standardize parameter passing to improve configuration accuracy, and reduce script execution anomalies caused by environment differences.

[0164] Step c42: Obtain the script execution logs of the temporary service and upload them to the monitoring platform. The phase results are obtained by parsing the script execution logs.

[0165] Specifically, by utilizing a container log driver to collect standard output logs from temporary services, and uploading them to a monitoring platform via log transmission protocols such as Hypertext Transfer Protocol (HTTP) and Transmission Control Protocol (TCP), the platform employs a structured parsing algorithm to split the logs according to preset identifiers for each script execution stage, extracting status information for each stage to generate stage results. This achieves end-to-end observability of the script execution process, transforming discrete logs into structured stage data, providing detailed evidence for execution status judgment, and overcoming the limitation of relying solely on the final result. It can accurately pinpoint the specific stage of script execution anomalies, improving the efficiency and accuracy of problem troubleshooting.

[0166] Step c43: Determine whether to trigger subsequent scripts and obtain the execution status based on the stage results.

[0167] Specifically, based on preset stage result judgment rules, the validity of stage results is identified through status code matching, keyword retrieval, and other methods. The rules specify the success threshold conditions for each stage to determine whether to trigger subsequent script execution, and finally aggregate the results of each stage to generate the overall execution status.

[0168] By establishing a process-oriented control logic for script execution, clarifying the connection conditions between stages, solving the problem of ambiguous judgment criteria for script execution progress, enabling on-demand script execution, avoiding resource consumption in ineffective stages, ensuring a unified standard for judging execution status, and improving process controllability.

[0169] Step c44: When the execution status is successful, release the resources of the temporary service and trigger the deployment of the main service.

[0170] Specifically, through the resource management interface of the container orchestration platform, after the execution status is confirmed as successful, a deletion command for the temporary service is triggered to release resources such as CPU and memory. Simultaneously, the execution status is used as an event source, and triggers in the service orchestration engine are used to link the deployment process of the main service. This completes the closed-loop management of the temporary service's lifecycle, establishes a process connection mechanism between script execution and main service deployment, avoids long-term resource occupation, ensures timely resource release to improve cluster resource utilization, and guarantees that the main service deployment only starts after the script execution is successful, ensuring the orderly nature of the deployment process.

[0171] Step c45: When the execution status is failure, trigger a multi-level alarm.

[0172] Specifically, based on alarm grading rules, the failure type corresponding to the execution status is associated with the alarm level. The alarm engine matches preset notification channels and recipients, triggering notifications sequentially according to the level. If there is no response, the notification scope is automatically escalated. This achieves tiered delivery of anomaly information, ensuring differentiated responses to failures of different severity levels, preventing critical faults from being ignored, shortening fault response time, reducing interference from invalid alarms, improving the efficiency of the operations team in responding to core issues, and enhancing the reliability of deployment processes.

[0173] This invention achieves environmental adaptability, process controllability, and accurate anomaly response in containerized service deployment by matching the environment to obtain dynamic parameters to adapt to operational requirements, collecting and parsing log results to make the process observable, controlling the script execution process according to preset rules, completing resource management and process linkage based on status, and transmitting abnormal information through hierarchical alarms. This improves the flexibility and reliability of the overall deployment process.

[0174] In some optional implementations, the following steps are also included:

[0175] Step d1: Obtain the tag configuration information for the resources required for the main service deployment.

[0176] Specifically, based on the resource metadata management mechanism of the container orchestration platform, the tag configuration information of the resources required for the main service deployment is associated with the resource object in the form of key-value pairs. The tag data containing the initialization control logic is extracted by querying the resource type through the platform's application programming interface.

[0177] By obtaining the core control basis that triggers script execution, resource configuration is associated with initialization execution logic, providing standardized data input for subsequent process judgment, clarifying the configuration source of script execution control, avoiding difficulties in obtaining control information due to scattered storage, and ensuring accurate extraction of control parameters.

[0178] Step d2: Make a judgment based on the value of the initialization execution control field in the tag configuration information.

[0179] Specifically, through a field value matching and verification mechanism, the enumerated values ​​(enabled / disabled) of the preset initialization execution control field are used as the judgment benchmark. The target field values ​​in the tag configuration information are verified by a string comparison algorithm, and a binary judgment result is output.

[0180] By establishing trigger criteria for script execution processes and clarifying the basis for dividing process branches, the problem of ambiguous standards in traditional judgment logic is solved. This enables the judgment logic for process direction to have clear and quantifiable basis, improves the consistency and accuracy of judgment results, and reduces the error rate of branch execution.

[0181] Step d3: If the value of the initialization execution control field is enabled, the script execution process will be triggered.

[0182] Specifically, based on an event-driven architecture, the initialization execution control field is set to "enabled" as a preset event source. The process orchestration engine triggers the script execution process's start command, establishing a direct link between the judgment result and the execution process. This enables on-demand script execution, connecting tag judgment with the script execution business logic, ensuring that initialization operations are only executed when necessary, avoiding blind script execution, improving the targeting of the deployment process, and guaranteeing the timeliness and reliability of process startup through a standardized event triggering mechanism.

[0183] Step d4: If the value of the initialization execution control field is disabled, skip the script execution step and directly execute the main service deployment process.

[0184] Specifically, by using process branch jumps, when the judgment result is disabled, the script execution node is skipped through the branch control interface of the process engine, and the initialization interface of the main service deployment is directly called, realizing dynamic switching of the process path. By optimizing the deployment path in scenarios that do not require initialization, the resource consumption of invalid process nodes is reduced, the differences in deployment processes under different scenarios are clarified, the deployment cycle of the main service when no initialization is required is shortened, the idle consumption of cluster resources is reduced, and the flexibility and resource utilization efficiency of the deployment process are improved. The initialization execution control field judgment has higher priority than the script execution switch judgment. When the two conditions conflict, the value of the initialization execution control field prevails. That is, if the field is disabled, regardless of the script execution switch status, the script execution process is skipped and the main service deployment is triggered directly.

[0185] This invention establishes control criteria by acquiring resource tag configuration information, determines process flow according to preset standards, and triggers differentiated process execution based on the determination results, thereby achieving dynamic adaptation of containerized service deployment processes and improving the coverage of deployment scenarios and process execution efficiency.

[0186] This embodiment provides a detailed description of the process for obtaining the script execution status of temporary services in the above embodiments. The specific implementation of this process includes the following steps:

[0187] Step e1: Obtain application programming interface access credentials for the container platform; the container platform is a technical system for running containerized services such as temporary services, querying the running status of container groups, and obtaining script execution-related data.

[0188] Specifically, access to the application programming interfaces (APIs) of the container platform must be based on an identity authentication and authorization mechanism. Permission credentials are obtained through legitimate authentication methods such as open authorization tokens and client certificates, and the corresponding data query permissions are granted after verification by the platform's authentication layer.

[0189] By establishing a secure communication foundation with the container platform, the legitimacy of the access subject is verified, providing a compliant access basis for subsequent query operations, making up for the security deficiencies caused by uncredential access, ensuring that access to container platform resources complies with security specifications, avoiding data leakage or tampering caused by unauthorized operations, and providing a security prerequisite for subsequent status queries.

[0190] Step e2: The scheduling engine uses access credentials to call the container platform's application programming interface at preset intervals.

[0191] Specifically, the scheduling engine is based on a scheduled task mechanism. Trigger rules are set through Cron expressions or fixed-period configuration. A Cron expression is a string format used to define scheduled tasks, carrying acquired authorization credentials. It initiates an application programming interface (API) call request via the Transmission Control Protocol (TCP) to ensure the legitimacy and periodicity of the call. This enables continuous monitoring of container group status and script execution data, resolving the issue that a single query cannot capture dynamic status changes. It clearly defines the call frequency and execution entity, ensuring the real-time and continuous collection of status data, avoiding misjudgments due to delayed acquisition, and improving the timeliness of script execution status monitoring.

[0192] Step e3: Query the running status of the container group corresponding to the temporary service through the application programming interface and obtain the return code after the script is executed.

[0193] Specifically, the application programming interface of the container platform supports querying the running status of container groups (such as running, exited, and creating) and the return code of script execution. The running status reflects the stage of the container lifecycle, and the return code follows the container exit code standard (0 indicates normal termination, and non-zero indicates an exception).

[0194] By collecting core data to determine the script execution status, the container running status is correlated with the script execution results, providing complete raw data support for subsequent status determination. By acquiring multi-dimensional status data, the judgment bias caused by a single data dimension is avoided, ensuring the integrity and accuracy of the raw data and laying the foundation for accurate judgment.

[0195] Step e4: Match the script execution status of the temporary service according to the preset mapping rules between the return code and the container group running status.

[0196] Specifically, the preset mapping rules are based on the logical association between the container's running state and the return code, clarifying the script execution state (success, failure, in execution) corresponding to different combinations, and realizing the transformation of raw data into the target state through rule matching algorithms.

[0197] By establishing standardized criteria for status determination, the problems of vague standards and strong subjectivity in traditional determination are solved, the judgment logic is made quantifiable and reusable, the judgment results of script execution status are unified and accurate, human judgment errors are avoided, the reliability of status conclusions is ensured, and a clear basis is provided for subsequent process decisions.

[0198] This invention achieves security, real-time performance, completeness, and accuracy in obtaining the execution status of temporary service scripts by acquiring legitimate authorization credentials, ensuring data real-time performance through periodic calls to the scheduling engine, ensuring information integrity through the collection of multi-dimensional raw data, and ensuring accurate judgment through preset mapping rules. This provides reliable support for subsequent decisions in the deployment process.

[0199] Figure 2 A schematic diagram of the containerized service deployment device provided in this application is shown below. Figure 2 As shown, the containerized service deployment device 20 provided in this embodiment includes:

[0200] The acquisition module 201 is used to acquire the deployment model and the preset source code repository corresponding to the service deployment request. The deployment model includes the core configuration of the main service deployment, and the preset source code repository stores the business code and initialization scripts corresponding to the version tags.

[0201] The parsing module 202 is used to parse the deployment model to obtain the target environment identifier, script execution switch status, and main service version label;

[0202] The acquisition module 201 is also used to acquire a script file that matches the main service version tag from a preset source code repository when the script execution switch is enabled.

[0203] The parsing module 202 is also used to obtain the corresponding execution requirement information by parsing the script file. The execution requirement information includes the interpreter, client tools, and runtime environment.

[0204] Integration module 203 is used to integrate script files, interpreter, client tools and runtime environment to generate an initialization image and store it in a preset image repository;

[0205] Deployment module 204 is used to deploy temporary services based on the initialization image and control the execution scripts of the temporary services through a distributed lock mechanism.

[0206] The execution module 205 is used to obtain the script execution status of the temporary service. If the script execution status is successful, the temporary service resources are released and the main service deployment is triggered. If the script execution status is unsuccessful, an alarm is triggered and the deployment process is terminated.

[0207] In one possible implementation, the integration module 203 is specifically used for:

[0208] The base image layer is obtained by matching the runtime environment with the preset image resource library;

[0209] Based on the interpreter's version specifications and the client tool's functional parameters, deploy the corresponding interpreter and client tool in the base image layer and configure environment variable mapping;

[0210] Copy the script file to the default executable directory of the base image layer, and configure the image startup entry point to the path of the script file;

[0211] The metadata corresponding to the main service version tag is loaded into the base image layer and then encapsulated to obtain the initial image.

[0212] In one possible implementation, deployment module 204 is specifically used for:

[0213] Obtain the connection parameters of the distributed lock, which include the service address, authentication information, and lock timeout information;

[0214] Initiate a locking request to the distributed lock using the connection parameters;

[0215] When the distributed lock is not occupied, a temporary service occupies the distributed lock and executes a script, and releases the lock after execution;

[0216] When the distributed lock is already in use, the temporary service terminates the lock request and releases the resources.

[0217] In one possible implementation, the parsing module 202 is specifically used for:

[0218] Retrieve the preset field identifiers corresponding to the target environment identifier, script execution switch status, and main service version label. The preset field identifiers include the environment identifier, switch identifier, and version identifier.

[0219] By matching the environment identifier and switch identifier with the fields of the execution control module in the deployment model, the target environment identifier and script execution switch status are obtained.

[0220] The main service version label is obtained by matching the version identifier with the fields of the version configuration module in the deployment model.

[0221] In one possible implementation, the parsing module 202 is further configured to:

[0222] Obtain the dynamic parameters corresponding to the target environment identifier and pass the dynamic parameters to the temporary service to be deployed;

[0223] Obtain the script execution logs of the temporary service and upload them to the monitoring platform. Then, parse the script execution logs to obtain the phase results.

[0224] Determine whether to trigger subsequent scripts and obtain the execution status based on the phase results;

[0225] When the execution status is successful, the resources of the temporary service are released and the deployment of the main service is triggered;

[0226] When the execution status is failure, a multi-level alarm is triggered.

[0227] In one possible implementation, deployment module 204 is further configured to:

[0228] Obtain the tag configuration information for the resources required for the main service deployment;

[0229] The determination is made based on the value of the initialization execution control field in the tag configuration information;

[0230] If the value of the initialization execution control field is enabled, the script execution process will be triggered;

[0231] If the initialization execution control field is set to disabled, the script execution step is skipped, and the main service deployment process is executed directly.

[0232] The containerized service deployment device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0233] Figure 3 A schematic diagram of the structure of the electronic device provided in this application. Figure 3 As shown, the electronic device 30 provided in this embodiment includes at least one processor 301 and a memory 302. Optionally, the electronic device 30 further includes a communication component 303. The processor 301, memory 302, and communication component 303 are connected via a bus.

[0234] In a specific implementation, at least one processor 301 executes computer execution instructions stored in memory 302, causing at least one processor 301 to perform the above-described method.

[0235] The specific implementation process of processor 301 can be found in the above method embodiments, and its implementation principle and technical effect are similar. It will not be repeated here.

[0236] In the above embodiments, it should be understood that the processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0237] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage device.

[0238] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0239] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the above-described method.

[0240] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the above-described method.

[0241] The aforementioned readable storage medium 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. The readable storage medium can be any available medium accessible to a general-purpose or special-purpose computer.

[0242] An exemplary readable storage medium is coupled to a processor, enabling the processor to read information from and write information to the readable storage medium. Of course, the readable storage medium can also be a component of the processor. The processor and the readable storage medium can reside in an Application Specific Integrated Circuit (ASIC). Alternatively, the processor and the readable storage medium can exist as discrete components in the device.

[0243] The division of units is merely a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0244] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0245] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0246] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0247] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0248] Finally, it should be noted that other embodiments of the invention will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This invention is intended to cover any variations, uses, or adaptations of the invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein, and is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for deploying containerized services, characterized in that, include: Obtain the deployment model and preset source code repository corresponding to the service deployment request. The deployment model includes the core configuration for the main service deployment, and the preset source code repository stores business code and initialization scripts corresponding to the version tags. The deployment model is parsed to obtain the target environment identifier, script execution switch status, and main service version label; When the script execution switch is enabled, a script file matching the main service version tag is retrieved from the preset source code repository; The execution requirement information is obtained by parsing the script file, and the execution requirement information includes the interpreter, client tools, and runtime environment; The script file, interpreter, client tools, and runtime environment are integrated to generate an initialization image and stored in a preset image repository; A temporary service is deployed based on the initialization image, and the execution script of the temporary service is controlled by a distributed lock mechanism. Obtain the script execution status of the temporary service. If the script execution status is successful, release the temporary service resources and trigger the deployment of the main service. If the script execution status is unsuccessful, trigger an alarm and terminate the deployment process.

2. The method according to claim 1, characterized in that, The script file, interpreter, client tools, and runtime environment are integrated to generate an initialization image, including: The base image layer is obtained by matching the aforementioned operating environment with a preset image resource library; Based on the version specifications of the interpreter and the functional parameters of the client tool, deploy the corresponding interpreter and client tool in the base image layer and configure environment variable mapping; Copy the script file to the preset executable directory of the base image layer, and configure the image startup entry point to the path of the script file; The metadata corresponding to the main service version tag is loaded into the base image layer and then encapsulated to obtain the initial image.

3. The method according to claim 1, characterized in that, The method of controlling the execution of scripts for temporary services through a distributed lock mechanism includes: Obtain the connection parameters of the distributed lock, which include the service address, authentication information, and lock timeout information; A locking request is initiated to the distributed lock using the connection parameters; When the distributed lock is not occupied, the temporary service occupies the distributed lock and executes the script, and releases the lock after execution; When the distributed lock is already in use, the temporary service terminates the locking request and releases the resources.

4. The method according to claim 1, characterized in that, The deployment model is parsed to obtain the target environment identifier, script execution switch status, and main service version tag, including: Obtain preset field identifiers corresponding to the target environment identifier, script execution switch status, and main service version tag. The preset field identifiers include environment identifier, switch identifier, and version identifier. By matching the environment identifier and the switch identifier with the fields of the execution control module in the deployment model, the target environment identifier and script execution switch status are obtained. The main service version tag is obtained by matching the version identifier with the fields of the version configuration module in the deployment model.

5. The method according to claim 4, characterized in that, Also includes: Obtain the dynamic parameters corresponding to the target environment identifier, and pass the dynamic parameters to the temporary service to be deployed; Obtain the script execution logs of the temporary service and upload them to the monitoring platform. Then, parse the script execution logs to obtain the phase results. Based on the results of the aforementioned stages, determine whether to trigger subsequent scripts and obtain the execution status; When the execution status is successful, the resources of the temporary service are released and the deployment of the main service is triggered; When the execution status is failure, a multi-level alarm is triggered.

6. The method according to claim 1, characterized in that, Also includes: Obtain the tag configuration information of the resources required for the deployment of the main service; The determination is made based on the value of the initialization execution control field in the label configuration information; If the value of the initialization execution control field is enabled, the script execution process is triggered; If the initialization execution control field is set to disabled, the script execution step is skipped, and the main service deployment process is executed directly.

7. A containerized service deployment device, characterized in that, include: The acquisition module is used to acquire the deployment model and the preset source code repository corresponding to the service deployment request. The deployment model includes the core configuration of the main service deployment, and the preset source code repository stores business code and initialization scripts corresponding to the version tags. The parsing module is used to parse the deployment model to obtain the target environment identifier, script execution switch status, and main service version tag; The acquisition module is further configured to acquire a script file matching the main service version tag from the preset source code repository when the script execution switch is enabled. The parsing module is also used to obtain corresponding execution requirement information by parsing the script file, the execution requirement information including interpreter, client tools and runtime environment; The integration module is used to integrate the script file, interpreter, client tools and runtime environment to generate an initialization image and store it in a preset image repository; The deployment module is used to deploy temporary services based on the initialization image and control the execution scripts of the temporary services through a distributed lock mechanism. The execution module is used to obtain the script execution status of the temporary service. If the script execution status is successful, the temporary service resources are released and the main service deployment is triggered. If the script execution status is unsuccessful, an alarm is triggered and the deployment process is terminated.

8. An electronic device, characterized in that, include: Memory, processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory, causing the processor to perform the method as described in any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-6.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-6.

Images