目录

DevOps介绍

原文:https://library.prof.wang/handbook/h/hdbk-MWnS99ThmLVDi7U5mVFrB9

DevOps简介

DevOps 一词的来自于 Development 和 Operations 的组合,突出重视软件开发人员和运维人员的沟通合作,通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。DevOps 其实包含了三个部分:开发、测试和运维。换句话 DevOps 希望做到的是软件产品交付过程中IT工具链的打通,使得各个团队减少时间损耗,更加高效地协同工作。

DevOps工具链

  • 项目管理(PM):Jira
  • 代码管理:GitLab
  • 持续集成(CI):GitLab CI
  • 镜像仓库:VMware Harbor
  • 容器:Docker
  • 容器平台: Rancher
  • 镜像扫描:Clairctl
  • 编排:Kubernetes
  • 服务注册与发现:etcd
  • 脚本语言:python
  • 日志管理:EFK
  • 系统监控:prometheus
  • Web服务器:Nginx
  • 数据库:MySQL redis

DevOps架构

DevOps 流水线(工具链)

https://gitee.com/lienhui68/picStore/raw/master/null/20200913195701.png

Devops环境部署

备注: 按照 DevOps 流水线顺序部署 先部署,后续实战中简介如何把流水线打通,实现通过平台一键发布功能

安装JIRA(项目管理)

JIRA简介

JIRA 是 Atlassian 公司出品的项目与事务跟踪工具,被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。 JIRA 中配置灵活、功能全面、部署简单、扩展丰富,其超过150项特性得到了全球115个国家超过19,000家客户的认可。

JIRA安装

安装配置过程请参考:官方网站

安装 GitLab(代码管理)

GitLab 简介:

Git 是目前世界上最先进的分布式版本控制系统(没有之一), 而 GitLab 是基于 git 协议开发 Web 控制台,Git 命令能操作的大部分功能, 都可以通过gitLab web控制台操作。

GitLab 安装

请参考:GitLab 安装详情

安装 Docker(容器服务)

Docker 简介

Docker 是通过内核虚拟化工作(namespaces及cgroups等)来提供容器的资源隔离与安全保障等。由于Docker通过操作系统层的虚拟化实现隔离,所以Docker容器在运行时,不需要类似虚拟机(VM)额外的操作系统开销,提高资源利用率。 三大理念:Build(构建)、Ship(运输)、Run(运行) Docker 组成:Docker Client、Docker Server

https://gitee.com/lienhui68/picStore/raw/master/null/20200913200114.png

Docker 安装

请参考: Docker安装详情

安装 Rancher(容器调度)

Rancher 简介

Rancher是一个开源的企业级容器管理平台。通过Rancher,企业再也不必自己使用一系列的开源软件去从头搭建容器服务平台。Rancher提供了在生产环境中使用的管理Docker和Kubernetes的全栈化容器部署与管理平台。 Rancher由以下四个部分组成: 基础设施编排、容器编排与调度、应用商店、企业级权限管理 下图展示了Rancher的主要组件和功能:

https://gitee.com/lienhui68/picStore/raw/master/null/20200913200414.png

Rancher 安装

请参考: Rancher安装部署

安装 Harbor(镜像仓库)

Harbor 简介

Harbor是一个用于存储和分发Docker镜像的企业级Registry服务器,通过添加一些企业必需的功能特性,例如安全、标识和管理等,扩展了开源Docker Distribution。 Harbor支持安装在多个Registry节点的镜像资源复制,镜像全部保存在私有Registry中, 确保数据和知识产权在公司内部网络中管控。另外,Harbor也提供了高级的安全特性,诸如用户管理,访问控制和活动审计等。

Harbor 安装

请参考:安装详情

安装 Clair(镜像扫描)

Clair 简介

Clair 的功能通过 Restful API 实现,但是每个 API 参数很多,而且上传镜像时还有很多复杂的处理。所以 CoreOS 为我们提供了 Clairctl 这款工具。Clairctl 是一个 Clair 客户端, 让用户可以通过简单的命令就能实现镜像的上传、扫描、输出报告等等。

