前面几篇文章记录了我学习使用 AWS Lambda@Edge 由浅入深的过程,通过 Lambda@Edge 实现了请求重定向和动态生成响应:
今天再进一步,使用 Lambda@Edge 实现反向代理。
前面几篇文章记录了我学习使用 AWS Lambda@Edge 由浅入深的过程,通过 Lambda@Edge 实现了请求重定向和动态生成响应:
今天再进一步,使用 Lambda@Edge 实现反向代理。
最近用了不少 AWS Lambda@Edge,前两篇文章记录了我用 Lambda@Edge 实现请求重定向的过程,今天我又完成了一项新的需求,使用 Lambda@Edge 动态生成响应。
As we know, 在 RFC 中有明确说明 CNAME 记录不能与其他记录共存,特别是容易与 MX 记录产生冲突。因此,很多域名解析服务提供商都不允许为顶级域名设置 CNAME 解析。那如果我希望访问域名 example.net 跳转到 example.com 该如何做呢?
使用Nginx等后端服务器做跳转这里不考虑,现在讲究 Serverless 嘛。通过查询 AWS 相关文档,我找到了两种方法。
需要注意:
下面详细记录我的配置过程。
前一段时间,我在工作中用 Lambda 实现了很多功能,比如,对云上资源进行定时巡检,CloudWatch警报转发等等。现在我对 AWS Lambda 类似的传统用法已经非常熟悉了,除此之外,AWS Lambda还有一个强大的功能 —— Lambda@Edge。之前通过学习文档了解了一些,今天正好有实际需求可以拿来练练手。
看过这么一种理论:一年的时间对于一个3岁的孩子来说,是他所经历的整个人生的三分之一,而对于一个耄耋老人来说,只是他漫长人生中的短短的一小部分,所以年龄越大会感到时间流逝的越快。小时候一下午就可以跑东跑西玩个痛快,暑假就好像有一年那么长。而现在一年似乎也不过是转瞬之间的事情。从前鲜活的记忆在慢慢褪色,那些令人开心、激动、难忘亦或是伤心的事情似乎也越来越远。翻看老照片时我会感到恍惚,这些真的是我所经历过的生活吗?这些事真的是我亲身参与其中的吗?往昔不可谏,来者犹可追。还是希望能把生活过的更加充实,更加有意义一些。至少在一年结束之际回首之时,可以想起些什么有趣的事会心一笑,而不至于空叹时光飞逝。在2018年结束之前我就打算着做做总结了,因为各种原(jie)因(kou),今天已经是2019年的1月12日了,就算是流水账也要写点什么了。
前段时间把很多项目都上了 Auto Scaling 功能,这两天发现有些 EC2 实例缩减后留下了 EBS 没有释放。这是因为实例的块存设备(Block devices)没有设置终止时释放(DeleteOnTermination)。
在启动新实例或创建 AMI 映像时可设置终止时释放(DeleteOnTermination),但已启动的实例该怎么办呢?就此问题我求助了 AWS 客户支持,在这里把解决方案分享出来。
前两天对 AWS Lambda 做了一些学习,发现正好有实际需求用的上。于是业务需求又反推学习,现在我对 AWS Lambda 有了更多的了解。下面以问答形式记录一些我遇到的问题和解决方案。
按照团队的标准规范,在 AWS 上新建的 EC2 实例都要添加 Name, Region, App, Env, Layer, Group 等标签。其中 Name 标签的格式是:{Region}-{App}-{Layer}-{Env}-{Group}-{IP后两段}
,例如:vg-store-web-release-a-12-34
。
在 Auto Scaling Group 的配置上,我设置了为新扩容出的实例自动添加 Region, App, Env, Layer, Group 这些标签,但因为 Name 标签中包含 IP 后缀,因此没办法预先设置在 Auto Scaling Group 上,只能在实例创建出来分配到私有 IP 后手动的添加 Name 标签。
为了解决这个问题,我最先想到的方案是:使用脚本调用 API 定时扫描没有 Name 标签的实例,然后获取实例的 PrivateIP 和其他标签拼装出 Name 添加到实例上。
我很快就编写出 Demo,经过测试,可以实现需求,但总觉得不够优雅:
后来我想到了 Auto Scaling Group 有 LifeCycle Hook,又从它的设置界面了解到了 CloudWatch Events 这一服务。
最后通过 CloudWatch Events 和 AWS Lambda 就可以很好的实现我的需求!
在了解了目标跟踪扩展策略(Target Tracking Scaling Policy)的机制之后,突然就对 AWS Auto Scaling 有了新的理解。它最核心的部分其实是 CloudWatch!
想明白了这一点之后,AWS Auto Scaling 就不再那么神奇与神秘了。我甚至可以利用 CloudWatch 和 EC2 的相关 API 自己来实现一套 Auto Scaling!
(当然,这并不能否认 AWS Auto Scaling 的强大,无论是在细节上还是用户体验上它都打磨的非常完美了。)
AWS Auto Scaling 有手动扩展(Manual Scaling)、计划的扩展(Scheduled Scaling)及动态扩展(Dynamic Scaling)三种扩展方式。
手动扩展(Manual Scaling)、计划的扩展(Scheduled Scaling)两种方式使用比较简单,本文主要记录我在使用动态扩展(Dynamic Scaling)时遇到的一些疑惑及解答。
动态扩展(Dynamic Scaling)目前支持的扩展策略类型有:
详细的介绍可以看官网文档:适用于 Amazon EC2 Auto Scaling 的动态扩展
以下内容会记录一些在文档中没有写清,我通过实际测试并与AWS 技术支持沟通得到的结果。