在 AWS ECS 中的任务定义之间链接容器? [英] Linking containers between task definitions in AWS ECS?

问题描述

我正在尝试在 AWS ECS 中设置一个具有关联数据库的基本 Web 应用程序.在本地，我在不同的容器中进行了这些设置，而在 ECS 上，我希望有单独的任务定义，以便我可以分别扩展这两个.

I'm trying to setup a basic web application, which has an associated database, in AWS ECS. Locally I have these setup in different containers, and on ECS, I'd like to have separate task definitions so that I may scale the two separately.

1. 我在 ECS 中成功地将我的第一个任务定义注册为 david_mongodb.它有一个名为 david_mongodb 的容器.
2. 然后我尝试将我的第二个任务定义注册为 david_web，它有一个名为 david_web 的容器，它通过 david_mongodb:db 链接数据库.

3. 当我点击创建"时，它返回一个错误:

1. I registered my first task definition as david_mongodb successfully in ECS. It has a container named david_mongodb in it.
2. Then I attempted to register my second task definition as david_web, which has a container named david_web that links the database via david_mongodb:db.

3. When I click 'Create', it returns an error:

Unable to create Task Definition
Linked container 'david_mongodb:db' doesn't exist.

似乎任务定义在其他任务定义中看不到容器名称?我想将 david_web 和 david_mongodb 容器放在同一个任务定义中会起作用，但我不想这样做:它会阻止我扩展任一网络应用程序或数据库分开.这个概述似乎证实了我的架构是推荐的...

It seems like task definitions can't see container names in other task definitions? I'm thinking putting both david_web and david_mongodb containers in the same task definition would work, but I don't want to do that: it would prevent me from scaling either web app or database separately. This overview seems to confirm that my architecture is recommended...

那么我如何链接位于不同任务定义中的容器?或者还有其他巧妙的方法来处理这个问题吗?

So how do I link containers that live in different task definitions? Or is there another clever way of handling this?

推荐答案

ECS 任务定义中的链接类似于 Docker 链接 并且仅当容器是同一任务定义的一部分时才起作用(作为单个任务定义的一部分的容器一起放置在同一主机上).为了在不同任务定义中的容器之间进行通信，您需要一种机制来发现容器所在的位置(什么主机)以及通信端口.

Links in an ECS task definition are analogous to Docker links and only work when the containers are part of the same task definition (containers that are part of a single task definition are placed together on the same host). In order to communicate between containers in different task definitions, you'll need a mechanism for discovering where the containers are located (what host) as well as the port for communication.

ECS 通过 service 功能，其中任务将自动在 ELB 中注册并在 ELB 中适当取消注册.

ECS has integration with Elastic Load Balancing (Application Load Balancers, Network Load Balancers, and Classic Load Balancers) through the service feature, where tasks will be automatically registered in the ELB and deregistered in the ELB appropriately.

ECS 还集成了 Route 53 自动命名 用于使用 A 和 SRV 记录的基于 DNS 的服务发现.您的服务任务可以自动输入到 DNS 记录中或从 DNS 记录中删除.

ECS also has integration with Route 53 Auto Naming for DNS-based service discovery using A and SRV records. Your service's tasks can be automatically entered into and removed from DNS records.

亚马逊服务发现使用 DNS 的 ECS 描述了一种不同的方法，其中 Lambda 函数通过 CloudWatch Events 侦听 ECS 事件流并更新 Route 53 DNS 记录. 此方法已被上述 Route 53 自动命名功能取代.

Service Discovery for Amazon ECS Using DNS describes a different approach where a Lambda function listens to the ECS event stream through CloudWatch Events and updates Route 53 DNS records. This method has been superceded by the Route 53 Auto Naming feature described above.

如果您想避免负载均衡器和 DNS，另一种模式可能是 大使容器(有一个名为 ecs-task-kite 的示例，它使用 ECS API)或者您可能对覆盖网络感兴趣(Weave 有一个相当详细的 其解决方案的入门指南).

If you want to avoid load balancers and DNS, another pattern might be an ambassador container (there's a sample called the ecs-task-kite that uses the ECS API) or you might be interested in an overlay network (Weave has a fairly detailed getting started guide for their solution).

Nathan Peck 正在跟踪与 ECS 相关的许多不同主题，包括服务发现、这里.

Nathan Peck is keeping track of a number of different subjects related to ECS, including service discovery, here.

这篇关于在 AWS ECS 中的任务定义之间链接容器?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！