@clavichord93 等作者发善心更新... lol

我现在都用 kitty 了, 比 iTerm2 实在是快一圈, 而且配置文件比 iTerm2 管理方便太多了.

@whileFalse 感谢回复, 现在这个项目开发人员也就五六个, 所以还没到用不同 iam role 部署的程度, 不过有比较成熟的部署脚本了, 搭建个人 Stack 比较方便. 不过要做完整的部署, 即使不考虑创建 Cloudfront 层, 仍然快不起来, 因为 Cloudfront 的 cache invalidation 仍需要五分钟或更多.

@laxenade 我们之前的做法是在 cfn 上加一层 python 逻辑, 部署的时候再是一层 Jenkinsfile 的逻辑. 不过由于人手不够, 有些新项目(比如用 SAM 的这个)就没有用这种做法, 而是直接拿 cfn 搞. 外面部署逻辑套一层脚本, Jenkinsfile 里的逻辑也简化了很多. 我周围的所有同事使用的方式都是你所说的第二种, 因为在 cfn 的 best practice 里面提到, 不同生命周期的资源应该尽量放到不同的 stack 里面去. 我能理解你说的多个 yml 拼成一个完整的 stack 这样的做法, 因为这样可以把相似资源的集合放到一个文件里面去, 方便重用. 不过我觉得这样仍可能有坑. 多个 stack 在部署时会有问题, 在于中间某个 stack 部署失败可能影响整个 app 的稳定性, 我们的解决方案是通过脚本来实现整体部署. 每次部署一个版本, 如果中间有一步出错, 全部回滚. 这套逻辑在线上也已经跑了一段时间, 稳定性还可以. 我不太明白你说的服务不支持不是 cfn managed S3 bucket 是什么意思, 方便给个例子了解下吗?

@binux 我完全同意你的观点, DynamoDB 本身不应该出现在这个 stack 里面, 这样我们也不会踩这个坑, 说起来可笑, 虽然我是 infra 工程师, 但是一个资深但没怎么用过 Cloudformation 的前端程序员同学不顾我的多次抗议强烈要求所有的资源放到一个 stack 里面去, 我实在是拿这个人无语.

好多 AWS 同学冒泡了, 感谢各位捧场.

@whileFalse 之前我想的是把这个大的 stack 拆掉, DynamoDB 的生命周期和 lambda 本身就不一样, 这样也能绕过这个问题, 而且架构会更合理. 也看到讨论说 changeset 是更被推荐的部署方式, 不过我更期望这个明显的 bug 能被修掉. 问题 2 我们目前准备去掉这个宏, 因为不知道后面还会不会再踩坑. 问题 3 我们现在的部署不是 blue-green 的, 不过后面有时间应该会做. 至于验证 cfn 模板, 真觉得是目前 cloudformation 自带的验证只检查语法, 实在不够用. 能增强一点儿就增强一点儿, 至少构建出来的模板会更可靠些.

@timle1029 我看到文档里面有提到`cloudformation validate`仅检查语法, 我也认同你提到的, cfn 验证唯一靠谱的办法是在沙盒环境中部署. 但是这样未免测试时间也太长了. 我们的模板里还有 Cloudfront, 一个 distribution 部署下来半个小时是跑不了的. 所以我们这儿说增强的目的是能在 30 秒内尽最大努力测试模板里面是不是有问题, 不求一定能找到坑, 只求能够把开发同学的低价错误给抓出来. 至于 cfn 特性添加太慢的问题, 有兴趣也可以围观 reddit 上这个贴: https://www.reddit.com/r/aws/comments/as21r7/cloudformation_feature_support_lag_is_way_out_of/

@laxenade 我们给 lambda 的 Role 里面也添加了不少的 policy, 还好没遇到坑. 我现在准备全部去掉这个宏, 希望能够好些.

旁敲侧击一下, 不鼓励不反对. 的确有能力有人品, 不过毕竟是拿着东家的工资给前东家做事.

你是不是对漫游有什么误解...

虽然我只看过目录, 但你这些技巧或者说知识真的都只是入门级的, 对于没学过 Linux/Unix 的人可能有点用...

浏览没发现异常

同意, 不如 itunes 卡.

中国人多的海滩不要去

本地 json 文件和其他配置文件一起同步到 github.

@Bestda 有一说一, 你是不是去看一看心理医生比较好.

HN, lobste.rs

你可以做这个实验来看看 cron 是用什么环境变量跑的:

```
* * * * * export > /tmp/cron_env
```