2017年11月17日 星期五

網頁執行錯誤HTTP 500.19 - 解決方法


最近遇到客戶反應,當網頁的使用者過多時,尤其是特定的時段,網頁會發生HTTP 500的錯誤,在進一步的確認後發現初步的問題如下。

從下列的錯誤來看,其實可以看到已有提到可以有參考的KB,而且也有詳細的錯誤,找一下Google大神後,你會找到不少的文章與解決方法,但如果真的這麼簡單的話,我也不會寫下這篇文章了,其實在我嘗試了不同網站寫的方法後,其實都無法解決,而且最重的事如果你照著設定的話,你會發生系統會發生問題,無法進行檔案分享,而且關機時會無法正常進行,如下列的畫面。

就因為如此,所以我才特別整理此篇文章,希望大家可以藉以解決此問題。

錯誤訊息:
[From Web Page]

[From Failed Request Tracing Log]

[From Event Log]
Event Level:Error
Source:ASP.NET 4.0.30319.0
Event ID:1185
Message:Failed to start monitoring changes to '\\caryhsu\my_fav\video' because the network BIOS command limit has been reached. for more information on this error, please refer to Microsoft knowledge base article 810886. Hosting on a UNC share is not supported for the Windows XP Platform.

設定錯誤時,嘗試關機的畫面:

環境描述:
1、IIS Server(Windows 208R2)
2、File Server(Windows 2003R2)

目前已知在新版的環境上也都可以重現此問題。

問題重現:
1、由於此問題在大量的透過網路分享時就會遇到,所以我建立一個站台,然後建立50個虛擬目錄。


2、在各虛擬目錄上我也分別設定特定的使用者。

 3、為了模擬大量的使用者,所以透過Visual Stdio進行壓測,果然立即就發生相同的情況。

解決方法:
在此處設定的值非常的重要,如果在IIS端設定錯誤時,可能就會造成此主機在分享目錄上發生問題,所以強烈建議請參考下列的值進行設定即可。

For IIS(Windows 2008R2)
HKLM\system\currentcontrolset\services\lanmanworkstation\parameters\MaxCmds=REG_DWORD value=5000(十進位制)

再次強調,上述的值(5000),請勿設定過大,否則會造成系統問題。

For File Server(Windows 2003R2)
HKLM\system\currentcontrolset\services\lanmanserver\parameters\Maxwi=REG_DWORD value=65535(十進位制)

HKLM\system\currentcontrolset\services\lanmanserver\parameters\MaxMpxCt=REG_DWORD value=65535(十進位制)

設定完成後,再請重新啟動電腦後即可。


關鍵字:KB810886500.19network BIOS command limit has been reached

參考連結:


2017年3月1日 星期三

如何進行App Service for Web問題排除

網站發生問題時,往往都會手忙腳亂,雖然Azure有提供良好的服務可以直接請工程師進行問題的排除(Azure Technical Support),但有時候問題的情況過了之後就需要再等待問題的重現,所以我們本篇就介紹一些基本的排除方式,在第一時間發生時,即可以收集並進行初步的分析與問題排除,另外也可以將收集到的資訊提供給專業的微軟工程師進行初步的分析,藉以快速的找出問題。

其實當問題發生時,可以先初步的確認Azure Service Status的網站,確認此次的問題是否可能與Azure本身的服務有關,當如果真的是Azure本身發生問題時,通常發生問題會以Data Center為區域性影響,網站上也會進行公告,但有時候可能公告訊息不一定會立即列出問題的區域,如果沒有顯示會並非Azure本身的問題的話,我們接下來後續的處理。

基本上App Service for Web(Windows)本身的核心就是IIS,所以我們可以透過一些IIS的除錯方式進行處理,另外在問題除錯上,非常不建議在正式的網站啟用Remote Debug Mode進行,因為會造成網站整個被咬住,造成許多問題。

建議如果可以的話,可以嘗試在Deployment Slot新增一個測試站台,然後再透過此測試網站進行遠端除錯,老話一句正式環境不到最後一步,儘可能不要使用遠端除錯的方法。

可能的問題情況:
1、Azure Portal介面操作無法完成,出現錯誤等情況。

