Deployment method, device and storage medium for multiple Odoo applications

Abstract

The present invention discloses a method, device, and storage medium for deploying multiple Odoo applications. The method includes the following steps: S1, compiling corresponding application images and database images for the multiple Odoo applications to be deployed, and generating an application image template and a database image template; S2, querying the application data corresponding to each of the multiple Odoo applications, where the application data includes the application image, the database image, the application image template, and the database image template; and S3, automatically allocating resources for each Odoo application, copying the database image template, starting a database container, copying the application image template, starting an application container, and generating and binding a domain name. The method deploys Odoo applications by calling the Kubernetes API and Docker containers, enabling one-click deployment of multiple Odoo applications. The method also offers advantages such as fast deployment and low management costs.

Description

Technical Field

[0001] The present invention relates to the field of industrial Internet technology, and in particular to a deployment method, device, and storage medium for multiple Odoo applications. Background Art

[0002] Application deployment is an important part of software development. In traditional deployment methods, the general process is that developers develop the code, debug, submit the code for testing, test it by testers, then release the application package, and finally the project implementers deploy the project application. The traditional Odoo application deployment method has the following disadvantages:

[0003] (1) The deployment process is complex. Odoo deployment often includes database deployment, application deployment, reverse proxy, load balancing, and domain name resolution, which places high demands on deployment personnel.

[0004] (2) The configuration is cumbersome and error-prone.

[0005] (3) The entire process requires the participation of developers and implementation personnel, and non-relevant personnel cannot deploy applications by themselves.

[0006] (4) Poor isolation. When different applications require different environments, the environment of one application on the same server is often incompatible with the environment of another application. Although traditional deployment can isolate environments through virtual machines, it also leads to the problem of excessive resource usage by virtual machines, making it impossible to deploy too many applications.

[0007] (5) Poor portability. Applications in production environments are too dependent on the deployed operating system and cloud server. When the operating system or cloud server provider is changed, the application often fails to run.

[0008] Based on the above situation, it is necessary to provide a method for automatic application deployment, so that users can independently deploy multiple Odoo applications such as ERP, CRM, MES, eHR, etc. to the cloud server with one click. Summary of the Invention

[0009] The present invention aims to solve, at least to some extent, one of the technical problems in the related art. To this end, one object of the present invention is to provide a method, apparatus, and storage medium for deploying multiple Odoo applications, which can facilitate users to deploy multiple Odoo applications with one click.

[0010] The technical solution adopted in the present invention is:

[0011] In a first aspect, the present invention provides a deployment method for multiple Odoo applications, which includes the following steps: S1, compiling corresponding application images and database images for multiple Odoo applications to be deployed, and generating application image templates and database image templates; S2, querying application data corresponding to each Odoo application in the multiple Odoo applications, where the application data includes: the application image, the database image, the application image template, and the database image template; S3, automatically allocating resources for each Odoo application, copying the database image template, starting a database container, copying the application image template, starting an application container, and generating and binding a domain name.

[0012] Step S3 includes: calling a Kubernetes API to allocate a first resource for the database image; determining whether the first resource is sufficient; if so, calling a Kubernetes API to create a unique namespace for the database image; calling a Kubernetes API to copy the database image template and start a database container;

[0013] If the database container is started successfully, the Kubernetes API is called to allocate the second resource for the application image.

[0014] Determine whether the second resource is sufficient; if so, call the Kubernetes API to copy the application image template and start the application container; if the application container starts successfully, generate and bind a domain name.

[0015] Among them, the generation and binding of the domain name includes: using the API interface function and secret key provided by the domain name provider to create a client connection; if the client successfully creates the connection, setting parameters for the client, which include: the first-level domain name, the second-level domain name and the resolution record type; submitting the second-level domain name resolution to the domain name provider through the client; if the second-level domain name resolution is successful, binding the second-level domain name to the Odoo application.

[0016] Among them, step S1 includes: using the dockerfile file to compile the corresponding application images and database images for the multiple Odoo applications respectively, and generating application image templates and database image templates.

[0017] The process between step S1 and step S2 also includes: synchronizing the organizational structure and user list from the user center to the database mirror template.

