一年5000万次配置是怎么着一种概念,DevOps工具的

2020-04-16 作者:亚洲城动态   |   浏览(102)

本文根据张孝峰老师在〖Gdevops 2017全球敏捷运维峰会广州站〗现场演讲内容整理而成。

Fbric、Ansible、Docker、Chaos Monkey:DevOps工具的年中回顾

【编者按】近日,Cyber Engineering Solutions Group 技术经理 Hasan Yasar 在 SEI 攥文盘点了当下流行的 DevOps 思想和工具,其中包括Fabric、Ansible、Docker、Chaos Monkey等。本文系 OneAPM 联合高效运维联合编译整理:

在2014年年底,SEI 博客发表了一系列有关 DevOps 的博客文章,提供指南,实用的建议和教程。这些帖子针对越来越多的采用 DevOps 的企业(2011年以来,高达26%)。根据最近的研究,这些组织部署变更代码比传统的方式快30倍。尽管 DevOps 的好处显而易见,但是许多企业仍不敢采用 DevOps,因为这需要转变心态、文化和技术要求,对于传统企业是非常大的挑战。鉴于这些障碍,CERT 研究人员的文章主要集中在介绍 Amazon和 Netflix DevOps 的成功案例,以及一些 DevOps 流行技术的教程,如 Fabric、Ansible 和 Docker。这个帖子介绍了过去六个月,10个最流行的 DevOps 相关文章(根据访问次数排序)。

讲师介绍

1. DevOps 技术:Fabric 与 Ansible

这篇博客文章 DevOps 技术:Fabric 与Ansible中,CERT 研究人员 Tim Palko 重点描述了使用 DevOps 部署过程相关的情况,包括评估资源需求、设计生产系统、配置和生产服务器的配置、同步代码等等。

以下为摘录:

部署代码的工作流程几乎和代码本身一样古老。有许多与部署过程相关联的用例,包括评估资源需求、设计一个生产系统、配置和配置生产服务器、同步代码等等。在这篇博客文章中,我将会专注于配置一个远程服务器上的软件包和必要的软件来执行您的代码。这个用例可以使用许多不同的,相互竞争的技术完成,如:Chef、Puppet、Fabric、Ansible、Salt、Foreman,这些只是少数你可能已经听到过的有关 DevOps 自动化运维之路的技术。所有这些技术都有提供仓库,可以提交脚本到仓库,并完成任务。这篇文章更深入的探讨了Fabric 和 Ansible。要了解更多关于其他基础设施即代码的解决方案,看看Joe Yankel 关于 Docker 的文章或我的关于 Vagrant 的文章。

Fabric 和 Ansible 之间的一个区别是,Fabric 会让你在几分钟内看到结果,而 Ansible 需要付出更多的努力去理解。通常来说,Ansible 是更强大的,因为它提供了更深入和更复杂的多层架构模型的语义,如 Web 和数据库主机阵列。从运维的角度看,Fabric 具有更直接和基本 API,可以使用 Python 编写,而 Ansible 使用 YAML,提供了丰富的操作(我以后再讨论这篇文章)。我们将通过这篇文章中的例子来说明。

阅读完整的文章 DevOps 技术:Fabric 与 Ansible 请访问

张孝峰,AWS资深架构师,20年技术研发经验。

2.DevOps 之 Docker

今天将跟大家分享一下亚马逊AWS在DevOps方向的一些见解。AWS其实是在亚马逊整个DevOps沃土中发展起来的一个产品体系,所以在讲AWS时,我希望给大家看到的不是一个服务的广告,而是一些DevOps理念真正的实现。

3.使用Dokcer做开发

Docker 这些日子在 DevOps 社区是相当火爆,这有很好的理由。Docker 容器使开发和部署应用软件达到可控制的、隔离的、灵活的和高度可移植的基础设施。在 DevOps 和 Docker 这篇文章中,CERT 研究员Joe Yankel介绍了使用 Docker 开发和部署软件应用程序的可扩展性,资源效率,以及弹性。

以下为摘录:

Linux 容器技术(LXC),为 Docker 的建立提供了基础,然而这并不是一个新想法。LXC 早已出现在 Linux 内核2.6.24版本中,当控制族群(或 cgroups)正式被集成时。实际上谷歌早在2006就使用了 Cgroups 技术,因为谷歌一直在寻找,在共享硬件上进行资源隔离和运行的方式。事实上,谷歌承认每周会启动200万个容器,使用自己发布的 LXC 容器imctfy。

不幸的是,这种技术并不容易被采用,直到 Docker 来简化容器技术,使它更易于使用。在没有 Docker 的时代,开发者很难访问,实现,更不用说要理解 LXC 的优点。DotCloud创始人、现任首席技术官 Solomon Hykes 发现 Docker 的潜力,在2013年三月份Docker作为开源项目被发布。Docker的易用性是由于其高层次抽象的API以及文档,使得 DevOps 社区充满力量,并创建 Docker 教程、官方化应用程序和许多其他的技术。通过降低进入容器技术的门槛,Docker 已经改变了开发人员共享、测试和部署应用程序的方式。

在这篇文章使用 Docker 开发中,Yankel 描述了如何开始使用 Docker 在一个普通的软件开发环境开发相应的软件,通过启动一个数据库容器(MongoDB),一个 Web 服务容器(Python Bottle APP),并配置它们可以互相访问。这是一个多容器应用程序。

以下为摘录:

如果你没有事先了解过 Docker,你应该去官方教程学习一下教程再在这里继续。

