亚马逊AWS官方博客

基于Amazon EC2 Container Service的持续集成/持续交付解决方案

基本概念 持续集成/持续交付 互联网软件的开发和发布,已经形成了一套标准流程,最重要的组成部分就是持续集成(Continuous integration,简称CI)和持续交付(Continuous delivery,简称CD)。 通过CI/CD构建自动化的代码交付管道,可以实现: (1) 快速交付。通过CI/CD自动化软件发布的过程,可以更快速地发布新的功能,快速迭代反馈并让新功能更快提供给客户。 (2) 提高质量。自动化构建、测试和发布过程致使可以轻松测试每次代码更改并捕捉易于修复的小型漏洞,通过标准化发布过程运行每一项更改,从而保证应用程序或基础设施代码的质量。 (3) 可配置工作流。通过图形用户界面模拟软件发布过程的各个阶段。 容器 本文涉及到的另外一个概念是容器,相信大家都已经不再陌生,并且很多朋友已经在自己的环境中有实际的运行、部署基于容器的应用,这边简单的回顾下容器的几个重要优势: 一是因为容器可以跨平台,从而让程序猿可以享受到研发生产环境一致性的便利,也就是DevOps。在没有容器之前,常常一个应用做好了在笔记本上可以运转起来,在数据中心就运转不起来,因为操作系统版本不同、库版本不对;或者有的时候生产环境里出现了问题,在笔记本的开发环境中复制不出来。有了容器之后,这些问题就大大减少了。 其二,容器在虚拟机里面可以大幅度提升资源利用率。因为一旦把应用容器化,虚拟机资源就可以通过部署多个容器而得到充分利用,而不是每一个应用去申请一个虚拟机,造成资源的浪费。 Amazon ECS/ECR Amazon EC2 Container Service (ECS)是一个托管的容器集群管理和调度服务, 可使您在 Amazon EC2 实例集群中轻松运行和管理支持 Docker 的应用程序。 使用 Amazon ECS 后,您不再需要安装、操作、扩展您自己的集群管理基础设施,可以根据资源需求和可用性要求在集群中安排支持 Docker 的应用程序。借助 Amazon ECS,您可以从一个容器扩展到覆盖数百个实例的数千个容器,而运行应用程序的方式并不会因此而变得复杂。您可以运行包括应用程序、批量作业和微服务在内的任何东西。Amazon ECS 将基础设施的一切复杂因素全部消除,让您能够集中精力设计、开发、运行容器化应用程序。 Amazon EC2 Container Registry (ECR) 是完全托管的 Docker 镜像仓库,可以让开发人员轻松存储、管理和部署 Docker 容器映像。Amazon ECR 集成在 Amazon EC2 Container Service (ECS) 中,从而简化产品工作流的开发。 本文主要介绍如何在AWS云上,使用Jenkins快速构建针对容器应用的持续集成/持续交付管道。 下图是整个CI/CD的流程图: […]

Read More

新增:Amazon Kinesis Streams 服务器端加密

在这个智能家居、大数据、物联网设备、手机、社交网络、聊天机器人和游戏机的时代,流媒体数据场景无处不在。利用 Amazon Kinesis Streams,您可以构建自定义应用程序,以便从数千个流媒体数据源捕获、处理、分析和存储每小时数 TB 的数据。由于 Amazon Kinesis Streams 允许应用程序从同一个 Kinesis 流并发处理数据,因此您可以构建并行处理系统。例如,您可以将处理后的数据发送到 Amazon S3,使用 Amazon Redshift 执行复杂分析,甚至使用 AWS Lambda 构建强大的无服务器流媒体解决方案。 Kinesis Streams 为消费者提供了多种流媒体使用案例,现在我们通过为 Kinesis Streams 添加服务器端加密 (SSE) 支持,让服务能够更有效地保护您的传输中数据。借助 Kinesis Streams 的这一新功能,现在您可以提高数据安全性和/或满足任何法规和合规性要求,以符合组织的任何数据流式处理需求。 事实上,Kinesis Streams 现在是支付卡行业数据安全标准 (PCI DSS) 合规性计划涵盖的 AWS 服务之一。PCI DSS 是由主要金融机构成立的 PCI 安全标准委员会管理的专有信息安全标准。PCI DSS 合规性适用于存储、处理或传输持卡人数据和/或敏感的身份验证数据的所有实体,其中包括服务提供商。您可以使用 AWS Artifact 索要 PCI DSS 合规性证明和责任摘要。但是,关于 Kinesis Streams 合规性的好消息还不止这些。Kinesis Streams […]

