Amazon Elastic Container Service 现在支持 Amazon EFS 文件系统

在仅仅五年前，Jeff 撰写了这篇关于推出 Amazon Elastic Container Service 的博文。我还记得阅读这篇文章并思考容器有何新奇和独特之处时的情形。经过仅仅五年的快速发展，容器就已融入到大多数开发人员的日常生活中，不过，虽然客户在越来越多地采用 ECS 等容器编排系统，但有些类型的应用程序仍然很难迁移到这个容器化的世界。

当构建需要数据持久性或共享存储的应用程序时，客户面临着一个挑战：容器本质上是临时存在的。随着容器动态收缩和扩张，当容器终止后，所有本地数据都将丢失。如今，我们正在为 Amazon Elastic File System (EFS) 文件系统推出支持，以改变 ECS 的这种状况。容器无论是运行在 ECS 还是 AWS Fargate 上，都将能够使用 Amazon Elastic File System (EFS)。

借助这种新的能力，我们的客户可以将需要共享存储的应用程序（例如内容管理系统、内部开发运营工具和机器学习框架）容器化。一组全新的工作负载现在可以受益于容器带来的多种优势，这样，客户就能够加快部署过程、优化基础设施利用率和构建更加富于弹性的系统。

Amazon Elastic File System (EFS) 提供了一个完全托管、具有高可用性并且可以扩展的共享文件系统；这意味着您可以将数据存储在计算机以外的其他位置。它还是一项区域性的服务，意味着这项服务会在 3 个可用区以内存储数据，以实现高可用性和耐用性。

到目前为止，如果您在一组 EC2 实例上运行您的容器，则可以获得与 ECS 配合使用的 EFS。但如果您希望将 AWS Fargate 用作容器数据面，则在此公告发布之前，您无法安装 EFS 文件系统。Fargate 不允许客户访问 Fargate 队组内的托管实例，因此您无法对实例进行所需的修改以设置 EFS。

我相信，我们的很多客户很高兴现在能够轻松将 EFS 文件系统连接到 ECS，就个人而言，我也非常乐于看到我们可以将这项新功能与 Fargate 结合使用，它非常适合我目前构建的这个小型附带项目，并最终让我们能够获得可以与无服务器容器配合使用的持久存储。

ECS 和 EFS 有充分的理由在它们的名称中包含 Elastic 一词，因为这两项服务都可以根据您的应用程序需求扩张和收缩。EFS 可按需从零扩展到 PB 级容量，全程无中断，并随着文件的添加和移除自动增大和缩小。对于 ECS，可以选择使用 Cluster Auto Scaling 或 Fargate，以确保增大或缩小您的容量以满足需求。对我们的客户来说，这意味着他们只需为实际要使用的存储和计算付费。

已经说得够多了，我们来了解有趣的部分，看一看如何将容器化的应用程序与 Amazon Elastic File System (EFS) 配合使用。

一个简单的共享文件系统示例

我为此示例构建了一个基本基础设施，以便能够展示将 EFS 添加到 Fargate 集群之前和之后的效果。我首先创建了一个跨越两个可用区的 VPC。接下来，我创建了一个 ECS 集群。在此 ECS 集群上，我打算使用 Fargate 运行两个容器，这意味着我不必设置任何 EC2 实例，因为我的容器会运行在 AWS 托管的 Fargate 对组上。

为了部署我的应用程序，我创建了一个任务定义，它使用一个名为 Cloud Commander 的开源应用程序的 Docker 映像，此应用程序是一个简单的拖放式文件管理器。

在 ECS 控制台中，我创建了一个服务，并使用我创建的任务定义来部署我的应用程序。部署了这项服务并预置了容器之后，我转到在我的服务中创建的 Application Load Balancer URL，我发现我的应用程序看起来正在运行。我可以拖放文件，以将其上传到此应用程序中。

不过，我遇到了一个问题。如果刷新此页面，我拖放的待上传文件有时会消失。之所以出现这种情况，是因为我有两个容器在运行我的应用程序，但它们都在使用各自的本地文件系统。当我刷新我的浏览器时，负载均衡器会将我转到这两个容器之一，但这两个容器只有一个将映像存储在它的本地卷中。

我需要的是一个这两个容器都能挂载并向其写入文件的共享文件系统。

接下来，我在 EFS 控制台内创建了一个新的文件系统。在此向导中，我选择了在我创建 ECS 集群时使用的那个 VPC，还选择了 VPC 跨越的所有可用区，并让此服务在每个可用区中创建挂载目标。这些挂载目标意味着，位于不同可用区中的容器依然能够连接到文件系统。

对于此向导中的所有其他选项，我选择了默认设置。在第 3 步中，我单击了此按钮，以便添加接入点。使用接入点，我可以分配对于文件系统的特定应用程序访问权限，并极其精细地控制我的应用程序可以访问哪些数据。您可以为您的 EFS 文件系统添加多个接入点，并为同一个文件系统提供不同的应用程序、不同的访问权限级别。

我正在部署的这个应用程序将为我的网站处理用户上传行为，因此我会创建一个 EFS 接入点，以使此应用程序拥有对于 /uploads 目录的完全访问权限，但仅此而已。为此，我会创建一个具有新用户 ID (1000) 和组 ID (1000) 且其主目录为 /uploads 的接入点。对于我要创建的这个目录，此用户和组将是拥有完全权限的拥有者，所有其他用户对此目录只有读取权限。

安全性是 AWS 的第一要务，为了防止 EFS 文件系统遭到未经授权的访问，我们的团队一直在努力确保 ECS 与 EFS 集成，以提供多层安全性，包括基于 IAM 角色的访问控制、VPC 安全组以及数据加密传输。

完成此向导之后，我就创建了这个文件系统，并获得了文件系统 ID 和接入点 ID。我需要这两个 ID 才能在 Fargate 中配置任务定义。

我要回到我的 ECS 集群内的任务定义，并创建一个新版本的任务定义。我向下滚动到此定义的“卷”部分，然后单击添加卷。

随后，我可以添加我的 EFS 文件系统详细信息，并选择我刚刚创建的正确文件系统 ID 和正确的接入点 ID。

我还选择启用加密传输，但对于此示例，我并未启用 EFS IAM 授权。在大型应用程序中，很多客户需要对文件系统的不同部分设置不同的访问权限级别，在这种情况下，此授权会非常有用。此功能可利用 IAM 授权简化管理工作，如需这方面的更多详细信息，请阅读我们在今年年初推出此功能时撰写的博文。

现在，我更新了我的任务定义，因此可以更新我的 ECS 服务以使用这个新定义了。这时，我还必须确保将平台版本设置为 1.4.0。

此服务将部署我的两个新容器，并弃用那两个旧容器。现在，新的容器将使用共享的 EFS 文件系统，因此我的应用程序现在能够正常运行。

如果我上传了文件，然后再次访问此应用程序，我的文件也依然会在那里。即使我替换、扩张或收缩了我的容器，此文件系统也依然存在。

展望未来

我非常欣赏容器团队最近推出的创新成果，并乐于观看他们的公共路线图；对于未来，他们有一些真的非常激动人心的计划。如果您有什么想法或功能请求，请务必和其他众多客户一样畅所欲言，以帮助容器团队确定路线图。

此新功能将在可以使用 ECS 和 EFS 的所有地区推出，而且不会产生额外费用。因此，请在 AWS 控制台中先睹为快，并让我们知道您的想法。

祝您容器化顺利！

— Martin