CN116661813A

CN116661813A - Application upgrading method, device and storage medium

Info

Publication number: CN116661813A
Application number: CN202310460455.0A
Authority: CN
Inventors: 鲍立焕; 谷嘉乐; 高伟; 周明伟
Original assignee: Zhejiang Dahua Technology Co Ltd
Current assignee: Zhejiang Dahua Technology Co Ltd
Priority date: 2023-04-23
Filing date: 2023-04-23
Publication date: 2023-08-29

Abstract

The application discloses an application upgrading method, an application upgrading device and a storage medium. The method can realize upgrading of the application deployed on the electronic equipment, and comprises the following steps: the electronic device obtains a first installation package, wherein the first installation package comprises a first upgrade script and at least one resource file. The electronic device generates an application instance running based on the at least one container from the at least one resource file. And the electronic equipment runs the first upgrading script according to the configuration information of the first installation package so as to finish upgrading the application instance according to the requirements of the application scene. The method can meet the diversified application upgrading requirements.

Description

Application upgrading method, device and storage medium

Technical Field

The present application relates to the field of computer technologies, and in particular, to an application upgrading method, an application upgrading device, and a storage medium.

Background

Applications on cloud platforms may run based on containers (containers), which may be understood as packages of applications and their running environments. Applications running on a container basis are also referred to as container applications.

kubernetes is a container management platform on which multiple container applications can run. Batch upgrades of multiple container applications can be implemented through the package manager of the kubernetes platform. The batch upgrade of multiple container applications by the package manager palm is actually to abstract the combination and orchestration of the installation packages to meet certain upgrade requirements, and then deploy the combined orchestrated installation packages.

However, the packet manager helm itself has limited orchestration capabilities and cannot meet the upgrade requirements of each of the multiple container applications.

Disclosure of Invention

The application provides an application upgrading method which is used for solving the problem that a palm cannot meet the upgrading requirement of diversified container applications due to the fact that the arrangement capacity is limited.

In a first aspect, the present application provides an application upgrading method, by which an application deployed on an electronic device may be upgraded, the method including: the electronic device obtains a first installation package, wherein the first installation package comprises a first upgrade script and at least one resource file. The electronic device generates an application instance running based on the at least one container from the at least one resource file. And the electronic equipment runs the first upgrading script according to the configuration information of the first installation package so as to finish upgrading the application instance according to the requirements of the application scene.

In the embodiment of the application, when the application instance is generated to upgrade the application, some operations required by the upgrade may need to be performed, and the operations can be completed through an upgrade script. The electronic device may add a first upgrade script of the application instance upgrade to a first installation package required to upgrade the application in advance. And then generating an application instance running based on at least one container according to the first installation package, and running a first upgrading script according to the configuration information of the first installation package to finish upgrading the application instance. The first upgrade script may be determined according to a requirement of an application scenario during upgrade, for example, when an upgrade operation needs to be performed on a certain container of the application instance alone, an upgrade script may be determined; or another upgrade script may be determined accordingly, requiring an upgrade operation on another container. By adding different upgrade scripts to the installation package, diversified upgrade requirements can be satisfied.

Optionally, the electronic device runs a first upgrade script according to the configuration information of the first installation package, including: and the electronic equipment acquires the name of the first container according to the configuration information of the first installation package. The electronic device determines a first container from the at least one container according to the name of the first container, and runs a first upgrade script in the first container.

The containers can be distinguished according to the names of the containers, so that the names of the containers can be recorded in the configuration information of the first installation package, the electronic equipment can determine the first container from at least one container according to the names of the first containers corresponding to the application examples in the configuration information, and the first upgrading script is operated in the first container.

Optionally, the configuration information of the installation package indicates that the set of containers is empty, and determining the first container from the at least one container according to the name of the first container includes: the electronic device traverses the workload in sequence until it is determined that there is a first container group in which the first container is located, one container group including at least one container. The electronic device determines the first container from the first container group according to the name of the first container.

Optionally, the configuration information of the installation package includes information of the second container group, and the method further includes: the electronic device determines the first container from the second container group based on the name of the first container.

Optionally, the method further comprises: the electronic equipment outputs prompt information according to the fact that the name of the first container is not obtained by the configuration information of the first installation package, and the prompt information is used for prompting that the first container cannot be obtained.

When the name of the first container is not acquired from the configuration information of the first installation package, the electronic device cannot acquire the first container. In this case, it cannot be determined in which container the first upgrade script is executed, and the electronic device outputs a prompt message to prompt to pause the operation of the first upgrade script, otherwise, an error occurs in the upgrade process.

