Application program deployment and management method and device, electronic equipment and storage medium

Abstract

The invention discloses an application program deployment and management method and device, electronic equipment and a storage medium, and the method comprises the steps: responding to a container construction command, and constructing a container mirror image of an application program according to a mirror image construction file; in response to the resource creation command, creating a resource object in the Kubernetes cluster according to the Kubernetes list file, the resource object being used for configuring a use mode of the container mirror image; and deploying and managing the container mirror image based on the resource object. By the adoption of the scheme, efficient application program deployment and management can be achieved when large projects and complex applications are processed.

Description

Technical Field

[0001] This application relates to the field of software deployment technology, and more particularly to a method, apparatus, electronic device, and storage medium for deploying and managing applications. Background Technology

[0002] Traditional front-end project deployment requires manually copying static files such as HTML, CSS, and JavaScript to a web server, and then configuring load balancing and scaling nodes. This process has a low degree of automation and is quite cumbersome in terms of deployment and management.

[0003] To achieve automated deployment, Docker Swarm clusters are commonly used to package front-end projects into Docker container images and orchestrate and manage them through Docker Swarm. However, Docker Swarm has a relatively small ecosystem and limited functionality, resulting in inefficient application deployment and management when handling large projects and complex applications. Summary of the Invention

[0004] This application provides a method, apparatus, electronic device, and computer storage medium for deploying and managing applications, which enables efficient application deployment and management when dealing with large projects and complex applications.

[0005] In a first aspect, embodiments of this application provide a method for deploying and managing an application, the method comprising:

[0006] In response to container build commands, build a container image of the application based on the image build file;

[0007] In response to the resource creation command, a resource object is created in the Kubernetes cluster based on the Kubernetes manifest file. The resource object is used to configure how the container image is used.

[0008] Container images are deployed and managed based on resource objects.

[0009] In one possible implementation, in response to a container build command, a container image of the application is built from the image build file, including:

[0010] In response to the container build command, obtain the image build file, which includes the base image, application dependencies, and application static resource files;

[0011] Container images for applications are built based on image build files.

[0012] In one possible implementation, the container image of the application is built based on the image build file, including:

[0013] Determine the base layer of the container image based on the base image;

[0014] Based on dependencies, static resource files, and pre-defined configuration files, multiple container layers are overlaid on top of the base layer;

[0015] Container images are built based on a base layer and multiple container layers.

[0016] In one possible implementation, before creating the resource object in the Kubernetes cluster according to the Kubernetes manifest file in response to the resource creation command, the method further includes:

[0017] In response to the image push command, the container image is pushed to a remote image repository for storage.

[0018] In one possible implementation, in response to a resource creation command, a resource object is created in the Kubernetes cluster based on the Kubernetes manifest file, including:

[0019] In response to a resource creation command, retrieve the deployment manifest file and service manifest file from the Kubernetes manifest files;

[0020] Deployment resource objects are created based on the deployment manifest file. These deployment resource objects are used to provide configuration information for how the container image runs.

[0021] Service resource objects are created based on the service manifest file. These service resource objects are used to provide configuration information for how container images are exposed.

[0022] In one possible implementation, container images are deployed and managed based on resource objects, including:

[0023] Based on the deployment resource object, the container image is deployed to generate an instantiated container image;

[0024] Based on service resource objects, manage the instantiated container images.

[0025] In one possible implementation, the runtime configuration information includes instantiation configuration information;

[0026] Based on the deployment resource object, the container image is deployed to generate an instantiated container image, including:

[0027] Based on the instantiation configuration information provided by the deployment resource object, the container image is instantiated to generate the instantiated container image.

[0028] In one possible implementation, the exposure configuration information includes port mapping configuration information and service exposure configuration information;

[0029] Based on service resource objects, manage the instantiated container images, including:

[0030] Based on the port mapping configuration information provided by the service resource object, access management is performed on the instantiated container image.

[0031] Based on the service exposure configuration information provided by the service resource object, service management is performed on the instantiated container image.

[0032] In one possible implementation, access management of the instantiated container image is performed based on the port mapping configuration information provided by the service resource object, including:

[0033] Based on the port mapping configuration information provided by the service resource object, a network service mechanism is used to manage access to the instantiated container image.

[0034] In one possible implementation, service management is performed on the instantiated container image based on the service exposure configuration information provided by the service resource object, including:

[0035] Based on the service exposure configuration information provided by the service resource object, a service discovery mechanism and a load balancing mechanism are used to manage the services of the instantiated container image.

[0036] Secondly, embodiments of this application provide an application deployment apparatus, the apparatus comprising:

[0037] The first response module is used to respond to container build commands and build the container image of the application based on the image build file;

[0038] The second response module is used to respond to resource creation commands and create resource objects in the Kubernetes cluster according to the Kubernetes manifest file. The resource objects are used to configure how container images are used.

[0039] The deployment management module is used to deploy and manage container images based on resource objects.

[0040] Thirdly, embodiments of this application provide an electronic device, including: a processor and a memory; wherein the memory stores a computer program, the computer program being adapted to be loaded by the processor and execute the method steps provided in the first or second aspect of embodiments of this application.

