一句话，部署要趁早

　　这是一个关于部署的话题，一句话，部署要趁早。

　　故事1

　　我们的应用有一个静态导出功能，在自己开发环境中，我们做了无数次导出，没有任何问题。但上到真正的环境中，导出功能一下子不起作用了。

　　经过紧张的调试，我们把目光聚集到一个配置上，它是一个用来处理导出的 URL，这个 URL 的地址是一个内部地址。在真正的环境里，每一台机器都会有内部 IP 和外部 IP，我们用来登陆进行配置的是一个内部 IP，但用浏览器登陆时，我们却用的是外部 IP。所以，当试图访问一个内部 IP 地址时，自然就访问不到了，于是，导出过程就挂掉了。

　　改正很简单，只要把配置改成外部 IP 即可。

　　故事2

　　做 Web 应用，开启 gzip 压缩是不可避免的。我们在自己的 Nginx 服务上测试好的配置文件，部署到了真正的环境中，gzip 死活不起作用了。最初，我以为是自己的配置没有起作用，结果，用内部地址访问以下，一切正常。可为什么用域名访问就访问，难道域名解析还和 gzip 压缩有关？

　　经过半天紧张的调试，我们把焦点定位在了负载均衡器上。请求通过域名在真正环境是要先到达负载均衡器的，然后，由负载均衡器分发到后台的 Nginx 上。这种访问模式实际上成了反向代理，所以，在 Nginx 上，要想 gzip 在这种模式下工作，需要把 gzip 的代理模式打开，比如：

gzip_proxied any

　　故事3

　　如果我们做的是一个老应用的改版，为了搜索引擎，无可避免的一件事是要兼容老应用的一些 URL。初想起来，有一个很简单的做法，在 Nginx 上配置一些 URL rewrite 规则即可。

rewrite /old/url /new/url permanent;

　　在我们测试环境一切正常，但是，上了真正的环境，这个跳转一下子不起作用了。原来，在真正的环境里，给外部访问所用的端口与内部部署的端口是不一样的，而这个跳转是正常的，只不过，它跳到了内部的端口，而这个端口在外部是不可见的，于是，出了问题。

　　给出一个 quick and dirty 的解决方案很容易，给出一个绝对地址用于跳转即可：

rewrite /old/url http://outside/new/url permanent;

　　上面的几个小故事遇到的问题其实是一样的，部署环境和测试环境的差异。即便我们的软件写得完美无缺，环境永远是不可轻视的。除非我们能做到让所有环境完全一致，从头到尾，否则还是那句话，部署要趁早。