黑皮考町

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

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

  快速建立私有 GCE Instance 並整合 Cloud NAT 前言 私有 GCE Instance 能夠減少被駭客攻擊的機會,  因為在做網路配置的時候, 不會特別分派外部 IP 給這類型的 VM, 所有存取 VM 的行為都必須走內網, 但也因為沒有對外的 IP, 所以 VM 裡也沒辦法透過網際網路去下載並且使用第三方的套件 解法： 整合 Cloud NAT 透過 Cloud NAT 位址轉譯的功能, 將 VM 的內部 IP 對應到一組共用的對外 IP 使用 Terraform 建立 VPC, Subnet, GCE VM variable "project" {   default = "test"    } variable "network_name" {   default = "net-123"    } variable "subnet_name" {   default = "subnet-123"    } resource "google_compute_network" "vpc_network" {   project                 = var.project   name                    = var.network_name   auto_create_subnetworks = false } resource "google_compute_subnetwork" "vpc_subnet" {   project                 = var.project   name          = var.subnet_name   ip_cidr_range = "10.51.0.0/23...

 使用 Terraform + Slack + Cloud Function 快速建立簡易通知系統 前言 要設計一個通知系統, 一般都會需要考慮到前端, 後端, 以及後續部署維運相關的問題, 但其實想要快速建立通知系統並不難, 只要善用雲端資源, 十分鐘也能建立一個簡易的通知系統 以下示範, 如何使用 Slack 作為訊息輸出的前端, 以及整合 Cloud PubSub 和 Cloud Function 作為訊息處理的後端, 最後再以 Terraform 將所有元件的部署流程自動化, 使日後維運更加輕鬆簡易 前端 整合 Slack 時, 需要先取得 Webhook Token  有了 token 就能透過 Slack 的 API 將訊息打到指定的 Channel 中, 使用以下方式來測試 Webhook token 有沒有作用 測試 andy@host: curl -X POST --data-urlencode "payload={\"channel\": \"#etl_job\", \"username\": \"webhookbot\", \"text\": \"This is posted to # etl_job  and comes from a bot named webhookbot.\", \"icon_emoji\": \":ghost:\"}" https://hooks.slack.com/services/T02G1HSTG/AAA4M9NN095/1VDjE3453234292ZTF4IRDEv ok 後端 後端的部分會整合 Cloud PubSub 作為觸發 Cloud Function 以習訊息輸入的來源 Source Code const { IncomingWebhook } = require('@slack/webhook'); exports.handler= async (message, context) => {  const messageData = message.data    ? Buffer.from(mes...