1-1 請先嘗試將語言與地區格式切換至英文(English)後,再進行確認。
1-2 如果都無法完成你要的作業時,此時建議可以將錯誤畫面截圖並將操作過程透過瀏覽器的開發者工具(F12)或是透過Fiddler進行收集,並在Azure Portal上建立Support Request請微軟的工程師進行協助。

2、網頁無法顯示或是顯示錯誤訊息為500、50x類型:

2-1 請確認空白網頁(html)是否也會有相同的情況。
2-2 請確認下列的#a收集網站的詳細錯誤訊息,確已確認問題為何。
2-3 透過下列的#b的方式進行memory dump的捉取,並再進行分析找出問題。

3、特定網頁開啟緩慢

3-1 請確認空白網頁(html)是否也會有相同的情況。
3-2 透過Application Insights觀察目前網站的情況,藉以確認是否網站無法負荷,可以嘗試增加Instance,藉以加快處理。
3-3 如果程式語言為.net時,建議可以透過下列的方式在程式中加入執行計時分析,藉以找出真正慢的區塊為何。

Stopwatch 類別
https://msdn.microsoft.com/zh-tw/library/system.diagnostics.stopwatch(v=vs.110).aspx

3-4 在網頁過慢的時候,透過Hang Dump的方式建立Memory Dump,藉以分析當下網站主要的問題為何。

4、網頁發生列外狀態(Exception)。

4-1 透過Application Insight可以收集到程式是否有產生Exception。
4-2 透過#a的log可以知道是那一支程式發生Exception。
4-3 在有問題的程式區塊透過Try-Catch進行例外的捉取,
4-4 透過#c的方式主動觀察網站,並產生Exception Dump。

PS:如果你的網站有多個網頁都有發生例外時,可能你會收到太多種的Exception Dump,所以可能會收到的檔案並非預期頁面的檔案,這時就要分析這些檔案的資訊,再逐一解決這些問題。

5、CPU High

5-1 透過Application Insights觀察目前網站的情況是否正常,如流量與CPU比率等。
5-2 當問題發生時透過#b的方式進行Hang Dump的產生,再進行分析。
5-3 問題發生時可能無法當下手動產生,可以透過#c的方式進行自動監控,藉以當CPU超過一定的比率時,自動產生Hang Dump File,

6、網站發生Crash

6-1 透過後台觀察網站有自動進行重啟。
6-2 透過Application Insights發現網站有重啟的情況。
6-3 透過#c的方式自動觀察網站,當發生Crash時,即會自動產生Crash Dump。

資訊收集:
a. 啟用詳細的Log File與Failed Request Tracing

這個其實就是捉取IIS的Log File,另外也可以透過Failed Request Tracing當問題發生時詳細記錄錯誤訊息。

在 Azure App Service 中針對 Web 應用程式啟用診斷記錄功能
https://docs.microsoft.com/zh-tw/azure/app-service-web/web-sites-enable-diagnostic-log

b. 將網站手動產生Memory Dump

登入SCM的後台,選擇 Tools -> Diagnostic dump即可產生Memory Dump,千萬記住在產生時,系統會全部暫時凍結住,所以會影響前端的操作,這部份再請注意。

Using KUDU with Microsoft Azure Web Apps
https://blogs.msdn.microsoft.com/benjaminperkins/2014/03/24/using-kudu-with-windows-azure-web-sites/

c. 透過網站的擴充功能(Extensions)啟用自動監控,即可當網站發生預期的問題時,即可自動產生Memory Dump。

假設我們啟用監控CPU當超過60%又超過10秒時,自動產生Memory Dump。

從網站的處理序總管即可看到會有二個新增的Process,名稱為CrashDiagnoserProcDump,當設定的條件達到時,即會自動產生。

How to capture and analyze a dump file when intermittent High CPU happens on Azure Web Apphttps://blogs.msdn.microsoft.com/asiatech/2016/01/20/how-to-capture-dump-when-intermittent-high-cpu-happens-on-azure-web-app/

d. 分析Memory Dump。

基本上對底層架構沒有一定的熟悉時,是很難可以自行分析的,但其實我們可以過一些方式簡單的進行分析,如果還是不行的話,其實還是可以透過Support Request請微軟的工程師進行分析。

