[翻译]DevOps with k8s 1-1 Introduction to DevOps

软件交付周期愈来愈短，而另外一方面，应用程序的规模愈来愈大。软件开发人员和IT运营商面临着找到解决此问题的压力。而有一个全新的角色，叫作DevOps，它致力于支持软件构建和交付。

本章包括如下主题：

• 软件交付方法是如何改变的？
• 什么是微服务，为何人们采用这种架构？
• DevOps如何支持构建应用程序并将其交付给用户？

Software delivery challenges

(软件交付挑战)

构建一个计算机应用程序并将其交付给客户，已通过了充分的论证，而且随着时间的推移不断演变。它与软件开发生命周期（SDLC）息息相关；有这么几种经典

的演变过程、方法论和发展历史，在本节中，咱们将详细描述它。

Waterfall and physical delivery

（瀑布模型与物理交付）

早在20世纪90年代，软件交付就采用了物理方法，如软盘或CD-ROM。所以，SDLC是一个很是长期的计划，由于它不容易（从新）交付给客户。

当时，一个主要的软件开发方法是瀑布模型，它有需求/设计/实现/验证/维护阶段，以下图所示：

在这种状况下，咱们不能回到前一个阶段。例如，在开始或完成实现阶段以后，不容许返回到设计阶段（例如，查找技术可扩展性问题），由于这将会影响到进度和成本，项目倾向于继续并完成发布，而后进入下一个发布周期，包括新的设计。

它与物理软件交付彻底匹配，由于它须要与物流管理部门协调，后者向用户发布软盘/光盘。过去，瀑布模型和实物交付须要一年到几年的时间。

Agile and electrical delivery

(敏捷与电子交付)

几年后，互联网被普遍接受，随后软件交付方式也从物理方式转变为电子方式，如在线下载。所以，许多软件公司（也被称为网络公司）试图找出如何缩短SDLC流程，以便交付可以击败竞争对手的软件。

许多开发人员开始采用新的方法，如增量、迭代或敏捷模型，而后更快地交付给客户，这样即便发现了新的缺陷，也更容易更新并经过电子交付做为补丁交付给客户，Microsoft Windows update也从Windows 98开始引入的。

在这种状况下，软件开发人员只编写一个小逻辑或模块，而不是一次性地编写整个应用程序。随后它便被交付给QA，开发人员继续添加一个新模块，而后再次交付给QA。

当所需的模块或功能准备就绪时，将按下图所示进行发布：

该模型使得SDLC周期和软件交付速度更快，而且在过程当中易于调整，由于整个周期缩短至几周到几个月，能够快速调整。

尽管这种模式目前受到大多数人的青睐，但在当时，应用软件交付意味着软件二进制，例如设计用于在客户PC上安装和运行的EXE程序。另外一方面，基础设施（如服务器和网络）几乎是静态的，而且须要预先设置好。所以，SDLC还不打算将这些基础设施也归入其中。

Software delivery on the cloud

（云软件交付）

又过了几年，智能手机（如iPhone）和无线技术（如Wi-Fi和4G网络）被普遍接受，软件应用也从二进制变成了在线服务。web浏览器是应用软件的接口，再也不须要安装。另外一方面，基础设施变得动态，由于应用程序需求不断变化，生产效率也须要提升。

虚拟化技术和软件定义网络（SDN）使服务器机器具备动态性。如今，Amazon Web services（AWS）和Google cloud Platform（GCP）等云服务能够很容易地建立和管理动态基础设施。

如今，基础设施是软件开发交付周期的一个重要组成部分，由于应用程序是在服务器端而不是在客户机上安装和运行的。

正由于如此，软件和服务交付周期如今只须要几天到几周的时间。

Continuous Integration

（持续集成）

如前所述，软件交付环境不断变化；然而，交付周期愈来愈短。为了实现更高质量的快速交付，开发人员和QA开始采用一些自动化技术。持续集成（CI）是目前流行的自动化技术之一。CI包含一些工具的组合，如版本控制系统（VCS）、构建服务器和测试自动化工具。

VCS帮助开发人员在中央服务器上维护程序源代码。它能够防止重写或与其余开发人员的代码冲突，还能够保留历史记录。所以，保持源代码的一致性并将其传递到下一个周期变得更容易。

