我去年也清理了一次, 发现过去 常常一个文档里, 收藏了很多个子页面到收藏夹, 也没什么章法, 也不写收藏注释.

具体到 云计算网络 这个子方向, 我想你也是搜索过的, 感觉这个子方向难有比较"现代"的学习向导或 roadmap 之类的.
因为"网络"这个领域发展太久了, 基本找到的都是 不那么"现代"的内容, 不像 DevOps, 很大量的新东西新概念.

所以, 要不要换个思路, 列举一些个具体的云计算网络方向的 小项目/Tasks, 然后再不断对它们进行需求扩展与具体实现, 在这个过程中进行实践与理论俱进式的学习.

我对网络这个子领域认识有限, 举几个可能的基于云计算的网络方面 小项目/Tasks:
云平台上多种 VPN 的原理与实现
云平台上多业务网络的 连接 和 管理
云网络上的 安全管控机制
...
当然, 不会少的就是一些基础实验, 比如: 多种路由策略, 交换策略 等.

大概这几个自己小项目做下来并进行一点程度的扩展的话, 几个月时间就已经过去了.
到时, 你应该能以另一个视角考虑你现在问的问题了.

+1 我估计可不是最后 一天 两天的问题

人的情绪习惯等等, 不是一两年造成的结果,
冰冻三尺 非一日之寒,
不要期望这个情绪问题会 在几年甚至几个月内改掉,
我个人认为对于这个问题, 你更需要注意的是控制 情绪问题造成的"影响", 包括 影响范围和影响大小, 而不是控制情绪"本身".

根本不是什么病, 你所有的顾虑都来自于你并非医疗专业人士, 又能轻易获得一些医疗材料.

上面那三点, 第一点要常做, 第二点等机会, 第三点等时间.
会好的.

事后多思索自我,
还需要等一点机会(比方: 某天因为自己情绪问题, 造成了 一些或大或小的不可挽回的影响),
还需要年龄再大一些.

满足这几个条件, 你这个情绪问题大概率就能好了.

@hongyexiaoqing

个人认为, DevOps 并不一定就要自己研发相关系统, 毕竟大部分公司关注的是公司层面的业务系统, 所以至于 DevOps team 是使用的自研系统还是广泛使用的系统, 从管理层看是不太 care 的.

能自己开发给其它 DevOps 使用的系统自然是高级 DevOps 能力的体现.

但楼主更关注的是如何开始 DevOps 方向, 而不是 DevOps 这个方向的高点在哪里.

@YaakovZiv

这是那个 Team 就没有太按照 DevOps 的方式来运作吧, 他还有很重的之前 Ops 的思路.

否则以代码驱动的配置, 是一定会走 git 的, 再有个一般性的 review, 被同意再进行 修改配置代码的部署.

直接上去改配置绝对是 DevOps 的大忌讳, 因为会导致实际环境和代码部署的环境不一致.

前面说了不同规模的公司, 运维所具体的工作内容和具体的技术栈差别很大.
我尝试理下 DevOps 所需要的: 基础的大方向, 这些应该和公司规模及技术栈没太多关系.

硬的:
1. 一个操作系统方向[Linux/Windows]
2. 一门脚本语言 [Shell/PowerShell]
3. 一个业务开发语言[Java/Python...]
4. 一个配置管理工具[Ansible/Chef/Salt ...]
5. 一个基础设施即代码工具[Terraform, Cloudformation, CDK 等]
6. 一个公有云平台/一个私有云平台/一个容器化平台
7. 一个 CI/CD 平台
8. 一个监控系统的应用
9. 一个日志系统的应用
10. 一个备份管理系统的应用

软的:
11. 一些网络知识
12. 一些安全知识
13. 一些业务连续性知识
14. 一些业务系统运作的架构知识
15. 一些各层面所需的测试工具和知识
16. 现代应用和基础设施 部署和管理的一些思路和思想[基础设施即代码 IaC, 容器化, 应用发布模式 ... ] [对这些的理解会直接影响如何应用具体技术进行工作].

我就先想到这些.其他朋友再补充.
而且, 这其中每一条应该都可以展开为一个知识/技能体系.

上 Dev Container 可能是你的最终方案吧
行业里也都是这么做的.

否则一个操作系统环境 终归容易出问题

看起来确实很棒, 以这个项目, 应该足够教人学会 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 系统内部, 此端口是否被其它应用占用, 导致无法访问.