Timed task deployment method and device, computer device and storage medium
Patent Information
- Application Number
- CN202211210061.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-09-30
- Publication Date
- 2026-09-25
- Estimated Expiration
- 2042-09-30
AI Technical Summary
[0003]然而,在整个应用服务的开发过程中,特别是应用服务中包含定时任务时,如何将应用服务及其定时任务部署于容器环境,需要作业人员详细了解k8s中有关定时任务的文件配置、代码编写以及部署流程,这使得容器技术的利用成本高、部署效率低
[0023]上述定时任务部署方法、装置、计算机设备和存储介质,获取自定义配置文件中有关定时任务的配置信息,确定目标定时任务并从目标定时任务的任务配置信息中提取部署关键信息,并根据代码模板快速生成各目标定时任务对应的用于任务部署的配置文件,从而快速、高效地将需要进行部署的目标定时任务部署在容器集群中,作业人员在无需详细了解容器技术的情况下,也能够通过自定义配置文件实现定时任务的高效部署和管理,从而提高了带有定时任务的应用服务开发的效率。
Smart Images

Figure CN115543572B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer software technology, and in particular to a method, apparatus, computer device, and storage medium for deploying timed tasks. Background Technology
[0002] With the development of computer software technology, containerization technology has emerged. Containerization technology divides the resources of a single operating system into isolated containers in order to better balance conflicting resource usage needs among isolated containers. Using Kubernetes (k8s) technology in containerization technology, container deployment and management can be achieved.
[0003] However, during the entire application service development process, especially when the application service includes scheduled tasks, how to deploy the application service and its scheduled tasks in a container environment requires operators to have a detailed understanding of the file configuration, code writing and deployment process of scheduled tasks in Kubernetes. This makes the utilization cost of container technology high and the deployment efficiency low. Summary of the Invention
[0004] Therefore, it is necessary to provide a method, apparatus, computer equipment, and storage medium for deploying scheduled tasks in container clusters that can improve the deployment efficiency of scheduled tasks in container clusters, in order to address the above-mentioned technical problems.
[0005] A method for deploying scheduled tasks, the method comprising:
[0006] Obtain the custom configuration file; the custom configuration file includes task configuration information for at least one scheduled task;
[0007] Identify at least one target scheduled task from the scheduled tasks, and extract key task deployment information from the task configuration information of each target scheduled task;
[0008] Obtain the first code template, write the key task deployment information of each target scheduled task into the information reserved space in the first code template, and generate the first configuration file corresponding to each target scheduled task.
[0009] Based on the first configuration file, allocate the corresponding container for each target scheduled task in the container cluster.
[0010] In one embodiment, the custom configuration file also includes application configuration information of the application service to which the scheduled task belongs. Before allocating corresponding containers for each target scheduled task in the container cluster according to each first configuration file, the method further includes: extracting application deployment key information from the application configuration information; obtaining a second code template, writing the application deployment key information into the information reserved space in the second code template, and generating a second configuration file; and allocating corresponding containers for the application service in the container cluster according to the second configuration file.
[0011] In one embodiment, the key information for task deployment includes the task image address, the task environment image address, and the task start time. The process involves allocating a corresponding container for each target scheduled task in the container cluster based on each first configuration file, including: obtaining the task image of each target scheduled task based on the task image address; obtaining the task environment image of each target scheduled task based on the task environment image address; and allocating a corresponding container for each target scheduled task in the container cluster at the task start time of each target scheduled task, based on each first configuration file, each task image, and each task environment image.
[0012] In one embodiment, the task configuration information includes task name configuration information. Determining at least one target scheduled task from the scheduled tasks includes: in response to a scheduled task addition instruction, obtaining a current name list, where the current name list is a list of names of currently deployed scheduled tasks in the container cluster; determining whether the name of each scheduled task exists in the current name list based on the name configuration information, and determining the scheduled task whose name does not exist in the current name list as the target scheduled task.
[0013] In one embodiment, the method further includes: in response to a scheduled task deletion instruction, deleting a currently deployed scheduled task whose name does not exist in the name configuration information from the container cluster.
[0014] In one embodiment, the task configuration information includes task version configuration information. Determining at least one target scheduled task from the scheduled tasks includes: in response to a scheduled task update instruction, obtaining the current version information of the deployed scheduled tasks corresponding to each scheduled task in the container cluster; when the current version information is inconsistent with the version configuration information, determining the scheduled task as the target scheduled task.
[0015] In one embodiment, before obtaining the task image of each target scheduled task according to the task image address, the method further includes: querying whether the task image of each target scheduled task exists in the image repository; if not, extracting the task integration key information from the task configuration information; obtaining a third code template, writing the task integration key information into the information reserved space in the third code template, and generating a third configuration file; and generating the task image of each target scheduled task according to the third configuration file.
[0016] A scheduled task deployment device, the device comprising:
[0017] The configuration acquisition module is used to acquire custom configuration files; the custom configuration files include task configuration information for at least one scheduled task.
[0018] The information extraction module is used to identify at least one target scheduled task from the scheduled tasks and extract key task deployment information from the task configuration information of each target scheduled task.
[0019] The file generation module is used to obtain the first code template, write the key task deployment information of each target timed task into the information reserved space in the first code template, and generate the first configuration file corresponding to each target timed task.
[0020] The container allocation module is used to allocate corresponding containers for each target scheduled task in the container cluster according to each first configuration file.
[0021] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the timed task deployment method described above.
[0022] A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the timed task deployment method described above.
[0023] The aforementioned method, apparatus, computer equipment, and storage medium for deploying scheduled tasks obtain configuration information related to scheduled tasks from custom configuration files, determine target scheduled tasks, extract key deployment information from the task configuration information of target scheduled tasks, and quickly generate configuration files for task deployment corresponding to each target scheduled task based on code templates. This allows for the rapid and efficient deployment of target scheduled tasks in container clusters. Operators can achieve efficient deployment and management of scheduled tasks through custom configuration files without needing detailed knowledge of container technology, thereby improving the efficiency of developing application services with scheduled tasks. Attached Figure Description
[0024] Figure 1 This is an application environment diagram of a scheduled task deployment method in one embodiment;
[0025] Figure 2 This is a flowchart illustrating a scheduled task deployment method in one embodiment;
[0026] Figure 3 A schematic diagram of the technical architecture for deploying scheduled tasks in an application instance;
[0027] Figure 4 This is a structural block diagram of a timed task deployment device in one embodiment;
[0028] Figure 5 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation
[0029] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.
[0030] The scheduled task deployment method provided in this application can be applied to, for example... Figure 1 In the application environment shown, the terminal 102, server 104, and servers in the container cluster 106 can communicate with each other via a network.
[0031] Specifically, the user can configure a custom configuration file based on terminal 102. Terminal 102 can send the user-configured custom configuration file to server 104. Server 104 obtains the custom configuration file, which includes task configuration information for multiple scheduled tasks. Server 104 determines at least one target scheduled task from the multiple scheduled tasks, extracts the key task deployment information of each target scheduled task from the task configuration information, obtains a first code template, writes the key task deployment information of each target scheduled task into the information reserved space in the first code template, generates a first configuration file, and allocates corresponding containers for each target scheduled task in container cluster 106 according to the first configuration file.
[0032] In this context, terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. Server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers. Server 104 can be a physical server or a cloud server, regardless of its type. Server 104 can be a server independent of container cluster 106 or any one or more servers in container cluster 106. For example, server 104 can be the central control server of the container cluster, such as a Kubernetes central control machine.
[0033] In one embodiment, such as Figure 2 As shown, a method for deploying scheduled tasks is provided, which can be applied to... Figure 1 Taking the server in the example, the following steps are included:
[0034] Step S202: Obtain a custom configuration file; wherein the custom configuration file includes task configuration information for at least one scheduled task.
[0035] A custom configuration file refers to a user-configurable configuration file. A custom configuration file can include at least one configuration item, such as application configuration items, scheduled task configuration items, or other custom function configuration items. Application configuration items allow configuration of information related to the application service, while scheduled task configuration items allow configuration of information related to scheduled tasks within that application service. The configured information related to scheduled tasks can be called task configuration information, which may include, but is not limited to, the task name, task version, start time, end time, command statements to be executed, required environment image, and the image address of the scheduled task.
[0036] Specifically, users can customize various task configuration information through the terminal's information configuration interface. The terminal responds to the various task configuration information entered by the user, generates a custom configuration file, and submits the custom configuration file to the server.
[0037] Step S204: Determine at least one target scheduled task from the scheduled tasks, and extract key task deployment information from the task configuration information of each target scheduled task.
[0038] The target scheduled task refers to the scheduled task that has been identified as needing to be deployed. Key task deployment information refers to the relevant information required to deploy the scheduled task to the container cluster. This key information may include, but is not limited to: the image address of the scheduled task, the environment image address required by the scheduled task, and the start time of the scheduled task.
[0039] Specifically, users can configure one or more scheduled tasks in a custom configuration file and assign corresponding task configuration information to each scheduled task. The server can then select some or all scheduled tasks as target scheduled tasks in response to user commands. Deployment-related information is extracted from the task configuration information of each target scheduled task as key deployment information.
[0040] For example, user commands may include commands such as deploying, adding, deleting, and updating scheduled tasks. In response to the command to deploy a scheduled task, all scheduled tasks in the custom configuration file can be identified as the target scheduled task. In response to the commands to add, delete, and update scheduled tasks, a portion of the configured scheduled tasks can be selected as the target scheduled task.
[0041] Step S206: Obtain the first code template, write the key task deployment information of each target scheduled task into the information reserved space in the first code template, and generate the first configuration file corresponding to each target scheduled task.
[0042] The first code template refers to the general code template used to generate the first configuration file, and the first configuration file refers to the configuration file used to deploy scheduled tasks in the container cluster.
[0043] Specifically, the server can call a pre-written first code template, which is a general code template adapted to the configuration file of the scheduled task deployment in the container cluster. Through this first code template and different task configuration information, task deployment configuration files (first configuration files) for different scheduled tasks can be generated.
[0044] For example, in the deployment of scheduled tasks based on a Kubernetes container cluster, the first code template can be a general code template adapted to the CronJob (scheduled task) yaml file in Kubernetes. By writing the extracted key information of each target scheduled task into the information reserved space in the first code template, the yaml file of each CronJob can be generated.
[0045] Step S208: Allocate corresponding containers for each target scheduled task in the container cluster according to each first configuration file.
[0046] A container cluster refers to a management cluster for containerized applications, such as a Kubernetes container cluster. A container cluster can include at least one container management server.
[0047] Specifically, based on the first configuration file corresponding to each generated target task, a corresponding container (Docker) can be allocated in the container cluster for each target scheduled task, and each target scheduled task can be executed and managed based on the allocated container.
[0048] The above-described method for deploying scheduled tasks obtains configuration information related to scheduled tasks from a custom configuration file, identifies the target scheduled task, extracts key deployment information from the task configuration information of the target scheduled task, and quickly generates configuration files for task deployment corresponding to each target scheduled task based on a code template. This allows for the rapid and efficient deployment of the target scheduled tasks in the container cluster. Operators can achieve efficient deployment and management of scheduled tasks through custom configuration files without needing to have a detailed understanding of container technology, thereby improving the efficiency of developing application services with scheduled tasks.
[0049] In one embodiment, the task configuration information includes task name configuration information. Determining at least one target scheduled task from the scheduled tasks includes: in response to a scheduled task addition instruction, obtaining a current name list, where the current name list is a list of names of currently deployed scheduled tasks in the container cluster; determining whether the name of each scheduled task exists in the current name list based on the name configuration information, and determining the scheduled task whose name does not exist in the current name list as the target scheduled task.
[0050] In this embodiment, the user can add scheduled tasks in a custom configuration file via the terminal and trigger a scheduled task addition command. The server responds to the command by calling the container cluster's API interface to obtain a list of names of currently deployed scheduled tasks in the container cluster, i.e., the current name list. This list includes the name information of the currently deployed scheduled tasks. By comparing the configured scheduled task name information with the names in the current name list, it can be determined which scheduled tasks configured in the custom configuration file have not yet been deployed to the container cluster. These undeployed scheduled tasks are then identified as target scheduled tasks to be added to the container cluster.
[0051] In this embodiment, users only need to add task configuration information in a custom configuration file via the terminal. The server can then dynamically deploy the newly added scheduled tasks to the container cluster based on the changes in the task name configuration information. This avoids duplicate deployments during the synchronization process, reducing the workload of application delivery and deployment caused by the increase in scheduled tasks during application development.
[0052] In one embodiment, the method further includes: in response to a scheduled task deletion instruction, deleting a currently deployed scheduled task whose name does not exist in the name configuration information from the container cluster.
[0053] In this embodiment, the user can delete one or more scheduled tasks in a custom configuration file and trigger a scheduled task deletion command. The server responds to the command by calling the container cluster's API to obtain a list of currently deployed scheduled task names in the container cluster. This list includes the names of the currently deployed scheduled tasks. By comparing the name configuration information with the names in the current name list, the container corresponding to the currently deployed scheduled task whose name is not in the name configuration information but is in the current name list is deleted from the container cluster.
[0054] In this embodiment, users only need to delete task configuration information in a custom configuration file via the terminal. The server can then promptly and dynamically delete unnecessary scheduled tasks deployed in the container cluster based on the deleted and modified task name configuration information. This reduces the resource pressure on the container cluster and also reduces the workload of application delivery and deployment caused by the deletion of scheduled tasks during application development.
[0055] In one embodiment, the task configuration information includes task version configuration information. Determining at least one target scheduled task from the scheduled tasks includes: in response to a scheduled task update instruction, obtaining the current version information of the deployed scheduled tasks corresponding to each scheduled task in the container cluster; when the current version information is inconsistent with the version configuration information, determining the scheduled task as the target scheduled task.
[0056] In this embodiment, the user can modify the version configuration information of the scheduled task in the custom configuration file through the terminal. The server responds to the scheduled task update command by calling the API interface of the container cluster to obtain the version information of the deployed scheduled tasks corresponding to these scheduled tasks in the container cluster, that is, the current version information. If the current version information of the deployed scheduled task corresponding to the scheduled task in the container cluster is inconsistent with the task configuration information configured in the custom configuration file, it means that the version of the scheduled task needs to be updated. Therefore, the scheduled task can be identified as the target scheduled task, and the new version of the scheduled task can be redeployed. Furthermore, the container corresponding to the old version of the scheduled task can also be deleted from the container cluster.
[0057] Since Cronjobs in a Kubernetes container cluster cannot manage the version of scheduled tasks, when the version of a scheduled task changes, the application service process needs to be stopped, the version of the scheduled task in the application service needs to be modified again, and then redeployed. The whole process is complex and time-consuming. With this embodiment, users only need to modify the version configuration information of the scheduled task and other task configuration information of the scheduled task under that version in the custom configuration file on the terminal. The server can then quickly generate the corresponding first configuration file for one or more target scheduled tasks that need to be updated, and realize batch container allocation. Furthermore, it can also delete the container corresponding to the old version of the scheduled task, thereby realizing the version update and management of scheduled tasks based on the container cluster.
[0058] In one embodiment, the custom configuration file also includes application configuration information of the application service to which the scheduled task belongs. Before allocating corresponding containers for each target scheduled task in the container cluster according to each first configuration file, the method further includes: extracting application deployment key information from the application configuration information; obtaining a second code template, writing the application deployment key information into the information reserved space in the second code template, and generating a second configuration file; and allocating corresponding containers for the application service in the container cluster according to the second configuration file.
[0059] The second code template refers to a generic code template used to generate the second configuration file, which in turn refers to a configuration file used to deploy application services in a container cluster.
[0060] For example, in the deployment of scheduled tasks based on a Kubernetes container cluster, the second code template can be a general code template that adapts to the YAML file of the application service in Kubernetes. By writing the extracted key application deployment information into the information reserved space in the second code template, the YAML file of the Kubernetes application can be generated.
[0061] In this embodiment, before deploying each target scheduled task in the container cluster, a second configuration file can be quickly generated based on the application configuration information. Then, according to the second configuration file, corresponding containers are allocated in the container cluster for the application service to which the scheduled task belongs. The scheduled task is triggered during the operation of the application service based on the allocated container. At this point, the step of deploying each target scheduled task of the application service can proceed. This embodiment, by performing one-stop, automated deployment of the application service and its corresponding scheduled task, can further improve the efficiency of application development and deployment.
[0062] In one embodiment, the key information for task deployment includes the task image address, the task environment image address, and the task start time. The process involves allocating a corresponding container for each target scheduled task in the container cluster based on each first configuration file, including: obtaining the task image of each target scheduled task based on each task image address; obtaining the task environment image of each target scheduled task based on each task environment image address; and allocating a corresponding container for each target scheduled task in the container cluster at the task start time of each target scheduled task, based on each first configuration file, each task image, and each task environment image.
[0063] In this embodiment, the task image address refers to the address of the image corresponding to the scheduled task, and the task environment image address refers to the address of the environment image required by the scheduled task. The task start time refers to the execution start time of the scheduled task.
[0064] In this embodiment, by configuring the task image address and task environment image address for each target scheduled task, the image of the target scheduled task and the environment image required by the target scheduled task can be quickly obtained from the image repository. By separating the task image and task environment image of the scheduled task, different environment images can be obtained for the same scheduled task based on different user-configured task environment image addresses. Therefore, it can support the deployment of scheduled tasks under multiple environment images. Moreover, by combining the task start time, the container is allocated to the corresponding target scheduled task only when the task start time arrives, which can improve the utilization rate of container resources.
[0065] In one embodiment, the key information for application deployment may include the application image address and the address of the environment image required by the application, i.e., the application environment image address. Allocating a corresponding container for the application service in the container cluster according to the second configuration file may include: obtaining the application image according to the application image address; obtaining the application environment image according to the application environment image address; and allocating a corresponding container for the application service in the container cluster according to the second configuration file, the application image, and the application environment image.
[0066] In one embodiment, before obtaining the task image of each target scheduled task according to the task image address, the method further includes: querying whether the task image of each target scheduled task exists in the image repository; if not, extracting the task integration key information from the task configuration information; obtaining a third code template, writing the task integration key information into the information reserved space in the third code template, and generating a third configuration file; and generating the task image of each target scheduled task according to the third configuration file.
[0067] In this embodiment, the third code template refers to a general code template used to generate the third configuration file, and the third configuration file refers to a configuration file used to package the scheduled task into an image. Before obtaining the image of the target scheduled task from the image repository, it can be determined whether the image of the target scheduled task already exists in the image repository. If it does not exist, a continuous integration (CI) tool such as Jenkins can be further invoked to package the image according to the third configuration file and the relevant data of the target scheduled task in the Git repository, generate the task image of the target scheduled task, and store the generated task image in the image repository at the location corresponding to the configured task image address.
[0068] Furthermore, if a user modifies or edits the application configuration information in a custom configuration file, resulting in the application service not yet having a corresponding application image in the image repository, key application integration information can be extracted from the current application configuration information, and the fourth code template can be retrieved. This key application integration information is then written into the reserved information slots in the fourth code template to generate a fourth configuration file. The application image is then generated based on this fourth configuration file. The fourth code template refers to the general code template used to generate the fourth configuration file, and the fourth configuration file refers to the configuration file used to package the application service into an image.
[0069] In the above embodiments, when a user modifies the relevant configuration information of the application or scheduled task in the custom configuration file, the modified application or scheduled task may not have a corresponding image in the image repository. In this case, the server can quickly generate the corresponding image based on the application configuration information or task configuration information in the custom configuration file and the third and fourth code templates, and store it at a specified address in the image repository. In traditional technologies, different stages of continuous integration and delivery in application service development, such as image packaging and deployment, require different operation procedures, configuration files, and code writing standards. Therefore, if a small part of the application service is modified, the entire continuous integration and delivery process must be interrupted. This embodiment achieves one-stop rapid development of applications and their scheduled tasks from image packaging to task deployment. Users do not need to understand the specific operation procedures and code writing standards of different stages in the continuous integration and continuous delivery process of application service development, such as image packaging and deployment. They can focus on application development itself, without interruption after each configuration modification, achieving fast, efficient, and one-stop continuous integration and delivery.
[0070] In one embodiment, the method may further include: acquiring deployment environment parameters, determining a release environment based on the deployment environment parameters, and, if the release environment is a formal release environment, proceeding to the step of determining at least one target scheduled task from the scheduled tasks. If the release environment is a pre-release environment, only the application service may be deployed without synchronizing the scheduled tasks therein.
[0071] The following section provides a detailed explanation of the scheduled task deployment method described in this application, using an application example. (Refer to...) Figure 3 As shown, Figure 3 This diagram illustrates the technical architecture for deploying scheduled tasks in an application example. Specifically, it may include the following:
[0072] 1. Obtain the user-configured custom configuration file and deploy (deliver) the application based on the Spug deployment system.
[0073] 2. Based on the configuration information in the custom configuration file, check if the corresponding image exists in the image repository. If it exists, retrieve the image. If it does not exist, quickly package the image based on the Git repository, the Jenkins continuous integration tool, the preset code template for image packaging, and the configuration information in the custom configuration file.
[0074] 3. Based on the Kubernetes central control machine, container deployment is performed according to a custom configuration file, a pre-configured code template for deployment, and the corresponding image. This can be divided into two scenarios:
[0075] 1) In the pre-release environment (test status), the corresponding containers for the application services can be deployed only in the Kubernetes cluster to simplify the testing process.
[0076] 2) In the official release environment (official delivery status), when deploying the corresponding container for the application service, the scheduled tasks in the application service are also synchronized to achieve the deployment of scheduled tasks.
[0077] It should be understood that, although Figure 2 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 2 At least some of the steps in the process may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.
[0078] In one embodiment, such as Figure 4 As shown, a scheduled task deployment device is provided, including: a configuration acquisition module 402, an information extraction module 404, a file generation module 406, and a container allocation module 408, wherein:
[0079] The configuration acquisition module 402 is used to acquire a custom configuration file; wherein the custom configuration file includes task configuration information for at least one scheduled task;
[0080] Information extraction module 404 is used to determine at least one target timed task from the timed tasks and extract key task deployment information from the task configuration information of each target timed task.
[0081] The file generation module 406 is used to obtain the first code template, write the key task deployment information of each target timed task into the information reserved space in the first code template, and generate the first configuration file corresponding to each target timed task.
[0082] The container allocation module 408 is used to allocate corresponding containers for each target scheduled task in the container cluster according to each first configuration file.
[0083] In one embodiment, the device further includes an application deployment module, which is used to extract key application deployment information from application configuration information; obtain a second code template, write the key application deployment information into the information reserved space in the second code template, generate a second configuration file; and allocate corresponding containers for the application service in the container cluster according to the second configuration file.
[0084] In one embodiment, the container allocation module 408 obtains the task image of each target scheduled task based on the task image address; obtains the task environment image of each target scheduled task based on the task environment image address; and allocates the corresponding container in the container cluster for each target scheduled task at the task start time of each target scheduled task according to each first configuration file, each task image, and each task environment image. In one embodiment, the information extraction module 404, in response to the scheduled task addition instruction, obtains the current name list, which is the list of names of currently deployed scheduled tasks in the container cluster; determines whether the name of each scheduled task exists in the current name list based on the name configuration information, and identifies the scheduled task whose name does not exist in the current name list as the target scheduled task.
[0085] In one embodiment, the information extraction module 404, in response to a scheduled task deletion instruction, deletes the currently deployed scheduled task whose name does not exist in the name configuration information from the container cluster.
[0086] In one embodiment, the information extraction module 404 responds to the scheduled task update instruction to obtain the current version information of the deployed scheduled tasks corresponding to each scheduled task in the container cluster; when the current version information is inconsistent with the version configuration information, the scheduled task is determined as the target scheduled task.
[0087] In one embodiment, the container allocation module 408 is further configured to query whether there are task images for each target scheduled task in the image repository; if not, extract task integration key information from the task configuration information; obtain a third code template, write the task integration key information into the information reserved space in the third code template, and generate a third configuration file; and generate task images for each target scheduled task according to the third configuration file.
[0088] Specific limitations regarding the scheduled task deployment device can be found in the limitations of the scheduled task deployment method described above, and will not be repeated here. Each module in the aforementioned scheduled task deployment device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.
[0089] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows. Figure 5 As shown, the computer device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a scheduled task deployment method.
[0090] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0091] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it performs the following steps: obtaining a custom configuration file; wherein the custom configuration file includes task configuration information for at least one scheduled task; determining at least one target scheduled task from the scheduled tasks, and extracting key task deployment information from the task configuration information of each target scheduled task; obtaining a first code template, writing the key task deployment information of each target scheduled task into the information reserved space in the first code template, and generating a first configuration file corresponding to each target scheduled task; and allocating a corresponding container for each target scheduled task in a container cluster according to each first configuration file.
[0092] In one embodiment, when the processor executes the computer program, it also performs the following steps: extracting application deployment key information from application configuration information; obtaining a second code template, writing the application deployment key information into the information reserved space in the second code template, and generating a second configuration file; and allocating a corresponding container for the application service in the container cluster according to the second configuration file.
[0093] In one embodiment, when the processor executes a computer program to allocate corresponding containers for each target timed task in the container cluster according to each first configuration file, it specifically implements the following steps: obtaining the task image of each target timed task according to the task image address; obtaining the task environment image of each target timed task according to the task environment image address; and allocating corresponding containers for each target timed task in the container cluster at the task start time of each target timed task according to each first configuration file, each task image, and each task environment image.
[0094] In one embodiment, when the processor executes a computer program to determine at least one target scheduled task from the scheduled tasks, it specifically implements the following steps: in response to a scheduled task addition instruction, it obtains a current name list, which is a list of names of currently deployed scheduled tasks in the container cluster; it determines whether the name of each scheduled task exists in the current name list based on the name configuration information, and determines the scheduled task whose name does not exist in the current name list as the target scheduled task.
[0095] In one embodiment, when the processor executes the computer program, it further performs the following steps: in response to a scheduled task deletion instruction, deletes the currently deployed scheduled task whose name does not exist in the name configuration information from the container cluster.
[0096] In one embodiment, when the processor executes a computer program to determine at least one target scheduled task from the scheduled tasks, it specifically implements the following steps: in response to a scheduled task update instruction, it obtains the current version information of the deployed scheduled tasks corresponding to each scheduled task in the container cluster; when the current version information is inconsistent with the version configuration information, it determines the scheduled task as the target scheduled task.
[0097] In one embodiment, when the processor executes the computer program, it also performs the following steps: querying the image repository to see if there are task images for each target timed task; if not, extracting task integration key information from the task configuration information; obtaining a third code template, writing the task integration key information into the information reserved space in the third code template, and generating a third configuration file; and generating task images for each target timed task according to the third configuration file.
[0098] In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored. When the computer program is executed by a processor, it performs the following steps: obtaining a custom configuration file; wherein the custom configuration file includes task configuration information for at least one scheduled task; determining at least one target scheduled task from the scheduled tasks, and extracting key task deployment information from the task configuration information of each target scheduled task; obtaining a first code template, and writing the key task deployment information of each target scheduled task into the information reserved space in the first code template to generate a first configuration file corresponding to each target scheduled task; and allocating a corresponding container for each target scheduled task in a container cluster according to each first configuration file.
[0099] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: extracting application deployment key information from application configuration information; obtaining a second code template, writing the application deployment key information into the information reserved space in the second code template, and generating a second configuration file; and allocating a corresponding container for the application service in the container cluster according to the second configuration file.
[0100] In one embodiment, when a computer program is executed by a processor to allocate corresponding containers for each target scheduled task in a container cluster according to each first configuration file, the specific steps are as follows: obtaining the task image of each target scheduled task according to the task image address; obtaining the task environment image of each target scheduled task according to the task environment image address; and allocating corresponding containers for each target scheduled task in a container cluster at the task start time of each target scheduled task according to each first configuration file, each task image, and each task environment image.
[0101] In one embodiment, when a computer program is executed by a processor to determine at least one target scheduled task from the scheduled tasks, the following steps are specifically implemented: in response to a scheduled task addition instruction, a current name list is obtained, which is a list of names of currently deployed scheduled tasks in the container cluster; based on the name configuration information, it is determined whether the name of each scheduled task exists in the current name list, and the scheduled task whose name does not exist in the current name list is determined as the target scheduled task.
[0102] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: in response to a scheduled task deletion instruction, deleting the currently deployed scheduled task whose name does not exist in the name configuration information from the container cluster.
[0103] In one embodiment, when a computer program is executed by a processor to determine at least one target scheduled task from the scheduled tasks, the following steps are specifically implemented: in response to a scheduled task update instruction, the current version information of the deployed scheduled tasks corresponding to each scheduled task in the container cluster is obtained; when the current version information is inconsistent with the version configuration information, the scheduled task is determined as the target scheduled task.
[0104] In one embodiment, when the computer program is executed by the processor, it further performs the following steps: querying the image repository to see if there are task images for each target timed task; if not, extracting key task integration information from the task configuration information; obtaining a third code template, writing the key task integration information into the information reserved space in the third code template, and generating a third configuration file; and generating task images for each target timed task according to the third configuration file.
[0105] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.
[0106] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.
[0107] It should be noted that in this invention, terms such as "first" and "second" are used only for descriptive purposes and should not be construed as indicating or implying relative importance or order; terms such as "S101," "S102," "S201," and "S202" are used to distinguish steps and should not be construed as performing method steps in a specific order or sequence; when the following description relates to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The term "multiple" in this invention includes two or more, unless otherwise stated.
[0108] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.
Claims
1. A method for deploying a scheduled task, the method comprising: Obtain a custom configuration file; wherein the custom configuration file includes task configuration information for at least one scheduled task; the task configuration information includes task version configuration information; In response to the scheduled task update command, obtain the current version information of the deployed scheduled tasks corresponding to each scheduled task in the container cluster; When the current version information is inconsistent with the version configuration information, the scheduled task is determined as the target scheduled task, and the key task deployment information is extracted from the task configuration information of each target scheduled task. Obtain the first code template, and write the key task deployment information of each target timed task into the information reserved space in the first code template to generate the first configuration file corresponding to each target timed task. According to each of the first configuration files, a corresponding container is allocated for each of the target scheduled tasks in the container cluster.
2. The method according to claim 1, characterized in that, The custom configuration file also includes application configuration information of the application service to which the scheduled task belongs. Before allocating a corresponding container for each target scheduled task in the container cluster according to each of the first configuration files, the method further includes: Extract key application deployment information from the application configuration information; Obtain the second code template, write the application deployment key information into the information reserved space in the second code template, and generate the second configuration file; According to the second configuration file, a corresponding container is allocated for the application service in the container cluster.
3. The method according to claim 1, characterized in that, The key information for task deployment includes the task image address, the task environment image address, and the task start time. The step of allocating corresponding containers for each target scheduled task in the container cluster according to each of the first configuration files includes: Obtain the task image of each target timed task based on the task image address; Obtain the task environment image of each target timed task based on the task environment image address; Based on each of the first configuration files, each of the task images, and each of the task environment images, a corresponding container is allocated in the container cluster for each of the target scheduled tasks at the task start time of each target scheduled task.
4. The method according to claim 1, characterized in that, The task configuration information includes task name configuration information. Before extracting key task deployment information from the task configuration information of each of the target timed tasks, the process includes: In response to a scheduled task addition command, obtain the current name list, which is the list of names of currently deployed scheduled tasks in the container cluster; Based on the name configuration information, determine whether the name of each scheduled task exists in the current name list, and determine the scheduled task whose name does not exist in the current name list as the target scheduled task.
5. The method according to claim 4, characterized in that, The method further includes: In response to a scheduled task deletion command, the currently deployed scheduled task whose name does not exist in the name configuration information is deleted from the container cluster.
6. The method according to claim 3, characterized in that, Before obtaining the task image of each target timed task based on the task image address, the method further includes: Check if task images for each of the target scheduled tasks exist in the image repository; If it does not exist, extract the key information for task integration from the task configuration information; Obtain the third code template, write the key information of the task integration into the information reserved space in the third code template, and generate the third configuration file; The task images for each target timed task are generated based on the third configuration file.
7. A timed task deployment device, characterized in that, The device includes: A configuration acquisition module is used to acquire a custom configuration file; wherein, the custom configuration file includes task configuration information for at least one scheduled task; the task configuration information includes task version configuration information; The information extraction module is used to respond to the scheduled task update command, obtain the current version information of the deployed scheduled tasks corresponding to each scheduled task in the container cluster; when the current version information is inconsistent with the version configuration information, the scheduled task is determined as the target scheduled task, and the task deployment key information is extracted from the task configuration information of each target scheduled task. The file generation module is used to obtain the first code template, write the key task deployment information of each target timed task into the information reserved space in the first code template, and generate the first configuration file corresponding to each target timed task. The container allocation module is used to allocate corresponding containers for each target scheduled task in the container cluster according to each of the first configuration files.
8. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.
9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.
Citation Information
Patent Citations
Configurable timed task processing method and device, equipment and storage medium
CN112612592A
Quartz timed task-based domain task real-time scheduling method
CN114020436A
Method, terminal, medium and program for deploying applications across clusters in assembly line
CN114896027A