黑皮考町

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

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

  如何設定 WireGuard VPN Server How to Set Up a WireGuard VPN Server on Ubuntu 想要架設自己的 VPN？WireGuard 是現在最輕量、高速又安全的 VPN 協議，比 OpenVPN 和 IPSec 更簡單易用！這篇教學會手把手帶你在 Ubuntu 上安裝與設定 WireGuard 伺服器，讓你的連線更安全、且快速！🚀 💡 Step 1：更新系統 在開始之前，先確保你的系統是最新的： sudo apt update && sudo apt upgrade -y 小提醒 ：記得備份重要資料，確保系統更新不會影響到其他服務哦！📦 🛠 Step 2：安裝 WireGuard Ubuntu 20.04 以上的版本已經內建 WireGuard，直接執行安裝指令： sudo apt install wireguard -y 安裝完後，可以用這個指令確認版本： wg --version 🔑 Step 3：生成 WireGuard 金鑰 每台裝置都需要一組 私鑰 (private key) 和 公鑰 (public key) 。先來生成伺服器端的密鑰： umask 077 wg genkey | tee privatekey | wg pubkey > publickey 接著把這些密鑰放到安全的位置： sudo mv privatekey /etc/wireguard/server_private.key sudo mv publickey /etc/wireguard/server_public.key sudo chmod 600 /etc/wireguard/server_private.key 📄 Step 4：設定 WireGuard 伺服器 現在來建立 WireGuard 設定檔 ： sudo nano /etc/wireguard/wg0.conf 輸入以下內容： [Interface] Address = 10.0.0.1/24 SaveConfig = true PrivateKey = <server_private_key> ListenPort = 51820 # 啟用 IP 轉發...

  在 Ubuntu 設置 WireGuard Client Setting Up a WireGuard Client on Debian/Ubuntu 想讓你的網路變得更安全、更隱私，WireGuard 就是你的好夥伴！這是一款超高效、超簡單的 VPN 協議，不但安全性強，而且性能優異。這篇文章將會示範如何在 Debian/Ubuntu 系統上安裝並配置 WireGuard Client。 第一步：安裝 WireGuard 首先，更新軟體包列表並安裝 WireGuard，執行以下命令： sudo apt update sudo apt install wireguard 第二步：生成 WireGuard 密鑰 WireGuard 需要一對加密密鑰來確保安全通信。執行以下命令來生成密鑰： cd /etc/wireguard/ wg genkey | tee privatekey | wg pubkey > publickey 第三步：配置 WireGuard 客戶端 在 /etc/wireguard/ 目錄下建立 my-client.conf 配置檔，並填入以下內容： 範例配置： [Interface] PrivateKey = <您的私鑰> Address = <WireGuard 伺服器分配的 IP，例如 10.13.0.105/32> DNS = <可選，指定 DNS 伺服器，例如 8.8.8.8> [Peer] PublicKey = <WireGuard 伺服器的公鑰，例如 utrkMw+tobMpNfQgxa3ZnFzTjhja1XPXz4QQLllcVis=> AllowedIPs = <VPN 網段，例如 10.13.0.0/24>, <內部網段，例如 10.101.0.0/16> Endpoint = <WireGuard 伺服器的 URL 或 IP，例如 wireguard01-server.aws.test.tw:51820> PersistentKeepalive = 25 ⚠️ 注意 ：如果 Client 與伺服器位於不同網路，請確保 Endpoint 使用的是伺服器的 public  IP 。 範...

  如何在 QNAP NAS 上更新 SSL 憑證 How to Update SSL Certificates on QNAP NAS 為了提升網站或服務的安全性，定期更新 SSL 憑證至關重要。如果您在使用 QNAP NAS 作為伺服器，本文將示範如何通過腳本快速更新 SSL 憑證。 前置作業 新的 SSL 憑證與私密金鑰： 確保您已獲取新的 SSL 憑證（例如 cert.crt ）與對應的私密金鑰（例如 private.key ）。 Bash 腳本： 下方的腳本將協助您完成憑證的備份與更新。 QNAP 管理權限： 確保您有 NAS 的 admin 權限，並能使用 SSH 登入 QNAP 系統。 腳本內容 以下是用於更新 QNAP SSL 憑證的 Bash 腳本： #!/bin/bash # Variables CERT_DIR="/etc/stunnel" # 預設的憑證目錄 NEW_CERT="/path/to/new/cert.crt" # 新的憑證路徑 NEW_KEY="/path/to/new/private.key" # 新的私密金鑰路徑 BACKUP_DIR="/etc/stunnel/backup" # 備份目錄 TIMESTAMP=$(date +%Y%m%d%H%M%S) # 建立備份目錄（如果不存在） if [ ! -d "$BACKUP_DIR" ]; then mkdir -p "$BACKUP_DIR" echo "已建立備份目錄：$BACKUP_DIR" fi # 備份現有憑證與金鑰 echo "備份現有的憑證與金鑰..." cp "$CERT_DIR/stunnel.pem" "$BACKUP_DIR/stunnel.pem.bak.$TIMESTAMP" if [ $? -eq 0 ]; then echo "備份成功完成。" else echo "備份失敗，腳本結束。" exit 1 fi # 合併新的憑證...