[0018] In a second aspect, the present invention provides a deployment device for multiple Odoo applications, which includes: a compilation module, which is used to compile corresponding application images and database images for multiple Odoo applications to be deployed, and generate application image templates and database image templates; a query module, which is used to query the application data corresponding to each Odoo application in the multiple Odoo applications, and the application data includes: the application image, the database image, the application image template and the database image template; a deployment module, which automatically allocates resources for each Odoo application, copies the database image template, starts the database container, copies the application image template, starts the application container, and generates and binds a domain name.

[0019] The deployment module includes: a database image resource allocation unit, which is used to call the Kubernetes API to allocate a first resource for the database image; a database image resource judgment unit, which is used to judge whether the first resource is sufficient; a database image naming unit, which is used to call the Kubernetes API to create a unique namespace for the database image if the first resource is sufficient; a database image template copying unit, which is used to call the Kubernetes API to copy the database image template and start the database container; an application image resource allocation unit, which is used to call the Kubernetes API to allocate a second resource for the application image if the database container is successfully started; an application image resource judgment unit, which is used to judge whether the second resource is sufficient; an application image template copying unit, which is used to call the Kubernetes API to copy the application image template and start the application container if the second resource is sufficient; a domain name generation and binding unit, which is used to generate and bind a domain name if the application container is successfully started.

[0020] Among them, the domain name generation and binding unit includes: a client connection creation sub-unit, which is used to create a client connection using the API interface function and secret key provided by the domain name provider; a client parameter setting sub-unit, which is used to set parameters for the client if the client successfully creates the connection, and the parameters include: the first-level domain name, the second-level domain name and the resolution record type; a second-level domain name resolution sub-unit, which is used to submit the second-level domain name resolution to the domain name provider through the client; a domain name binding sub-unit, which is used to bind the second-level domain name to the Odoo application if the second-level domain name resolution is successful.

[0021] The deployment device further includes: a data synchronization module for synchronizing the organizational structure and user list from the user center to the database mirror template.

[0022] In a third aspect, the present invention provides a computer-readable storage medium storing computer-executable instructions for causing a computer to execute the above method.

[0023] The beneficial effects of the present invention are:

[0024] The present invention implements the deployment of Odoo applications by calling the Kubernetes API and Docker containers, allowing for the easy deployment of multiple Odoo applications with one click. This deployment method has multiple advantages, such as fast deployment speed and low management cost. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 1 is a flow chart of an embodiment of a method for deploying multiple Odoo applications according to the present invention;

[0026] Figure 2 yes Figure 1 A schematic flow chart of an embodiment of step S3;

[0027] Figure 3 yes Figure 2 A flowchart of an embodiment of step S38;

[0028] Figure 4 It is a structural diagram of an embodiment of a deployment device for multiple Odoo applications of the present invention;

[0029] Figure 5 yes Figure 4 A schematic structural diagram of an embodiment of a deployment module 3;

[0030] Figure 6 yes Figure 5 A structural diagram of an embodiment of a domain name generation binding unit 38. DETAILED DESCRIPTION

[0031] It should be noted that, unless there is any conflict, the embodiments and features in the embodiments of this application can be combined with each other.

[0032] Example 1

[0033] See also Figure 1 , Figure 1 FIG. 1 is a flow chart of an embodiment of a method for deploying multiple Odoo applications of the present invention. Figure 1 As shown, the deployment method includes the following steps:

[0034] S1: Compile the corresponding application images and database images for multiple Odoo applications to be deployed, and generate application image templates and database image templates;

[0035] In step S1, the Dockerfile file is used to compile the corresponding application images and database images for the multiple Odoo applications, and an application image template and a database image template are generated.

[0036] S2: Query the application data corresponding to each Odoo application in the multiple Odoo applications, where the application data includes: the application image, the database image, the application image template, and the database image template;

