Ghost是一個開源博客平臺，而Ghost(Pro)是它的托管平臺。這篇文章的作者是Ghost的高級DevOps工程師Sebastian Gierlinger。他用簡單的6個步驟，總結了Ghost(Pro)的基礎設施從專用服務器遷移到DigitalOcean Droplets的過程。

以一年多運營Ghost(Pro)的經(jīng)驗來看，我們認為自己的下一代基礎設施需要滿足如下需求：

任何一個項目的遷移，都以一定程度的不確定性開始。一開始就預料到所有的遷移步驟是不可能的，更不要說預料到任何一個即將遇到的問題。但鑒于這是一篇回顧文章，出于方便理解的目的，遷移過程包括以下幾個大步驟：

遷移后的Ghost(Pro)系統(tǒng)架構是這樣的：

　　下面就讓我們來詳細看看遷移過程的6個步驟。

Step 1：創(chuàng)建目錄

第一步是用配置管理工具創(chuàng)建一個目錄，用來顯示現(xiàn)存的服務器基礎設施上運行著什么。

我們并沒有一個完整的目錄，包含所有安裝的軟件、防火墻設置和其他服務器配置。為了解決這個問題，我們引入了一個配置管理系統(tǒng)工具箱。配置管理的一大好處就是，一旦系統(tǒng)建立起來，它既可以作為記錄文檔，又可以用作一個部署工具。

我們考慮過幾個比較流行的配置管理工具，包括Puppet、Chef、Ansible和SaltStack。我們需要一個既能完成工作又不容易因為復雜性而過載的工具。最終就選擇了SaltStack。

下面是幾個選擇SaltStack的原因：

另一個附加的好處是Salt Cloud，它包含在SaltStack里，并且和DigitalOcean的API無縫兼容，資源可以快速彈性伸縮，我們可以用命令行管理系統(tǒng)資源。

雖然這個新的Ghost(Pro)架構初始設置和配置頗花費了一些時間——大概3周，但SaltStack表現(xiàn)除了它強大的功能。第二步迭代配置用了大概一周，第三步部署托管平臺只用了兩天。

創(chuàng)建一個目錄，并把它遷移到配置管理工具，這是一個迭代的過程，會涵蓋幾乎整個系統(tǒng)遷移的過程。除了完成遷移，創(chuàng)建目錄還暴露了我們結構中需要改進的部分。讀者如果想要嘗試SaltStack更多功能，請參考使用手冊：1、2、3.

Step 2：確保公網(wǎng)安全

第二步是為了確保平臺內(nèi)部服務器的公網(wǎng)防火墻安全。

以前，只有我們面向公眾的服務器可以通過外網(wǎng)訪問；其他服務，比如APP和數(shù)據(jù)庫服務，只能通過專用網(wǎng)絡訪問。遷移到DigitalOcean的云端后，所有服務器都有一個公共IP地址，我們必須解決這項新的安全隱患。

我們給內(nèi)部服務器的公網(wǎng)設置了一個iptables規(guī)則，能夠攔截除了SSH加密通信的其他所有連接。我們自己的服務器用的是Ubuntu，所以用UFW作為iptables的管理界面。

和其他基礎設施一樣，防火墻配置是通過SaltStack完成的，方便于我們統(tǒng)一管理。

Step 3：確保專用網(wǎng)絡安全

第三步是用VPN確保所有服務器專用網(wǎng)絡的安全。

DigitalOcean的專用網(wǎng)絡允許同一數(shù)據(jù)中心的Droplets彼此通信。這個特點非常棒，它在基礎設施內(nèi)保證了高帶寬和低延時，專用網(wǎng)絡被共享給數(shù)據(jù)中心所有的Droplets，包括那些屬于其他DigitalOcean客戶的Droplets。這就是說，專用網(wǎng)絡保護我們不會被接入一般的互聯(lián)網(wǎng)連接，但可能接入其他不屬于我們的Droplets。

我們選擇配置VPN來確保服務器專用網(wǎng)絡的安全，它提供的加密和身份認證正是我們所需要的。我們選了Tinc VPN，因為它有網(wǎng)狀路由布局，這意味著它的流量會盡可能直接發(fā)送到目標主機。它允許通過直連的Droplets發(fā)送流量，而不必直接與請求者相連。不像OpenVPN那樣把VPN管理復雜化，我們的VPN更像是個傳統(tǒng)的專用網(wǎng)絡。

就像防火墻配置一樣，我們用SaltStack集中管理VPN配置。這樣就可以在所有服務器中自動更新Tinc VPN的配置，從而保證了所有VPN網(wǎng)絡的正確和及時更新。

Step 4：啟動數(shù)據(jù)庫備份

第四步是設置備份來遷移數(shù)據(jù)庫。

最初，我們計劃在數(shù)據(jù)庫遷移期間把Ghost(Pro)下線。這樣暫停一下，我們就可以保持數(shù)據(jù)的連續(xù)性，并為MySQL數(shù)據(jù)庫備份。然后我們再把備份傳到新數(shù)據(jù)庫服務器上，最后重置一下就能完成數(shù)據(jù)庫遷移。然而，分析完現(xiàn)有數(shù)據(jù)后，我們發(fā)現(xiàn)這并不可行。我們有大約500G的數(shù)據(jù)庫，這意味著預計需要6小時的下載時間，還不包括任何意外的錯誤。服務下線那么長時間是不能接受的。我們需要其他解決方案。

我們決定首先遷移備份數(shù)據(jù)庫，這樣可以保證在遷移數(shù)據(jù)的一致性，同時也能保證數(shù)據(jù)庫遷移過程中線上服務不中斷。下面簡述備份步驟：

把原始數(shù)據(jù)庫服務器設置為master，新數(shù)據(jù)庫服務器設為slave。這意味著從原始數(shù)據(jù)庫系統(tǒng)到新架構的數(shù)據(jù)庫備份是單向的。

用這樣的master/slave設置，就可以測試了，看我們新的Ghost(Pro)系統(tǒng)是不是和原有設置保持一致。所有測試完成后，我們刪除了新的數(shù)據(jù)庫服務器（slave）數(shù)據(jù)來為下一步做準備。

新數(shù)據(jù)庫服務器測試后，我們開啟了master/master備份，這意味著所有的數(shù)據(jù)變更是雙向的。一旦開啟master/master備份，原始數(shù)據(jù)庫被遷移到新服務器上，新的基礎設施準備就緒了。更多關于數(shù)據(jù)庫遷移的教程，請參考1、2。

Step 5：更新DNS記錄

第五步是更新DNS記錄，以此把新基礎設施投入使用。

更新DNS記錄有時候會出現(xiàn)問題，因為DNS生效需要時間。如果處理得當，生效時間是幾個小時，用戶可以使用新老系統(tǒng)。我們使用CloudFlare管理DNS條目，它支持實時修改DNS，這樣我們就能避免可能出現(xiàn)的問題了。

當準備啟用新系統(tǒng)時，我們執(zhí)行了以下步驟。首先，更新ghost.org，使它指向新的核心服務器；然后，測試運行；最后，更新ghost.io，使它指向新緩存服務器，再多測試幾次。

Step 6：下線舊的運行環(huán)境

最后一步就是下線舊運行環(huán)境中的服務器。所有服務都運行在新的DigitalOcean中，我們不再需要原來的專用服務器基礎設施了。淘汰舊的設備能大大節(jié)省我們的開支。

在關停舊的基礎設施前，我們需要停掉新舊數(shù)據(jù)庫服務器的備份。

結語

把Ghost(Pro)平臺從專用服務器遷移到DigitalOcean非常成功。我們希望分享自己的經(jīng)驗，因為我們知道業(yè)務遷移是很多項目面臨的一個挑戰(zhàn)。我們希望自己遷移到DigitalOcean的分享對其他準備遷移的項目能有借鑒意義。

本文編譯自：How Ghost Migrated From Dedicated Servers to DigitalOcean