[0041] Fourthly, embodiments of this application provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the method steps provided in the first or second aspect of embodiments of this application.

[0042] The aforementioned application deployment and management methods, devices, electronic equipment, and computer storage media, in response to container build commands, construct application container images based on image build files; in response to resource creation commands, create resource objects in the Kubernetes cluster based on Kubernetes manifest files. These resource objects are used to configure the usage of the container images; and based on these resource objects, the container images are deployed and managed. The entire application deployment and management process, by responding to container build commands and resource creation commands, automates the construction of application container images and the creation of Kubernetes resource objects, simplifying the deployment and management process and reducing the complexity and possibility of errors associated with manual deployment and management. Containerizing the application using image build files ensures consistent behavior across different environments, such as development and production, guaranteeing application portability. Creating resource objects in the Kubernetes cluster using Kubernetes manifest files allows for flexible configuration of container image usage. Deploying and managing container images based on resource objects created in Kubernetes leverages the rich ecosystem and powerful container orchestration and management capabilities of the Kubernetes cluster to improve deployment and management efficiency for large projects and complex applications. This solution enables efficient application deployment and management for large projects and complex applications. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0044] Figure 1 A schematic diagram of an application environment for an exemplary embodiment of this application, illustrating a method for deploying and managing an application.

[0045] Figure 2 A flowchart illustrating an application deployment and management method provided for an exemplary embodiment of this application;

[0046] Figure 3 A flowchart illustrating another method for deploying and managing an application provided as an exemplary embodiment of this application;

[0047] Figure 4 A flowchart illustrating another method for deploying and managing an application provided as an exemplary embodiment of this application;

[0048] Figure 5 A schematic diagram of the structure of an application deployment and management apparatus provided for an exemplary embodiment of this application;

[0049] Figure 6 This is a schematic diagram of the structure of an electronic device provided as an exemplary embodiment of this application. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0051] In the description of this application, it should be understood that the terms "first," "second," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances. Furthermore, in the description of this application, unless otherwise stated, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0052] The application deployment and management method provided in this application embodiment can be applied to, for example, Figure 1 The application environment shown is illustrated. Terminal 10 communicates with server 20 via a network. A data storage system can store the data that server 20 needs to process. The data storage system can be integrated onto server 20 or located in the cloud or on other network servers. Server 20 responds to container build commands by building container images of the application based on image build files; responds to resource creation commands by creating resource objects in the Kubernetes cluster based on the Kubernetes manifest file. These resource objects are used to configure how the container images are used; and deploy and manage the container images based on the resource objects. Terminal 10 can be, but is not limited to, various personal computers, laptops, and tablets. Server 20 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0053] In one embodiment, such as Figure 2 As shown, a method for deploying and managing an application is provided, which can be applied to... Figure 1Taking server 20 as an example, the following steps are included:

[0054] S201: In response to a container build command, build a container image of the application based on the image build file.

[0055] Optionally, a container image of the front-end application is built based on the open-source platform Docker. Developers predefine the containerization specifications for the front-end application, which include, but are not limited to, a base image (such as Node.js), dependencies of the front-end application (such as package management tools npm, yarn, etc.), and front-end resource files (such as HTML files, CSS files, JavaScript files, etc.). Then, a Dockerfile is created based on the containerization specifications, and the `docker build` command is issued via the Docker CLI (Command Line Interface) installed on the terminal. The server 20 responds to the `docker build` command, building the container image of the application according to the Dockerfile.

[0056] Specifically, in the Dockerfile created based on the containerization specifications described above, Nginx can be used as a static file server. By declaring an exposed port (such as port 80) and copying the Nginx configuration file to the container image, Nginx can listen on the declared exposed port when the container starts and handle various HTTP (Hypertext Transfer Protocol) requests according to the rules in the Nginx configuration file. The rules in the Nginx configuration file include, but are not limited to, rules for compressing resource files, caching control rules, and error page handling rules. Resource file compression rules can, but are not limited to, using Nginx's gzip module to enable compression; caching control rules can, but are not limited to, controlling browser caching by setting the expiration time (expires) of static resource files; and error page handling rules include, but are not limited to, using the `error_page` directive to specify a custom error page to return when a specific error status code is displayed.

[0057] For example, in the Dockerfile, the FROM instruction specifies Node.js as the base image, the WORKDIR instruction sets the working directory, the COPY instruction copies the configuration file that manages project dependencies to the working directory, the RUN npm config instruction sets the image address, the RUN npm install instruction installs the dependencies of the front-end application, the COPY instruction copies the application source code and other front-end resource files to the container, the RUN npmrun build instruction builds the front-end resource files, the COPY instruction copies the custom Nginx configuration file to the container, the COPY instruction copies the built front-end resource files to the Nginx directory, the EXPOSE instruction declares the exposed ports, and the CMD instruction starts Nginx. Server 20 responds to the docker build command issued by the terminal and builds the container image of the application according to the above Dockerfile.

[0058] In this embodiment, the server responds to the container build command and packages the front-end application into a container image based on the image build file, ensuring the portability of the application and providing a foundation for the efficient deployment and management of containerized applications through the Kubernetes cluster, thereby improving the efficiency of application deployment and management.