Read More

Lambda@Edge – 在边缘智能地处理 HTTP 请求

去年年底,我宣布推出预览版 Lambda@Edge,并谈论了如何使用它在靠近客户的位置 (低延迟) 智能地处理 HTTP 请求。申请并获得预览版访问权的开发人员一直在很好地使用它,并为我们提供了大量非常有用的反馈意见。在预览期间,我们添加了生成 HTTP 响应和支持 CloudWatch Logs 的功能,并根据反馈意见更新了路线图。 现已正式发布 今天我很高兴地宣布 Lambda@Edge 现已正式发布!您可以使用它来: 检查 Cookie 并重写 URL 以执行 A/B 测试。 根据 User-Agent 标头将特定对象发送给用户。 通过在将请求传递到源之前查找特定标头来实现访问控制。 添加、删除或修改标头以将用户指引到不同的缓存对象。 生成新的 HTTP 响应。 干净利落地支持旧 URL。 修改或缩减标头或 URL 以提高缓存利用率。 向其他 Internet 资源发出 HTTP 请求,并使用结果自定义响应。 Lambda@Edge 允许您创建基于 Web 的丰富且个性化的用户体验。由于它正迅速成为当今世界的常态,因此您不需要配置或管理任何服务器。您可以直接上传代码 (在Node.js 中编写的 Lambda 函数),并选择您为分发版创建的其中一个 CloudFront 行为以及所需的 CloudFront 事件: 在本例中,我的函数 (假设名为 EdgeFunc1) […]

Read More

使用 Amazon Redshift 中的查询监控规则管理查询工作负载

