SpringCloud微服务实战——搭建企业级开发框架（三十四）：SpringCloud + Docker + k8s实现微服务集群打包部署-打包配置
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
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
spring:
profiles: dev
nacos:
addr: 127.0.0.1:8848
config:
prefix: gitegg-cloud-config
group: GITEGG_CLOUD
spring:
profiles: test
nacos:
addr: 测试地址:8848
config:
prefix: gitegg-cloud-config
group: GITEGG_CLOUD
spring:
profiles: prod
nacos:
addr: 生产地址:8848
config:
prefix: gitegg-cloud-config
group: GITEGG_CLOUD
上面的配置可以满足分环境打包读取不同配置文件的目的，但是在实际开发过程中我们发现，我们的微服务太多，如果要修改Nacos配置的话，每个微服务的配置文件都需要修改一遍，虽然可以用IDEA批量替换，但是感觉这不是很好的方式。我们理想的方式是这样的：
- 所有的微服务配置文件默认都从一个统一的地方读取
- 当有某一个微服务需要特殊的配置时，只需要修改它自己的配置文件即可
实现上面的方式，我们可以将Nacos的配置到放到Maven的profile中，不同环境的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
spring:
profiles: dev
nacos:
addr: @nacos.addr@
config:
prefix: @nacos.config.prefix@
group: @nacos.config.group@
spring:
profiles: test
nacos:
addr: @nacos.addr@
config:
prefix: @nacos.config.prefix@
group: @nacos.config.group@
spring:
profiles: prod
nacos:
addr: @nacos.addr@
config:
prefix: @nacos.config.prefix@
group: @nacos.config.group@
true
dev
dev
1127.0.0.1:8848
gitegg-cloud-config
GITEGG_CLOUD
test
test
测试环境地址:8848
gitegg-cloud-config
GITEGG_CLOUD
prod
prod
生产环境地址:8848
gitegg-cloud-config
GITEGG_CLOUD
这样，通过在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里配置如下：
1.8
3.8.1
UTF-8
${project.name}
src/main/resources
true
**/*.jks
src/main/resources
false
**/*.jks
src/main/java
**/*.xml
org.apache.maven.plugins
maven-compiler-plugin
${maven.plugin.version}
${java.version}
${java.version}
${maven.compiler.encoding}
-parameters
org.springframework.boot
spring-boot-maven-plugin
${spring.boot.version}
true
${project.build.finalName}
repackage
org.springframework.boot
spring-boot-maven-plugin
org.apache.maven.plugins
maven-compiler-plugin
true
dev
dev
127.0.0.1:8848
gitegg-cloud-config
GITEGG_CLOUD
test
test
127.0.0.1:8848
gitegg-cloud-config
GITEGG_CLOUD
prod
prod
127.0.0.1:8848
gitegg-cloud-config
GITEGG_CLOUD
以上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如下：
......
3.1.4
......
......
com.google.cloud.tools
jib-maven-plugin
${jib.maven.plugin.version}
install
build
true
openjdk:8-jdk-alpine
${docker.harbor.addr}/${docker.harbor.project}/${project.artifactId}:${project.version}
${docker.harbor.username}
${docker.harbor.password}
-Xms512m
-Xmx4g
/giteggData
/gitegg
Asia/Shanghai
USE_CURRENT_TIMESTAMP
OCI
......
true
dev
dev
172.16.20.188:8848
gitegg-cloud-config
GITEGG_CLOUD
172.16.20.175
gitegg
robot$gitegg
Jqazyv7vvZiL6TXuNcv7TrZeRdL8U9n3
test
test
127.0.0.1:8848
gitegg-cloud-config
GITEGG_CLOUD
172.16.20.175
gitegg
robot$gitegg
Jqazyv7vvZiL6TXuNcv7TrZeRdL8U9n3
prod
prod
127.0.0.1:8848
gitegg-cloud-config
GITEGG_CLOUD
172.16.20.175
gitegg
robot$gitegg
Jqazyv7vvZiL6TXuNcv7TrZeRdL8U9n3
在需要docker打包的工程pom.xml里面添加插件引用
com.google.cloud.tools
jib-maven-plugin
在不需要docker打包的工程pom.xml里面需要配置skip=true
com.google.cloud.tools
jib-maven-plugin
true
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才能够解析@，如下所示：
src/main/resources
true
- 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"
GitEgg-Cloud是一款基于SpringCloud整合搭建的企业级微服务应用开发框架，开源项目地址:
Gitee: https://gitee.com/wmz1930/GitEgg
GitHub: https://github.com/wmz1930/GitEgg
欢迎感兴趣的小伙伴Star支持一下。