看起来确实很棒, 以这个项目, 应该足够教人学会 Next.js 了

@justdoit123

Jenkins 里的 secret 管理确实不是很好的选择, 但也胜过记录"加密"过的密码在代码里, 再在 pipeline 里"解密". 这种方式实质还是把密码保存在了 git repo 里, 是尽量要避免的.

要是用 GitHub Actions 的 CI/CD, secret 也不会在多个途径使用的话, GitHub 里的 Secret 管理也是可靠的.

但一般生产环境, 一个第三方的 secret 管理工具[SaaS 或 self-host]还是需要的.
HashiCorp 的 Vault 就是很好的选择, 能 SaaS, 也能公司自己 self-host, 国内国外都用得很广泛, 第三方支持也很广泛. 各种 CI/CD 工具基本都支持动态从其中获取 secret.

我估计这些镜像安装中不会自己检测自己的完整性, 这个超出了一个系统安装镜像的考虑范围吧.

但用户应该可以写一个 PowerShell 脚本之类的, 定期运行检查指定位置存储的 iso 文件并和存储的检验码进行比对, 用来简单实现 iso 篡改检测, 这个应该可行吧.

关于: 是应用 CI 自身的模块来编写更原生化的 pipeline, 还是使 CI 基本仅负责调用,组织和粘合 shell/python script 的执行.
我个人倾向于后者, 确实是会更方便在多种 CI 工具之间迁移.

不论如何, 把 sensitive 的配置加密到代码里都不是首选方案吧.

把这些 sensitive 配置 抽取为输入变量 , 并转换为 自动从环境变量取值, pipeline 中由 jenkins/github actions 等从自身的 secret 或第三方 secret manager 获取 secret 并注入到 运行时环境变量 来实现相应配置的赋值, 这样才是一般比较广泛使用的平衡了安全性与复杂度的方案吧.

协议呢 ? 端口也分 TCP/UDP 的, 检查下.
确认以下情况:
1. 确认设置的安全组是否是被应用在此 instance 上的安全组.
2. 确认下协议是否正确.
3. 安全组之外, 还有一层网络控制机制 Network Access Control Lists , 确认下是否开启了 NACL.
4. 外部网络之外, 再确认下 EC2 instance 系统内部, 此端口是否被其它应用占用, 导致无法访问.

有理想, 有追求 !

目前的税务制度 "发展中" 的离谱 ... 本应该是一个年度整体统计, 多退少补的过程, 但由于社会中"黑灰资金"比例太大, 与其多退少补, 不如有一笔扣一笔来的"简单粗暴又直接".

但是当然, 这套税务制度也不是多么的"税务", 本身也不是建立在 "义务"与"权力"之上的, 所以只会让人觉着自己失去了一部分资产, 却又没换来什么"权力", 所以有种相当的"损失"感.

当然，不讨论生活状态， 还有一种可能， 很简单， 就是你“完美主义”者，玩游戏中前期什么都要力图完美，所以玩得很慢，所以时间拖得很久， 所以 到游戏后期就把自己都搞得逐渐失去兴趣了 ...

BG3 110h 刚到第三章 ??

如果你人在体制内，生活也没什么困难，整体处于很清闲舒适的状态， 那你玩 500 小时也能继续玩下去，而且饶有兴致。

如果你不处在类似于上面这种状态，大部分人大概都不处在以上这种状态， 那你玩 50 小时都会觉着玩不下去了。

所以， 没那生活状态就别花太长时间玩游戏，或许一个游戏 20 至 30 小时的游戏时间更合适你

What are you talking about ??

进不去+1

@jhdxr 根据版本支持时间, 技术上来说, 这么认为也是对的 !!

1. 香港普通人生活压力大, 这个大概没什么争议
2. 香港身份可以做完美的跳板
3. 大家应该能看出来, 楼主是没"觉醒"的那类, 大概是根本不想离开国内

@Bingchunmoli 那个“上面” 的决策层大概是更缺乏 信息安全意识

@jhdxr 关键我想表达的是 国内开发人员整体的信息安全意识比较弱，守在一个 centos7 好多年