黯雲端記事錄

因為 Apple 近年來把 CPU 逐漸換成 Silicon 架構，過去有些人習慣在 Mac 上使用 Windows 就會沒辦法安裝 x86/x64 版的 Windows，而微軟自家的 Surface 也有出 ARM 架構的版本，後來微軟也陸續讓一些自家軟體支援 ARM 架構的 CPU，其中也包含了開發工具 Visual Studio，從 Visual Studio 2022 17.4 版之後也正式支援 ARM CPU 了，而 Windows ARM 也內建 x86/x64 模擬，可以讓更多非 ARM 架構的程式也可以順利在上面執行，因此我也開始嘗試在 Windows 11 ARM 進行開發，而第一個遇到的問題就是在連線到 localdb 時候會導致錯誤，後面就把解決的過程稍微記錄一下。

在 Azure 上面要運行網站的應用程式，除了使用虛擬機器之外，就不能不提到 App Service 這一個 PAAS 服務了，可以很方便的部署和管理網站，因此第一個可以最佳化成本的服務就先來說明 App Service，本文就針對 App Service 計費方式和選擇建議等做介紹和說明。

在最佳化 Azure 成本之前，第一步當然是先瞭解自己的 Azure 成本組成，看到底是用了哪些服務而產生費用，這些服務是否又都是已知的費用，進而從中找出非預期而產生的費用。除了透過微軟或是購買 Azure 的提供商提供的帳單之外，在 Azure 上也提供了 Cost Management 這一個服務可以來協助我們分析這些帳務資訊，本文就來介紹此服務的基本功能。

在之前的文章「透過 Kudu API 實做 App Service WebJob 管理平台」裡透過 Kudu API 來觸發執行 WebJob ，但是在某些情境下會需要讀取參數，而且會是要每次執行的時候可以帶不一樣的參數，這樣的情境我們就不能把參數寫在 config 上，參考文件之後發現透過程式去觸發 WebJob 的時候我們可以在網址帶入參數，因此就調整了之前寫的管理平台讓它可以支援參數。

透過 App Service 上執行網站的時候，有時候可能會需要透過私有的 DNS Server 來解析特定的網址，這時候可以透過一些簡單的設定就可以完成這樣的需求，後面就來介紹兩個方式來完成這需求。

針對 App Configuration 主題還有一些在之前文章主題之外的一些補充筆記。主要有兩個補充的部分，一個是針對設定自動重新重整新設定，另一個是在「使用 App Configuration 的 Feature manager 功能來實做 Feature Toggle/Flag 機制」主要說明都是使用到內建的 Filter，如果是完全自訂的話就要另外實做自訂的 Filter 來使用。

現在在開發上逐漸強調可以持續整合 (CI) 和持續發佈 (CD)，希望工程師可以更快速的交付程式碼，因此會使用 Feature branch 的 Git 策略來開發，在開發完成之後就可以馬上合併回主分支，這時候就會需要 Feature Toggle/Flag 機制，它可以透過一個設定值來控制功能的啟用和關閉，就可以在快速交付程式碼時候先隱藏或關閉開發中的功能，等測試完成之後再打開就好，或是再配合一些 Feature Toggle 的服務來管理設定，也可以針對特定使用者或按照比例來開發功能給使用者使用，而在 Azure 上面我們可以透過 App Configuration 的其中 Feature manager 功能來實做出這樣的機制，後面我就以一些實務上可以使用的情境來介紹功能的使用。

在前面的文章「不修改程式下在 App Service 使用 App Configuration 管理參數」介紹到不修改程式的情境來套用 App Configuration，這在只有單一 App Service 時候或是沒有在其它程式也會共用參數的情境下適合，如果有同一個參數會用到多個應用程式還是建議修改程式來支援會是比較好的使用情境。另外針對參數設定上也可已設定 Lable 來區分不同的環境，本文也會介紹如何在存取的時候設定要存取的 Label。

在開發的時候一定會有機會存取陣列類型的設定值，在程式裡面通常會用複雜型別來對應這樣的設定資料，那部署到 App Service 如果要透過組態來設定陣列值的話因為沒辦法像設定 appsetting.json 那樣方便，會需要採用 key 值的方式來設定，平常又是透過強型別來存取陣列設定，反而不熟悉存取陣列 key 值的方式而卡了一下，因此筆記一下設定的方式。

前言

在開發專案的初期，除了環境設定以外，程式的參數設定會是初期需要處理的問題，不外乎是怎麼存？存哪裡？而在預設的 .NET Core 專案會是存在 appsettings.json 這一個檔案裡面，而專案越來越大或是越來越多子專案之後，就會延伸一個問題是參數的管理，可能在很多專案會用到一樣的參數，但是當這個參數要調整的時候，會需要每一個專案都記得去修改，這樣在管理上會相當的不方便，這時候就可以使用 Azure 上的 App Configuration 這一個服務來統一管理和設定參數，而最近微軟 Public Preview 一個新的功能，讓我們可以在不修改程式的情境下讓 App Service 的組態可以直接使用 App Configuration 內的參數，後面就來介紹該如何啟用這樣的功能。

