亚马逊AWS官方博客

Amazon Simple Storage Service（简称S3）是AWS在2006年发布的第一款云服务产品，S3作为对象存储具有海量存储、接口灵活、11个9持久性、价格便宜等特点，特别适合存放静态文件如图片、视频、日志以及备份文件等等，同时S3是AWS大数据解决方案中重要组成部分，以EMRFS的形式与EMR（AWS托管的Hadoop平台）结合提供计算与存储分离的灵活架构。 熟悉S3控制台的小伙伴一定发现，自从5月份开始，控制台的界面焕然一新，甚至有点无处下手，但熟悉起来后又有些爱不释手，下面我们将介绍下新版控制台带来了哪些新的功能，以及如何给你的工作带来极大效率提升。 新版控制台的操作说明，图文并茂，详见： http://docs.amazonaws.cn/AmazonS3/latest/user-guide/what-is-s3.html 一、创建存储桶 创建存储桶的时候除了配置桶名、存储桶区域之外，还可以配置版本控制、日志、标签以及访问权限，现在用户可以在新版控制台使用“从现有存储桶复制设置”的功能，选择相同配置的存储桶即可，避免重复设置。 二、上传对象 在控制台下除了正常的通过点击上传按钮选择上传文件完成上传外，新版控制台支持在存储桶界面下，直接将待上传的对象拖放到页面上。通过新版控制台上传单个文件支持最大78GB。 对存储桶中对象的上传、删除、重命名等操作，页面底部可以看到该操作的进度及其他操作的历史记录。 三、ACL 我们可以通过配置存储桶及对象的ACL来实现存储桶和对象的访问控制，老版控制台的部分名称容易让人引起歧义，以存储桶ACL为例，如下图所示，其中查看权限是指查看该存储桶权限的权限，即查看该存储桶ACL的权限，而不是指查看存储桶的权限，编辑权限同样是指编辑权限的权限，不是编辑存储桶的权限。 在新版控制台中很好的避免了这点误区，分对象访问和权限访问，这里以存储桶的ACL举例，见下图： 其中一个新功能是我们可以在管理用户处添加其他帐号的规范ID（https://docs.aws.amazon.com/zh_cn/general/latest/gr/acct-identifiers.html ）或帐号的Email向该帐号中的IAM user/role授权访问，以实现跨帐号访问，需要注意的是对方帐号的IAM user/role拥有对该存储桶的操作权限取决于此处我们设置的ACL以及对方帐号中IAM user/role本身policy设定的权限。 四、标签Tag S3标签是随S3新版控制台一起发布的一个服务特性。标签可以帮助你对存储桶以及对象进行分类或标记，类似我们给EC2等资源添加标签一样，每个S3标签也是一个键值对，每个对象最多可添加10个标签键值对，键值对大小写敏感。通过使用标签，我们可以创建基于标签的IAM policy以实现细粒度的权限控制，比如标签为PHI的值为true时，仅供只读。同时，在使用S3数据生命周期管理、分析、指标等功能的时候，可以创建基于标签的过滤器，实现细粒度的资源管理。 S3 标签作为新服务特性，相应的API也同步发布，比如PUT Object tagging, GET Object tagging, DELETE Object tagging以及其他支持标签的API如PUT Object, GET Object, POST Object, PUT Object-Copy，详细可参考： http://docs.aws.amazon.com/zh_cn/AmazonS3/latest/dev/object-tagging.html 需要注意的是，标签遵循最终一致性模型。 五、生命周期管理 数据通常从创建后会经历频繁访问、低频访问、极少访问的数据热度周期，相对于热数据，冷数据适合以成本更低的方式存储，比如热数据存放在S3 standard，冷数据存放在S3-IA，归档数据存放在Glacier等，以达到成本最优的目标。我们可以使用S3数据生命周期管理通过配置相应的规则来实现数据的生命周期管理，随着S3标签的发布，现在我们可以创建基于前缀和/或基于标签的规则，以实现更细粒度的资源管理。详细操作步骤见： http://docs.amazonaws.cn/AmazonS3/latest/user-guide/create-lifecycle.html 六、存储类分析 存储类分析是新发布的功能，通过该工具，我们可以更加直观的了解到存储桶中的数据活跃情况，帮助我们决策何时将不常访问的数据从S3 Standard转换为S3-IA，即为配置数据生命周期管理提供数据支持。 同时，可以创建筛选条件，选择对整个桶中对象或者具有某些前缀或标签的对象进行分析，即对对象进行分类分析，需要注意的是，分析是从启用该功能后一段时间后才能看到结果（通常是24~48小时），并不是可以立刻可以看到分析结果。 通过存储类分析，我们可以可视化的了解到存储桶数据在过去30天的检索量，占比，以及多个时间范围段内数据存储与检索的情况，该数据每天更新，并且可以以csv的格式导出到S3存储桶以供下载，可使用Quicksight等BI工具进行展现。 csv中字段说明见： http://docs.amazonaws.cn/en_us/AmazonS3/latest/dev/analytics-storage-class.html#analytics-storage-class-export-to-file 配置存储类分析详细操作步骤见： http://docs.amazonaws.cn/AmazonS3/latest/user-guide/configure-analytics-storage-class.html […]

