之后的文章我不会去将一整个流程的实现步骤和代码记录，更多的是记录一些想法和心得
问题一：为什么要用jenkins+docker自动化部署？
主要是去减少手动运维的工作量。
问题二：为什么要去选择jenkins+docker？
这是比较流行的一套，文档比较多;并不是说去中意这些框架而是中意这套解决方案带来的效应和功能。
实现思路
分为俩大部分，jenkins与docker
jenkins
jenkins在这一套里面担任很重要的角色，甚至在没有docker的情况，通过jenkinsfile都能实现自动化部署
jenkins安装
docker下jenkins的安装：
https://www.cnblogs.com/fuzongle/p/12834080.html
jenkins优势
引用公司大牛跟我所说，jenkins最大的优点就是他的组件，组件很多对各个平台的兼容也就很大。
构建方案
我选择的构建方案是 本地push->git仓库-> jenkins发现push开始构建 ->推送至目标服务器。还有什么隔1小时推送一次的都可以看看，看是否适合。
jenkins对docker的支持
借用网上一位大哥的图。
我目前并未去使用这些组件，我直接用脚本构建docker，这个可以往后安排。
Docker
优点
环境解耦，分离。
环境环境环境，优势就是环境以及快速部署。
在传统的操作下，环境一致性，环境不同之间迁移问题非常让人头疼，而这docker就很大程度的解决了这些问题。
缺点
对服务器内存有要求，并且微服务下更加。
Docker与jenkins的交互
完整的交互如图
参考。
https://blog.csdn.net/xiaoxiangzi520/article/details/88842200
这样jenkins一次构建后，目标服务器只需要拉取镜像生成容器即可。
8.1更新
方案更新
git推送->jenkins依靠dockerFile构建docker镜像、将docker镜像推送至镜像仓库、依靠docker-compose文件对微服务同意docker-compose down并docker-compose up -d、更新前端文件夹
这样比之前的步骤少了很多，能交给应用执行的就可以应用执行；并且是把jenkins放到了本地，因为目前就个人使用；使用了这套流程快半个月了，很稳定；
这个镜像仓库我用的是阿里云的个人版，目前够用，这个镜像仓库就把他当成github那样的代码库一样，他也有类似github的应用，这个搭建成本大我就没有去搭建了不适合；
问题
我目前是有俩个docker-compose文件、一个是所有微服务的每次推送都会重启的，一个是环境的docker-compose；
我就只放微服务的给个参考了
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
| version: '3.8'
services:
eureka-server:
image: registry.cn-zhangjiakou.aliyuncs.com/zhaoyuan_image/eureka-server:latest
container_name: eureka-server
environment:
- JVM_OPTS=-Xms56m -Xmx56m
restart: always
ports:
- 8880:8880
networks:
netName:
ipv4_address: 192.20.0.11
config-server:
image: registry.cn-zhangjiakou.aliyuncs.com/zhaoyuan_image/config-server:latest
environment:
- JVM_OPTS=-Xms300m -Xmx300m
restart: always
container_name: config-server
ports:
- 30870:8870
networks:
netName:
ipv4_address: 192.20.0.5
libary-auth:
image: registry.cn-zhangjiakou.aliyuncs.com/zhaoyuan_image/libary-auth:latest
environment:
- JVM_OPTS=-Xms512m -Xmx512m
container_name: libary-auth
ports:
- 30100:8100
networks:
netName:
ipv4_address: 192.20.0.6
restart: always
libary-eureka-device:
image: registry.cn-zhangjiakou.aliyuncs.com/zhaoyuan_image/libary-eureka-device:latest
environment:
- JVM_OPTS=-Xms512m -Xmx512m
container_name: libary-eureka-device
ports:
- 30083:8083
networks:
netName:
ipv4_address: 192.20.0.8
restart: always
libary-eureka-user:
image: registry.cn-zhangjiakou.aliyuncs.com/zhaoyuan_image/libary-eureka-user:latest
environment:
- JVM_OPTS=-Xms512m -Xmx512m
container_name: libary-eureka-user
ports:
- 30081:8081
networks:
netName:
ipv4_address: 192.20.0.10
restart: always
networks:
netName:
driver: bridge
ipam:
driver: default
config:
- subnet: 192.20.0.0/16
|
容器内微服务网络问题
微服务间免不了有相互的通讯，这个时候就牵扯到一个网络问题。当你每个微服务的网络都是独立的，你又不想每个微服务都给个公共端口提供的话，就得将这些微服务集合到一起：
定义网关：
1
2
3
4
5
6
7
| networks:
netName:
driver: bridge
ipam:
driver: default
config:
- subnet: 192.20.0.0/16
|
指定网络
1
2
3
4
5
6
7
8
9
10
11
| libary-eureka-user:
image: registry.cn-zhangjiakou.aliyuncs.com/zhaoyuan_image/libary-eureka-user:latest
environment:
- JVM_OPTS=-Xms512m -Xmx512m
container_name: libary-eureka-user
ports:
- 30081:8081
networks:
netName:
ipv4_address: 192.20.0.10
restart: always
|
这样的话微服务间通讯就没有问题了
docker内存高占用
我的7到8个微服务一启动，测试机8g内存基本就会过百分之50的占用，之前开端口被病毒占了百分之40，我i的微服务通过docker-compose启动直接服务killed，原因是内存不足；
使用docker命令查看了一下占用，好家伙 eurekaserver注册中心都需要500m+ 按理来说应该200m差不多了；
这里我出厂服务器后，直接用nginx转发，弃用gateway，勉强救急去解决了。
正确的解决方式：
代办：
内存控制： 分俩端 一边是jdk占用、一边是指定容器的占用；
可参考
https://www.jdon.com/51409
https://www.cnblogs.com/shunzi115/p/14173015.html
最佳的解决应该是升级jdk11，通过dockerfile 指定容器占用内存和jdk占用内存生成镜像；