net 程式進階除錯教學 - 使用WinDbg
http://caryhsu.blogspot.tw/2011/11/net-windbg.html

Analyze a memory dump using the Debug Diagnostic tool
https://blogs.msdn.microsoft.com/benjaminperkins/2016/02/01/analyze-a-memory-dump-using-the-debug-diagnostic-tool/

Using Visual Studio 2013 to Diagnose .NET Memory Issues in Production
https://blogs.msdn.microsoft.com/visualstudioalm/2013/06/20/using-visual-studio-2013-to-diagnose-net-memory-issues-in-production/


關鍵字:AzureWeb AppsApp Service for WebTroubleshooting問題排除Memory Dump

2017年2月25日 星期六

建置Azure App Service for Web的建議實務 - 進階篇

上一篇我們已介紹完基礎建置的部份,接下來我們來介紹進階管理與應用的部份,功能的部份我也逐一介紹,如有不清楚或較深入整合的應用,我會考慮再加開文章進一步的介紹,也歡迎大家討論。

相關介紹:
建置Azure App Service for Web的建議實務 - 基礎篇
http://caryhsu.blogspot.tw/2017/02/azure-app-service-for-web.html

1、部署位置(Deployment Slot)

一般我們在開發上如果要進行部署時,通常建議先將程式放置在測試機上進行確認,以後我們都需要找二台相同的機器進行正式機與測試機的運作,在App Service for Web上,你可以透過部署位置(Deployment Slot)來完成。

Standard TierPremium Tier等級上可以透過建立部署位置(Deployment Slot)來完成測試的動作,在建立後,你可以將程式先部署至此,然後再進行測試,到時候再透過切換的方式,即可達到快速的換版動作,一來可以先行測試程式,二來也可以減少前端離線的影響,最重要的是此功能在Standard TierPremium Tier等級上是免費的,所以強烈推薦進行使用。

從網站 -> 部署位置中即可看到目前已建立的項目,如下圖我們已先建立好一個部署位置。

從Visual Studio上來看,你也可以看到部署時我們可以選擇將專案部署到特定的位置上。

在應用程式設定的部份,也可以進行位置區分,當進行切換時,也可以保留特定部署位置上的設定值。


2、快取(Cache)

在快取的部份,除了在網站的部份啟用Local Cache外,在App Service for Web中大家常用的有Redis CacheCDN,二個是不同層級的應用,Redis Cache屬於應用程式中的資料快取,在某些資料上沒有即時性的需求時,即可考慮透過此服務來加快讀取,藉以提升速度。

另外由於我們的Web Apps部署時會選定一個資料中心(Data Center)進行存放,但是當使用者的區域與資料中心(Data Center)的位置不同時,可能會造成使用者在讀取上因為網路的傳遞過遠而造成頁面回應過慢的情況,此時你就可以考慮啟用CDN,藉以減少因地理環境不同而造成的讀取回應上過慢的問題。

快取等級:
Local Cache -> 網站內容快取
Redis Cache -> 網站內容中特定資料的快取
CDN -> 網站內容快取,並提供給其他地理位置的使用者進行讀取

3、Application Insights 

在網站架設後,我們要隨時觀察網站的使用量與健康程度,以往我們可以要透過IIS Log進行或是加入Google Analytics等進行網站的分析,其實可以不用這樣麻煩,你可以直接透過Application Insights進行即可,啟用後即可快速的透過此服務進行網站的監控。

3-1 預設上網站並沒有特別啟用Application Insights,請先進行建立。

建立時由於存放Application Insights的Data Center並沒有太多的選擇,所以可以先指定一個先行存放,基本上不會有太大的影響。

3-2 在程式中也需要同時啟用Application Insights,在Visual Studio非常簡單,只需啟用此服務並設定後即可。

3-3 啟用後即可透過即時計量資料流看到即時的資料。


3-4 Dashboard即可顯示監控的資訊,在監控的項目上也非常的多,可以將一些常見的都加入進行觀察。

3-4 在啟用Application Insights後,可以設定警示功能當監控的數值超過一定的數量主動透過E-Mail進行提示。

4、自動調整(Auto-Scaling)

