流程
开发通过git push上传代码,经Git和Jenkins配合,自动完成程序部署、发布,全程无需运维人员参与
持续部署的技术思路
在本例中,假设我们JAVA项目的名称为hello。简要的技术思路如下
本案例中假设代码托管在git.oschina.com上,Jenkins和Docker Registry(类似于yum源)各运行在一个Docker容器中。JAVA项目自己也单独运行在一个叫hello的容器中。
本文采取的持续部署方案,是从私有的Docker Reistry拉取代码。有些变通的方案,把代码放在宿主机上,让容器通过卷组映射来读取。这种方法不建议的原因是,将代码拆分出容器,这违背了Docker的集装箱原则:
这也导致装卸复杂度增加。从货运工人角度考虑,整体才是最经济的。这样,也才能实现真正意义的容器级迁移。
或者说,容器时代,抛弃过去文件分发的思想,才是正途。本文最后的问答环节对此有更多阐述。
容器即进程。我们采用上述方案做Docker持续部署的原因和意义,也在于此。容器的生命周期,应该远远短于虚拟机,容器出现问题,应该是立即杀掉,而不是试图恢复
效果展示
程序代码更新前的效果
提交程序代码更新
上传新代码到Git,在静静地等待几分钟后,新的代码确实已经自动部署完毕
实现
Jenkins配置Git源
Jenkins中新建项目java-app,并配置从Git拉取程序代码。具体如下:
Jenkins配置远程构建
Jenkins中配置token,以供git远程调用时使用
Git开启钩子
怎么让Git在接收到用户更新的代码后,把消息和任务传递给Jenkins呢?这借助于Git的hook功能,配置起来也非常简单,如下
配置Jenkins自动更新代码
Jekins在接收到Git传递过来的消息后,再触发一个远程构建(到目标服务器),按照预定义的任务列表,执行一系列的工作,重建容器等。详见如下:
最关键的Shell脚本内容
测试
Git提交代码
这时会触发Git服务器向相应的Jenkins服务器发出一个操作请求,此工作太过迅速,也没啥好说的,我们接下来看Jenkins都干啥子了
看看具体操作日志(正在接受来自Git的任务)
下载Maven相关的软件包(就是这个过程慢)
下载完成后,就开始利用maven BUILD 新的hello项目包
然后重建Maven容器,构建新的Image并Push到Docker私有库中
最后,重新把Docker容器拉起来
发表评论 取消回复