如何評估並將現有的 ASP.NET 網站上至雲端 - [Azure Web App]

現在越來越多企業對於內部系統上 Azure PaaS 躍躍欲試,筆者手上光是今年就有三家客戶想將現有系統移植上 Web App,以前將 ASP.NET MVC 網站佈署至 Azure 上大部分是玩票性質,直到真的有企業進行現有系統的 Migration 後才會真正遇到一些實際的狀況。

本篇文章,小編將過程記錄下來。

前言

先前有一個客戶想要將現有的公司內部的 ASP.NET 網站佈上 Azure 的 Web App ,他們希望我能夠提供諮詢與協助,本篇文章是將這個網站轉換並放置到 Azure Web App 的經驗分享。

現有環境

  •  Windows Server 2008 R2 ==> 顧名思義 執行在 IIS 7.5
  • ASP.NET WebForm 網站
  • .NET Framework 4.0
  • MS SQL Server 2008 R2

評估現有網站是否可以上雲端

看到上方的「現有環境」,相信讀者應該也注意到了這是一個 ASP.NET WebForm 所開發的網頁應用程式,但事實上移植到 Azure 並沒有差別,因為 Azure WebApp 也是提供 IIS 包含一個 AppPool 的執行個體,好比你在地端的 IIS 上開一個 IIS AppPool 來執行應用程式一樣沒什麼差別!

但是在 PaaS 上執行還是有一些限制存在,一般來說,要評估一個現有的網站是否可以上至雲端,我們會透過以下幾點來評估:

  • Web Apps 僅支援連接埠 80 (適用於 HTTP) 和連接埠 443 (適用於 HTTPS 流量)的繫結,系統將會忽略不同的連接埠組態,並將流量路由傳送至 80 或 443
  • Web Apps 預設支援匿名驗證以及應用程式所指定的表單驗證 只有與 Azure Active Directory 和 ADFS 整合,才能使用 Windows 驗證,目前不支援所有其他形式的驗證 (例如基本驗證)
  • Web Apps 不支援全域組件快取GAC,如果您的應用程式會參考部署至 GAC 的組件,就必須部署至 Web Apps 上的應用程式 bin 資料夾
  • Web Apps 不支援 IIS5 以前的相容性模式
  • 應用程式集區 - 在 Web Apps 中,每個網站及其子應用程式都在相同的應用程式集區中執行
  • 如果您的網站上有多個利用多個應用程式集區(AppPool)的子應用程式,請將它們彙總到具有通用設定的單一應用程式集區,或將每個應用程式移轉至個別的 Web 應用程式
  • Web Apps 不允許在平台上註冊 COM 元件,如果您的網站或應用程式使用任何 COM 元件,您必須以 Managed 程式碼予以重新撰寫,並與網站或應用程式一起部署這些元件
  • Web App 為了高可用性 HA (High Availability) 與附載平衡 (Load-Balances),因此,不支援 SessionState,如果您有使用到請考慮將 Session 存放至 SQL Database 或是 Redis Cache 中
  • 在 WebApp 上,若你需要上傳檔案至檔案系統,請務必使用 Storage/Blob 來存放,而不是使用 WebApp (VM) 本身的儲存體,因為儲存體的資料會因為動態配置時被刪除或消失

應用程式要上 Azure Web App,除了排除前面的已知的注意事項、與定價資訊(評估)外,需要上 PaaS 的項目部分,我們得要分以下幾個來看:

1. ASP.NET Website

2. (應用程式/網站) 所使用的 MS SQL Server 也需要上 Azure SQL Database

3. ASP.NET Website 的 Session 導向 SQL Database 或 Redis Cache 中

    A. 如果要導向 Redis Cache 中,那麼根據目前網站的使用者數、每一個 Session 工作階段所使用的量來評估的話,最少得使用 C1 標準 定價等級的 Redis Cache

4. 原有的 ASP.NET 網站若有檔案上傳 (FileUpload) 的部分,這得要再開一個 儲存體帳戶 來存放上傳的檔案,因此也得要將這個 Storage 成本估算進來。

5. 如果網站需要走 SSL 也要將憑證的租用費用算進來

6. 多少使用者、平均用量 (頻寬/價格)

作業開始

以下開始進行上雲端的作業,首先,評估的項目是,因為可能要將 Session 導向至 Redis Cache 中,但 Microsoft.Web.RedisSessionProvider 如果要使用叢集,官方建議使用 2.0.1 或更高版本,否則會擲回例外狀況,但這樣可能需要使用 .NET 4.6 的執行環境會較理想,但是現有的網站是 .NET 4.0,所以勢必要升級。

而升級,我們會面臨到幾個挑戰,如下方我們一個個來談:

1. Entity Framework 4.0 升級到 5.x 以上

在 Entity Framework 4.x 之前的版本使用的是 「擴充功能」裡的 System.Data.Entity.DLL 提供的實體物件功能,但這從 5.x 開始改由  NuGet 提供,所以這個問題稍微棘手一點,因為該舊網站使用的是 Entity Framework 4.0 而且使用的還是 Model Designer from existing Database

在我們改使用 NuGet 安裝 Entity Framework 且升級到  6.1.3 之後,馬上編譯就會發生錯誤如下:

因為原本的 ObjectContext 定義在 System.Data.Objects 中,且在 System.Data.Entity.DLL 這顆組件中,但 5.x/6.x 是定義在 EntityFramework.DLL 這個組件中,且命名空間更換到 System.Data.Entity.Core.Objects 裡。解決方式也很容易,首先,移除掉 「System.Data.Entity」、「System.Data.Objects」、「System.Data.Objects.DataClasses」這三個命名空間,如下:

這時候按下 快速鍵 Shift+alt+F10 小燈泡就會自動列出可以引用的項目。

剩下的 [assembly: EdmSchemaAttributes()] 使用 IDE 工具幫我們找回應該要 using 的命名空間即可。

注意:

您也可以改寫為 DbContext,從 Entity Framework 5.x 開始改以 DbContext 取代 ObjectContext,DbContext 是 ObjectContext 的輕量版,比較適合套用 Repository Pattern 樣式來實作 Data Access Layer,詳細的比較可以參考 Stackoverflow 上的解釋「ObjectContext vs DbContext

2. 更新 AjaxControlToolKit

這部分比較沒什麼問題,原先所使用的 AjaxControlToolKit 是 4.1.51116,且不是由 NuGet 安裝,是自行下載參考進來的,這部分還好 NuGet Market 上還可以找到 4.1.51116

到這裡,初步可以在開發環境先測試使用 Entity Framework 6.1.3 與 執行原本的 CRUD 是無問題,以及驗證 AjaxControlToolKit 在 .NET Framework 4.6 下所有 WebControls 的執行是否如預期,可搭配一些自動化測試工具,如:Selenium。

開始上雲端

如果驗證無誤,由於應用程式本身使用到 Session,前面提到客戶希望此應用程式使用 Redis Cache 來存放 Session,現在我們要開始安裝 Microsoft.Web.RedisSessionStateProvider

接著是調整 Web.Config 中的 <sessionState> 區段,將 mode 調整為 “custom”,並定義 customProvider,如下:

assessKey 以及連線字串中的 password 可由 Azure Portal 中取得。

 

資料庫也要上雲端 (PaaS 服務的 SQL Database)

當然,我們得先建立一個 SQL Database 服務,建立方式筆者就不再熬述,可參考 Microsoft Docs 「
在 Azure 入口網站中建立和查詢單一 Azure SQL Database」 的說明。

在 SQL Database 建立完成之後,接著就是將現有地端的 MSSQL Database 匯出來,可使用命令列工具 BACPAC 工具匯出,或是使用 SSMS 工具執行匯出,筆者這裡採用 BACPAC 工具匯出。

匯出方式如下:

不過在執行匯出時,如果你的 Store Procedure 的撰寫方式如果是 [DBName].[dbo].[TableName] 方式是不會過的,原因很減單,因為 SQL Database 本來就不支援跨 DB 的寫法,因為他只是提供單一 Instance 給你。

匯入方式如下圖:

註:

BACPAC 命令列語法可參照官方說明「SqlPackage.exe 說明

在前棉的步驟都完成之後,我們可以將這個 ASP.NET WebForm 的應用程式發佈到 Azure WebApp 上 (發佈到 Azure WebApp 上可參考:Publish the App to Azure WebApp 這類說明官方都非常完整,筆者就不再熬述)

 

開始測試

萬事俱備後,緊張的時刻來了,希望執行時不要掛掉 XD,不過事實上,總是事與願違,一執行隨即收到錯誤訊息…..

根據錯誤訊息可以推斷是有物件 Class 並未標記為 [Serializable] 導致無法序列化並儲存到 Redis Cache 中,於是立馬執行簡單的 Code-Review 作業,搜尋所有程式碼裡面有使用到 Session 的部分,並確認都加上 [Serializable],但重新發佈後在測試還是相同的結果,案情這時候陷入膠著…………

於是,唯一作法就是先寫 Log 吧!重新發佈程式後,再由 Log 去查看問題出在什麼地方?

後來在 Log 中發現,在將 SecurityLevel 物件塞入時發生這個 Exception,詳細查看這個 SecurityLevel 類別後發現,他的屬性 Property 裡面居然有一個父類型是 System.Web.UI.Page 類型的物件,疑!這不是 Web Page 的型態,這就搞笑了,倒底是誰把 Web Page 塞到 Session 裡?(怒~翻桌)… 這當然會序列化失敗。

調整後,果然測試成功!!!

 

後記

現在越來越多企業對於內部系統上 Azure PaaS 躍躍欲試,筆者手上光是今年就有三家客戶想將現有系統移植上 Web App,以前將 ASP.NET MVC 網站佈署至 Azure 上大部分是玩票性質,直到真的有企業進行現有系統的 Migration 後才會真正遇到一些實際的狀況。


 

簽名:

學習是一趟奇妙的旅程

這當中,有辛苦、有心酸、也有成果。有時也會有瓶頸。要能夠繼續勇往直前就必須保有一顆最熱誠的心。

軟體開發之路(FB 社團)https://www.facebook.com/groups/361804473860062/

Gelis 程式設計訓練營(粉絲團)https://www.facebook.com/gelis.dev.learning/


 

如果文章對您有用,幫我點一下讚,或是點一下『我要推薦,這會讓我更有動力的為各位讀者撰寫下一篇文章。

非常謝謝各位的支持與愛護,小弟在此位各位說聲謝謝!!! ^_^