[0059] S202: In response to the resource creation command, a resource object is created in the Kubernetes cluster based on the Kubernetes manifest file. The resource object is used to configure how the container image is used.

[0060] Understandably, Kubernetes manifest files are typically written in .yaml or .yml format and are used to describe how to create various Kubernetes resource objects to configure how container images are used.

[0061] Optionally, in response to the kubectl command, server 20 creates a Deployment resource object in the Kubernetes cluster based on the deployment manifest file in the Kubernetes manifest file, and creates a Service resource object in the Kubernetes cluster based on the service manifest file in the Kubernetes manifest file. Both the Deployment and Service resource objects are used to configure how the container image is used. Specifically, the Deployment resource object provides configuration information for the container image's runtime mode, i.e., configuring the container image's start, stop, update, scale, and rollback modes; the Service resource object provides configuration information for the container image's exposure mode, i.e., configuring the container image's service type, port mapping, and other exposure methods.

[0062] In this embodiment, the server responds to the resource creation command and creates a resource object in the Kubernetes cluster according to the Kubernetes manifest file. This allows for flexible configuration of the container image usage, improving the efficiency of subsequent application deployment and management.

[0063] S203: Deploy and manage container images based on resource objects.

[0064] Optionally, after the server 20 creates a resource object in the Kubernetes cluster based on the Kubernetes manifest file, it deploys the container image based on the deployment resource object to generate an instantiated container image, and then manages the instantiated container image (i.e., the running container instance) based on the service resource object.

[0065] In this embodiment, container images are deployed and managed based on resource objects created in Kubernetes. This leverages the rich ecosystem and powerful container orchestration and management capabilities provided by the Kubernetes cluster to improve deployment and management efficiency when handling large projects and complex applications.

[0066] The aforementioned application deployment and management methods automate the construction of application container images and the creation of Kubernetes resource objects by responding to container build commands and resource creation commands. This simplifies the deployment and management process, reducing the complexity and error potential of manual deployment and management. Containerizing the application using image build files ensures consistent application behavior across different environments, including development and production, guaranteeing application portability. Creating resource objects in the Kubernetes cluster using Kubernetes manifest files allows for flexible configuration of container image usage. Deploying and managing container images based on resource objects created in Kubernetes leverages the rich ecosystem and powerful container orchestration and management capabilities of the Kubernetes cluster, improving deployment and management efficiency for large projects and complex applications. This approach enables efficient application deployment and management for large projects and complex applications.

[0067] In one embodiment, such as Figure 3 As shown, another method for deploying and managing applications is provided, which can be applied to... Figure 1 Taking server 20 as an example, the following steps are included:

[0068] S301: In response to a container build command, obtain the image build file, which includes the base image, application dependencies, and application static resource files.

[0069] Optionally, server 20 responds to the container build command docker build to obtain the image build file Dockerfile created based on the application's containerization specifications, which includes information such as the base image, dependencies, and front-end resource files.

[0070] Specifically, the base image mentioned above can be, but is not limited to, Node.js, Nginx, Tomcat, etc., depending on the project's needs. If the front-end application is built using a modern JavaScript framework like React or Vue, and the build process relies on a Node.js environment (e.g., using Webpack for bundling), then using Node.js as the base image is a good choice. If the front-end application has already been built into static resources such as HTML, CSS, and JavaScript, and only a lightweight HTTP server is needed to serve these static resource files, then Nginx can be used as the base image to efficiently handle static resource content. If the project includes front-end and back-end integration, then Tomcat can be considered as the base image. This example illustrates the deployment and management of a front-end application, using Node.js, which handles the front-end application, as the base image.

[0071] The aforementioned dependencies may include front-end build tools such as Webpack, Gulp, or Grunt, as well as package management tools such as npm or yarn for managing JavaScript libraries and frameworks. These tools can help the server handle tasks such as code optimization and resource compression, thereby optimizing project build performance.

[0072] The aforementioned front-end resource files typically include HTML files, CSS files, JavaScript files, etc., and may also include other resource files such as image (Img / SVG) resource files, font icon (Iconfont) resource files, etc. These files are the core components of the front-end application. By copying them into the container through Dockerfile, it can be ensured that the application can run normally in different environments such as development and testing.

[0073] For example, in a Dockerfile, the `FROM` instruction specifies Node.js as the base image, the `WORKDIR` instruction sets the working directory, the `COPY` instruction copies the configuration file managing project dependencies to the working directory, the `RUN npm config` instruction sets the image address, the `RUN npm install` instruction installs the front-end application's dependencies, the `COPY` instruction copies the application's source code and other front-end resource files to the container, the `RUN npm run build` instruction builds the front-end resource files, the `COPY` instruction copies the custom Nginx configuration file to the container, the `COPY` instruction copies the built front-end resource files to the Nginx directory, the `EXPOSE` instruction declares the exposed port, and the `CMD` instruction starts Nginx. Understandably, in the Dockerfile created based on containerization specifications, Nginx is used as a static file server. By declaring an exposed port and copying the Nginx configuration file to the container image, Nginx can listen on the declared exposed port when the container starts and handle various HTTP requests according to the rules in the Nginx configuration file.

