只有累積,沒有奇蹟

顯示具有 Azure 標籤的文章。 顯示所有文章
顯示具有 Azure 標籤的文章。 顯示所有文章

2022年6月15日 星期三

[AzureDevops] 初探 Wiki 文件管理

前言
隨著團隊成員越來越多,在人員越來越多發現有些基本知識像是 Code Review 規範或是新人報到流程沒有系統化整理起來,因此需要一個知識管理平台存放相關 Domain 與流程相關文件,於是開始 suvery 知識管理平台發現在 Azure Devops Wiki 符合好管理、版控紀錄、可以使用 markdown 方式撰寫十分方便,可以做為團隊上 KM (knowledge management) 文件中心,這篇文章就來簡單介紹小小的使用心得。

建立 Wiki Project
首先在 Azure Devops 建立完 Demo Team Knowledge Management 專案,接著建立 wiki 專案,到左邊點擊 create project wiki
接著會請你建立第一個 wiki page,在這編輯視窗是可以透過 Markdown 格式輸入你整理好的資訊文件內容,接著就完成了第一頁 wiki page。

關閉 Azure Devops Service
建立完專案後,如果專案目的是專門給 Knowkedge Management 文件管理使用的話,可以考慮關閉專案中其他 Azure Devops Service 像是 Board、Pipeline、Test Plans 等服務,選單就會比較乾淨些。關閉方式可以透過到 Project setting > Azure Devops Service > Off service
關閉之後,在 Project 左方選單就僅會呈現必需的資訊 (非必要,視主管與團隊需求而定)

設定 Access level
建立完專案後,必須在設定用戶權限才可以具有訪問專案的權限,如果沒有特別設定的情況下預計權限會是 Stakeholder,可以訪問到的功能是 Azure Boards 和 Azure Pipelines 部分功能;要讓團隊成員可以編輯則要將訪問權限設定為 Basic,就可以讀取大部分的 Azure Devops 服務,詳細訪問級別權限與讀取服務可以參考 About access levels

Clone Wiki
在編輯上有兩種方式,你可以選擇直接在 Azure Devops 上直接透過畫面編輯,或是把專案直接 Clone 下來 (背後也是 Git Repo),Clone 功能可以透過專案點擊右邊會跳出 more action,接著選擇 Clone wiki 複製 Git repo 位置,再透過你熟悉的工具進行編輯的動作
Wiki Page
新增 page
可以透過下方的 new page 進行新增 wiki page 的動作,如果新增完頁面後想要新增子頁面也可以透過 add sub-page 動作新增,在 page title 部分是有限制的,wiki page 名字是不能重複(唯一性),不能與其他已存在的 wiki page name 重複;另外在 page title 上如果輸入空白的話系統預設會用 - 來取代。
如果要進行頁面的排序調整,可以透過滑鼠拖拉的方式在 Azure Devops 介面直接調整;若是使用 Git repo 則可以開啟 .order 檔案透過手動修改排序方式達到你要調整的排序。

Page 編輯
在編輯文字內容上是使用 Markdown 風格,關於 markdown 基本語法詳細說明可以參考微軟官方文件 Syntax guidance for basic Markdown usage,這裡就不在多加說明,這裡我就列出個人覺得實用的幾個功能
Table of content (TOC)
當你的內容需要標題時可以在指定位置插入 TOC,讓在閱讀時可以透過導引快速定位你要找的資訊內容,對於文件內容過長時很好用
Insert Mermaid diagram
如果文件中需要說明模組之間的互動關係,或是畫流程圖時,可能在過去都是透過軟體繪製,像是之前在部落格介紹過的 PlantUML - 在 Visual Studio Code 繪製 UML 圖,再將畫完的結果截圖貼在文件內容中。使用 Mermaid 則可以替你省下這些工作
舉例來說上述內容簡單描述 User 發送請求,透過應用程式讀取資料庫的流程,在 Mermaid 使用下列語法描述
::: mermaid
 graph LR;
 A[User] --> B[Application] --> C[Database]
