落格博客最早是運行在虛擬主機上的，只能通過面板操作，也沒什麼權限，使用起來非常彆扭。再加上反正弄了服務器跑翻牆代理服務，那乾脆就將博客搬遷到了 VPS 上。因此也就開始了我的 vps 折騰之旅。一轉眼十年過去了，我後來也固定在 Vultr 的 VPS 上跑了 4 年。當然，這中間很多事情發生了，我做了 cnswift， 做了落格輸入法，還有落格輸入法的 macOS 版本……於是這個 20美元一個月的 vps 上邊，除了要跑三個 wordpress 外，也開始陸續跑起了三個關於輸入法的授權 API 服務。當然還有一個訪問統計系統，一個 phpmyadmin 方便管理數據庫——顯然，還有一個為上述所有服務提供數據訪問的 MySql 服務，對了，還有落格輸入法的使用說明書這個靜態網站。
在用命令維護服務器這麼多年後，我早就對面板動了心……可以選擇的面板很多，但很可惜，他們都不能和現有的配置相兼容——當然這也是可以理解的，畢竟現有的配置每個人都不同，位置、版本也千奇百怪就是了。於是我就一直也沒機會體驗。
後來知道了 AWS 進軍虛擬主機市場，便宜的 Lightsail 理念很不錯……經過測試，國內訪問速度也還行，於是我決定把整個落格工作室的東西全都上雲！ （畢竟現在來說“雲計算”也已經不再是新名詞了，而我還在用虛擬私人服務器這種“傳統”的東西……其實很容易單點故障對吧）
我做了一個整理：
- 我可以用一個 光帆 跑我的博客、工作室以及 Swift 編程語言翻譯，這樣開銷是 $5/莫（最低有3.5的，我沒選，下文詳述）；
- 輸入法說明書的靜態網站，可以丟到 S3 容器，開銷大概是 $0.1/mo 可以忽略不計；
- 那些輸入法的授權服務剛好是 Python 寫的，可以無縫遷移到 Lambda 上，由於用量很小，開銷同上，忽略不計；
- 而數據庫，就可以分開，wordpress 的就在 Lightsail 上，不用額外花錢。因為我本身也不會存很大的數據，自帶 40G 空間足夠了。輸入法的訂單等數據存放在 動態數據庫，方便 拉姆達 使用，由於數據量也很小，讀寫也不多，根本用不完免費額度。
這樣，一旦完成遷移，我每月的固定開銷就變成了 5 美元，但由於是雲計算，所以穩定性和安全性都得到了提升，且後續開發維護都變得容易了很多。
難點
其實對於 aws 這樣的雲計算平台來說，技術沒什麼難度的。難的是去理解一些必要的概念。比如權限：由於 AWS 服務很多，不同服務之間的訪問等都需要配置權限，他們有自己的一套配置模式 role。另外為了方便為外部服務授權，還有可配置的賬號系統 AIM。
還有就是由於服務分的很細，有一些我們常用的功能可能有現成的工具批量自動化部署，而這個自動化部署的功能，又成了另一個服務，所以在你選擇功能時，注意去看，不然很有可能你手動配置好了才發現原來有現成的方案。
靜態網站
我第一個遷移的是靜態網站，這個沒什麼好說的，GitHub 用 Actions 編譯電子書，然後 push 到一個預先開啟的 bucket 就可以了，bucket 我選在了香港區，國內直連速度也不錯。然後我用 AWS CloudFront 自定義域名來為這個 bucket 做 cdn，這樣就可以開啟 https 了。
有個問題就是這樣一來bucket 放在香港的優勢就沒有了。不過令人驚訝的是，cloudfront 的cdn在國內速度也很快，所以目前就這樣好了。我把這個原因歸結為 AWS 的 CloudFront 用的人不多，所以國內並沒有被牆。（參考 Cloudflare，幾乎大半的 IP 被屏蔽）
值得一提的是，其實可以不用 cdn，直接用 nginx 反向代理一下也是可以的，這樣就也能提供 https 了。當然由於我這最先遷移的這個，當時沒有想到這個方案。
落格博客
靜態網站很簡單，但 WordPress 就比較麻煩了。我首先想的是用本身就支持多站點的 WordPress，而且 Lightsail 是有這個 Application 可以直接部署的。但遺憾的是，多站點模式的配置比我預想的要復雜，幾乎所有常用的插件都會針對多站點模式單獨收費（往往單站點模式下是免費的）。於是我考慮另一種選項，我開三個小的 3.5美元的 Lightsail 如何？這樣每月開銷是 10.5 美元，也是可以接受的。
但直接運行 WordPress 也有它自己的問題，預置的這個配置也比我預想的要奇怪，配置文件很難找，都不是在標準的目錄下。比如落格博客需要修改 nginx 配置來實現偽靜態，需要使用 certbot 來實現自動 https 證書續簽……但遺憾的是，這兩樣你都無法達成。
思前想後，既然心水面板很久了，不如就試試？
最後的實現是用 $5/mo 的 Plesk 面板 Application。方便快捷！
由於 Plesk 本身性能需求，3.5 價位的 Lightsail 無法支持 Plesk。
我砍掉了訪問統計系統，改用 WordPress 插件 WP統計， 而 phpmyadmin plesk 也自帶了。另外這個選項還內置了一個 Plesk 的基礎授權，最多支持 3 個域名，我只有兩個，如果子域也算上，也就三個，足夠了。就這樣在 plesk 上創建網站，添加數據庫，然後 WordPress 目錄打包遷移。匹配數據庫賬號密碼後，就遷移成功了。由於我的博客啟用了偽靜態，所以還需要單獨配置一下偽靜態，最後再到“固定鏈接”那裡點一下保存配置，刷新 rewrite 規則即可。
cnswift.org
這個沒有偽靜態，多以比落格博客要簡單一些，就不再多說了。
落格工作室
落格工作室實際上是 logcg.com 的一個子域名，好在 plesk 支持創建子站點，子站點默認會使用和主站點相同的數據庫賬戶，但數據目錄是分開的。我們可以在 plesk 上手動創建一個數據庫關聯給子站點，這樣就各自獨立了。但網站目錄還是會在同一個父目錄下就是了。
緩存
如果你使用了比如 WP超高速緩存 這類插件，那麼遷移之前最好先刪除全部緩存然後把他們關掉。首先緩存文件很多的話會佔用空間，壓縮、解壓縮都需要時間，上傳下載也是一樣。另外由於網站目錄的絕對路徑有了變化，會導致默認的緩存文件找不到，然後導致網站崩潰……這下就很難辦了，因為你根本不知道問題出在哪裡。
CDN
我嘗試用 CloudFront 為 WordPress 做整站 cname cdn，但很遺憾，這樣會導致 WordPress 自己困惑，從而發生重定向環路。要么是 https 訪問 cdn， cdn http 回源被再次重定向到 https 循環，要么就是 域名不同導致的環路。總之，最終我還是用傳統辦法，只替換靜態文件的域名來實現靜態文件 cdn了。
有一個問題是當 cdn 緩存字體時，總是會有報錯無法命中，需要在 nginx 中添加額外規則：
|
1 2 3 |
location ~ .(ttf|ttc|otf|eot|woff|woff2|font.css)$ { add_header Access-Control-Allow-Origin "*"; } |
證書授權服務
這個比較麻煩，好在都是 Python，我首先是想用 lambda 實現，但後來發現原來有個組合服務叫 雲形成，配合 AWS 自己的工具 山姆，就可以用描述文件一次性自動化部署 lambda+api gateway+lambda 了。
這裡我遇到一個難題是怎麼才能讓現有服務無縫銜接過去，不同於 web 端，用戶只要刷新了就是新版，落格輸入法這種軟件是需要用戶去更新的，戰線會拖得很長……感謝早年時候與牆奮鬥，藉著當年反代 Google 的經驗，我用現有域名反代了我的 拉姆達 API,這樣這些服務的接口遷移對客戶端來說就是完全無縫的了！
有一點，在反代時，注意這一條設定：
|
1 |
proxy_set_header Host $proxy_host; |
不能是 $host 。
總結
其實使用 光帆 便宜的原因是他把 CPU 拆分為“算力”來賣了，平時我們租一個 VPS， CPU 是按照速度和核心算錢的，但並不是每一個服務總能跑滿 CPU 的所有核心的，相反，大多數情況下，CPU 可能都處在20%左右的工作狀態。這樣一來絕大部分計算量就被浪費了。而 Lightsail 則引入了固定算力和突發算力，平時服務器穩定運行，會在固定分配的算力區間，也就是 CPU 佔用量的 10%。如果遇到突發比如插件升級，瀏覽量突然增多，那 CPU 的佔用量也可以飆升到 100% 甚至 140%，此時會消耗你的突發點數。這個點數會在平時不用突發算力時自動增長。（當然，如果點數用完了，那CPU的性能會給你固定到 10%，此時服務器就運行緩慢了。顯然，這也說明這個配置對你當前的狀態有點低了。）
另外 Lightsail 由於已經過於精簡（都已經在按 CPU 算力賣錢了），它不支持動態擴容，不過好在支持每日自動快照，所以 AWS 官方也推薦需要擴容時直接創建快照，然後購買高級版本，再恢復快照。反正靜態 IP 地址是單獨的另一個服務，你只需要將舊的服務器上的 IP 地址附加給新的服務器，就完成了擴容。
不要忘了同步你的防火牆配置，而且 IPv6 地址會變，記得更新域名解析記錄。
另，由於有了快照功能，也就不需要再用複雜的 WordPress 備份插件來每周備份整站數據到 投遞箱 啦～
本文由 落格博客 原創撰寫：落格博客 » 落格博客 AWS 上雲踩坑記
轉載請保留出處和原文鏈接：https://www.logcg.com/archives/3803.html
現在好了，騰訊雲、阿里雲取代了過去大部分的IDC