A method and related apparatus for deploying virtual machine applications
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-25
- Publication Date
- 2026-08-14
AI Technical Summary
该方式需要大量物理服务器和组件支持,维护代价高昂
[0019]本申请第五方面提供一种计算机程序产品,包括计算机可读指令,当所述计算机可读指令在电子设备上运行时,能够使所述电子设备实现上述第一方面所述的虚拟机应用发布方法。
Smart Images

Figure CN122570080A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of cloud computing technology, and in particular to a method and apparatus for publishing virtual machine applications. Background Technology
[0002] In the cloud computing field, the deployment and maintenance of virtual machine applications have long relied on traditional Infrastructure as a Service (IaaS) platforms such as OpenStack. Taking OpenStack as an example, operations personnel first build a virtual machine image, upload the image through the OpenStack image service, then call the compute service to create a virtual machine instance. After the instance starts, they use automated operation and maintenance tools such as Salt to operate the virtual machine instance, complete operations such as application code push and configuration updates, and finally manually or through scripts restart the application service. This approach requires the support of a large number of physical servers and components, resulting in high maintenance costs.
[0003] With the widespread adoption of Kubernetes, a container orchestration engine, the KubeVirt plugin has emerged. This platform leverages Kubernetes' resource management and scheduling capabilities to manage virtual machines, providing new possibilities for the deployment of virtual machine applications.
[0004] Therefore, how to achieve efficient virtual machine application deployment based on KubeVirt plugins has become a technical problem that urgently needs to be solved by those skilled in the art. Summary of the Invention
[0005] In view of the above problems, this application provides a virtual machine application deployment method and related apparatus to achieve efficient virtual machine application deployment tasks.
[0006] The specific plan is as follows:
[0007] The first aspect of this application provides a method for publishing virtual machine applications, including:
[0008] Obtain three pre-built container images, including: a system layer image, a startup logic layer image, and an application layer image; the system layer image is a container image containing the runtime environment required by the application to be released, the startup logic layer image includes application deployment and startup scripts corresponding to the application type of the application to be released, and the application layer image includes the application code of the application to be released.
[0009] Obtain a pre-configured virtual machine definition file, in which the virtual machine definition file references the identification information of the system layer image, the boot logic layer image, and the application layer image, and the virtual machine definition file declares each layer of container images in the form of independent virtual disk volumes;
[0010] Submit the virtual machine definition file to the Kubernetes cluster so that the Kubernetes cluster can execute the virtual machine instance creation and startup process corresponding to the virtual machine definition file through the KubeVirt plugin deployed on it.
[0011] A second aspect of this application provides a virtual machine application publishing apparatus, comprising:
[0012] The delivery object configuration unit is used to obtain three pre-built container images, which include: a system layer image, a startup logic layer image, and an application layer image; the system layer image is a container image containing the runtime environment required by the application to be released, the startup logic layer image includes application deployment and startup scripts corresponding to the application type of the application to be released, and the application layer image includes the application code of the application to be released.
[0013] The virtual machine resource configuration unit is used to obtain a pre-configured virtual machine definition file. The virtual machine definition file references the identification information of the system layer image, the boot logic layer image, and the application layer image, and the virtual machine definition file declares each layer of container images in the form of an independent virtual disk volume.
[0014] The delivery execution unit is used to submit the virtual machine definition file to the Kubernetes cluster so that the Kubernetes cluster can execute the virtual machine instance creation and startup process based on the virtual machine definition file.
[0015] A third aspect of this application provides a virtual machine application publishing device, comprising at least one processor and a memory connected to the processor, wherein:
[0016] The memory is used to store computer programs;
[0017] The processor is used to execute the computer program to implement the virtual machine application deployment method described in the first aspect above.
[0018] A fourth aspect of this application provides a storage medium carrying one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the virtual machine application publishing method described in the first aspect.
[0019] The fifth aspect of this application provides a computer program product including computer-readable instructions that, when executed on an electronic device, enable the electronic device to implement the virtual machine application publishing method described in the first aspect.
[0020] By employing the aforementioned technical solution, this application first obtains pre-built system-layer images, startup logic layer images, and application-layer images. Then, it obtains pre-configured virtual machine definition files, which reference the identification information of each layer's container images. Finally, it submits the virtual machine definition files to the Kubernetes cluster, enabling the Kubernetes cluster to execute the virtual machine instance creation and startup process corresponding to the virtual machine definition files through the KubeVirt plugin deployed on it. Since the three container images are independent, the system-layer image can be shared by various applications, and the startup logic layer image can be shared by one type of application. This allows for the reuse of previous system-layer and startup logic layer images when deploying virtual machine applications, meaning only a smaller application-layer image needs to be built, thereby improving application deployment efficiency. Furthermore, this application executes the virtual machine instance creation and startup process corresponding to the virtual machine definition files through the KubeVirt plugin deployed on the Kubernetes cluster, eliminating the need for manual intervention, reducing human costs, and ultimately achieving highly efficient virtual machine application deployment. Attached Figure Description
[0021] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:
[0022] Figure 1 A flowchart illustrating a virtual machine application publishing method provided in this application;
[0023] Figure 2 A schematic diagram of the structure of a virtual machine application publishing device provided in this application;
[0024] Figure 3 This is a schematic diagram of the structure of a virtual machine application publishing device provided in this application. Detailed Implementation
[0025] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is only for explaining specific embodiments and is not intended to limit the application. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.
[0026] The applicant's research revealed that current virtual machine application deployment solutions based on the KubeVirt platform typically use a single integrated image to host all the content required for running a virtual machine application. This image configuration method results in a very large image size required for application deployment (including initial deployment and subsequent updates). In other words, when a new virtual machine application needs to be deployed, a large, complete image needs to be configured; when an application version needs to be updated, the complete image corresponding to the new version needs to be reconstructed and redistributed. Therefore, the current deployment solution suffers from low deployment efficiency.
[0027] To address the aforementioned issues, this application provides a virtual machine application deployment method and related apparatus to achieve efficient virtual machine application deployment tasks.
[0028] Figure 1 This is a flowchart illustrating a virtual machine application deployment method according to an embodiment of this application. Combined with... Figure 1 As shown, the method may include the following steps:
[0029] Step S101: Obtain three pre-built container images.
[0030] The three container images include: a system layer image, a startup logic layer image, and an application layer image.
[0031] The applicant, by studying the functional responsibilities of all components required for the operation of virtual machine applications and considering the changing patterns of these components, divided all the components required for the operation of virtual machine applications into the operating system layer, the startup logic layer, and the application layer. Based on this, a three-layer container disk architecture was determined, namely, the three container images include: a system layer image, a startup logic layer image, and an application layer image. The three layers and their corresponding container images are described below.
[0032] The operating system layer (corresponding to the system layer image) provides the basic operating system environment and underlying runtime support required for virtual machine startup, and is responsible for implementing the virtual machine's boot process. Correspondingly, the system layer image is a container image containing the runtime environment required by the application to be released. Furthermore, the operating system layer typically does not change, has a low change frequency, and is considered a stable layer.
[0033] The startup logic layer (corresponding to its image) is used for deployment startup control. Specifically, it can include automatically executing application deployment, distribution, and service startup actions after operating system initialization, without manual intervention. Furthermore, different application types or deployment modes typically have different startup logic. Correspondingly, the startup logic layer image includes application deployment and startup scripts corresponding to the application type of the application to be released. The startup logic changes less frequently than application version changes. The startup logic layer image solves the problem of traditional solutions relying on the Salt module.
[0034] The application layer (corresponding to the application layer image) includes the business application itself and its related configuration content. Correspondingly, the application layer image includes the application code of the application to be released, and may also include related configuration files. Applications change most frequently and are the primary update target during continuous releases; therefore, the application layer can be called the high-frequency change layer. Furthermore, the application layer image is relatively small, providing a basis for reducing the storage, transmission, and retrieval time during application version updates.
[0035] Based on the foregoing, merging the operating system layer and the boot logic layer would require rebuilding the system layer image when the boot logic changes. Furthermore, the operating system layer and the boot logic layer have different boot sequences. Separating the operating system layer and the boot logic layer allows the operating system layer to remain stable and the boot logic to remain independent, providing a foundation for cross-application reuse. Conversely, merging the boot logic layer and the application layer would require rebuilding the boot logic layer when the application version changes. This application, by dividing all the content required for virtual machine application operation into three layers and constructing the aforementioned three-layer container disk architecture, can achieve both maximizing reusability and minimizing the scope of changes.
[0036] In addition, adopting the aforementioned three-tier architecture can avoid problems such as complex version management relationships, lengthy virtual machine declarative configurations, increased disk mount relationships and startup dependencies, and increased costs for fault location and compatibility verification caused by layer refinement and increased number of images.
[0037] It should be noted that to obtain the aforementioned division results, it is necessary to decouple the functions and responsibilities of different contents. Simply mechanically splitting the existing integrated image will not yield the three container images described in this application. A layered architecture allows for the independent construction and distribution of images at each layer, providing a foundation for independent versioning and on-demand combination of each layer's images.
[0038] Step S102: Obtain the pre-configured virtual machine definition file.
[0039] The virtual machine definition file references the identification information of the system layer image, the boot logic layer image, and the application layer image. This identification information includes a version identifier. Furthermore, the virtual machine definition file declares each layer of container images as an independent virtual disk volume, which is uniformly loaded and mounted by the virtual machine platform. The aforementioned virtual machine definition file can refer to a file that defines virtual machine resources using a declarative configuration method; it can also be called a declarative configuration file.
[0040] Step S103: Submit the virtual machine definition file to the Kubernetes cluster so that the Kubernetes cluster can execute the virtual machine instance creation and startup process corresponding to the virtual machine definition file through the KubeVirt plugin deployed on it.
[0041] For example, virtual machine definition files can be submitted to the Kubernetes cluster through the management tools of the Kubernetes container orchestration platform or the CI / CD system, so that Kubernetes can schedule, create and start virtual machine resources according to the definition files, thereby realizing the virtual machine deployment task.
[0042] The aforementioned virtual machine instance creation and startup process may include:
[0043] The first step is for the container orchestration platform to schedule virtual machine workloads to appropriate host nodes (Kubernetes Nodes).
[0044] The second step is for the host node to run the container Pod, which pulls three container images in parallel during runtime.
[0045] The third step is to run the QEMU virtualization process inside the container. The virtualization process mounts the three container images as independent virtual machine disks to the virtual machine, ultimately forming a three-layer structure of Node→Container→QEMU VM.
[0046] Step 4: The virtual machine boots from the disk corresponding to the system-level image;
[0047] Step 5: After the operating system initialization is complete, the deployment script in the boot logic layer image will be executed automatically;
[0048] Step 6: The deployment script mounts the disk corresponding to the application layer image, distributes the application code to the target directory, and triggers the application service to start.
[0049] Step 7: The application has started successfully and is now providing application services to external users.
[0050] This application first obtains pre-built system-layer images, startup logic layer images, and application-layer images. Then, it obtains pre-configured virtual machine definition files (VMs), which reference the identification information of each layer's container images. Finally, it submits the VM definition files to the Kubernetes cluster, enabling the Kubernetes cluster to execute the VM instance creation and startup process corresponding to the VM definition files through the KubeVirt plugin deployed on it. Because the three container images are independent, the system-layer image can be shared by various applications, and the startup logic layer image can be shared by one type of application. This allows for the reuse of previous system-layer and startup logic layer images when deploying virtual machine applications; that is, only a smaller application-layer image needs to be built, thereby improving application deployment efficiency. Furthermore, this application executes the VM instance creation and startup process corresponding to the VM definition files through the KubeVirt plugin deployed on the Kubernetes cluster, eliminating the need for manual intervention, reducing human costs, and ultimately achieving highly efficient virtual machine application deployment.
[0051] This application implements a cloud-native deployment method for virtual machine applications. This method uses layered images as the delivery object, declarative configuration as the deployment entry point, and the Kubernetes container orchestration platform as the execution entity for automated delivery. This enables virtual machine applications to complete version release and runtime management in a manner similar to container applications. Specifically, virtual machine workloads run on a containerized virtual machine platform, and the container orchestration platform uniformly handles scheduling, creation, startup, and management, allowing virtual machine applications to obtain orchestration and management capabilities consistent with container applications. By declaring the image identification information to be used in the virtual machine definition file, the process of image pulling, virtual disk mounting, virtual machine startup, and application deployment startup is automatically completed without manual intervention in the virtual machine to execute deployment commands, thereby achieving configuration change-driven automated delivery.
[0052] In one or more embodiments provided in this application, the system layer image, the startup logic layer image, and the application layer image are all ContainerDisk.
[0053] It should be noted that all three layers of content are essentially release artifacts, rather than runtime temporary states. For such content, among the various disk types supported by KubeVirt, compared to other disk types such as PVC, HostPath, and ConfigMap that focus on persistent storage, local node dependencies, or small-scale configuration injection, using ContainerDisk as the carrier can better meet the needs of virtual machine application releases in terms of pre-built, distributable, versionable, reusable, and consistent deployment across environments.
[0054] In addition, the applicant found through research that ContainerDisk can serve as a standardized delivery carrier that is directly compatible with the container image system, thereby meeting the image-based, declarative, and unified requirements of virtual machine application delivery methods. This can solve the problem of inconsistent deployment processes and container applications in traditional solutions, which require the maintenance of two sets of process systems.
[0055] By employing a three-tier ContainerDisk architecture, the system layer, startup logic layer, and application layer can be built, stored, and distributed using a unified container image format. Version management can be performed within a unified image repository. Specifically, each layer of images can use a unified build pipeline and a unified image identification method, referenced in the virtual machine's declarative configuration file using image identifiers. Furthermore, it ensures consistency between the overall deployment process and the container application deployment process. Using other types of disks / volumes could lead to situations where some content is distributed via the image repository, while other content is distributed via the storage system or configuration system, causing a fragmentation of the delivery chain and hindering the implementation of a unified cloud-native deployment model. In summary, adopting a three-tier ContainerDisk architecture helps build a unified delivery and management system, enhances environmental consistency, improves deployment efficiency, and increases the reusability and composition flexibility of images.
[0056] For a system-level image (also known as a system disk or OS disk), in one possible implementation, the process of building the system-level image may include:
[0057] The automated image building pipeline is invoked to build the system-level image containing the runtime environment required by the application to be released, based on a standard base operating system image.
[0058] The constructed system-level image can pre-install the runtime environment and basic components (such as monitoring components) required by the application to be released. This image can be reused long-term without changes to the basic environment, eliminating the need for repeated builds with business iterations. Furthermore, after the system-level image is built, it can be pushed to a unified container image repository in container image format. For example, the aforementioned automated image build pipeline could be a Packer pipeline, thereby ensuring the standardization and reusability of the base image.
[0059] For the boot logic layer image (also known as the boot disk or entrypoint disk), in one possible implementation, the application deployment and startup scripts can be used to achieve the following steps:
[0060] Perform an application-layer image mounting operation to the preset path;
[0061] Add the application code of the application to be published to the preset application runtime directory;
[0062] Configure permissions;
[0063] In addition, start the application service corresponding to the application to be released.
[0064] After writing or generating the scripts corresponding to the above steps, the scripts can be packaged into a container image and pushed to the container image repository. Furthermore, startup logic layer images can be standardized and consolidated according to application type to support cross-application reuse; startup logic layer images support custom shell scripts or other scripting languages, allowing for flexible writing of deployment startup logic based on different application needs. Through flexible startup logic configuration of startup logic layer images, multiple versions of Java / Tomcat and other application environments can be supported.
[0065] For application-layer images (also known as app disks), in one possible implementation, after developers complete application code development, the application code can be compiled and packaged using a continuous integration (CI / CD) pipeline to generate application artifacts (such as compiled binary files, bytecode packages, and configuration files). These artifacts are then packaged into a lightweight container image and pushed to a container image repository. By employing a multi-stage build approach, ensuring that the application-layer image contains only compiled application binary files or bytecode, the size of the application-layer image is reduced.
[0066] Container images at different layers are independent of each other and can be pushed to the container image repository separately. Based on this, different versions of the image can be referenced in the virtual machine resource file to achieve flexible image version combination and meet diverse application deployment needs.
[0067] In one or more embodiments provided in this application, the method may further include:
[0068] Step S104: In response to the new version release request of the application to be released, obtain the application layer image of the new version.
[0069] The new version of the application layer image includes the new version of the application code for the application to be released;
[0070] Step S105: Update the identification information of the application layer image referenced in the virtual machine definition file to the identification information of the new version of the application layer image.
[0071] Step S106: Resubmit the virtual machine definition file to the Kubernetes cluster so that the Kubernetes cluster can rebuild the virtual machine and load the new version of the application layer image.
[0072] This application is based on three-layer container image deployment and management of virtual machine applications. When an application needs to be updated, only the application layer image can be rebuilt, which greatly reduces the size of the image that needs to be changed and shortens the image transfer time. On this basis, by updating the reference in the virtual machine definition file, the application update is triggered and the deployment is automatically executed by the startup logic layer without manual intervention, SSH connection or additional Salt module.
[0073] The virtual machine application deployment scheme provided in this application will be illustrated below with examples. Assuming the application to be deployed is based on a Java configuration, the application deployment will proceed as follows:
[0074] The first step is to use the Packer pipeline to build the Alma Linux base image, pre-install JDK, basic monitoring components, etc., package the built system image into a container image, and push it to the container image repository. Assume the system layer image name is almalinux-9.2-x86_64-linux_tomcat:v7.20.1.
[0075] The second step is to obtain the deployment and startup scripts, package the scripts into a container image, and push it to the container image repository. Assume the startup logic layer image name is vm-entrypoint-java-tomcat:v1.0.1.
[0076] The deployment and startup logic can include logic such as:
[0077] #! / bin / bash
[0078] # Mount App Disk
[0079] mount / dev / vdc / mnt / app
[0080] # Deploy application code to the specified directory
[0081] cp -r / mnt / app / * / opt / myapp /
[0082] # Set permissions
[0083] chmod +x / opt / myapp / bin / startup.sh
[0084] # Launch the application
[0085] / opt / myapp / bin / startup.sh
[0086] The third step is to obtain the developed application code, compile and package the application through the CI / CD pipeline, obtain only the compiled JAR file and configuration file, package it into a container image, and push it to the container image repository. Assume the application layer image name is app-disk:myapp-v2.5.3.
[0087] Step 4: Obtain the pre-configured virtual machine definition file, such as the KubeVirt VirtualMachine YAML description file, which references the three-tier container image. For example, it can be represented as:
[0088] apiVersion: kubevirt.io / v1
[0089] kind: VirtualMachine
[0090] metadata:
[0091] name: myapp-vm
[0092] spec:
[0093] running: true
[0094] template:
[0095] spec:
[0096] domain:
[0097] devices:
[0098] disks:
[0099] - name: os-disk
[0100] disk:
[0101] bus: virtio
[0102] - name: entrypoint-disk
[0103] disk:
[0104] bus: virtio
[0105] - name: app-disk
[0106] disk:
[0107] bus: virtio
[0108] volumes:
[0109] - name: os-disk
[0110] containerDisk:
[0111] image: registry.example.com / almalinux-9.2-x86_64-linux_tomcat:v7.20.1
[0112] - name: entrypoint-disk
[0113] containerDisk:
[0114] image: registry.example.com / vm-entrypoint-java-tomcat:v1.0.1
[0115] - name: app-disk
[0116] containerDisk:
[0117] image: registry.example.com / app-disk:myapp-v2.5.3
[0118] Step 5: Apply the VM YAML file to the Kubernetes cluster using kubectl or a CI / CD system.
[0119] For example, it can be expressed as: kubectl apply -f myapp-vm.yaml.
[0120] Step 6: The Kubernetes cluster executes the following automated process:
[0121] Kubernetes schedules VM Pods to appropriate Node nodes;
[0122] The container runtime on Node pulls three ContainerDisk images;
[0123] KubeVirt starts a QEMU virtual machine and mounts the three images as / dev / vda, / dev / vdb, and / dev / vdc respectively.
[0124] After the virtual machine starts, the system boots from the OS Disk ( / dev / vda);
[0125] After the operating system initialization is complete, the deployment startup script in the Entrypoint Disk ( / dev / vdb) is executed automatically;
[0126] The script mounts the App Disk ( / dev / vdc) and deploys the application code to the / opt / myapp / directory;
[0127] The script starts the application and begins providing application services to external users.
[0128] Based on the above, if you need to release a new version v2.5.4, please follow these steps:
[0129] Step 7: Rebuild the application layer image (named app-disk:myapp-v2.5.4).
[0130] Step 8: Update the application layer image identification information in the VM YAML, specifically, update the image version information;
[0131] Step 9: Reapply the VM YAML file to the Kubernetes cluster, which can be represented as: `kubectl apply -fmyapp-vm.yaml`;
[0132] Step 10: Automatically restart the virtual machine (VM) and load the new version of the application.
[0133] During the release of a new application version, the system-level image and the startup logic layer image remain unchanged; only the application-level image is updated. This significantly reduces image pull time and does not require a large amount of storage space. Furthermore, by leveraging Kubernetes' declarative API, a cloud-native delivery model for virtual machine applications is implemented, improving release efficiency and automation without the need for additional components such as the Salt module.
[0134] The virtual machine application publishing apparatus provided in the embodiments of this application is described below. The virtual machine application publishing apparatus described below and the virtual machine application publishing method described above can be referred to in correspondence.
[0135] Figure 2 This is a schematic diagram of the structure of a virtual machine application publishing device disclosed in an embodiment of this application. Figure 2 As shown, the device may include:
[0136] The delivery object configuration unit 11 is used to obtain three pre-built container images, the three container images including: a system layer image, a startup logic layer image, and an application layer image; the system layer image is a container image containing the runtime environment required by the application to be released, the startup logic layer image includes application deployment and startup scripts corresponding to the application type of the application to be released, and the application layer image includes the application code of the application to be released.
[0137] The virtual machine resource configuration unit 12 is used to obtain a pre-configured virtual machine definition file. The virtual machine definition file references the identification information of the system layer image, the boot logic layer image and the application layer image, and the virtual machine definition file declares each layer of container images in the form of an independent virtual disk volume.
[0138] Delivery execution unit 13 is used to submit the virtual machine definition file to the Kubernetes cluster so that the Kubernetes cluster can execute the virtual machine instance creation and startup process according to the virtual machine definition file.
[0139] In one or more embodiments provided in this application, the delivery object configuration unit can also be used to obtain a new version application layer image in response to the new version release requirement of the application to be released, wherein the new version application layer image includes the new version application code of the application to be released;
[0140] The virtual machine resource configuration unit can also be used to update the identification information of the application layer image referenced by the virtual machine definition file to the identification information of the new version of the application layer image;
[0141] The delivery execution unit can also be used to resubmit the virtual machine definition file to the Kubernetes cluster, so that the Kubernetes cluster can rebuild the virtual machine and load the new version of the application layer image.
[0142] In one or more embodiments provided in this application, the process of the delivery object configuration unit 11 constructing the system layer image may include:
[0143] The automated image building pipeline is invoked to build the system-level image containing the runtime environment required by the application to be released, based on a standard base operating system image.
[0144] In one or more embodiments provided in this application, the application deployment and startup script is used to implement the following steps:
[0145] Perform an application-layer image mounting operation to the preset path;
[0146] Add the application code of the application to be published to the preset application runtime directory;
[0147] Configure permissions;
[0148] In addition, start the application service corresponding to the application to be released.
[0149] In one or more embodiments provided in this application, the system layer image, the startup logic layer image, and the application layer image are all ContainerDisk.
[0150] The virtual machine application publishing device provided in this application embodiment can be applied to virtual machine application publishing devices, such as terminals with data processing capabilities: mobile phones, computers, servers, etc. Optionally, Figure 3 The hardware structure block diagram of the virtual machine application deployment device is shown below. Figure 3 The hardware structure of a virtual machine application publishing device may include: at least one processor 1, at least one communication interface 2, at least one memory 3, and at least one communication bus 4;
[0151] In this embodiment of the application, the number of processor 1, communication interface 2, memory 3, and communication bus 4 is at least one, and processor 1, communication interface 2, and memory 3 communicate with each other through communication bus 4;
[0152] Processor 1 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention.
[0153] Memory 3 may include high-speed RAM, and may also include non-volatile memory, such as at least one disk storage device;
[0154] The memory is used to store computer programs, and the processor is used to execute the computer programs so that the virtual machine application publishing device can implement any of the above-described virtual machine application publishing methods.
[0155] This application also provides a storage medium that carries one or more computer programs. When the one or more computer programs are executed by an electronic device, the electronic device can implement any of the virtual machine application publishing methods provided in this application.
[0156] This application also provides a computer program product including computer-readable instructions, which, when executed on an electronic device, cause the electronic device to implement any of the virtual machine application publishing methods provided in this application.
[0157] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.
[0158] The various embodiments in this specification are described in a progressive manner. Each embodiment focuses on the differences from other embodiments. The various embodiments can be combined as needed, and the same or similar parts can be referred to each other.
[0159] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.
Claims
1. A method for deploying virtual machine applications, characterized in that, include: Obtain three pre-built container images, including: a system layer image, a startup logic layer image, and an application layer image; the system layer image is a container image containing the runtime environment required by the application to be released, the startup logic layer image includes application deployment and startup scripts corresponding to the application type of the application to be released, and the application layer image includes the application code of the application to be released. Obtain a pre-configured virtual machine definition file, in which the virtual machine definition file references the identification information of the system layer image, the boot logic layer image, and the application layer image, and the virtual machine definition file declares each layer of container images in the form of independent virtual disk volumes; Submit the virtual machine definition file to the Kubernetes cluster so that the Kubernetes cluster can execute the virtual machine instance creation and startup process corresponding to the virtual machine definition file through the KubeVirt plugin deployed on it.
2. The virtual machine application deployment method according to claim 1, characterized in that, The method also includes: In response to the new version release requirement of the application to be released, a new version application layer image is obtained, the new version application layer image including the new version application code of the application to be released; Update the identification information of the application layer image referenced in the virtual machine definition file to the identification information of the new version of the application layer image; Resubmit the virtual machine definition file to the Kubernetes cluster so that the Kubernetes cluster can rebuild the virtual machine and load the new version of the application layer image.
3. The virtual machine application deployment method according to any one of claims 1-2, characterized in that, The process of building the system layer image includes: The automated image building pipeline is invoked to build the system-level image containing the runtime environment required by the application to be released, based on a standard base operating system image.
4. The virtual machine application deployment method according to any one of claims 1-2, characterized in that, The application deployment and startup script is used to implement the following steps: Perform an application-layer image mounting operation to the preset path; Add the application code of the application to be published to the preset application runtime directory; Configure permissions; In addition, start the application service corresponding to the application to be released.
5. The virtual machine application deployment method according to any one of claims 1-2, characterized in that, The system layer image, the startup logic layer image, and the application layer image are all ContainerDisk.
6. A virtual machine application deployment device, characterized in that, include: The delivery object configuration unit is used to obtain three pre-built container images, which include: a system layer image, a startup logic layer image, and an application layer image; the system layer image is a container image containing the runtime environment required by the application to be released, the startup logic layer image includes application deployment and startup scripts corresponding to the application type of the application to be released, and the application layer image includes the application code of the application to be released. The virtual machine resource configuration unit is used to obtain a pre-configured virtual machine definition file. The virtual machine definition file references the identification information of the system layer image, the boot logic layer image, and the application layer image, and the virtual machine definition file declares each layer of container images in the form of an independent virtual disk volume. The delivery execution unit is used to submit the virtual machine definition file to the Kubernetes cluster so that the Kubernetes cluster can execute the virtual machine instance creation and startup process based on the virtual machine definition file.
7. The virtual machine application publishing device according to claim 6, characterized in that, The delivery object configuration unit is also used to obtain a new version application layer image in response to the new version release request of the application to be released, wherein the new version application layer image includes the new version application code of the application to be released; The virtual machine resource configuration unit is also used to update the identification information of the application layer image referenced by the virtual machine definition file to the identification information of the new version of the application layer image; The delivery execution unit is also used to resubmit the virtual machine definition file to the Kubernetes cluster so that the Kubernetes cluster can rebuild the virtual machine and load the new version of the application layer image.
8. A virtual machine application deployment device, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program so that the virtual machine application publishing device can implement the virtual machine application publishing method as described in any one of claims 1 to 5.
9. A storage medium, characterized in that, The storage medium carries one or more computer programs, which, when executed by an electronic device, enable the electronic device to implement the virtual machine application publishing method as described in any one of claims 1 to 5.
10. A computer program product, characterized in that, It includes computer-readable instructions that, when executed on an electronic device, enable the electronic device to implement the virtual machine application deployment method as described in any one of claims 1 to 5.