[0037] Typically, after an application is deployed, the organizational structure and user list cannot be packaged in the database template because different customers have different organizational structures and corresponding user lists. After an application is automatically deployed, the corresponding administrator must manually create or use other tools to import the organizational structure and user list into the application, which greatly reduces efficiency. When a customer deploys multiple applications, they also need to create organizational structures and user lists for multiple applications, which requires a lot of repetitive and error-prone work. To address the above issues, we introduced the User Center, which not only stores the customer's organizational structure and user list, but also serves as a permission authentication center. After the customer completes registration, they only need to import the organizational structure and user list into the User Center. After deploying the application, the organizational structure and user list corresponding to the User Center can be automatically or manually synchronized to the application, so that they can be imported into one place and used in multiple places.

[0038] Therefore, between step S1 and step S2, the following step is also included: synchronizing the organizational structure and user list from the user center to the database mirror template. In this way, there is no need to manually configure the organizational structure and user list for each Odoo application.

[0039] S3: Automatically allocates resources for each Odoo application, copies the database image template, starts the database container, copies the application image template, starts the application container, and generates and binds a domain name.

[0040] See also Figure 2 , Figure 2 yes Figure 1 A flow chart of an embodiment of step S3. Figure 2 As shown, step S3 includes the following sub-steps:

[0041] S31: Call the Kubernetes API to allocate the first resource for the database image;

[0042] The first resource includes: CPU, memory and disk space.

[0043] S32: Determine whether the first resource is sufficient;

[0044] S33: If yes, call the Kubernetes API to create a unique namespace for the database image;

[0045] The database image name is unique for each Odoo application, so no two Odoo applications will have the same database image name. This avoids the technical problem of having databases with the same name when different users deploy Odoo applications using the same database template on the same cluster.

[0046] S34: Call the Kubernetes API to copy the database image template and start the database container;

[0047] S35: If the database container is successfully started, call the Kubernetes API to allocate the second resource for the application image;

[0048] S36: Determine whether the second resource is sufficient;

[0049] S37: If yes, call the Kubernetes API to copy the application image template and start the application container;

[0050] S38: If the application container is started successfully, a domain name is generated and bound.

[0051] See also Figure 3 , Figure 3 FIG. 4 is a flow chart of an embodiment of step S38. Figure 3 As shown, this step includes the following sub-steps:

[0052] S381: Use the API interface function and secret key provided by the domain name provider to create a client connection;

[0053] Optionally, create a client connection using the AssClient API function and key provided by the domain name provider.

[0054] S382: If the client successfully establishes a connection, set parameters for the client, including: the first-level domain name, the second-level domain name, and the resolution record type;

[0055] S383: Submitting the secondary domain name resolution to the domain name provider through the client;

[0056] S384: If the second-level domain name is resolved successfully, the second-level domain name is bound to the Odoo application.

[0057] In this step, the SDK provided by the domain name provider is used to automatically and quickly apply for a second-level domain name for the application and bind the domain name to the application. Users can access the application through this second-level domain name. Compared with the method of accessing the application using the IP address + port, it is easier for users to remember and avoids the technical problem of limited port resources. It should be noted that each sub-step in step S38 is implemented by calling the Kubernetes API interface function.

[0058] In this example, the Odoo application is deployed by calling the Kubernetes API and Docker containers. Compared with other deployment methods, this deployment method has the following main advantages:

[0059] (1) Fast startup. The container startup of this deployment method is equivalent to starting a process on the host operating system, which is at the second level. Database and application template data are added to each application, and image data initialization is not required after the application starts.

[0060] (2) Small resource usage. A traditional virtual machine is a complete operating system that requires a large amount of disk space, memory, and CPU resources. Compared to a virtual machine, an optimized cloud container is just a process that only packages the application and related components. Thousands of instances can be opened on a single machine.

[0061] (3) Easy deployment and strong portability. In the past, after product development was completed, it took a lot of manpower and material resources to build the test environment and production environment. In addition, there was a problem that the test environment ran normally while the production environment could not run due to inconsistencies between the test environment and the development environment. The Docker container of this embodiment can perfectly solve the above problems, and it can support multiple operations in one package. In addition, it also supports multiple cloud platforms, including but not limited to Alibaba Cloud Server, Huawei Cloud Server, and Tencent Cloud Server. It can also run perfectly on self-built servers.