如何在 QNAP QuTS hero 上設定共享資料夾與 NFS 存取權限 How to Set Up Shared Folders and NFS Access on QNAP QuTS Hero QNAP 的 QuTS hero 是一個強大的儲存解決方案，結合 ZFS 檔案系統，提供高效能和高可靠性的數據管理功能。如果您需要在 QuTS hero 上建立共享資料夾並啟用 NFS 存取權限，以下是完整的教學步驟，適合用於數據密集型工作負載。 步驟 1：建立共享資料夾並設定儲存屬性 首先，透過以下指令建立一個名為 test123 的共享資料夾，同時設定壓縮啟用、快速複製 (Fast Clone)、以及適合 VDI 或資料庫的 4KB 記錄大小： # 建立共享資料夾並設定儲存屬性 qcli_sharedfolder -s sharename=test123 poolID=1 \ compress=1 \ dedup=0 \ read_cache=0 \ fast_clone=1 \ sync=0 \ record_size=4 \ type=1 \ worm_type=0 \ size=107374182400 參數說明： compress=1 ：啟用壓縮以節省存儲空間。 dedup=0 ：關閉重複數據刪除以降低系統負擔。 record_size=4 ：設定 4KB 記錄大小，適合資料庫應用。 fast_clone=1 ：啟用快速複製以提升數據處理效率。 size=107374182400: 100 Gb 步驟 2：啟用並設定 NFS 存取 共享資料夾建立完成後，接下來啟用 NFS 存取，並設定所有主機 ( * ) 皆具有讀寫權限： # 啟用 NFS 存取 qcli_sharedfolder -N sharename=test123 Access=Enabled qcli_sharedfolder -U sharename=test123 userrw=guest # 為所有主機設定 NFS 權限 qcli_sharedfolder -K sharename=test123 remove_HostIP="*" qcli_sharedfolder -T sharename=test123 HostIP="*...

在 Ubuntu 20.04 上安裝 Podman Podman 是一款適用於基於 Linux 操作系統的容器引擎，可在無需 daemon 的情況下管理容器。它是一個開源工具，設計上可作為 Docker 後台的替代品，並且無需以 root 權限運行。 以下是如何在 Ubuntu 20.04 上安裝 Podman 的步驟： 1. 更新系統： sudo apt update 2. 安裝 Podman 所需的套件： sudo apt install software-properties-common uidmap 3. 添加 libcontainers 軟體庫： sudo sh -c "echo 'deb http://download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable/xUbuntu_20.04/ /' > /etc/apt/sources.list.d/devel:kubic:libcontainers:stable.list" 4. 更新系統： sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 4D64390375060A sudo apt-get update 5. 安裝 Podman： sudo apt-get install podman 6. 測試 Podman 是否安裝成功： podman version

容器執行的替代方案：Docker 之外的選擇 在現代軟體開發與部署中，容器技術是不可或缺的工具。雖然 Docker 是最廣為人知的容器工具，但它並不是唯一的選擇。根據具體使用場景或環境需求，以下幾種 Docker 替代方案可能會是更適合的選擇。 1. Podman Podman 是一個與 Docker 兼容的容器執行環境，最大的特點是它以 daemonless 的方式來運行容器。 什麼是 daemonless？ 在 Docker 的設計中，需要一個 Docker Daemon 的背景服務來管理和運行容器。這意味著每當啟動一個容器時，Docker Daemon 都會作為中介來處理指令。然而，Podman 的設計則是 "daemonless"，也就是說，Podman 不需要一個持續運行的背景服務來管理容器。 用 Docker 的做法來解釋 在 Docker 中，當執行指令（例如 docker run ）時，其實是通過 Docker CLI 向 Docker Daemon 發送請求，而 Docker Daemon 再負責實際執行容器。 在 Podman 中，執行指令（例如 podman run ）時，這些操作是直接執行的，沒有背景服務作為中介，這樣的設計減少了潛在的資源消耗和安全風險。 優點： Daemonless ： 提高安全性並減少系統資源佔用。 類似 Docker 的指令： 如果熟悉 Docker，轉換到 Podman 幾乎不需要額外學習成本（例如 podman run 替代 docker run ）。 Rootless Containers： 提供更高的安全性，適合在需要多人共享的環境下使用。 缺點： 雖然 Podman 與 Docker 兼容，但某些較為複雜的 Docker 工具（例如 Docker Compose）可能需要額外配置或工具來支援。 在某些環境下，社群資源和技術支持可能不如 Docker 豐富。 範例指令： podman run -d --name my-container nginx 2. containerd containerd 是一個輕量級的容器執行環境，直接與 Linux 核心的容器功能進行整合。它常被用作 Kubernetes 的底層容器執行工具。 優點： 與 Kubernetes 無縫整合： Kubern...