文章目录
- 一、Devops
- 1、什么是Devops
- 2、什么是CI/CD
- 3、Devops方案参考
- 二、人工部署
- 1、项目打jar包
- 2、生成镜像、创建容器
- 三、自动化部署
- 1、代码提交到git
- 2、修改pom.xml文件
- 3、前端部署
一、Devops
1、什么是Devops
一个软件的生命周期包括:需求分析阶、设计、开发、测试、上线、维护、升级、废弃。详细如下:
- 产品人员进行需求分析
- 设计人员进行软件架构设计和模块设计
- 每个模块的开发人员并行开发,设计接口、进行编码,并进行单元测试
- 开发完毕,将代码集成部署到测试服务器,测试人员进行测试
- 测试人员发现bug,提交bug、开发人员修改bug
- bug修改完毕再次集成、测试
- 测试完毕,项目上线
- 运维人员进行安装部署、培训
- 用户提出问题,返回给运维人员
- 运维人员反馈给开发人员,开发人员进行问题处理
- 再次提交测试
- 测试完毕再次部署升级
整个生命周期中有两个核心阶段:开发阶段和维护阶段 ⇒ ⇒ 提高开发阶段、运维阶段的工作效率是企业在进行软件项目管理的重点。⇒ ⇒Devops
DevOps(Development和Operations的组合词),DevOps不是一种工具,也不是一个工作岗位,而是一种思想理念,它涵盖开发、测试、运维的整个过程。DevOps强调软件开发人员与软件测试、软件运维、质量保障(QA)部门之间有效的沟通与协作,强调通过自动化的方法去管理软件变更、软件集成,使软件从构建到测试、发布更加快捷、可靠,最终按时交付软件。
2、什么是CI/CD
关于Devops理念如何落地,对每个阶段都开发出一大批工具,这些工具包含了开发、测试、运维等各个阶段。下图是Devops工具集:
有了工具,接下来就是实施Devops的具体方案⇒ ⇒CI/CD
,其中:
CI:Continuous Intergration,即持续集成
CD:Continuous Delivery 和 Continuous Depolyment,即持续交付和持续部署
CI:持续集成
即团队成员需要频繁的集成他们的工作(
将开发分支合并到主分支
),每次集成都通过自动化构建(包括编译、构建、自动化测试)来验证
,从而尽快地发现集成中的错误,让产品可以快速迭代,同时还能保持高质量
CD:持续交付
持续交付将集成后的代码
部署到类生产环境
(测试、预发布环境),除了交付到类生产环境之外,还会执行一些集成测试、API测试。持续交付强调的是“交付”,交付给测试、产品验收
,不管怎么更新,软件是随时随地可以交付的。
CD:持续部署
在持续交付的基础上由开发人员或运维人员
自助式的定期向生产环境部署稳定的构建版本
,持续部署的目标是代码在任何时刻都是可部署的,并可自动进入到生产环境。
以上三个过程环环相扣,每个过程都自动化执行。
3、Devops方案参考
下图是一种可行的CI/CD方案:
二、人工部署
1、项目打jar包
STEP1:项目打包
- 在父工程pom文件中使用<modules>聚合各模块
<!--聚合的好处是Maven自动识别依赖关系,如checkcode服务依赖base服务,打包的时候则会先把base打包,再打包checkcode-->
<modules>
<module>../xuecheng-plus-base</module>
<module>../xuecheng-plus-checkcode</module>
<module>../xuecheng-plus-gateway</module>
<module>../xuecheng-plus-auth</module>
<module>../xuecheng-plus-content</module>
<module>../xuecheng-plus-learning</module>
<module>../xuecheng-plus-media</module>
<module>../xuecheng-plus-orders</module>
<module>../xuecheng-plus-message-sdk</module>
<module>../xuecheng-plus-search</module>
<module>../xuecheng-plus-system</module>
</modules>
<!--父工程中还有依赖版本的统一管理-->
- 配置打包插件(在
每个
要打可执行jar包的工程中配置该插件,否则直接执行maven的package指令出来的jar包无法运行。base这种工程就不用加了。)
<!--在需要打可执行包的工程中配置spring-boot-maven-plugin插件
否则报 “jar中没有主清单属性”
"Unable to access jarfile "-->
<build>
<!--以后jar包的名字-->
<finalName>${project.artifactId}-${project.version}</finalName>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>${spring-boot.version}</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
- 插件安装成功
# 功能说明
build-info: 生成项目的构建信息文件 build-info.properties
repackage: 这个是默认 goal,在 mvn package 执行之后,这个命令再次打包生成可执行的 jar,同时将 mvn package 生成的 jar 重命名为 *.origin
run: 这个可以用来运行 Spring Boot 应用
start: 这个在 mvn integration-test 阶段,进行 Spring Boot 应用生命周期的管理
stop: 这个在 mvn integration-test 阶段,进行 Spring Boot 应用生命周期的管理
- 在父工程执行:
clean install -DskipTests -f pom.xml
对所有工程进行打包
package、install、deploy三者的区别:
package: 打包
install: 打包完以后拷贝到本地仓库
deploy: 打包完后上传到局域网的私服
# -DskipTests跳过测试
- 等待打包成功,在target目录下即可看到jar包
- 验证一下jar包是否正常,打开cmd:
java -Dfile.encoding=utf-8 -jar xuecheng-plus-checkcode-0.0.1-SNAPSHOT.jar
2、生成镜像、创建容器
STEP2:部署到Linux
- 在Linxu目录下编写DockerFile文件
FROM java:8u20
MAINTAINER docker_maven docker_maven@email.com
WORKDIR /ROOT
ADD xuecheng-plus-checkcode-0.0.1-SNAPSHOT.jar xuecheng-plus-checkcode.jar
CMD ["java", "-version"]
//对比启动jar包的指令
ENTRYPOINT ["java", "-Dfile.encoding=utf-8","-jar", "xuecheng-plus-checkcode.jar"]
EXPOSE 63075
- 将打好的jar包拷贝到该目录
- 执行镜像构建指令
docker build -t
checkcode:1.0 .
指令中最后的. 即当前目录
报这个错,是因为Dockerfile文件被命名成了DockerFile,不想改名就-f指定一下
docker build -t checkcode:1.0-f DockerFiler .
-
构建成功
-
根据镜像启动容器
docker run --name checkcode -p 63075:63075 -idt checkcode:1.0
到此,Java工程,从代码到jar包,再到镜像,再到Docker容器部署到Linux上的整个过程,手动完成了!
此时,请求虚拟机IP:63075/checkcode/pic即可
docker logs -f 容器ID查看日志
三、自动化部署
接下来使用Jenkins来完成CI/CD:
- 代码使用git托管
- 在jenkins创建任务,从Git拉取代码
- 拉取代码后进行自动构建
- 将代码打成镜像包上传到docker私服
- 自动创建容器、启动容器
- 当有代码push到git实现自动构建
1、代码提交到git
git commit
git push
2、修改pom.xml文件
添加docker-maven-plugin
插件实现将springboot工程创建镜像。在要部署到容器的每个微服务中添加以下插件:
<build>
<!--生成可执行的jar包-->
<finalName>${project.artifactId}-${project.version}</finalName>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>${spring-boot.version}</version>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
<!--创建镜像,上传镜像-->
<plugin>
<groupId>com.spotify</groupId>
<artifactId>docker-maven-plugin</artifactId>
<version>1.2.2</version>
<configuration>
<!--修改imageName节点的内容,改为私有仓库地址和端口,再加上镜像id和 TAG,我们要直接传到私服-->
<!--配置最后生成的镜像名,docker images里的,我们这边取项目名:版本-->
<!--<imageName>${project.artifactId}:${project.version}</imageName>-->
<imageName>192.168.101.65:5000/${project.artifactId}:${project.version}</imageName>
<!--也可以通过以下方式定义image的tag信息。 -->
<!-- <imageTags>
<imageTag>${project.version}</imageTag>
<!–build 时强制覆盖 tag,配合 imageTags 使用–>
<forceTags>true</forceTags>
<!–build 完成后,push 指定 tag 的镜像,配合 imageTags 使用–>
<pushImageTag>true</pushImageTag>
</imageTags>-->
<baseImage>java:8u20</baseImage>
<maintainer>docker_maven docker_maven@email.com</maintainer>
<workdir>/root</workdir>
<cmd>["java", "-version"]</cmd>
<!--来指明Dockerfile文件的所在目录,如果配置了dockerDirectory则忽略baseImage,maintainer等配置-->
<!--<dockerDirectory>./</dockerDirectory>-->
<!--2375是docker的远程端口,插件生成镜像时连接docker,这里需要指定docker远程端口-->
<dockerHost>http://192.168.101.65:2375</dockerHost>
<!--入口点,project.build.finalName就是project标签下的build标签下 的filename标签内容,testDocker-->
<!--相当于启动容器后,会自动执行java -jar ...-->
<entryPoint>["java", "-Dfile.encoding=utf-8","-jar", "/root/${project.build.finalName}.jar"]</entryPoint>
<!--是否推送到docker私有仓库,旧版本插件要配置maven的settings文件。 -->
<pushImage>true</pushImage>
<registryUrl>192.168.101.65:5000</registryUrl> <!-- 这里是复制 jar 包到 docker 容器指定目录配置 -->
<resources>
<resource>
<targetPath>/root</targetPath>
<directory>${project.build.directory}</directory>
<!--把哪个文件上传到docker,相当于Dockerfile里的add app.jar /-->
<include>${project.build.finalName}.jar</include>
</resource>
</resources>
</configuration>
</plugin>
</plugins>
</build>
- 在Jenkins源码管理中配置git仓库的地址
- 打包指令、生成镜像上传镜像到私服
- 进入任务点击build now
- 控制台查看日志
- 配置触发器,当代码提交时,jenkins自动构建任务
3、前端部署
- 在docker中部署nginx,修改nginx.conf配置文件
- 将静态资源拷贝到容器映射到宿主机的目录
- 将机构端的前端工程打包,运行yarn build
- 打包成功在工程目录生成dist目录
- 将此目录的内容拷贝到虚拟机的/data/soft/nginx/xuecheng_portal_static/dist