CN115145604A - Containerized electric power marketing system deployment method - Google Patents
Containerized electric power marketing system deployment method Download PDFInfo
- Publication number
- CN115145604A CN115145604A CN202210840636.1A CN202210840636A CN115145604A CN 115145604 A CN115145604 A CN 115145604A CN 202210840636 A CN202210840636 A CN 202210840636A CN 115145604 A CN115145604 A CN 115145604A
- Authority
- CN
- China
- Prior art keywords
- mirror image
- marketing system
- power marketing
- environment
- file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 43
- 238000011161 development Methods 0.000 claims abstract description 26
- 238000012360 testing method Methods 0.000 claims description 29
- 238000013515 script Methods 0.000 claims description 14
- 238000004806 packaging method and process Methods 0.000 claims description 13
- 238000004519 manufacturing process Methods 0.000 claims description 11
- 230000005611 electricity Effects 0.000 claims description 8
- 238000012545 processing Methods 0.000 claims description 7
- 238000004140 cleaning Methods 0.000 claims description 6
- 230000007246 mechanism Effects 0.000 claims description 5
- 244000035744 Hura crepitans Species 0.000 claims description 3
- 238000009434 installation Methods 0.000 claims description 3
- 230000008569 process Effects 0.000 abstract description 10
- 238000002955 isolation Methods 0.000 abstract description 3
- 230000018109 developmental process Effects 0.000 description 20
- 238000005516 engineering process Methods 0.000 description 8
- 238000007726 management method Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 3
- 230000001419 dependent effect Effects 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 230000005012 migration Effects 0.000 description 2
- 238000013508 migration Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 239000008186 active pharmaceutical agent Substances 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000006835 compression Effects 0.000 description 1
- 238000007906 compression Methods 0.000 description 1
- 230000003247 decreasing effect Effects 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 238000009826 distribution Methods 0.000 description 1
- 230000002349 favourable effect Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 238000013439 planning Methods 0.000 description 1
- 238000009877 rendering Methods 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000005096 rolling process Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000033772 system development Effects 0.000 description 1
- 238000002054 transplantation Methods 0.000 description 1
- 238000013024 troubleshooting Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
- G06F8/63—Image based installation; Cloning; Build to order
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45562—Creating, deleting, cloning virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45587—Isolation or security of virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
The invention discloses a containerized electric power marketing system deployment method, which comprises the following steps: step 1, constructing a JAR file of a power marketing system in a development environment; step 2, generating a Docker container mirror image of the power marketing system in a maker on the basis of the JAR file of the power marketing system; step 3, pushing the Docker container mirror image into a Harbor mirror image library; step 4, drawing a Docker container mirror image of a required environment by configuring Kubernets; and 5, starting the Docker container mirror image pulled by the k8s in a standard mirror image starting mode. According to the invention, each container is isolated from each other, the file system is provided, processes among the containers cannot influence each other, and computing resources can be distinguished. Since the container is decoupled from the underlying infrastructure, the machine file system, it can migrate between different clouds, different versions of the operating system. The deployment is safe and convenient, the isolation is good, the rapid rollback can be realized, and the cost is low.
Description
Technical Field
The invention belongs to the technical field of electric power energy, and particularly relates to a containerized electric power marketing system deployment method.
Background
The electricity marketing system is divided into three environments: development environment, test environment and production environment. Continuous deployment and environment migration are usually required in the system development and test process, and multiple environments and multiple application services are required to be unaffected during the deployment process.
One solution in the prior art is that an application deployment mode installs an application through a plug-in or a script. Therefore, the operation, configuration, management and all life cycles of the application are bound with the current operating system, and the operation of upgrading, updating, rolling back and the like of each application of the power marketing system is not facilitated.
Another solution in the prior art is that an application deployment manner implements system functions by creating a virtual machine, but the virtual machine is very heavy and is not favorable for portability.
Therefore, it becomes a difficult point to research a deployment method suitable for multi-environment systems such as power marketing systems with characteristics of non-interference, rapid deployment and flexible transplantation.
Disclosure of Invention
In order to solve the defects in the prior art, the invention aims to provide a containerized power marketing system deployment method, wherein each container is isolated from each other, each container has a file system, processes among the containers cannot influence each other, and computing resources can be distinguished. Since the container is decoupled from the underlying infrastructure, the machine file system, it can migrate between different clouds, different versions of the operating system.
The invention adopts the following technical scheme:
a containerized electric power marketing system deployment method, comprising:
step 1, constructing a JAR file of a power marketing system in a development environment;
step 2, generating a Docker container mirror image of the power marketing system in a maker on the basis of the JAR file of the power marketing system;
step 3, pushing the Docker container mirror image into a Harbor mirror image library;
step 4, drawing a Docker container mirror image of a required environment by configuring Kubernets;
and 5, starting the Docker container mirror image pulled by the k8s in a standard mirror image starting mode.
Preferably, in step 1, the constructing a JAR file of the electricity marketing system in the development environment specifically includes: respectively generating JAR files of a development environment, a test environment and a production environment by using terminals in the development environment;
the JAR file in each environment of the power marketing system specifically comprises: the system comprises a system end front end service, a client module back end service and a contract module back end service.
Preferably, step 1 specifically comprises:
step 1.1, cleaning the existing catalogue by using a cleaning plug-in;
step 1.2, the resource plug-in is used for executing the processing of the resource file;
step 1.3, compiling all source files by using a compiling plug-in to generate byte code files;
step 1.4, the resource plug-in is used for executing the processing of the test resource file;
step 1.5, compiling all source codes under a test directory by using a compiling plug-in;
step 1.6, running a test case by using a plug-in;
and step 1.7, packaging the files generated after compiling in the step 1.3 and the step 1.5 by using plug-ins.
Preferably, in the step 2, generating the Docker container image in the maker based on the JAR file of the power marketing system specifically includes: automatically packaging system end front-end services, customer module back-end services and contract module back-end services of JAR files of the development environment, the test environment and the production environment in the step 1 into a Docker container mirror image standardized environment deployment by reading instructions in Dockerfile, wherein the containers use a sandbox mechanism and do not have any interfaces; the Dockerfile instruction includes: basic mirror image information, maintainer information, mirror image operation instructions and container execution instructions when starting.
Preferably, in step 2, creating a mirror image of the electricity marketing system based on the configuration file specifically includes:
step 2.1, establishing a catalog as a working catalog for generating a working mirror image;
step 2.2, creating and compiling a configuration file;
step 2.3: compiling the content of the execution script;
step 2.4, a test page is created;
and 2.5, generating an image by using the configuration file.
Preferably, in step 2.2, the content defined by the configuration file includes: the method includes the steps of base mirroring, maintaining user information of the mirroring, mirror operation instruction installation, port exposure, copying execution scripts into the mirroring, and scripts executed when a container is started.
Preferably, in step 3, pushing the Docker container mirror image to the Harbor mirror image library specifically includes: pushing the Docker container mirror generated by Dokcerfile into the Harbor private warehouse.
Preferably, in step 4, the mirror is pulled through the mirror pull policy and the mirror address defined in the YAML file.
Preferably, in step 4, the mirror image pull method includes: pulling the mirror image regardless of whether the mirror image exists locally or not; if the local mirror image exists locally, the local mirror image is used for not pulling; only the local image is used to never pull, even if not locally.
Preferably, in step 5, the constructing a container image start-up configuration file includes: the configuration file describes the packaging association relationship of the container mirror image, a host port and a container mirror image packaging port used by the container mirror image, an API (application programming interface) package used by a starting environment, the content type of the described object, the name of the content object related to the container mirror image, and the configuration content of the description parameters of the content object.
Compared with the prior art, the invention has the beneficial effects that:
(1) The containerized electric power marketing system deployment method is convenient to deploy. The containers are very easy to deploy, the development environment of the system is only the addresses of one or more container images, at most, an execution script for controlling the deployment process is needed, or the environment images and the image scripts are further put into a project and issued to the cloud, and the environment images and the image scripts are pulled to the local place when needed.
(2) The containerized electric power marketing system deployment method is safe to deploy. The feedback of the Bug is often in the inconsistency of the environment, and the debugging in the development process is often not capable of guaranteeing the problems of other environments. The daily air supply deployment method can reduce the occurrence of the situation. The development environment, the test environment and the production environment are kept unified in version and dependence through a container technology, and the code is guaranteed to be executed on a highly unified environment. The unification of the test environment can also solve the requirement of the continuous integration process on the environment. At present, distributed technology and increasing capacity expansion demand are increasing day by day, use container technology to carry out the deployment of environment, not only saved deployment time greatly, also can reduce many because the mistake that artifical configuration environment produced to minimum.
(3) The containerized electric power marketing system deployment method has good isolation. Whether development or production, often, a plurality of services may need to run on one machine, and the respective required dependency configurations of the services are different, and if it is stated that two applications need to use the same dependency, or there is some conflict between the dependencies required by the two applications, problems easily occur. The containers have natural advantages in this respect, each container is an isolated environment, the requirement for providing services inside the container is met, and the containers can be provided in a self-dependent manner. This high-cohesion appearance can enable rapid separation of problematic services, and in some complex systems, rapid troubleshooting and timely processing.
(4) The containerized electric power marketing system deployment method can realize quick rollback. The rollback mechanism before the container technology generally needs to be redeployed based on the application of the previous version to replace the current problem version. This may be a complete development-to-deployment process that often takes a long time to execute. In a version control based environment, it may be possible to rollback a certain historical commit and then redeploy. These are not fast enough and may cause new problems due to modifications based on new versions. Container technology with a rollback property, every history container or mirror will have a save, and replacing a container or a history mirror is very quick and simple.
(5) The disposition method of the containerized electric power marketing system is low in cost. In the past, a new server or a virtual machine is often required for building an application, the acquisition cost and the operation and maintenance cost of the server are high, and the virtual machine also needs to occupy a lot of unnecessary resources. The container is small, exquisite and light, and can be completed only by relying on the application built in one container.
(6) The containerized electric power marketing system deployment method is lower in management cost. As container management and organization technology has evolved, container technology has more possibilities and greater play space in a production environment, and costs of use and learning have decreased even more.
Drawings
FIG. 1 is a flow chart of a method of deploying a containerized power marketing system of the present invention.
Detailed Description
The present application is further described below with reference to the accompanying drawings. The following examples are only for illustrating the technical solutions of the present invention more clearly, and the protection scope of the present application is not limited thereby.
As shown in fig. 1, a first embodiment of the present invention provides a containerized electric power marketing system deployment method, including the following steps:
step 1, constructing a JAR file of the power marketing system in a development environment.
It is noted that JAR files (Java Archive, english: java Archive) are a computer file format that is commonly used to aggregate a large number of Java class files, associated metadata and resource (text, pictures, etc.) files into one file in order to develop Java platform applications or libraries. JAR files are based on the popular ZIP file format, but unlike ZIP files, JAR files are not only used for compression and distribution, but also for deploying and packaging libraries, components, and plug-ins, and can be used directly by tools like compilers and JVMs.
In a preferred but non-limiting embodiment of the invention, the electricity marketing system is largely divided into a development environment, a test environment, a production environment. In order to ensure that programs of three environments are kept consistent and avoid program errors caused by inconsistent programs, a JAR file of a power marketing system is constructed in a development environment, and the method specifically comprises the following steps: and respectively generating JAR files of a development environment, a test environment and a production environment by using terminals in the development environment. The JAR file in each environment of the power marketing system specifically comprises: the system comprises a system end front end service, a client module back end service and a contract module back end service. The whole architecture of the electric power marketing system adopts micro-services, the whole system is divided into two modules of a client and a contract from the whole business function division, so that the corresponding micro-services of the client module and the contract module are provided when the micro-services are created, the two modules refer to service APIs provided by the back end, except the service provided by the back end, rendering of a front end page is provided, the front end page of the whole system is used as one micro-service, so that three micro-service modules exist in total, each module can operate independently, and the three module codes jointly form the functions of the electric power marketing system.
In a further preferred but non-limiting embodiment of the invention, the building of a JAR file of the electricity marketing system in the development environment specifically comprises:
step 1.1, cleaning the existing catalogue by using a cleaning plug-in;
step 1.2, the resource plug-in is used for executing the processing of the resource file; the resource file refers to that some configurations used in the program are written in the resource file, and the program can read required information from the resource file, such as the configuration of a data source, the configuration of a third-party plug-in, a port used by the program, and the like;
step 1.3, compiling all source files by using a compiling plug-in to generate byte code files;
step 1.4, the resource plug-in is used for executing the processing of the test resource file; the code package structure comprises a main code and a test code, the main code is provided with a corresponding resource file, the test code is also provided with a corresponding test resource file, some global information can be written in the resource file according to needs in the specific resource file, and a program can read the needed information from the resource file;
step 1.5, compiling all source codes under a test directory by using a compiling plug-in;
step 1.6, running a test case by using a plug-in; the test cases are mainly some test codes written for verifying the correctness of the program in the development process;
and step 1.7, packaging the files generated after compiling in the step 1.3 and the step 1.5 by using plug-ins.
It is worth noting that the method for constructing the JAR file of the power marketing system in the development environment can ensure that the package is accurate and error-free, and can timely find obvious errors in the compiling test stage.
And 2, generating a Docker container mirror image of the power marketing system in a maker on the basis of the JAR file of the power marketing system obtained in the step 1.
Notably, docker is a container technology in Linux. The Docker container is used as an application container engine, so that developers can package their applications and dependency packages in a uniform mode into a portable container and then distribute the portable container to any server provided with the Docker container, and virtualization can be achieved. The containers are fully sandboxed without any interface between each other. There is little performance overhead and it can be easily run in machines and data centers. Most importantly, they are not dependent on any language, framework, and system. To create an image, a Dockerfile is used to define the necessary steps for image development.
In a preferred but non-limiting embodiment of the present invention, generating a Docker container image in a producer based on a JAR file of a power marketing system specifically includes: and (2) automatically packaging system end front-end services, client module back-end services and contract module back-end services of JAR files of the development environment, the test environment and the production environment in the step (1) into a Docker container mirror image standardized environment deployment by reading instructions in Dockerfile, wherein the containers use a sandbox mechanism and do not leave any interfaces, so that unnecessary bugs cannot occur due to inconsistent environments in the migration and deployment of the services in different environments. The Dockerfile instruction includes: basic mirror image information, maintainer information, mirror image operation instructions and container execution instructions when starting.
In a further preferred but non-limiting embodiment of the invention, creating an image of the electricity marketing system based on the profile specifically comprises:
step 2.1, establishing a catalog as a working catalog for generating a working mirror image;
and 2.2, creating and writing a configuration file.
The contents of the profile definition include: the method comprises the steps of basic mirroring, user information for maintaining mirroring, mirror operation instruction installation, port exposure, copying execution scripts into mirroring and scripts executed when a container is started. The above is the main content used by the configuration file of the power marketing system, but the configuration file is not limited to the above points.
Step 2.3: and writing the execution script content.
And 2.4, creating a test page.
It should be noted that the configuration files, the script files that need to be run, and the files to be copied into the container all have to be at the same level below the working directory.
And 2.5, generating an image by using the configuration file.
In a further preferred but non-limiting embodiment of the present invention, when creating an image of an electric power marketing system based on a configuration file, a generated unique number is spliced to each manufactured image name and used as a name of a final image, and then the manufactured image is pushed to a warehouse, so that a version rollback problem is solved, if it is said that each manufactured image is the same name and has no unique number or other identifier, so that the original image is covered by pushing the image to the warehouse, if an application program of this time has a major error, the rollback version can only be repackaged and deployed after the program is modified, and the electric power marketing system adopts the above manner to avoid the problem, so that there are multiple versions of image files in the warehouse, and if the error occurs, the corresponding version can be quickly rolled back according to the version number, thereby avoiding that the previous version cannot be rolled back in time due to the major error of the program.
And 3, pushing the Docker container mirror image into a Harbor mirror image library.
Notably, harbor is an enterprise level Registry server for storing Docker images. Users are organized with Docker mirror warehouses by 'project', and one user can have different rights in the same namespace (project) for a plurality of mirror warehouses. Mirroring can be replicated (synchronized) in multiple registration instances.
In a preferred but non-limiting embodiment of the invention, pushing the Docker container mirror to the Harbor mirror library specifically comprises: and pushing the Docker container mirror generated by the Dokcerfile to a Harbor private warehouse. When the electric power marketing system pushes the mirror image to the mirror image warehouse. Each image is labeled and not covered with the last image, so that each image has an identifier, and if a program fails, the program can be quickly rolled back to the previous image. If the label is the same label each time, the original mirror image package is covered each time, so that the program cannot be quickly returned once a problem occurs.
In a further preferred but non-limiting embodiment of the present invention, the Docker container mirror image is pushed into a Harbor mirror image library, and the electric power marketing system separately builds a base mirror image warehouse and an application program mirror image warehouse, where the base mirror image is the most basic mirror image from the building of the application program mirror image, and is customized on the basis of one mirror image, which is the base mirror image, for example, a mirror image of a Java application is built, and a mirror image of an Oracle JDK is selected as the base mirror image. The application program mirror image refers to a mirror image manufactured by jar of the power marketing system, and the warehouses are separately built, so that the downloading bottleneck of a multi-node single-mirror-image warehouse can be solved, and the pressure is reduced.
And 4, pulling the Docker container mirror image of the required environment by configuring Kubernets.
It is worth noting that kubernets, K8s for short, is a container orchestration management system for managing containerized applications on multiple hosts in a cloud platform, making deploying containerized applications simple and efficient, and providing mechanisms for application deployment, planning, updating, and maintenance.
In a preferred but non-limiting embodiment of the invention, the mirror is pulled by the mirror pull policy and mirror address defined in the YAML file. The mirror image pull strategy has three modes: whether the local exists or not, the mirror image is pulled; if the local mirror image exists locally, the local mirror image is used for not pulling; only the local image is used to never pull, even if not locally.
In a further preferred but non-limiting embodiment of the invention, the electricity marketing system is adapted to pull the mirror image from the repository regardless of whether the mirror image is present locally or not, which is done to ensure that the mirror image file is up-to-date, and to avoid the occurrence of a non-up-to-date mirror image package that would render the updated service inoperative.
And 5, starting the Docker container mirror image pulled by the k8s in a standard mirror image starting mode.
In a preferred but non-limiting embodiment of the present invention, building a container image startup profile comprises: the configuration file adopts YAML file format, and describes the packaging association relationship of the container mirror image, the host port and the container mirror image packaging port used by the container mirror image, the API interface package used by the start environment, the content type of the described object, the name of the content object related to the container mirror image, and the configuration content of the description parameters of the content object.
The K8s can quickly pull up the instance according to the configuration information of the start configuration file, wherein the instance refers to the container service which runs according to the Docker container mirror image. The number of instances here can be freely configured, and K8s will always maintain the configured number of instances.
When a new mirror image package is pushed to a warehouse to be deployed, the management interface of the K8S is clicked for redeploying, the K8S can pull up the instances of the new mirror image according to the number of the configured instances, and then kills the running instances of the original mirror image, so that the number of the configured instances is maintained.
Compared with the prior art, the containerized electric power marketing system deployment method has the advantages that the containers are isolated from one another, each container has the own file system, processes among the containers cannot influence one another, and computing resources can be distinguished. Since the container is decoupled from the underlying infrastructure, the machine file system, it can be migrated between different clouds, different versions of the operating system. The deployment is safe and convenient, the isolation is good, the rapid rollback can be realized, and the cost is low.
The present applicant has described and illustrated embodiments of the present invention in detail with reference to the accompanying drawings, but it should be understood by those skilled in the art that the above embodiments are merely preferred embodiments of the present invention, and the detailed description is only for the purpose of helping the reader to better understand the spirit of the present invention, and not for limiting the scope of the present invention, and on the contrary, any improvement or modification made based on the spirit of the present invention should fall within the scope of the present invention.
Claims (10)
1. A containerized electric power marketing system deployment method, comprising:
step 1, constructing a JAR file of a power marketing system in a development environment;
step 2, generating a Docker container mirror image of the power marketing system in a maker on the basis of the JAR file of the power marketing system;
step 3, pushing the Docker container mirror image into a Harbor mirror image library;
step 4, drawing a Docker container mirror image of a required environment by configuring Kubernets;
and 5, starting the Docker container mirror image pulled by the k8s in a standard mirror image starting mode.
2. The containerized electric power marketing system deployment method of claim 1,
in the step 1, the specific steps of constructing the JAR file of the power marketing system in the development environment comprise: respectively generating JAR files of a development environment, a test environment and a production environment by using a terminal in the development environment;
the JAR file in each environment of the power marketing system specifically comprises: the system comprises a system end front end service, a client module back end service and a contract module back end service.
3. The containerized electric power marketing system deployment method of claim 2,
the step 1 specifically comprises the following steps:
step 1.1, cleaning the existing catalogue by using a cleaning plug-in;
step 1.2, the resource plug-in is used for executing the processing of the resource file;
step 1.3, compiling all source files by using a compiling plug-in to generate byte code files;
step 1.4, using the resource plug-in to execute the processing of the test resource file;
step 1.5, compiling all source codes under a test directory by using a compiling plug-in;
step 1.6, using a plug-in to run a test case;
and step 1.7, packaging the files generated after compiling in the step 1.3 and the step 1.5 by using plug-ins.
4. The containerized electric power marketing system deployment method of claim 3,
in step 2, generating a Docker container mirror image in a maker based on a JAR file of the power marketing system specifically includes: automatically packaging system end front-end services, customer module back-end services and contract module back-end services of JAR files of the development environment, the test environment and the production environment in the step 1 into a Docker container mirror image standardized environment deployment by reading instructions in Dockerfile, wherein the containers use a sandbox mechanism and do not have any interfaces; the Dockerfile instruction includes: basic mirror image information, maintainer information, mirror image operation instructions and container execution instructions when starting.
5. The containerized electric power marketing system deployment method of claim 4,
in step 2, creating a mirror image of the electricity marketing system based on the configuration file, specifically comprising:
step 2.1, establishing a catalog as a working catalog for generating a working mirror image;
step 2.2, creating and compiling a configuration file;
step 2.3: compiling the content of an execution script;
step 2.4, a test page is created;
and 2.5, generating an image by using the configuration file.
6. The containerized power marketing system deployment method of claim 5,
in step 2.2, the content defined by the configuration file includes: the method includes the steps of base mirroring, maintaining user information of the mirroring, mirror operation instruction installation, port exposure, copying execution scripts into the mirroring, and scripts executed when a container is started.
7. The containerized electric power marketing system deployment method of claim 6,
in step 3, pushing the Docker container mirror image to the Harbor mirror image library specifically comprises: pushing the Docker container mirror generated by Dokcerfile into the Harbor private warehouse.
8. The containerized electric power marketing system deployment method of claim 1,
in step 4, the mirror image is pulled through the mirror image pulling strategy and the mirror image address defined in the YAML file.
9. The containerized power marketing system deployment method of claim 8,
in step 4, the mirror image pulling mode comprises: pulling the mirror image regardless of whether the mirror image exists locally or not; if local exists, the local mirror image is used for not pulling; only the local image is used to never pull, even if not locally.
10. The containerized electric power marketing system deployment method of claim 1,
in step 5, constructing a container mirror image starting configuration file comprises: the configuration file describes the packaging association relationship of the container mirror image, a host port and a container mirror image packaging port used by the container mirror image, an API (application programming interface) package used by a starting environment, the content type of the described object, the name of the content object related to the container mirror image, and the configuration content of the description parameters of the content object.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210840636.1A CN115145604A (en) | 2022-07-18 | 2022-07-18 | Containerized electric power marketing system deployment method |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202210840636.1A CN115145604A (en) | 2022-07-18 | 2022-07-18 | Containerized electric power marketing system deployment method |
Publications (1)
Publication Number | Publication Date |
---|---|
CN115145604A true CN115145604A (en) | 2022-10-04 |
Family
ID=83411239
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202210840636.1A Pending CN115145604A (en) | 2022-07-18 | 2022-07-18 | Containerized electric power marketing system deployment method |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN115145604A (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115495148A (en) * | 2022-11-17 | 2022-12-20 | 深圳代码兄弟技术有限公司 | Low-code program based deployment package unified construction management method and system |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110109680A (en) * | 2019-05-14 | 2019-08-09 | 重庆商勤科技有限公司 | Using dispositions method, device and apply dissemination method, server, storage medium |
CN111399865A (en) * | 2020-04-21 | 2020-07-10 | 贵州新致普惠信息技术有限公司 | Method for automatically constructing target file based on container technology |
WO2021217871A1 (en) * | 2020-04-28 | 2021-11-04 | 平安科技(深圳)有限公司 | Method and apparatus for deploying micro service cluster, computer device and storage medium |
CN113779477A (en) * | 2021-09-13 | 2021-12-10 | 科大国创云网科技有限公司 | Assembly line publishing method and system based on PaaS cloud platform |
-
2022
- 2022-07-18 CN CN202210840636.1A patent/CN115145604A/en active Pending
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110109680A (en) * | 2019-05-14 | 2019-08-09 | 重庆商勤科技有限公司 | Using dispositions method, device and apply dissemination method, server, storage medium |
CN111399865A (en) * | 2020-04-21 | 2020-07-10 | 贵州新致普惠信息技术有限公司 | Method for automatically constructing target file based on container technology |
WO2021217871A1 (en) * | 2020-04-28 | 2021-11-04 | 平安科技(深圳)有限公司 | Method and apparatus for deploying micro service cluster, computer device and storage medium |
CN113779477A (en) * | 2021-09-13 | 2021-12-10 | 科大国创云网科技有限公司 | Assembly line publishing method and system based on PaaS cloud platform |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN115495148A (en) * | 2022-11-17 | 2022-12-20 | 深圳代码兄弟技术有限公司 | Low-code program based deployment package unified construction management method and system |
CN115495148B (en) * | 2022-11-17 | 2023-09-22 | 深圳代码兄弟技术有限公司 | Unified construction management method and system for deployment package based on low-code program |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11435986B2 (en) | Containerized deployment of microservices based on monolithic legacy applications | |
KR102370568B1 (en) | Containerized deployment of microservices based on monolithic legacy applications | |
CN107577475B (en) | Software package management method and system of data center cluster system | |
CN101470621B (en) | Virtual machine configuration system | |
US8255363B2 (en) | Methods, systems, and computer program products for provisioning software using dynamic tags to identify and process files | |
US8924930B2 (en) | Virtual machine image lineage | |
US20100325624A1 (en) | Method and System for Application Portability | |
US8464246B2 (en) | Automation of mainframe software deployment | |
CN111399865A (en) | Method for automatically constructing target file based on container technology | |
CN110088733A (en) | The layout based on accumulation layer of virtual machine (vm) migration | |
US20060282479A1 (en) | Methods, systems, and computer program products for provisioning software using local changesets that represent differences between software on a repository and a local system | |
US20190114165A1 (en) | Using semantic annotations to control compatibility behaviors | |
CN111930465A (en) | Kubernetes-based dreams master-slave cluster deployment method and device | |
CN109240716B (en) | Big data platform version management and rapid iterative deployment method and system | |
US11762639B2 (en) | Containerized deployment of microservices based on monolithic legacy applications | |
US20230259358A1 (en) | Documentation enforcement during compilation | |
CN115145604A (en) | Containerized electric power marketing system deployment method | |
CN111273960A (en) | Method for realizing cloud native MIPS architecture container cloud | |
CN113407257A (en) | Mysql cluster deployment method and device, electronic equipment and storage medium | |
CN113821228B (en) | Method for constructing ROS or ROS-like project based on layered container mirror image | |
Sethi et al. | Rapid deployment of SOA solutions via automated image replication and reconfiguration | |
US20230093197A1 (en) | Generating executables for target operational environments | |
US20240069883A1 (en) | Deriving a container from a package set | |
Neto | A Container-based architecture for accelerating software tests via setup state caching and parallelization | |
CN115509852A (en) | Method, system, equipment and medium for publishing database monitoring operation and maintenance software |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20221004 |
|
RJ01 | Rejection of invention patent application after publication |