Pensieve: 1903

2019-03-29 20:48

所观所读

主要在读APUE, 做了些实验还写过一篇结果. 默克家庭医生手册和豪斯医生都在缓慢推进中. 前者到了11%, 后者第六季看了一半.

看完了Free Solo, 世界真大, 这些人的想法和我周围的人相差也好大.

看完了Netflex家的新片Love, Death & Robots. 我从小就喜欢寓言和小小说, 挺喜欢这种短篇的. 大多数时候, 我们的idea的内核都很简单, 用这种简单的idea肯定无法衍生出一个长篇. 与其用力憋一个虎头猪肚豹尾, 不如直接就虎头豹尾, 不是更好吗?

所玩

文明6和Skyforce Reloaded玩得比较多, 后一个正在努力追求单人全成就. Switch上文明6的存档加载很慢, 加载的时候可以看看豪斯医生什么的. 另外, 又开始捡起放下了许久的大师模式塞尔达, 目前神庙已经刷完了, 种子近200个.

本月去了趟South Gate Bridge附近的公园, 里面有个粉红色的湖. 湖不大, 颜色挺讨喜, 所以人还不少, 不过除了湖水之外没什么有趣之处, 所以一般人去了那儿也就绕着湖转悠一圈, 拍拍照片走人.

几个Cloudformation中Serverless这个宏相关的bug

最近在做Serverless相关的工作. 我们前台用Cloudfront和S3来放静态资源, 后台用了API Gateway和Lambda来写逻辑. 在其他同事的建议下使用了SAM, 此时, 在Cloudformation模板里面需要使用一个名为Serverless的宏. 这样可以大量简化模板的编写, 提高模版的可维护性. 缺点是这个宏的代码不由我们控制, 逻辑对于我们而言也是黑箱子. 这个黑箱子不能正常工作时, 我们是完全没有办法的.

首先是被AWS官方认证的bug. 我们在模板里面定义了若干个DynamoDB表, 现有另外一个stack需要引用这些表里的内容. 正统的做法当然是在定义了表的模板中定义若干个Output, 把这些DynamoDB的属性(比如 Arn)export出去, 这样其他stack就可以通过ImportValue来引用了. 我们加入这些Output后更新这个stack会报内部错误而不能继续. 我们各种尝试后交给AWS客服解决, AWS工程师进一步将整个stack削减到只有一个DynamoDB的表, 加入Output, 同时使用了前述的Serverless宏, 这样就能重现我看到的内部错误. 另外, 如果我们通过Changeset来更新, 则不会触发问题, 而当我们直接更新模板时, 就会出现问题. 我们目前解决方案是在其他需要使用Dynamodb表的模板中将表的Arn人肉拼出来, 虽然能工作, 但是毕竟只是hack.

第二个被AWS官方认为不是bug, 但是我个人认为是bug. 在使用API Gateway时, 一般修改了参数或属性时我们都需要做部署, 在Cloudformation中做API Gateway的部署时需要加入类型为Deployment资源. 在使用宏的情形下, 我们观察到宏有时会自动创建这个资源, 实现自动部署, 所以这个操作我们认为这个宏可以全部搞定, 没多去深究细节. 直到有一天我们通过API Gateway调用后台的Lambda时发现Lambda根本没被访问到, API Gateway就直接返回了502. 打开API Gateway的详细日志时发现日志的最后一条报权限错误, 即API Gateway没有权限访问这个Lambda. 再仔细一看, API Gateway试图访问的Lambda函数根本不是我们当前stack中定义的函数, 于此, 我们意识到是Deployment没有被触发. 咨询AWS客服后被答复, 这是期待的行为: 因为模板里函数的LogicalID没有变, 所以不会触发Deployment. 但是写过Cloudformation模板的同学都知道, 一个资源的LogicalID是很少会改动的. 这个宏自动创建Deployment资源的依据是LogicalID, 未免太过儿戏.

第三个算是无伤大雅的小问题, 不过仍然算是缺陷. Cloudformation自带的模板校验命令只会校验yaml/json语法, 不会做更深一层的检查, 在开发同学屡次改错模板后, 我们希望在测试流程中添加一个靠谱的模板校验步骤, 我们看上了AWS的这个开源工具cfn-python-lint, 结果用这货来跑我们的模板时就报错了, 即使这个模板在线上部署时运行如常, 原因是AWS对SAM的支持不够完善, GH上有相关讨论.

结论: 玩Serverless的同学们遇到SAM这货请绕路. 尤其是Serverless这个宏可能是大坑.

顺便的, 上面这段在v2上相关讨论在这儿

一点吐槽: 当Cloudformation出现内部错误的时候, AWS将出错信息都隐藏得很好, 所以我们很难知道具体发生了什么事情. 由于出错的可能性比较多, 所以绝大多数时候我们没法真正了解出错原因而解决问题, 只能反复修改模板尝试绕过问题. 这真的很让人遗憾, 我觉得AWS至少可以多给一个错误代码, 这样网上多少会有些讨论, 修改模板绕过问题时也多少会有针对性一点.

清洗地毯

家里的地毯需要清洁了, 受推荐, 去Bunnings租了一台Britex的机器, 买了一瓶洗涤剂. 回家后按照视频里的介绍, 依比例兑水后洗涤. 洗涤剂有一定腐蚀性, 所以接触过洗涤剂瓶子后最好洗一下手. 另外, 虽然机器的吸力已经很大了, 但是仍然无法把所有的水气全吸走, 所以最好趁温度较高的时候坐这件事情. 如果温度和通风不能保证味道散发, 可以考虑用空调抽湿加通风来辅助. 下次, 我们准备挑一个气温较高风较大的前一天去租, 第二天一早起来干活, 争取早上搞定清洁, 下午散气味, 晚上去店里归还机器.