:::
可以在編輯視窗中劃出所需要的流程圖,可以說是相當的方便。目前內建支援三種圖形分別是循序圖、流程圖與甘特圖,如果想了解更多細節內容可以參考官方文件 add-mermaid-diagrams-to-a-wiki-page 說明。

感想
工欲善其事,必先利其器。在過去開發或是接觸到不同的專案時,最讓人害怕的就是沒有文件說明要重新摸索,可能會花費較長的時間來整理前人留下來的祖產內容,但部分開發人員對於撰寫文件也是不熟悉的,如果可以讓撰寫文件這件事變得容易上手,就有機會達到這兩者之間的平衡。若是你的團隊也有類似的困擾時不妨可以參考 Azure Devops Wiki 的服務,讓知識文件化對團隊夥伴帶來幫助,hope it help :D

參考
Add and edit wiki pages
Syntax guidance for Markdown usage in Wiki


2022年6月4日 星期六

[Azure] App Service Diagnostics - Collect Memory Dump

前言
前兩篇分別介紹了 App Service Diagnostics 中的 Collect .Net Profiler Trace 與 Auto heal,分別都可以透過工具來蒐集雲端伺服器的緩慢問題分析與蒐集記憶體資訊,這一篇則是介紹如何 dump 目前伺服器 memory 的資料,以及有多個伺服器的時候該如何抓取特定的 Server memory data。若對於上述內容有問題或是不清楚的地方,歡迎提出來一起討論。

Collect Memory Dump
在 Azure 上提供非常多的分析工具可以協助開發人員找到應用程式的問題,應用程式出問題不管在地端的機房或是雲端上都是有可能會發生的,在過去服務還沒上到雲端時是透過一些工具,像之前黑暗大就寫過 ASP.NET CPU 飆高問題之傻瓜分析工具-DebugDiag Tools 找到應用程式 Crash 或是緩慢原因,今天要分享的是 Memory Dump 把應用程式當下的記憶體 clone 一份下來,再進行問題的盤查或是分析,另外在 Memory Dump 之前提醒事項如下
  • While collecting the memory dump, a clone of your app's process is created so the impact on the site availability is negligible.
  • Dumps are collected for the worker process (w3wp.exe) and child processes of the worker process.
  • Size of the memory dump is directly proportional to the process size, so processes consuming more memory will take longer to be dumped.
  • Your App will not be restarted as a result of collecting the memory dump.
白話來說,Memory Dump 會 Clone 當下應用程式 (w3wp.exe) Process 的資訊,花費時間多寡取決於 Process 用量多寡決定,應用程式不會被重啟。了解以上資訊後,就來看看如何在 Azure 設定 Memory Dump
Step 1 : 開啟 App Service
Step 2 : 點選左邊清單的 Diagnose and solve problems 功能
Step 3 : 在右邊框輸入 "點選 Memory Dump"
Step 4 : 選擇 Dump 下來的檔案放置的位置,如果之前沒執行過需要設定 Dump file 要存放的位置
Step 5 : 接著下一步,Mode 部分是選擇要蒐集 Dump Data 或者是除了 Dump 之外還希望進行 Memory 的分析,如果 Server 是多台機器的話,下面會列出目前的機器有哪些提供使用者選擇所要蒐集的 Instance
另外,如果之前有執行過蒐集過 Dump 的動作,下方也會列出之前手動或是自動蒐集的 Dump 檔案清單
Step 6 : 按下 Collect MemoryDump 按鈕之後,會開始蒐集應用程式的 Memory 資訊 (需等待一段時間,時間長短跟你應用程式 Memory 成正比)
Step 7 : 完成後可以看到 dump file 存放到指定的 storate account 位置,如果有勾選 Analyze Data 則會產生分機報告。
Step 10 : 點選 Report 可以看到分析 memory 的結果,打完收工 !
另外,如果是在線上環境發生緊急問題時,蒐集應用程式的 Memory dump 可以有助於我們找到問題,但其 dump 處理時間是很漫長會花費比較長的時間,勢必也會影響到處理線上問題的時間,與微軟技術支援討論建議如果遇到這狀況,可以透過 Metric Apply Splitting 找到特定的 instance,接著在 dump 時選擇該 instance 加速其 collect dump file 的時間 (又多學到一招,Azure 初學者覺得開心)。