在开始教程之前,你需要有一个虚拟机或其他兼容 Docker 的主机。按照下面的说明创建演示程序所需的源文件。为方便起见,从我们的 GitHub 库上下载所有源文件并跳转到演示部分。我们的源代码包含一个 Vagrant 的配置文件,自动配置能够运行的正确环境。这里可以看看我们有关Vagrant的帖子。

阅读完整的文章,DevOps 和Docker,请访问

阅读完整的使用 Docker 开发,请访问

关于DevOps

4.亚洲城官网,DevOps 示例:Amazon AWS

经常阅读DevOps 博客的读者会发现这个系列中会反复出现的主题:DevOps 本质上是通过精心的构建组织过程、加强沟通和工作流程来提升质量。通过学习知名高科技公司的技术管理和软件工程,我们的系列文章,可以从真实世界的案例中获得非常大的价值和相关的结果。这些案例也为 DevOps 从业者的提供非常优秀案例。在DevOps 示例:Amazon AWS,C. Aaron Cois 分享了 Amazon DevOps 的经验。

以下为摘录:

Amazon 是当今最多产的科技公司之一。Amazon 在2006年时做了转变,从一个在线零售商,转变成一个科技巨头,并发布了(AWS),成为云服务的先锋,AWS 提供了广泛使用的一种按需配置的基础设施服务(IaaS)。Amazon 的 AWS 承受了大量的风险。通过开发第一个大规模的公共云服务,他们了解了很多的挑战都是未知的,有许多未经证实的解决方案去证实。要学习亚马逊的成功,我们需要问正确的问题。亚马逊采取什么措施来减少这种固有风险的风险?亚马逊工程师如何定义他们的过程,以确保质量?

幸运的是,当谷歌工程师Steve Yegge(前亚马逊工程师)意外地公开了一份内部备忘录,概述了他所了解的谷歌平台工程的失败(亚马逊的成功)。这使我们可以大致了解 Amazon 成功的过程。这本备忘录(这 Yegge 特别允许可以在网络上传播)概述了具体决策,描述了首席执行官 Jeff Bezos 的基本原则,这些原则我们现在称之为 DevOps,以及 AWS 平台的质量属性:互操作性、可用性、可靠性和安全。

阅读完整的文章,DevOps 示例:Amazon AWS, 请访问
.

大家对DevOps也比较清楚了,我们不希望研发人员直接把代码丢给运维,再让运维去做,因为代码的发布是一次发布成千上万个,如果出现问题,我们不知道怎么去修改,我们的希望是让整个代码发布、整个运维更加顺畅。所以在亚马逊,DevOps需要管理很多很多方面的问题:包括了基础设施、IT自动化和配置管理、版本控制的集成、持续集成和持续交付、持续部署、应用和基础设施的版本管理、监控和日志管理等。

5.DevOps 示例:Netfix的Chaos Monkey

DevOps 经常被运用在如敏捷开发、自动化和持续交付,DevOps 的精神可以应用在很多方面。在这篇博客中,C. Aaron Cois分享了另外一个具有开创性的 DevOps 案例研究,Netflix的一些开箱即用的方式。

以下为摘录:

Netflix 是一个奇妙的案例研究,因为他们的 DevOps 软件工程过程,展示了一个对 DevOps 本质的了解,专注通过 DevOps 自动化辅助过程来达到质量要求。DevOps 从业者信奉一种注重质量属性的驱动来满足业务需求,利用自动化过程实现一致性和效率。

Netflix 的流媒体服务是一个托管在AWS的大型分布式系统。由于这么多组件一起工作,为各个地区的客户提供可靠的视频流,Netflix 工程师需要侧重于服务端-客户端组件质量属性的可靠性和鲁棒性的。总之,他们得出结论认为,处理失败的唯一方法是不断实践失败。为了实现如此可信赖的,质量达标的水平,使用 DevOps 的风格,Netflix 公司的工程师开始使用自动化故障方案。

阅读完整的文章 DevOps 示例:Netfix 的 Chaos Monkey,请访问

亚马逊的DevOps故事1、亚马逊开发流程的演进

6.DevOps 和敏捷开发

Melvin Conway,一个杰出的计算机科学家和程序员,创造了康威定律,康威定律说:设计系统的组织,最终产生的设计等同于组织之内、之间的沟通结构。因此,一个公司的前端、后端和数据库团队可能会倾向于使用三层架构。在很大程度上,应用程序的结构,是由组织沟通后产生。简而言之,形式是交流的产物。

在文章DevOps 和敏捷开发中,C. Aaron Cois学习康威定律并应用到自己的组织。

以下为摘录:

传统的,但不足的,瀑布式开发模式已经为我们的应用程序定义一个特定的沟通结构:开发开发人员让(QA)团队测试并质量保证,QA 让运维(OPS)团队去部署。这种方式的沟通,是非敏捷的,加重了我们有缺陷的组织结构,这又是一个印证了康威定律的例子:组织结构决定产品。

阅读完整的文章DevOps 和敏捷开发,请访问

传统应用发布的4个阶段:冗长的周期和复杂的协作

7.DevOps 团队需要 ChatOps

项目团队关键利益相关者之间的对话(例如,开发人员、业务分析员、项目经理、安全团队),平台之间的沟通,可以对协作产生深远的影响。较差的或甚至没有使用通讯工具,导致沟通不畅,重复的工作,或错误的实现。另一方面,开发和业务基础设施相结合的通信工具,可以加快向组织交付业务价值。一个团队如何组织基础设施结构,如何沟通,将直接影响团队的效率。

