Remote upgrading method, electronic equipment and storage medium

Abstract

The invention provides a remote upgrading method, electronic equipment and a storage medium, the method is applied to a terminal, and the method comprises the following steps: in response to an upgrading notification of a server, downloading a target upgrading mirror image from a mirror image warehouse, the target upgrading mirror image being used for updating at least one application program of the terminal, the application program is deployed on the terminal through containerization; and running the target upgrading mirror image in a local container to update the application program corresponding to the target upgrading mirror image.

Description

Technical Field

[0001] The present disclosure belongs to the technical field of platform as a service, and particularly relates to a remote upgrade method, an electronic device, and a storage medium. Background Art

[0002] Remote OTA (Over-The-Air) upgrade technology, as a method for wirelessly updating software, firmware, or an operating system, is gradually penetrating and changing the traditional software update and maintenance mode. OTA upgrade needs to download the upgrade package to the device through the air interface of the wireless network and write it into the flash to complete the upgrade. Usually, the entire new firmware image needs to be downloaded, which may take a long time. Moreover, if the device loses power or the network is unstable during the upgrade process, the upgrade may fail, and the user needs to manually intervene to perform a re-upgrade. Summary of the Invention

[0003] The present disclosure provides a remote upgrade method, an electronic device, and a storage medium, which can effectively solve the above problems.

[0004] The present disclosure is implemented as follows:

[0005] In a first aspect, the present disclosure provides a remote upgrade method, which is applied to a terminal, and the method includes:

[0006] In response to an upgrade notification from a server, download a target upgrade image from an image repository, where the target upgrade image is used for updating at least one application program of the terminal, and the application program is deployed on the terminal through containerization;

[0007] Run the target upgrade image in a local container to update the application program corresponding to the target upgrade image.

[0008] In a second aspect, the present disclosure provides a remote upgrade method, which is applied to a server, and the method includes:

[0009] Obtain new information of the target upgrade image in the image repository;

[0010] Generate an upgrade notification according to the new information and send it to at least one terminal. The upgrade notification is used to cause the terminal to download a target upgrade image from the image repository. The target upgrade image is used for updating at least one application program of the terminal. The application program is deployed on the terminal through containerization. The target upgrade image runs in a container on the terminal to update the application program corresponding to the target upgrade image on the terminal.

[0011] In a third aspect, the present disclosure provides an electronic device, including:

[0012] A memory that stores execution instructions; and

[0013] A processor that executes the execution instructions stored in the memory, such that the processor executes the method described in the first aspect or the method described in the second aspect.

[0014] In a fourth aspect, the present disclosure provides a readable storage medium storing execution instructions, which when executed by a processor are used to implement the method described in the first aspect or the method described in the second aspect.

[0015] Compared with the prior art, the beneficial effects of the present disclosure are:

[0016] 1. The present disclosure provides a remote upgrade method. By combining Docker with OTA upgrade technology, it not only greatly improves the flexibility and efficiency of application deployment on terminals, supports centralized management and upgrade of a large number of containerized applications, reduces operation and maintenance costs, but also provides strong technical support for implementing continuous integration / continuous deployment (CI / CD). Combining with the CI / CD process, it can easily achieve continuous iteration and optimization of applications.

[0017] 2. The upgrade process requires no manual intervention and automatically completes the remote update of the application, greatly shortening the update cycle. Through a reasonable deployment strategy, the upgrade can be completed without interrupting the service, improving the user experience.

[0018] 3. It has more advantages in the security of the upgrade process. By adding an upgrade script to be downloaded to the terminal for upgrade verification and the method of rolling back to the previous version in case of upgrade failure, it can ensure that the upgrade of the running system will not directly crash due to problems. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] To more clearly illustrate the technical solutions of the embodiments of the present disclosure, the following will briefly introduce the drawings required for the embodiments. It should be understood that the following drawings only show some embodiments of the present disclosure and should not be regarded as limiting the scope. For those of ordinary skill in the art, other relevant drawings can be obtained based on these drawings without creative efforts.

[0020] Figure 1 is the first flowchart of the remote upgrade method S100 provided by the embodiment of the present disclosure.

[0021] Figure 2 is the second flowchart of the remote upgrade method S200 provided by the embodiment of the present disclosure.

[0022] Figure 3 is the first structural schematic diagram of the course scheduling device 1000 provided by the embodiment of the present disclosure.