在基礎篇有特別的提過,基本上網站可以應該忙碌的情況進行調整站台的執行個體,在預設的情況下是透過手動的方式進行,但在Standard Tier(含)以上的架構,可以透過CPU百分比排程及效能規則的方式進行自動調整的動作,此部份強烈建議你在啟用Application Insights後對網站的使用率有深入的了解後,即可進行彈性的調整,假設今天你知道晚上有有促銷的活動時,你就可以透過自動調整的規則進行,藉以穩定網頁的回應與整體速度。


5、Traffic Manager

在雲端上的服務基本上在一定的等級上都有服務層級協議(SLA),如App Service的部份只要是Basic Tier(含)以上的等級,就有保證每月最多只會有21分鐘左右的斷線(SLA 99,95),所以基本上也不會是100%保持服務,所以Traffic Manager會是你一個很好的選擇。

下圖是從官網截取而來的圖,從此圖上來看,概念類似負載平衡器,將使用者依據Traffic Manager的設定,如效能、優先權、權重等方式,一般來說常見的就是效能模式,效能模式上可以將使用者導向 "網路延遲" 最少的Data Center,問題當其中的一個Data Center發生問題無法提供服務時,Traffic Manager也可以將使用者導向其他的Data Center。

一般來說使用者最常考量的就是要同時租用多個Data Center,只為了那每個月的可能21分鐘斷線,但換個方向想每次的斷線可能造成當下的交易損失與多一個Data Center的成本相比,我想對大部份的企業來說決對是值得的,而且另一個節點還是有同時提供服務,並不是一般Cluster上的Standby模式,所以相信此服務絕對值得投資。

Traffic Manager架構圖

高效能模式
其實建立的方式也很簡單只要在Azure Portal上選擇Azure Traffic Manager Profile並選擇作業模式,此處的名稱即是後續連線時主要的DNS名再,而且後續無法變更,所以再請注意名稱的定義。


建立完成Traffic Manager Profile之後,再將Web Apps加入。

最後即可透過Traffic Manager對外的DNS名稱連線到Web Apps中。



參考連結:
App Service plans
https://azure.microsoft.com/en-us/pricing/details/app-service/plans/
Set up staging environments in Azure App Service
https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-staged-publishing
Redis 快取
https://azure.microsoft.com/zh-tw/services/cache/
開始使用 Azure CDN
https://docs.microsoft.com/zh-tw/azure/cdn/cdn-create-new-endpoint
設定 ASP.NET 的 Application Insights
https://docs.microsoft.com/zh-tw/azure/application-insights/app-insights-asp-net
Scaling apps in an App Service Environment
https://docs.microsoft.com/en-us/azure/app-service-web/app-service-web-scale-a-web-app-in-an-app-service-environment
Manage an Azure Traffic Manager profile
https://docs.microsoft.com/en-us/azure/traffic-manager/traffic-manager-manage-profiles



關鍵字:App Service for WebAuto ScalingBest Practices、Cahce

2017年2月21日 星期二

建置Azure App Service for Web的建議實務 - 基礎篇

網站架設的部份,以往都是透過代管的方式或是自申請固定IP自行架設,在雲端的推出後,許多人紛紛打量雲端架構的合適性,在雲端上常見的方式就是透過IaaS的方式,在Azure Portal上啟用一個VM,然後再進行服務的提供,但其實這的情況下,你仍需處理如HA、Load Balance、Backup與OS等層面的問題,除非是真的有其考量性,其實現在有一個方案可以考慮,透過Azure App Service for Web,即可完成快速的完成網站的部署與架設。

關於Azure App Service for Web我們就先逐步來說明建立上的程式,相信在官網上也有相常的資料可以參考,所以文章上我將著重在建立上一些常見的細節,如果有任何問題,也歡迎大家提出。

1、評估初使架構大小
一開始最常遇到的就是該如何設定初使的大小,由於在雲端上屬於使用多少就付多少錢,在你的網站上,一開始我們要先評估一個合適的大小,雖然都有強調會自動延展,但前提是你要使用Standard Tier才可以設定規則自動進行,要不然的話,基本上都是手動進行調整,所以我們就介紹幾個常見且大略的評估方式進行。