結論
以上是簡單介紹 Azure Memory Dump 的方式,另外在微軟官方 youtube 也有影片說明如何在 App service 進行 debugging memory 的說明,有需要的朋友可以自己觀看,Hope it helps :D

2022年4月4日 星期一

[Azure] App Service Diagnostics - Auto-Heal

前言
上一篇提到了如何在 Azure 取得當下的 memory dump 資訊 App Service Diagnostics - 應用服務診斷,這一篇則是透過另外一種方式使用 Auto-heal 的方式設定 memory 達到一定的水位時,觸發自動收集 memory 的使用狀況,並在自訂的條件下抓取 memory 資料,並指定 dump file 放置在某個 storage account 帳號中。若對於上述內容有問題或是不清楚的地方,歡迎提出來一起討論

Auto-Heal
今天要分享的是透過 Auto-Heal 方式取得應用程式發生例外或是異常時,透過設定特定的行動、內存限制定義各種條件,採取什麼特定的行動方案,例如重啟應用程式、紀錄事件或是啟動另外一個可執行方案,以下就來介紹如何使用 Azure 來設定 Auto-Heal 選項
Step 1 : 開啟 App Service
Step 2 : 點選左邊清單的 Diagnose and solve problems 功能
Step 3 : 在右邊框輸入 "點選 Auto-heal"
Step 4 : Custom Auto-Heal Rules Enabled 選擇開啟 (on)
Step 5 : 在 Define Conditions 中選擇 Memory limit,並設置水位值為 (5872025),此設定值可以依據實體狀況做調整,是指以 KB 為單位的 App 占用 momory 的值
Step 6 : 在 Configure Actions 選 Custom Action,下方則選擇 Memory dump
Step 7 : Tool options 選擇 collectLogs
Step 8 : 選擇按下 Select,選擇要儲存的 storage 位置
Step 9 : 點擊儲存 Auto-heal 設定配置,此功能將自動監控應用程式的 Memory 使用情況,並在剛剛自定義的條件下取得應用程式的 Dump files

透過以上詳細的資訊,就可以發生異常問題的 dump file 上傳給微軟或者是有經驗的 SRE 團隊分析與使用;另外,如果一陣子發現 storage account 都沒有異常的 memory dump file 的話,可以試著調降 memory 水位值,這樣更有機會可以取得所需要的資訊內容,才有機會找到蛛絲馬跡再進行下一步的推斷。

結論
如果想要了解更多細節可以參考 Announcing the New Auto Healing Experience in App Service Diagnostics 以及 Azure App Service tips: Increase reliability with the Auto-Healing features 這兩篇文章內容都有詳細說明 Auto-heal 的用法與步驟,Hope it helps :D

2022年3月9日 星期三

[Azure] App Service Diagnostics - 應用服務診斷

前言
目前工作主要服務都是放在 Azure 服務上,因此接觸到 Azure 時間也越來越多,當應用程式發生問題時要如何進行診斷找到 Root cause 呢 ? 過去在地端機房上可能可以先取得執行當下的 Memory Dump 檔案,再把抓下來的 dump file 透過一些記憶體分析工具像是 DebugDiag Tools 或是 WinDBG 來分析原因,那如果今天我們使用的是雲端 Azure 的 Paas 服務該如何處理呢 ? 今天就透過這篇文章來簡單跟大家分享如何在 Azure 上取得執行當下的 Memory dump file,若對於上述內容有問題或是不清楚的地方,歡迎提出來一起討論

App Service Diagnostics
在 Azure App Service 中提供多種工具來協助開發者來針對問題做分析與排除,目前 Diagnostic Tools 分為以下幾類
  • Collect .Net Profiler Trace
  • Collect Memory Dump
  • Check Connection Strings
  • Collect Network Trace
  • Network/Connectivity Troubleshooter
