SpringCloud微服务实战——搭建企业级开发框架(三十四):SpringCloud + Docker + k8s实现微服务集群打包部署-打包配置

本文涉及的产品
MSE Nacos/ZooKeeper 企业版试用,1600元额度,限量50份
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
简介: SpringCloud微服务包含多个SpringBoot可运行的应用程序,在单应用程序下,版本发布时的打包部署还相对简单,当有多个应用程序的微服务发布部署时,原先的单应用程序部署方式就会显得复杂且不可控。那么我们就会思考使用简单的部署方式,解决自动化发布、自动化部署、微服务监控等问题。

SpringCloud微服务包含多个SpringBoot可运行的应用程序,在单应用程序下,版本发布时的打包部署还相对简单,当有多个应用程序的微服务发布部署时,原先的单应用程序部署方式就会显得复杂且不可控。那么我们就会思考使用简单的部署方式,解决自动化发布、自动化部署、微服务监控等问题。


  我们使用目前行业通用的解决方案,Jenkins+GitLab+Maven+Docker+Kubernetes来实现可持续自动化部署微服务的功能。下面将从工程中Maven打包文件配置、Dockfile文件编写开始到Kubernetes配置来说明如何实现SpringCloud微服务可持续自动化部署功能。


1、bootstrap.yml文件不同环境加载配置


  在项目打包部署时,我们系统的配置文件需要根据不同的环境来区分开发、测试、生产环境的配置,在之前的SpringBoot工程中,我们用到spring.profiles.active配置属性,使用application.yml、application-dev.yml、application-test.yml、application-sit.yml、application-uat.yml、application-prod.yml来区分不同环境的配置文件。在SpringCloud中,我们用到了Nacos注册中心,Nacos的Config默认读取的是bootstrap.yml配置文件,如果将Nacos Config的配置写到application.yml里面,工程启动时就会一直报错。下面是SpringCloud加载配置文件的顺序:


  • bootstrap.yml(bootstrap.properties)先加载,用于应用程序上下文的引导阶段,可以用来配置application.yml中使用到的参数,由父Spring ApplicationContext加载。


  • application.yml(application.properties)后加载,用于配置各工程模块中使-用到的参数。


  所以在SpringCloud工程中我们通过使用bootstrap.yml、bootstrap-dev.yml...等不同的配置文件来区分不同的环境,有些框架是放到同一个yml配置文件中,然后不同的配置放到不同的spring.profiles.active下面,类似于下面这种:


spring:
  profiles: dev
     开发配置项: 开发配置项
spring:
  profiles: test
     测试配置项: 测试配置项


但是,在实际开发过程中,我们开发、测试的配置文件有时会经常修改,而生产部署环境确很少改动,当多人员开发时,难免会有部分人员不小心将配置文件改动影响到生产环境配置,即使没有影响,开发人员在改动时也要小心翼翼,害怕哪里改错。当我们将这些配置分开时,开发、测试的配置文件无论如何改动,都不会影响到生产环境文件,这正是我们想要的结果。所以我们将不同环境的配置放到不同的配置文件中。我们将配置文件分为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: 测试地址:8848
    config:
      prefix: gitegg-cloud-config
      group: GITEGG_CLOUD


<!-- bootstrap-prod.yml -->
spring:
  profiles: prod
  nacos:
    addr: 生产地址:8848
    config:
      prefix: gitegg-cloud-config
      group: GITEGG_CLOUD


  上面的配置可以满足分环境打包读取不同配置文件的目的,但是在实际开发过程中我们发现,我们的微服务太多,如果要修改Nacos配置的话,每个微服务的配置文件都需要修改一遍,虽然可以用IDEA批量替换,但是感觉这不是很好的方式。我们理想的方式是这样的:


  • 所有的微服务配置文件默认都从一个统一的地方读取


  • 当有某一个微服务需要特殊的配置时,只需要修改它自己的配置文件即可


实现上面的方式,我们可以将Nacos的配置到放到Maven的profile中,不同环境的bootstrap.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: @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>
                <!--默认为dev环境打包方式-->
                <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>测试环境地址: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>生产环境地址:8848</nacos.addr>
                <nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
                <nacos.config.group>GITEGG_CLOUD</nacos.config.group>
            </properties>
        </profile>
    </profiles>