Clair 安装

请参考:安装详情


持续集成、持续交付、持续部署

指导思想

代码的零库存管理

  • 代码越早push出去,用户能越早用到,快就是商业价值;
  • 用户越早用到就越早反馈,团队越早得到反馈,好坏都是有价值的输入;
  • 用户不反馈,说明我们做了用户不想要的东西(通过用例跟踪)或者marketing没做好,能帮助产品市场人员调整策略;
  • 代码库存越是积压,就越得不到生产检验,积压越多,代码间交叉感染的概率越大,下个release的复杂度和风险越高;
  • 代码库存越多,workflow的包袱越重,管理成本越大,说敏捷越可笑。

持续集成

首先是 WiKi 给出的定义:

continuous integration (CI) is the practice of merging all developer working copies to a shared mainline several times a day.

持续集成 的含义为:频繁的(一天多次的)将所有开发者的工作合并到主干上。

https://gitee.com/lienhui68/picStore/raw/master/null/20200913201803.png

从图例上来看持续集成的流程就十分清晰了:

  • 开发人员提交代码到 Source Repository (源代码仓库),并通过 git hook 等
  • 触发 CI Server(持续集成服务器)的相关功能。执行 编译 -> 测试 -> 输出结果 的流程,
  • 向开发人员反馈结果的 report

可以看出,持续集成的 核心 在于 确保新增的代码能够与原先代码正确的集成。与后续要介绍的持续交付以及持续部署,其最主要的差别也就在于其目标不同。

不过持续集成的流程还存在一定的异议:上图所示的流程为 Build -> Test,在阮老师的教程里头是 Test -> Build。不过,持续集成本身只不过是一种软件工程的方法或者策略,其并不规定具体的实现。在实际的应用中,还是需要结合具体的开发语言或者工具来定。

持续集成的优势

和我们一直在使用的 阶段集成(完成一个阶段的开发后执行代码的集成) 相比, 持续集成 的策略能够为我们带来哪些好处呢?

  • 易于定位错误:每一次的代码集成都需要执行相关的测试工作,持续集成频繁的集成次数天然的将复杂的代码逻辑切割为了小块,也就使得每一次测试中遇到的错误能够更加容易的被定位;
  • 易于控制开发流程:更为细致的工作提交也就意味着更容易判断当前的工作进度,这对于管理者规划开发流程而言提供了一个有效的参考,同时也为开发人员省下了汇报工作的时间;
  • 易于CodeReview:对于大块工作的切分自然也有助于做 CodeReview;
  • 易于减少不必要的工作:build 以及 test 过程的自动化可以为你节约一大票的时间,从而投入到有价值的工作中去。

持续交付

同样,以 WiKi 的定义开头:

Continuous delivery (CD or CDE) is a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, doing so manually.

持续交付 指的是:一种能够使得软件在较短的循环中可靠的发布的软件工程方法。

与持续集成相比,持续交付的侧重点在于 交付,其核心对象不在于代码,而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试,其变动到持续交付后还需要一些额外的流程。

仍然以图例说明:

https://gitee.com/lienhui68/picStore/raw/master/null/20200913202454.png

可以看到,与 持续集成 相比较,持续交付 添加了 Test -> Staging -> Production 的流程,也就是为新增的代码添加了一个保证: 确保新增的代码在生产环境中是可用的 。 在这一增加的流程中,Test 环节不仅仅包含基本的单元测试,还需要延伸到更为复杂的功能测试以及集成测试等。在这里,Staging 指的是 类生产环境 ,其尽可能的对真实的网络拓扑、数据库数据以及硬件设备等资源进行模拟,从而为测试人员反馈代码在生成环境中的可能表现。流程中每一个环节的执行结果都会对开发人员进行反馈,每一个出现的错误都会导致版本的回滚。当测试完毕确认无误之后,将由相关人员对其进行 手动部署到生产环境

