亚马逊AWS官方博客

Tag: Amazon EC2 Container Service

基于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 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 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

白皮书:Amazon EC2 Container Service(ECS)上的微服务架构(下篇)

ECS上构建微服务架构 在构建微服务架构时面临的一个主要问题就是,如果减轻运行、维护、扩展和管理微服务架构所需大规模分布式集群资源的工作量和复杂性。目前主流的解决此问题的方案之一就是通过容器化部署和运行服务,降低运维和部署的复杂性。Amazon EC2 Container Service(ECS)是AWS提供的一个容器管理服务,能够应对和解决微服务架构的部署和运维中面临的种种挑战。 本章节首先介绍Amazon ECS及其架构和工作原理,然后介绍利用Amazon ECS及其他相关AWS服务分层构建的一个高可用、高可扩展性、容错的微服务,并讨论该方案中涉及的分布式系统监控、服务发现、异步通信等问题。 Amazon ECS 简介 什么是Amazon ECS Amazon ECS是一个高度可扩展伸缩、高性能容器管理服务,支持Docker容器[vi]并能够让你轻构地在EC2实例构建的集群中运行应用程序。 Amazon ECS能够让你轻松地进行安装、操作和扩展你的集群资源。使用简单的API调用,你就可以启动和停止基于Docker的应用程序、查询你的集群状态、还可以使用其他熟悉的服务,诸如安全组、ELB、EBS卷和AWS IAM角色。 Amazon ECS的特点 与Docker完美兼容:支持 Docker 并使您能够在 Amazon EC2 实例的集群间运行和管理 Docker 容器。Amazon ECS 所管理的集群中的每个 EC2 实例都运行有 Docker 守护程序,所以无论您将何应用程序打包为本地容器,它都将部署和运行在 Amazon ECS 上,无需进行任何配置更改。 内置集群托管:管理自己的容器管理基础设施通常涉及安装、操作、扩展自己的集群管理软件、配置管理系统和监控解决方案。这些系统的可用性和可扩展性架构和管理很难。Amazon ECS 消除了容器管理工作的复杂性。使用 Amazon ECS,您只需要启动容器实例集群并指定想要运行的任务即可,所有集群管理工作将由 Amazon ECS 完成。 编程控制:Amazon ECS 为您提供一组简单的 API,方便您集成和扩展服务。使用 API,您可以创建和删除集群、注册和取消注册任务、启动和终止 Docker 容器,并能提供集群及其实例的状态相关详细信息。您还可以使用 AWS CloudFormation[vii] 预置 […]

Read More

白皮书:Amazon EC2 Container Service(ECS) 上的微服务架构(上篇)