本文主要介绍了如何利用Amazon Redshift的WLM(工作负载管理)功能,监控数据仓库的查询性能,从而优化队列优先级并保障关键任务的执行。本文还列出了三个常见场景,给出了简单的配置过程。 众所周知,数据仓库的工作负载由于周期性、潜在高开销的数据探索查询以及SQL开发人员不同的技能水平等会出现比较大的性能变化。 为了在面临高度变化的工作负载下仍然能使Redshift集群获得较高的性能,Amazon Redshift工作负载管理(WLM)使您能够灵活地管理任务优先级和资源使用情况。通过配置WLM,短时间,快速运行的查询不会停留在需要较长时间运行的查询之后的队列中。 但尽管如此,某些查询有时可能会陷入不相称的资源分配,并影响系统中的其他查询。 这种查询通常被称为流氓查询或失控查询。 虽然WLM提供了一种限制内存使用并将超时查询移动到其他队列的方法,但多重精细控制依然很需要。您现在可以使用query monitoring rules查询监视规则为查询创建资源使用规则,监视查询的资源使用情况,然后在查询违反规则时执行操作。 工作负载管理并发和查询监控规则 在Amazon Redshift环境中,单个集群最多可以同时连接500个连接。 吞吐量(Throughput)通常表示为每小时的查询量以最大化性能,但像MySQL这样的行数据库使用并发连接数进行衡量。 在Amazon Redshift中,工作负载管理(WLM)可以最大限度地提高吞吐量,而不太考虑并发性。 WLM有两个主要部分:队列和并发。 队列允许您在用户组或查询组级别分配内存。 并发或内存是如何进一步细分和分配内存到一个查询。 例如,假设您有一个并发度为10的队列(100%内存分配)。这意味着每个查询最多可以获得10%的内存。 如果大部分查询需要20%的内存,那么这些查询将交换到磁盘,导致较低的吞吐量。 但是,如果将并发度降低到5,则每个查询分配20%的内存,并且最终结果是更高的吞吐量和更快的SQL客户端响应时间。 当从行数据库切换到基于列的数据库的时候,常见的错误认知是认为更高的并发性将产生更好的性能。 现在你了解了并发性,这里有更多关于查询监控规则的细节。 您可以基于资源使用情况定义规则,如果查询违反了该规则,则会执行相应的操作。 可以使用十二种不同的资源使用指标,例如查询使用CPU,查询执行时间,扫描行数,返回行数,嵌套循环连接等。 每个规则包括最多三个条件,或谓词,和一个动作。谓词由一个指标,比较条件(=、<、>),和一个值组成。如果所有的谓词满足任何规则,该规则的行动被触发。可能的规则操作包括日志记录、跳过任务和中止任务。 这样就可以在导致严重问题前捕获流氓或失控查询。该规则触发一个动作来释放队列,从而提高吞吐量和响应速度。 例如,对于专用于短时运行查询的队列,您可能会创建一个规则来中止超过60秒的查询。 要跟踪设计不当的查询,您可能会有另一个规则记录包含嵌套循环的查询。 在Amazon Redshift控制台中有预定义的规则模板让您使用。 使用场景 使用查询监控规则来执行查询级别的操作,从简单地记录查询到中止查询,以下所有采取的操作都记录在STL_WLM_RULE_ACTION表中: 日志记录(log):记录信息并继续监视查询。 跳出(hog):终止查询,并重新启动下一个匹配队列。 如果没有其他匹配队列,查询将被取消。 中止(abort):中止违反规则的查询。 以下三个示例场景显示如何使用查询监视规则。 场景1:如何管理您临时查询队列中的未优化查询? 连接两个大表的失控查询可能返回十亿行或更多行。 您可以通过创建规则来中止返回超过十亿行的任何查询来保护您的临时队列。 在逻辑上如下所示: IF return_row_count > 1B rows then ABORT. 在以下截图中,任何返回BI_USER组中超过十亿行的查询都将中止。 场景2:如何管理和控制未调优的CPU密集型查询? 偶尔引起CPU飙升的查询不一定有问题。 然而,持续的高CPU使用率可能会导致其他并发运行查询的延迟时间增加。 例如,在较长时间内使用高百分比CPU的未调优查询可能是由于不正确的嵌套连接引起的。 […]

Read More

如何在Amazon EC2 Container Service上实现服务高可用的自动伸缩

1. 简介 Amazon EC2 Container Service (ECS)是Amazon提供的一项Docker容器管理服务,可以让您轻松构建、运行、管理您的Docker容器服务。ECS Service是ECS的重要组件,它可以在集群中运行指定数量的任务,当某个任务不可用时,它会重新启动新的任务,维持住任务的指定数量。这个特性从一定程度上保证了服务的可用性,但当面对突发流量,ECS本身并不能动态地进行任务数量的扩展,当流量较少时,ECS也无法动态地进行任务数量的缩减。为解决此问题,可以使用Auto Scaling和Amazon CloudWatch等实现服务的自动伸缩,保证服务高可用。本文将介绍一个运用Auto Scaling在ECS中实现服务高可用的方案,并通过对方案构建过程的剖析,让您对高可用、自动伸缩的服务架构有更进一步的了解。 2. 方案构建 2.1 整体结构图 本方案使用AWS CloudFormation模板声明整个资源堆栈所需资源和相关配置,并实现自动化构建。关于AWS CloudFormation相关知识,请通过以下链接了解:CloudFormation入门。 从上面这个结构图可以看出以下主要组成部分: 初始由两个跨AZ的Container Instance组成的ESC Cluster。 初始ESC Service中有两个task。 Service Auto Scaling与CloudWatch结合,当Service维度的 CPUUtilization与Threshold满足设定的触发条件时,触发CloudWatch Alarm,CloudWatch Alarm根据设定的Scaling Policy进行Task数量伸缩。 Auto Scaling Group与CloudWatch结合,当Cluster维度的CPUReservation与Threshold满足设定的触发条件时,触发CloudWatch Alarm,CloudWatch Alarm根据设定的Scaling Policy进行实例数量的伸缩。 2.2 准备工作 (1)准备好CloudFormation模板脚本 请从这里(点我)下载用于构建整个资源堆栈的模板脚本文件。 或者通过点击下面按钮来运行堆栈: (2)准备好Lambda Function 本方案在Auto Scaling Group中的实例关闭时,会调用一个实现自动切换Draining状态的Lambda Function。那么在构建整个堆栈之前,需要先准备好这个Lambda Function。这里我们使用Python编写了这个脚本auto_drain.py来实现此功能。您可以了载包含了这个脚本的压缩包(点我)。 下载完成后,请将它上传到您账户上同个Region的S3 Bucket中。记住这个S3 Bucket Name,在构建堆栈时,将它传给Lambda Function S3 […]