持续部署

照惯例 Wiki 开头:

Continuous deployment (CD) is a software engineering approach in which software functionalities are delivered frequently through automated deployments.

持续部署 意味着:通过自动化部署的手段将软件功能频繁的进行交付。 与持续交付以及持续集成相比,持续部署强调了通过 automated deployment 的手段,对新的软件功能进行集成。

上图例说明:

https://gitee.com/lienhui68/picStore/raw/master/null/20200913202655.png

可以看到,同 持续交付 相比 持续集成 的区别体现在对 Production 的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预,完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度,保证新的功能能够第一时间部署到生产环境并被使用。

DevOps

介绍完了持续集成、持续交付和持续部署三大件,接下来在讲讲 DevOps。与三大件不同,DevOps 更偏向于一种对于文化氛围的构建。

还是搬出 Wiki

DevOps (a clipped compound of “development” and “operations”) is a software development methodology that combines software development (Dev) with information technology operations (Ops). The goal of DevOps is to shorten the systems development life cycle while also delivering features, fixes, and updates frequently in close alignment with business objectives.

DevOps 一词本身是对于 development 以及 operation 两个词的混合,其目的在于缩短系统开发的生命周期,在这过程中发布特性、修复bug以及更新均被紧密的结合。 听起来似乎有点玄乎,可以这样理解:DevOps 也即是促使开发人员与运维人员之间相互协作的文化。 DevOps 的概念似乎与持续交付的概念有些类似,两者均旨在促进开发与运维之间的协作,但是实际上两者差别很大:DevOps 更偏向于一种文化的构建,在 DevOps 文化指导下,团队中将包含了具有不同技能的人员(开发、测试等),并通过自动化测试与发布的手段,更快、更高质量的生产软件。

以图为例:

传统开发和运维

https://gitee.com/lienhui68/picStore/raw/master/null/20200913202822.png

使用DevOps之后

https://gitee.com/lienhui68/picStore/raw/master/null/20200913202828.png

在传统的团队组织方式中,开发人员与运维人员之间是割裂开的,软件开发流程被分割为多个独立环节,分别由不同的人员执行。这使得软件开发过程中需要付出高昂的沟通成本,层层手动的流程将大量的时间耗费在了重复的劳动中。 在 DevOps 的指导下,不同技能的人员处在同个团队中,为了一个共同的软件开发目标而工作,更好的协同工作与自动化的手段能够优化整个 Code -> Build -> Test -> Release -> Operate -> Code 的循环。这一理念看起来很美,用图画来说明就构成了一个和谐友好的大圈,不过在实际应用中也许会遇到不少问题,例如不同技能人员之间相互沟通的额外开销、团队组织形式改变后为管理所带来的困难等等。这些问题大概等到真正将 DevOps 在开发过程中开展来才能做解答了。

小结

  • 持续集成 是三者中最简单的,同时也是开销最低的。由于不需要类生产环境的配合,测试环境也可以仅支持单元测试的执行,使得持续集成的实现是最为便宜的。考虑到现实开发过程的种种限制,向资源与成本做妥协,舍弃持续交付或者持续部署这样看起来很美的方法,退而转向持续集成也是很合理的选择;
  • 持续交付 面向开发初期或者软件稳定性或者安全性要求较高的领域,新增代码提交、编译、测试等一系列环节均可以通过自动化工具完成,很好的节约了人力资源的同时,还对新增代码的功能进行了有效的保障。在手动执行的部署环节,还可以添加在执行完毕标准测试之外的可能需求,以保证发布功能的可靠;
  • 持续部署 面向稳定的发布上线后的功能更新。自动的,无需人工干预的部署可以保证新增功能第一时间被发布到生产环境中,确保其尽快的被用户所使用。其与持续交付相比,就在于其功能可靠性与功能及时性的侧重不同。