[0074] S302: Build container images of applications based on image build files.

[0075] Understandably, in Docker, an image consists of a series of read-only layers, which can be viewed as incremental changes to the file system. Server 20 builds container images of applications based on image build files, that is, by layering the instructions in the image build files.

[0076] In one embodiment, server 20 builds a container image of an application based on an image build file, including: determining the base layer of the container image based on the base image in the image build file; overlaying multiple container layers on top of the base layer based on the dependencies, static resource files, and preset configuration files (such as the Nginx configuration file mentioned above) in the image build file; and building the container image based on the base layer and the multiple container layers.

[0077] The base layer is typically an image containing the basic components of the operating system, providing the minimum environment required to run applications. Stacking multiple container layers on top of the base layer involves making layer-by-layer changes to the file system, such as adding, modifying, or deleting files.

[0078] In this embodiment, the application's container image is built in a layered manner to enable efficient deployment and management of the container image on the Kubernetes cluster, while ensuring the container image's lightweight nature and maintainability.

[0079] S303: In response to the image push command, push the container image to a remote image repository for storage.

[0080] Understandably, to facilitate the subsequent distribution and deployment of container images, after the container image is built, it is pushed to a remote image repository (such as Docker Hub) for storage.

[0081] Specifically, before pushing the container image, server 20 responds to the repository login command `docker login` to log in to the remote image repository; then responds to the image tag command `docker tag` to tag the container image to specify the name of the container image and which remote image repository the container image should be pushed to; finally responds to the image push command `docker push` to push the container image to the corresponding remote image repository for storage based on the container image's tag.

[0082] It is worth noting that after a container image is stored in a remote image repository, you can either use the Docker CLI to issue the `docker pull` command to pull a specific container image from the specified remote image repository, or you can use the kubelet service in the Kubernetes cluster to pull the image from the specified remote image repository. You can then use the `kubectl getpods` command to check the status of the Pod (container group) to confirm whether the image was successfully pulled.

[0083] In this embodiment, by pushing the container image to a remote image repository, it is convenient to deploy the same application version in multiple different environments (such as production, development, and testing) in the future. This simplifies the deployment and management process while improving the consistency, security, and maintainability of the application.

[0084] S304: In response to a resource creation command, retrieve the deployment manifest file and service manifest file from the Kubernetes manifest file.

[0085] Optionally, in response to the resource creation command kubectl, server 20 obtains the Deployment manifest file from the Kubernetes manifest file based on kubectl apply-ffrontend-deployment.yaml, and obtains the Service manifest file from the Kubernetes manifest file based on kubectl apply-f frontend-service.yaml.

[0086] Specifically, the Deployment manifest file defines how to run and manage container images. For example, in the Deployment manifest file, the `replicas` subfield under the `spec` field specifies the number of replicas of the running Pod. The `selector` subfield under the `spec` field specifies which Pods belong to the Deployment resource object. The `metadata` subfield under the `spec.template` field defines the Pod's metadata, including the container group's tag. The `volumes` subfield under the `spec.template.spec` field defines the Pod's volume configuration. The `name` subfield under the `spec.template.spec.containers` field defines the Pod's container name. The `image` subfield under the `spec.template.spec.containers` field defines the image used by the container. The `limits` subfield under the `spec.template.spec.containers.resources` field defines the container's maximum resource limits. The `requests` subfield under the `spec.template.spec.containers.resources` field defines the container's resource requests.

[0087] The Service manifest file defines how instantiated container images are exposed. For example, the `spec.selector` field in the Service manifest file defines labels for matching Pods. The Service resource object then selects which Pods should receive traffic routed through the Service based on these labels. The `spec.ports` field defines the port configuration exposed by the Service resource object. Specifically, the `protocol` subfield under `spec.ports` specifies that the protocol type accepted by the Service resource object is TCP (Transmission Control Protocol), the `port` subfield under `spec.ports` specifies that the port number exposed by the Service resource object is 80, and the `targetPort` subfield under `spec.ports` specifies that the port number of the container in the Pod is 80, thus mapping the container's port 80 to the Service resource object's port 80. The `spec.type` field specifies that the Service resource object is of type LoadBalancer.

[0088] S305: Create a deployment resource object based on the deployment manifest file. The deployment resource object is used to provide configuration information for how the container image runs.

[0089] Optionally, server 20 creates a Deployment resource object based on the Deployment manifest file. The Deployment resource object is used to provide runtime configuration information such as the instantiation method configuration information of the container image, as well as management configuration information such as update policy configuration information and health check configuration information.

[0090] The instantiation method configuration information defines how to instantiate the container image. Specifically, it can include specifying the container image name and its version tag, the maximum resource limit of the container instance, and the resource requests for the container instance. The update strategy configuration information defines how to update the container image in deployment. Specific strategies include rolling updates and in-place updates. Rolling updates involve gradually replacing Pods to ensure application availability, while in-place updates directly update existing Pods, which may cause temporary application interruptions. The health check configuration information defines how to check the health status of containers to ensure they are running normally. Specific options include a liveness probe for periodically checking if containers are alive, a readiness probe for checking if containers are ready to receive traffic, and a startup probe for checking if containers have started successfully at the beginning of startup.