今天要分享的是透過 Profile Trace 可以幫助識別 .NET 異常的 Exception Type、異常訊息資訊與 Callstack,不需要再額外安裝其他的工具,以下就來介紹如何使用 Azure 來設定 .NET Profile Trace 選項
Step 1 : 開啟 App Service
Step 2 : 點選左邊清單的 Diagnose and solve problems 功能
Step 3 : 點選 Diagnostic tools
Step 4 : 在 Diagnostic tools 中選擇 Collect .NET Profiler Traces
Step 5 : Mode 是這次目的是單純蒐集或是蒐集後進行分析,Instance 部分則可以選擇要分析的機器名稱,選擇後即可按下 Collect Profiler Trace 按鈕
Step 6 : 按下執行後會開始進行蒐集的動作,會在一分鐘後結束(有選產生報表會多一點點時間),完畢後會在下方產生分析後的報表連結
Step 7 : 開啟報表後則可以看到本次蒐集後的內容與分析結果,中間區塊則有分為五個 section,分別會是在蒐集站台的資訊期間
Slow Request,例如前100名緩慢有哪些,打到那些 endpoint,所花費的時間多久
Fail Requests : 失敗的請求清單,失敗定義 HTTP Status >= 400
Thread Callstacks
.NET Exception : 蒐集到關於 .NET 的錯誤分別有哪些

CPU Stacks : Instance CPU 使用的狀況是甚麼
透過以上詳細的資訊,就可以針對異常的問題找到可能潛在的原因是什麼,舉例來說 : 17:00 開始發現系統緩慢,平台可以使用程度下降,這時請求回應的時間是 503,後來發現是呼叫 Auth API 雍塞受到影響造成,都可以猜測的方向看找到蛛絲馬跡再進行下一步的推斷。

結論
如果想要了解關於報告的更多細節可以參考 App Service Diagnostics – Profiling an ASP.NET Web App on Azure App Service,另外 Diagnostics tools 還具備其他更多分析的功能,如果在後續有機會使用到會在分享相關心得的,Hope it helps :D

2021年12月2日 星期四

[Azure] 建立 Azure Container Registry 並整合 Microsoft Team 通知

前言
在 上一篇 介紹了使用 Azure 的 Web App For Container 服務將 Docker Image 部署至 Microsoft Azure,在 Demo 過程中 Image 是放置在公開的 Docker Hub 上,但在實務上不太可能將應用程式 Docker Image 檔案公開,如果希望可以建立私有的 Docker 服務時可以使用 Azure 中的 Container Registry 服務,建立個人/公司專用的私人 Docker 上傳空間,這篇文章就來簡單介紹建立 Azure Container Registry 服務的步驟與操作,以及上傳完成之後發送通知給 Microsoft Teams 頻道的團隊成員,若有問題或是錯誤的地方歡迎各方高手大大一起討論或給予指導。

前置作業
在開始前需先檢查電腦中是否有安裝下列軟體,才可以順利進行後續的步驟

安裝 Microsoft Teams 
Teams 是微軟在 2018 年 7 月所推出的團隊協作平台,整合 Office 365、Skype 以及 Outlook 等功能,方便團隊在線上進行溝通的工作,有提供免費版本支援 40 種語系讓有需要的企業使用,更多詳細資訊可以參考 Teams 官方介紹。在此我們的應用情境是當有人上傳 Docker image 到 Azure Container Registry 時候會主動發送通知到 Teams 的頻道中,讓團隊的成員收到上傳 image 成功的消息。

安裝 Docker For Windows
在 Windows 作業系統要操作 Docker 那麼 Docker for windows 是不可或缺的工具,安裝 Docker 與操作細節可以參考小弟之前寫的 Docker for windows 初體驗 文章介紹,安裝傳送門 : Docker Desktop for Windows

