DevOps其实是技术企业用于研发上线等一整套完成基本流程的一种文化
不是岗位,是软件工程开发的实现方案
开发和技术运营本来是隔离的
devops,需要把运维和开发两个环节整合起来
linux运维做的更多的时候,系统应用级的运维
开发pm 项目工程师,质保,开发
QA质量保证,质检部
三个地方交接的部分,把这部分延展出去,叫devops
应用一个项目需要做plan计划,产品提需求,pm来交给研发开发code,代码写完,构建build,转换格式,编译,构建好了该测试了,测试,单元测试,系统测试,确保没问题,打包释出,release,发行,
如果只是内部使用,就需要运维部署,扩展规模,缩减规模,日常得到的数据,需要监控monitor,如果监控经常出现问题,监控的数据反馈给PM,来了解问题,进行新一轮计划
如果实现自动实现,每个环节自动减少人为的干预,既能自动化,又能无缝衔接,devops
三件套工具,了解下,人(开发,运维,测试,监控)people,流程(process),工具(tools)
实现两个功能,CI,CD,借助于工具
CI持续集成 continuous integration
CD continuous delivery 持续交付
code编写代码,buil代码构建,如果能借助于工具一并实现,称为敏捷开发 agile development,(程序员每天上班,就是检出库里的代码,开始编写自己的内容,编写以后要review,review没问题就需要构建,交给测试工程师测试,如果每天写的内容都构建出来整合,立即让测试,测试出的问题就可以马上修复,把代码推送到代码库,仓库会根据自动帮你完成构建功能,构建完进入下一步,完成集成,测试也可以借助工具自动测,测出的结果报告给程序员,程序员第二天先修复bug,修复完继续构建测试)
如果把后面两步,测试也整合进来,测试也自动测试,当程序员构建结束,就自动帮你测试,报告给开发,这部分叫持续集成CI,因为集成的操作,开发可能 只开发一个模块,构建的时候,要集成到整个项目中去,集成完就要做测试
build integeate test 后面的三步可以用工具来实现,代码写完往仓库推,仓库有触发器,触发一个自动构建的工具,来完成自动构建,再触发一个集成工具来完成所谓的集成,而后再触发一个测试工具来完成测试
到这一步就是持续继承,CI,每一天都在继承,每一次代码上去都能继承测速
测试完成,没有障碍向下一步,release,这样的好处是敏捷开发,不这么做就是,不持续继承,会遇到一个代码花了很长时间写好了发现跟之前的不匹配,只能推到重来,持续继承,每天测试,有问题可以及早发现,不至于让问题积蓄很多,
测试以后,能自动发布到线上,自动释出,这个过程称为持续交付,放到对应的ftp服务器上,测试完没有问题,用对应工具发布到系统上去,可以理解为不是发布,还是交付给运维工程师的系统上,可能是个NFS,FTP,http服务器,文件共享,交付了,就需要运维灰度发布
部署上线的过程可以借助于工具来实现,就是持续部署,CD,应该有一个部署系统或者发布系统,一旦发现先release了新版本就把他拖出来,放到各线上服务器上去,而且基于灰度的方式和蓝绿的方式
部署完了就需要监控和运营,operate,监控系统中的各种指标
这些都构建出来称为DevOps
**除了code无法完成自动,后面的每一步都需要自动来完成,可以找一个中央工具,构建每一个阶段的需要的工具,不同的代码可能构建的方式不一样,但是发布,释出,部署,监控都是不一样的,
devops三件套,人 ,process,tools,
如果每一个工具需要自己去手动整合那就很头疼,好一个集成式的工具,可以把每个过程的工具当插件继承到自己上面,然后让用户借助这一个接口,能定义每一个环节的实现,但是它自己可能对每一个环节都没有具体的实现
java代码的构建工具Gradle,Maven Ant ,
php的则是Phing,Chef
c则是 make
不同的编程语言工具不一样,要用插件方式,来用特定的方式来调用构建不同的代码,java用java的工具,c用c的,
不同的代码继承方式也不一样,也可以都像插件一样集成到控制台,来调用完成不同的功能
测试万,release还要发布到预发布系统,预发布系统上可以做功能测试,以及接受性测试,这个测试没问题才能真正上面的, **
sre站点可靠性工程师,以解决痛点为目的,来实现自动化的研发
devops整体流程
4种环境
开发环境 测试环境 暂存环境(预发布) 线上环境
研发到测试持续化就是持续继承
测试做测试就是持续测试,测试有两个环境,功能测试和接受性测试
预发布环境直接推到线上环境,
持续计划的,研发以后,,构建之前做单元测试unit test(把自己的代码做测试),单元测试完以后做自动化测试,automated test,测试没问题做构建,构建以后做
灰度发布,假如有100台服务器需要发布
一批10台10台 发叫灰度发布
额外再找10台当预发布环境,先预发十台做接受性测试功能测试,下来十台,再发布,最后十台下来之后就不要上了,最后下来的10台就成了预发布环境
持续集成,持续部署,持续发布,devops的过程
jenkins有10多年的时间了,11年,是Hudson分支,几乎完全兼容Hudson,hub核心
是CD/devops环境中的核心工具,控制台,能够以插件化的方式来,集成各种各样的工具,来让你定义每一个步骤的实现,自定义一个流水线,集成多个项目的流水线
代码托管集成的工具称为scm,有github,git,stash,vb
代码拖下来放到仓库就可以构建配置,maven构建是个war包,gradle新生代java构建工具
docker构建的dockerfile,是一个镜像
构建以后做扫描和测试,scan test,junit测试工具,sonar,fitnesse,
release做释出,测试完没有问题就需要打包成一个二进制格式的程序包,.exe,.msi等
deploy部署,docker部署更加简化,k8s部署,openstack部署,vwmare云环境部署,也可以用puppet,ansible来部署,
tomcat是一个jsp程序运行环境的平台,j2ee部署,manager就可以实现我们的部署,因此调用的managerapi接口,是直接把war包传过去,不用手动都能实现,其实调用tomcat接口,也能完成部署
jenkins并不实现某一功能,而是用提供一平台,让这些工具统一集成在这个平台上,定义成一个流水线,完成一步自动执行下一步
最流行的CI持续集成自动服务器
自动持续集成
自动持续部署
devops
开源
11年才出现jekins
市场份额
jenkins目标,从CI转换成cd
可以直接从jenkins1升级到2
可以直接定义流水线
用的是dsl的配置语言,域编程语言
jenkins属于java语言研发需要使用jdk
至少有256M内存,1G磁盘空间
推荐使用java8
1g内存
50gb磁盘空间,构建过程要存储很多数据的
jenkins是个war文件,可以部署好tomcat把它丢到目录下,能被访问
、安装以后要安装很多插件
可以直接使用系统自带的openjdkhttps://jenkins.io/zh/
安装好jenkins,其实生成的也是一个war包
systemctl其实也能启动
去调整一下使用的内存空间大小,先启动,暂时不改
也可以基于tomcat启动
把jenkins的war包复制到目录下,war包扔进去即可,会自动展开
已经自动展开了
默认jenkins锁定的,需要输入密码,密码在这个文件里
自定义jenkins
安装对方建议的插件,选择插件去安装
会访问互联网安装
基本上做到了对maven,git等软件的开箱即用
能用指对这个应用程序而言,可以给它做到直接集成,不需要做更多的配置,并不是内部这个插件不需要安装了
maven是xml格式的构建描述符文件,gradle应该可以yaml格式的文件
简称mvn,java代码是用maven构建的,就可以使用mvn来维护
这个是源码程序
goal表示构建目标是什么
把这个内容构建并打包 mvn package
maven自己也需要用到很多对应的插件
在项目目录下生成一个target目录,把war文件就扔进去了
在安装个tomcat,把构建好的代码扔到tomcat看下效果
提示我们版本不对
target下的文件有定义的类,maven状态属性
**查看xml格式的文件是否有问题,继续构建
**
使用manager,需要拥有gui权限,所以你的role需要manager-gui这么一个角色
文本行访问还需要script
tomcat用户既能访问web页面又能命令行工具
上面的manager少了个A
应该就需要安装-devel包导致的
就会生成一个war文件,把这个文件扔到tomcat下
war文件复制到宿主机上
直接选择文件deploy
这就是自己手动构建和应用的方法,这个方法可以整合在jenkins中
让jenkins整合这些插件,来自定义流程