Heroku 的自动化持续部署之旅

发布于:2019 年 12 月 7 日 08:00

Heroku 的自动化持续部署之旅

Heroku 工程团队记录了他们利用 Heroku 运行时 Heroku Runtime )从手动部署到自动化持续部署的过程,Heroku 运行时是他们的应用程序托管环境。他们使用 Heroku 原语和自定义部署工具实现了这一目标。

Heroku 运行时团队可以构建和运维单一(私有空间,Private Space/PS)及多租户(公共运行时,Common Runtime/CR)环境。这包括容器编排、路由和日志记录。在此之前,该团队需要遵循的部署流程是由多个手动步骤组成的,包括主要值班工程师的签字、预留足够的缓冲区以监控部署后的情况以及对多个仪表板的监控。如果还需要部署其他区域和服务,则必须等到该次部署全部稳定之后,这也会带来相应的开销。由于当时团队规模较小,并且服务和区域仅限于美国和欧盟 2 种生产环境,所以这种方法是可行的。随着团队成员数量的增加以及将 CR 重新构建成一个面向多服务的长期项目,团队必须进行自动化实践并构建一个可以自动化部署工具。

InfoQ 联系了 Heroku 的主要技术人员 Bernerd Schaefer , 以进一步了解他们所面临的挑战以及相应解决方案的细节。

之前的流程依赖于团队的规模和对预期效果的详细手动计划。Direwolf 是一个测试平台,它可以上报跨区域的状态。当团队成员增加到 30 多人时,这个过程会变得很繁琐。再加上 CR 管理架构改造(将 CR 的单体 Ruby 应用程序分割成多服务)的挑战。团队决定推行完全自动化。该应用程序在两个生产环境中运行,手动步骤会导致更高的协调成本。

团队的解决方案是使用现有的 Heroku 原语和一个名为 cedar-service-deployer 的自定义工具。每个服务都会成为管道(Pipeline)的一部分,并且共享服务作为长期项目的一部分部署在跨多个预生产(staging)和生产(prod)环境中。cedar-service-deployer tools 工具是使用 Go 编写的,它可以扫描管道以发现不同阶段之间的差异。如果扫描到任何差异,它将运行检查程序以查看是否可以将代码提交到下一个阶段。这些检查包括发布时间、足够的集成测试时间、正在运行的事件(incident)、正在触发的告警、只能从主干分支进行升级等。Schaefer 说到,添加新检查需要变更代码,因为该列表是固定的。同时,他还解释到,团队可以配置自己的告警:

团队可以配置单个服务所需要检查的服务项,特别是要监控哪些告警以确定服务的健康状况。例如,某个服务可能有一个告警是用来检查服务是否启动的,一个是用来检查其 HTTP 成功率是否超过 99%,向部署程序中添加这些服务的团队可以在 JSON 文件中配置告警,以便对部署程序服务在发布期间进行监控。

监控和告警是部署的重要组成部分,因为它们可以指出可能存在的问题。Heroku 使用 Librato 收集度量指标和告警。Schaefer 说,还有一些其他的系统也可以进行监控,但是到目前为止,部署程序所控制的所有服务都是使用的 Librato。

Schaefer 进一步阐述了他们的监控理念:

我们一直在推动的一件事情是将监控引入到我们的标准服务工具包中,以便每个服务在默认情况下都具有有用的工具。当然,随着服务投入生产并进入成熟阶段,它们可能需要一些定制的工具。但是我们的目标是,服务开发人员可以专注于他们服务所提供的功能,并成为对应功能的专家,而无需成为度量指标收集、跟踪或其他我们想知道的系统运行情况的专家。

尽管在大多数情况下,部署程序可以自动决定是否推送,但是我们仍提供了手动覆盖的规则。Schaefer 解释道:

系统总是允许运维人员使用现有的手动工具来进行发布。我们可能会在事件期间执行此操作,以便将关键的热修复程序补丁发布到受影响的环境中。在一个事件中,很少还会推送其他的变更,因为如果有某项事件正在进行中的话,我们会尽力减少其他对生产环境的变更,而且人们很少会急于将产品发布上去,但是如果需要的话,这种能力也是存在的。