这样,通过在pom.xml里面不同profile的配置,就可以实现修改一处,使所有微服务读取Nacos的配置文件同时修改。


  修改完之后,可能会有这样的疑惑:现在我们三个文件bootstrap-dev.yml、bootstrap-test.yml、bootstrap-prod.yml内容配置基本是一样的,只有profiles的值不同,那么实际可以直接写在bootstrap.yml一个文件中,通过pom.xml来配置区分不同环境即可。那么这里做的目的和意义:主要是为了后续可扩展定制,某个环境特定的配置。


2、Maven打包配置


在编写pom.xml之前,我们先了解一下几个常用Maven打包插件的区别和联系:


  • maven-compiler-plugin: 用于在编译(compile)阶段加入定制化参数,比如设置项目源码的jdk版本、编译的jdk版本,以及项目编码等。


  • maven-jar-plugin: 将maven工程打成 jar 包,提供了manifest的配置,生成jar包中一般存放的是.class文件和resources目录下的配置,不会将依赖的jar包打包成一个可运行的jar包。


  • spring-boot-maven-plugin: 其在Maven的package生命周期阶段,能够将mvn package生成的软件包,再次打包为可执行的软件包,并将mvn package生成的软件包重命名为*.original。 其主要作用就是将SpringBoot工程代码和依赖的jar包全部打包为可执行的jar或war文件,可以直接在jre环境下运行。


  因为maven-jar-plugin打包的jar是把打包的jar和lib放在同一目录下,不是打成一个包,所以这样打的jar包文件很小。spring-boot-maven-plugin打包是把maven-jar-plugin打的jar包和依赖库repackage一个可运行的jar包,这个jar包文件很大。如果考虑到系统升级时的网络因素,那么使用maven-jar-plugin是最好不过了,当依赖库不改变的时候,只升级很小的jar包即可。这里因为是企业级微服务应用开发框架,不考虑网络传输的影响,考虑系统升级稳定性,不至于开发时依赖库修改了版本,而生产环境依赖库版本升级导致所有微服务受到影响,所以我们选择使用spring-boot-maven-plugin插件进行打包。


  在GitEgg工程的父级pom.xml里配置如下:


<properties>
        <!-- jdk版本1.8 -->
        <java.version>1.8</java.version>
        <!-- maven-compiler-plugin插件版本,Java代码编译 -->
        <maven.plugin.version>3.8.1</maven.plugin.version>
        <!-- maven编译时指定编码UTF-8 -->
        <maven.compiler.encoding>UTF-8</maven.compiler.encoding>
    </properties>
    <build>
        <finalName>${project.name}</finalName>
        <resources>
            <!-- 增加分环境读取配置 -->
            <resource>
                <directory>src/main/resources</directory>
                <filtering>true</filtering>
                <excludes>
                    <exclude>**/*.jks</exclude>
                </excludes>
            </resource>
            <!-- 解决jks被过滤掉的问题 -->
            <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>
                <!-- 用于在编译(compile)阶段加入定制化参数,比如设置项目源码的jdk版本、编译的jdk版本,以及项目编码等 -->
                <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>
                <!-- 能够将Spring Boot应用打包为可执行的jar或war文件,然后以通常的方式运行Spring Boot应用 -->
                <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>
                <!--默认为dev环境打包方式-->
                <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>


  以上Maven配置完成之后,就可以进行正常的打可运行的SpringBoot包了。通常情况下,如果不使用docker和k8s集群,那么就可以直接使用Jenkins一键打包部署到测试或生产环境了。


  我们下面将一步步介绍如何实现将微服务打包为Docker文件,进而发布到Docker镜像仓库私服Harbor上,k8s拉取私服Harbor上的Docker文件进行分布式部署。


  • Docker: 开源的应用容器引擎,打包应用以及依赖包到一个可移植的镜像中,可以发布到任何流行的 Linux或Windows操作系统的机器上。


  • Harbor: 区别于Docker官方提供的公共的镜像仓库,可以用于本地部署的私有Docker镜像仓库。


  • Kubernetes(k8s): 用于自动部署,扩展和管理容器化应用程序的开源系统,可以自由地部署在企业内部,私有云、混合云或公有云


3、Docker打包配置


  目前,网上有多种Docker打包插件使用说明,讲解最多的是Spotify开源的,Spotify官方已不再推荐使用docker-maven-plugin插件进行打包,而是推荐其最新的docker打包插件dockerfile-maven-plugin,但是dockerfile-maven-plugin也已经很久没有更新了,在使用方面也有局限性,比如:只支持在本机Docker的镜像build、tag、push。经过在网上搜索,发现Google开源的Jib插件功能更强大,它可以不写Dockerfile,不需要在本地安装Docker环境就能实现Docker打包,而且一直在更新,所以这里选择这个插件作为我们的Docker打包插件。


  SpringBoot打包会将所有的依赖和资源文件等打包到一起,生成一个Fat Jar,这个Fat Jar的文件大小往往高达百兆,如果受制于网络环境,那么发布时,会传输较慢;同时,发布多次后,会占用大量的磁盘空间。尤其微服务架构下,会有一堆的Far Jar,那么,我们可以利用Docker镜像的分层结构特性,将应用程序的公共依赖打包为源镜像层,发布应用时,只发布业务修改层的代码。下面介绍Jib( jib-maven-plugin插件 )如何将SpringBoot应用程序分层打包Docker镜像,充分利用Docker的镜像分层复用机制,解决网络限制和占用大量磁盘空间的问题。


Jib( jib-maven-plugin插件 )构建的三个参数:


  • buildTar:本地构建,不需要Docker daemon就可以将镜像生成tar文件,保存在工程的target目录下


  • dockerBuild:将构建的镜像存到当前环境的Docker daemon


  • build:将构建的镜像推送到远程仓库,官方仓库或者Harbor私有仓库


  • 在GitEgg工程的父级pom.xml里配置jib-maven-plugin如下:


<properties>
......
        <!-- jib-maven-plugin插件版本,代码打包docker -->
        <jib.maven.plugin.version>3.1.4</jib.maven.plugin.version>
......
    </properties>
       <pluginManagement>
            <plugins>
......
                <!-- Docker 打包插件 -->
                <plugin>
                    <groupId>com.google.cloud.tools</groupId>
                    <artifactId>jib-maven-plugin</artifactId>
                    <version>${jib.maven.plugin.version}</version>
                    <!-- 绑定到Maven的install生命周期 ,此处如果不使用https,会有问题,需要设置sendCredentialsOverHttp=true-->
                    <executions>
                        <execution>
                            <phase>install</phase>
                            <goals>
                                <goal>build</goal>
                            </goals>
                        </execution>
                    </executions>
                    <configuration>
                        <!--允许非https-->
                        <allowInsecureRegistries>true</allowInsecureRegistries>
                        <!-- 相当于Docerkfile中的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内存参数-->
                            <jvmFlags>
                                <jvmFlag>-Xms512m</jvmFlag>
                                <jvmFlag>-Xmx4g</jvmFlag>
                            </jvmFlags>
                            <volumes>/giteggData</volumes>
                            <workingDirectory>/gitegg</workingDirectory>
                            <environment>
                                <TZ>Asia/Shanghai</TZ>
                            </environment>
                            <!--使用该参数保证镜像的创建时间与系统时间一致-->
                            <creationTime>USE_CURRENT_TIMESTAMP</creationTime>
                            <format>OCI</format>
                        </container>
                    </configuration>
                </plugin>
            </plugins>
        </pluginManagement>
......
    <profiles>
        <profile>
            <activation>
                <!--默认为dev环境打包方式-->
                <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>


在需要docker打包的工程pom.xml里面添加插件引用


<build>
        <plugins>
            <plugin>
                <groupId>com.google.cloud.tools</groupId>
                <artifactId>jib-maven-plugin</artifactId>
            </plugin>
        </plugins>
    </build>


在不需要docker打包的工程pom.xml里面需要配置skip=true


<build>
        <plugins>
            <plugin>
                <groupId>com.google.cloud.tools</groupId>
                <artifactId>jib-maven-plugin</artifactId>
                <configuration>
                    <!--此模块不打可执行的jar包,打普通jar包即可-->
                    <skip>true</skip>
                </configuration>
            </plugin>
        </plugins>
    </build>


Docker本地打镜像tar包命令:


clean package -Ptest jib:buildTar -f pom.xml


Docker把镜像push到本地docker命令:


clean package -Ptest jib:dockerBuild -f pom.xml


Docker把镜像push到远程镜像仓库命令:


clean package -Ptest jib:build -Djib.httpTimeout=200000 -DsendCredentialsOverHttp=true -f pom.xml


  Jib( jib-maven-plugin插件 )的构建可以绑定到maven生命周期,以上实例中,已经绑定到maven的install生命周期,在实际使用时,因为安全方面的考虑,不支持http发送用户名密码,需要设置sendCredentialsOverHttp=true。


常见问题


  • 在bootstrap.yml中无法读取@spring.profiles.active@,且提示found character '@' that cannot start any token.


解决:项目中如果没有指定spring-boot-starter-parent,resources->resource->filtering一定要设置为true才能够解析@,如下所示:


<build>
        <resources>
            <resource>
                <directory>src/main/resources</directory>
                <filtering>true</filtering>
            </resource>
        </resources>
    </build>


  • GitEgg-Platform作为平台jar包,不需要打docker文件,在GitEgg-Cloud打包时会引入GitEgg-Platform的jar包,所以上面的配置只需要在GitEgg-Cloud工程下配置。


  • K8S部署yaml,Jenkins脚本会首先读取子工程是否有配置部署的yaml,如果有则使用,如果没有则读取根目录下的部署yaml。


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安装启动命令


docker pull 172.16.20.175/gitegg/gitegg-service-system:1.0-SNAPSHOT
#  --restart=always 自动重新启动 , /opt/gitegg 是配置 jar包运行的位置
docker run -d imageId --restart=always --name=gitegg-service-system -p 8006:8006  /opt/gitegg
# 查看是否启动
docker ps
# 查看日志
docker logs --tail  100 -f  gitegg-service-system


  • docker-compose配置启动


docker-compose up -d


  • docker使用容器内网络,当服务注册中心Nacos使用docker-compose安装时使用,注册到Nacos的地址为docker容器内ip


......
    networks:
      - giteggNetworks
......
networks:
  giteggNetworks:
    driver: bridge
......


完整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使用宿主机网络,不能和上面的使用容器内网络同时使用。当服务注册中心Nacos单独部署时使用,Nacos获取到的是docker宿主机的ip


......
network_mode: "host"
......


完整yaml,使用了network_mode: "host"之后,不能再使用ports端口映射


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"


相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
kde
|
8天前
|
应用服务中间件 网络安全 nginx
手把手教你使用 Docker 部署 Nginx 教程
本文详解Nginx核心功能与Docker部署优势,涵盖镜像拉取、容器化部署(快速、挂载、Compose)、HTTPS配置及常见问题处理,助力高效搭建稳定Web服务。
kde
245 4
|
7天前
|
应用服务中间件 Linux nginx
在虚拟机Docker环境下部署Nginx的步骤。
以上就是在Docker环境下部署Nginx的步骤。需要注意,Docker和Nginix都有很多高级用法和细节需要掌握,以上只是一个基础入门级别的教程。如果你想要更深入地学习和使用它们,请参考官方文档或者其他专业书籍。
41 5
kde
|
24天前
|
存储 NoSQL Redis
手把手教你用 Docker 部署 Redis
Redis是高性能内存数据库,支持多种数据结构,适用于缓存、消息队列等场景。本文介绍如何通过Docker快速拉取轩辕镜像并部署Redis,涵盖快速启动、持久化存储及docker-compose配置,助力开发者高效搭建稳定服务。
kde
443 7
|
12月前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
596 6
|
12月前
|
设计模式 Java API
微服务架构演变与架构设计深度解析
【11月更文挑战第14天】在当今的IT行业中,微服务架构已经成为构建大型、复杂系统的重要范式。本文将从微服务架构的背景、业务场景、功能点、底层原理、实战、设计模式等多个方面进行深度解析,并结合京东电商的案例,探讨微服务架构在实际应用中的实施与效果。
270 1
|
11月前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
859 69
从单体到微服务:如何借助 Spring Cloud 实现架构转型
|
安全 应用服务中间件 API
微服务分布式系统架构之zookeeper与dubbo-2
微服务分布式系统架构之zookeeper与dubbo-2
|
负载均衡 Java 应用服务中间件
微服务分布式系统架构之zookeeper与dubbor-1
微服务分布式系统架构之zookeeper与dubbor-1
|
11月前
|
运维 监控 持续交付
微服务架构解析:跨越传统架构的技术革命
微服务架构(Microservices Architecture)是一种软件架构风格,它将一个大型的单体应用拆分为多个小而独立的服务,每个服务都可以独立开发、部署和扩展。
2899 36
微服务架构解析:跨越传统架构的技术革命

热门文章

最新文章

下一篇
开通oss服务