我想说无论在哪里，公司的价值观里，业务才是王道，技术都是用来辅助业务的。
所以现在的技术趋势上，会让越来越多的人碰不到技术的核心，你只需要专心干业务就行。
而且做了更多的容错，让越来越多的人就能 CRUD 干的活。

所以技术上自我驱动才是最重要的。

无论是外包还是小公司，团队里愿意接受与尝试新的事物，而且公司还需要有能力去接受新的事物，这才是主要的。

说实话，前年 9 月-10 月 2 个月做的项目用的 swarm 。
如果去年还是我们团队继续做，我会把替换成 k8s 。
但就现在接手的团队还是用我之前的东西，都没有动，有问题还是过来找。

openvpn 服务端需要虚拟出一个网络，需要 iptables 指定 source 为改网络的转发到物理网卡上。
iptables -t nat -A POSTROUTING -s x.x.x.x/x -o eth0 -j MASQURADE

@hantsy k8s 健康检查分为两种：就绪检查与存活检查。
1. 就绪的健康检查是 pod （程序）启动时，检查服务是否可以正常接受 HTTP 请求，如果检查正常之后才会将 HTTP 流量转发的这个 pod （程序），失败则重启 pod （程序）；
2. 存活的健康检查是 pod （程序）运行时，如果检查失败，则将 pod （服务） kill 掉，重新启动一个 pod （服务）。

现在 springboot 的问题不就是第一次请求的时候慢，但这个第一次请求是在就绪的健康检查的时候（此时程序没有接受业务上的 http 请求）就给预热完毕了，那么其他的任何接口请求时间正常了。

k8s 两种检查的好处在于：
1. 就绪的检查可以实现一些稍稍比较重的任务，比如数据库连接状态或者数据是否成功初始化的检查，因为只是在启动时请求，不会因为检查而影响效率；
2. 存活检查就可以很简单，一般单纯返回程序运行状态或加上数据库连接状态就可以了。

实际在使用 k8s 之前，nginx 上一般都会在 upstream 配置一个统一的健康检查，只不过这个没有区分两种检查，同样也是进行了预热。

@sampeng 健康检查，检查一下各种数据库，然后同时预热。虽然有点歪门邪道，但可以考虑用 k8s 就绪健康检查做完整的健康检查。

我想健康检查是不是能解决这个问题？

刚想推荐一个成品 nas，结果发现没有随着硬盘降价儿降价，感觉不合适了。

剩余 10 年以下，怎么选都无所谓；剩余 10 年以上，5 以下固定就好，个人感觉不需要承受风险；剩余 10 年以上，5 以上这个就看你赌 lpr 是不是想银行所说的，需要承担风险。

minio?

@ztechstack 而且在实际架构中，甚至可以将认证的步骤提前，放在网关等外部层去处理。

核心概念#47 说的很明白

用户 /认证信息、组织、角色在 REST 里都是资源。
但在实际情况中，而且这些在业务系统中并不完全适合放在 url 里进行传输，因此放在 header(cookie)里。

自己电脑 jenv 切换工具, https://www.jenv.be/
集成环境 docker.

@ztechstack 回复错了，这个是直接安装 nginx 的依赖包，包名。

zlib1g openssl libpcre3

1. 单节点纯 docker 即可，3 节点以上可以使用 swarm 管理，一般上没有 20 台机器不推荐用 k8s 。
2. 单节点可以不折腾镜像仓库，如果服务器本地构建镜像可以不折腾，如果远程构建搭一个也很简单。
3. 公用一个数据库服务器(容器)，我现在都是使用 docker 管理(包括一些生产环境)，现在好一点的镜像都是使用外部数据库服务的。
4. 开源项目 portainer 了解一下，可视化管理。

点过啊，去年还是前年的 jetbrains 的优惠就是从那里点的。
只要不是弹窗和左右上下都是，我觉得可以接受。

发现 · 打不出来。。。。。。。

docker 的话，nginx 容器内部访问 127.0.0.1 是访问 nginx 容器自身；
如果需要访问 python 容器的话：
1. 在同一 docker 的 network 里，可以使用[python 容器名称]:[python 服务端口]。
2. 或者使用[宿主机 IP]:[python 容器映射宿主机端口]。