@jhsea3do :

1. command 键很垃圾， 有时要用 ctrl, 有时要用 command， 脑子要转很快

前面有人提到了, 不赘述.

2. 鼠标反向滚动，这个好像可以改设置

是很容易配置, 习惯了也好

3. backspace 删除 和 左箭头移动 巨慢， 这个好像也可以改键速， 但是我改了没多久就被复原了

defaults write -g InitialKeyRepeat -int 10
defaults write -g KeyRepeat -int 1

4. 外置移动盘，只能用 ntfs 兼容， 不能用 xfs

这个是不是要求太高了? 或者你高兴的话把外置的移动盘挂到虚拟机下面去, 爱读什么系统读什么系统?

5. 目录下 一堆 隐藏的 垃圾文件

嗯, 终于有一个比较好的问题了, 我的 ls 是自己改过的, 在~里面屏蔽掉了那一群烦人的目录: https://github.com/xiaket/etc/blob/master/bin/myls


在我看来, 所有你说的问题在我看来都算比较容易解决的问题.

经常收 aws 邮件说你那儿的 lambda runtime 又要升级了

远程工作了一年多了. 觉得上班做的事情比较好玩的话是不是远程工作关系不大, 如果对工作的内容不是特别感兴趣那么很容易摸鱼. 所以, 如果你能大致决定自己做什么, 远程工作挺适合你, 毕竟省时间省事自由度大. 如果你是做一些自己不太想干的事情, 那么还是放弃吧

自己写了一个工具来管理: https://github.com/xiaket/Snape

自己的 snippets: https://github.com/xiaket/etc/blob/master/snape.json

tig +1

用 Python 的人更应该关注脚本可读性, 大多数情况性能什么的不是那么重要. 或者说追求性能用 Python 这个语言就目前来看就是走歪了.

有哪些源码看了可以帮助面试的, 干了这么多年活还真不知道.

是不是开了 zoom 之类的.

@vindurriel 谢谢, 大家对 pyyaml 看来是怨恨都很多. lol

我对 assume-role 的不满仍可以参见我上面的比方, assume-role 给了一台服务器的 shell 权限, 虽然是受限的; 而 eb 给了一个 api, 没有直接暴露 shell, 所以我们觉得放心一点. 不过对于 eventbridge 方案你提到的坏处我有点不太理解. 我为啥要限制接收账号的权限? 我定义好了消息的格式后就把命令丢出去, 这类似一个客户端请求, 受服务端处理的摆布在我理解算是正常的?

@xderam 谢谢, 我们可以自动删账号的, 只不过目前我们觉得相对比较危险, 所以没这样做. 即, 技术上没有问题, 只不过我们没有去这样处理.

好处在于后面如果添加了什么新特性, 可以很方便地加到这个 DSL 里面, 可玩性可扩展性都比较好. 坏处嘛毕竟是自己写的, 有个后续维护的开销.

@xderam 账号不用了就删掉呗, 这个月我已经干掉了 10 个账号了, 删完账号后配置文件里面再删掉就好, 目前来看, 不算太麻烦. 而且我们懒, 一般是该删的账号积了一堆后一次干掉多个, 节省时间和精力. 至于你说的那个状态, 我们是用 cicd 流程来保证配置和实际强一致收敛.

@vindurriel 因为 toml 是有可能进 stdlib 的, 而 PyYAML, 我看过源码, 有点一言难尽...

为什么你认为 eventbridge 跨账号传数据风险比 IAM 更高? 就我的理解, 一个账号是一个容器, 或者可以理解为一台服务器. 如果给了跨账号 assume-role, 类似于给用户提供了远程登录的接口, 而提供 eventbridge 的入口更像是通过 API 提供了服务. eventbridge 跨账号传数据应该是在 aws 的 control plane 层面传, 不走公网, 而且我们做了 resource policy, 不接受来自无关账号的消息.