在文章DevOps 团队需要 ChatOps中,CERT研究员 Todd Waits 介绍了 ChatOps,DevOps 的一个分支,关注 DevOps 团队的沟通。ChatOps 包括了团队的沟通和协作工具:通知、聊天服务器、机器人、问题跟踪系统等等。

以下为摘录:

在最近的一篇博客中,Eric Sigler写道,ChatOps,一词起源于GitHub上,都是关于基于对话的驱动开发方式。“把你的工具带到您的沟通过程中,并使用一个聊天机器人修改关键的插件和脚本工作,团队可以自动执行任务和协作工作,使工作更好、更便捷、更快”Sigler写道。

大多数团队在聊天服务器上都有一定程度的合作。聊天服务器可以作为一个城市广场一样容纳开发团队、促进团队之间的凝聚力、讨论实际问题以及潜在解决方案等。我们希望所有的团队成员使用聊天服务器。在我们的团队中,为了避免一般聊天室的灌水聊天,我们也创建专用聊天室,每个项目,项目团队成员可以谈论项目的细节,不涉及其他的团队。

和其他简单的沟通介质不一样,聊天服务器可以智能化,开发的基础设施,向团队传递通知,团队执行命令并反馈回基础设施。我们的聊天服务器是通知的枢纽,与我们的基础设施快速互动。项目团队通过聊天服务器接到通知(还有其他方法),关注基础设施任何生成状态,他们关注:构建失败、构建成功、超时等。

阅读完整的文章DevOps团队需要ChatOps,请访问

亚马逊作为一家非常庞大的电商公司,最早进行开发时也有很多的团队,把它分在一个代码里去发布,然后在开发时会用一种很传统的源码编译、特色生产的过程去做。

8.DevOps之Vagrant

环境等同是一个理想的状态,在不同的环境中执行代码都将正常运行。缺乏环境等同会使软件开发陷入令人沮丧的困境。部署和开发都经常会陷入这样的陷阱,降低了稳定性、可预测性和生产力。当环境不等同时,这使得故障难以排除,而且难以协作。这种缺乏环境等同使开发人员和运维人员负担太多。

在这篇博客中DevOps 之 Vagrant,CERT研究员 Tim Palko 描述了 Vagrant,这是一个开发者使用的工具,提供了一个虚拟化和环境配置,Vagrant 为开发者提供了一个单一的,声明式脚本,以及一个简单的命令行界面。通过使用相同的预先配置的 Vagrant 脚本,Vagrant 为所有开发者统一了线上的环境。Vagrant 的消除了“环境不同”的借口,在应用开发生命周期过程中。

以下为摘录:

运维团队的作业通常包括在所有部署环境中实施全面的校验,例如用于测试、分段和上线。相反,开发团队几乎完全自己负责配置开发机器。为了达到百分之100的环境等同,两个团队必须使用相同的语言,使用相同的资源。

Chef和Puppet,这两个都是为运维而生,对一个繁忙的开发人员来说可能不太友好。Chef和Puppet都有一个比较陡的学习曲线,并没有真正解决环境等同的问题:开发者仍然需要和线上环境同步。所有这些额外的工作会带来一个相当大的开销,而你只想好好的写业务代码!

这就是Vagrant出现的意义。Vagrant是一个面向开发者的工具,基本上Vagrant提供了一个虚拟化环境,提供了一个单一的,声明式的脚本和一个简单的命令行界面。Vagrant通过启动一个虚拟机(VM),去除繁重的工作,消除了人工配置或运行,例如,chef-server和chef-client。Vagrant的隐藏这一切,提供一个简单的脚本给开发人员,一个名叫Vagrantfile无扩展项文件,可随着代码签入到源代码控制。

阅读完整的文章DevOps之Vagrant,请访问

亚马逊开发形式的转变:2001-2009

9.使用DevOps解决上下文切换的不利影响

在计算系统中,上下文切换发生在,操作系统保存一个应用程序线程的状态,停止线程并恢复其他线程的状态(之前停止线程),使其他线程恢复执行。上下文切换管理的开销,发生在处理状态的保存和恢复,这个过程会对操作系统产生负荷,并影响应用程序的性能。在博客使用DevOps解决上下文切换的不利影响中,CERT研究员Todd Waits描述了如何使用DevOps改善负面影响,减少项目之间的“上下文切换”对软件工程团队效率的影响。

以下为摘录:

Quality Software Management: Systems Thinking, Gerald Weinberg在这本书中讨论了,上下文切换的概念是如何适用于一个工程团队。从人力劳动力的角度来看,上下文切换是一个项目停止工作的过程,并在不同的项目上完成不同的任务后,将其重新捡起来。就像计算机系统一样,在多个项目之间进行上下文切换时,团队成员通常会产生开销。

当团队成员被分配到多个项目时,上下文切换通常会发生。上下文切换的合理理由是,逻辑上来讲,为团队成员分配项目任务,比为每个项目分配专用资源更省时省力。这似乎是合理的假设,将一个人的精力平分,对每个项目,两者之间的项目收益率百分之50。此外,如果一个团队成员只在一个单独的项目中,如果这个项目正在等待处理某些事情,比如等待书面工作审批、审查等,该小组成员将是空闲的,没有充分利用。

使用我们计算系统的隐喻,任务之间的切换类似多线程概念,如果一个线程因为某些事情阻塞,其他线程可以执行其他工作,而不是等待第一个线程直到恢复。如果所有的工作只分配给第一个线程,进展很慢。虽然多线程在计算系统中很合理,问题是,人类并不总是能很好分配精力。因此效率会在上下文切时损失,生产力可能会在精力分散在更多的项目的时候下降。