简介 微服务是一种软件开发的组织和架构方法,它可以加快软件交付周期、增强创新和自主性,提高软件的可维护性和可伸缩、可扩展性,同时也提高了企业开发和发布软件服务的能力。使用微服务架构,软件产品将由多个独立的、可通过API进行交互的服务组成。这些服务将由各个小团队独自负责。 通过本白皮书,我们将首先总结一下微服务架构的特性,讨论构建微服务架构面临的挑战和难题,然后介绍AWS的ECS容器集群服务,以及如何利用ECS结合其他AWS提供的服务解决微服务架构中遇到的难题。 什么是微服务架构 微服务架构的特性 近些年,微服务架构的概念变得越来越火[i],事实上微服务并非某项具体的技术或框架,它也不是软件工程学中新的概念,而是一些成功的,经过实践论证的概念的组合,比如面向对象方法论、敏捷开发、面向服务架构、API-first设计、以及持续集成。 “微服务”这个名词是一个概括性的术语,很难对其进行精确的定义。但是所有微服务架构方法都具有以下共同特性: 去中心化:微服务架构是由去中心化数据管理的分布式系统组成。它不依赖中心数据库上统一的数据库模式。每一个服务都有自己独立的数据模型。去中心化的另一个含义是,每个服务在开发、部署、管理和维护过程中也是相互独立的,不依赖某个中心系统。 独立:微服务架构中各个服务组件都可以独立进行更改、升级和替换,而不会影响其他服务组件的正常功能。同样,负责各个服务组件的团队之间也都是相互独立的,互不干扰的。 专注做好一件事:每个服务组件都是专注于某个问题域的功能集合,一旦某个服务复杂度到达一定程度,则应该考虑将其进行服务切分或对其进行再次微服务架构。 多语种:微服务并不是“一体通用”的方法,它允许各个团队根据自己的喜好选择最适合自己问题域的开发语言、开发工具。因此,微服务无论在操作系统、开发语言、数据存储还是工具,都是兼容的。也就是说,微服务是“多语种”的。 黑盒子:微服务中的服务都是按照“黑盒”设计的,也就是说,它们将内部逻辑对外隐藏进来,各个服务间通过定义良好的API进行通信,避免了暗含的相互依赖。 谁构建,谁运行:通常情况下,在生产环境中,构建了某个服务的团队负责该服务的运行和维护。这条规则也称之为DevOps[ii]。DevOps除了能让各个团队按照自己的安排独立工作外,还可以让开发人员更贴近软件产品的真正使用者,能帮助他们更好地了解用户的需求。微服务对于企业组织架构上的影响也是不容忽视的,正如康威定律所言,系统架构是公司组织架构的反映[iii]。 图1:微服务架构的特征 单体型架构 vs. SOA vs. 微服务架构 技术为业务而生,架构也为业务而出现,无论传统单体型架构、SOA和微服务都是因为业务的发展而出现。出现SOA以及微服务框架与业务的发展、平台的壮大密不可分。 单体型架构 当网站或者应用流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本,简化开发流程,适合于个人开发或者小团队开发一些功能单一的小产品使用。这是最传统的架构模式,一般整个系统都是有一个统一的数据中心,各个功能模块显式进行相互依赖(比如直接调用模块公开的方法)。当网站流量随着业务发展不断变大时,这种架构的应用在可扩展性、容错性(一旦某个功能模块被流量击溃,整个系统瘫痪)上存在致命性的缺陷。 SOA 当网站或者应用流量变大,单体型架构无法招架之时,可以采取面向服务架构方式,将应用根据系统维度、功能维度、读写维度或者模块维度进行划分成各个独立的服务组件,服务组件间通过某个约定的方式(比如Web Service或者HTTP REST API)进行通信。当服务越来越多,容量的难以准确评估,小服务导致资源浪费等问题逐渐显现,此时需增加一个调度中心基于访问压力实时管理集群容量,提高集群利用率,这种架构一般仍然存在一个统一的数据中心或者调度中心。整个系统的可维护性、可扩展性相对于单体型架构得到提高,但在服务细粒度、隔度性、去中心化方面仍与微服务有差,另外就是SOA架构常常依赖于总线结构,利用可热插拔的中间件以及消息队列来完成服务与服务之间的解耦,对于总线结构的依赖也使得服务的独立性并没有被完全剥离。 微服务架构 在微服务架构中,每个服务都要去中心化,不存在单点故障问题。每个服务都要实现高可用、高负载,不会因为一个服务不可用而影响整套业务流。每个服务细粒度,专注于自己的问题域,与别的服务采用更好的Restful或者良好定义的API进行通信。服务都要高度通用化,即多种终端都可调用,不分语言和平台服务部署或升级简单,不会消耗大量人力并且部署过程不易出现人为错误,同时还具有快速注册与自动服务发现功能。 微服务的益处 许多AWS客户选择微服务架构来解决传统单体型架构中存在的敏捷性和可扩展性限制的问题。让我们来看看选择微服务架构能够带来哪些方面的益处吧。 敏捷 使用微服务的组织由多个负责运维独立服务的小团队组成。各个团队都是在界限明确的小范围内独立、快速地工作,从而起到减小迭代时间的效果。各个小团队效率的提升将使整个企业组织工作效率进行很大程序地提高。 图2标示由多个小团队组成的企业组织架构与由一个大团队组成的企业组织架构,在发布部署一个应用时的工作效率区别。 图2:部署微服务 创新 小团队可以独立自主地针对自己负责的问题域选择相关的技术、框架和工具,这就是创新的体现。职责与义务,让团队产生对自己的服务的责任感。 DevOps通过将开发与运维人员结合到一个团队中,让他们能更早地、更好地沟通,解决了开发部署过程中没必要的摩擦和矛盾。当应用程序部署时,敏捷的处理流程可以让开发和运维工作不再需要暂停下来,相反,整个软件交付周期,从提交代码到发布版本,整个流程将变成自动化的。测试一个新的想法,或者当新功能出现问题时及时回滚,将变得更加轻松。因为失败成本的降低,团队将更加乐于更改和创新。 质量 使用微服务架构您的应用程序,将一定程度上提高代码质量。这跟面向对象设计中提出的分模块开发有同样的效果:提高代码的可重用性、封装性和可维护性。 伸缩性 细粒度解耦的微服务架构另一个好处就是,它非常适合构建大规模系统。它允许针对不同的服务选择最适合的技术,这也是性能优化的体现。每个服务都可以使用最合适的开发语言和框架来实现,利用最优的数据持久化解决方案,并通过各自独立的服务配置进行调优。 合理解耦的微服务架构,可以独立地进行水平伸缩扩展。这相对于传统架构中使用的垂直伸缩有很大的优势。垂直伸缩指的是当业务量、流量增大时,升级硬件资源,将应用部署到“更大的机器”上,这会导致“机器硬件资源上限”和伸缩时宕机的问题。水平伸缩,通过将更多的服务部署到服务池(多个机器组成的集群)中,可以动态地适配流量,并且不会陷入单个机器资源上限问题。整个水平伸缩的过程将会是自动化的。另外,应用程序的可靠性将得到增加,因为出现问题的服务可以自动地被健康的服务替换掉,而不影响整个应用的运行。 可用性 微服务架构可以轻松实现故障隔离。通过健康检查、缓存、隔离仓、断路器等技术,可以减小当某个组件出现故障时的影响,从而保证应用的高可用性。 微服务架构面临的挑战 尽管拥有前面提到的那么多优点,但是微服务架构和所有其他架构一样,都不是解决所有问题的“银弹”。使用微服务架构也会面临一些挑战和难题。比如: 微服务架构都是分布式的,也就会存在所有“分布式计算误区”中提到的问题[iv]。 从单体型架构迁移至微服务架构,需要您准确地划分好各个服务间的界限,并且从应用层到数据库层松耦合代码依赖。 除此之外,在组织管理方面还存在着一些挑战,比如如何组建一个高效的团队,如何将团队转变成DevOps的生产模式,如何合理化开发团队与运维团队的沟通等。 本白皮书主要关注的是架构和运维方面遇到的挑战,如果想了解更多关于AWS如何运用DevOps的知识,请访问https://aws.amazon.com/devops[v] 架构复杂度 在传统单体型架构中,所有的复杂度和依赖都存在项目的代码库中。而对于微服务架构而言,复杂度变成了各个服务间的交互。 在架构上面临的挑战有处理异步通信、连锁故障、数据一致性问题、服务发现和授权认证等问题。 运维复杂度 […]