Optionally, before the first installation package is acquired, the method further includes: the electronic device edits the first upgrade script. And the electronic equipment writes the information of the first upgrading script into the configuration information of the first installation package.

Optionally, the electronic device runs a first upgrade script in a first container of the at least one container, including: the electronic device copies the first upgrade script to the first container via the kubecl_cp command. The electronic device executes the first upgrade script through a kubectl_exec command.

Optionally, before the electronic device generates the application instance running based on the at least one container according to the at least one resource file, the method further includes: the electronic equipment acquires data to be migrated according to the configuration information of the first installation package, wherein the data to be migrated is user data used by the application instance before upgrading. The electronic equipment determines a target path of data to be migrated according to the configuration information of the first installation package, wherein the data in the target path is user data used by the application instance after upgrading. The electronic equipment migrates the data to be migrated according to the target path, and the data in the target path after migration is the same as the data to be migrated.

In the embodiment of the application, due to the architecture change of the application when the application is upgraded, the user data used by the application may need to be migrated. The configuration information of the first installation package stores data to be migrated and a target path of the data to be migrated, which are used before the application is upgraded, and the electronic equipment can migrate the data to be migrated to the target path according to the configuration information of the first installation package, so that the upgraded application can continue to use the data. By writing the data migration operation into the configuration information of the first installation package, the electronic equipment can perform data migration together when executing the first upgrade script.

In a second aspect, the present application provides an application upgrade apparatus. The device comprises: the device comprises an acquisition module, a generation module and an operation module. The acquisition module is used for acquiring a first installation package, wherein the first installation package comprises a first upgrading script and at least one resource file. The generation module is used for generating an application instance running based on at least one container according to at least one resource file. The operation module is used for operating the first upgrade script according to the configuration information of the first installation package so as to finish the upgrade of the application instance according to the requirement of the application scene.

Optionally, the operation module is specifically configured to: and acquiring the name of the first container according to the configuration information of the first installation package. Determining a first container from at least one container according to the name of the first container, and running a first upgrade script in the first container.

Optionally, the operation module is specifically configured to: the workload is traversed in sequence until a first container group is determined to exist in which the first container is located, one container group including at least one container. The first container is determined from the first group of containers according to its name.

Optionally, the operation module is further configured to: the first container is determined from the second set of containers based on the name of the first container.

Optionally, the operation module is further configured to: and outputting prompt information, wherein the prompt information is used for prompting that the first container cannot be acquired.

Optionally, the acquiring module is further configured to: editing the first upgrade script. And writing the first upgrading script into the configuration information of the installation package.

Optionally, the operation module is specifically configured to: the first upgrade script is copied to the first container by a kubecl_cp command. The first upgrade script is executed by a kubectl_exec command.

Optionally, the operation module is further configured to: and acquiring data to be migrated according to the configuration information of the first installation package, wherein the data to be migrated is user data used by the application instance before upgrading. And determining a target path of the data to be migrated according to the configuration information of the first installation package, wherein the data in the target path is user data used by the application instance after upgrading. And migrating the data to be migrated according to the target path, wherein the data in the target path after migration is the same as the data to be migrated.

In a third aspect, an embodiment of the present application provides an electronic device including a processor and a memory communicatively coupled to the processor. Wherein the memory stores computer-executable instructions that are executed by the processor to enable the processor to perform the method of any one of the first aspects.

In a fourth aspect, embodiments of the present application provide a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, cause the processor to perform the method of any one of the first aspects.

In a fifth aspect, embodiments of the present application provide a computer program product comprising a computer program stored in a computer readable storage medium, from which computer program a processor can read the computer program, the processor implementing the method according to any of the first aspects above when executing the computer program.

Drawings

Fig. 1 is a schematic view of a scenario of kubernetes application provided in an embodiment of the present application;

FIG. 2 is a schematic diagram of a workload component of a node according to an embodiment of the present application;

FIG. 3 is a flowchart of an application upgrade method according to an embodiment of the present application;

fig. 4 is a schematic diagram of a directory structure of a part format installation package according to an embodiment of the present application;

FIG. 5 is a schematic diagram of a directory structure of a value. Yaml configuration file according to an embodiment of the present application;

FIG. 6 is a schematic flow chart of another method for upgrading applications according to an embodiment of the present application;

FIG. 7 is a schematic diagram of the structure of the volume field in the value. Yaml directory according to an embodiment of the present application;

fig. 8 is a schematic structural diagram of an application upgrading device according to an embodiment of the present application;

fig. 9 is a schematic structural diagram of an electronic device according to an embodiment of the present application.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application will be further described in detail with reference to the accompanying drawings.