阅读完整的文章使用 DevOps 解决上下文切换的不利影响,请访问

这个过程持续了很久,直到2001年,我们的创始人跟一个巨大的运维团队将里面越来越多的开发运维进行了改善,所做的就是把整个亚马逊的服务拆成很多微小的服务。当时在内部有个说法,可以看到就是上图中的2 pizza teams,即我们希望用两张披萨饼就可以喂饱每一个承担这些微服务的团队,这一点在亚马逊内部是贯穿始终的。两个披萨饼、一顿午饭,大概就是说2到10来个人的团队,这个情况下每个团队都是在这么小的一个范围内,他们能对外提供一个统一的标准化的接口,内部也可以用自己的方法去构建自己的服务,去保证整体的服务是一个统一的整体。

10.什么是 DevOps?

通常,当我们设想一个实现了 DevOps 的组织,我们可以想象一个自动化运转良好的机器

  • 基础设施配置
  • 代码测试
  • 应用部署

最终,这些做法的结果是运用 DevOps 的方法和工具。DevOps 适合所有规模的团队,从一个一个人的团队到一个企业组织。在这篇博文中,什么是 DevOps,CERT 研究员 Todd Waits 介绍了 DevOps 的基础。

DevOps 可以看作是敏捷方法的推广。它要求掌握相当多的知识和技能,包括一个项目从开始到持续,到被一个专门的项目小组负责。组织壁垒必须打破。只有这样才能有效地缓解项目风险。

以下为摘录:

然而严格来说,DevOps 并不是持续集成,交付或部署。DevOps 的做法能使团队达到协调,理解必要的自动化基础设施、测试和部署。特别是,DevOps 提供了组织如何保证:

  • 不同项目团队人员之间的合作
  • 基础设施即为代码
  • 自动化任务、过程和工作流程
  • 监控应用和基础设施

商业价值驱动 DevOps 的发展。如果没有 DevOps 的心态,组织经常发现他们的运维、开发和测试团队,目光短浅,只致力于创建方便自己的基础设施、测试套件或产品增量。一旦一个组织打破了这些孤岛,把这些领域的专业知识整合起来,就可以把重点放在共同致力于提供商业价值的基本目标上。

组织良好的团队会发现(或创建)工具和技术,使他们的组织实践 DevOps。每个组织都是不同的,有不同的需求,不同的但是必须满足的需求。DevOps 的关键,并不是一个杀手级的工具或脚本,而是合作文化和传递价值的终极承诺。

阅读完整的什么是DevOps,请访问

每两周,SEI 会发布一篇新的博客,为那些尝试采用 DevOps 的组织提供指南,实用的建议和教程。我们欢迎您对本系列文章提供反馈,以及对未来内容的建议。请在下面的评论部分反馈意见。

原文链接:Fabric, Ansible, Docker, and Chaos Monkey: The DevOps Mid-Year Review

OneAPM 是应用性能管理领域的新兴领军企业。想阅读更多技术文章,请访问 OneAPM 官方博客。

这样的情况下,我们通过构造一个巨型的面向服务的架构,单一地通过不同的APL调用,把整个亚马逊的各种服务进行一个高度的解耦,最后达到的效果就是每一个团队都有自己的持续集成、持续交付、持续发布的灵活情况。

软件生命期新的管道

这个情况可达到怎么样的效果呢?可以达到一年5千万次的部署,如果按工作日来算,就是平均下来一年里每11秒就可能会有一个小版本部署上去,这个版本部署可能只有几十行代码的修改,然后2 pizza teams会针对这个版本做自己的回归测试、单元测试,保证自己提供出去的APL是稳定可靠的。

总体通过一个巨型的架构,利用中间的微服务APL调用来保证我们整体去做,所以可以同时部署在很多不同的服务器、应用上,这是亚马逊今天能够做到的。

我们屏蔽了以前旧的软件交付方式,可能要用很多不同的版本,甚至用十几个介质来配适我们的客户,包括在亚马逊AWS上的客户,他们已经可以很好地用新的这种交付方式去做。这里,亚马逊想到,除了能够让我们自身的团队变成这样,其实能不能为我们的客户去做到这样一个微服务的架构或持续集成的架构,于是就有了亚马逊AWS服务体系的诞生。

接下来我会介绍AWS这部分DevOps方向的一些服务,通过这个服务去看到我们如何能够在一个云端非常敏捷地实现DevOps,同时也会介绍到一些DevOps的框架和工具。

基于AWS服务实现DevOps的框架和工具1、AWS对DevOps的全面支持

首先AWS对DevOps是全面支持的,包括从代码的提交到各种的FreeWork Test,然后会有SDK去调用我们的APL,去使用平台的各种基础设施,建立流畅的自动交互渠道,下图是我们整个持续流程的模型。

这个模型也包括了我们整个域名服务。域名服务很多情况下跟我们整个DevOps的服务是一个最基础的入口,因为访问是通过域名去进入的,那么,我们在域名这一端通过一个智能DNS可以做到蓝绿发布这样一些动作,然后通过我们的基础服务来获得基础服务提供的这些服务。这个基础服务旁边是各种的源代码库,还有项目管理库会用去构造不同的服务,去自动化地持续集成到我们实际的服务里去。

持续集成模型

2、AWS CodeCommit