[0023] Figure 4 It is the second structural schematic diagram of the course scheduling device 2000 provided by an embodiment of the present disclosure. Specific embodiments

[0024] The present disclosure will be further described in detail below in conjunction with the accompanying drawings and embodiments. It can be understood that the specific embodiments described herein are only used to explain the relevant content and do not limit the present disclosure. Additionally, it should be noted that for the convenience of description, only parts related to the present disclosure are shown in the drawings.

[0025] It should be noted that, without conflict, the embodiments in the present disclosure and the features in the embodiments can be combined with each other. The technical solutions of the present disclosure will be described in detail below with reference to the drawings and embodiments.

[0026] Unless otherwise specified, the illustrated exemplary embodiments / embodiments are understood to provide exemplary features of various details of some ways that can implement the technical concept of the present disclosure in practice. Therefore, unless otherwise specified, without departing from the technical concept of the present disclosure, the features of various embodiments / embodiments can be additionally combined, separated, interchanged, and / or rearranged.

[0027] Embodiment 1

[0028] Refer to Figure 1 , an embodiment of the present disclosure provides a remote upgrade method S100.

[0029] Specifically, the method S100 is applied to a terminal, and the method S100 includes:

[0030] S102. In response to an upgrade notification from a server, download a target upgrade image from an image repository, where the target upgrade image is used for updating at least one application program of the terminal, and the application program is deployed on the terminal through containerization; the upgrade notification is generated by the server based on the newly added information of the target upgrade image in the obtained image repository;

[0031] S104. Run the target upgrade image in a local container to update the application program corresponding to the target upgrade image.

[0032] For the remote upgrade method provided by the embodiment of the present disclosure, a server is built in a local environment, and a remote upgrade environment is deployed between the server and the terminal using Docker, bringing the terminal device into a more secure and controllable environment. Moreover, the application programs to be updated and their dependencies are packaged into lightweight and portable images using Docker container technology, realizing a consistent running environment for the applications, thereby improving the security and reliability of remote upgrades.

[0033] The method selects one or more of multiple terminal devices in the same local area network as the server, such as a PC. Then, the server uses Docker tools to control the upgrade process within the local area network.

[0034] Furthermore, the server can be a terminal that needs to be upgraded using an upgrade image, or it can be a terminal only used for the upgrade process of terminals within the same local area network.

[0035] Both the server and the terminal specifically use the Linux system.

[0036] The method mainly relies on the remote pulling of Docker images and the automatic restart or replacement mechanism of containers for the upgrade process.

[0037] The method increases the target object group for Docker upgrades. The traditional method of using Docker containers is mainly for development, testing, and production environments, aiming to ensure the consistency of these environments, thereby optimizing their performance and security. For terminal devices such as smartphones, smart cars, and smart home devices, and their user groups, OTA upgrade processing is carried out in the traditional way.

[0038] The method deploys a remote upgrade environment through docker and incorporates these object groups into a more secure and controllable environment for upgrade processing.

[0039] Among them, upgrading through Docker technology is relatively flexible. The server and the terminal can communicate and connect one-to-one. By using Docker Compose, or one-to-many, using Docker Swarm and Portainer, the single Docker host or Docker Swarm cluster can be intuitively managed and monitored. Furthermore, Docker Cloud Agents can be added for many-to-many centralized management, and through the above Docker tools, the Docker server can be effectively managed and the upgrade tasks of multiple terminals can be carried out simultaneously.

[0040] In some embodiments, all terminals connected to the server adopt the same architecture.

[0041] That is, terminals with different architectures are correspondingly connected to the server with the same architecture as theirs.

[0042] Furthermore, servers with different architectures form a server cluster.

[0043] After the server completes its own upgrade, it can build a target upgrade image according to the local image file and upload it to the image repository under the same local area network for terminals with the same architecture to download.

[0044] In some other embodiments, the terminals connected to the server adopt different architectures.

[0045] At this time, the target upgrade images corresponding to other architectures in the image repository need to be uploaded through other means, such as the upload by technicians.

[0046] Building and publishing Docker images: Developers build applications locally or in a CI / CD pipeline and package them into Docker images, and then push the images to a remote image repository (such as Docker Hub, Alibaba Cloud Image Service, etc.). The server can, based on the update requirements of the application programs of the terminals it controls, notify the terminals to download from the image repository when there are new target upgrade images.

