毫无疑问,DocKer成了近些年来最火热,甚至最具颠覆性的技术之一。首先,我们在传统项目简单描述一下,项目发布的基本流程。
本地开发+测试,没有问题的话,编译打包发布到测试环境
在测试环境中进行测试,测试完成后,发布到生产环境
在生产环境中进行最后的测试,如果没有问题,那么一切就OK了
如果你是从事了一年以上开发人员,我想100%的人都亲身经历过这样的事情 —— 在自己本地测试都没有问题,发布到测试环境、生产环境后,就出现问题了!搞得自己非常苦恼!非常纠结!到底是哪里出了问题呢?明明代码什么的都一样啊~
那么在这种情况下,其实是有N种可能,但我这这里提出一个比较常见的原因,就是:
本地开发环境与测试环境、生产环境上的软件环境配置,可能出现不一致的情况,导致有些时候相同的代码在不同的环境下运行会出现问题。
再列举几个实际开发中遇到的情况:
公司在阿里云买了一台新服务器,要想能正常发布项目等,前提是需要在服务器上重新安装一些软件环境(比如node、mysql、nginx等),在安装软件环境的过程中,很大几率会出现配置错误的情况;一些比较复杂的环境配置步骤会很多,很多人都记不清具体的步骤和命令,还得上网搜索......
像jdk、tomcat等基础的环境搭建,都已经很熟练了,每次有新机器的时候,都要重新搭建,这样就造成了重复性工作、效率低下、配置繁琐麻烦、易出错等情况。
当然也会有其他的问题,这里就不多做说明了。
因此,我们在开发完毕之后,如果我们要部署10个项目,那就需要找10部虚拟机,然后再给对应的10部虚拟机部署对应的10个环境,重复性的工作量就算了,但部署的过程中肯定会衍生出很多的问题,上述提到的问题只是其中的一部分,这样会导致项目的落地造成了极大的问题,效率上也及其的低效。因此Docker技术就帮我们解决了我上述的痛点。可以说是程序员的福音。接下来,我们简单了了解下docker的基本概念,了解下它是如何解决上述的问题和痛点的。
Docker本质上是一个采用虚拟化技术的容器,基于Linux容器进行再封装,使用户不用关心容器的管理,而简化应用操作。
传统的虚拟化是基于硬件实现的,如果要部署10个应用,则需要创建10个虚拟机,而Docker是基于操作系统做的虚拟化,也就是复用本地主机的操作系统,部署运营10个应用时只需要起10个隔离的应用即可。
我们之前需要在每台服务器去配置对应的环境,但docker的出现,我们只需要去docker的公开社区,通过docker命令去下载镜像环境即可。
通过启动容器命令就可以在你的服务器中使用了对应的环境,这就可以让开发者在不了解对应环境的安装命令的同时也可以使用环境。并且占用服务器的资源也会更少。
开发者只需在项目结构中添加对应的Dokcerfile文件,即可在服务器中实现代码和环境的容器,这样项目的环境会根据当前的Dockerfile配置对应的环境,解决了因环境的不同导致项目无法正常运行的问题。
当你熟练的使用了docker命令去部署一个项目之后,现在问题的核心在于,如果我们每新建一个项目就要去服务器中执行同样的命令去启动容器,启动项目。这样的操作算是一种重复的操作,例如10个项目,开发者需要在服务器中走10此同样的命令,这样的操作是十分致命的。
因此,接下来要做的,就是“让重复的事情自动化”!!!
DevOps 就可以让“让重复的事情自动化”,它可以实现项目管理、自动化部署、自动化发布、自动化测试、容器云来实现持续集成、持续交付及持续部署。
DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称。
它实现持续集成、持续交付及持续部署。
在业界,我们通常将它称之为 CI ,这是一种开发、部署的实践。开发人员每天都将自己的更改推送到主分之中进行集成,通常情况下,这样的操作每天都会发生很多次。从更高的视角来看,CI 能使开发者更快的发现模块或功能中的错误。无论提交的大小,CI 能让整个团队看到每一个提交对整个项目的影响。当流程中出现问题的时候,通过 CI,可以准确地知道问题是由哪个提交造成的,也有可能从错误信息中看到是因为哪一行代码引起的。
持续交互在业界被简称为 CD ,是指在自动完成所有事情过后,将通过的代码进行直接部署。作为整个流程的最后一个步骤,设置监控报警,来确保你所部署的服务正在顺利的运行。当出现问题是要第一时间通知开发者。
了解了Devops之后,我们来看看具体的实现流程
开发人员在本地完成代码开发后,提交到本地分支,利用docker模拟生产环境进行测试,测试通过后合并到远端的主分支;
2.master 主分支一旦更新后,触发持续集成软件进行打包集成(常见的集成工具: gitlab-vi,travis,或Jenkins)自动完成构建docker 镜像并push 推到远程仓库(docker cloud 或者企业自己的docker registry)
3.利用docker cloud等持续部署到web服务器。
4.配置发布服务器从仓库拉取镜像,run起来后,停止旧的版本。完成了一次自动集成部署。
流程图如下
运行命令后,会从git仓库中获取VUE模板,此时项目的根目录文件中会多出三个文件,分别是Dockerfile.Jenkinsfile,nginx.conf三个文件,是为了后面的自动化部署作准备用的。
项目进入开发模式,即我们平时的开发模式,在这里该干什么就干什么了
这些都是git的基本操作了,就不过多的论述,
当联系远程仓库成功之后,进入step4
在实现部署之前,需要手动的创建一个制品库,制品库中存放着项目的镜像,并将权限设置为团队内部人员均可使用。
在团队项目中新建一个构建计划。
选择自定义构建过程。
选择关联的工蜂项目并设置流水线的来源为项目本身自带的流水线设置后,点击确定和立即构建。
接下来,就会按照自研流水线一步一步的执行自动化的部署。
等待部署完成之后,即可访问之前输入域名地址进行访问。
同时,我们可以通过终端远程访问到服务器中容器运行情况,查看当前项目的容器是否正在运行,通过docker ps命令查看正在运行容器,而其中的bluej_test即是刚刚经过自动化部署完毕的项目。