[0062] (4) Good isolation. The Docker container of this embodiment can support running multiple versions simultaneously on the same server. The environment and resources within the container will not affect each other. Updating or deleting one container will not affect the operation of other containers.

[0063] (5) Low management cost. Developed based on native Kubernetes, it implements and supports modularization, plug-inization, mountability, automatic deployment, automatic restart, automatic replication, and automatic scaling of containers, saving a lot of operation and maintenance costs.

[0064] (6) Application installation is quick and easy. Users can install applications automatically and autonomously on the Optimized Cloud Server with just one click. They are ready to use right out of the box, without the involvement of developers or maintenance personnel. Users can have their own cloud ERP, cloud CRM, cloud MES, cloud eHR and other cloud applications, saving a lot of manpower and material resources.

[0065] Example 2

[0066] See also Figure 4 , Figure 4 FIG is a schematic diagram of a structure of an embodiment of a deployment device for multiple Odoo applications of the present invention. Figure 4As shown, the deployment device includes a compilation module 1, a query module 2 and a deployment module 3.

[0067] Compilation module 1 is used to compile corresponding application images and database images for multiple Odoo applications to be deployed, and generate application image templates and database image templates.

[0068] Query module 2 is used to query the application data corresponding to each Odoo application in the multiple Odoo applications, and the application data includes: the application image, the database image, the application image template and the database image template.

[0069] Deployment module 3 automatically allocates resources for each Odoo application, copies the database image template, starts the database container, copies the application image template, starts the application container, and generates and binds a domain name.

[0070] Specifically, see Figure 5 , Figure 5 Schematic diagram of the structure of an embodiment of the deployment module 3. Figure 5 As shown, the deployment module 3 includes a database image resource allocation unit 31, a database image resource judgment unit 32, a database image naming unit 33, a database image template copy unit 34, an application image resource allocation unit 35, an application image resource judgment unit 36, an application image template copy unit 37 and a domain name generation and binding unit 38.

[0071] A database image resource allocation unit 31 is configured to call a Kubernetes API to allocate a first resource to the database image;

[0072] The database mirror resource determination unit 32 is configured to determine whether the first resource is sufficient;

[0073] The database image naming unit 33 is configured to call the Kubernetes API to create a unique namespace for the database image if yes.

[0074] The database image template copy unit 34 is used to call the Kubernetes API to copy the database image template and start the database container;

[0075] The application image resource allocation unit 35 is configured to call the Kubernetes API to allocate a second resource to the application image if the database container is successfully started;

[0076] An application image resource determination unit 36 ​​is configured to determine whether the second resource is sufficient;

[0077] The application image template copying unit 37 is configured to call the Kubernetes API to copy the application image template and start the application container if yes;

[0078] The domain name generation and binding unit 38 is used to generate and bind a domain name if the application container is successfully started. Figure 6 , Figure 6 FIG. 1 is a structural diagram of an embodiment of the domain name generation and binding unit 38. Figure 6 As shown, the domain name generation and binding unit 38 includes: a client connection creation subunit 381, a client parameter setting subunit 382, ​​a second-level domain name resolution subunit 383, and a domain name binding subunit 384. The client connection creation subunit 381 is used to create a client connection using the API interface function and secret key provided by the domain name provider. The client parameter setting subunit 382 is used to set parameters for the client if the client successfully creates a connection, and the parameters include: the first-level domain name, the second-level domain name, and the resolution record type. The second-level domain name resolution subunit 383 is used to submit the second-level domain name resolution to the domain name provider through the client. The domain name binding subunit 384 is used to bind the second-level domain name to the Odoo application if the second-level domain name resolution is successful.

[0079] Preferably, the deployment device further includes a data synchronization module (not shown) for synchronizing the organizational structure and user list from the user center to the database mirror template.

[0080] Specifically, the working methods of the various modules of the deployment device have been described in detail in the first embodiment and will not be repeated here.

[0081] Example 3

[0082] The present invention provides a computer-readable storage medium storing computer-executable instructions, wherein the computer-executable instructions are used to enable a computer to execute the method described in the first embodiment.

