黑皮考町

  為什麼 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...