有 CI 楼主就不会问这个问题了。

git hook 还得建仓库，多麻烦，推荐参考 hexo 的方式，本地 build 完成后通过 ssh 或 api 的方法把 build 结果传输到 服务器目录或静态托管上。

觉得麻烦，写个 deploy shell 脚本做这个也行。

文本的存在是为了可控、可读、可追溯；二进制文件的存在是为了方便部署，避免在生产服务器“构建”。只要流程允许，在服务器上构建镜像也可以，从仓库拉二进制镜像也行。

作为一个野生运维最近都找不到工作，伸手部分的问题没心情回答，慢慢啃相关文档去吧。

不说业务逻辑不是瞎扯么。

全部数据放内存跑，最快到什么速度取决于具体业务逻辑，反正也没法更快了。

楼主精神可嘉，不过我还是推荐 portainer。

1. 没有 docker.sock 访问权限
2. docker daemon 没有启动

又来黑我 PHP

╮(￣▽￣")╭

别急，至少要等大牛挑完，把其他 offer 拒掉，才轮得到备胎。

因为靠谱的员工和靠谱的公司一样少，所以招人难招，求职难求。

面试官情商略低。

出不出问题要看具体情况。

修改内部端口确保内外端口一致我觉得是最优解，也容易排查问题。

Web 应用，如果有可以配置 URL root 的选项配置最好，没有可以使用反向代理解决。

如果是一定会把检测到的容器内 IP 返回给外部客户端使用，那用 host 网络运行容器是最直接的做法。当然，也可以看看其他网络类型能不能解决问题。

补充一下，bridge 网络下，内外端口不一致时可能会产生一些问题。比如服务检测到的配置或环境，是容器内网 IP 和端口，如果一些自动生成的 URI 会使用这些值，就会产生问题。

另外就算映射了端口，外部客户端也是无法通过容器内网 IP 访问容器。

不过也应该不是绝对，如果路由可达应该可以，但这时应该也不算是 bridge 网络了。

bridge 网络下可以把主机看成路由器，外部是通过 NAT 访问的，与路由器上的端口映射类似，同一个 Network 下的容器是同一台交换机下不同设备，每个容器可用端口范围都是独立的。

容器间互访，可以通过容器内网 IP 和 内网端口——即容器自身端口。外部想访问容器，就必须把容器端口 EXPOSE ——映射出来，暴露的端口属于主机端口，是不能冲突的。

其实 SSD 不适合这种连续长时间写入，回收时写入会受影响，也许最新的傲腾才可以解决你的问题。

如果场景是日志收集，建议找专门的针对性接近方案处理吧。

客户端支持的话可以考虑用 307 跳转
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status/307

野生运维一名，下面是个人理解：

SRE 其实是开发，之不过这个开发面对的业务需求是“如何保障公司业务的可靠性”。基于这个目标，DevOps 只是为了对整个环节可控的必要步骤而已，只有规模效应下 SRE 或者说 DevOps 的价值才能更体现价值——或者说成本也是 SRE 必须考虑的指标之一。

最简单的例子，假设有一种新图片格式，可以让当前系统中所有图片质量保持不变（或者损失很小）的前提下体积减少 50%，如果带来的收益无法覆盖（可能的）研发费用、终端变更成本、业务升级风险成本，就不会有人去做。

最终的结果就是 SRE 是个没有初级岗位的岗位，只有在大公司才有 SRE 的基础，或者说小公司实践造就的 SRE 很多小公司也不会要——毕竟现在创业公司招开发都是百万并发打底。

总之想成为 SRE，先学好开发技能吧。

全天站着工作，以免猝死。

REST 主要的问题一个是数据有冗余，一个是请求多级关系数据查询是串行——必须先获取上级资源，再来获取子资源，版本基本上就三个方式：

URI - https://example.com/api/v2/foo
Custom Header - api-version: 2
Accept Header - Accept: application/vnd.app.v2+json

URI 直观，简单易懂，但是违背了同一个资源 URI 不变这个原则。放 Header 里面不直观，对队友有要求，（个人理解）自定义头和 Accept 头的区别是 Accept 更符合 Http 协议的设计。

REST 的优势在于 URI 明确，资源权限控制清晰。GraphQL 对外是灵活而强大，不过解决权限、性能问题对于后端而言复杂度是高于 REST 的——毕竟 REST 成熟的框架更多。