透過 Nginx proxy_pass 架構，進行 Service migration

有一個舊網站已活了數年，改造的方向不外乎提升 SEO、移除不需要的檔案、增加系統安全、架構拆分，或是基本的 Web Framework 的抽換使用等等。對於一個 IoT 產業來說，包袱多多，像是 device 不見得會更新到新版，更別說會跟隨 HTTP 301/302 去取得新資源，甚至新網站的開發還沒辦法一步到位全部切換，只好透過 Nginx proxy_pass 架構去處理相容並扛流量了。

在此使用 upstream 管理舊機器們，並且添加新的 log format 多紀錄 $upstream_addr 資訊以便後續維護：

log_format add_proxy_pass '$remote_addr - $remote_user [$time_local] [=$upstream_addr=] "$request" ' '$status $body_bytes_sent "$http_referer" ' '"$http_user_agent" "$http_x_forwarded_for"';

resolver 8.8.8.8;
upstream oldserver {
hostname1;
hostname2;
hostname3;
}

後續，都是在 nginx server {} 定義範圍下。

更改 log 記錄格式：

access_log  /var/log/nginx/access.log add_proxy_pass;

預期 http client 能處理 HTTP 301/302 的服務位置，給予更佳的 SEO URL：

location ~ old_page\.php$ {
return 301 $scheme://$host/new/page/;
}

對於不能用 HTTP 301/302 的，則改用 proxy_pass 機制：

location ~ ^/old/resource {
proxy_pass http://oldserver$uri;
}

對於，有些文件很清楚要更改內文關鍵字的，可以善用 ngx_http_sub_module：

location /old/resource/file\.json {
proxy_pass http://oldserver$uri;
sub_filter_types *;
sub_filter_once off;
sub_filter '//old.hostname/' '//cdn.hostname/';
}

也可以順順換成 CDN 架構囉。