当前位置: 首页 > 科技观察

有助于改进部署过程的四件简单事情

时间:2023-03-20 00:33:33 科技观察

这里有四件简单的事情,可以在任何环境中完成,以帮助改进部署过程。这些将使您更好地了解和确信您的应用程序正在正确运行和配置。应用程序健康检查事件注释Pod:最小化对蓝绿部署的影响应用程序健康检查改进应用程序部署和管理的第一步是了解您的应用程序是否健康(运行并能够执行其预期任务),可以与下游服务并运行正确的版本。显然,监控很关键,但是我们如何监控才是将其用于自动化部署的关键。在我工作过的每个地方,我们都有某种形式的应用程序和数据库监控,但并不是所有的应用程序都有健康检查。最近,在Kountable,我们在所有应用程序上设置*/public/healthpoints。此健康检查将告诉我们有关该应用程序的信息。首先,应用程序是否已启动并正在运行*(已启动并准备就绪)。其次,应用程序运行的代码版本(提交)。第三,应用程序正常运行时间,最后是connection_status。connnection_status告诉我们应用程序是否可以连接到数据库或下游服务。如果不行,那我们看看这是网络问题,还是密码问题,还是下游服务下线问题?这有助于在应用程序失败时减少时间和注意力。这是健康检查输出示例。{"healthy":true,"commit":"1e98e46","uptime":"05:22:47:21","connection_status":true}这种健康检查不仅可以用来监控服务,还可以作为部署过程的一部分。在蓝绿部署期间可以使用健康检查来验证安装的版本(提交)以及健康和连接状态。如果所有这些都通过,连同其他综合测试,我们可以自动将该部署提升到生产环境。在此设置的早期,我们将未通过健康检查的服务部署到AWSECS。提交ID与要部署的ID不匹配。如果您已经在运行ECS服务,您就会知道AWS在允许您部署新版本的ECS任务方面做得很好,同时对当前正在运行的服务的影响最小。ECS会启动新的任务,验证目标组配置的健康检查端点,只有通过,才会排空旧任务并启用新服务。在过去,我曾多次看到部署了新的ECS任务,然后陷入启动和失败的循环。任务部署没有AWS错误。唯一的选择是查看CloudWatch日志,您会看到您的服务每分钟都在启动和停止。通过提交ID或版本的应用程序健康检查可能需要一些时间,并且通过蓝绿部署,我们能够捕获部署失败。部署工具验证要部署的提交ID和运行状况检查提交ID。当它们不匹配时,部署将停止。这个简单的设置节省了30多分钟的时间来识别问题并使其停止生产。事件记录我反复看到的一个趋势是,当系统、应用程序或环境没有变化时,几乎不会出现问题或中断。我在Apigee工作的时候,早期我们的客户增长非常快,代码也在不断的发布。在这段快速开发和持续部署的时期,我们在生产应用中会遇到很多问题。在没有生产部署的安静时期,问题将几乎消失或几乎不存在。在不断变化的环境中,可能很难跟踪所有变化。当发生变化时,需要一些时间来缩小范围,尤其是随着时间的推移和全球范围内的变化。我发现很容易实现并且非常有用的一件事是记录更改事件并将该事件添加到您的监控系统。这可以使用部署工具轻松完成,以使用部署事件更新监控系统。这是一个示例,我们最近部署了一个应用程序,响应时间立即增加。grafana注释标记部署时间,然后您会看到响应时间激增。除了帮助快速确定原因外,我还发现为任何部署过程或其他自动化过程实施日志记录事件很容易。我认为需要对环境的所有更改进行更改(从配置管理工具运行、打补丁、备份,甚至是非自动更改)。我发现添加备份事件有助于将备份窗口覆盖到系统资源使用情况(CPU、内存等)。这是查看备份进程是否是导致CPU和内存峰值的罪魁祸首的一种快速简便的方法。Pod:最小化影响的概念Pod有许多不同的迭代,从数据中心设计到VMwarePod,再到KubernetesPod。Pod可以通过多种方式使用或设计。关键是设计应用程序和基础架构以减少任何故障对某些组件、客户或服务的影响。当我们在Apigee一起设计应用程序和基础设施时,我们就意识到了这个概念。从运营方面与工程部门合作,我们设计多租户应用程序以在2个或更多应用程序单元上运行客户。对我们来说,Pod是一组应用程序服务,其中1到X个客户端分配给特定的Pod。例如,您可能有一个用于核心应用程序的pod和另一个用于分析或日志记录的pod。在AWS设置中,您可以按AWS区域拥有应用程序pod,然后您可以将客户分配到全球所有或多个区域中的每个区域中的pod。其他示例包括Google的gmail如何基于用户的默认位置或Facebook如何向某些用户推出新功能。如果由于云故障、部署问题或其他因素导致特定区域的pod出现问题。该问题的影响只会影响到该地区该pod上的客户端。通常,客户在部署到多个区域后永远不会注意到该问题。通过一起设计应用程序和基础架构,您越有可能减少问题的影响/爆炸半径,最终结果就越好。蓝绿部署蓝绿部署允许您运行两个不同版本的应用程序,同时一个运行实时流量。您可以通过几种不同的方式进行设置。过去,我在ECS中运行过一个应用程序的两个版本,都指向同一个数据库。您的应用程序和数据库需要向前和向后兼容。兼容性的关键是您的数据库架构更改。您需要确保延迟删除列,直到两个版本都不需要为止。为了在v1.0.3或v1.0.5之间切换,AWSALB设置了两条规则,一条用于蓝色,一条用于绿色。ALB将侦听器规则从蓝色切换为绿色,然后耗尽所有旧(蓝色)连接。