[0047] The method can also deploy the image repository directly on the server of the local local area network without relying on a remote image repository. For example, after directly building the target upgrade image on the server, it is uploaded to the image repository for the terminals to perform upgrade processing.

[0048] After the method pulls the image to the image repository within the local local area network and distributes it through the local local area network, it can eliminate the process where all terminals need to connect to the OTA server individually, which is complex and inconvenient.

[0049] Moreover, the OTA servers required for OTA upgrades are generally not universal and all need to be set up by each manufacturer on their own. The upgrade environment built based on Docker can provide an efficient, reliable, and flexible solution.

[0050] Furthermore, each terminal device can generate various image versions locally through Docker tools, and as a server, provide these images for other terminals in the same local area network to use for upgrades, or can also be used for its own upgrade. Therefore, there is no obvious distinction between the server and the terminals.

[0051] The server can also be a cloud data warehouse, such as Alibaba Cloud Data Warehouse, or a PC within the local area network can be used as the server.

[0052] In the image repository, different image versions are distinguished by tags or version numbers to ensure that each version is traceable and easy to manage.

[0053] The method also has more controllability in version management. Similar to git or svn, it can upload and download image versions. The version verification rules are verified by the Docker server and then pushed to the terminals for upgrade processing, that is, the C->S->C mode.

[0054] Further, the version number may include a major version number and a minor version number. The major version number is used to determine the iterative upgrade of functions, while the minor version number is used to determine the applicable terminal architecture.

[0055] In conclusion, the version control of OTA upgrades focuses more on the remote upgrade and firmware management of devices, while Docker focuses more on the management and deployment of container images. The granularity and precision of the two are different, and Docker is more precise, so its scope of application is wider and it is more flexible to use in different environments.

[0056] In some embodiments, the upgrade notification is generated by the server based on the new information of the target upgrade image in the image repository, and includes:

[0057] The server regularly monitors the image repository using a scheduled task, or the server uses an automation tool to monitor the image repository.

[0058] The server monitors the image versions corresponding to these applications based on the applications used on the connected terminals.

[0059] When a new version of the image is released, the server can trigger the upgrade process through API calls, Webhooks or other automation tools. Or monitor the update of the image version in the image repository by setting a scheduled task.

[0060] In contrast, OTA is more triggered by the terminal device actively checking for updates (such as script verification) or server push. Therefore, upgrading the terminal through Docker is more autonomous.

[0061] In some other embodiments, the upgrade notification can be sent by a staff member under the operation of the server. At this time, it is not necessary for the server to detect the update of the image version to trigger the upgrade process, and the final image version to which the terminal needs to be upgraded is also determined by the staff member himself.

[0062] In step S102, in response to the upgrade notification from the server, downloading the target upgrade image from the image repository includes:

[0063] The prerequisite for the terminal to perform the upgrade process is that the target upgrade image needs to meet the determination of the dependencies and priority relationships required for the application upgrade by the sh script. The version of the target upgrade image selected by the terminal for its own upgrade is confirmed by the sh script of the terminal, and different terminals need to form an upgrade path for themselves through self-check.

[0064] For example, based on the selection of the target upgrade image, the terminal can adopt the multi-differential upgrade method to first transition to an intermediate version, thereby obtaining the dependencies required for further upgrades, or to meet the priority order, and can also directly adopt the full-scale upgrade method to upgrade to the required version.

[0065] Correspondingly, the terminal selects one or more images as the target upgrade image.

[0066] The batch upgrade method adopted by the server is only used to notify the terminals connected to it of the final version to which they need to be upgraded.

[0067] In some embodiments, after the terminal performs the upgrade process, it feeds back the upgrade result to the server.

[0068] If the terminal fails to upgrade to the final version due to the inability to use the image in the image repository, the terminal feeds back the reason for the upgrade failure to the server. For example, it lacks a certain intermediate version and cannot meet the dependencies required for the upgrade. At this time, the server can point to the image version containing the dependency and send the upgrade notification to the terminal again.

[0069] After the terminal upgrades to the intermediate version and feeds back to the server to indicate that the upgrade is successful, the server will send the upgrade notification to upgrade to the final version again, and so on, until the terminal upgrades to the final version specified by the server or terminates the upgrade.

[0070] If the server cannot find the image version containing the dependencies that meet the terminal's upgrade requirements, it sends a notification to prompt the terminal to terminate the upgrade.

