别这么认真, 套路之外, 京东自营商品的整体品质和售后还是各平台里最好的.

Win7 Win2008 等 安装近两年的 VMTools 需要安装个系统补丁, 名称如下, 自己去下载吧
windows6.1-kb4474419-v3-x64_b5614c6cea5cb4e198717789633dca16308ef79c

这个坛子里 , DevOps 都少之又少, SRE 就更别说了 ...

大概是非常好的 WireGuard 一键部署方案了吧
https://github.com/hwdsl2/wireguard-install

前面几位基本已经列出了主要的安全的连接方式,
1. VPN 方案:
目前看 WireGuard 应该是 可靠性, 易用性, 性能, 几方面平衡下来很好的选择.
使用 VPN 方案的话, 在主路由器的防火墙上只映射 WireGuard 的端口, 为了安全性不要也不需要映射全端口.
2. 使用 Tunnel 类的方案:
ZeroTier 是很好的一个方案, 可管理性很好, 构建了一个安全的基于局域网和互联网之上的 Private Network. 个人用了几年了.
Cloudflare tunnel 也常看到, 大概也是此类型的方案吧.
3. 自建 Bation sever 方案:
仅仅只开放 ssh 端口, 通过 ssh public/private key 机制进行安全链接, 并通过 ssh tunnel 进行数据转发. 安全实施难度较大.


至于常见的 公网 IP + DDNS 方案 呢?
那纯属是找死 .......

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

具体到 云计算网络 这个子方向, 我想你也是搜索过的, 感觉这个子方向难有比较"现代"的学习向导或 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.