SpringCloud microservices contain multiple SpringBoot runnable applications. In a single application, the packaging and deployment during version release is relatively simple. When there are microservices of multiple applications, the original single application deployment method will appear complex and uncontrollable. Then we will think about using simple deployment methods to solve the problems of automatic publishing, automatic deployment, micro service monitoring and so on.
we use the current industry common solution, Jenkins+GitLab+Maven+Docker+Kubernetes, to realize the function of sustainable automatic deployment of microservices. The following will explain how to realize the sustainable automatic deployment function of spring cloud microservices from Maven packaging file configuration, Dockfile writing to Kubernetes configuration in the project.
1,bootstrap.yml file loading configuration in different environments
when the project is packaged and deployed, the configuration file of our system needs to distinguish the configuration of development, testing and production environments according to different environments. In the previous SpringBoot project, we used spring profiles. Active configuration properties, using application yml,application-dev.yml,application-test.yml,application-sit.yml,application-uat.yml, application-prod.yml to distinguish configuration files in different environments. In spring cloud, we use the Nacos registry. By default, the Nacos Config reads bootstrap YML configuration file, if the configuration of Nacos Config is written to application In YML, errors will be reported all the time when the project is started. The following is the order in which spring cloud loads configuration files:
- bootstrap.yml (bootstrap.properties) is loaded first. It is used for the boot phase of the application context. It can be used to configure the parameters used in application.yml and loaded by the parent Spring ApplicationContext.
- application. After loading YML (application.properties), it is used to configure the parameters used in each project module.
so in the spring cloud project, we use bootstrap YML, bootstrap dev.yml... And other configuration files are used to distinguish different environments. Some frameworks are placed in the same YML configuration file, and then different configurations are placed in different spring profiles. Active, similar to the following:
spring:
profiles: dev
Development configuration item: Development configuration item
spring:
profiles: test
Test configuration item: Test configuration item
However, in the actual development process, the configuration files we develop and test are often modified, and the production deployment environment is rarely changed. When multiple people develop, it is inevitable that some people inadvertently change the configuration file to affect the production environment configuration. Even if there is no impact, developers should be careful when changing, afraid of making mistakes. When we separate these configurations, no matter how the development and test configuration files are changed, they will not affect the production environment files, which is exactly the result we want. So we put the configurations of different environments into different configuration files. We divide the configuration file into bootstrap yml,bootstrap-dev.yml,bootstrap-test.yml,bootstrap-prod.yml
<!-- bootstrap.yml -->
server:
port: 8001
spring:
profiles:
active: @spring.profiles.active@
application:
name: @artifactId@
cloud:
nacos:
discovery:
server-addr: ${spring.nacos.addr}
config:
server-addr: ${spring.nacos.addr}
file-extension: yaml
prefix: ${spring.nacos.config.prefix}
group: ${spring.nacos.config.group}
enabled: true
<!-- bootstrap-dev.yml -->
spring:
profiles: dev
nacos:
addr: 127.0.0.1:8848
config:
prefix: gitegg-cloud-config
group: GITEGG_CLOUD
<!-- bootstrap-test.yml -->
spring:
profiles: test
nacos:
addr: Test address:8848
config:
prefix: gitegg-cloud-config
group: GITEGG_CLOUD
<!-- bootstrap-prod.yml -->
spring:
profiles: prod
nacos:
addr: Production address:8848
config:
prefix: gitegg-cloud-config
group: GITEGG_CLOUD
the above configuration can meet the purpose of packaging and reading different configuration files by environment. However, in the actual development process, we found that there are too many micro services. If we want to modify the Nacos configuration, the configuration file of each micro service needs to be modified. Although it can be replaced in batch with IDEA, it doesn't feel that this is a good way. Our ideal way is this:
- All microservice configuration files are read from a unified place by default
- When a micro service needs special configuration, you only need to modify its own configuration file
To implement the above method, we can configure Nacos into Maven's profile and bootstrap in different environments YML can read the configuration information of its corresponding environment. The modified configuration is as follows:
<!-- bootstrap.yml -->
server:
port: 8001
spring:
profiles:
active: @spring.profiles.active@
application:
name: @artifactId@
cloud:
nacos:
discovery:
server-addr: ${spring.nacos.addr}
config:
server-addr: ${spring.nacos.addr}
file-extension: yaml
prefix: ${spring.nacos.config.prefix}
group: ${spring.nacos.config.group}
enabled: true
<!-- bootstrap-dev.yml -->
spring:
profiles: dev
nacos:
addr: @nacos.addr@
config:
prefix: @nacos.config.prefix@
group: @nacos.config.group@
<!-- bootstrap-test.yml -->
spring:
profiles: test
nacos:
addr: @nacos.addr@
config:
prefix: @nacos.config.prefix@
group: @nacos.config.group@
<!-- bootstrap-prod.yml -->
spring:
profiles: prod
nacos:
addr: @nacos.addr@
config:
prefix: @nacos.config.prefix@
group: @nacos.config.group@
<!-- pom.xml -->
<profiles>
<profile>
<activation>
<!--Default to dev Environment packaging method-->
<activeByDefault>true</activeByDefault>
</activation>
<id>dev</id>
<properties>
<spring.profiles.active>dev</spring.profiles.active>
<nacos.addr>1127.0.0.1:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
</properties>
</profile>
<profile>
<id>test</id>
<properties>
<spring.profiles.active>test</spring.profiles.active>
<nacos.addr>Test environment address:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
</properties>
</profile>
<profile>
<id>prod</id>
<properties>
<spring.profiles.active>prod</spring.profiles.active>
<nacos.addr>Production environment address:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
</properties>
</profile>
</profiles>
In this way, through the POM The configuration of different profile s in XML can be modified once, so that all microservices can read the configuration files of Nacos and modify them at the same time.
after the modification, you may have such doubts: now we have three files, bootstrap-dev.yml and bootstrap-test The content configurations of YML and bootstrap-prod.yml are basically the same. Only the values of profiles are different, they can be written directly in bootstrap YML a file, through POM XML to configure and distinguish different environments. The purpose and significance of this work: it is mainly for subsequent extensible customization and specific configuration of an environment.
2. Maven packaging configuration
Writing POM Before XML, let's first understand the differences and connections of several common Maven packaging plug-ins:
- Maven compiler plugin: used to add customized parameters in the compile phase, such as setting the jdk version of the project source code, the compiled jdk version, and the project code.
- maven jar plugin: the maven project is converted into a jar package, which provides the configuration of manifest. The generated jar package generally stores The configuration in the class file and resources directory will not package the dependent jar package into a runnable jar package.
- Spring boot Maven plugin: in Maven's package life cycle stage, it can package the software package generated by mvn package into executable software package again, and rename the software package generated by mvn package to * original. Its main function is to package the SpringBoot project code and dependent jar packages into executable jar or war files, which can be run directly in the jre environment.
because the jar packaged by Maven jar plugin puts the packaged jar and lib in the same directory instead of being packaged into one package, the jar package file is very small. Spring boot Maven plugin packaging is to make the jar package of Maven jar plugin and the dependency library repackage a runnable jar package. The jar package file is very large. Considering the network factors during system upgrade, it is best to use Maven jar plugin. When the dependency library does not change, only a small jar package can be upgraded. Because it is an enterprise level microservice application development framework, regardless of the impact of network transmission and the stability of system upgrade, it is not possible to rely on the library to modify the version during development, while the production environment depends on the library version upgrade, which will affect all microservices. Therefore, we choose to use the spring boot Maven plugin plug-in for packaging.
in the parent POM of GitEgg project XML is configured as follows:
<properties>
<!-- jdk Version 1.8 -->
<java.version>1.8</java.version>
<!-- maven-compiler-plugin Plug in version, Java Code compilation -->
<maven.plugin.version>3.8.1</maven.plugin.version>
<!-- maven Specify encoding at compile time UTF-8 -->
<maven.compiler.encoding>UTF-8</maven.compiler.encoding>
</properties>
<build>
<finalName>${project.name}</finalName>
<resources>
<!-- Add sub environment read configuration -->
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
<excludes>
<exclude>**/*.jks</exclude>
</excludes>
</resource>
<!-- Solve jks filtered problems -- >
<resource>
<directory>src/main/resources</directory>
<filtering>false</filtering>
<includes>
<include>**/*.jks</include>
</includes>
</resource>
<resource>
<directory>src/main/java</directory>
<includes>
<include>**/*.xml</include>
</includes>
</resource>
</resources>
<pluginManagement>
<plugins>
<!-- Used when compiling( compile)Add customized parameters in the phase, such as setting the source code of the project jdk Version, compiled jdk Version, project code, etc -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven.plugin.version}</version>
<configuration>
<source>${java.version}</source>
<target>${java.version}</target>
<encoding>${maven.compiler.encoding}</encoding>
<compilerArgs>
<arg>-parameters</arg>
</compilerArgs>
</configuration>
</plugin>
<!-- Can Spring Boot The application is packaged as executable jar or war File, and then run in the usual way Spring Boot application -->
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>${spring.boot.version}</version>
<configuration>
<fork>true</fork>
<finalName>${project.build.finalName}</finalName>
</configuration>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
</plugin>
</plugins>
</build>
<profiles>
<profile>
<activation>
<!--Default to dev Environment packaging method-->
<activeByDefault>true</activeByDefault>
</activation>
<id>dev</id>
<properties>
<spring.profiles.active>dev</spring.profiles.active>
<nacos.addr>127.0.0.1:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
</properties>
</profile>
<profile>
<id>test</id>
<properties>
<spring.profiles.active>test</spring.profiles.active>
<nacos.addr>127.0.0.1:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
</properties>
</profile>
<profile>
<id>prod</id>
<properties>
<spring.profiles.active>prod</spring.profiles.active>
<nacos.addr>127.0.0.1:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
</properties>
</profile>
</profiles>
after the Maven configuration above is completed, you can print the runnable SpringBoot package normally. Generally, if docker and k8s cluster are not used, Jenkins can be directly used to package and deploy to the test or production environment.
next, we will introduce step by step how to package micro services into Docker files, publish them to Docker image warehouse private server Harbor, and k8s pull Docker files from private server Harbor for distributed deployment.
- Docker: an open source application container engine, which packages applications and dependent packages into a portable image, and can be released to any popular Linux or Windows operating system.
- Harbor: different from the public image warehouse officially provided by Docker, it can be used for the private Docker image warehouse deployed locally.
- Kubernetes(k8s): an open source system used to automatically deploy, expand and manage container applications. It can be freely deployed within the enterprise, private cloud, hybrid cloud or public cloud
3. Docker packaging configuration
at present, there are many instructions for using docker packaging plug-ins on the Internet. Spotify's open source plug-ins explain the most. Spotify officials no longer recommend using docker made plugin for packaging, but recommend its latest docker packaging plug-in Dockerfile made plugin. However, Dockerfile made plugin has not been updated for a long time and has limitations in use, For example, only build, tag and push images of docker on the local machine are supported. After searching on the Internet, we found that Google's open source Jib plug-in has more powerful functions. It can realize docker packaging without writing Dockerfile and installing docker environment locally, and it has been updated all the time. Therefore, we choose this plug-in as our docker packaging plug-in.
SpringBoot packaging will package all dependency and resource files together to generate a Fat Jar. The file size of this Fat Jar is often as high as 100 megabytes. If it is subject to the network environment, the transmission will be slow when publishing; At the same time, after publishing multiple times, it will occupy a lot of disk space. In particular, under the microservice architecture, there will be a pile of far jars. Then, we can use the hierarchical structure feature of Docker image to package the public dependencies of the application into the source image layer. When publishing the application, we only publish the code of the business modification layer. The following describes how Jib (Jib Maven plugin) packs SpringBoot applications into Docker images in layers, makes full use of Docker's image layered reuse mechanism, and solves the problems of network constraints and occupying a lot of disk space.
There are three parameters built by Jib (Jib Maven plugin):
-
buildTar: build locally. You can generate a tar file from the image without Docker daemon and save it in the target directory of the project
-
dockerBuild: save the built image to the Docker daemon of the current environment
-
build: push the built image to remote warehouse, official warehouse or Harbor private warehouse
-
In the parent POM of GitEgg project Configure the jib Maven plugin in XML as follows:
<properties>
......
<!-- jib-maven-plugin Plug in version, code packaging docker -->
<jib.maven.plugin.version>3.1.4</jib.maven.plugin.version>
......
</properties>
<pluginManagement>
<plugins>
......
<!-- Docker Package plug-ins -->
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>${jib.maven.plugin.version}</version>
<!-- Bind to Maven of install Lifecycle, if not used here https，There will be problems and need to be set sendCredentialsOverHttp=true-->
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>build</goal>
</goals>
</execution>
</executions>
<configuration>
<!--Allow non https-->
<allowInsecureRegistries>true</allowInsecureRegistries>
<!-- amount to Docerkfile Medium FROM -->
<from>
<image>openjdk:8-jdk-alpine</image>
</from>
<to>
<image>${docker.harbor.addr}/${docker.harbor.project}/${project.artifactId}:${project.version}</image>
<auth>
<username>${docker.harbor.username}</username>
<password>${docker.harbor.password}</password>
</auth>
</to>
<container>
<!--jvm Memory parameters-->
<jvmFlags>
<jvmFlag>-Xms512m</jvmFlag>
<jvmFlag>-Xmx4g</jvmFlag>
</jvmFlags>
<volumes>/giteggData</volumes>
<workingDirectory>/gitegg</workingDirectory>
<environment>
<TZ>Asia/Shanghai</TZ>
</environment>
<!--Use this parameter to ensure that the creation time of the image is consistent with the system time-->
<creationTime>USE_CURRENT_TIMESTAMP</creationTime>
<format>OCI</format>
</container>
</configuration>
</plugin>
</plugins>
</pluginManagement>
......
<profiles>
<profile>
<activation>
<!--Default to dev Environment packaging method-->
<activeByDefault>true</activeByDefault>
</activation>
<id>dev</id>
<properties>
<spring.profiles.active>dev</spring.profiles.active>
<nacos.addr>172.16.20.188:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
<docker.harbor.addr>172.16.20.175</docker.harbor.addr>
<docker.harbor.project>gitegg</docker.harbor.project>
<docker.harbor.username>robot$gitegg</docker.harbor.username>
<docker.harbor.password>Jqazyv7vvZiL6TXuNcv7TrZeRdL8U9n3</docker.harbor.password>
</properties>
</profile>
<profile>
<id>test</id>
<properties>
<spring.profiles.active>test</spring.profiles.active>
<nacos.addr>127.0.0.1:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
<docker.harbor.addr>172.16.20.175</docker.harbor.addr>
<docker.harbor.project>gitegg</docker.harbor.project>
<docker.harbor.username>robot$gitegg</docker.harbor.username>
<docker.harbor.password>Jqazyv7vvZiL6TXuNcv7TrZeRdL8U9n3</docker.harbor.password>
</properties>
</profile>
<profile>
<id>prod</id>
<properties>
<spring.profiles.active>prod</spring.profiles.active>
<nacos.addr>127.0.0.1:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
<docker.harbor.addr>172.16.20.175</docker.harbor.addr>
<docker.harbor.project>gitegg</docker.harbor.project>
<docker.harbor.username>robot$gitegg</docker.harbor.username>
<docker.harbor.password>Jqazyv7vvZiL6TXuNcv7TrZeRdL8U9n3</docker.harbor.password>
</properties>
</profile>
</profiles>
In the project POM that needs to be packaged by docker Add plug-in reference in XML
<build>
<plugins>
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
In projects that do not require docker packaging, POM skip=true needs to be configured in XML
<build>
<plugins>
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<configuration>
<!--This module is not executable jar Bag, ordinary jar Just pack-->
<skip>true</skip>
</configuration>
</plugin>
</plugins>
</build>
Docker local image tar package command:
clean package -Ptest jib:buildTar -f pom.xml
The docker push es the image to the local docker command:
clean package -Ptest jib:dockerBuild -f pom.xml
The Docker push es the image to the remote image warehouse command:
clean package -Ptest jib:build -Djib.httpTimeout=200000 -DsendCredentialsOverHttp=true -f pom.xml
the construction of Jib (Jib maven plugin) can be bound to maven life cycle. In the above example, it has been bound to maven install life cycle. In actual use, due to security considerations, it does not support http to send user name and password, and sendCredentialsOverHttp=true needs to be set.
common problem
- In bootstrap Unable to read @ spring. In YML profiles. Active @, and the prompt found character '@' that cannot start any token
Solution: if spring boot starter parent is not specified in the project, resources - > resource - > filtering must be set to true to resolve @, as shown below:
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
- As a platform jar package, gitegg platform does not need to type a docker file. The gitegg platform jar package will be introduced when gitegg cloud is packaged, so the above configuration only needs to be configured under gitegg cloud project.
- When deploying yaml for K8S, Jenkins script will first read whether the sub project has yaml configured for deployment. If so, it will be used. If not, it will read the deployment yaml under the root directory.
apiVersion: apps/v1
kind: Deployment
metadata:
name: {APP_NAME}-deployment
labels:
app: {APP_NAME}
spec:
replicas: 1
revisionHistoryLimit: 3
selector:
matchLabels:
app: {APP_NAME}
template:
metadata:
labels:
app: {APP_NAME}
spec:
hostNetwork: true
containers:
- name: {APP_NAME}
image: {IMAGE_URL}/{IMAGE_PROGECT}/{APP_NAME}:{IMAGE_TAG}
imagePullPolicy: Always
resources:
limits:
cpu: 300m
memory: 500Mi
requests:
cpu: 100m
memory: 100Mi
ports:
- containerPort: {APP_PORT}
env:
- name: SPRING_PROFILES_ACTIVE
value: {SPRING_PROFILE}
imagePullSecrets:
- name: harbor-key
---
kind: Service
apiVersion: v1
metadata:
name: {APP_NAME}-service
labels:
app: {APP_NAME}
spec:
selector:
app: {APP_NAME}
ports:
- protocol: TCP
port: {APP_PORT}
targetPort: {APP_PORT}
- docker installation startup command
docker pull 172.16.20.175/gitegg/gitegg-service-system:1.0-SNAPSHOT # --restart=always restarts automatically, / opt/gitegg is where the jar package is configured to run docker run -d imageId --restart=always --name=gitegg-service-system -p 8006:8006 /opt/gitegg # Check to see if it starts docker ps # view log docker logs --tail 100 -f gitegg-service-system
- Docker compose configuration startup
docker-compose up -d
- Docker uses the network in the container. It is used when the service registry Nacos is installed using docker compose. The address registered with Nacos is the ip in the docker container
......
networks:
- giteggNetworks
......
networks:
giteggNetworks:
driver: bridge
......
Complete yaml
version: '3'
services:
gitegg-service-system:
image: 172.16.20.175/gitegg/gitegg-service-system:1.0-SNAPSHOT
container_name: gitegg-service-system
ports:
- 8001:8001
volumes:
- "/data/gitegg/gateway/gitegg-service-system.jar:/app.jar"
- "/data/gitegg/gateway/logs:/logs"
logging:
options:
max-size: "100m"
networks:
- giteggNetworks
gitegg-service-base:
image: 172.16.20.175/gitegg/gitegg-service-base:1.0-SNAPSHOT
container_name: gitegg-service-base
ports:
- 8002:8002
volumes:
- "/data/gitegg/base/gitegg-service-base.jar:/app.jar"
- "/data/gitegg/base/logs:/logs"
networks:
- giteggNetworks
gitegg-oauth:
image: 172.16.20.175/gitegg/gitegg-oauth:1.0-SNAPSHOT
container_name: gitegg-oauth
ports:
- 8003:8003
volumes:
- "/data/gitegg/oauth/gitegg-oauth.jar:/app.jar"
- "/data/gitegg/oauth/logs:/logs"
networks:
- giteggNetworks
gitegg-service-extension:
image: 172.16.20.175/gitegg/gitegg-service-extension:1.0-SNAPSHOT
container_name: gitegg-service-extension
ports:
- 8005:8005
volumes:
- "/data/gitegg/extension/gitegg-service-extension.jar:/app.jar"
- "/data/gitegg/extension/logs:/logs"
networks:
- giteggNetworks
gitegg-code-generator:
image: 172.16.20.175/gitegg/gitegg-code-generator:1.0-SNAPSHOT
container_name: gitegg-code-generator
ports:
- 8006:8006
volumes:
- "/data/gitegg/generator/gitegg-code-generator:/app.jar"
- "/data/gitegg/generator/logs:/logs"
networks:
- giteggNetworks
gitegg-gateway:
image: 172.16.20.175/gitegg/gitegg-gateway:1.0-SNAPSHOT
container_name: gitegg-gateway
ports:
- 801:80
volumes:
- "/data/gitegg/gateway/gitegg-gateway:/app.jar"
- "/data/gitegg/gateway/logs:/logs"
networks:
- giteggNetworks
networks:
giteggNetworks:
driver: bridge
- Docker uses the host network and cannot be used simultaneously with the network in the container above. When the service registry Nacos is deployed separately, Nacos obtains the ip of the docker host
...... network_mode: "host" ......
Complete yaml, using network_ Mode: after "host", ports port mapping can no longer be used
version: '3'
services:
gitegg-service-system:
image: 172.16.20.175/gitegg/gitegg-service-system:1.0-SNAPSHOT
container_name: gitegg-service-system
network_mode: "host"
volumes:
- "/data/gitegg/gateway/gitegg-service-system.jar:/app.jar"
- "/data/gitegg/gateway/logs:/logs"
logging:
options:
max-size: "100m"
gitegg-service-base:
image: 172.16.20.175/gitegg/gitegg-service-base:1.0-SNAPSHOT
container_name: gitegg-service-base
network_mode: "host"
volumes:
- "/data/gitegg/base/gitegg-service-base.jar:/app.jar"
- "/data/gitegg/base/logs:/logs"
gitegg-oauth:
image: 172.16.20.175/gitegg/gitegg-oauth:1.0-SNAPSHOT
container_name: gitegg-oauth
network_mode: "host"
volumes:
- "/data/gitegg/oauth/gitegg-oauth.jar:/app.jar"
- "/data/gitegg/oauth/logs:/logs"
gitegg-service-extension:
image: 172.16.20.175/gitegg/gitegg-service-extension:1.0-SNAPSHOT
container_name: gitegg-service-extension
network_mode: "host"
volumes:
- "/data/gitegg/extension/gitegg-service-extension.jar:/app.jar"
- "/data/gitegg/extension/logs:/logs"
gitegg-code-generator:
image: 172.16.20.175/gitegg/gitegg-code-generator:1.0-SNAPSHOT
container_name: gitegg-code-generator
network_mode: "host"
volumes:
- "/data/gitegg/generator/gitegg-code-generator:/app.jar"
- "/data/gitegg/generator/logs:/logs"
gitegg-gateway:
image: 172.16.20.175/gitegg/gitegg-gateway:1.0-SNAPSHOT
container_name: gitegg-gateway
network_mode: "host"
volumes:
- "/data/gitegg/gateway/gitegg-gateway:/app.jar"
- "/data/gitegg/gateway/logs:/logs"
Gitegg cloud is an enterprise level microservice application development framework based on spring cloud integration. Open source project address:
Gitee: https://gitee.com/wmz1930/GitEgg
GitHub: https://github.com/wmz1930/GitEgg
Welcome interested partners Star to support.