[0071] In some embodiments, the target upgrade image is used for the update of at least one application program of the terminal, including:

[0072] The target upgrade image is constructed by the server.

[0073] In some embodiments, the address of the image repository where the original upgrade image is located is not in communication connection with the terminal.

[0074] The method can also implement cross-region upgrade processing.

[0075] The machine on which the image repository is deployed and the terminal to be upgraded can be located in different local area networks, and are connected to the two respectively through the server. Therefore, after the server obtains the upgrade image from the image repository, it can, after completing its own upgrade process, construct the target upgrade image for the terminal's upgrade process, or transfer it to the image repository under the local area network where the terminal is located.

[0076] Furthermore, the method can be implemented through the Docker Swarm cluster tool.

[0077] In some embodiments, the target upgrade image is used for updating at least one application of the terminal, including:

[0078] The target upgrade image is a differential image or a full - volume image.

[0079] Drawing on the OTA upgrade technology, the method adopts two upgrade methods: differential and full - volume.

[0080] The differential upgrade method can use Docker to package specified parts of the application and its dependencies into lightweight and portable containers, achieving a consistent operating environment for the application.

[0081] The dependencies include dynamic libraries, executable files, soft links, etc. of the application.

[0082] This technology greatly simplifies the process of application deployment, migration, and expansion, enabling developers to focus more on the implementation of business logic without worrying about differences in the underlying environment.

[0083] The container image of the full - volume upgrade method can be that, compared with the differential upgrade method, its iteration includes all dependencies of the specified part of the application, and iterative upgrades are performed according to the upgrade requirements of the terminal.

[0084] Or, the full - volume upgrade method can use Docker to package the entire Linux system into a container image of the new version firmware.

[0085] These two upgrade methods are implemented through Docker. Therefore, the download of the target upgrade image can be carried out within the local local area network, excluding the interference of the wireless network environment, thereby improving the download efficiency and avoiding the situation of long download times.

[0086] When using the OTA method, a large number of terminal devices connecting to the server for upgrades simultaneously may bring greater pressure to the server.

[0087] The upgrade image is created by R & D personnel after writing a functional application on a certain terminal and encapsulating it into a container, and then one or more containers are packaged into an image and uploaded to a specified image repository for the terminal to pull at any time for upgrade processing.

[0088] The target upgrade image downloaded to the terminal is not necessarily the entire complete upgrade image. It may only be a part of the constructed upgrade image, only containing one or several application processes to generate an image, and one container is used to generate one application process.

[0089] The mirror upgrade on the terminal is to create a new container after unpacking the mirror and use it to replace the corresponding original container, and the upgrade process does not affect the system operation.

[0090] Further, in some embodiments, the method further includes:

[0091] Downloading an upgrade script corresponding to the target upgrade image from a server;

[0092] Running the target upgrade image in a local container, including:

[0093] Running the target upgrade image in the local container by running the upgrade script.

[0094] Based on the Docker upgrade method, the method can automatically implement the upgrade process by pushing a relatively standardized upgrade script from the server, reducing the difficulty of user operation and improving the upgrade efficiency at the same time.

[0095] Although the OTA method can also be automatically upgraded through an upgrade script, it has certain limitations. For example, most upgrade scripts need to be generated locally. For different terminal devices, different scripts need to be generated, and the control logic of the scripts needs to be independently borne. Moreover, the execution of the script requires the device to be rooted or run in the device's Recovery mode. And in the actual environment, additional error checking and logging may be required to ensure the stability and reliability of the upgrade process. None of these problems exist for the Docker method.

[0096] Moreover, due to the inapplicability of the upgrade script, various problems are likely to occur in the OTA upgrade process due to non-standard operations by operators. And since terminal devices usually need to interact with users, this will greatly affect the user experience, and the device security cannot be effectively guaranteed.

[0097] The Docker method can finely control each node of the upgrade process through the upgrade script and containerization, while the OTA method does not have containerized operations, and it is difficult to achieve this level of fineness even with scripts.

[0098] The upgrade script is a text used for performing some upgrade, maintenance and other deployment tasks, and a series of key information such as the addresses, Tags, dependencies, upgrade order, etc. of each container image to be downloaded need to be specified in it.