Read More

使用Amazon EC2 Systems Manager取代堡垒机

通常情况下,堡垒机(也称为“跳转机”)是在系统中访问私有主机的一个最佳实践。例如,您的系统可能包含一个不希望被公开访问的应用服务器,当需要在这台服务器上进行产品的更新或系统补丁程序的管理时,您通常会登录到堡垒机,然后从那里访问(即“跳转到”)应用服务器。 本文将向您介绍使用Amazon EC2 Systems Manager替换您的堡垒机,实现在服务器上运行命令的同时缩小系统攻击平面并获取更好的可见性。 堡垒机方案 堡垒机最好仅向特定的IP地址范围开放,这个地址范围通常可设定为您单位的企业网络。使用堡垒机的好处是,任何对内部服务器的访问都被限定到一种方式:通过单个或一组堡垒机。为了获取进一步的隔离,堡垒机通常被安放在单独的VPC中。 这种设计方案如下图所示: 应用服务器运行在与管理VPC对等相连的一个VPC的私有子网中。 应用服务器设定了一个安全组规则,其仅允许来自管理VPC中堡垒机所在安全组的22端口访问(本文的示例仅针对端口22和SSH访问。Windows用户可将其相应的替换为端口3389和RDP访问)。同样,堡垒机也设定了一个安全组规则,其仅允许来自公司网络IP地址空间的22端口访问。 由于应用服务器运行在私有子网中,所以它只能通过VPC公共子网中的NAT网关来建立出站公网连接。 假设您希望查看应用程序服务器的网络接口,您需要执行以下步骤: 将应用服务器的私钥安装在堡垒机上。 从可信网络(如公司网络)发起,在堡垒机上建立SSH会话。 从堡垒机发起,建立SSH会话到应用服务器。 运行“ifconfig”命令。 如需保存命令的结果,您可以复制和粘贴命令的输出,或者将输出重定向到文件。 这个方案中的安全措施限制了对应用服务器和堡垒机的访问,但堡垒机模式存在一些缺点: 像任何基础设施服务器一样,堡垒机必须进行管理和维护。 运行时会产生成本。 允许堡垒机访问的每个安全组都需要设置一个安全组入口规则,即SSH(用于Linux)的22端口或RDP的3389端口(用于Windows服务器)。 堡垒机和应用服务器的RSA密钥需要进行管理、保护和轮换。 SSH操作无缺省日志记录。 替代方案 Systems Manager允许您在被管理的服务器上远程执行命令,而不使用堡垒机(此功能称为EC2 Run Command)。安装于服务器上的代理程序会自动轮询Systems Manager以确定是否有命令在等待执行。 此方案具备以下优点: 使用AWS托管服务,这意味着Systems Manager组件具备高可用性。 Systems Manager通过IAM策略设定是否允许用户或角色远程执行命令。 Systems Manager代理程序需要IAM角色和策略才能允许它们调用Systems Manager服务。 Systems Manager不可更改的记录每个执行的命令,从而提供了可审计的命令历史,包括:  o   执行命令的内容  o   执行命令的主体  o   执行命令的时间  o   命令的输出摘要 当AWS CloudTrail在当前区域中启用时,CloudTrail会记录每个事件,并写入Amazon CloudWatch Logs。 使用CloudTrail和CloudWatch规则,您可以将Systems Manager事件用作自动响应的触发器,例如Amazon SNS通知或AWS Lambda函数调用。 […]