The container technology can implement virtualization of an operating system, through the container technology, isolation of multiple containers at an Operating System (OS) level can be implemented, and different containers can share an operating system kernel. The applications may run on a container (container) basis, which is also referred to as a container application. The container application may implement process-level packaging so that a single container may be migrated and deployed relatively quickly.

The containers are managed by a container management platform. kubernetes is a distributed container management platform based on container technology, and can realize management of multiple containers. Referring to FIG. 1, one scenario of a kubernetes application is shown. In fig. 1, a plurality of electronic devices (including physical servers, personal computers, etc.) mounted with kubernetes platform establish one distributed cluster through kubernetes platform. The distributed clusters may be referred to as kubernetes clusters. Each electronic device is a node (e.g., node 1, node 2, node 3, node 4, …) in the kubernetes cluster. Multiple container applications may be deployed on each node, e.g., node 1 deploys application a, application B, application C, application D, application E, application F, etc. A kubernetes cluster-based container application may migrate between nodes in the kubernetes cluster. For example, when the application a needs to be transferred from the node 1 to the node 2, a plurality of containers corresponding to the application a may be migrated to the node 2, and the node 2 may deploy the application a according to the plurality of containers.

Nodes in kubernetes clusters can be divided into master (master) nodes and slave (slave) nodes. kubernetes clusters may include one or more master nodes, with the other nodes in addition to the master node being slave nodes. The master node may schedule the container application running on the slave node. For example, as shown in FIG. 2, the container application of each node runs on multiple container groups pod, one pod comprising at least one container, at least one container group pod comprising a workload. In kubernetes clusters, the pod object is the smallest scheduling unit in the kubernetes cluster, so that kubernetes nodes can schedule container applications based on the pod object. For example, when the master node schedules the slave node, the pod object may be deployed at a certain node, or the pod object deployed by the node may be deleted. When a node deploys the pod object, at least one container included in the pod object is generated, and the node can run an application through the deployed pod object and the at least one container.

Due to the actual requirements of the application, upgrades to the container application may be required. Typically, the installation packages required for upgrading the container application are deployed to the kubernetes platform, and the package manager helm based on the kubernetes platform can schedule the deployed installation packages to achieve the upgrading of the container application. The installation packages required for the container application upgrades include the resources required for the container application upgrades. Specifically, the package manager helm may abstract the content (e.g., resources) included in the installation package, obtain corresponding kubernetes resources, and generate an application instance of the container application, to implement upgrading of the container application. Moreover, batch upgrades of multiple container applications can be implemented through the package manager of the kubernetes platform.

However, the package manager helm itself has limited orchestration capability, and when abstracting and orchestrating resources included in the installation package, the function of upgrading the pre/post script can only be achieved by a hook method, and the hook method needs to hard code an operation flow into the installation package, so that the upgrade policy applied by the container cannot be adaptively adjusted according to the scene. In addition, because there is a change in the architecture of the application during the upgrade, the data used by the application needs to be migrated after the upgrade. And the packet manager helm itself cannot migrate the volume data at the time of application upgrade.

In view of this, the embodiment of the application provides an application upgrading method, which enables an upgrade script to be added in an installation package by adding a strategy of embedding points in the installation package for upgrading. A portion of the operations that would otherwise be required to hard code an application upgrade into an installation package may be completed by the upgrade script, which is executed to complete the upgrade of the application. Because the upgrade script can be edited according to the upgrade requirement of the actual application scene, the matched upgrade script can be edited according to the actual upgrade requirement, so that the application upgrade is more flexible.

Fig. 3 is a schematic flow chart of an application upgrading method according to an embodiment of the present application. The process shown in fig. 3 is taken as an example of the process of executing the application upgrade by the electronic device, and the electronic device may be any device, for example, the electronic device may be a smart phone, a tablet computer, a desktop computer, and the like. The electronic device may be a node in the kubernetes cluster of the architecture shown in fig. 1, and the node may be a master node or a slave node. When the electronic equipment is a master node in the kubernetes cluster, the application upgrading flow executed by the electronic equipment upgrades the container application deployed on the slave node; when the electronic device is a slave node in the kubernetes cluster, the application upgrading process executed by the electronic device is to upgrade the container application deployed on the electronic device. It should be noted that, in the following description, the electronic device is taken as a slave node in the kubernetes cluster as an example, and the situation that the electronic device is taken as a master node is similar to the example, and is not repeated.

S301, the electronic device acquires a first installation package, wherein the first installation package comprises a first upgrade script and at least one resource file.