第一步接触到的是AWS的Codecommit,你可以认为它是一个代码管理库,它在整个AWS Devops服务体系中是处于最左边的位置,就是在我们的开发、版本管理这个方向,那么它能够提供一个怎样的东西呢?

它其实是一个Git的服务,就像现在大家都会使用Github去管理自己的代码,那么在AWS的Codecommit,它是一个典型AWS微服务的结合,它会用到AWS S3这样的对象储存服务去储存代码实际的部分。因为在这种情况下,相比传统的磁盘,S3会有一个更好的方式去储存一些大文件。作为一个海量的代码库,它对一些大的分区或者大尺寸文件的储存会有更好的优势,而后我们会使用Amazon的NoSQL服务去作为它的元数据管理。这个在Git里面,我们的版本控制、各种分支的控制,都可以在这边去做到,我们也可以通过KMS去加密存在AWS的代码,因为相信对很多公司来说,做好自己源代码的保密性是非常重要的。

有了这样一个Git的服务之后,我们就很容易会去构造企业私有化的一些仓库。众所周知,如果我们使用Github的方式去管理,它的私有化仓库是要付费的,那在CodeCommit这样的方式里,我们是可以提供免费的私有化仓库,只需要出少量的储存费用就可以去做,所以这个本身也是一个由亚马逊自身微服务组合而成的一个组合型服务。

AWS CodeCommit使用方式

关于Git的提交大家也都很熟悉了,其实可以把Codecommit作为我们最常见的一种方式,因为Git的仓库其实是平行的,所以Codecommit作为我们的远程仓库,它可以跟本地一些分发的仓库平行地去做,可以把需要做云端的Devops的部分作为一个特殊的Commit权限,或者叫Push的权限放到云端去,同时本地还可以维护这样的Git仓库。

3、AWS CodePipeline

有了这个代码以后,就需要在云端去构造一个Pipeline流程,或者说一个持续集成的流程,我们可以通过CodePipeline这样的可视化工具去调动云端的服务,去进行各种自动化的持续集成工作。

AWS CodePipeline管道流程

这个持续集成的工作通常包括了好几块,会有代码、构建、各种的Staging,我们需要在不同的Staging里面去做不同的测试,可能我们有些项目里需要一些人工的审批,确定是否去不到我们实体的生产环境里去,这一部分无论是自动化的流程还是人工审批的流程,我们都能可视化地构建在Codepipeline流程里,去让它很完善地流动起来,数据也就可以很好地在这上面去做。

这个是CodePipeline界面的截屏,我们可以把Source、Beta阶段、QA阶段通过一个很好的可视化工具去做,相信在座的各位应该用过Jenkins,或者别的一些开源工具,都能够构造出一个很好的Pipeline。在AWS上面,大家可以沿用自己传统的一些使用工具或已经非常熟悉的工具去做,这些都是支持的,包括我们的Codecommit,也会有相应的Jenkins插件去集成。如果是初创企业或者新的研发团队直接使用云端的资源,也可以大大节省学习成本和部署成本。

4、AWS CodeBuild

有了CodePipeline和CodeCommit以后,我们就有了流程,有了源代码,这时可能就需要一个很重要的编译。编译环境在很多的开发团队或者说在DevOps过程里是非常重要的,很多团队可能会使用Jenkins或者别的一些工具去构造这样的编译流程,但AWS CodeBuild是在具有弹性的云端编译工具和环境中,它会预先帮大家构造好一些成熟、常见的编译环境,比如安卓、Java、Golang等各种的编译,当然JS不算是一种编译了,但JS的项目通常也需要打包,所以我们就无需重头去建立这样的一个编译环境。

AWS CodeBuilde工作流程

另外还有个非常重要的事情,在很多已经很成熟的团队里,可能公司内部已经构造了一些很好的编译环境,这些我们也已经搭建了,但没办法避免的一件事就是我们的本地资源是有限的,很有可能在不同的团队下面,我们可能刚好有一个大的发版情况,比如说在双11前我们会集中式地去做一些开发,这时可能同时有好几个团队都在编译,这种情况下,我们的资源就很有可能会不足。但在AWS CodeBuild的过程中,每一个团队去创建一个CodeBuild实例时,它其实都是在云端申请了一段新的资源,这时它的资源永远是不会跟别的团队去竞争的,这个情况可以大大保证我们的开发团队整个开发的过程,而不会因为一些开发流程的竞争而导致实际工作被阻塞,这个是云端一个非常大的好处。我们在云端去构造比如Jenkins这样的环境时,其实也很难去构造一个完全弹性的环境,而CodoBuild里是有一些已经内置好的,当然如果有一些自己的发布情况,也可以把自己打包成一个Docker的镜像,作为一个Customers的Codobuild镜像发布上去。

有了CodePipeline、CodeCommit、CodeBuild以后,我们就能在云端很容易地构造一个持续集成的完整链条。我们的代码Commit以后,有一个很常见的开发过程,比如说我们本地有一个开发团队,他们本地可能使用Gitlab建了自己的一个开发的Git仓库,本地仓库进行完一个简单的单元测试以后,它就可以通过这个团队的管理员,比如说他是有权限去把这个代码Push到远端的CodeCommit的仓库,那么这个代码一旦进到Codecommit仓库,后面的流程就完全自动化,CodePipeline会发现Codecommit的一些改动,然后会把这个代码拖下来,启动一个Codebuild的环境进行一个编译,接下来我们还可以持续地结合一些测试的工具进行一个代码测试,步入单元测试,或者说一个QA的测试,而生成的代码我们可以放在S3上面,这样就完成了一个持续集成的过程。