建立 Container Registry
首先第一步是要先建立 Azure Container Registry,建立方式先到 Azure Portal 首頁選擇左上方建立資源 > 容器 > Container Registry
建立新的 Container Registry 需要輸入以下資訊
  • 登錄名稱 : 名稱輸入  dockerregistrylab  
  • 資源群組 : 可以選擇建立新的資源群組
  • 位置 : 這裡選擇亞洲日本西部
  • SKU : 與計價有關,一開始如果沒特別需求先選擇基本

  • 按下建立之後,很快的完成建立新的 Container Registry 的動作,在完成頁面可以看到稍早所設定的資訊像是群組、位置、伺服器與 SKU 等設定內容,這裡我們先將登入伺服器內容複製起來稍後測試上傳時會用到
    Docker Image上傳測試
    建立完 Container Registry 之後為了確保是可以使用的,因此我們進行簡單的上傳 Docker image 測試,首先使用 admin 開啟 powershell 視窗
    首先要登入 Azure Container Registry,在稍早開啟的 powershell 中輸入  az acr login  + 伺服器名稱 來進行登入的動作 
    az acr login --name dockerregistrylab 
    回傳 Login Success 代表已登入成功,稍早提到要針對新增的 Container Registry 進行測試,因此我們可以下載 hello-world 的 Docker Image 檔在上傳到新增的 Azure Docker Server 上,先透過  docker pull  指令取得 image 檔案
    PS C:\Users\username> docker pull hello-world
    Using default tag: latest
    latest: Pulling from library/hello-world
    Digest: sha256:451ce787d12369c5df2a32c85e5a03d52cbcef6eb3586dd03075f3034f10adcd
    Status: Image is up to date for hello-world:latest
    docker.io/library/hello-world:latest 
    接著在 image 上透過  docker tag  指令加上 tag,在將 image 檔案透過  docker push  + 伺服器位置 指令將 Docker image 上傳到 dockerregistrylab 上面,其中要注意的伺服器是要輸入位置而不僅僅是名稱,在此範例中伺服器位置要輸入的值是 dockerregistry.azurecr.io ,指令操作過程如下 
    PS C:\Users\username> docker tag hello-world dockerregistrylab.azurecr.io/helloworld:v1
    PS C:\Users\username> docker push dockerregistrylab.azurecr.io/helloworld:v1  
    The push refers to repository [dockerregistrylab.azurecr.io/helloworld] 
    af0b15c8625b: Pushed
    v1: digest: sha256:92c7f9c92844bbbb5d0a101b22f7c2a7949e40f8ea90c8b3bc396879d95e899a size: 524                           PS C:\Users\marcustung> docker pull hello-world                                                                         Using default tag: latest                                                                                               latest: Pulling from library/hello-world                                                                                Digest: sha256:451ce787d12369c5df2a32c85e5a03d52cbcef6eb3586dd03075f3034f10adcd                                         Status: Image is up to date for hello-world:latest                                                                      docker.io/library/hello-world:latest                                                                                    
    PS C:\Users\username> 
    上傳完畢之後可以到 Azure Portal 介面確認上傳的檔案,可以到操作介面的左邊點選 存放庫 進行確認,可以看到稍早上傳的 helloworld Docker image 已上傳成功
    透過以上簡單的步驟,就可以在 Azure 上建立屬於自己的 Container Registry。

    整合 Teams
    一開始有提到另外一個代辦事項是當上傳 Docker image 後要發送訊息到 Teams 的頻道,告知團隊成員 image 檔案的狀態資訊,接下來在整合 Teams 發送通知將會分為以下幾個步驟
  • Teams 頻道 : 建立負責接收 ACR 訊息通知的頻道 
  • Azure Function : 當上傳成功時,接收 ACR Webhook 訊息處理後轉發給 Teams
  • ACR Webhook : 負責發送 ACR 通知的服務 

  • Teams 頻道
    首先在 Teams 中建立一個名字叫  ACR Version Notifier  的通知頻道,建立後在頻道按右鍵選擇 連接器
    連接器部分預設會以人氣指數進行排序,我們這次要接的服務是 Webhook
    接下來會需要定義 incoming webhook 連接器的名字,在此輸入  ACR webhook  ,並按下下方的建立按鈕
    在建立完成之後會有屬於此連接器的 url 位置,這是 Teams incoming webhook 負責接收訊息的 URL,這裡要複製下來等等在 Azure function 會用到
    Azure Function
    接下來動作是要建立 Azure function 服務,主要工作內容是當上傳 Docker Image 成功時,接收 ACR Webhook 所發出來的訊息轉發給 Teams,或許你會好奇為什麼不直接用 Teams 來接收 ACR Webhook 發送的通知就好,還要在特別建立 Azure Function 來做處理的動作,自己經過嘗試之後發現 Teams 在接收 incoming 的 json 內容要有 title 與 text 兩個欄位,但在 Azure webhook 發送時並未包含這兩個欄位,因此在串接上會有造成錯誤 Teams API 會回傳不接受訊息,此時可以透過在 Azure Function 上撰寫簡單的 C# 代碼進行轉換即可解決此問題。
    建立 Azure function 可以透過很多種方式來建立,這裡使用的是從 Portal 上直接建立,如果想了解其他建立方式可以參考官網說明文件 : 傳送門,在 Azure Portal 左邊 menu 選單點擊 建立資源,應用程式名稱輸入  acrnotifyteams  
    接著要新增函式,在左邊選單選擇新增函式 > 入口網站 > Webhook + API 
    建立完畢後可以看到會有新增好的 Httptrigger1 的函式,右邊是要執行的 C# Code 相關功能
    先透過簡單的測試來看稍早在 Teams 的連接器是否 work,在一開始有提到 Teams 連接器 API 使用的 json 格式需要有 title & text,因此我先使用 httpclient 發送簡單的測試訊息測試
    提醒 : httpclient.PostAsync 網址就是上一步所複製的連接器 Url


    #r "Newtonsoft.Json"
    
    using System.Net;
    using Microsoft.AspNetCore.Mvc;
    using Microsoft.Extensions.Primitives;
    using Newtonsoft.Json;
    
    public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
    {
        log.LogInformation("C# HTTP trigger function processed a request.");
    
        var client = new HttpClient();
     
        var json = "{\"title\": \"Title Test\", \"text\": \"9527 就是你的終身代號\"}";
        log.LogInformation(json);
        await client.PostAsync("https://outlook.office.com/webhook/yourteamsurl", new StringContent(json, System.Text.Encoding.UTF8, "application/json"));
         
        return (ActionResult)new OkObjectResult($"ok");
    } 
    測試後即可看到 Teams 正常收到所發送的訊息
    設定 Webhook
    接著回到 Container Registry 頁面,新增 Webhook 並在服務 url 的地方加上稍早建立 Azure function 網址
    在根據 webhook 發送的通知 json 內容調整 azure function 如下
    #r "Newtonsoft.Json"
    
    using System.Net;
    using Microsoft.AspNetCore.Mvc;
    using Microsoft.Extensions.Primitives;
    using Newtonsoft.Json;
    
    public static async Task<IActionResult> Run(HttpRequest req, ILogger log)
    {
        log.LogInformation("C# HTTP trigger function processed a request.");
        
        string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
        dynamic data = JsonConvert.DeserializeObject(requestBody);    
        string repository = data?.target.repository;
        string tag = data?.request.tag;
        
        var client = new HttpClient();
     
        var json = "{\"title\": \"Docker Image :" + repository + " pull success\", \"text\": \"" + repository + ":" + tag + "\"}";
        log.LogInformation(json);
        await client.PostAsync("https://outlook.office.com/webhook/4cbb9e75-0910-41e3-81ec-84a158988cc4@938ecd8f-754e-4e60-883d-bad2b0b26a9e/IncomingWebhook/1ab11e49ab0f4497922cef639d185223/42c59a4e-ea5b-43d8-8edb-21f3572bf85a", new StringContent(json, System.Text.Encoding.UTF8, "application/json"));
         
        return (ActionResult)new OkObjectResult($"ok");
    } 
    測試上傳 Docker Image
    在重新上傳一次 docker image,即可看到已成功通知 Teams
    格式內容可以再依據需求調整,Docker Image 上傳至 Azure Container Registry 整合 Team 宣告整合成功 :)


    Copyright © m@rcus 學習筆記 | Powered by Blogger

    Design by Anders Noren | Blogger Theme by NewBloggerThemes.com