[0091] S306: Create service resource objects based on the service manifest file. Service resource objects are used to provide configuration information on how container images are exposed.

[0092] Optionally, server 20 creates a Service resource object based on the Service manifest file. The Service resource object provides port mapping configuration information, service exposure configuration information, and other exposure method configuration information for the container image. The port mapping configuration information includes, but is not limited to, service port configuration information for receiving external traffic, target port configuration information for receiving forwarded traffic, and node port configuration information that allows access from outside the cluster. The service exposure configuration information includes, but is not limited to, service type configuration information (such as LoadBalancer type) for defining which Pods should receive traffic from the Service resource object, and container group selection configuration information for defining how the Service resource object distributes traffic among multiple Pods.

[0093] It is worth noting that this embodiment only describes a preferred implementation of this application. Kubernetes manifest files can include not only Deployment and Service manifest files, but also other manifest files such as Pod manifest files (container group manifest files), ConfigMap manifest files (configuration mapping manifest files), and Ingresses manifest files (access point manifest files). Accordingly, server 20 can create resource objects other than Deployment and Service resource objects based on other manifest files. This embodiment of the application does not limit the specific content included in the Kubernetes manifest file, nor the types of resource objects created by the server based on the Kubernetes manifest file.

[0094] S307: Deploy container images based on deployment resource objects to generate instantiated container images.

[0095] Optionally, server 20 instantiates the container image based on the instantiation method configuration information provided by the Deployment resource object to generate an instantiated container image. The instantiation method configuration information mentioned above includes, but is not limited to, container image configuration information, replica count configuration information, port mapping configuration information, and resource limit configuration information.

[0096] S308: Manage instantiated container images based on service resource objects.

[0097] Optionally, server 20 manages access to the instantiated container image based on the port mapping configuration information provided by the Service resource object; and manages services for the instantiated container image based on the service exposure configuration information provided by the Service resource object.

[0098] For example, this embodiment uses a Service resource object of type LoadBalancer to manage the instantiated container image (i.e., the running container instance). The Service resource object selects a Pod with the tag app=frontend as the backend, defines the port exposed by the service as port 80, and the actual listening port of the container in the Pod (i.e., the target port of the container) as port 80. By mapping the container's port 80 to the service's port 80, service management is performed on the instantiated container image.

[0099] The aforementioned application deployment and management methods improve application portability by responding to container build commands to obtain image build files and then building container images of the application based on these files. This lays the foundation for subsequent automated deployment and management based on Kubernetes clusters. By responding to image push commands and pushing container images to a remote image repository for storage, it's easy to deploy the same application version in different environments, improving application consistency, security, and maintainability. By responding to resource creation commands and obtaining deployment and service manifest files from the Kubernetes manifest, deployment resource objects are created based on the deployment manifest files, and service resource objects are created based on the service manifest files, achieving automated deployment and configuration and reducing the possibility of errors from manual configuration. Based on deployment resource objects, container images are deployed to generate instantiated container images; based on service resource objects, instantiated container images are managed. Leveraging the deployment and service resource objects provided by the Kubernetes cluster, efficient and automated deployment and management are achieved, effectively improving deployment and management efficiency for large projects and complex applications.

[0100] In one embodiment, such as Figure 4 As shown, another method for deploying and managing applications is provided, which can be applied to... Figure 1 Taking server 20 as an example, the following steps are included:

[0101] S401: In response to a container build command, retrieve the image build file, which includes the base image, application dependencies, and application static resource files.

[0102] Specifically, S401 is the same as S301, and will not be repeated here.

[0103] S402: Build container images of applications based on image build files.

[0104] Specifically, S402 is the same as S302, and will not be repeated here.

[0105] S403: In response to the image push command, push the container image to a remote image repository for storage.

[0106] Specifically, S403 is the same as S303, and will not be repeated here.

[0107] S404: In response to a resource creation command, retrieve the deployment manifest file and service manifest file from the manifest file.

[0108] Specifically, S404 is the same as S304, and will not be repeated here.

[0109] S405: Create a deployment resource object based on the deployment manifest file. The deployment resource object is used to provide configuration information for how the container image runs.

[0110] The runtime configuration information includes the instantiation configuration information.

[0111] Specifically, S405 is the same as S305, which will not be repeated here.

[0112] S406: Create service resource objects based on the service manifest file. Service resource objects are used to provide configuration information on how container images are exposed.

[0113] The exposure configuration information includes port mapping configuration information and service exposure configuration information.

[0114] Specifically, S406 is the same as S306, which will not be repeated here.

[0115] S407: Instantiate the container image based on the instantiation method configuration information provided by the deployment resource object to generate the instantiated container image.

[0116] Optionally, server 20 instantiates the container image into a group of Pods based on the instantiation configuration information provided by the Deployment resource object, such as container image configuration information, replication quantity configuration information, port mapping configuration information, and resource limit configuration information.