[0099] The upgrade script and the target upgrade image are used in a supporting manner for upgrade processing. Both are downloaded to a terminal to be upgraded simultaneously or at different times according to the upgrade requirements to perform the upgrade task.

[0100] In some embodiments, running the target upgrade image in a local container includes:

[0101] By executing the upgrade script, the upgrade images corresponding to multiple application programs are run in the local container in batches.

[0102] In the batch upgrade mode, the method can also automatically allocate upgrade time based on the upgrade script, avoiding the situation where the upgrade queue of terminals is too large at the same time, resulting in disorder of upgrade tasks.

[0103] This refers to the batch update of containers. If all application containers cannot be updated at one time, they can be updated in batches. Only a part of the application containers are updated each time, which can maintain the stability of the service.

[0104] The Docker upgrade method can upgrade different application containers in sequence. After unpacking the image, multiple containers inside it are upgraded one by one according to the order defined by the script. During the update process of the containers, the containers running other functions of the system do not need to interrupt their functions to prevent errors.

[0105] The upgrade order of the containers is very important. For example, some containers need to be upgraded simultaneously to maintain the normal operation of the system, and there are dependency relationships between the applications corresponding to some containers. The containers that play a fundamental role need to be upgraded first.

[0106] The operation of batch update can be automatically executed through the written Docker script.

[0107] Compared with OTA upgrade, the entire image file is directly upgraded. Whether it is a full package or an incremental package, it is a unified image with data of different application processes inside. The data of the image file needs to be directly updated to the Flash. Therefore, the allocation of upgrade time cannot be achieved, resulting in the inability to upgrade without interrupting the operation of other functions of the system.

[0108] In some embodiments, running the target upgrade image in the local container includes:

[0109] Verify that the application is successfully updated by executing the upgrade script;

[0110] Non-volatile store the upgrade image file corresponding to the application.

[0111] In some embodiments, after a failed upgrade and restart, after verifying that the current version does not match according to the upgrade script stored in the non-volatile Flash, the upgrade process is restarted.

[0112] The Docker upgrade method tends to upgrade a running container, avoiding the situation of directly writing the image to the Flash. In this way, even if the upgrade fails due to sudden power failure or unstable network, it will not directly cause the system to crash, and it itself does not depend on the wireless network, so the influence factors of unstable network are relatively small.

[0113] After the application container is updated, it can be verified through an upgrade script. After ensuring that it is normal and error-free, the data of the complete version can be written to the Flash during idle time to achieve the solidification and iteration of the version, which can reduce the situation of repeatedly erasing the Flash due to upgrade failures, thereby delaying the service life of the Flash.

[0114] Container replacement or restart: According to the specific application scenario, you can choose to stop the old container and start the new container, or smoothly transition through strategies such as blue-green deployment and rolling updates on the premise of keeping the service uninterrupted. For example, in a blue-green environment, when one environment (blue environment) is online, the other environment (green environment) can be upgraded. Once the upgrade is completed and tested without errors, the data can be switched to the upgraded environment (green environment), and the original environment (blue environment) can then be updated.

[0115] Health check and verification: After the new container is started, necessary health checks and function verifications are carried out to ensure that the updated application runs normally and meets expectations.

[0116] After an OTA upgrade fails, it is not easy to roll back to the previous version and requires manual intervention by the user. Moreover, the method of verifying whether the upgrade is successful is not as fine-grained as Docker. The judgment of the upgrade is basically just success or failure.

[0117] In some embodiments, Docker secrets are used to securely manage encryption keys.

[0118] Specifically, a key is created by the instruction echo "my-secret-key" | docker secret create my_secret_key-. The key is referenced in docker-compose.yml. In the application container that needs to be upgraded, the key can be accessed through the environment variable SECRET_KEY_PATH and used for encryption / decryption operations to ensure that during the upgrade of Docker or the application container, the management and use of the key are properly handled, so as to reduce the risk of possible data leakage during the upgrade process and ensure the security of the data.

[0119] The updated new firmware may be incompatible with the old software, resulting in device failures.

[0120] In some embodiments, before the upgrade, the docker commit command is used to create a snapshot of the current container so that it can be automatically rolled back to the previous version when problems occur during the upgrade.

[0121] Corresponding to the method S100, refer to Figure 2 , the present disclosure embodiment provides a remote upgrade method S200.

[0122] Specifically, the method S200 is applied to the server, and the method S200 includes:

[0123] S202, obtaining the new information of the target upgrade image in the image repository;

[0124] S204, generating an upgrade notification according to the new information and sending it to at least one terminal. The upgrade notification is used to enable the terminal to download the target upgrade image from the image repository. The target upgrade image is used for the update of at least one application on the terminal. The application is deployed on the terminal through containerization, and the target upgrade image runs in a container on the terminal to implement the update of the application corresponding to the target upgrade image on the terminal.

[0125] Embodiment Two

[0126] The embodiments of the present disclosure provide a remote upgrade device.

[0127] The device may include corresponding modules that execute each or several steps in the above first flowchart. Therefore, each step or several steps in the above flowchart may be executed by the corresponding modules, and the device may include one or more of these modules. The modules may be one or more hardware modules specifically configured to execute the corresponding steps, or implemented by a processor configured to execute the corresponding steps, or stored in a computer-readable medium for implementation by the processor, or implemented through a certain combination.

[0128] Specifically, as Figure 3 shown, the device 1000 includes:

[0129] An image download module 1002, configured to download a target upgrade image from an image repository in response to an upgrade notification from a server. The target upgrade image is used for the update of at least one application on the terminal. The application is deployed on the terminal through containerization. The upgrade notification is generated by the server based on the obtained new information of the target upgrade image in the image repository;

[0130] An image running module 1004, configured to run the target upgrade image in a local container to implement the update of the application corresponding to the target upgrade image.

[0131] The embodiments of the present disclosure provide a remote upgrade device.

[0132] The device may include corresponding modules that perform each or several steps in the above second flowchart. Therefore, each step or several steps in the above flowchart may be performed by corresponding modules, and the device may include one or more of these modules. The module may be one or more hardware modules specifically configured to perform the corresponding steps, or implemented by a processor configured to perform the corresponding steps, or stored in a computer-readable medium for implementation by a processor, or implemented through a certain combination.

[0133] Specifically, as Figure 4 shown, the device 2000 includes:

[0134] An information acquisition module 2002, configured to acquire the new information of the target upgrade image in the image repository;

[0135] A notification sending module 2004, configured to generate an upgrade notification according to the new information and send it to at least one terminal. The upgrade notification is used to enable the terminal to download the target upgrade image from the image repository. The target upgrade image is used for updating at least one application on the terminal. The application is deployed in a container on the terminal, and the target upgrade image runs in the container on the terminal to implement the update of the application corresponding to the target upgrade image on the terminal.

[0136] An embodiment of the present disclosure further provides an electronic device, including: a memory storing execution instructions; and a processor or other hardware module. The processor or other hardware module executes the execution instructions stored in the memory, so that the processor or other hardware module executes the above remote upgrade method.

[0137] The present disclosure also provides a readable storage medium storing execution instructions, which are used to implement the above remote upgrade method when executed by a processor.

[0138] Among them, the hardware structure adopted by the remote upgrade device implemented based on the hardware implementation mode using a processor can be implemented using a bus architecture. The bus architecture may include any number of interconnected buses and bridges, depending on the specific application of the hardware and the overall design constraints. The bus connects various circuits including one or more processors, memories, and / or hardware modules together. The bus may also connect various other circuits such as peripheral devices, voltage regulators, power management circuits, external antennas, etc.

[0139] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of representation, only one connecting line is used in this figure, but it does not mean that there is only one bus or one type of bus.

[0140] Any process or method description represented in the flowchart or described in other ways herein can be understood as representing a module, segment, or part of code including one or more executable instructions for implementing a specific logical function or process. And the scope of the preferred embodiments of the present disclosure includes additional implementations, where the functions can be executed in a substantially simultaneous manner or in the reverse order according to the involved functions, rather than in the order shown or discussed. This should be understood by those skilled in the technical field to which the embodiments of the present disclosure belong. The processor executes the various methods and processes described above. For example, the method embodiments in the present disclosure can be implemented as a software program, which is tangibly included in a machine-readable medium, such as a memory. In some embodiments, part or all of the software program can be loaded and / or installed via the memory and / or a communication interface. When the software program is loaded into the memory and executed by the processor, one or more steps of the methods described above can be executed. Alternatively, in other embodiments, the processor can be configured to execute one of the above methods by any other suitable means (such as by means of firmware).

