CaryHsu - 學無止盡: 2月 2017

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

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

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

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

2、快取(Cache)

在快取的部份，除了在網站的部份啟用Local Cache外，在App Service for Web中大家常用的有Redis Cache與CDN，二個是不同層級的應用，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 Web、Auto Scaling、Best 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
Free and Shared	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 Web、Web Apps、Local Cache、ARRAffinity、Best 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後，即完成驗證。