@whileFalse @akira 感谢两位的兴趣, 请允许我解释一下(看来我文章里面没有说清楚, 这一段回头也得加进去).

我们做这样设定的初衷是为了安全, 首先, 我们觉得 IAM User 不够安全, 所以我们设立了一个登录账号, 专门用来对接我们的 sso 服务. 用户 assume 了一个登录账号里的一个 IAM Role, 然后再 assume 另外一个 role, 去到他 /她真正要使用的账户.

然后, 我们做这些设定是认为总有一天我们的某一个账号会因为误用而导致被人拿到 Administrator 级的权限, 那么为了减少相关的影响, 我们不应该把所有的服务全部放到一个账号里面, 甚至也不应该把所有生产环境下的服务放到一个账号里去. 因为如果一个服务被人拿到权限, 那么所有的服务都会受影响, 因此, 多账号对于我们而言是必要的. 我上面写的这篇文章就是针对多个 AWS 账号的管理的一个方案, 这种方案各个公司多少都有, AWS 甚至还有 Control Tower 服务可以供使用, 但是我们觉得用 Eventbridge 来管理更适合我们.

如果你使用了多个 AWS 账号, 在费用上不会增加特别多, 真正增加的是你的管理成本, 尤其是几年之后你是否还能有效地管理这样的多账号环境, 每个账号里是否有配置漂移的情况, 我们觉得使用一个 DSL 并使用 CICD 来强制收敛是一个更好的选择.

@whileFalse 单独回答一下你的疑问. 我们不是做 SAAS, 在 AWS 层面, 也不是一个用户一个账号. 作为程序员, 张三和李四都可以通过两次 assume role 进入到要用的同一个账户里面去, 第二次 assume role 时使用的 Role 也是一样的. 方便讨论, 我们来一个假设的场景吧. 一个游戏公司里有多个工作室, 每个工作室有三个账号, 一个开发, 一个外部测试, 一个生产. 现在我们新开了一个工作室, 要加新 AWS 账号. 那么我们会要求主程去一个 repo 提一个 PR, 在一个 yml 文件里面添加新账号的定义. Infra 批了 PR 后进入自动化流程. 回头来看你的评论, 我不太确认你说的权限应该在 Code 层面完成是什么意思. 不过我认可你说的 merge 之后这个操作是被 Infra 同学认可了. 但是, 我们目前这个自动化流程是跑在专门的 cicd 账号里的, 不是 master, 所以没有办法直接创建 AWS 账号. 我们通过文章里提到的办法通过发消息来让 cicd 账号控制 master 账号, 创建新 AWS 账号. 至于这个账号里面的 Admin Role, 都是允许从那个特殊的`identity`账号来 assume role, 具体谁有权限是在那个账号管理的. 或者之前一篇文章里的一个图能够帮助你的理解: https://blog.xiaket.org/media/2020/okta-identity-destination.png

谢谢你们的提问, 让我意识到文章里面还有缺失的地方, 解释工作做得不够好, 我晚上改改.

@xupefei 谢谢, 我们自己实现 jsonnet 那层逻辑也不算太大负担, 我现在只是有点后悔没用 toml.

你用云服务前不查一下收费方式的吗? 心真大...

@joesonw 谢谢! 我们的全部基础设施也都在 aws 上. 看过 ConsoleMe, 不太喜欢这种自助式服务, 因为担心配置漂移, 另外我们还没有到那种需要为几百几千个人提供访问权限的程序.

@Cabana 我是先用英文写的, 这两天放假有空全部人肉翻译了一遍再校对润色了一遍.

@wandehul @gtx990 这篇要点在于提供了多账号管理且不需要跨账号 assume role 的方式, 和是否使用 cdk/tf 没什么关系.

另外 @Livid, AWS 区右边的链接似乎可以换成 https://github.com/boto/boto3 和 https://boto3.amazonaws.com/v1/documentation/api/latest/index.html