[0141] The logic and / or steps represented in the flowchart or described in other ways herein can be specifically implemented in any readable storage medium for use by an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processor, or other systems that can fetch and execute instructions from the instruction execution system, apparatus, or device), or in combination with these instruction execution systems, apparatus, or devices.

[0142] As used in this specification, a "readable storage medium" can be any device that can contain, store, communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of the readable storage medium include the following: an electrical connection (electronic device) having one or more wirings, a portable computer diskette (magnetic device), a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber device, and a portable read-only memory (CDROM). Additionally, the readable storage medium can even be paper or other suitable medium on which a program can be printed, as the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpretation, or other appropriate processing as necessary, and then stored in a memory.

[0143] It should be understood that various parts of the present disclosure can be implemented by hardware, software, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented by software stored in a memory and executed by a suitable instruction execution system. For example, if implemented by hardware, as in another embodiment, any one or a combination of the following techniques well known in the art can be used: discrete logic circuits having logic gate circuits for implementing logical functions on data signals, application specific integrated circuits having appropriate combinational logic gate circuits, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

[0144] Those of ordinary skill in the art of this technology can understand that all or part of the steps for implementing the above-described embodiments of the method can be completed by a program instructing relevant hardware. The program can be stored in a readable storage medium, and when the program is executed, it includes one or a combination of the steps of the method embodiments.

[0145] Furthermore, in each of the various embodiments of the present disclosure, the functional units can be integrated in a processing module, or each unit can exist physically alone, or two or more units can be integrated in a module. The above-described integrated module can be implemented in the form of hardware or in the form of a software functional module. When the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a readable storage medium. The storage medium can be a read-only memory, a disk, or an optical disc, etc.

[0146] Those skilled in the art should understand that the above-described embodiments are merely for clearly illustrating the present disclosure and are not intended to limit the scope of the present disclosure. For those skilled in the art, other changes or variations can be made based on the above disclosure, and these changes or variations are still within the scope of the present disclosure.

Claims

1. A remote upgrade method, characterized in that: The method is applied to a terminal, and the method includes: In response to an upgrade notification from the server, download a target upgrade image from an image repository, wherein the target upgrade image is used to update at least one application of the terminal, and the application is deployed on the terminal through containerization; the upgrade notification is generated by the server based on newly added information of the target upgrade image in the image repository obtained; The target upgrade image is run in a local container to update the application corresponding to the target upgrade image.

2. The method according to claim 1, characterized in that The upgrade notification is generated by the server based on the acquired new information of the target upgrade image in the image repository, including: The server uses a scheduled task to regularly monitor the image repository, or the server uses an automated tool to monitor the image repository.

3. The method according to claim 1, characterized in that The target upgrade image is used for updating at least one application of the terminal, and includes: The target upgrade image is a differential image or a full image.

4. The method according to claim 1, characterized in that The target upgrade image is used for updating at least one application of the terminal, and includes: The target upgrade image is constructed by the server.

5. The method according to claim 1, characterized in that The method further comprises: Download the upgrade script corresponding to the target upgrade image from the server; Running the target upgrade image in the local container includes: By running the upgrade script, the target upgrade image is run in the local container.

6. The method according to claim 5, characterized in that Running the target upgrade image in the local container includes: By executing the upgrade script, the upgrade images corresponding to the multiple application programs are run in batches in the local container.

7. The method according to claim 5, characterized in that Running the target upgrade image in the local container includes: Verify that the application is successfully updated by executing the upgrade script; The upgrade image file corresponding to the application is stored in a non-volatile manner.

8. A remote upgrade method, characterized in that: The method is applied to the server, and the method includes: Obtaining new information of the target upgrade image in the image repository; An upgrade notification is generated based on the newly added information and sent to at least one terminal, the upgrade notification is used to enable the terminal to download a target upgrade image from an image repository, the target upgrade image is used to update at least one application of the terminal, the application is deployed on the terminal through containerization, and the target upgrade image runs in a container on the terminal to implement the update of the application corresponding to the target upgrade image on the terminal.

9. An electronic device, characterized in that: include: A memory storing execution instructions; as well as A processor, wherein the processor executes the execution instruction stored in the memory, so that the processor executes the method according to any one of claims 1 to 7 or the method according to claim 8.

10. A readable storage medium, characterized in that: The readable storage medium stores execution instructions, which are used to implement the method according to any one of claims 1 to 7 or the method according to claim 8 when executed by a processor.

Images