[0117] The container image configuration information specifies the Docker image to be used by each container in the Pod. The replication count configuration information defines the number of running Pod instances, ensuring that even if some Pods fail or are destroyed, a predetermined number of Pods will remain running. The port mapping configuration information defines the mapping relationship between ports inside the container and external services, allowing external traffic to reach the services within the container. The resource limit configuration information defines the maximum resource limits, such as CPU and memory, that each Pod can use, as well as the resource requests of the containers within each Pod.

[0118] S408: Based on the port mapping configuration information provided by the service resource object, manage access to the instantiated container image.

[0119] Optionally, server 20 manages access to the instantiated container image based on port mapping configuration information provided by the Service resource object, such as service port configuration information for receiving external traffic, target port configuration information for receiving forwarded traffic, and node port configuration information that allows access from outside the cluster.

[0120] In one embodiment, access management of the instantiated container image is performed based on the port mapping configuration information provided by the service resource object, including: using a network service mechanism to manage access to the instantiated container image based on the port mapping configuration information provided by the service resource object.

[0121] Understandably, since the port mapping configuration information provided by the Service resource object defines in Kubernetes how to map the ports of a service (i.e., a group of Pods) to ports inside or outside the cluster, after a container image is instantiated (i.e., a container is created), server 20 can use the network service mechanism based on the port mapping configuration information to access and manage the instantiated container image, thereby enabling communication and collaboration between the front-end application and other containerized applications. For example, the front-end application can access other services within the Kubernetes cluster through the IP (Internet Protocol) address or the DNS (Domain Name System) name of the service assigned to the Pod by the Kubernetes cluster.

[0122] It's worth noting that server 20 can also employ a message passing mechanism to manage access to the instantiated container image. For example, it can use message queues like Kafka for asynchronous communication, achieving decoupling and message passing between services.

[0123] In this embodiment, the port mapping configuration information provided by the Service resource object enables communication and collaborative work between the front-end application and other containerized applications. In addition, a message passing mechanism can be used to decouple and pass messages between services, enhancing the interaction capabilities between services.

[0124] S409: Based on the service exposure configuration information provided by the service resource object, perform service management on the instantiated container image.

[0125] Optionally, server 20 performs service management on the instantiated container image based on service exposure configuration information provided by the Service resource object, such as service type configuration information (in this embodiment, the service type is LoadBancer type) for defining which Pods should receive traffic from the Service resource object, and container group selection configuration information for defining how the Service resource object distributes traffic among multiple Pods.

[0126] In one embodiment, service management is performed on the instantiated container image based on the service exposure configuration information provided by the service resource object, including: using a service discovery mechanism and a load balancing mechanism to perform service management on the instantiated container image based on the service exposure configuration information provided by the service resource object.

[0127] Understandably, a Service resource object of type LoadBalancer creates an external load balancer, enabling the front-end application to automatically discover the location of the back-end service based on the DNS name provided by the Service resource object, thus achieving service discovery, and to achieve load balancing by automatically distributing traffic to Pods matched by the selector.

[0128] In this embodiment, by providing service exposure configuration information through the service resource object, service discovery and load balancing functions are provided for Pods. This not only enables different Pods to easily find and access each other, but also ensures that traffic is evenly distributed to each Pod, thereby improving the responsiveness and reliability of the application.

[0129] The above application deployment and management methods, by using the instantiation configuration information provided by the deployment resource object to instantiate the container image, can achieve automatic deployment of the container image and reduce the possibility of errors from manual configuration. By using the port mapping configuration information provided by the Service resource object to manage access to the instantiated container image, flexible adjustments to service configurations can be made; for example, port mappings can be changed directly without redeploying the entire application. By using the service exposure configuration information provided by the Service resource object to manage services to the instantiated container image, the automatic scheduling and scaling capabilities provided by the Kubernetes cluster can be leveraged to achieve service discovery and load balancing, improving the reliability of application deployment and management. Adopting this solution enables efficient and reliable application deployment and management when handling large projects and complex applications.

[0130] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0131] Inventive concepts based on the above-mentioned application deployment and management methods, such as Figure 5 As shown in the embodiments of this application, an application deployment and management apparatus 500 for implementing the above-described application deployment and management method is also provided. The application deployment and management apparatus 500 includes:

[0132] The first response module 501 is used to respond to the container build command and build the container image of the application based on the image build file;

[0133] The second response module 502 is used to respond to the resource creation command and create a resource object in the Kubernetes cluster according to the Kubernetes manifest file. The resource object is used to configure how the container image is used.

[0134] Deployment management module 503 is used to deploy and manage container images based on resource objects.

[0135] In one possible implementation, the first response module 501 is specifically used to respond to the container build command, obtain the image build file, which includes the base image, the application's dependencies, and the application's static resource files; and build the application's container image based on the image build file.

[0136] In one possible implementation, the first response module 501 is specifically used to respond to the container build command, obtain the image build file, which includes the base image, the application's dependencies, and the application's static resource files; and build the application's container image based on the image build file.

[0137] In one possible implementation, the application deployment and management device 500 also includes an image push module for pushing container images to a remote image repository for storage in response to an image push command.