1-1 在地端的機器設備為何,經效能監視器進行監控後大約使用到的比例為多少,再換算為何適的大小。
1-2 另外也可以先選擇Basic的類型,然後再透過Application Insight持續進行監控並確認目前的網站回應速度為何。

參考價格(實際的價格請參考官網連結的資訊為主)
Type Instance Cores Ram Storage Prices
Free and Shared F1 Share
(60 CPU min/day)
1GB 1GB NT$0 
D1 Share
(240 CPU min/day)
0.5GB 1GB  ~NT$0.403 per site per hour (~NT$300.10/mo)
Basic Service Plan B1 1 1.75GB 10GB NT$2.3271/hr
(~NT$1,731/mo)
B2 2 3.50GB 10GB NT$4.6541/hr
(~NT$3,463/mo)
B3 4 7GB 10GB NT$9.3083/hr
(~NT$6,925/mo)
Standard Service Plan S1 1 1.75GB 50GB NT$3.1028/hr
(~NT$2,308/mo)
S2 2 3.50GB 50GB NT$6.2055/hr
(~NT$4,617/mo)
S3 4 7GB 50GB NT$12.41/hr
(~NT$9,234/mo)
Premium Service Plan P1 1 1.75GB 250GB NT$9.3083/hr
(~NT$6,925/mo)
P2 2 3.50GB 250GB NT$18.62/hr
(~NT$13,851/mo)
P3 4 7GB 250GB NT$37.23/hr
(~NT$27,701/mo)
P4 8 14GB 250GB NT$74.47/hr
(~NT$55,403/mo)

2、資料中心選擇

基本上我們通常都是建議選擇放置在主要的客戶群在那,就將Data Center放在最接近的地方,基本上我們通常建議放在日本的Data Center(個人建議),另外你也可以透過下列的連結測試那一個Data Center離你最近。


Microsoft Azure Speed Test
http://azurespeedtest.azurewebsites.net/

3、部署方式

在部署的方式上有多種方式可以選擇,如TFS、Git、FTP、Visual Studio等方式進行,但一般來說我們較簡單的方式就是透過Visual Studio來進行部署,但強烈建議在第一次開發完成後,請先至Azure Portal先將你的網站進行建立後,再透過Visual Studio進行部署,會是一個比較好的方式。

另外我們也可以透過FTP手動的進行網站的部署動作,相關FTP的資訊,可以透過站台上的概觀資訊查到,如下圖顯示。


4、基本參數建議設定

在基本參數設定上這是個人的經驗建議,在啟用上請特別注意我講到的部份,真的有合適才建議進行啟用的動作,不一定適合每一個站台。

4-1 一律開啟(Always On)

此設定為當網站閒置時,系統會將資源嘗試釋放(回收),藉以降低使用率,但當有使用者再發出請求時,會因為進行初使化的動作,而造成頁面回應過慢,所以建議如果系統為持續有使用者進行訪問的話,請將此設定設定為 "開啟",藉以避免因系統初使化造成頁面回應過慢的問題,此值預設為 "關閉"。

4-2 Local Cache

實際就是將你的網站中的/site與/siteextensions的目錄進行快取設定,這樣將有助於你的網站在啟動與快取上,如果你的網站的總大小小於2GB的情況下,建議可以考慮啟用此選項。

WEBSITE_LOCAL_CACHE_OPTION = Always

設定方式:
站台 -> 設定 -> 應用程式設定


PS:更改應該程式設定時,會造成網站的重新載入,所以再請注意。

4-3 偵錯 - 遠端偵錯

遠端偵錯可以有效的幫助開發者透過遠端連線的方式與開發工具(Visual Studio)進行直接除錯的動作,但此選項建議非必要千萬不要在正式環境中啟用,因為可能造成網站被鎖定等待遠端開發工具進行逐步除錯,所以請千萬要注意。

請關閉此選項

4-4 ARR 同質性(ARRAffinity)

此值預設的情況下是開啟的,主要是識別每一個連線的使用者,並且將其導向相同的主機上,但如果你有啟用多個Instance時,有可能會發現許多的使用者都在同一個Instance上,
啟用這個值之後,可以有效的將使用者的訪問平均的分佈在多個Instance上,但要特別注意由於導向不同台,所以可能會有Session Loss的問題,這個問題在啟用前建議先行處理。


