黑皮考町

  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...

Ignore files in Git without using a .gitignore file 在日常開發中，你可能會遇到某些檔案不希望被 Git 追蹤變更，但又不想修改專案中的 .gitignore 檔案。以下我將介紹四種在 Git 中忽略文件（但不使用 .gitignore）的常見方法，並分享每種方法的適用情境與操作方式。 1. 使用 git update-index --assume-unchanged 當你希望暫時忽略某個已經在版本控制中的檔案變更時，這個命令會非常有用。執行下列指令後，Git 會假設該檔案沒有變更，即使實際上已經做了修改。 git update-index --assume-unchanged <file> 如果未來需要取消這個忽略設定，可以執行： git update-index --no-assume-unchanged <file> 這個方法適合用於那些偶爾需要修改但又不希望被提交到版本庫的檔案，例如配置檔案或環境變數文件。 2. 使用 git update-index --skip-worktree 另一個類似的命令是 --skip-worktree 。這個選項通常用於當你需要保留檔案在版本庫中的狀態，但又不希望本地修改被 Git 追蹤。這對於那些會根據個人環境做出調整的檔案尤其適用。 git update-index --skip-worktree <file> 如果想要回復檔案變更的追蹤，則使用： git update-index --no-skip-worktree <file> 與 --assume-unchanged 不同， --skip-worktree 的設計目的是忽略本地修改，特別適用於分支間共享同一份文件而本地配置有所不同的情境 3. 使用 Git Exclude (Per-Repo) 有時候你可能不想讓某些忽略規則進入版本控制，但又希望在本地專案中使用。這時候可以利用 Git 的「排除檔案」功能，把忽略規則放在 .git/info/exclude 裡面。該檔案的語法與 .gitignore 完全相同，但它只會影響當前專案，不會提交給版本庫。 步驟如下： 打開 .git/info/exclude 檔案。 添加你想...

如何使用 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...