Read More

基于Amazon EC2 Container Service构建安全高可用的Docker私有库

1. 背景 Docker hub作为docker官方镜像仓库,提供了大量Docker镜像的托管服务。但使用它来托管企业私有Docker镜像存在一些问题,比如: (1)Docker hub托管私有镜像的服务目前只面对收费账户; (2)使用Docker hub托管私有镜像并不适合一些特殊场景,比如工作环境网络是内网,不允许访问外网,那就更不可能到Docker hub去下载镜像。 在这种情况下,如果能构建一个安全可靠的Docker私有库,将会是一个更好的选择。本文将介绍在Amazon EC2 Container Service基础上结合AWS Elastic LoadBalancer、AWS Autoscaling Group、AWS S3及Docker官方提供的registry镜像构建安全、高可用的Docker私有库的方案,帮助您轻构实现这一需求。 2. 方案详解 我们会使用AWS CloudFormation服务,使用自定义的模板脚本声明所需的资源,实现自动化构建。接下来结合我们的模板脚本对本方案进行详细介绍。 注意:以下内容与代码相关部分只贴出主要代码,部分代码用…表示省略;红字部分请替换成您自己账号相关的信息。 完整模板代码地址:https://s3-us-west-2.amazonaws.com/blog.leonli.org/registry.yml          或者点击按钮直接在控制台中运行: 2.1 架构图 根据以上架构图,基本数据传输过程为: (1)Docker客户端向镜像仓库发送的pull/push等命令事实上都是通过docker daemon转换成restful请求的形式再发送给镜像仓库的。在本架构中,我们利用AWS Elastic LoadBalancer(简称ELB)接收客户端发来的请求,作为整个架构的接入层。由于我们要求数据是通过TLS加密传输的,所以我们需要使用AWS IAM中的server certificate(由AWS IAM账户上传的TLS证书)与ELB关联,实现对客户端发来的请求进行加密。 (2)ELB会将请求反向代理给后端分布在不同可用区的两台Container Instance(安装了Docker运行环境的EC2实例),Container Instance中运行了Docker registry服务。当请求到达registry时,我们需要首先使用内置在registry中的用户认证文件(比如本架构中使用apache htpasswd创建的基本用户名密码保护文件),进行用户认证,认证不通过,则驳回请求,认证通过,才可以读写数据。 (3)我们将数据统一存储在一个只供创建者使用的S3 Bucket中。 2.2 基于AWS ECS运行Docker Registry服务 Amazon EC2 Container Service (ECS) 是一项高度可扩展的高性能容器管理服务,它让您能够在托管的 Amazon EC2 […]

Read More

新增 – EC2 Auto Scaling 的目标跟踪策略

最近我介绍过 DynamoDB Auto Scaling,并演示了它如何使用多个 CloudWatch 警报来实现 DynamoDB 表的自动容量管理。此功能在后台使用了一种更为通用的 Application Auto Scaling 模型,我们计划以后逐渐在多项不同 AWS 服务中投入使用该模型。 这一新的 Auto Scaling 模型包括一项重要的新功能,我们称之为目标跟踪。在创建使用目标跟踪的 Auto Scaling 策略时,需要为特定 CloudWatch 指标选择一个目标值。然后,Auto Scaling 旋转相应的旋钮 (打个比方) 推动指标趋向于目标,同时调整相关的 CloudWatch 警报。比起使用初始步进扩展策略类型来手动设置范围和阈值而言,采用对应用程序有意义的任何指标驱动的单元来指定期望的目标,通常来说要更简单,也更为直接。不过,您可以结合使用目标跟踪和步进扩展来实现高级扩展策略。例如,您可以使用目标跟踪实现扩展操作,使用步进扩展实现缩减操作。 现在面向 EC2 现在我们为 EC2 Auto Scaling 增加了目标跟踪支持。您现在可以创建应用程序负载均衡器请求计数、CPU 负载、网络流量或自定义指标 (Request Count per Target 是新指标,也是在今天发布) 驱动的扩展策略: 这些指标都具有同一个重要的特性:添加额外的 EC2 实例会推动指标下降 (但不会改变总体负载),反之亦然。 要创建使用目标跟踪的 Auto Scaling 组,只需输入策略名称、选择一个指标,然后设置所需的目标值: 您可以选择禁用策略的缩减功能。如果禁用,您可以手动缩减,也可以使用独立的策略。您可以使用 AWS Management Console, […]