[0083] The above is a specific description of the preferred implementation of the present invention, but the invention is not limited to the embodiments. Those skilled in the art can make various equivalent modifications or substitutions without violating the spirit of the present invention. These equivalent modifications or substitutions are all included in the scope defined by the claims of this application.

Claims

1. A method for deploying multiple Odoo applications, characterized in that: Including steps: S1. Compile the corresponding application images and database images for multiple Odoo applications to be deployed, and generate application image templates and database image templates; S2. Query application data corresponding to each of the multiple Odoo applications, where the application data includes: the application image, the database image, the application image template, and the database image template; S3. Automatically allocate resources for each Odoo application, copy the database image template, start the database container, copy the application image template, start the application container, and generate and bind a domain name; The steps between step S1 and step S2 also include: Synchronize the organizational structure and user list from the user center to the database mirror template, wherein the user center not only stores the customer's organizational structure and user list, but also serves as an authority authentication center; The step S3 comprises: Calling a Kubernetes API to allocate a first resource for the database image; determining whether the first resource is sufficient; If yes, call the Kubernetes API to create a unique namespace for the database image; Call the Kubernetes API to copy the database image template and start the database container; If the database container is successfully started, call the Kubernetes API to allocate a second resource to the application image; determining whether the second resource is sufficient; If yes, call the Kubernetes API to copy the application image template and start the application container; If the application container is started successfully, a domain name is generated and bound; Generating and binding a domain name includes: Use the AssClientAPI interface function and secret key provided by the domain name provider to create a client connection; If the client successfully establishes a connection, parameters are set for the client, including: the first-level domain name, the second-level domain name, and the resolution record type. The SDK provided by the domain name provider is used to automatically apply for the second-level domain name for the Odoo application. Submitting secondary domain name resolution to the domain name provider through the client; If the second-level domain name is resolved successfully, the second-level domain name is bound to the Odoo application; The step S1 comprises: Use the Dockerfile file to compile the corresponding application images and database images for the multiple Odoo applications, and generate application image templates and database image templates.

2. A deployment device for multiple Odoo applications, characterized in that: include: The compilation module is used to compile the corresponding application images and database images for multiple Odoo applications to be deployed, and generate application image templates and database image templates; A query module, configured to query application data corresponding to each of the multiple Odoo applications, wherein the application data includes: the application image, the database image, the application image template, and the database image template; A deployment module that automatically allocates resources for each Odoo application, copies the database image template, starts the database container, copies the application image template, starts the application container, and generates and binds a domain name; The deployment module includes: A database image resource allocation unit, configured to call a Kubernetes API to allocate a first resource to the database image; a database mirror resource determination unit, configured to determine whether the first resource is sufficient; A database image naming unit, configured to, if yes, call the Kubernetes API to create a unique namespace for the database image; A database image template copy unit, used to call the Kubernetes API to copy the database image template and start the database container; An application image resource allocation unit, configured to call a Kubernetes API to allocate a second resource to the application image if the database container is successfully started; An application image resource determination unit, configured to determine whether the second resource is sufficient; An application image template copying unit, configured to call a Kubernetes API to copy the application image template and start an application container if yes; A domain name generating and binding unit, configured to generate and bind a domain name if the application container is successfully started; The compilation module and the query module also include: A data synchronization module, used to synchronize the organizational structure and user list from the user center to the database mirror template, wherein the user center not only stores the customer's organizational structure and user list, but also serves as an authority authentication center; The domain name generation and binding unit includes: The client connection creation subunit is used to create a client connection using the AssClientAPI interface function and secret key provided by the domain name provider; The client parameter setting subunit is used to set parameters for the client if the client successfully establishes a connection. The parameters include: the first-level domain name, the second-level domain name, and the resolution record type. The SDK provided by the domain name provider is used to automatically apply for the second-level domain name for the Odoo application. A secondary domain name resolution subunit, configured to submit a secondary domain name resolution to the domain name provider via the client; The domain name binding subunit is used to bind the second-level domain name to the Odoo application if the second-level domain name resolution is successful.

3. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, and the computer-executable instructions are used to enable a computer to execute the method according to claim 1.

Images