前篇使用Azure CLI-自動刪除Azure Container Registry過期映像檔，我寫好了維護 ACR Repository 維護指令碼。我們希望能定期自動化執行這份維護指令碼（或說排程執行也行），這份指令碼有幾個麻煩的地方，一、註解第一行「First we need to login to Azure」，你必須先登入 Azure 帳號，登入之後才能執行 Azure CLI。二、因為需要登入 Azure 帳號，也就被 Azure 帳號這件事給限制住了，它就不太可能離開你的主機去別的地方做自動化。因此，在自動化之前，我們必須先解決 ACR 訪問權限的問題。
Azure Container Registry裡會儲存大量的映像檔，但其中許多都是已過期或未使用的映像檔。因此，都需要定期清理 ACR 裡的映像檔，以節省空間與成本。
我們將地端 VM 進行作業系統（OS）升級，由 Windows Server 2016 升級至 Windows Server 2022，升級之後發現，Azure Arc 裡的 MDE.Windows Extensions 有點不太正常。
備註，MDE.Windows Extension 只支援 Windows Server 2019 之後的作業系統。例如，Windows Server 2016 那麼是不會被安裝此 Extension。
就在我們完成 ExpressRoute 加入 Windows / Linux VM 的問題後，我們開始大量部屬 Azure Monitor Agent（AMA），但二天後收到 DBA 的通知，說我們安裝 Azure Monitor Agent（AMA）之後，不斷有程式在嘗式新增 SQLArcExtensionServerRole 角色進資料庫。
前篇（07）（08）提到，不論在 Windows 或 Linux 之下，我們最終都會碰到 AZCM0026: Network Error 錯誤，從錯誤訊息及測試得知 agentserviceapi.guestconfiguration.azure.com 這個端點無法正常連線。
PS C:\> & "$env:ProgramW6432\AzureConnectedMachineAgent\azcmagent.exe" connect --service-principal-id "$ServicePrincipalId" --service-principal-secret "$ServicePrincipalClientSecret" --resource-group "$env:RESOURCE_GROUP" --tenant-id "$env:TENANT_ID" --location "$env:LOCATION" --subscription-id "$env:SUBSCRIPTION_ID" --cloud "$env:CLOUD" --correlation-id "$env:CORRELATION_ID";
INFO Connecting machine to Azure... This might take a few minutes.
INFO Testing connectivity to endpoints that are needed to connect to Azure... This might take a few minutes.
INFO Exit Code: AZCM0026: Network Error
INFO For troubleshooting, see https://aka.ms/arc/azcmerror
FATAL required endpoints unavailable: https://agentserviceapi.guestconfiguration.azure.com
接續 ExpressRoute with Microsoft Peering with Windows第一次 PoC 成功之後，這裡要繼續研究如何在 Azure ExpressRoute + Microsoft Peering 環境將 Linux VM 加入 Azure Arc 管理清單。一樣分析官方提供的 Shell 指令碼，發現麻煩的一件事，以我們 Linux 環境來說明。我們採用 Ubuntu 22.04，因此 Shell 指令碼協助設定 APT 的下載點，然後，透過 APT 來進行安裝 azcmagent 套件。
我們公司是混合雲架構，採用 Azure ExpressRoute 來進行「地與雲之間安全的連線」，這在此 Blog 提到多次。
從圖來看，Azure ExpressRoute 本身還有兩種選擇，採用 Microsoft Peering 與 Private Peering，差異細節不是這裡的重點，就先跳過。簡單以安全性來說，Microsoft Peering 安全性高於 Private Peering，因此我們選擇 Microsoft Peering 線路架構來實踐。你可以把 Microsoft Peering 想成一個完全黑箱，中間的線路沒有第三者碰得到，而且能存取內容也僅是微軟官方的雲服務（Microsoft 365、Azure Public Service等），A 存取 B 服務，僅此而已，沒了。
前面，我們花了很多功夫進行各類型的 Azure Arc 整合的 PoC。但進入到企業實際內部發現，原本來 PoC 無法實行。以「如何在Azure Arc加入多台地端VM伺服器」為例，它為 Windows 提供的 PowerShell ，我們在跑安裝指令碼的過程是會去下載外部資源。
想要學習如何將地端 Kubernets 叢集加入 Azure Arc，並且利用 Azure Monitor 來監控地端 Kubernets 叢集。架設地端 Kubernets 叢集對我來說已經沒什麼難度了。但對於入門介紹，總不能說，我們要先架個三台地端 Kubernets 叢集，才能開始進入主題吧。借此機會，跟大家介紹一下 Kind 這套架設與測試 Kubernets 叢集的利器。
有了前面把地端 VM 加入 Azure Arc 及地端 VM 安裝 Azure Monitor Agetn 的經驗，接下來我們要挑戰把地端的 SQL Server 也加入到 Azure Arc 清單中。
實作環境：
前篇，我們先把地端安裝 Azure Monitor Agent 的前置環境給準備好。接下來我們要安裝 Azure Monitor Agent。
我們使用 Azure Log Analytics agent（Microsoft Monitoring Agent (MMA)） 來收集監控地端 VM 多年，但從 2023 年初開始，不斷看到 Azure 文件或系統上提示 MMA 在2024年8月31日將不再受到支援。近來地端有申請新的 VM，因此規劃新的 VM 改用Manage Azure Monitor Agent，並且熟悉了解整個設定及升級流程。
我們映像檔（images）是儲存在ACR（Azure Registry Container），在ACR有提供 Microsoft Defender 能提供我們映像檔（images）的安全性報告。
Azure Container Registry 最近 GA 了一個 Artifact Cache 功能，我測試之後，Artifact Cache 完全可以解決我們長期（困擾３－５年以上）以來在混合雲環境存取外部Registry映像檔存取問題。公司有非常安全網路規劃，因此地端內網非常不易接觸外網資源，例舉來說：
a: 地端伺服器 <--> Firewall <--> MPLS <--> ACR (v) b: 地端伺服器 <--> Firewall <--> MPLS <--> hub.docker.com (x) c: 地端伺服器 <--> Firewall <--> MPLS <--> mcr.microsoft.com (x)
我知道，這個題目很奇怪。原因來自於一場週未神奇的Debug之旅。
週末我們進行系統更新，其中包含了Kubernetes叢集。測試區很正常的更新完成，但正式區有個系統，在更新之後不正常，在 kubectl看來Pod、Service都很正常，但就是會產生連線錯誤。查了好幾個小時，終於發現是核心calico-apiserver有問題，根本跟原本的Pod與Service無關。因為是Calico的問題，造成內部網路的運作不正常，心想，正式區又是核心網路，怎麼會出事呢？
我心都涼了。
上一篇，是直接透過各種 containerd CLI 來存取 Private Registry 裡的 Images。其實這只算一個 PoC，因為要先學習如何存取私有 Registry。有了之前的經驗，那麼接下來的大目標是讓 Kubernetes 的 nodes 也能存取私有 Registry。之前提到，Kubernetes 本身是使用 crictl CLI 來與 containerd 溝通。
crictl pull --creds "UserName:Password" "ImageDetail"
但我們用 Kubernetes 時不可能這樣下指令，必須透過一些其他方法。Kubernetes 本身可以吃 docker 的 config.json 組態來使用。對「docker 的 config.json 組態」有沒有很熟悉的感覺。對，在上一篇我們透過 nerdctl login 協助，它預設會把相關組態儲存下來到 /root/.docker/config.json，這不就是我們需要的嗎。
在安裝完containerD之後，有時需要直接與containerd溝通，這時就需要透過CLI，文件共介紹 ctr、nerdctl、crictl 三套 CLI，CLI 與 containerd 的關係，就像 dockerd 與 docker CLI 差不多意思。除了溝通之外，由於我們 Registry 是採用Azure Container Registry，因此另一個重點是要知道如何設定以存取預設 docker.io 以外的 Registry。
導入Docker以來，一直有個難題困擾著我。公司因資安問題，伺服器被嚴格保護在隔離區，簡單說，就是與外界網路處於隔離狀態。但Docker本身需要存取Microsoft Container Registry（早期是Docker Hub）服務來取得Base Images，但這些服務都處在雲端，而Firewall大多只能有效處理IP Based的情況下，根本無法做到安全的開放，以致於我們都是使用非常笨的離線處理方式（docker save、docker load），當Base Images需要更新時，就是個費時費力的苦力活。終於在多年之後迎來曙光。
YARP架構如下：
某一批新 VM 主機在安裝了 Microsoft Monitoring Agent(MMA)之後，出現奇怪的現像，在 Log Analytics 裡，除了 Perf (效能計數器) 項目，其他查詢都很正常。本來方向一直在 MMA 打轉，查了許久，終於找出原因：
Get-Counter -ListSet * | Sort-Object -Property CounterSetName | Format-Table -AutoSize
Get-Counter -ListSet * | Where-Object -FilterScript {$_.CounterSetName -eq "Process" -or $_.CounterSetName -eq "Memory" -or $_.CounterSetName -eq "LogicalDisk"}
當我們導入了 Azure Container Monitor 之後，取得另外一個好處，內建的 Log Analytics 提供強大的日誌分析功能。而且 Log Analytics 經過設計之後，這些數據分析的資料能輸出為儀表板(Dashboard)。我們製作了一個 Dashboard，然後放到團隊的電視上，圖中很明顯出現直線下滑的曲線，而那條線是 Memory 的可用率！連入主機查詢，又是可惡的 99% 記憶體。
一般當 Docker Host 與 Container 的越來越多時就能發現，在管理與處理 Docker Host 與 Container 因為太分散的關係(Docker Swarm / Kubernetes 本身就分散式架構)反而費時費力，在內網可以採用 Portainer 來管理，Portainer 好用是好用，但 Portainre 本身還是比較是單一個 Docker 與 Container 服務來查詢與管理，要想整合多個 Docker 資訊時，它就比較使不上力了。在嘗試使用 Container Monitoring solution 之後，發現這真是個好服務，用個簡單實例來看看如何使 Container Monitoring 來快速進行問題定位與處理。