Read More

Amazon EC2 Container Service打造容器化的SaaS应用

概述 在SaaS化应用的改造中,容器技术的应用越来越广泛。相对于传统的虚拟机模式,容器化模式的隔离技术“更轻量”,“ 更快速”,“ 更便捷”. 目前业界越来越广的使用“容器”技术用于应用的微服务化改造,将自己产品的一些服务“微服务”化,构建基于云平台的SaaS化应用。 容器技术改造的难点 1. 技术的复杂性 容器技术应用的难点在于生产环境的实施及部署, 一般需要解决 容器资源编排调度 服务的自动发现及注册 容器的监控及报警 容器的扩展及收缩 这只是解决的部分问题,用户还必须去解决生产环境部署中怎样实现高可用部署及与公有云平台的集成问题。这使得Docker的生产化部署变得困难。 2. Docker编排框架的选型 许多人认为容器技术的价值在编排层,目前在容器的编排框架上主要的流派正在上演 “三国演义”包括,Google Kubernetes、Apache Mesos、Docker  DockerSwarm. Kubernetes,Mesos是目前市场上比较成熟的解决方案,占有较大的市场份额。DockerSwarm的优点是与Docker平台中的许多功能的集成,因为它平滑地内置于Docker平台中。上述三个编排框架都开放源代码,用户只需为技术支持服务付费。除了这些标准外还有许多初创公司也推出了自有的编排框架, 如Rancher使用Java语言开发了Cattle,它是Rancher实现的自有的一套基于Docker的编排引擎。众多的开源或自有的编排框架在不断发展,演进。这给客户的技术平台选型也带来极大的挑战。 Amazon EC2 Container Service(ECS) 为了降低容器平台生产部署的复杂性,Amazon ECS提供了一个平台来管理Docker容器。Amazon ECS是一项高度可扩展的高性能容器管理服务,您将不再需要安装、运维、扩展自己的群集管理基础设施。只需进行简单的 API 调用,您便可以启动和停止支持 Docker 应用程序,查询群集的完整状态,使用各种熟悉的功能,包括安全组、Elastic Load Balancing、EBS 卷和 IAM 角色。您可以使用 Amazon ECS 根据您的资源需求和可用性要求在您的群集中安排容器的置放。您还可以集成自己的或第三方的计划程序,以满足业务或应用程序的特定要求。Amazon EC2 Container Service 没有任何附加费用。您只需为您创建的用于存储和运行应用程序的 AWS 资源 (例如 EC2 实例或 EBS 卷) 付费。Amazon […]

