只需6步，教你把服務遷移到云端
英文原文：How Ghost Migrated From Dedicated Servers to DigitalOcean
Ghost 是一個開源博客平臺，而 Ghost (Pro)是它的托管平臺。這篇文章的作者是 Ghost 的高級 DevOps 工程師 Sebastian Gierlinger。他用簡單的 6 個步驟，總結了 Ghost (Pro)的基礎設施從專用服務器遷移到 DigitalOcean Droplets 的過程。
以一年多運營 Ghost (Pro)的經驗來看，我們認為自己的下一代基礎設施需要滿足如下需求：
- 能夠在幾分鐘內對服務器擴容
- 擁有能服務數千個博客的大內存
- 提供強大的客戶支持
- 在不做重大重構的前提下遷移軟件
任何一個項目的遷移，都以一定程度的不確定性開始。一開始就預料到所有的遷移步驟是不可能的，更不要說預料到任何一個即將遇到的問題。但鑒于這是一篇回顧文章，出于方便理解的目的，遷移過程包括以下幾個大步驟：
- 為現有的服務器基礎設施建立目錄
- 確保公網安全
- 確保專用網絡安全
- 備份數據庫
- 更新 DNS（切換到目標服務器）
- 下線舊的運行環境
遷移后的 Ghost (Pro)系統架構是這樣的：
下面就讓我們來詳細看看遷移過程的 6 個步驟。
Step 1：創建目錄
第一步是用配置管理工具創建一個目錄，用來顯示現存的服務器基礎設施上運行著什么。
我們并沒有一個完整的目錄，包含所有安裝的軟件、防火墻設置和其他服務器配置。為了解決這個問題，我們引入了一個配置管理系統工具箱。配置管理的一大好處就是，一旦系統建立起來，它既可以作為記錄文檔，又可以用作一個部署工具。
我們考慮過幾個比較流行的配置管理工具，包括 Puppet、Chef、Ansible 和 SaltStack。我們需要一個既能完成工作又不容易因為復雜性而過載的工具。最終就選擇了 SaltStack。
下面是幾個選擇 SaltStack 的原因：
- 它很輕量，易于安裝和維護；
- 它采用 master/minion 的架構，可以將更改從 master“推送”到 minion 端，避免了由于頻繁請求可能造成的 DDoS 攻擊；
- 它擁有一個專門的主服務器，可以防止管理員和開發者直接在未受保護的生產環境部署更改；
- Master 和 Minion 的通信采用 ZeroMQ 而不是 SSH。在處理多個加密并發連接時，ZeroMQ 使用更少的 CPU 資源，效率更高。
另一個附加的好處是 Salt Cloud，它包含在 SaltStack 里，并且和 DigitalOcean 的 API 無縫兼容，資源可以快速彈性伸縮，我們可以用命令行管理系統資源。
雖然這個新的 Ghost (Pro)架構初始設置和配置頗花費了一些時間——大概 3 周，但 SaltStack 表現除了它強大的功能。第二步迭代配置用了大概一周，第三步部署托管平臺只用了兩天。
創建一個目錄，并把它遷移到配置管理工具，這是一個迭代的過程，會涵蓋幾乎整個系統遷移的過程。除了完成遷移，創建目錄還暴露了我們結構中需要改進的部分。讀者如果想要嘗試 SaltStack 更多功能，請參考使用手冊：1、2、3.
Step 2：確保公網安全
第二步是為了確保平臺內部服務器的公網防火墻安全。
以前，只有我們面向公眾的服務器可以通過外網訪問；其他服務，比如 APP 和數據庫服務，只能通過專用網絡訪問。遷移到 DigitalOcean 的云端后，所有服務器都有一個公共 IP 地址，我們必須解決這項新的安全隱患。
我們給內部服務器的公網設置了一個 iptables 規則，能夠攔截除了 SSH 加密通信的其他所有連接。我們自己的服務器用的是 Ubuntu，所以用 UFW 作為 iptables 的管理界面。
和其他基礎設施一樣，防火墻配置是通過 SaltStack 完成的，方便于我們統一管理。
Step 3：確保專用網絡安全
第三步是用 V*N 確保所有服務器專用網絡的安全。
DigitalOcean 的專用網絡允許同一數據中心的 Droplets 彼此通信。這個特點非常棒，它在基礎設施內保證了高帶寬和低延時，專用網絡被共享給數據中心所有的 Droplets，包括那些屬于其他 DigitalOcean 客戶的 Droplets。這就是說，專用網絡保護我們不會被接入一般的互聯網連接，但可能接入其他不屬于我們的 Droplets。
我們選擇配置 V*N 來確保服務器專用網絡的安全，它提供的加密和身份認證正是我們所需要的。我們選了 Tinc V*N，因為它有網狀路由布局，這意味著它的流量會盡可能直接發送到目標主機。它允許通過直連的 Droplets 發送流量，而不必直接與請求者相連。不像 OpenV*N 那樣把 V*N 管理復雜化，我們的 V*N 更像是個傳統的專用網絡。
就像防火墻配置一樣，我們用 SaltStack 集中管理 V*N 配置。這樣就可以在所有服務器中自動更新 Tinc V*N 的配置，從而保證了所有 V*N 網絡的正確和及時更新。
Step 4：啟動數據庫備份
第四步是設置備份來遷移數據庫。
最初，我們計劃在數據庫遷移期間把 Ghost (Pro)下線。這樣暫停一下，我們就可以保持數據的連續性，并為 MySQL 數據庫備份。然后我們再把備份傳到新數據庫服務器上，最后重置一下就能完成數據庫遷移。然而，分析完現有數據后，我們發現這并不可行。我們有大約 500G 的數據庫，這意味著預計需要 6 小時的下載時間，還不包括任何意外的錯誤。服務下線那么長時間是不能接受的。我們需要其他解決方案。
我們決定首先遷移備份數據庫，這樣可以保證在遷移數據的一致性，同時也能保證數據庫遷移過程中線上服務不中斷。下面簡述備份步驟：
- 配置 Master/Slave 備份
把原始數據庫服務器設置為 master，新數據庫服務器設為 slave。這意味著從原始數據庫系統到新架構的數據庫備份是單向的。
- 測試新基礎設施
用這樣的 master/slave 設置，就可以測試了，看我們新的 Ghost (Pro)系統是不是和原有設置保持一致。所有測試完成后，我們刪除了新的數據庫服務器（slave）數據來為下一步做準備。
- 配置 Master/Master 備份
新數據庫服務器測試后，我們開啟了 master/master 備份，這意味著所有的數據變更是雙向的。一旦開啟 master/master 備份，原始數據庫被遷移到新服務器上，新的基礎設施準備就緒了。更多關于數據庫遷移的教程，請參考1、2。
Step 5：更新 DNS 記錄
第五步是更新 DNS 記錄，以此把新基礎設施投入使用。
更新 DNS 記錄有時候會出現問題，因為 DNS 生效需要時間。如果處理得當，生效時間是幾個小時，用戶可以使用新老系統。我們使用 CloudFlare 管理 DNS 條目，它支持實時修改 DNS，這樣我們就能避免可能出現的問題了。
當準備啟用新系統時，我們執行了以下步驟。首先，更新 ghost.org，使它指向新的核心服務器；然后，測試運行；最后，更新 ghost.io，使它指向新緩存服務器，再多測試幾次。
Step 6：下線舊的運行環境
最后一步就是下線舊運行環境中的服務器。所有服務都運行在新的 DigitalOcean 中，我們不再需要原來的專用服務器基礎設施了。淘汰舊的設備能大大節省我們的開支。
在關停舊的基礎設施前，我們需要停掉新舊數據庫服務器的備份。
結語
把 Ghost (Pro)平臺從專用服務器遷移到 DigitalOcean 非常成功。我們希望分享自己的經驗，因為我們知道業務遷移是很多項目面臨的一個挑戰。我們希望自己遷移到 DigitalOcean 的分享對其他準備遷移的項目能有借鑒意義。
來自: InfoQ