与VCS同样，有一个集中的构建服务器，它链接VCS，以便在开发人员将代码更新到VCS时按期或自动检索源代码，同时触发新的构建。若是构建失败，它会及时通知开发人员。所以，，它能够帮助开发人员避免将有BUG的代码提交到VCS。

测试自动化工具还与构建服务器进行集成测试，后者在构建成功后调用单元测试程序，而后将结果通知开发人员和QA。它有助于识别什么时候有人编写了错误代码并存储到VCS中。

CI的整个流程以下图所示：

CI不只能够帮助开发人员和QA提升质量，还能够缩短应用程序或模块包的归档周期。在向客户提供电子交付的时代，CI已经足够了。可是如今则远远不够，由于在当前，交付给客户意味着部署到服务器。

Continuous Delivery

（持续交付）

CI plus部署自动化是服务器应用程序向客户提供服务的理想过程。然而，还有一些技术挑战须要解决。如何向服务器交付软件？如何优雅地关闭现有应用程序？如何替换和回滚应用程序？若是系统库也须要更改，如何升级或替换？如何根据须要修改操做系统中的用户和组设置？等等。

由于基础设施包括服务器和网络，因此它都依赖于诸如Dev/QA/staging/production这样的环境。每一个环境都有不一样的服务器配置和IP地址。

持续交付（CD）是一种能够实现的实践；它是CI工具、配置管理工具和编排工具的组合：

Configuration management

（配置管理）

配置管理工具备助于配置一个操做系统，包括用户、组和系统库，还能够管理多个服务器，若是替换服务器，这些服务器将与所需的状态或配置保持一致。

它不是脚本语言，由于脚本语言执行基于脚本的命令。若是咱们执行两次脚本，可能会致使一些错误，例如，尝试建立同一个用户两次。另外一方面，配置管理会查看状态，所以若是已经建立了用户，配置管理工具不会执行任何操做。可是，若是咱们意外或故意删除用户，配置管理工具将再次建立该用户。

它还支持将应用程序部署或安装到服务器。若是告诉配置管理工具下载应用程序，而后设置它并运行它，它会尝试去运行这些步骤。

此外，若是告诉配置管理工具关闭应用程序，而后下载并替换到新的软件包（若是可用），而后从新启动应用程序，它将保持最新版本。

固然，有些用户只想在须要时更新应用程序，例如蓝绿部署。配置管理工具也容许您手动触发执行。

tips

蓝绿部署是一种准备两组应用程序栈的技术，而后只有一个环境（例如：Blue）为生产服务。而后，当须要部署新版本的应用程序时，部署到另外一侧（例如：Green），而后执行最终测试。若是工做正常，更改负载均衡器或路由器设置，将网络流从Blue切换到Green。而后，Green变为生产，而Blue变为休眠状态，等待下一个版本的部署。

Infrastructure as code

基础设施即代码

配置管理工具不只支持操做系统或虚拟机，还支持云基础设施。若是须要在云上建立和配置网络、存储和虚拟机，则须要一些云平台操做。

但配置管理工具备助于经过配置文件自动设置云基础设施，以下图所示：

配置管理相对于维护操做手册标准操做程序（SOP）有一些优点。例如，使用Git等VCS控制软件维护配置文件，能够跟踪环境设置如何更改的历史记录。

复制环境也很容易。例如，您须要在云上的其余环境，若是遵循传统方法（即读取SOP文档以操做云），则它始终会存在潜在的人为错误和操做错误。另外一方面，咱们能够执行配置管理工具，该工具能够快速、自动地在云上建立环境。

Orchestration

(编排)

编排工具也被归类为配置管理工具之一。可是，在配置和分配云资源时，它更加智能和动态。例如，编排工具管理多个服务器资源和网络，而后当管理员但愿增长应用程序实例时，编排工具能够肯定可用的服务器，而后自动部署和配置应用程序和网络。

尽管编排工具超出了SDLC的范围，但当须要扩展应用程序和重构基础设施资源时，它有助于持续交付。

总的来讲，SDLC已经经过几个过程、工具和方法来实现快速交付。最终，软件（服务）交付只须要几个小时到一天的时间。同时，为了实现更大型和更丰富的应用，软件体系结构和设计也在不断发展。