Multiple applications may be deployed on an electronic device, and when these applications need to be upgraded, the latest version of the installation packages for these applications are typically obtained. The form of the installation package may be various, for example, the installation package is a mirror package in a certain format, or the installation package may be a hart-format installation package in kubernetes platform.

The installation package may include resource files used for application upgrades. For example, when the installation package is an image package, the installation package includes upgrade codes and/or configuration files required for application upgrades. When the installation package is in the chart format, the installation package includes one or more sets of kubernetes resources, which may include, for example, resources related to the container application and persistent volume resources for information storage, etc.

In the embodiment of the application, the resource file required by at least one application upgrade can be put into the installation package in the same char format, and batch upgrade can be performed on at least one application according to the installation package. At least one application that can be batch upgraded constitutes a collection of applications. The division manner of the applications included in one application set is not limited. For example, a plurality of applications that need to be upgraded in the same period may be divided into one application set, or a plurality of applications may be divided into one application set according to a dependency relationship between the plurality of applications. For example, applications a, B, E, F with dependencies may be partitioned into one set. Alternatively, the applications a, B, E, F that need to be upgraded in the same time period may be divided into one set. The batch upgrading of at least one application in the application set can be realized through one installation package, and the efficiency of the application upgrading can be improved.

For convenience of description, an installation package in a hart format including at least one resource file required for application upgrade will be referred to as a first installation package.

The electronic equipment acquires the first installation package, generates a new application instance corresponding to at least one application according to the first installation package, deletes the original application instance of at least one application, and can realize upgrading of at least one application. Considering that there may be additional upgrade requirements of a certain application or certain applications in an application scenario, some additional upgrade operations need to be performed, for example, user data migration, historical data cleaning, etc. need to be performed on the application according to the application scenario of the certain application. Additional upgrade requirements may be different for different application scenarios. While the resource files in the first installation package may not meet the additional upgrade requirements of each application scenario, in the related art, these additional upgrade operations may be hard-coded into the installation package in a hook manner, which may result in inflexible upgrade policies. Therefore, in the embodiment of the application, one or more upgrade scripts can be placed in the first installation package, and the upgrade operations are realized through the upgrade scripts.

Specifically, the electronic device may set a corresponding upgrade script for each application in the application set. For example, for a first application (application a) in the application set, it may be determined whether to configure a corresponding upgrade script for application a according to actual upgrade requirements. If it is determined that the upgrade script is configured for the application a, the upgrade script (e.g., the first upgrade script) of the application a may be edited in advance according to actual upgrade requirements. And so on, for at least one application in the application set, multiple upgrade scripts may be provided.

The electronic device may add the obtained plurality of upgrade scripts to the first installation package. For example, the addition of the plurality of upgrade scripts may be implemented by adding a start location and an end location of the execution of the upgrade scripts in the first installation package. Taking the first upgrade script as an example, a start position and an end position of execution of the first upgrade script may be saved in configuration information of the first installation package. And determining the starting position and the ending position of the execution of the first upgrade script according to the configuration information of the first installation package, so that the first upgrade script is operated according to the configuration information of the first installation package. The starting position of the execution of the upgrade script may be regarded as a buried point in the installation package, and the ending position of the execution of the upgrade script may be regarded as a buried point in the installation package. The addition of the plurality of upgrade scripts is realized by adding the starting position and the ending position of the execution of the upgrade scripts in the first installation package, which is equivalent to the addition of the plurality of upgrade scripts by adding the embedding points in the first installation package.

The configuration information of the first installation package includes the configuration required to run the first installation package and/or the upgrade script in the first installation package, which configuration information is typically presented in the form of a file directory. For example, referring to fig. 4, a directory structure of a first installation package in a char format according to an embodiment of the present application is shown. The directory structure of the first installation package comprises the following information: a directory for describing yaml files of installation package information, a directory for storing default configuration required for installing packages, a directory for storing configuration files of applications, a directory for storing upgrade scripts of applications, rights-related resource files, a directory for recording contents of values. The information stored in these directories may be referred to as configuration information of the first installation package. Wherein, the directory of yaml file for describing the installation package information may be expressed in char.yaml, yaml representing the file type. The directory for storing default configuration required for installing a package may be represented by values, the directory for storing configuration files of an application may be represented by values, the directory for storing upgrade scripts of an application may be represented by files, and the directory for recording the contents of the values, yaml configuration files may be represented by templates/configmap, yaml. The directory of rights related resources may be represented by templates/role. Yaml, etc.