Read More

AWS 深度学习之旅

如果您和我一样,就会对人工智能 (AI)、机器学习 (ML) 和深度学习这些主题有极大兴趣和深感兴奋。AI、ML 和深度学习的应用越来越广泛,对我来说,这意味着艾萨克·阿西莫夫博士的科幻小说、《星球大战》中机器和医疗的进步,以及让柯克船长和他的《星际迷航》舰员能够“前往没有人去过的地方”的那些技术都可成为现实。 大多数对前述主题感兴趣的人都熟悉深度学习支持的 AI 和 ML 解决方案,如实现图像和视频分类的卷积神经网络、语音识别、自然语言接口和推荐引擎。但是,设置基础设施、环境和工具,让数据科学家、机器学习实践者、研究科学家和深度学习爱好者/拥护者能够深入钻研这些技术并不总是那么容易。大多数开发人员都渴望能够快速上手深度学习,从而使用深度学习技术来训练模型和开发解决方案。 因此,无论您是经验丰富的数据科学家,还是急切想在这方面入门的开发人员,我都乐意分享一些资源,帮助您快速构建深度学习解决方案。 深度学习资源 Apache MXNet 是 Amazon 选择的深度学习框架。借助强大的 Apache MXNet 框架和 NVIDIA GPU 计算,您可以在 AWS 云中方便地启动您的可扩展深度学习项目和解决方案。随着您开始探索 MxNet 深度学习,有很多自助教程和数据集可供您使用: 启动 AWS 深度学习 AMI:该指南可引导您完成基于 Ubuntu 启动 AWS 深度学习 AMI 的步骤 MXNet – 创建计算机视觉应用程序:该实践教程使用预构建的笔记本指导您完成使用神经网络实现计算机视觉应用程序来识别手写数字的整个过程 AWS 机器学习数据集: AWS 在您可以免费访问的 AWS Marketplace 中托管机器学习数据集。这些大型数据集可供任何人用来分析数据,而无需下载或存储这些数据。 预测和提取 – 学习使用预先训练的模型来进行预测:该实践课程将指导您借助预先训练的模型并使用完整 Imagenet 数据集来进行预测和特征提取。 AWS 深度学习 AMI […]

Read More

白皮书:物联网的核心原则

摘要 本文概述了在制定物联网 (IoT) 策略时应考虑的核心原则。本文帮助客户了解 Amazon Web Services (AWS) 的好处以及 AWS 云平台如何成为支持 IoT 解决方案核心原则的关键组件。本文还简要介绍了应作为整个 IoT 策略一部分的 AWS 服务。本文针对的是正在了解物联网平台的决策者。 概述 物联网 (IoT) 策略的核心价值主张之一是让企业能够洞察以前不了解的周边环境。但企业若想制定 IoT 策略,则需要搭建符合 IoT 解决方案的基本原则的平台。 AWS 信奉一些自由原则,这些原则能为企业带来云的组织和经济收益。这些自由正是上百万客户使用 AWS 平台支持几乎所有云工作负载的原因。这些自由还是 AWS 成为跨商业、消费品和工业解决方案的任何物联网策略的主要催化剂 的原因。 采用这些解决方案的 AWS 客户已经确定了一些对所有 IoT 平台的成功都至关重要的核心原则。这些核心原则是敏捷性、可扩展性、成本和安全性;研究表明,它们对于 IoT 策略的长期成功十分重要。 本白皮书将这些原则定义为: 敏捷性 — 不受限制地快速分析、执行和构建业务和技术计划 可扩展性 — 在区域或全球范围内无缝地扩展基础设施以满足运营需求 成本 — 了解和控制运营 IoT 平台的成本 安全性 — 通过云保护来自设备的通信,同时保持合规性和快速迭代 通过使用 […]

Read More