一句話，部署要趁早
這是一個關于部署的話題，一句話，部署要趁早。
故事1
我們的應用有一個靜態導出功能，在自己開發環境中，我們做了無數次導出，沒有任何問題。但上到真正的環境中，導出功能一下子不起作用了。
經過緊張的調試，我們把目光聚集到一個配置上，它是一個用來處理導出的 URL，這個 URL 的地址是一個內部地址。在真正的環境里，每一臺機器都會有內部 IP 和外部 IP，我們用來登陸進行配置的是一個內部 IP，但用瀏覽器登陸時，我們卻用的是外部 IP。所以，當試圖訪問一個內部 IP 地址時，自然就訪問不到了，于是，導出過程就掛掉了。
改正很簡單，只要把配置改成外部 IP 即可。
故事2
做 Web 應用，開啟 gzip 壓縮是不可避免的。我們在自己的 Nginx 服務上測試好的配置文件，部署到了真正的環境中，gzip 死活不起作用了。最初，我以為是自己的配置沒有起作用，結果，用內部地址訪問以下，一切正常。可為什么用域名訪問就訪問，難道域名解析還和 gzip 壓縮有關？
經過半天緊張的調試，我們把焦點定位在了負載均衡器上。請求通過域名在真正環境是要先到達負載均衡器的，然后，由負載均衡器分發到后臺的 Nginx 上。這種訪問模式實際上成了反向代理，所以，在 Nginx 上，要想 gzip 在這種模式下工作，需要把 gzip 的代理模式打開，比如：
gzip_proxied any
</blockquote>故事3
如果我們做的是一個老應用的改版，為了搜索引擎，無可避免的一件事是要兼容老應用的一些 URL。初想起來，有一個很簡單的做法，在 Nginx 上配置一些 URL rewrite 規則即可。
rewrite /old/url /new/url permanent;
</blockquote>在我們測試環境一切正常，但是，上了真正的環境，這個跳轉一下子不起作用了。原來，在真正的環境里，給外部訪問所用的端口與內部部署的端口是不一樣的，而這個跳轉是正常的，只不過，它跳到了內部的端口，而這個端口在外部是不可見的，于是，出了問題。
給出一個 quick and dirty 的解決方案很容易，給出一個絕對地址用于跳轉即可：
rewrite /old/url http://outside/new/url permanent;
</blockquote>上面的幾個小故事遇到的問題其實是一樣的，部署環境和測試環境的差異。即便我們的軟件寫得完美無缺，環境永遠是不可輕視的。除非我們能做到讓所有環境完全一致，從頭到尾，否則還是那句話，部署要趁早。
<span id="shareA4" class="fl"> </span>本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！