As shown in fig. 5, is a directory structure of the values. Yaml configuration file. The information in the values. Yaml configuration file includes: application instance name, application installation package address, application installation package version, profile path used by the application, pre-embedded point, post-embedded point, etc. Taking application a in the application set as an example, an application instance name appname of the application a corresponds to "test1", an installation package address char of the application a corresponds to "oci:// image. The pre-buried point in the first installation package may be represented by a pre-directory, which may be used to store information of the upgrade script used by application a. The post-burial point in the first installation package may be represented by a post directory, which may also be used to store information of the upgrade script used by application a.

Further, the pre directory includes command field, file field and route field. The command field may be used to store a simpler command than a command executed by the upgrade script, that is, when the upgrade operation for the application a is simpler, the upgrade script may not be edited separately, and the file field may be set to a null value at this time, and only the operation required for the upgrade is edited into the command field. In this way, the electronic device can perform these operations directly from the command field. The file field may be used to store a storage path of an upgrade script required when the application a is upgraded, through which the electronic device may obtain the upgrade script. The route field is used to store the path that the upgrade script points to when executing, that is, the location in the system when the upgrade script executes. The route field specifically includes: workload name, workload type, container group name, and the name of the container executing the upgrade script. The workload name is denoted by workloadname, the workload type is denoted by workloadtype, the container group name is denoted by podname, and the container name is denoted by containername.

The electronic device may write information of the plurality of upgrade scripts to configuration information of the first installation package according to a directory structure of the first installation package. Taking the first upgrade script as an example, because the first upgrade script is applied to upgrade of the application a, the electronic device may write the first upgrade script into the first installation package at the embedded point corresponding to the application a. The electronic device may find the pre/post directory of the application a in the value.yaml configuration file according to the application name of the application a, and write the file name of the first upgrade script into the file command under the pre/post directory of the application a, where the file command is used to store the file name of the first upgrade script. And writing the information of the first upgrade script into the template/configmap.yaml directory in the configuration information of the first installation package through the {.files.get } command of the palm package manager. It should be understood that, specifically, writing the information of the first upgrade script into the pre directory or the post directory may determine whether to place the first upgrade script into the pre-buried point or the post-buried point according to the order of the upgrade scripts. Since the name of the container pointed by the execution of the first upgrade script is also specified when the first upgrade script is edited, the name of the container pointed by the execution of the first upgrade script is also written into the route field.

After writing information of a plurality of upgrade scripts required for upgrading at least one application into the first installation package, the first installation package can be deployed to the kubernetes platform. Batch upgrades to at least one application are implemented through the package manager of the kubernetes platform. In the following, an example of upgrading a first application in at least one application by using an electronic device is described, and a process of upgrading other applications in at least one application by using the electronic device is similar to the process, and is not repeated.

S302, the electronic equipment generates an application instance running based on at least one container according to at least one resource file.

And the electronic equipment generates an application instance corresponding to the first application according to at least one resource file in the first installation package. For convenience of description, the application instance corresponding to the first application is simply referred to as a first application instance. It is understood that the first application instance is an application instance that is run based on at least one container. The electronic device may create at least one container through a palm package manager from a first installation package deployed on a kubernetes platform, and execute a first application instance based on the created at least one container. When the first application instance is generated, the electronic device may acquire content under the templates/configmap.yaml directory in the first installation package, for example, parameters such as an application name, a repository address, a template version, and values content of the first application. And the electronic equipment generates a first application instance according to the acquired application name, warehouse address, template version and values of the first application.

S303, the electronic device runs a first upgrade script according to the configuration information of the first installation package so as to upgrade the application instance according to the requirements of the application scene.

The electronic device can sequentially call one or more upgrade scripts required by the upgrade of the first application instance according to the configuration information of the first installation package. For example, the electronic device may invoke one or more upgrade scripts in the first installation package through the api interface of the palm package manager. Taking the example that the electronic device calls the first upgrade script, the electronic device can acquire the information recorded in the pre directory and the post directory under the value.yaml directory in the configuration information of the installation package, and acquire the first upgrade script according to the information recorded in the pre directory and the post directory. For example, the electronic device first reads information in the command field, and if the command field is empty, reads the file field. The file field includes a storage path of the first upgrade script, and the electronic device may obtain the first upgrade script from the storage path pointed to by the file field.

And the electronic equipment runs the first upgrading script after acquiring the first upgrading script. Since the first application instance generates a workload on the kubernetes platform, wherein a workload is composed of at least one pod, and a pod can be composed of at least one container, the first application instance corresponds to the at least one container on the kubernetes platform. The paths of the individual containers of a workload are different, and therefore, before the first upgrade script is run, the container running the first upgrade script needs to be determined.

Since the first application instance includes at least one container, different containers may have different names. Containers may be distinguished by different names. The name of the container is recorded in the route field under the configuration information value. Yaml directory of the first installation package. The electronic device may obtain the name of the first container recorded in the route field according to the configuration information of the first installation package. In addition, if the electronic device does not acquire the name of the first container according to the configuration information of the first installation package, the electronic device outputs prompt information, and the prompt information is used for prompting that the first container cannot be acquired.

The configuration information of the installation package includes the name of the workload and the name of the container group in addition to the name of the first container. The names of the workload, the names of the container groups, and the names of the containers have a correspondence. For example, the 4 different container groups corresponding to the workload 1 are 4 different container group names (container group 1, container group 2, container group 3, container group 4) respectively, wherein the 4 different containers corresponding to the container group 1 are 4 different container names (container 1, container 2, container 3, container 4) respectively, and the 4 different containers corresponding to the container group 2 are 4 different container names (container 2, container 3, container 4, container 5) respectively. It can be seen that there may be containers of the same name in different groups of containers. Thus, the electronic device may determine the first container from the at least one container according to the name of the first container.

When the route field is not empty in the configuration information of the installation package, and the route field includes the name of the first container but the container group name is empty, it may be understood that the upgrade of the first upgrade script does not point to a specific certain container group, and the first upgrade script may run in all container groups in the workload. At this point, the electronic device may traverse the workload in sequence until a first container group in which the first container is located is determined, and the first container is determined from the first container group according to the name of the first container. When the route field in the configuration information of the installation package is not empty, and the route field includes the name of the first container and the name of the second container group, the electronic device may directly determine the first container from the second container group according to the name of the first container.

When the route field in the configuration information of the installation package is empty, the first upgrade script execution does not point to a specific workload, container group, container, and the upgrade script may be considered suitable for all workloads. At this time, the electronic device runs the first upgrade script in all the workloads, so that the first upgrade script can perform upgrade operations on other application instances except the first application instance.

After the electronic device determines that the first upgrade script is executed in the first container, the first upgrade script is run in the first container. While running the first upgrade script, the electronic device copies the first upgrade script to the first container via the kubctl_cp command. Then, the upgrade operation of the first application instance can be implemented by executing the first upgrade script through the kubectl_exec command. In addition, the electronic device may record the execution condition of the embedded point in the first installation package, and when executing the first upgrade script, if the execution of the first script is finished, mark the embedded point with the execution being finished as "executed". If the script "executed" of the embedded point is not marked after the execution of the first script is finished, a scene of restarting after pausing when upgrading the application through the first installation package occurs, and the first upgrade script is repeatedly executed. Thus, repeated execution of the upgrade script requires the user to ensure idempotent properties of the upgrade script, that is, to ensure that the first upgrade script, when repeatedly executed, achieves the same results as the previous execution.

In the embodiment of the application, after the electronic device runs the first upgrade script according to the configuration information of the first installation package, the first upgrade script executes some operations (such as user data migration and historical data cleaning) necessary for application upgrade, and finally the upgrade of the application instance is completed, and the operations are realized through the first upgrade script, so that the policy of application upgrade is more flexible.

Referring to fig. 6, an overall flow of an application upgrading method provided by an embodiment of the present application is shown. Therefore, a developer can determine different application sets according to different application upgrading requirements, can determine different upgrading schemes aiming at different application sets, and configures corresponding upgrading scripts for different upgrading schemes. After the operation and maintenance personnel obtain the upgrade scheme and the upgrade script, the upgrade script is written into the installation package, and the installation packages required by upgrading a plurality of applications are deployed on the kubernetes platform. The package manager of kubernetes platform will automatically acquire the installation package and then render the information in the installation package to create the application instance. And creating a workload and a container on the kubernetes platform, and running the generated application instance through the workload and the container. For one application instance in a plurality of application instances, if an upgrade script exists, the upgrade script needs to be acquired to upgrade the application instance. Therefore, the method can reduce the operation required by operation and maintenance personnel and improve the efficiency of application upgrading.

Based on the same inventive concept, the embodiment of the application also provides a data migration method. When an application is updated, the volume data may be changed from a temporary volume to a persistent volume, from a local volume to a ceph volume, and the like, due to a change in the application architecture, and the volume data may be migrated. The data migration operation can be added to the front embedded point and the rear embedded point of the configuration information of the first installation package, and the data migration operation can be executed together when the first upgrade script is run. This can be accomplished by adding the volume field in the configuration information value. Yaml directory of the first installation package. As shown in fig. 7, the volume field includes the fields of src_pvc_name, src_mount_path, src_files_path, des_pvc_name, des_mount_path, des_files_path, and the like. Where src_pvc_name represents the source pvc name and src_mount_path represents the mount path mounted on the child podsrcpod. The src_files_path represents a path of data to be migrated in the source pvc, and it can be understood that the data to be migrated is data used before the application instance is upgraded. des_pvc_name represents the target pvc name, des_mount_path represents the mount path mounted on the child add. The des_files_path represents a target pvc path, namely a target path of data to be migrated, and accordingly, the data in the target path is the data used by the application instance after upgrading.