Read More

Amazon EC2 Container Service – 发布回顾、客户案例和代码

今天似乎是回顾在过去一年左右的时间里我们添加到 [madison] 的一些功能,以及与您分享一些客户成功案例和代码的大好时机!该服务使您可以轻松地在托管的 EC2 实例群集上运行任意数量的 Docker 容器,并获得完整的控制台、API、CloudFormation、CLI 和 PowerShell 支持。您可以将您的 Linux 和 Windows Docker 镜像存储在 EC2 容器注册表中以方便访问。 发布回顾 我们先来看一些最新的 ECS 功能和一些演示如何使用这些功能的有用的操作方法博客文章: 应用程序负载均衡 – 去年我们添加了对应用程序负载均衡器的支持。这一高性能的负载均衡选项在应用程序级别运行,允许您定义基于内容的路由规则。它支持动态端口,并且可以跨多个服务共享,使您更容易在容器中运行微服务器。要了解更多信息,请阅读有关服务负载均衡的信息。 任务的 IAM 角色 – 您可以通过向 ECS 任务分配 IAM 角色来保护您的基础设施。这允许您基于每个任务精细地授予权限,从而可根据每个任务的需要自定义权限。阅读任务的 IAM 角色,了解更多信息。 服务 Auto Scaling – 您可以定义扩展策略,以根据需求的变化来扩展和缩减您的服务 (任务)。您只需设置所需的最小和最大任务数,并创建一个或多个扩展策略,服务 Auto Scaling 将负责其余的工作。服务 Auto Scaling 的文档可帮助您使用此功能。Blox – 在基于容器的环境中,调度是将任务分配给实例的过程。ECS 为您提供三个选项:自动 (通过内置的服务计划程序)、手动 (通过RunTask 函数) 和自定义 (通过您提供的计划程序)。Blox […]

Read More