前言

前幾天微軟公告 Microsoft Dev Box 這個服務進入 Public Preview，此服務建構在微軟 Windows 365 服務之上，可以讓開發人員更專注在開發上，而不用煩惱於基礎建設上，它可以讓我們自定義好專案需要的開發環境，讓開發人員可以快速的建置好一個開發環境起來，身為一個開發者和 Azure 使用者，第一時間還是來建立起來評估一下，把服務建立起來體驗一下，後面就會簡單的介紹服務的建置和使用的心得。

前言

現在開發上越來越依賴使用 NuGet 來管理套件，專案和團隊變大之後就會開始把一些共用的函示庫抽離並打包成 NuGet 套件，而這些套件屬於公司內部使用，所以就會需要有私有的 NuGet，這時候可以有兩種方案，一個是使用一個共用的資料夾或是 Azure DevOps 上的 Artifacts 來管理套件，這時候如果有設定 Azure DevOps 的 CI/CD 的話，就需要多一點設定才可以連接到這些非官方 NuGet 的外部套件來源，本文就來介紹如何設定以及需要注意的點。

前言

最近工作上需要串接 SAP，但是因為現在專案都改用 .NET Core 了，官方的 SAP Connector for Microsoft .NET 主要是支援 .NET Framework，因此就在 NuGet 上面找了幾個套件，經過測試之後，huysentruitw/SapNwRfc 這一個套件，它的使用方式我比較喜歡，而且可以支援強型別的 Model ，使用上會比較順手，另外也需要將程式部署到 App Service 執行，因此也把可能會遇到的問題記錄一下。 

前言

現在許多主流的 API 服務的驗證都是透過 OAuth 來實做，而為了安全性許多服務針對取得的 Access Token 也都會有授權的期限，因此在實做存取 API 的時候大部分人第一個卡關的點就是 OAuth 取得 Access Token，後續則是實做快取 Token 和重新取得 Access Token，而這些每一個不同的 API 服務都要再重新寫一次，實在是太費時了，我們應該把時間留給在真正呼叫 API 的時候，而不是一直花在取得授權這一段重複的工，本文就來介紹透過 API Management 來協助我們管理這些 OAoth 授權。

前言

前陣子微軟公告 App Service 基本定價層支援虛擬網路整合的功能 GA 了，這樣終於可以不用要到比較高的定價層才可以使用，可以節省不少費用，剛好實務上要設定，就開始了一連串的踩雷，最後終於找到解決的辦法，後面就來說明遇到的情境和提供一些解法。

前言

在 Azure 上面執行排程程式除了 Azure Function、Logic App 等服務以外，最方便的方式還是使用 App Service 裡面的 WebJob，它可以執行很多種類型的程式，所以我們可以簡單的開發一個 Console 程式去執行我們的排程程式，而當然也要讓它可以自動化部署，在設定上會有一些細節需要注意，所以特別針對一些設定和參數來記錄一下部署的流程。

前言

本系列的第三篇文章，這次要部署的服務就是 Azure Kubernetes Services，現在很多服務架構上都會使用上 K8S，而在 Azure 上面也提供一個受控的 K8S 服務，就是 Azure Kubernetes Services，它可以減少我們管理 K8S 的一些成本，需要更新 K8S 版本的時候也可以一鍵點選就可以升級節點的 K8S 版本，需要增加節點的時候也可以很方便的透過手動或是設定自動調整，如此一來我們就可以專注在程式的部署上就好，不用太擔心整個 K8S 叢集的維護和管理。

前言

在前一篇「使用 Azure DevOps 部署到 App Service 預備環境 (Slot) 並進行切換」介紹了將程式部署到 App Service，那另一個常見的情境則是 VM，這次就針對部署到 Azure Windows VM 來作為情境介紹。

前言

App Service 有一個很實用的功能就是預備環境 (Slot)，他可以方便我們在部署程式的時候可以先佈到預備環境，測試完成之後可以直接和正式環境進行切換 (Swap)，也可以在發現有沒測試到的嚴重問題的時候可以再切換一次，就可以快速的退到前一版的環境，那要結合 Azure Devops 的話就可以達到自動化的部署和切換，而且可以加上審核的關卡，測試完成之後審核完成就自動的進行切換，本文就來針對這樣得情境進行介紹如何完成這樣的自動化流程。

前言

在之前的文章 App Service 實做身份識別存取 KeyVault 中我們實做了使用身份識別在  App Service 中存取儲存體，而身份識別目前也在 Azure 很多服務都支援，其中一個就是常見的服務 VM，本文就來實做 VM 中的 IIS 執行的 ASP.NET 站台上使用身份識別存取儲存體。