[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
簡而言之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
很抱歉,必須登入網站才能發佈留言。