用开源软件轻松打造企业级DevOps工作流

Posted 2021-04-16 NightTeam

"NightTeam"一个值得加星标的公众号。

文章作者：「夜幕团队 NightTeam」 - 张冶青

润色、校对：「夜幕团队 NightTeam」 - Loco

前言

大家作为程序员或开发运维人员，可能很少有没在开发、部署、交付过程中遇到过问题的。特别是在企业环境、多人协同工作、模块纷繁复杂的情况下，用简单粗暴的方式（例如手动上传代码，或是线上更改代码）进行处理往往会造成很严重的问题。因此对于企业级环境中开发部署来说，有一套严格完备的工作流机制会减少很多失误和因此而导致的延期，增加交付应用的健壮性，从而提升交付效率。

现在有个很流行的名词叫 DevOps，意为开发（Development）与运维（Operations）的组合简写，从字面上的意思解释，就是让开发团队（Dev）和运维团队（Ops）相互沟通、融合、协作，旨在促进开发和技术运营与质量保障之间的整合。甚至有些职位就设置为 DevOps 工程师，要求工程师既做开发，又做运维，这对人本身、技术以及流程要求都较高。

本文将简单介绍 DevOps，以及 DevOps 工作流程包含的一些基础架构元素。而本系列文章将从应用开源框架的角度，介绍如何使用开源软件构建一个健壮、实用的企业级 DevOps 工作流。本系列文章主要集中在 DevOps 三大要素（下面我们会简单介绍）中的技术这一块讲解。

本文或本系列文章适合对软件开发及运维有一定基础，并想要实践 DevOps 工作流到工作中的技术人员。

DevOps概述

DevOps 的概念由一个名叫 Patrick Debois 的 IT 咨询师发明的。他在负责测试工作的时候发现，他既需要跟随开发团队的敏捷节奏，又需要以传统方式维护这些系统，而这两种工作环境差异巨大，他需要一个更优雅的方式解决这种琐事。

2009年时，他看到 Velocity 大会上的一篇轰动世界的演讲，这篇演讲提出了以业务敏捷为中心、构造适应快速发布软件的工具（Tools）和文化（Culture）。于是，Patrick 由此萌发了举办"社区版" Velocity 大会的想法，取名为 DevOpsDays，并号召了全球各地的人来参加。DevOps 这个概念就此诞生。

人们对 DevOps 这个概念的认识不尽相同：

•有认为 DevOps 是一种技术或平台的，不过这种认识过于片面，忽视了人和流程的作用；•还有认为 DevOps 是一种流程的，这种认识虽然比较合理，但也相对片面；

而目前大家普遍认可的，则是「DevOps 是 Dev 和 Ops 的组合的一种职位」，这个定义就很完善了。

---

下图是 DevOps 的三大元素，可以看到 DevOps 是平台（技术）、流程、人的融合出来的结果，少了一样都会很片面。

本文或本系列文章主要关注的是平台或技术这一块，内容是讲解如何用开源软件打造企业级 DevOps 工作流。

但要注意的是，DevOps 只考虑技术是不够的，还需要考虑流程和人的因素。如果一个技术人员只知道如何配置 Jenkins 自动发布应用，而不知道将该流程推广到整个公司，不能形成一个文化的话，这样的 DevOps 是失败的。DevOps 要求有合适的工具，更需要全公司参与，打造成一个工作流程和文化。

---

下图是 DevOps 涉及到的技术。

可以看到，DevO ps 涉及的技术相当繁多，包括玲琅满目的技术类别。 我们不需要掌握所有的技术，在面对不同的场景时，我们只需要用合适的工具就足够了。

本系列文章将讲解一些基础功能，包括版本控制（VCS）、持续集成（CI）、容器化（Container）、编排（Orchestration）以及网络（Networking），并讲解如何用开源软件实现上述功能。

版本控制（VCS）

版本控制系统（Version Control System）是 DevOps 中的重要环节。它可以被看作是代码的数据库，谁修改了什么、谁删除了什么，都可以通过这个系统来进行管理。在中大型项目中，不用版本控制系统很可能会导致严重的问题。

下面是一个典型的场景：

1.线上服务被发现有 BUG，需要立即修复；2.维护人员发现是因为一个变量名称写错导致的；3.这名维护人员采用了最快速的线上修改代码的方式，将这个问题暂时解决了，大家似乎相安无事；4.一个月以后，这个问题又出现了，由于代码量和项目复杂度的增加，这个问题隐藏得很深，久久得不到解决，或者好不容易把这个问题解决了，其他问题又出现了。

其实，如果一开始所有开发人员都用了版本控制系统 Git 或者 SVN 的话，并且要求所有代码更改都必须进入版本控制，就有很难出现上述这个问题了。

在后续文章中，我们将讲解如何用开源软件 GitLab 来实现版本控制。

持续集成（CI）

持续集成（Continuous Integration）也是非常重要的部分，因为它可以将构建应用并打包上线的工作自动化，减少了很多人工上线的成本，最关键的是——它很方便！

想象一下，如果没有持续集成，我们的部署流程会是什么样子：

1.开发人员开发好一个应用，编写好部署文档；2.运维人员获取源码，并按照部署文档来部署应用；3.中途运维人员发现，部署文档中缺少了一个安装依赖的步骤，需要去找开发人员要这个步骤；4.开发人员测试了半天，将正确的部署文档发给运维人员；5.反反复复折腾，终于部署好了，但时间也浪费了好几天。

