黑皮考町

  為什麼 Azure Subnet 總是少五個 IP？ 你是否曾經在 Azure 設定 Virtual Network (VNet) 時，發現即使精心規劃了 IP 範圍，實際可用的 IP 卻比你計算的少 五個 ？這五個 IP 到底去哪了？是 Azure 偷走了嗎？ 這個問題困擾了許多雲端工程師，尤其當你的 Subnet 設計較小時，這些消失的 IP 可能會影響服務部署。 Azure 官方說法：為什麼要保留五個 IP？ 根據 Microsoft 官方文件 ，Azure 會保留 每個 Subnet 的前四個 IP 和最後一個 IP 。這些 IP 的用途如下： 第一個 IP - 網路位址 (Network Address) 這是整個 Subnet 的識別位址，不能指派給任何設備。 第二個 IP - Azure 預設閘道 (Default Gateway) 這是 Azure 內部的路由閘道，提供 Subnet 內的通訊能力。 第三個 IP - 內部 DNS 解析 Azure 會使用這個 IP 來提供內部 DNS 服務。 第四個 IP - Azure 預留位址 官方並未詳細說明用途，但可能為未來功能做準備。 最後一個 IP - Azure 內部服務專用 這個 IP 被 Azure 內部系統使用，無法指派給 VM 或其他資源。 這對 Subnet 設計有什麼影響？ 因為 Azure 會自動保留這五個 IP，所以在規劃 Subnet 時，你需要計算「實際可用的 IP」，而不是理論上的 IP 數量。例如： /29 子網路 （8 個 IP）→ 可用 IP 3 個 （8 - 5 = 3） /28 子網路 （16 個 IP）→ 可用 IP 11 個 （16 - 5 = 11） /27 子網路 （32 個 IP）→ 可用 IP 27 個 （32 - 5 = 27） 如果你的 Subnet 太小，可能會導致資源無法順利分配。例如，Kubernetes Service (AKS) 需要較多的 IP 空間，若沒有提前考量這些保留 IP，可能會導致 Pod 無法分配到可用 IP。 如何避免 IP 不足的問題？ 如果你發現 Subnet 的可用 IP 不足，可以考慮以下解決方案： 使用較大的 Subnet （如...

  Best Practices: Terraform Azure Authentication 在 Azure 上使用 Terraform 部署資源時，身份驗證是確保部署安全與順利執行的關鍵步驟。不同的環境適用不同的身份驗證方式，無論是 本地開發、CI/CD 自動化，還是 Azure 託管服務，選擇合適的方法能提升安全性與操作效率。本文將介紹常見的身份驗證方式及其最佳使用情境，幫助你在不同環境下順利完成 Terraform 部署。 1. Azure CLI 身份驗證（適用於本地開發） 對於 本地開發 ，使用 Azure CLI ( az login ) 是最簡單的方法。Terraform 會自動使用您登入的憑證。 步驟： 登入 Azure CLI ： az login （可選）設置訂閱 ID ： az account set --subscription "<SUBSCRIPTION_ID>" 正常執行 Terraform 。 優點： 簡單易用 無需管理額外的憑據 缺點： 需要手動登入 不適合 CI/CD 自動化 憑證會過期 2. Service Principal + Client Secret（適用於 CI/CD & 自動化） 對於 自動化部署 ，使用 Service Principal  搭配 Client Secret  是安全且可擴展的解決方案。 步驟： 建立 Service Principal ： az ad sp create-for-rbac --name "terraform-sp" --role="Contributor" --scopes="/subscriptions/<SUBSCRIPTION_ID>" 儲存返回的憑證（JSON 格式）： { "appId": "xxxxxxx", "password": "xxxxxxx", "tenant": "xxxxxxx" } 設置環境變數 （讓 Terraform 使用）： export AR...

