AWS服务建设之路-Docker集群

AWS服务建设之路-Docker集群,第1张

最近的项目处于种种原因要放到亚马逊上面,也正好体验一下世界最大云计算平台的服务。于是又开始了漫长的爬坑路。不得不说AWS的管理交互台设计充满了工业气息,新手很难上手,但熟练工会觉得很直观。
简单来说分4步:

ECR是私有镜像仓库,先把自己的镜像上传上来,这一步的坑就在于要上传镜像不能直接 docker login 需要

ECS有一个很重要的概念,任务定义。这个概念类似于 k8s 的 pod。任务定义抽象出了任务这个概念,一项任务可以包含多个docker镜像及对应的参数/环境配置,并且拥有CPU,内存限额。
任务定义拥有版本号,只能创建新版本不能修改以前版本。
而在集群中的调度则是以任务定义为对象。
所以我们为我们每一个服务创建了1个任务定义,一个任务定义包含1个镜像。

这里有3种网络模式供选择:

大部分情况我们都使用桥接模式,少部分情况使用 awsvpc 。主机模式则尽量不要使用,不利于编排。 awsvpc 的具体使用场景会在下文服务发现章节介绍。

动态端口映射 技术,是指将容器在宿主机上的外部端口随机映射,只在桥接模式下有效。

勾上日志配置,ECS就会自动把镜像的标准输出定向到 CloudWatch,就可以去那里查看镜像日志了,当然专业的日志系统还是得ELK。

ECS有2种集群,Fargate 与 EC2 Linux。

Fargate是很酷炫的架构,特别是在资源占用量不稳定,时间不确定的情况下很合适。而且全部使用awsvpc网络模式,所有的服务都可以拥有独立IP,纯正的无服务器架构。只有一个缺点,贵(同样资源量是EC2的3倍价格

建议创建空集群,再自行添加服务器,不然容易触发一些 keng

上面说了任务定义,那么任务这个概念也很简单,被运行的任务定义。
一个任务可能包含多个容器,这个任务可能是在有限时间内执行完毕就停止的,比如一次性脚本,也可能是无限运行的,比如nginx服务器。

服务这个概念比较复杂,一个服务会管理一个任务定义在运行时的方方面面

服务没有停止功能,只能修改任务数为0。
服务删除后,需要手动停止已经运行的任务。

AWS提供基于Router53(DNS服务)的服务发现,其实很难用,awsvpc模式的很方便,桥接模式下特难用。
在awsvpc模式中 ,因为每个任务都有自己的IP,所以端口可以直接固定,不会存在冲突,配合基于Router53的服务发现可以直接完成完美的服务发现--无论如何更新重启服务,总能通过固定域名访问到服务。但因为一台服务器只能绑定3张网卡,所以只能启动3个awsvpc模式容器。
在桥接模式中 ,每个任务都使用宿主机的ip,以及随机分配的端口,所以服务发现需要带上端口,不然也不能正常发现。AWS提供SRV类型的DNS记录用作服务发现,本身是没有问题,但SRV并不是被广泛接受的记录类型,浏览器与网络库均不能解析SRV记录,所以要访问服务还需要定制DNS解析。
所以我们最终选择使用Eureka作为服务发现服务,使用awsvpc作为补充的服务发现服务,比如将Eureka本身及xxl-job等使用awsvpc部署。

在选用了Eureka之后,又遇到了问题。因为使用了动态端口映射,所以向Eureka注册的端口不是Spring的监听端口,并且容器内部无法知道宿主机的ip与端口。
这里通过多种方式配合破局:

不过要注意,启用元数据服务,需要修改ECS代理配置,而这个配置是在集群创建时就写入服务器的,所以要修改ECS代理配置,必须要先修改自动伸缩组的初始化脚本,再删除伸缩组内所有服务器,再重新添加服务器。

这样就可以在Eureka中心正确展示服务信息了。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/10857084.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-11
下一篇 2023-05-11

发表评论

登录后才能评论

评论列表(0条)

保存