• 2014-05-15

    不部不知道

    Tag:部署

    版权声明:转载时请以超链接形式标明文章原始出处和作者信息及本声明
    http://www.blogbus.com/dreamhead-logs/271589775.html

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

    故事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;

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

    分享到:

    历史上的今天:

    引用地址: