[IIS 8.5 | Azure]_將On Premise上的WordPress轉移到Azure VM

直接Copy paste發在FB解釋做這件事情的動機文字內容XD…:

 

因為HPC Server放在頂樓,才不到兩年機殼就開始有很明顯的鏽蝕

自幹NAS在一樓RUN了6年都沒一點生鏽…

覺得這樣下去不太妙,考量了一下我只有在需要HPC的時候才會動用頂樓HPC Server…

而現在唯一需要他開24H的原因也只是想說順便把原本托在NAS上的Blog拿來放在上面。

但發現這是個不明智之舉,因為平常blog流量一天也才3百多人次,托在HPC Server上雖然給的資源一點點,但電力還是種浪費

於是趁休息時間…做了一些事
把Wake on lan的功能測一下,之前這個功能測試失敗就擺著沒試,調了一些設定,之後有需要HPC,可以直接用NAS送WOL封包叫醒Server,用完之後直接從OS下關機就可以

而原本的Blog也花了幾個小時轉移到Azure虛擬機器上

好一段時間沒碰Azure,新的Portal被改的好好用…
但很多地方要重新摸,文章也有一定數量是舊Portal的

原本打算VMWare migrate到Azure,但發現一直受重重阻礙
尤其現在新的VM作法又不太一樣,不想花太多時間

Updraft有推30USD無痛轉移套件…但我不想花錢 😛

決定還是直接把IIS的Web application export以及MySQL export,直接開一台全新的Windows Server把Blog手動丟上去

過程有點小bug,不過都還是順利解決…

希望MSP的MSDN額度可以繼續無限Extend…XDD…

沒Azure額度就糗了…

不用Web APP在於MySQL的是不能用Azure額度去扣的…這就是為甚麼我們Addweup最後服務雲端沒有Host在Azure的主因…哀哀可惜~~~

最後都安頓好之後測了一下時間
TTFB比自己Host的站只慢了10~20ms

今天終於可以安心的關掉HPC Server啦~~
預計之後會把HPC Server拿來直接當個人電腦了
<del>裝張顯卡就可以重返PC Gamming XDDD</de>

 


 

於是本篇來記錄一下,手動轉移IIS上的Wordpress到一台全新Azure VM上需要哪些步驟

 

1.把IIS對應的站台停掉,並建議備份原本的On Premise VM:

可以使用Windows Backup,若為VM可以Snapshot一下

 

2.Set好Azure VM:

這步驟必須要準備一些東西

WordPress會需要的PHP,既然是全新的VM而不是用轉移的,這次就直接利用Microsoft WebInstaller 5裝上PHP7.0.3,還有另外下載的MySQL 5.7

以及URL Rewrite2建議先下載安裝檔下來,不要安裝

WP在IIS上跑只需要這三樣東西,其他都不用

 

並且記得在Azure portal上開好對應的端口

 

3.回頭到舊站台,從IIS後台直接匯出整個Wordpress:

這樣會順便幫你把所有的照片跟整個網站都打包成一包zip,會包括站台原先的設定(但後面還是有一些在web.conf的參數是因為只適用在舊機器上所以必須手動拿除,基本上不適用的參數匯入新機器在使用IIS管理員設定站台並運行時會告訴你哪邊有問題,再一一修改即可)。

並且上傳到新站台上,並利用”匯入應用程式”進行站台匯入

 

之後記得把站台底下的wordpress應用程式的Application Pool設定改成No Managed Code與Classic

 

4.舊站台上,匯出對應wordpress的資料庫,並匯入到新站台用的DB中:

另外在wp-config.php內,其實會直接用明文記載著你站台使用的DB Table, DB User, DB Password,拿這DB Table名稱去MySQL裡面把對應的TABLE Export,可利用MySQL Workbench來幫你忙。以及手動的在新站台上的MySQL手動建立對應的db user,如果你要換db上專門給這個WP用的USER帳號密碼什麼的記得wp-config.php要跟著動就對了。

 

如果你忘記舊DB的root密碼…可以估狗,但我認為跳過grand-tables會比較有效快速

參考:http://stackoverflow.com/questions/21651898/resetting-root-password-in-mysql-5-6

 

以及你可能再匯入的時候會遇到row count過大導致無法完全匯入的問題,錯誤碼如下:

Error Code: 1118 Row size too large (> 8126). Changing some columns to TEXT or BLOB

可以將位於C:\ProgramData\MySQL\MySQL Server 5.7下的my.ini,最後面加上:

innodb_strict_mode=0

儲存之後重新啟動MySQL(可用windows 服務管理員重啟),重新執行匯入動作就ok,匯入完之後再把該行註解掉並重啟MYSQL

參考:http://stackoverflow.com/questions/22637733/mysql-error-code-1118-row-size-too-large-8126-changing-some-columns-to-te

 

簡而言之DB只要匯出WP用的Table,以及重新建立對應的WP db user即可。

 

5.調整PHP設定

先是php.ini

路徑在C:\Program Files\PHP\v7.0

post_max_size, upload_max_filesize, max_file_uploads視需求改大

第一項影響WP能夠上傳的檔案,第三項則是單一requset可以丟多少

 

6.檢查IIS對應WP站台及應用程式的Handler Mappings與URL Rewrite

Handler Mappings內的PHP_via_FastCGI是否正確指向PHP7的php-cgi.exe

 

以及URL Rewrite有沒有正確,如果你在IIS沒有找到URL Rewrite,請直接上網找Microsoft URL Rewrite2,另外我這邊遇到一個很怪的情況是先裝好才匯入站台,明明web.config的設定都對,但會告訴你找不到schema…我是重新裝ULR Rewrite 2後就自己正常了

Rewrite rule沿用你先前有正確運作的設定就可以,當然你也可以double check,這是其中一個版本的寫法:

http://www.iis.net/learn/extensions/url-rewrite-module/enabling-pretty-permalinks-in-wordpress

 

我自己是用這個版本:

    <rewrite>
      <rules>
            <rule name="wordpress" patternSyntax="Wildcard">
                <match url="*" />
                    <conditions>
                        <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" />
                        <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" />
                    </conditions>
                <action type="Rewrite" url="index.php" />
            </rule></rules>
    </rewrite>

 

如果URL Rewrite沒有寫對,那在繼續閱讀文章跳轉時會403 forbidden,就是需要來這邊檢查一下

 

6.權限

記得WP站台的資料夾權限要加入IIS_IUSRS完整權限

還有很怪的是C:/Windows/Temp也要給IIS_IUSRS讀取的權限,否則上傳新的照片Editor Preview會跑不出來(我也是打這篇文章才發現…)

參考:https://blog.sofast.info/2016/05/after-wordpress-added-the-media-show-500-internal-server-error/

 

7.域名

因為我WP有綁域名,記得IIS WP站台也要在Biding那邊改一下,以及在域名指向位置也要做對應調整。

 

 

最後可以多逛逛轉移後的WP,點開照片看有沒有正常(記得把WP給的CDN先關了以確保其來源運作正常)以及發發文章~

 

 

我這次自己的經驗大概是這樣~~,所有的數據跟文章媒體都直接帶過來,非常快速

後續站台有發生甚麼怪問題會繼續補充在這一篇

Leave a comment 取消回覆

這個網站採用 Akismet 服務減少垃圾留言。進一步了解 Akismet 如何處理網站訪客的留言資料

Exit mobile version