AWS 持续集成

这是一个在云端很顺畅的过程,当然,即使我的一些客户他们也在云端构建了类似的过程,他们也不一定要使用到亚马逊的服务,最重要一点是,在云端的一些资源,因为都是弹性的,在不适用时,Build服务器其实不会占着我们的使用费用或开机费用,CodePipeline也会在后面默默地等待Codecommit的存储,所以在整个开发的过程中,如果我们很多时候可能都没有动到这一块,它整个过程是没有产生任何费用的,只需稍微给一些代码存储的费用,只有当我们的代码真正进入到远端的分支以后,它才会开始启动AWS云端的服务,去产生这样的一个实际的集成。有了持续集成以后,我们就要进行持续地部署了。相比持续交付,持续部署更多的一个情况在于部署过程中,会把人工化尽可能地减少,逐步地做到完全自动化的部署。

持续交付与持续部署的区别

5、AWS CodeDeploy

我们会有CodeDeploy这样一个服务,CodeDeploy的服务其实是处于AWS整个Devops体系中一个承上启下的作用,它往后会跟我们的CodePipeline去做集成。

当CodePipeline做了一个测试以后,它就可以往前去调用我们的各种基础设施,去生成一些真正的生产环境或者说蓝绿测试的环境,去部署我们的软件包在上面,并且调用一些测试的过程。CodeDeploy能够很容易地通过一个很可视化的部署,去把我们的实际的软件包发布到不同的环境里,比如说我们有开发的环境、测试的环境,还有生产的环境,它可以集中化地控制成千上万台不同的服务器,然后做滚动的发布等各种情况。

这是一个很典型的部署流程,我们可以通过自动化部署直接发布到实际的应用里面去,比如说Instance,在亚马逊上面就是我们实际的实例,可以通过Auto-scaling group去按照我们实际的一个业务流量去扩展这个实例,并且这些扩展也是可以被自动关联起来的。

这个是CodeDeploy的一些语法,它使用YAML的方式去定义一个实际的版本控制,在整个Deploy的过程中,我们可以控制它的代码在什么地方,安装包在什么地方,安装成功前后,我们都可以做不同的Staging动作。

此外,我们可以去编排不同的目标组,因为不同的目标组可能会有不同的实例大小,或者实例组。

这个其实在很多的团队里都会用到,他们开发的环境会有这样的一些环境,在我们的生产环境会有更多、更强劲的服务器去做,这些东西我们都可以通过CodeDeploy的一个描述把他们全部描述完成,有了这样的部署以后,现在一键就可以去创造整个部署的目标,包括CodePipeline也可以直接调用这样的CodeDeploy去做。

还有很重要的一点,就是我们可以在云端很好地去调用云端弹性的资源,去构造不同的发布方式。比如说我们在云端希望保证一个数据的可用性,可以把它变成一次一台的发布、一次一半的发布或者一次全部的发布。

图:Codedeploy如何工作

图:CodeDeploy就地部署

其实在云端还有一些更好的发布方式,因为一般来说,云端的资源像开水龙头一样,您可以认为它是无限的,所以我们的Auto Scaling Group会去做一个折算的弹性发布。比如说我们原来的业务在生产系统里面本来是有三台机器的,然后需要去扩展我们业务或者发布一个新版本时,我们可以在很短的时间内在云端产生一台新的机器,把我们实际的新的版本放到这台新的机器上面去,再通过刚才说过的域名方式或AWS负载兼容器的方式,把一部分的流量往这个地方去发布,这个情况其实构成了一个蓝绿的发布。

这个蓝绿发布在绿的部分完全是一个新的机器,不会干预到我们实际的生产环境的机器,我们通过这样域名的方式去把一部分的流量引入到绿方的新发布里去,然后通过云端的工具去监控绿方这边的动作。刚才说到的,我们可能会监控它的错误码、订单下载量等,发现这个绿的部分情况完全没有问题后,我们可以在云端逐步地增加绿这边的流量和它实际的机器数量,最终我们发现在新的版本环境已经完全可以支撑服务了,我们再移步把蓝方这边旧的环境全部给切换掉,把机器也关闭掉,这里成本几乎是没有增加的,增加的只是在这几个小时的发布过程中一个双倍机器的成本,之后我们还是用一样的机器去支撑一样的服务,这是一个在云端蓝绿发布非常好的实践。

所以,当CodePipeline加上CodeDeploy,我们就可以很好地控制持续部署的流程,后面我还会介绍OpsWorks和Elastic Beanstalk,折算子的基础设施即代码的服务。这个也是我们希望做到的一点。

6、基础架构代码化

刚才说到了AWS其实是亚马逊微服务化的过程中的一个产物,在这个过程中我们发现这种经验不仅仅可以帮助到自己,也可以帮助到我们的客户,所以我们在2006年就发明了这样一个公有云的服务。这个公有云服务一个很重要的过程,就是说我们希望公有云上面的一切东西都是一个API,有了这个API以后我们就可以用代码去描述我们在公有云上的每一项服务。所以在AWS DevOps服务的右手边,包括部署、搭建、监控、运维等,这都是一些基础设施即代码的服务,这里面包括了我们的Elastic Beanstalk,就是说如果我们的团队仅仅是开发一个PHP的集成环境或Tomcat的集成环境,我们并不需要很复杂的互相访问架构,这时就可以使用Beanstalk;如果是需要描述一些很复杂的互联方关系,可以使用CloudFormation这样一个YAML或者JSON放入描述语言,去快速地构造云端的整个基础设施。

