2

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

构建 docker 容器，推送到 aws ecr，然后使用 Jenkinsfile 通过 jenkins 部署到 ecs。在 taskdefinition json 文件中，我将主机端口设置为 0，这样每个 docker 容器主机端口都是随机的，如果我们将所需的服务计数增加到 2 或更多，则不会有任何端口冲突。

我猜同一任务定义上的容器可以使用链接进行通信，但在我的情况下，我们无法预测 docker 容器在哪个实例上。

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

4

2 回答 2

0

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

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

参考 - 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 集群对话。使 ASG [min,max,desire=1] 以防 RabbitMQ 不可扩展。

于 2018-12-21T05:26:57.587 回答
0

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

当服务想要读取/发布消息时，y 使用定义的主机。如果由于某种原因我重新启动rabbitmq 实例和IP 地址，我将不得不重新部署所有具有更新IP 地址的容器。

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

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

根据官方文档Ec2 Instance metadata在某处注册它（redis，zookeeper，etcd ...），然后您的服务可以检查它，因此如果 rabbitMq 实例重新启动，则不需要重新部署。

于 2018-12-28T09:21:03.187 回答