部署程序的无状态特性意味着它的工作方式可以尝试在管道中任意两个阶段之间进行升级,而不是绑定到单个“发布”版本上。这使得多个提交点可以同时出现在部署管道的不同阶段。

原文链接:

Heroku’s Journey to Automated Continuous Deployment

阅读数:3287 发布于:2019 年 12 月 7 日 08:00

更多 运维、DevOps、部署 相关课程,可下载【 极客时间 】App 免费领取 >

评论

发布
暂无评论
  • 应用托管服务:Web 应用怎样在云上安家?

    能不能有一个平台服务,来帮我们解决所有的基础架构问题,让我们只需要专注于应用构建本身?这就是云上应用托管PaaS服务。

    2020 年 3 月 27 日

  • 快速构建持续交付系统(四):Ansible 解决自动部署问题

    在今天这篇文章中,我主要基于Ansible系统的能力,和你分享了搭建一套部署系统的过程。

    2018 年 9 月 27 日

  • AWS 的 Elastic Beanstalk 是现在支持最多语言的 PaaS 吗?

    亚马逊web服务(AWS)团队为Elastic Beanstalk服务添加了对Ruby的支持,从而成为支持最多语言的云平台之一。另外,AWS还为Elastic Beanstalk引入了在虚拟私有云(Virtual Private Cloud,VPC)中的支持,这样客户可以对其web应用程序进行私有版本的部署和管理。

    2012 年 11 月 13 日

  • 英国税务局(HMRC Digital)的 DevOps 之旅

    2016年在伦敦举办的DevOps企业峰会上,最吸引大家眼球的莫过于英国皇家税收与关税局(HMRC)英国税务海关总署的DevOps和持续交付实践案例,在案例中他们逐步将部门的官僚文化改变为快速交付的数字税务服务。InfoQ采访了其中的演讲者之一Lyndsay Prewer,深入了解了他们的历程,以及目前的情况和最大的挑战。

    2016 年 8 月 30 日

  • 面向服务的开发:Rafael Schloming 关于构建微服务的经验分享

    San Francisco QCon大会上,Rafael Schloming提出了“面向服务的开发”,他认为,想迁移到微服务的组织必须要寻求一种方法来打破单一的开发过程,而不仅仅是试图打破传统系统架构。将新成立的微服务团队看作是内部的“衍生品”,他们具有团队边界,并且鼓励他们自给自足和自我管理。

    2017 年 11 月 27 日

  • 构建检测,无规矩不成方圆

    工欲善其事必先利其器, 好的工具可以解放大量的生产力,最重要的是构建检测后的交付让你我更有信心了。

    2018 年 8 月 7 日

  • 第 55 讲 | 用机器打造迭代机器:现代研发流程体系打造(二)

    构成自动化流程的大部分工具都是现成的、可以花合理价钱买到的,本文就将重点介绍研发流程里的各种工具们,以及不同场景下的具体选型。

    2018 年 7 月 18 日

  • 构建微服务架构的最佳实践 3/3

    微服务架构主要是为了应对复杂度。相对于单一的复杂系统,该架构由多个简单的服务组成,这些服务之间存在复杂的交互,其目标在于确保复杂度能够得到控制。作者Vinay Sahni在为Enchant构建微服务架构中总结了一套适用于现代化Web和云技术的实战经验。通过前两篇介绍过微服务架构的服务本质与服务的交互后,作为这一系列文章的最后一篇,本文将将介绍服务的开发、部署、运维,以及与人员有关的最佳实践。

    2016 年 10 月 16 日

  • Netflix 如何部署代码

    著名的电影流媒体网站Netflix每天都会进行上百遍部署,它们没有使用Chef 或 Puppet,没有一个质量保证部门,也没有发布工程师。为了实现自己的目标,Netflix构建了一个先进的内部PaaS(平台即服务)平台,所有的团队都能够通过这个平台部署自己的基础设施部分,同时部署也没有时间和次数上的限制。

    2013 年 6 月 14 日

  • Pinterest 的 Kubernetes 平台化之旅

    容器编排系统如何才能提供一种方法来统一管理工作负载。

    2019 年 10 月 5 日