devops使用,devops软件

目录 什么是 `DevOps``DevOps` 概念的起源单体架构 + 瀑布模式分布式架构 + 敏捷开发模式多人协同开发问题多机器问题开发和运维角色的天生对立问题 微服务架构 + `DevOps` `DevOps` 到底是什么`DevOps` 常用的工具`Jenkins``Kubernetes`

什么是 DevOps

DevOps 这个词，其实就是 Development 和 Operations 两个词的组合。它的英文发音是 /de'vɒps/，类似于"lgdds"

它的目标：DevOps 就是让开发人员和运维人员更好地沟通合作，通过自动化流程来使得软件整体过程更加快捷和可靠

以电商系统为例，它是单体应用架构，这个时候只有开发人员 ，没有运维人员，开发人员就是全栈，项目开发好，找台服务器安装好环境，把 jar 包丢到远程服务器，放上去开启服务就可以

这个时候服务监控也简单，服务出了问题，直接去线上看一下运行日志，为了解放双手监控服务，开发者会写一些脚本分析日志，服务器少，部署简单，通常开发就可以完成运维的工作，不需要专门的运维来做部署，所以开发模式很简答，直接按照瀑布流方式开发就可

随着业务体量发展越来越大，一台机器扛不住，那么就加机器，单机变多机，业务架构也开始加入了 nginx，cdn 缓存等通用基础服务，业务变多肯定会招人，就涉及到多人协同开发，多人多机器模式

人员一多，为了更好的分工，大多会将项目进行拆分，每个人负责专注于一部分，有点包干到户的感觉。敏捷开发的核心理念：就是既然我们无法充分了解用户的真实需求是怎样的，将一个大的目标不断拆解，把它变成一个个可交付的小目标，然后通过不断迭代，以小步快跑的方式持续开发。另外，一个项目是很大的，为了保证项目质量，测试环节不可减少，为了加快速度增大开发效率，QA 的工作最好是和开发同步交替进行的，需要将测试环节从后面注入到整个开发环节当中，每次可交付的都是一个可用的功能集合，对开发交付的内容进行持续验证

再说说多机器问题，之前机器很少架构简单的时候，开发就可以干运维的活，就算加了几台服务器，那也是脚本将 JAR 包同时发布到这些机器上，好像也挺简单，但是会有两个人同时上线部署被覆盖的问题，所以大家在上线之前可能会去群里吆喝一声，”我要上线了，大家先别上线哈“，可想而知这样效率也很低下

公司业务一大，像大公司的动不动就是几千台服务器，就需要专门的运维介入了，一方面是因为开发分工每个人都专注于自己的事情，不会那么用心进行维护，另一方面是运维的学习成本确实变高了，开发人质量参差不齐，服务器要是每个人都可以上估计领导每天晚上都要做噩梦。但是这个时候也不是 DEVOPS，而是 DEV+OPS，这时 Ops 的主要职责就是：硬件维护、网络设备维护、DBA 、基础服务维护、数据监控等，运维们擅长写各种部署，监控脚本，减少机械的重复工作，开发模式变成了敏捷开发模式

加入运维，就要协调人员配合，运维的宿命就是维稳，他们是很讨厌变动的；开发的天职确是不断地推代码上线，进行代码变动，更替迭代，这两个工种天生就是对立的

很多大公司有那种，开发人员想要上线，需要提交各种审批，层层签字画押，多少人的上线激情被一句冷冰冰的‘还没到窗口发布期’给泼的透心凉。所以，敏捷开发解决了协同开发和多机器部署开发问题，但是没有解决内部人员的矛盾，留着这个矛盾在公司，开发和运维随时都可能约‘生死架’

将项目拆成一个个小的服务单独部署，以电商项目为例如图，将整个项目拆分为用户服务，商品服务，订单服务，积分服务…每个服务单独部署，之间通过互相调用的方式来交互，而且可以将一些基础服务例如上传图片，发送短信等很多服务都需要的基础东西，抽象到一个单独的服务，也就是前些年鼓吹的很厉害的‘中台服务’

拆分部署催生出 DevOps，再看看这种架构下的开发模式 DevOps，运维需要做的上线工作，主要就是将代码部署到对应的机器里面，微服务有那么多的服务，每个大点的公司几百个服务不算多，而且还可能随时搞一个服务出来，如果还按照原始的脚本部署方式，可能最后连是哪个脚本都找不到。而且，如果每个服务上线都需要运维来同意，开发也太卑微了，估计要天天求着运维同意发布，运维也会烦不胜烦

那么为何不能再远程部署一些机器，专门用来管理代码，进行上线工作，由运维事先把上线的规则都给定义好了，开发只要按照他的规则都访问这台服务器进行各自的代码合成和发布，自己上线呢，能用代码自动完成的事情就绝不要手动解决，这是每个开发人员都在想的东西。运维需要做的事情，慢慢的都沉淀到了各个平台上面，例如监控，有专门的监控组件和可视化，基础服务例如服务器，CDN，负载均衡等基础服务可以外包到云服务厂商，日志也有专门的日志工具，链路追踪也有专门的组件和可视化，还有网关等，渐渐的，只要这些都配置好了，开发也可以做运维的部分工作，毕竟开发才是最了解代码的人，哪里出了问题看看监控日志，可以最快速度定位到问题，于是 DevOps开发模式诞生了，开发也是运维

从目标来看，DevOps 就是让开发人员和运维人员更好地沟通合作，通过自动化流程来使得软件整体过程更加快捷和可靠

对比前面所说的瀑布式开发和敏捷开发，我们可以明显看出，DevOps贯穿了软件全生命周期，而不仅限于开发阶段

下面这张图，更明显地说明了 DevOps 所处的位置，还有它的价值

在 DevOps 的流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中，并提供系统部署的优化建议

DevOps 的实施，促进开发和运维人员的沟通，增进彼此的理（gan）解（现实的纸鹤）

Jenkins（读：[ˈdʒɛŋkɪnz]）是很多软件开发团队在走向 DevOps 时会用的自动化工具。它是开源的 CI/CD 服务器，帮助用户自动化交付流水线的不同阶段。Jenkins 之所以流行的主要原因是其巨大的插件生态系统。目前，它提供 1000 多个插件，因此它可以和几乎所有 DevOps 工具集成

使用 Jenkins 很容易，它在 Windows，Mac OS X 和 Linux 上开箱即用。很容易就可以使用 Docker 安装它。用户可以通过浏览器搭建并且配置 Jenkins 服务器。如果你是第一次使用它，可以选择安装最常用的插件。当然也可以创建自定义配置。使用 Jenkins 用户可以尽快迭代并部署新代码。它还帮助用户度量流水线里每一步是否成功

官网：https://jenkins.io/

Kubernetes 又称 K8S，它是容器编排平台，将容器化推进到下一个层面。它可以使用 Docker 或者其他替代产品。使用 Kubernetes 用户可以将容器组织成逻辑单元。如果你只有几个容器，那么可能并不需要容器编排平台。但是，当系统达到一定级别的复杂度，需要扩展资源的时候，这就是合理的下一步。Kubernetes 让用户可以自动化管理上百个容器的过程

使用 Kubernetes 无需将容器化的应用程序绑定到某个单独的机器里。相反，你可以将它部署到一个机器集群里，Kubernetes 会自动化分发并在整个集群里调度容器

一个 Kubernetes 集群包含一个 master 和几个 worker 节点。master 节点实现预定义的规则，并且将容器部署到 worker 节点上。Kubernetes 负责所有一切。比如，它注意到某个 worker 节点下线了，就会将其上的容器重新分发到别的节点上

官网：https://kubernetes.io/