这是个典型的没有持续集成的例子。但如果采用 Jenkins 将发布做成自动化的，就不需要什么部署文档了，部署步骤清晰可见，开发人员可以直接看到部署是否成功、是否有步骤出问题等，省去了非常多折腾的时间。

在后续文章中，我们将讲解如何用开源软件 Jenkins 来实现持续集成和自动部署。

容器化（Container）

想象 这样一个开发场景，为了保证环境隔离，我们建立了开发、测试、生产三个环境，每个环境尽量保证一致，例如操作系统都为 Linux，数据库版本一致，编译器版本一致，等等。

但可惜的是，我们不可能完全做到环境一致，特别是开发者自己的环境，与测试（Test）和生产环境（Production），基本不可能完全一致。

大多数开发者用的是 Windows 或 Mac OS 操作系统，但实际测试环境和生产环境大多数情况都是 Linux 的。很多 Windows 或 MacOS 上可以正常运行的程序，到了服务器上就不能运行了、或者有奇奇怪怪的 BUG，这都是环境不一致导致的。

早期有个解决方案是让每个开发者装一个虚拟机（VM），在上面安装虚拟的 Linux 环境，让开发好的应用在上面调试，通过后再测试部署到测试或者生产环境上。自动化的软件也涌现出来，比如著名的 Vagrant，可以通过编写配置文件一键生成虚拟环境。但是，安装虚拟机开销比较大，需要预分配内存和磁盘空间，这对于资源并不充裕的机器来说不是个最优的解决方案。

直到 2013 年，Docker 横空出世，实现了容器化的功能。它与虚拟机有本质上的区别，因为它不要求预分配资源，所以对低配机器也非常友好。自此之后，环境隔离和环境复用就再也不是难事了。

Docker 的使用非常简单，其中的 容器（Container）概念类似于编程语言中的实例（Instance），镜像（Image）类似于类（Class），很易于管理，横向扩展非常简单。实质上，Docker 的配置跟编写一个应用差不多，用 Dockerfile 可以让构建一个五脏俱全的应用程序这件事情变得非常容易。

如果把版本控制系统比喻为收藏设计图纸的图书馆，持续集成比喻成工厂流水线，那么容器则可看作是一个个功能样式统一的产品。Docker 正在（或者已经）成为编程部署应用的首选。

在后续文章中，我们将讲解如何用大红大紫的 Docker 来构建容器化部署。

编排（Orchestration）

随着服务器资源变得越来越廉价，分布式应用得到普及，像微服务这样的架构在如今正在逐渐成为主流。而伴随而来的痛点就是如何有效地让这些分布式应用或者集群被更好的管理起来。

编排（Orchestration）技术正是这样的管理集群的有效方法，它能保证分布式应用能得到很好的扩展。

对于一些简单的应用来说，单机或许已经足够，但对于某些大型应用来说（例如搜索引擎爬虫、高并发服务器、大数据应用），它们往往对资源要求较高，需要大规模的分布式集群，所以为了管理这些集群，编排技术必不可少。

Kubernetes（又称k8s） 是 Google 开源的容器编排引擎，后续文章将讲解如何使用 Kubernetes 来实现集群的管理。

网络（Networking）

网络是非常重要的技术。 我们可以没有 DevOps 这样的流程和技术，但 99% 以上的可能是少不了网络技术的。

而网络技术也种类繁多，涉及通信、传输、配置等等，这里我们只会讲解其中一个类别，也就是反向代理。为什么会讲反向代理呢？我相信绝大多数人在开发 Web 应用的时候都会碰到配置路由的情况，而反向代理正是解决网络路由问题的技术。

另外，反向代理还可以实现负载均衡（Load Balance），可以合理利用分布式应用的计算、网络带宽等资源。如果没有反向代理，你会发现很多内部端口会暴露在外，既不安全，也不美观。

在后续文章中，我们将讲解如何使用 nginx 实现反向代理，并会介绍如何将其整合到 DevOps 工作流中。

总结

本文介绍了 DevOps 的基本概念，并简单介绍了一些 DevOps 工作流中的技术，包括版本控制、持续集成、容器、编排、网络，另外我们还介绍了即将在后续系列文章里讲解的开源软件。

但是 DevOps 的技术 RoadMap 绝对不仅仅局限于此，从前面小节中的图就可以看出来，要懂得所有技术绝对是 CTO 级别的大师级人物。而我们也应该了解 DevOps 也不仅限于技术和平台，而应该将其与流程跟人结合起来，这样才能很好地实践 DevOps。

本文只是个开始，后面我们将更加细致地讲解各项技术以及实现用到的开源软件，并且将他们应用到企业级 DevOps 工作流中来，敬请关注后续文章。

---

夜幕团队成立于 2019 年，团队包括崔庆才、周子淇、陈祥安、唐轶飞、冯威、蔡晋、戴煌金、张冶青、韦世东和文安哲。

涉猎的编程语言包括但不限于 Python、Rust、C++、Go，领域涵盖爬虫、深度学习、服务研发、对象存储等。团队非正亦非邪，只做认为对的事情，请大家小心。