4-5 平台(Platform)

平台的部份可以設定成32位元或64位元,基本上在一般Visual Studio上編譯都會以AnyCPU的方式進行,也就是可以在不同的平台(x86、x64、ARM)上執行,但基本上二者間有一些不同的差異,個人看法上,簡單的來說,你可以看你目前網站是否有使用超過4GB的記憶體,要不然的話,其實你可以考慮使用x86即可,而且在同一個網站透過x86與x64的平台進行執行時,載入使用的記憶體也會稍為大一點,所以不一定要選擇x64的架構進行執行,看實際上的需求而定。


此篇我們就先介紹到此,下一篇我們會再介紹一些進階的功能設定,也希望可以有效的幫到大家快速的了解此服務。

相關介紹:
建置Azure App Service for Web的建議實務 - 進階篇
http://caryhsu.blogspot.tw/2017/02/azure-app-service-for-web_25.html


參考連結:
App Service plans
https://azure.microsoft.com/en-us/pricing/details/app-service/plans//
Monitor Azure web app performance
https://docs.microsoft.com/en-us/azure/application-insights/app-insights-azure-web-apps
Microsoft Azure Speed Test
http://azurespeedtest.azurewebsites.net/
Azure App Service Local Cache overview
https://docs.microsoft.com/en-us/azure/app-service/app-service-local-cache
Disabling ARR’s Instance Affinity in Windows Azure Web Sites
https://azure.microsoft.com/zh-tw/blog/disabling-arrs-instance-affinity-in-windows-azure-web-sites/
Configure web apps in Azure App Service
https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-configure
Does your Web App really need 64-bits?
https://blog.cdemi.io/does-your-web-app-really-need-64-bits/

關鍵字:App Service for WebWeb AppsLocal CacheARRAffinityBest Practices


2017年2月15日 星期三

如何進行自訂網域與SSL憑證購買,並綁定於App Service for Web中。

此篇我們就來介紹如何在Azure Portal上進行自訂網域名稱與SSL憑證購買的動作,最後再進行SSL憑證綁定與測試。
基本上Azure在這部份也是與GoDaddy進行合作,所以在購買上不一定要透過Azure Portal進行,但為了一貫化作業,我們流程就全部透過Azure Portal進行,並將完整的流程整理如下,提供給大家進行參考。


1、購買自訂網域:
1-1 自訂網域的部份主要與WebApp綁定在一起,所以請先選擇你希望購買的WebApp站台後,選擇自訂網域 -> 購買網域。

1-2 在購買網域的部份,請確定希望購買的網域名稱,另外可以在搜尋網域的部份先行確定網域是否可以購買,最後再勾選希望購買的網域名稱即可。

1-3 建議連絡資訊一定要留正確。
1-4 填寫完資訊後,再請選擇確定即可建立起網域。

1-5 建立完成後,依照測試約經過10-15分鐘後,即可透過新購買的網址進行連線。  

1-6 購買完成後,也請確認可以正常的透過瀏覽器進行訪問新的網址,待確認後再往後續的流程。

2、購買SSL憑證:
2-1 請登入Azure Portal後,搜尋 “App Service 憑證”-> 建立
 

2-2 登入,請依序輸入下列的資訊。
  • 名稱:識別名稱,僅供識別使用
  • 裸網域主機名稱:主要綁定的網域名稱,也是你購買網域名稱時輸入的資訊。
  • 訂用帳戶:綁定的帳戶別
  • 資源群組:綁定的資源群組,可以新增群組或加入到目前現有的項目中。
  • 憑證SKU:選擇憑證的類型,二個主要差別在於當選擇W1 萬用字元時,此憑證可以使用到多個子網域中,如下列的範例。
Examples
If you request your certificate for *.coolexample.com, you can secure:

coolexample.com
www.coolexample.com
photos.coolexample.com
blog.coolexample.com

參考連結:
What is a Wildcard SSL certificate?
https://tw.godaddy.com/help/what-is-a-wildcard-ssl-certificate-567