如何使用 Terraform 在 Azure Flexible Server 啟用 PostgreSQL 擴充功能 簡介 Azure Database for PostgreSQL Flexible Server 提供了一個靈活的託管資料庫解決方案，可以根據需求調整效能和規模。然而，某些擴充功能（例如 pg_stat_statements 、 pgcrypto 和 pgstattuple ）預設未啟用。如果你直接嘗試使用 Terraform 創建這些擴充功能，可能會遇到權限錯誤，顯示 azure_pg_admin 用戶無法啟用這些功能。 好消息是，Microsoft 目前提供了一個 允許清單機制 ，可以手動啟用特定的擴充功能，這讓我們能夠透過 Terraform 或 CLI 來啟用這些功能，避免權限問題。 Azure 的限制與解決方案 在 Azure Database for PostgreSQL Flexible Server 中， azure_pg_admin 角色 不具備完整的 superuser 權限 ，因此某些擴充功能預設為不可用，這導致在 Terraform 配置時可能會出現權限錯誤。 目前，Azure 允許透過 azure.extensions 參數來啟用特定的擴充功能，這解決了開發人員無法自行安裝常見擴充功能的問題。我們可以使用 Terraform 或 Azure CLI 來修改這個設定。 透過 Terraform 啟用 PostgreSQL 擴充功能 要允許這些擴充功能，我們需要在 Terraform 配置 azure.extensions ，以下是具體步驟： 步驟 1：更新 Terraform 配置 在 Terraform 腳本中加入以下設定，允許指定的 PostgreSQL 擴充功能： resource "azurerm_postgresql_flexible_server_configuration" "extensions" { name = "azure.extensions" server_id = azurerm_postgresql_flexible_server.demo.id value = ...

Azure vs. AWS: 為什麼 Azure 無法指定 Subnet 的可用區 (AZ)？ 如果你是 AWS 的使用者，可能已經習慣了在建立 Subnet 時指定可用區 (Availability Zone, AZ)。但當你轉戰 Azure，可能會發現 「咦？Azure 竟然無法讓 Subnet 綁定到特定的 AZ？」 😲 這到底是為什麼？Azure 設計上有什麼不同？它的優勢又在哪裡？今天我們就來解開這個迷思！🔍 在 AWS 中，每個 Subnet 都是 「專屬於某個 AZ」 Subnet 綁定 AZ ：你建立的 Subnet 只能存在於特定的 AZ。 AZ 掛掉，影響有限 ：如果某個 AZ 出現故障，只有該 AZ 內的 Subnet 和資源會受影響，其他 AZ 依然健在！ 手動控制架構 ：你可以 手動 在不同 AZ 中建立 Subnet，來達到更細緻的可用性管理。 AWS CLI 建立 Subnet（範例） aws ec2 create-subnet \ --vpc-id vpc-12345678 \ --cidr-block 10.0.1.0/24 \ --availability-zone eu-central-1a 這樣一來，這個 Subnet 只會存在於 eu-central-1a ，所有部署在該 Subnet 的 EC2 也都會落在這個 AZ 內。 Azure：Subnets 是「Regional」而非「Zonable」 VNet（虛擬網路）是區域級的 ：Azure 的虛擬網路 (VNet) 覆蓋整個區域 ，而不是被分割成不同的 AZ。 Subnet 也是區域級的 ：Subnet 不會被限制在特定的 AZ，因此所有 AZ 都可以存取它。 可用區 (AZ) 是資源層級的設定 ：例如，你可以讓 VM 指定在哪個 AZ 內，但它仍然可以使用同一個 Subnet。 Azure CLI 建立 VMs 到不同 AZ az vm create --name VM1 --resource-group RG-WestEurope \ --image UbuntuLTS --vnet-name AppVNet \ --subnet AppSubnet \ --zone 1 az vm create --nam...

簡化 Terraform 狀態遷移：自動化匯入命令產生器 遇到的問題 狀態遷移可能非常繁瑣且容易出錯，特別是在處理複雜的 Azure 資源時。每個資源都需要特定的匯入命令和唯一的資源 ID，手動建立這些命令既耗時又容易出錯。 解決方案 以下是一個 Python 腳本，可以讀取您的 Terraform 狀態檔並自動生成所有必要的匯入命令： import json import os def read_terraform_files(state_path, code_path): try: # 檢查檔案是否存在 if not os.path.exists(state_path): raise FileNotFoundError(f"找不到狀態檔：{state_path}") if not os.path.exists(code_path): raise FileNotFoundError(f"找不到程式碼檔：{code_path}") # 讀取檔案 with open(state_path, 'r') as f: state_data = json.load(f) with open(code_path, 'r') as f: tf_code = f.read() return state_data, tf_code except json.JSONDecodeError: raise ValueError("無效的狀態檔格式") except Exception as e: raise Exception(f"讀取檔案時發生錯誤：{str(e)}") def extract_resource_ids(state_data, tf_code): import...

使用 Azure Private Link 或 VNet Service Endpoints 來建立私有 ACR 在現代雲端環境中， 安全性 是企業最關心的議題之一，尤其是當你的 Azure Container Registry (ACR) 儲存了關鍵映像檔時，你絕對不希望它暴露在公網上，成為駭客攻擊的目標。 兩種方式讓 ACR 更安全 Azure Private Link（推薦 ） - ACR 完全私有，封鎖所有公網流量，只允許內部 VNet 存取。 VNet Service Endpoints - ACR 仍有公網 IP，但僅允許來自指定 VNet 的請求。 為什麼選擇 Private ACR？ 確保 ACR 不暴露在公網上 - 預設 ACR 會有公網 IP，這是一個潛在的安全風險！ 增強安全性，阻擋外部攻擊 - 只有內部網路能存取 ACR，提高保護級別。 與 AKS 無縫整合 - 確保 Kubernetes 叢集能安全拉取映像檔。 DNS 解析更順暢 - 透過 privatelink.azurecr.io 解析內部 ACR。 🔹 選項 1：使用 Private Link（推薦 ） Private Link 讓 ACR 完全私有 ，不允許任何來自公網的存取。 步驟 1：建立 Private ACR resource "azurerm_container_registry" "acr" { name = "myprivateacr" resource_group_name = <resource_group_name> location = <resource_group_location> sku = "Premium" ad...

Azure AKS Outbound 流量最佳化 - 為什麼選擇 NAT Gateway 而不是 Load Balancer 前言 當部署 Azure Kubernetes Service (AKS) 叢集時，如何高效管理出站流量 (Outbound Traffic) 是影響系統穩定性、可擴展性和成本優化的關鍵因素。傳統上，AKS 會透過 Azure Load Balancer 來處理出站流量，但這種方式有諸多限制。因此，使用 Azure NAT Gateway 是更優秀的選擇。 為什麼 NAT Gateway 比 Load Balancer 更適合 AKS 出站流量？ 1. 避免 SNAT Port 枯竭 當使用 Azure Load Balancer 作為 AKS 的出站流量處理方式時，會透過 Source Network Address Translation (SNAT) 來分配臨時埠 (Ephemeral Ports)，但這些埠數量有限，對於高流量環境來說很容易 耗盡 (SNAT Exhaustion) 。 2. 提供固定的 Outbound IP，增強安全性 透過 NAT Gateway，AKS 叢集的所有出站流量都會透過 單一的靜態 Public IP ，使安全控管更加容易，可確保外部服務僅允許來自特定 IP 的請求。 3. 更佳的擴展性與效能 更高吞吐量： 支援高達 50 Gbps 的流量處理能力。 自動擴展： 無需手動調整，適用於動態擴展的 AKS 叢集。 4. 降低成本與簡化設定 使用 Azure Load Balancer 處理出站流量時，會產生額外的 SNAT 規則管理成本 ，且 Load Balancer 本身的收費也會隨著規模增加。相比之下， NAT Gateway 的計價方式更簡單。 Terraform 設定範例 - 如何在 AKS 上配置 NAT Gateway 1. 建立 NAT Gateway 的靜態 Public IP resource "azurerm_public_ip" "natg...

前言 Azure Function 是微軟提供的無伺服器服務(類似於AWS上的Lambda) 使開發人員無需花太多心力去維護伺服, 器部屬時也不用特別考慮環境如OS, Driver, Hotfix 等等, 只須專心於商用邏輯的設計 環境 Runtime使用Node.js 前置作業 安裝VS Code Azure Function Extension 建立開發環境 首先, 使用Azure Function Extension開一個專案,  VS Code 會根據選擇的開發語言來設置開發環境 這邊示範使用JavaScript來建立專案 選擇HTTP Trigger的範例來開發 選擇Authorization Level, 若想要完全開放給所有人使用可以選擇Anonymous 替Function命名 最後, 若選則Javascript當作開發語言的話, 工作目錄會長這樣 如何更改Authorization Level來保護API? 基本上目前支援以下三種方式: Anonymous Function Admin 若不想開放給所有人用的話, 可以將function.json裡的authLevel修改為 function   { "bindings" : [ { "authLevel" : "function" , "type" : "httpTrigger" , "direction" : "in" , "name" : "req" , "methods" : [ "get" , "post" ], "route" : ...

Title: How to use MSBuild to deploy your .NET Web Application on Azure 前言 對於開發人員來說, routine的事情能夠自動化就自動化, 比如說編譯程式, 或是發布程式等等, 這些自動化之後, 才能將更多的專注力放在程式開發上, 以下就是介紹如何使用 MSBuild 來佈署.NET Framework的程式到Azure App Service上 MSBuild 用來佈署.Net framework到Azure 上的工具, 可以透過安裝Visual Studio來獲得, 使用方式如下: MSBuild <solution的位置> /p:DeployOnBuild  /p:PublishProfile /p:Password MSBuild 需要吃一個Publish Profile才能正常運作, 以下教學將會演示如何編輯Publish Profile, 並且使用 MSBuild 來做編譯以及佈署 必要條件 需要安裝Visual Studio 需要在Azure App Service建立服務   需要取得佈署帳密(Publish Profile) 需要安裝Azure Cli az webapp deployment list-publishing-profiles --name YOUR-APP-NAME --resource-group YOUR-RESOURCE-GROUP Step 1. 下載佈署範本 $appSolutionDeploymentProfile = ".\production.pubxml" wget https://gist.githubusercontent.com/andy51002000/37a0af3fec1caf2955f109c0b583b3e3/raw/9b2105abd05a304b8ea6045fe78c8de781f4d0a2/publish.pubxml -OutFile $appSolutionDeploymentProfile Step 2. 開始來編輯Publish Profile的內容 宣告...

Title: how to set timeout in Azure Logic App 前言 對開發人員來說, Logic Apps是個非常好用的工具, 特別是有DevOps需求, 或是想做自動化的開發者來說, 可以節省許多時間寫一堆Code或是腳本去串接服務 設計Logic Apps 直接在Azure Portal上定義Action的種類, Input是什麼就好了, 底層的事情就交給Azure 來幫我們處理 比如說, 我們可以設一個排程, 每隔一段時間就發個請求去搓一下某個Service是否還活著 Timeout 在某些情況下, 我們可能不希望Action的執行時間過長, 假設我們預期最多不超過10秒, 但因為訪問的端點有可能發生異常, 造成Actionc還傻傻地等待Server的回應 這種情況我們可以設Timeout讓Logic App把超時的Action殺掉 首先, 右鍵 > 選擇Settings Step 2. 找到Timeout的欄位設定Duration 這邊要注意填入的時間要使用ISO 8601 的格式 ISO 8601的規則  P (Period) T(duration) H (Hour) M(Minute) S(Second). 如果Timeout想設20秒的話可以表示成PT20S 設定好之後選擇Done ... 接下來就可以存檔跑看看結果了 ... 結果 如果有成功跑完的話, 會出現綠色小勾勾, 但如過被Timeout的話就沒有

前言 當Pipeline要結束的時候, 通常大家都會希望系統可以自動寄信去通知相關人員, "程式已經Build好了"或是"程式已經上線了"等等 網路上可以找到的方法一般都是用Send Mail的Task去作這件事 這些方法都要設定SMTP, 而我自己試的結果是一直卡在權限以及安全性的問題使的Gmail總是拒絕我的請求 後來發現有個更簡單的方法, 就算不懂SMTP也可以的設定, 也可以做到相同的事情 就是使用Azure上的SendGrid來幫我們寄信 設定步驟如下 Step 1. 建立SendGrid 首先需要在Azure 建立一個SendGrid的資源 填入帳號密碼, 然後選擇付費方式, 基本方案是不用錢的 Step 2. 取得API Key 資源配置完成之後, 就可以點進去到以下的頁面 選擇Manage進入管理頁面後可以在Settings下方找到API Keys, 我們可以在這邊建立API Key然後再把API Key記下來 Step 3. 設定Pipeline 回到Azure DevOps頁面去設定Pipeline 在右邊的搜尋欄上敲"SendGrid" 就可以找到相關的Task並安裝, 安裝完之後就可以把他加進Pipeline 接下來就填一下API Key, 寄件對象, 內容之後就差不多了 點選上方存檔然後開始跑Pipeline

前言 最近一兩年微軟開始大力的推廣自家的DevOps工具, 可以感覺的出他們很想要搶下這塊市場, 這對開發者來說其實是件好事情, 表示我們的選擇可以更多元了, 不需要再侷限於Gitlab, Jenkins 等等 Aure Pipeline 用起來的感覺是蠻好上手的, 兩三下就能將.Net程式編譯打包然後部屬到Azure的雲上跑 以前用Gitlab作CI/CD時, 比較麻煩的是如果要Build .Net Framework的程式, 就需要特別自架runner跑在windows的機器上當作build machine, 而這台build machine還需要設定跟安裝某些套件才能讓整個自動化的流程運作起來, 光弄這些code 都不用寫了 TT 那這也是我們團隊開始接觸Azure DevOps的原因, 以下就簡單的帶各位了解一下怎麼在Azure DevOps 上建立Pipeline跑CI/CD的流程 Step 1. 建立組織 一開始Azure DevOps會要求開發者建立一個組織 Step 2. 建立專案 在組織底下我們可以建立多個專案 Step 3. 建立 Pipeline 選擇Pipelines > Builds Step 4. 設定Pipeline 選擇Source Code的來源 : 這邊示範從Gitlab伺服器上抓Code下來編譯 填入遠端倉庫的位址, 帳密 然後" 下一步 " 選擇Pipeline的範本 : 待會我們會根據這個範本作些微的調整, 讓他可以正常編譯程式最終部屬到Azure App Service上 設定與調整Pipeline範本: 這邊比較重要的部分是Azure帳號裡的訂閱ID, 以及要部屬的目標App Service 的名稱 最後按上方的" Save & Queue " 接下來Pipeline就會跑起來做事 結果 如果一切順利的話, 可以看到類似以下的結果

前言 相對以前來說, 現在要建一個LINE Bot已經變得非常簡單了, 尤其是最近微軟的Bot Service提供LINE的支援, 對使用微軟Bot Framework的開發者來說, 可以省去不少功夫去串接LINE 基本上使用Bot Framework來建立一個LINE Bot有幾個步驟 建立一個BOT 建立LINE BOT帳號 設定LINE頻道 串接LINE與Azure Bot Service 建立一個BOT 關於如何建立可以參考之前的 文章 啟用LINE的頻道 建立LINE BOT專用帳號 要開啟賴的通道首先必須要在賴的平台上替機器人建一個帳號 https://developers.line.biz/console/register/messaging-api/provider/ 建立Provider 這邊我們需要給他一個名字 選擇Message Api, 然後建立頻道 給個名字, 然後下方選擇Developer Trial Developer 跟Free最大的差別是Free沒有推送訊息的權限, 所以如果你選擇Free, 那你的Bot就相當於有耳朵但是卻沒有嘴巴 而這個問題可以透過升級為付費模式來解決 相反的Developer有嘴巴也有耳朵的權限, 但是他不能透過升級來獲得更多的權限 填入你的電子郵件後按同意, 完成後會看到你剛剛建立的賴帳號 進入賴帳號, 繼續接下來的設定 接下來我們要開始將Azure Bot Service跟賴串起來 卷軸往下滾找到～Channel Secrete 回到Azure Bot Service上, 把Channel Secrete 填上去 接下來複製下面 Webhook URL , 然後再回到賴的頁面 卷軸繼續下拉到 Message Setting 這部分有四個步驟 1. 依序是設定Webhook URL, 把剛剛在Azure上複製的URL給貼上去 2. 啟動 Use Webhook 3. 取得Channel access token 4. 啟動 Allow bot to join group chats 複製在步驟...