[0138] In one possible implementation, the second response module 502 is specifically used to create a deployment resource object based on the deployment manifest file, the deployment resource object being used to provide configuration information for the runtime mode of the container image; and to create a service resource object based on the service manifest file, the service resource object being used to provide configuration information for the exposure mode of the container image.

[0139] In one possible implementation, the deployment management module 503 is specifically used to deploy container images based on deployment resource objects to generate instantiated container images; and to manage instantiated container images based on service resource objects.

[0140] In one possible implementation, the runtime configuration information includes instantiation configuration information; the deployment management module 503 is specifically used to instantiate the container image based on the instantiation configuration information provided by the deployment resource object, so as to generate the instantiated container image.

[0141] In one possible implementation, the exposure configuration information includes port mapping configuration information and service exposure configuration information; the deployment management module 503 is specifically used to manage access to the instantiated container image based on the port mapping configuration information provided by the service resource object; and to manage services for the instantiated container image based on the service exposure configuration information provided by the service resource object.

[0142] In one possible implementation, the deployment management module 503 is specifically used to manage access to the instantiated container image based on the port mapping configuration information provided by the service resource object and by using a network service mechanism.

[0143] In one possible implementation, the deployment management module 503 is specifically used to manage the instantiated container image by adopting a service discovery mechanism and a load balancing mechanism based on the service exposure configuration information provided by the service resource object.

[0144] This application also provides an electronic device, which can be a server, and its internal structure diagram can be as follows: Figure 6 As shown, this electronic device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores the user's historical dialogue data. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. The processor executes computer programs to implement a method for deploying and managing applications.

[0145] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0146] In one possible implementation, an electronic device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0147] In response to container build commands, build a container image of the application based on the image build file;

[0148] In response to the resource creation command, a resource object is created in the Kubernetes cluster based on the Kubernetes manifest file. The resource object is used to configure how the container image is used.

[0149] Container images are deployed and managed based on resource objects.

[0150] In one possible implementation, the processor, when executing the computer program, also performs the following steps: in response to a container build command, obtains an image build file, the image build file including a base image, application dependencies, and static resource files of the application; and builds a container image of the application based on the image build file.

[0151] In one possible implementation, the processor, when executing a computer program, also performs the following steps: determining the base layer of the container image based on the base image; overlaying multiple container layers on top of the base layer based on dependencies, static resource files, and preset configuration files; and building the container image based on the base layer and the multiple container layers.

[0152] In one possible implementation, the processor, while executing the computer program, also performs the following steps: in response to an image push command, pushes the container image to a remote image repository for storage.

[0153] In one possible implementation, the processor, when executing the computer program, also performs the following steps: in response to a resource creation command, obtains a deployment manifest file and a service manifest file from the Kubernetes manifest file; creates a deployment resource object based on the deployment manifest file, the deployment resource object being used to provide configuration information for how the container image runs; and creates a service resource object based on the service manifest file, the service resource object being used to provide configuration information for how the container image is exposed.

[0154] In one possible implementation, the processor, while executing the computer program, also performs the following steps: deploying the container image based on the deployment resource object to generate an instantiated container image; and managing the instantiated container image based on the service resource object.

[0155] In one possible implementation, the runtime configuration information includes instantiation configuration information; when the processor executes the computer program, it also performs the following steps: instantiating the container image based on the instantiation configuration information provided by the deployment resource object to generate the instantiated container image.

[0156] In one possible implementation, the exposure configuration information includes port mapping configuration information and service exposure configuration information; when the processor executes the computer program, it also performs the following steps: based on the port mapping configuration information provided by the service resource object, it performs access management on the instantiated container image; based on the service exposure configuration information provided by the service resource object, it performs service management on the instantiated container image.

[0157] In one possible implementation, the processor also performs the following steps when executing the computer program: based on the port mapping configuration information provided by the service resource object, it uses a network service mechanism to manage access to the instantiated container image.

[0158] In one possible implementation, the processor also performs the following steps when executing the computer program: based on the service exposure configuration information provided by the service resource object, it performs service management on the instantiated container image using a service discovery mechanism and a load balancing mechanism.

[0159] This application also provides a computer storage medium storing instructions that, when run on a computer or processor, cause the computer or processor to perform one or more steps in the above embodiments. If the constituent modules of the above-described electronic device are implemented as software functional units and sold or used as independent products, they can be stored in the above-described computer-readable storage medium.

[0160] In one possible implementation, a computer storage medium is provided on which a computer program is stored, and when the computer program is executed by a processor, it performs the following steps:

[0161] In response to container build commands, build a container image of the application based on the image build file;

[0162] In response to the resource creation command, a resource object is created in the Kubernetes cluster based on the Kubernetes manifest file. The resource object is used to configure how the container image is used.

[0163] Container images are deployed and managed based on resource objects.

[0164] In one possible implementation, when the computer program is executed by the processor, it also performs the following steps: in response to a container build command, it obtains an image build file, which includes a base image, application dependencies, and static resource files of the application; and builds a container image of the application based on the image build file.

[0165] In one possible implementation, when the computer program is executed by the processor, the following steps are also performed: determining the base layer of the container image based on the base image; overlaying multiple container layers on top of the base layer based on dependencies, static resource files, and preset configuration files; and building the container image based on the base layer and the multiple container layers.