The electronic device automatically creates two child pod when running the first upgrade script through the first installation package by adding the volume field in the configuration information of the first installation package. The two child pod are respectively a srcpod and a despod, and the two child pod are not associated with the old application instance pod and the pod of the new application instance, but are only used for data migration during upgrading, and the two child pod needs to be deleted after the migration is completed so as not to waste cluster pod resources. The two child pods are respectively mounted under a source pvc and a target pvc, wherein the source pvc points to the old application instance pod and the target pvc points to the pod of the newly generated application instance. That is, by mounting the srcpod under the source pvc, the srcpod can be caused to read and store data in the old application instance pod, and by mounting the despin under the target pvc, the despin can be caused to read and store data in the pod of the newly generated application instance. Thus, by transferring the data in the srcpod to the despod, migration of volume data between the old application instance pod and the pod of the new application instance can be achieved. It should be noted that, before mounting, an attempt is made to acquire the target pvc, if the target pvc already exists, the target pvc is directly mounted, if the target pvc does not exist, a sub-chart packet is rendered through a palm template grammar, yaml details of the target pvc are acquired from the sub-chart packet, and the target pvc is created. If the source pvc does not exist, the electronic device outputs information prompting the abnormality. After creating two child pods, recording the mounting path of the srcpod under the src_mount_path directory, and recording the mounting path of the despin under the des_mount_path directory.

And the electronic equipment transmits the data to be migrated in the srcpod to the despod according to the two created child pods so as to realize the migration of the user data. The electronic equipment acquires the data to be migrated in the src_files_path directory, determines a target path of the data to be migrated according to the des_files_path directory, and migrates the data to be migrated according to the target path recorded in the des_files_path directory. Since the srcpod and the despod open 22 ports and provide secure shell (ssh) service, the electronic device transmits the data to be migrated to the des_files_path of the despod-mounted target pvc by combining the ssh service with the tar command. And deleting the two child pod tasks after the execution is finished, and after the application is pulled up, mounting the target pvc in an application container to finish the migration of user data.

Referring to fig. 8, based on the same inventive concept, an application upgrading device 800 is further provided in the embodiment of the present application. The apparatus 800 includes: an acquisition module 801, a generation module 802 and an operation module 803. The obtaining module 801 is configured to obtain a first installation package, where the first installation package includes a first upgrade script and at least one resource file. The generating module 802 is configured to generate an application instance running based on at least one container according to at least one resource file. The operation module 803 is configured to operate the first upgrade script according to the configuration information of the first installation package, so as to complete the upgrade of the application instance according to the requirements of the application scenario.

Optionally, the operation module 803 is specifically configured to: and acquiring the name of the first container according to the configuration information of the first installation package. Determining a first container from at least one container according to the name of the first container, and running a first upgrade script in the first container.

Optionally, the operation module 803 is specifically configured to: the workload is traversed in sequence until a first container group is determined to exist in which the first container is located, one container group including at least one container. The first container is determined from the first group of containers according to its name.

Optionally, the operation module 803 is further configured to: the first container is determined from the second set of containers based on the name of the first container.

Optionally, the operation module 803 is further configured to: and outputting prompt information, wherein the prompt information is used for prompting that the first container cannot be acquired.

Optionally, the obtaining module 801 is further configured to: editing the first upgrade script. And writing the first upgrading script into the configuration information of the installation package.

Optionally, the operation module 803 is specifically configured to: the first upgrade script is copied to the first container by a kubecl_cp command. The first upgrade script is executed by a kubectl_exec command.

Referring to fig. 9, based on the same inventive concept, an embodiment of the present application provides an electronic device 900, including: at least one processor 901, at least one memory 902, and computer program instructions stored in the memory that when executed by the processor implement an application upgrade method as described above.

Optionally, the processor 901 may be a central processor, an application specific integrated circuit (english: application Specific Integrated Circuit, abbreviated as ASIC), one or more integrated circuits for controlling program execution, a hardware circuit developed using a field programmable gate array (english: field Programmable Gate Array, abbreviated as FPGA), or a baseband processor.