Kong是一个开源的API GW及微服务管理层，基于Nginx, Cassandra或者PostgreSQL构建，最初由Mashape开发，用于为其API Marketplace管理超过15,000个API和微服务，并于2015年开源。Kong具有如下优点： 可扩展性：通过简单地添加更多的机器，Kong可以轻松地水平缩放，这意味着您的平台可以处理几乎任何负载，同时保持低延迟。 模块化：可以通过添加新的插件来扩展，并通过RESTful Admin API轻松配置所有插件。 平台无关性：Kong可以运行在任何地方，包括本地数据中心及公有云，支持物理机，虚机及容器部署。 目前Kong的最新版本为0.10.2，支持的插件如下： 认证：Basic Authentication, Key Authentication, OAuth2.0 Authentication, OAuth 2.0 Introspection, HMAC Authentication, JWT, LDAP Authentication 安全：ACL, CORS, Dynamic SSL, IP Restriction, Bot Detection 流控：Rate Limiting, Response Rate Limiting, Request Size Limiting 无服务器架构：AWS Lambda, OpenWhisk 分析监控：Galileo, Datadog, Runscope 内容转换：Request Transformer, Response Transformer, Correlation ID 日志：TCP/UDP/HTTP Logging, File […]

基于地理信息的应用已经越来越深入到日常生活中，人们经常会在应用中寻找附近的朋友，车，餐厅或其它资源。而与此同时，随着物理网技术及设备的普及，应用需要更加实时和精确的处理来自各种数据源（包括用户手机，各种传感器设备及其他系统）的大量数据，以完成相关的搜索和计算距离等操作。 架构 对于开发者来说，Redis因为其性能上的优势往往会被采用作为位置数据的缓存，只是在3.2版本之前需要代码中把位置数据进行Geohash后才能有效的排序和分析。不过3.2版本后，Redis已经能够原生支持基于位置信息的存储，计算及搜索了。Amazon ElastiCache是AWS提供的托管型的数据缓存服务，借助该服务，用户能够在云中轻松部署、运行和扩展分布式内存数据存储或缓存。 Amazon ElastiCache 的Redis引擎是一项与 Redis 兼容的内存服务，兼具 Redis 的易用性和强大功能，同时还可为要求最苛刻的应用程序提供适用的可用性、可靠性和性能，提供单节点和多达 15 个分片的群集，从而可将内存数据扩展到高达 3.55TiB。这里，我们可以基于Elasticache并结合AWS其他服务构建出以下的示例架构： 1）终端设备获取GPS位置信息，定时或基于事件将数据上传到云端。在AWS上可以选择使用IoT或Kinesis等托管型服务作为数据收集的接收端，也可以使用部署在EC2／Lambda上的自定义服务。 2）所有位置信息写入可以自动扩展的DynamoDB，基本Schema包含设备Id/Timestamp/Geo location, 方便历史查询或轨迹查询。 3）打开DynamoDB流，用KCL或Lambda监听DynamoDB的数据改变，并将当前变化的位置数据更新到Elasticache中建立基于Geospatial的索引缓存。 4）手机应用搜索附近资源时，部署在EC2/Lambda的查询服务利用Elasticache geospatial直接获取结果。 实现 如前文所述，步骤1和2可选择的方案很多，比如采用AWS IoT服务甚至可以无需任何代码仅通过配置即可完成云端的功能讲数据实时写入相应的DynamoDB表中。因此，本文将着重介绍如何实现前文架构中的3和4步： a) 打开DynamoDB 流，获取流的ARN用于读取，如下图： 读取DynamoDB流数据有三种方式：利用Kinesis adapter，利用低级别API以及利用Lambda函数来进行读取。从易用性的角度来说，当然是Lambda函数最简单，不需要考虑shard，吞吐和checkpoint等问题而专注于业务逻辑。但是Lambda函数并不是在所有的AWS区域都支持，因此本文采用第一种方式利用Kinesis adapter完成读取。具体参考文档：http://docs.amazonaws.cn/amazondynamodb/latest/developerguide/Streams.KCLAdapter.html b) 在读取流的同时，我们需要将最新的地理位置信息利用GEOADD更新到Elasticache中。前文提到Redis在3.2版本后，Geospatial Indexing已经被原生支持，而它实际上是Sorted List数据结构的一种扩展，即排序 key扩展成了经纬度，如下图所示的数据结构，并且可以方便的使用基于地理信息的API，例如GEOADD——添加地理位置 。 通过Elasticache可以快速构建出一个Redis环境，包括支持shard的集群模式，如下图所示。 构建完成后，通过Elasticache提供的终端节点就可以访问cache了。 需要注意的是如果选择的Redis是集群模式，那么就得同步升级支持Redis集群模式的客户端SDK用以开发。因为Redis的集群提供的是分片功能，它会把不同的slots分布在不同的节点上，需要由客户端通过CRC16(Key)取模从而计算出数据在哪个节点上。目前可以支持redis集群模式的客户端有很多，比如本文用到的java的jedis以及nodejs的ioredis。 综合a，b两步的示例代码的StreamCacheProcessor.java如下(其余代码参考http://docs.amazonaws.cn/amazondynamodb/latest/developerguide/Streams.KCLAdapter.Walkthrough.CompleteProgram.html )： import java.nio.charset.Charset; import java.util.HashMap; import java.util.HashSet; import java.util.List; import java.util.Map; import java.util.Set; import org.apache.commons.logging.Log; […]

基本概念 持续集成/持续交付 互联网软件的开发和发布，已经形成了一套标准流程，最重要的组成部分就是持续集成（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的流程图： […]

在这个智能家居、大数据、物联网设备、手机、社交网络、聊天机器人和游戏机的时代，流媒体数据场景无处不在。利用 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 […]

去年年底，我宣布推出预览版 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) […]

本文主要介绍了如何利用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的未调优查询可能是由于不正确的嵌套连接引起的。 […]

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 […]

通常情况下，堡垒机（也称为“跳转机”）是在系统中访问私有主机的一个最佳实践。例如，您的系统可能包含一个不希望被公开访问的应用服务器，当需要在这台服务器上进行产品的更新或系统补丁程序的管理时，您通常会登录到堡垒机，然后从那里访问（即“跳转到”）应用服务器。 本文将向您介绍使用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函数调用。 […]

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 […]