黑皮考町

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

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

使用 Nginx Ingress Controller 進行 MQTT L4 負載均衡 在 Kubernetes 中，當你希望為 MQTT (Message Queuing Telemetry Transport) 提供 L4 (Layer 4) 負載均衡 ，可以使用 Nginx Ingress Controller 來管理 TCP 流量 。由於 MQTT 運行在 TCP 層 ，並不適用於 HTTP/2，因此需要特別配置。 為什麼選擇 Nginx Ingress Controller？ 支援 TCP 負載均衡 ：可直接處理 MQTT 連線。 與 Kubernetes 無縫整合 ：利用 ConfigMap 設定 TCP 服務。 可擴展與高可用性 ：透過 Kubernetes 自動擴展。 支援 TLS 加密 ：可進行安全通訊。 步驟 1：安裝並配置 Nginx Ingress Controller 首先，請確保你的 Kubernetes 叢集 已安裝 Nginx Ingress Controller ，這可以透過 Helm Chart 來快速安裝： helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx helm repo update helm install nginx-ingress ingress-nginx/ingress-nginx \ --set controller.publishService.enabled=true \ --set tcp.1883="default/mqtt-service:1883" 步驟 2：使用 ConfigMap 配置 TCP 負載均衡 由於 MQTT 使用 TCP ，我們需要定義 ConfigMap 來讓 Nginx Ingress Controller 處理 TCP 連線 。 apiVersion: v1 kind: ConfigMap metadata: name: tcp-services namespace: ingress-nginx data: "1883...

如何從 requirements.txt 載入套件並用於 setup.py 在 Python 開發中，套件管理是專案維護的重要一環。當我們使用 setuptools 來建立 Python 套件時，通常會在 setup.py 中指定 install_requires 來管理專案的套件。 然而，當專案的套件數量較多時，直接在 setup.py 內手動列出所有套件可能不太方便。因此，我們可以將套件整理到 requirements.txt ，然後在 setup.py 內動態讀取，確保專案的套件統一且易於維護。 setup.py 是什麼？ setup.py 是 Python 套件的安裝與發佈腳本，負責定義套件名稱、版本、依賴關係，並支援打包與發佈。開發者可以透過 pip install . 安裝專案，或使用 python setup.py sdist bdist_wheel 來打包套件，甚至上傳至 PyPI 讓其他人使用。 讀取 requirements.txt 並加到 setup.py 我們可以使用以下方式，在 setup.py 內讀取 requirements.txt 內容，並將其設為 install_requires ： from setuptools import setup # 讀取 requirements.txt with open('requirements.txt') as fid: requires = [line.strip() for line in fid] setup( name="my_package", version="0.1", install_requires=requires, packages=["my_package"] ) requirements.txt 內容範例 我們的 requirements.txt 可能會長這樣： numpy>=1.21.0 pandas==1.3.5 requests numpy>=1.21.0 表示至少需要 1.21.0 版本的 NumPy。 pandas==1.3.5 限...

快速入門 Ansible Playbook：如何遠端配置與部署 WEB 服務 前言 在 DevOps 的實務應用中，Ansible Playbook 常被用來快速配置系統環境或部署 Web 服務。 其特點是使用可讀性高的 YAML 格式來描述配置指令，並透過 SSH 與每個遠端節點溝通， 因此無需在遠端主機上額外安裝代理程式。 本教學將示範如何使用 Ansible 來遠端配置與部署 Web 服務，包含環境安裝、Inventory 配置、 Playbook 編寫及常見問題排查。 1. 安裝 Ansible 相關套件 1.1 安裝 Ansible 在 Ubuntu/Debian 系統上，可以使用以下指令安裝： sudo apt update sudo apt install -y ansible 在 CentOS/RHEL 系統上，可以使用： sudo yum install -y epel-release sudo yum install -y ansible 安裝完成後，可使用以下指令確認 Ansible 是否安裝成功： ansible --version 2. 配置 Inventory 來保存遠端主機資訊 Ansible 透過 Inventory（清單） 來管理遠端主機資訊，例如 IP 位址、登入帳密及 SSH 連線設定。 2.1 設定 Inventory 編輯 Ansible 預設的 Inventory 檔案： sudo vim /etc/ansible/hosts 新增以下內容，定義目標主機群組 mywebapp ： [mywebapp:vars] ansible_port=22 ansible_ssh_user=admin ansible_ssh_pass=12345678 [mywebapp] 10.36.172.210 2.2 測試連線 使用 ansible -m ping 測試與遠端主機的連線： an...