当然,如果你的团队在Chef这方面有很深的研究,也可以使用我们的OpsWorks,按照Chef的方式去定义整个环境的各种Layer,而且我们可以直接使用在社区各种Chef的Code去调用AWS的环境。

图:操作AWS服务的三种方式

首先这是AWS服务的三种服务方式,很多人刚刚接触AWS时,第一个接触到的一定是左手边的Web控制台,Web控制台是很重要的一个用户界面,我们可以在Web控制台上控制大部分的AWS服务,但其实这些Web的控制台上面的每一项功能,后面都会对应着一个DevOps API或SDK,然后可以通过我们的开发或命令行去操作这样的DevOps工具,有了这样的基础以后,就能做到各种基础设施即代码的服务。

7、Elastic Beanstalk

最简单最傻瓜的版本就是Elastic Beanstalk。如果我们新建的创业团队有一个电商或者互联网的项目需要构造跟微信的对接,会使用一些特定的技术栈,比如我们会使用PHP、MySQL这样的方式。而现在你只需要在Elastic Beanstalk上面选择一个这样的技术栈,一键就能帮你去做出这样一个完整的环境,里面包括了的语言比如PHP,还有底层的一些数据库服务,都会安装好。这样的情况下团队马上就可以投入到开发的工作,而不需要担心各种的基础设施的问题。同时我们的应用部署可以自动扩展,可以去跟各种的ID做结合,这样的情况下,代码人员纯写代码就可以运行到这样的一个环境。

AWS自身的环境包括了Java、PHP等这些东西,Golang也可以用到。我们一样可以通过Elastic Beanstalk部署到在持续集成里,而当经常面对到不同的环境时,比如说我们会有测试、Staging的环境、生产的环境,他们之间可以通过不同的版本去发布,而不会去互相地影响到,我们也可以调一部分环境去测试。

图:Elastic Beanstalk构建不同版本环境

8、Cloudformation

接下来如果要构造一些更详细的服务,我们可以使用CloudFormation。刚才说到AWS所有的资源,无论大小,它在提供时一定会提供API,而且我们会有SDK,在这个基础上,我们构造了CloudFormation这样一个组建的工具,可以通过JSON或者YAML的方式去描述你在AWS上面任何一项资源。

这个资源我们是可以通过变量去控制的,比如说常见的一些生产环境和测试环境,它们绝大部分的结构是一样的,但他们需要的JSON的大小可能不一样,我们可以通过一个JSON文件或YAML文件去备注一下他们的关联关系,然后通过不同的参数去启动不同的环境,一旦这个模块文件产生了改变,我们后台的程序也会自动根据你的模板程序的改进,去改变你们使用的一些资源跟它们的依赖关系。可以这样理解,JSON文件是一个类,它跟模本的程序产生每一个堆栈,这个堆栈就是这个类产生的实例,然后刚刚提到的变量,根据这个变量,这个实例的大小就会不一样。如果你的类改变,它的实例也会跟着做一定的改变。

图:CloudFormation组件和技术实现

这样的情况下,我们就可以做到整个基础设施平台的模板化,这对于DevOps是非常有用的,也就是说整个基础设施可以非常好地管理起来,比如说可以使用AWS的各种代码管理工具去管理我们的基础设施。

图:基础平台模板化

比如下图中的这个服务器,原来只是Application到数据库的,现在要在中间增加一个Redis作为缓存,基础设施的这种改变,可以完全用代码的方式描述起来,并且这个改变也可以被Commit到我们的代码库里,因此我们能够知道这个改变是什么时候产生的,为什么要这样产生,可以很好地去做这样一个动作。

图:基于模板的快速部署

基于这样的模板就可以产生不同的环境,这些环境可以去做不同的改变,然后我们也可以做到不同的生产测试环境与蓝绿部署。

图:Cloudformation一键部署全站

这个也是CloudFormation目前能够做到的事情,特别是对很多团队来说,当在中国的业务做大了后、想往海外发展时,我们可以利用在中国积累的经验,很容易地应用AWS的基础设施快速地部署到10-20个不同的海外区域,如欧洲、美国、中东甚至东南亚这些地方,这些均可通过一个代码、一套代码,去一次部署完整个的服务。

9、Opsworks

Opsworks大家可能不太熟悉,但说到Chef,各位可能多少都听过。Opsworks其实就是AWS提供的一个托管Chef的工具,它完全跟Chef一样,能把AWS实际的一些资源抽象化成Chef里面不同的Layer并给大家提供到服务,所以我们就可以利用它在Chef方面的一些经验去控制到我们在AWS上的这些资源,包括了它的Step以及不同的Layer,比如说数据库的Layer,No banners这一部分的Layer,还有我们实际Application计算资源的Layer,都可以被控制到。

然后AWS就可以通过每个用户的Chef Code去产生实际的计算资源,它可能比传统机房的Chef会更有效,因为对于传统机房,如果你要把这些Layer抽象化出来,你的机器实际上是开在那里的,首先你要付出购买机器这个成本,然后你可能还有接电的成本、电费等。但在云端,你在你的Layer真正产生实例化之前,你是不需要付这个费用的,只需去编写这些Code就可以了。还有一点很重要的是,本地的资源有可能不足,万一发现Layer不够时,我们还要去采购新的资源,这是个漫长的流程。

图:OpsWorks工作原理