2-3 輸入資訊完成後,請選擇下方的建立,建立憑證的時間約需要1~10分鐘不等。

     
2-4 當建立完成後,可以到你儲存SSL的資源群組中進行確認。



3、配置憑證:
憑證購買完成後,接下來就是憑證配置的動作,在Azure Portal上購買的憑證,通常我們會統一放置在Azure Key Vault中進行控管,接下來我們就來進行憑證配置的處理。

3-1 儲存憑證:
3-1-1 點選需要配置的憑證 -> 憑證組態 -> 儲存

3-1-2 選取憑證放置的位址,由於目前沒有已存在的Key Vault,所以我們新增一個進行存放。

3-1-3 輸入Key Vault的識別名稱與所在位址後,即可完成建立。

3-1-4 建立完成後,再選擇目前的憑證,藉以進行匯入的動作。

3-1-5 匯入完成後,即可看到儲存作業完成。

3-2 憑證驗證
3-2-1 一般來說此步驟有四種方式提供給我們驗證網域名稱與憑證的部份,而通常我們推薦有二個方法可以選擇:

  • App Service Verification -> 當你的網域名稱不是透過Azure Portal進行購買時,推薦使用。
  • Domain Verification -> 當你的網域名稱是透過Azure Portal進行購買時,可以直接進行驗證。

由於本篇是透過Azure Portal進行網域名稱的購買,但可惜透過Domain Verification進行時會發生錯誤,無法進行,所以本篇嘗試透過剩下的二個方法進行。

3-2-2 E-Mail驗證
基本上網頁會寫明將驗證的信件寄到你的網域名稱的主機中,如我的網域名稱為carytest-web4.biz,則信件就會寄到administrator@carytest-web4.biz中,原本以為因為我也沒有架設郵件主機,但是由於當初我在購買時有留下的主要聯絡信箱,所以郵件就會自動轉寄,所以也可以透過此方法進行。

點選下列的超連結後,即會轉向Goddy的網址並進行驗證的許可,點選Approval後,即完成驗證。





3-2-3 手動驗證
選擇手動驗證後,網頁上寫的很清楚,你可以在你的DNS主機上加入一筆TXT Record,所以我們可以透過下列的方式進行新增。

a. 此步驟請先記下 [網域驗證權杖] 的值,後續上會使用到此值。

b. 回到App Service -> 網站 -> 點選管理網域 -> 進階管理。

c. 點選後即可開啟一個外部網站,點選 Manage DNS

d. 在下列的DNS Records中加入一筆TXT Record,其中值的部份為網域驗證權杖的值,如下方顯示。

e. 我們可以透過外部網站進行DNS TXT Record的查詢,藉以確認是否DNS TXT Record是否已啟用,確認啟用完成後,即可進行後續的動作。

查詢網站:
https://mxtoolbox.com/


f. 回到憑證驗證的程序中進行驗證(步驟a),再次重新整理驗證確認後,即可看到驗證完成,而指派的部份通常系統會直接找到你對應的網域名稱設定至那一個WebAPP中,所以即會自動進行配置指派。

此時再確定憑證的狀態,你也可以看到憑證目前為準備中(Ready)


4、App Service for Web進行SSL綁定
4-1 回到App Service for Web -> 網站 -> SSL憑證 -> 匯入App Service 憑證

4-2 將剛剛配置好的憑證匯入此App Service中。

4-3 匯入完成後,即可看到此憑證的資訊,再點選新增繫結。

4-4 選擇目前的主機名稱與需要對應的憑證後,即可完成。

4-5 完成後,即可看到憑證綁定完成。

5、網站測試:
5-1 最後我們透過瀏覽器進行確認,即可看到透過HTTPS也可以正常的進行網頁的訪問。


參考知識文件:
Buy and Configure an SSL Certificate for your Azure App Service
https://docs.microsoft.com/en-us/azure/app-service-web/web-sites-purchase-ssl-web-site
Buy and Configure a custom domain name in Azure App Service
https://docs.microsoft.com/en-us/azure/app-service-web/custom-dns-web-site-buydomains-web-app
GoDaddy:主機代管, 網域名稱, 網站
https://tw.godaddy.com/

關鍵字:AzureApp Service for Web(Windows)SSL CertificateCustom Domain