用lls建设一个网站,网页设计职位,招远网站建设哪家专业,wordpress滑动切换因为老板想搞 K8S#xff0c;但是我连 Docker 都不懂#xff0c;就觉得还是要学一点点 Docker 的#xff0c;之前还是看了一点点的#xff0c;甚至折腾过一个开发环境的方案#xff0c;但是#xff0c;很长时间不弄了以后#xff0c;就全都还回去了。这次我又想自己搭建…因为老板想搞 K8S但是我连 Docker 都不懂就觉得还是要学一点点 Docker 的之前还是看了一点点的甚至折腾过一个开发环境的方案但是很长时间不弄了以后就全都还回去了。这次我又想自己搭建一个基于 Docker 的开发环境以前只是把 Docker 当成一个易于分发的开发环境来思考所以我记得以前费了很大的力气做出了一个单一的 image把 PHP nginx Redis Memcahed 全部压到一个 image 里面了然后用 Volume 映射代码MySQL 连接本地网络公用的实例形成一个开箱即用的开发环境。这次因为稍微看了点编排的概念开始纠结这些东西真的应该压到一个 image 里面么为啥不是多个 docker image然后怎么想办法编排一下子不是传说有个最优实践是一个 container 里面只放一个服务嘛第一个纠结的就是 nginx 和 PHP 到底应该放在一个 image 里面还是不同的 image 里面呢网上搜了一下发现还是有不少文章讲 nginx 和 PHP 分开放无法访问的问题。看来显然有人做过尝试了而且遇到了问题。就看看他们遇到了什么问题。经过一番分析我感觉我想明白了这个事情到底应该放在一起还是分开放。分开或者合并的原理其实经常配置 nginx 和 PHP 的话就会知道这俩在原理上分开和合并都是完全可能的。而且从提供的接口层面我们看不出来到底鼓励怎么做。常见的配置方法是使用 fastcgi 的方式来配合 nginx 和 PHP我这两年的经验用 debian 的 apt-get 安装的默认配置看nginx 和 PHP 的连接方式是用的 UNIX sock 文件这种情况下显然是必须在一台机器上了。但是显然我们知道 fastcgi 是支持 TCP 协议的就是大家很熟悉的 9000 端口流行的配置文件都是 tcp://127.0.0.1:9000 这样的编写方式。这个本地 IP 地址看起来也是部署在一台机器的。不过呢既然支持 TCP就必然可以分布在不同的机器上面原理上完全成立的。网上流行的问题是什么那么那些把 nginx 和 PHP 放到不同 image 的同学遇到了什么问题呢其实是路径问题。其实我想因为部署在一起的方式太过于流行了(可能的根本原因是互联网的绝大部分网站的规模很小都在单台服务器上)以至于很多人没有注意过路径这个问题。nginx 是一个服务器应用程序每次要伺服的时候都要从一个文件根目录出发寻找需要伺服的文件路径。而 PHP 的 FPM 进程也是一个服务器应用程序它也有一个问题就是需要从一个文件根目录出发去寻找需要解释的文件路径。因为最为流行的部署方式是放在一起的往往也包含了静态文件和动态文件部署在一起的问题(前后端不分离是更为流行的做法)所以用到的文件根目录都是在一起的所以很显然如果分开部署 nginx 和 PHP 的话一定会遇到文件路径寻址的问题。nginx 配置文件里会用 root 变量指定一个 server 寻址的根目录合并部署的时候和 PHP 的根目录是一样的用 document_root 变量(就是 root 的别名)传递给 fastcgi但是分开部署的时候一个 server 的 root 变量指的 nginx 所在的计算机的路径但是 fastcgi 需要使用的 SCRIPT_FILENAME 参量里面的路径要用的是 PHP 所在的计算机的路径。既然是两台计算机路径可以吻合也可以不吻合所以分开部署的话还能正确使用是有一定概率的。你怎么知道 nginx 的 image 和 PHP 的 image 正好基于一个发型版在 Docker 的世界下两个 image 来自天南海北的两个人制作的可能性很高。怎么解决路径问题要说怎么解决这个问题其实说到这里知道了原理就非常好解决梳理好两个服务器程序应该使用的路径参数就好了。document_root 这个变量一般会继承 server 段落的 root 变量的配置或者 http 段落的 root 的配置。如果这个 root 和 PHP 所在的机器驴唇不对马嘴那么可以猜测一定跑不起来。解决方法是把 PHP 所在机器的 root 在 location 段落里重新设定。或者设置 SCRIPT_FILENAME 这个 fastcgi_param 的时候用绝对路径直接写不要用 $document_root$script_name 这种变量的写法。然而像我这么纠结的人还是很不满意的因为这种写法让我觉得恶心。为什么呢因为耦合了。nginx 在一台机器上以服务的面貌提供自己的服务而 PHP 在另一台机器上也以服务的面貌提供自己的服务。但是如果 nginx 的配置必须知道 PHP 那台机器的文件路径我想这就是它知道了它理该不知道的事实这就是耦合这就是丑陋。其实nginx 作为一个服务从客户端那里得到了 script_name当然它自己解释不了也不拥有这个文件所以用 fastcgi 把 script_name 传递给 PHP 所在的服务就行了。这是最最必要的操作了。能不能不用搞清楚 PHP 所在的计算机的路径呢当然可以只要使用相对路径就行了。那就需要 PHP 的 fastcgi 启动的时候知道自己的根目录在什么地方然后传过来相对路径都可以自己找到正确的位置从而解决了一个耦合。PHP 的 FPM 当然可以这么配置只是因为一起部署的缺省配置太过流行咱们从没注意过这个可能性而已。到底应该放在一个 image 里还是分开答案是视情况而定。(KAO跟没说一样)其实PHP 的 FPM 是支持一个叫 pool 的特性的我们可以在一个 pool 里面通过 chroot 和 chdir 之类的特性来把访问限制在一个特定的路径里就是代码所在的根目录。但是那样的话如果你一台机器上有多个网站的源代码你就必须把根路径指向多个网站的共同根目录不然的话PHP 就只能伺服其中一个。我们知道世界上绝大多数网站的规模很小所以一台 Linux 可以同时支持很多网站的使用所以绝大多数缺省配置FPM 只配置了一个 pool。这种情况下nginx 传递相对路径的时候必须加一个网站名的前缀。懂道理的话会很简单啦怎么都不会搞混。但是显然增加了这套架构的学习成本不是每个人都能很快搞那么明白的。所以详细回答一下“到底应该放一个 image 还是分开”这个问题。如果你只是在本地做一个给自己用的开发环境我强烈建议放在一个 image 里面。一个程序员往往会开发 N 多个网站的代码放在一个里面最省资源。配置也最为熟悉和简单网上随手一搜搜出来的配置很大概率可以部署成功。如果在线上环境部署一个流量弹性范围很广或者增长可能性很高的服务的时候分开部署的优势比较大。因为nginx 的性能是非常好的远远好于 PHP。分开部署后PHP 的 FPM 进程不够用了以后可以不断扩容增加 container 数量就行了。但是这种方案的话学习成本较高需要程序员对这几个服务的配置有比较深的理解就算自动扩容执行动作感觉也不是单纯增加一个 container 就行的毕竟一个 container 就有一个入口 IP还要把扩容出来的入口 IP 告诉 nginx 所在的 container。结论其实吧最流行的方案恰恰是最正确的方案。比如你可以直接下载到 LNMP 完备的 image这种东西需求量最大所以最流行。因为都是单个程序员用来解决自己开发环境的。就算拿去用在生产问题也不大小流量的服务和网站才是这个世界的主流。不过想明白为什么是这个样子就要花点心思。相关阅读
