这篇文章给大家介绍自研的Devops工具是怎样的，内容非常详细，感兴趣的小伙伴们可以参考借鉴，希望对大家能有所帮助。

创新互联网络公司拥有10年的成都网站开发建设经验，上千余家客户的共同信赖。提供网站设计、成都网站制作、网站开发、网站定制、卖友情链接、建网站、网站搭建、成都响应式网站建设公司、网页设计师打造企业风格，提供周到的售前咨询和贴心的售后服务

2018年为了解决日常运维中的痛点以及更高效的推进运维工作，我们自研并完善了几个工具系统，这些系统无一例外的帮我们节约了时间，提高了效率，这篇文章将分享介绍一下这些工具系统

系统介绍

CMDB

CMDB配置管理数据库，主要用来记录我们管理维护的软硬件信息，包含实体的服务器，交换机以及虚拟的项目、服务、环境等所有需要管理维护的信息，通俗一点理解就是之前我们可能一个excel表格记录了我们维护的所有项目，项目所用的服务器资源，服务器的配置等等信息，都可以录入到CMDB系统里统一维护管理

CMDB系统是其他很多系统的基石，要给所有用到基础信息的第三方系统提供API以查询或修改数据，例如提供项目对应的服务器信息给持续部署工具推送代码到项目服务器上，所以CMDB系统的数据准确性非常重要，同时只在一个地方维护基础信息能够让整个运维系统更可控，更高效，减少出错

我们CMDB系统上线时间比较久，之前仅是用来替代Excel表格维护信息用，今年为他增加了API，提供给第三方系统获取基础数据，API认证采用了JWT，关于API认证这篇文章有更多的介绍：Django+JWT实现Token认证

varian

varian是我们内部开发的一个模块化的持续集成工具，主要负责项目从源代码到最终可部署程序的这个过程，现在有大部分项目已经是Docker部署了，那么varian会负责从源代码到最终打包好的项目镜像并上传到镜像仓库这个过程，其中会涉及到编译、合并、压缩等等操作，这篇文章有详细介绍我们varian的工作过程：探秘varian：优雅的发布部署程序

varian的核心逻辑是把持续集成中的每一个小步骤拆分成独立的类或方法，最终根据项目类型的不同组装不同的类或方法，实现不同类型不同技术栈项目能够共用同一套持续集成程序，减少代码冗余，提高可用性

nova

nova持续部署，配合varian做整个上线流程，nova主要负责的是将最终的可部署程序或者Docker镜像推送到线上各个节点更新的过程，因为线上环境比较复杂，有云主机、Docker容器、私有云、公有云k8s等，所以在nova这一层做了兼容

nova只接受三个参数，1.项目名称，2.部署环境，3.部署版本号，根据项目名称和部署环境调用CMDB提供的API确定最终推送项目到哪些节点，根据版本号去拉取代码仓库代码或者镜像仓库镜像

扩容、回滚、重启等操作都可以通过nova系统自动完成，这篇文章介绍了持续部署的更多细节：Docker环境的持续部署优化实践

kerrigan

在整个发布上线的过程中除了代码的变更之外，通常还会涉及到配置文件、数据库的变更，为了解决配置文件自动更新的问题我们开发了kerrigan系统，这篇文章有关于配置中心实现细节的介绍：中小团队落地配置中心详解

kerrigan底层基于etcd+confd实现，主要实现在web端修改，服务器上自动更新生效的功能，kerrigan还能够管理多环境不同类型的配置，尤其擅长文件型的配置（区别于通常看到的基于KV的配置中心，对运维更友好），例如管理nginx，tomcat等配置，同时能够记录配置文件的修改历史，快速回滚配置，还支持配置文件对比，只修改保存延后发布等功能

因为我们项目比较多，每个项目的nginx里边有一堆的规则，基于Docker的话每个rewrite的更新都需要重新打包发布比较繁琐，使用kerrigan之后有效解决了这个问题

overmind

数据库运维系统overmind，除了能够解决发布上线过程中的最后一环数据库变更外，我们还集成了其他一些实用的功能，例如SQL审核、SQL查询、自动导数据的工单系统，密码表等

overmind的第一个版本主要是集成了inception做SQL的审核和执行，帮助我们自动化的处理线上数据库的变更，这篇文章有介绍：中小团队快速构建SQL自动审核系统

完成第一个版本之后内部推动开发测试使用，收集到反馈，在第一个版本的基础上添加了SQL查询、Explain执行计划展示等功能，后续发现DBA经常接到各个不通环境之间导数据的需求，又开发了工单功能来实现数据自动迁移，这篇文章有介绍迁移：运维效率之数据迁移自动化

后边抛弃了Excel维护密码的方式，开发了密码表功能，见这篇文章介绍：Django开发密码管理表实例【附源码】

overmind在慢慢完善，后续还会基于需求和实用性添加更多的功能来提高效率

proxy

proxy是一个代理系统，类似于阿里云的SLB，kubernetes的ingress，主要给开发测试环境使用

我们维护项目较多，每个项目有多套不同的环境，每个环境都有不同的域名，对应不同的后端服务，为了模拟真实请求过SLB代理的环境以及集中的管理这些项目入口，之前的做法是把所有的域名都指向到一个nginx服务器，nginx服务器通过基于域名的vhost代理到后端服务，每次添加或修改都通过手动变更nginx配置文件来完成，现在开发了proxy系统，可以通过页面来快速方便的完成

wiki

wiki系统在18年之前已上线，当年提出来规范化、文档化、自动化、智能化的运维目标，文档是整个运维过程中非常重要的一环，其好处不用多说，持续推进文档的输出也是我们非常重要的一环

当然除了以上这些系统外还开发了一些小工具来规范管理，提高效率，这里不多介绍。另外我们还用到了大量的开源软件系统，例如Jenkins、ELK套件、Kubernetes等

我们知道devops是从研发到上线整个过程自动化的一种思想，并不是某个工具或者某几个工具的集合，我一直在想如何才能将devops落到实处，18年基于当前的环境我们开发了以上的各种工具来帮助我们高效的工作，但这些工具系统相对分散，不能形成体系流程，19年会实践一些方式方法将这些工具系统串联，实现更高程度的自动化，同时也会持续推进Kubernetes更大范围的落地，为真正的实现Devops思想，从开发到上线的全流程自动化打基础

关于自研的Devops工具是怎样的就分享到这里了，希望以上内容可以对大家有一定的帮助，可以学到更多知识。如果觉得文章不错，可以把它分享出去让更多的人看到。

文章标题：自研的Devops工具是怎样的
当前地址：http://azwzsj.com/article/ghcejg.html