通过RabbitMQ在AWS ECS中的Docker容器之间进行通信

Question

我的团队正在开发一个包含20个微服务的应用程序，它将部署在aws ecs ec2实例中。我计划在群集中启动3个AWS EC2实例。每个微服务都会有其任务定义和服务。

构建

docker容器，将其推送到aws ecr，然后使用Jenkinsfile通过jenkins部署到ecs。在taskdefinition json文件中，我将主机端口设置为0，以便每个Docker容器的主机端口将是随机的，并且如果我们将所需的服务数量增加到2个或更多，则不会发生任何端口冲突。

我想可以使用链接来通信具有相同任务定义的容器，但就我而言，我们无法预测Docker容器位于哪个实例上。

如果我们在其他服务器上使用Rabbitmq，它将如何与其他微服务通信？我在任务定义中使用“网络模式”作为“默认网络”，我应该将其更改为awsvpc吗？

Answer 1

“ awsvpc”网络模式不适用于服务发现

  

并非为此目的而设置网络模式awsvpc。这个   模式仅为每次运行分配一个弹性网络接口   任务，提供动态专用IP地址和内部DNS名称。这有助于获得与网络相关的主要好处，如控制，流日志，按任务定义进行流量监控。等，我   不知道是否有任何方法可以跟踪这些动态私有   IP，并明智地使用它们。

Ref-https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-networking.html

解决方案-

您可以寻找一种服务发现机制。 AWS最近启动了ECS服务发现，您可以将其与您的服务集成，这会大量使用Route 53并即时进行更改。
参考-
https://aws.amazon.com/blogs/aws/amazon-ecs-service-discovery/ https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-discovery.html

一个简单的说法是，人们也建议使用“ ecs-task-kite”，但似乎现在还没有准备好投入生产- https://github.com/awslabs/ecs-task-kite

目前看来，最好使用AWS ECS服务发现机制。虽然，我还没有机会对其进行测试。

另一种方法是对RabbitMQ本身使用不同的群集，根据所需的协议通过NLB或ALB公开它。并让服务群集使用其ALB / NLB端点与RabbitMQ群集进行通信。如果RabbitMQ无法扩展，则使ASG [min，max，desire = 1]。

Answer 2

我现在正在运行类似的部署。 RabbitMq服务器是与群集在同一vpc中的单独实例。安全组配置为允许来自该网络的所有流量。我的部署的“弱”部分是我没有进行任何服务发现。由于计算机没有重新启动，因此本地IP地址（10.0 ....）从未更改，因此我在任务定义中定义了一个指向该IP地址的Extrahost。

当服务要读取/发布消息时，y使用定义的主机。如果由于某种原因我重新启动了Rabbitmq实例和ip地址，则必须使用已更新的ip地址重新部署容器。

这可以使用实例元数据来解决

[ec2-user ~]$ curl http://169.254.169.254/latest/meta-data/local-ipv4

根据官方文档Ec2 Instance metadata将其注册到某个地方（redis，zookeeper等），然后您的服务可以对其进行检查，因此，如果rabbitMq实例重新启动，则无需重新部署。