[0166] In one possible implementation, when the computer program is executed by the processor, it also performs the following steps: in response to an image push command, pushes the container image to a remote image repository for storage.

[0167] In one possible implementation, when the computer program is executed by the processor, it also performs the following steps: in response to a resource creation command, it obtains a deployment manifest file and a service manifest file from the Kubernetes manifest file; it creates a deployment resource object based on the deployment manifest file, the deployment resource object being used to provide configuration information for how the container image runs; and it creates a service resource object based on the service manifest file, the service resource object being used to provide configuration information for how the container image is exposed.

[0168] In one possible implementation, when the computer program is executed by the processor, it also performs the following steps: deploying the container image based on the deployment resource object to generate an instantiated container image; and managing the instantiated container image based on the service resource object.

[0169] In one possible implementation, the runtime configuration information includes instantiation configuration information; when the computer program is executed by the processor, the following steps are also performed: based on the instantiation configuration information provided by the deployment resource object, the container image is instantiated to generate the instantiated container image.

[0170] In one possible implementation, the exposure configuration information includes port mapping configuration information and service exposure configuration information; when the computer program is executed by the processor, it also performs the following steps: based on the port mapping configuration information provided by the service resource object, it performs access management on the instantiated container image; based on the service exposure configuration information provided by the service resource object, it performs service management on the instantiated container image.

[0171] In one possible implementation, when the computer program is executed by the processor, it also performs the following steps: based on the port mapping configuration information provided by the service resource object, it uses a network service mechanism to manage access to the instantiated container image.

[0172] In one possible implementation, when the computer program is executed by the processor, the following steps are also performed: based on the service exposure configuration information provided by the service resource object, a service discovery mechanism and a load balancing mechanism are used to manage the instantiated container image.

[0173] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer storage medium or transmitted through the computer storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital versatile discs (DVDs)), or semiconductor media (e.g., solid-state drives (SSDs)).

[0174] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks. Unless otherwise specified, the technical features of this embodiment and its implementation can be combined arbitrarily.

[0175] The embodiments described above are merely preferred embodiments of this application and are not intended to limit the scope of this application. Any modifications and improvements made by those skilled in the art to the technical solutions of this application without departing from the spirit of this application should fall within the protection scope defined by the claims.

[0176] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A method for deploying and managing an application, characterized in that, The method includes: In response to container build commands, build a container image of the application based on the image build file; In response to a resource creation command, a resource object is created in the Kubernetes cluster according to the Kubernetes manifest file. The resource object is used to configure how the container image is used. Based on the resource object, the container image is deployed and managed.

2. The method as described in claim 1, characterized in that, The step of responding to a container build command and building a container image of the application based on an image build file includes: In response to a container build command, an image build file is obtained, which includes a base image, the application's dependencies, and the application's static resource files; The container image of the application is built based on the image build file.

3. The method as described in claim 1, characterized in that, The process of responding to a resource creation command and creating a resource object in the Kubernetes cluster based on the Kubernetes manifest file includes: In response to the resource creation command, retrieve the deployment manifest file and service manifest file from the Kubernetes manifest file; A deployment resource object is created based on the deployment manifest file. The deployment resource object is used to provide the runtime configuration information of the container image. A service resource object is created based on the service manifest file. The service resource object is used to provide configuration information for the exposure method of the container image.

4. The method as described in claim 3, characterized in that, The deployment and management of the container image based on the resource object includes: Based on the deployment resource object, the container image is deployed to generate the instantiated container image; Based on the service resource object, the instantiated container image is managed.

5. The method as described in claim 4, characterized in that, The operation mode configuration information includes instantiation mode configuration information; The step of deploying the container image based on the deployment resource object to generate the instantiated container image includes: Based on the instantiation configuration information provided by the deployment resource object, the container image is instantiated to generate the instantiated container image.

6. The method as described in claim 5, characterized in that, The exposure method configuration information includes port mapping configuration information and service exposure configuration information; The management of the instantiated container image based on the service resource object includes: Based on the port mapping configuration information provided by the service resource object, access management is performed on the instantiated container image. Based on the service exposure configuration information provided by the service resource object, service management is performed on the instantiated container image.

7. The method as described in claim 6, characterized in that, The access management of the instantiated container image based on the port mapping configuration information provided by the service resource object includes: Based on the port mapping configuration information provided by the service resource object, a network service mechanism is used to manage access to the instantiated container image.

8. An application deployment and management apparatus, characterized in that, The device includes: The first response module is used to respond to container build commands and build the container image of the application based on the image build file; The second response module is used to respond to the resource creation command and create a resource object in the Kubernetes cluster according to the Kubernetes manifest file. The resource object is used to configure the usage of the container image. The deployment management module is used to deploy and manage the container image based on the resource object.

9. An electronic device, characterized in that, include: A processor and a memory; the memory stores a computer program, and the processor executes the computer program to implement the method steps of any one of claims 1-7.

10. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions adapted for loading by a processor and executing the method steps as claimed in any one of claims 1-7.

Images