Optionally, the Read-write lock operation device further includes a Memory 902 connected to the at least one processor 901, where the Memory 902 may include a Read Only Memory (ROM), a random access Memory (Random Access Memory, RAM) and a disk Memory. The memory 902 is used to store data required by the processor 901 when it is running. The number of memories 902 is one or more. The memory 902 is also shown in fig. 9, but it should be noted that the memory 902 is not an essential functional module, and is therefore shown in fig. 9 by a broken line.

Based on the same inventive concept, embodiments of the present application also provide a computer-readable storage medium storing computer instructions that, when run on a computer, cause the computer to perform an application upgrade method as described above.

In a specific implementation, the computer readable storage medium includes: a universal serial bus flash disk (Universal Serial Bus flash drive, USB), a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk or an optical disk, or the like, which can store program codes.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-described division of the functional modules is illustrated, and in practical application, the above-described functional allocation may be performed by different functional modules according to needs, i.e. the internal structure of the apparatus is divided into different functional modules to perform all or part of the functions described above. The specific working processes of the above-described systems, devices and units may refer to the corresponding processes in the foregoing method embodiments, which are not described herein.

In the several embodiments provided by the present application, it should be understood that the disclosed apparatus and method may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the modules or units is merely a logical functional division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted, or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in the embodiments of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit. The integrated units may be implemented in hardware or in software functional units.

The integrated units, if implemented in the form of software functional units and sold or used as stand-alone products, may be stored in a computer readable storage medium. Based on such understanding, the technical solution of the present application may be embodied in essence or a part contributing to the prior art or all or part of the technical solution in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (processor) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: a universal serial bus flash disk (Universal Serial Bus flash disk), a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk or an optical disk, or other various media capable of storing program codes.

It will be apparent to those skilled in the art that various modifications and variations can be made to the present application without departing from the scope of the application. Thus, it is intended that the present application also include such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.

Claims

1. An application upgrade method, comprising:

acquiring a first installation package, wherein the first installation package comprises a first upgrading script and at least one resource file;

generating an application instance running based on at least one container according to the at least one resource file;

and running the first upgrading script according to the configuration information of the first installation package so as to finish upgrading the application instance according to the requirement of the application scene.

2. The method of claim 1, wherein running the first upgrade script according to the configuration information of the first installation package comprises:

acquiring the name of the first container according to the configuration information of the first installation package;

determining the first container from the at least one container according to the name of the first container;

and running the first upgrading script in the first container.

3. The method of claim 2, wherein the configuration information indicates that a group of containers is empty, the first container being determined from the at least one container based on a name of the first container, comprising:

traversing the workload in sequence until a first container group in which the first container is located is determined, wherein one container group comprises at least one container;

The first container is determined from the first group of containers according to the name of the first container.

4. The method of claim 3, wherein the configuration information includes information for a second set of containers, the method further comprising:

the first container is determined from the second set of containers according to the name of the first container.

5. The method of claim 3 or 4, wherein the method further comprises:

and outputting prompt information according to the condition that the name of the first container is not acquired by the configuration information of the first installation package, wherein the prompt information is used for prompting that the first container cannot be acquired.

6. The method of claim 1, wherein prior to obtaining the first installation package, the method further comprises:

editing the first upgrade script;

and writing the information of the first upgrading script into the configuration information of the first installation package.

7. The method of claim 1, wherein prior to generating an application instance running based on at least one container from the at least one resource file, the method further comprises:

acquiring data to be migrated according to the configuration information of the first installation package, wherein the data to be migrated is user data used by the application instance before upgrading;

Determining a target path of the data to be migrated according to the configuration information of the first installation package, wherein the data in the target path is user data used by the application instance after upgrading;

and migrating the data to be migrated according to the target path, wherein the data in the target path after migration is the same as the data to be migrated.

8. An application upgrading apparatus, comprising:

the system comprises an acquisition module, a storage module and a storage module, wherein the acquisition module is used for acquiring a first installation package, and the first installation package comprises a first upgrading script and at least one resource file;

the generation module is used for generating an application instance running based on at least one container according to the at least one resource file;

and the operation module is used for operating the first upgrading script according to the configuration information of the first installation package so as to finish upgrading the application instance according to the requirement of the application scene.

9. An electronic device, comprising: a processor, and a memory communicatively coupled to the processor;

the memory stores computer-executable instructions;

the processor executes computer-executable instructions stored in the memory to implement the method of any one of claims 1-7.

10. A computer readable storage medium having stored therein computer executable instructions which when executed by a processor are adapted to carry out the method of any one of claims 1-7.