这是一个创建于 1889 天前的主题，其中的信息可能已经有所发展或是发生改变。
随着云技术以及容器技术的崛起，人肉运维的时代结束了
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 等
2019 年计划
我们知道 devops 是从研发到上线整个过程自动化的一种思想，并不是某个工具或者某几个工具的集合，我一直在想如何才能将 devops 落到实处，18 年基于当前的环境我们开发了以上的各种工具来帮助我们高效的工作，但这些工具系统相对分散，不能形成体系流程，19 年会实践一些方式方法将这些工具系统串联，实现更高程度的自动化，同时也会持续推进 Kubernetes 更大范围的落地，为真正的实现 Devops 思想，从开发到上线的全流程自动化打基础
如果你觉得文章不错，请扫码关注为本文点个 [好看] 。如果你觉得读的不尽兴，推荐阅读以下文章：
目前尚无回复
Select Language