相信很多Opsworks的团队,都会有这样的深切体验,我们的整个业务可能来不及去支撑发展,而我们的运维也来不及支撑业务的发展,但这个在云端是能够进行改善的,Opsworks就是这样的一个情况,它可以改造这样不同的Layer,可以通过我们已经积累的Code知识去构造Chef的Layer,所以我们能够部署整个Setup、Configure、Deploy、undeploy和shutdown各种不同的阶段,这是我们Chef的一个界面的截图,大家有兴趣可以去看到。

图:使用内置Chef Recipe或定制Chef Recipes配置应用

第三方工具集成

前面也反复说过了,我们的团队现在已有很多DevOps方面的知识了,比如我们可能已在用Github去管理代码,可能部署了Jenkins,可能部署了Pipie各种的环境、Chef,这些东西已有现成的经验,可以不急于丢弃掉,我们云端的资源完全支持大家把现有的经验往云端去集成,而缺乏经验的部分,也可以拿云端的一些资源直接使用起来,这是我们的情况。

10、贯穿始终的安全与监控

安全是非常重要的,在云端,我们只要用好了服务,其安全性很有可能会比在本地更加安全,这里就好比钱存在自己钱包里安全还是存在银行安全一样。但存在银行里是要遵守一定的守则,都会有一些安全的最佳实践。

11、无服务器优化

DevOps,刚才我们说到了从代码开始的持续集成、持续发布,到基础设施即代码,这整个部分都是一个过程,最终实现的目的是希望我们的开发人员可以直接去支撑到业务,这个是非常重要的,我们的运维人员可能是隐身的、自动化的,这是最好的情况,那有没有可能达到这样的过程呢?我们觉得是有机会的,目前AWS也在做这一方面的尝试,就是无服务器的优化。

在无服务器方面,大家接触最多的大概说我们不需要去看到服务器资源,希望能够自动化的,首先大家都知道Docker,这里AWS也提供相应的Docker的服务,叫Elastic Container Service的服务,它算是一个Docker的管理器,会同时帮你管理AWS上的云资源去跟你各种不同的Docker镜像的一个编排,最重要的一点就是最右边的这个Lambda。

它是一个无服务器架构的函数,实际上它已经实现出来了,现在开发人员只需要去编写一段代码,就是一个事件响应的代码,开发人员响应了代码以后,我们只需要把事件部署上去,就可以在这个事件触发时运行这个代码,而不需要去管理这个代码运行在哪,也不需要管理这个代码是否会有成千上万个并发,这些东西甚至不需要运维了,AWS的基础设施会自动帮你去扩展。

举个例子,假设我现在有一个服务,Java或者IOS这种开发,它通过Internet去访问一个API,这个API Gateway是可以通过我们Swagger的方式去描述一个API标准的API,这个API并不需要连接到真正的服务器,而是连接到Lambda上,刚刚也说了,它就是一段代码,就是一个事件相应的结构,你可以用Java编写,可以去JS的方式去编写,然后它可以调用其它AWS服务,比如数据库,直接产生一个响应,这个情况下我们在这个流程中根本没有接触到任何的服务器,所以也没有很详细的运维可言,这是未来的方向,当然它不能替代所有的产品,因为还是存在一些情况。

API Gateway这里也稍微说一下。你可以认为它是一个AWS无服务器化的一部分,作为一个API Gateway,它在AWS端是运维了这样的服务器,但它可以通过你的编写生成一个近乎无线扩展能力的API,这里面包括了各种的指标监控,去调动Lambda的动作。

再举个例子来说,我们很多的手机厂商都会做这样的相册服务,会涉及到上传,我们可以使用Lambda的方式去做一个当S3上传后自动触发的一个动作,比如说这个相册可能做人脸检测,或者是变大小、变颜色,甚至是各种自动美颜优化,这个东西都可以自动触发地需做,我们放入开发人员可能只需要写的这部分的代码,实现里面的逻辑,中间的运维阶段可以完全把它屏蔽掉,这就是未来或者说现已实现的无服务器化的方向。

小结

这就是今天介绍的整体的内容, AWS DevOps服务的总体框架其实包括了从开发、构建、部署,搭建、监控、运维的整个范围,所以在座的各位,可以很容易地注册到一个AWS的帐号,开始去试用这样的服务,在云端试用的成本是非常低的,包括您和您的团队,都可以去试用云端的这种方法。

而今天我介绍的这个服务,未必是马上可以适应你的团队,你们可以先把团队现有的一些经验往云端去搬迁,这种情况下云端最大的优势就是它的资源是弹性的,弹性会包括两个方面,第一个就是试错的成本会变得非常低,比如说现在有一些AI的团队需要一些很庞大的GPU资源,但购买这样的GPU资源非常贵,在云端可能只需要几块钱、十几块钱的成本,就可以用它一个小时,你可以把你的模型在上面跑,在DevOps的环境也是一样,我们马上就可以去测试云端的东西是否适合我,如果真的不适合,你付出的可能只是几块钱的成本,但如果适合,我们马上就可以把整个团队的敏捷性大大地提高,这个就是我们开发运维的DevOps的经验,这里面涉及到了整个公司文化、组织这方面的理念,AWS在DevOps上面的实践也非常多,欢迎大家一起探讨这方面的问题。我今天的分享就到这里,谢谢大家!

原文来自微信公众号:DBAplus社群

本文由yzc216亚洲城发布于亚洲城动态,转载请注明出处:一年5000万次配置是怎么着一种概念,DevOps工具的

关键词: 亚洲城官网 yzc216亚洲城