緯育 2026-0509 - 修訂歷史

Kuyohong：/* 架構演進與雲端成本 */

2026-05-10T12:56:15Z

架構演進與雲端成本

←上個修訂		於 2026年5月10日 (日) 12:56 的修訂
行 40：		行 40：
	* K8s 使動態擴展（如節慶高峰）可行；雲端採用有正反兩派，記憶體漲價與硬體採購困難推動雲端採用，但需權衡長期 TCO。		* K8s 使動態擴展（如節慶高峰）可行；雲端採用有正反兩派，記憶體漲價與硬體採購困難推動雲端採用，但需權衡長期 TCO。
	[[檔案:2026-0509-01.png\|800px]]		[[檔案:2026-0509-01.png\|800px]]
			=== 虛擬機環境設定與問題排除 ===
			* 網路連線問題排除
			** 若 Linux 無法解析 IP 位址，需編輯設定檔將 NameServer 改為 8.8.8.8 以確保能上網安裝套件。
			* 操作環境
			** 課程操作主要在 Master 節點的虛擬機中進行。
			** 建議使用 SSH（如 Windows 11 內建的「終端機」）連線至虛擬機 (192.168.122.10，帳號/密碼: Root)，因其方便複製貼上指令。
			* 指令複製貼上注意事項
			** 避免直接從 PDF 複製指令，因可能包含隱藏字元。建議從講師提供的 Slack 群組複製。
			** 從 PDF 複製貼上至 Slack 時，可能因 Slack 改版自動加入反斜線 (\\) 導致指令錯誤，需手動修正。
			=== Docker 安裝與設定 ===
			* 安裝 Docker-CE
			** 課程提供了安裝 Docker-CE (Community Edition) 的指令，建議直接安裝最新版本。
			* 修改 Docker 設定檔
			** 安裝後需編輯 Docker 設定檔，將 cgroup 驅動修改為 systemd，以符合現代 Linux 系統的管理方式。
			* 啟動、驗證與開機自啟動
			** 修改設定後，需啟動 Docker 服務。
			** 使用 docker info 指令驗證 Docker 是否成功安裝並正常運作。
			** 執行 sudo systemctl enable docker 指令，設定 Docker 服務在系統重開機後自動啟動。
			=== Docker 核心概念 ===
			* Image 與 Container
			** Image (映像檔)：建立 Container 的基礎模板，類似 VM 的虛擬磁碟檔，但更輕量。包含所有應用程式執行所需的程式碼與相依性套件。
			** Container (容器)：由 Image 啟動後在記憶體中運行的實例 (Instance)，共享主機的作業系統核心，因此啟動速度極快。預設為無狀態 (Stateless)。
			* 基本操作流程
			** 課程涵蓋 Docker 的三大階段：Build (建立)、Ship (交付/分發)、Run (執行)。
			=== Docker Image 管理 (Ship) ===
			* 列出本地 Image: docker image ls 或 docker images。
			* 從倉庫拉取 Image: docker pull [imagename]:[tag]。若未指定 tag，預設為 latest。若 docker run 時本地不存在所需 Image，會自動拉取。
			** 建議優先選擇有 Official Image 標示的官方映像檔，來源較為安全。
			* 刪除本地 Image: docker rmi [imagename]:[tag] 或 docker image rm [imagename]:[tag]。
			* 建立 Image 別名 (Tag): docker tag [sourceimage]:[tag] [newname]:[tag]。
			* 上傳 Image 至倉庫 (Push): 需先 docker login 登入倉庫，再用 docker push 上傳。企業常建立私有倉庫以加速內部部署。
			=== Docker Container 管理 (Run) ===
			* 建立與執行 Container
			** docker run [options] [imagename]：基於指定 Image 建立並啟動 Container。
			** -d 或 --detach：在背景模式執行 Container，終端機可繼續操作。
			** --name [containername]：為 Container 指定一個有意義的名稱，方便後續管理。若不指定，系統會隨機命名。
			* Container 運行模式
			** 常駐型 (Service)：持續運行的服務，如 Nginx 網站伺服器，狀態為 Up。
			** 一次性工作 (Task/Job)：執行完特定任務後即結束，類似 Cron Job，狀態變為 Exited。其返回碼 (Return Code) 為 0 代表成功，非 0 代表失敗。
			* 列出 Container
			** docker ps 或 docker container ls：列出正在運行的 (Up) Container。
			** docker ps -a：列出所有 Container，包括已停止的 (Exited)。
			** docker ps -aq：只列出所有 Container 的 ID。
			* 管理 Container
			** docker stop [name/id]：正常停止一個正在運行的 Container。
			** docker rm [name/id]：刪除一個已停止的 Container。
			** docker rm -f [name/id]：強制刪除一個 Container (無論是否在運行)。
			** docker rm -f $(docker ps -aq)：一次性刪除所有 Container 的常用指令。
			* 進入 Container: docker exec -it [name/id] [command] (如 /bin/sh 或 bash)，用於進入 Container 內部進行互動式操作。
			* 查看日誌: docker logs [name/id]，對於問題排查至關重要。
			* 設定環境變數: -e 或 --env 參數，可用於傳遞設定給 Container，如資料庫密碼 (MYSQLROOTPASSWORD) 或時區 (TZ=Asia/Taipei)。
			=== 容器的數據持久化 (Volume) ===
			* 無狀態性問題：預設情況下，Container 刪除後，其內部產生的所有數據都會遺失。
			* Volume 掛載：使用 -v [主機端目錄]:[容器端目錄] 參數，將主機的目錄映射到容器內部，實現數據持久化。
			* 優勢：即使 Container 被刪除重建，只要掛載同一個主機目錄，數據就能被恢復。這是實現有狀態服務（如資料庫）與災難還原的關鍵。
			=== 容器網路模型 ===
			* Bridge 模式 (預設)
			** Docker 會建立一個虛擬橋接網卡 (docker0)，所有容器預設連接於此，並各自擁有獨立的 IP。
			** 優點：彈性高，容器間網路隔離，不會有埠口衝突。
			** Port Mapping：透過 -p [主機埠口]:[容器埠口] 將容器內部埠口映射到主機的不同埠口，使外部可以訪問。這允許在單一主機上運行多個提供相同服務的容器。
			* Host 模式
			** 容器直接共享主機的網路堆疊，不進行隔離。
			** 優點：網路效能高，無虛擬化開銷，適用於低延遲場景。
			** 缺點：缺乏彈性，容易造成埠口衝突，因為容器直接佔用主機埠口。
			* 其他模式
			** Overlay Network (SDN)：用於跨多個主機連接容器的虛擬網路，解決多主機容器間的路由問題。
			** MACVLAN：讓容器擁有獨立的 MAC 位址，效能接近實體網卡，但設定較複雜且不常用。
			=== WordPress 應用部署實作 ===
			* 應用架構：部署一個由 WordPress 前端（PHP）和 MySQL/MariaDB 後端資料庫組成的應用。
			* 部署順序：必須先啟動後端資料庫容器，再啟動前端應用程式容器。
			* 資料庫容器 (MariaDB) 部署：
			** 使用 docker run 啟動 mariadb:10.5 容器。
			** 使用 -p 3306:3306 映射資料庫埠口。
			** 使用 -v 掛載主機目錄至 /var/lib/mysql 以持久化資料庫檔案。
			** 使用 -e 設定 MYSQLROOT_PASSWORD。
			* 資料庫初始化：
			** 使用 docker exec 進入資料庫容器。
			** 登入 MySQL，並執行 SQL 指令 CREATE DATABASE wp; 來建立 WordPress 所需的資料庫。
			* WordPress 容器部署：
			** 使用 docker run 啟動 wordpress 容器。
			** 將其連接到已啟動的資料庫容器。
			** 使用 -v 掛載主機目錄以持久化 WordPress 的內容檔案（如外掛、主題、上傳檔案）。
			* 備份與還原：
			** 只需備份掛載在主機上的資料夾（資料庫檔案和 WordPress 內容）。
			** 災難發生時，在任何裝有 Docker 的主機上，將備份的資料夾放回原位，並重新執行相同的 docker run 指令，即可快速恢復整個服務。
			[[檔案:2026-0509-02.png\|800px]]

Kuyohong：建立內容為「課程路徑為先以 Docker 部署 WordPress，後續在 Kubernetes（K8s）上以同樣應用對照理解差異，並以 Infrastructure as Code（IAC）自動…」的新頁面

2026-05-10T12:53:50Z

建立內容為「課程路徑為先以 Docker 部署 WordPress，後續在 Kubernetes（K8s）上以同樣應用對照理解差異，並以 Infrastructure as Code（IAC）自動…」的新頁面

新頁面

課程路徑為先以 Docker 部署 WordPress，後續在 Kubernetes（K8s）上以同樣應用對照理解差異，並以 Infrastructure as Code（IAC）自動化佈署 K8s。實務面涵蓋 VM 與容器差異、容器鏡像（Image）與分層（Layer）、容器層讀寫、Cgroups 資源限制、存儲驅動與檔案系統、映像倉庫（Registry）安全與企業私庫、無狀態設計與持久卷（PV）、以及滾動更新（Rolling Update）在多服務相依下的應用。<br><br>
另以產業趨勢說明企業自 VMware 轉向開源虛擬化與容器，Red Hat 生態在臺灣的主流性、SUSE/Ubuntu/Debian等分支使用差異，並指出 AI 與容器使人類角色更偏向驗證（QA）。因現場多人同時更新致網路緩慢，上午先講觀念、下午再做實作，必要時可在下載階段暫停更新，避免在安裝過程中斷。

=== 課程與環境說明 ===
* 週六場地可能較吵，教學節奏視情況調整。
* 多數同學已建立三台 VM；K8s看似已裝但可能需打掉重建以跟上標準流程。
* 部署完成後三台 VM需分別執行系統更新與重啟；遇到 SSH 連線延遲常與更新未完成相關。
* 操作介面以 Linux 終端機為主，會解釋與 Windows 的差異；教材提供 EPUB 與 PDF。
=== Vagrant 與 IAC ===
* 以 Vagrant + VirtualBox 自動化建立三台 VM，符合 IAC（Infrastructure as Code）理念；建議使用課程指定版本避免相容性問題。
* Windows 需設定環境變數以便於任意目錄執行 vagrant 命令；遇到問題可重試 vagrant up 或以 vagrant destroy 重建。
* 標準 VM 拓撲示例：3 台 VM、root/root，IP 例：192.168.1.2、192.168.1.10、192.168.1.12，預設 4GB/4 核心。
=== 虛擬化（VM）與容器（Container）比較 ===
* VM 需獨立 OS，容器共用宿主機 kernel，資源開銷小、啟動更快。
* 企業因 VMware 授權成本與策略改變，逐步轉向 KVM、VirtualBox 等開源方案；商業支援（enterprise support）常作為風險保險。
* 容器鏡像（Image）標準化，提升跨環境（裸機、雲端）可攜性；容器與 VM 在隔離思維上類比但技術路徑不同。
=== 容器技術與工具 ===
* 現階段以 Docker 教學為主；後續 K8s 採用 containerd 作為容器執行時，亦會介紹 Podman 等工具與其生態差異。
* 基礎指令涵蓋容器列出、日誌檢視、映像建立等；後續以 Dockerfile 進行客製化、可重現的映像建置。
* Linux Cgroups 用於限制 CPU/I/O/記憶體等資源；一般在容器層級設定，不需直接操作底層。
* 存儲驅動與檔案系統（ext4、XFS、FAT32、NTFS、exFAT）各有特性；特定情境可用 Raw device/Device Mapper 以提升效能。
=== 映像（Image）、分層（Layer）與容器層 ===
* Image 由多個唯讀 Layer 堆疊而成；容器啟動後的寫入在容器層（於記憶體邏輯層）進行。
* 效能建議：Image 越小越好、Layer 數越少越好；AI 應用因依賴繁多，映像常數 GB、層數較多屬合理實務取捨。
* 容器啟動產生執行個體（Instance/實體）；多容器共用宿主 kernel，在多租戶高安全情境需額外安全控管。
=== 倉庫（Registry/Repository）與企業私庫 ===
* 套件倉庫（yum/apt）與映像倉庫（Registry）概念對應；公有倉庫以 Docker Hub 為代表，企業常設私有倉庫因安全與頻寬考量。
* 優先使用官方映像（Official Image）；避免下載來路不明映像，制定白名單與簽章驗證策略。
* 企業內部多環境（Dev→Staging→Prod）驗證與推進流程，避免在正式環境直接變更；內部套件/映像鏡像可顯著改善大量更新拉取速度。
=== 無狀態設計與持久卷（PV） ===
* 容器預設無狀態，重建後內部變更不保留；需以持久卷或外部掛載保存資料與設定。
* 實務策略：以映像維持環境一致性，壞掉即刪除重建；狀態資料透過外部存儲保留。
=== 作業系統生態與版本策略 ===
* 臺灣企業常用 Red Hat（RHEL）系，金融業偏好；SUSE 在金融圈也常見；Ubuntu 在臺灣多用於桌面，歐洲體系偏 Debian/SUSE。
* Red Hat 調整下游策略改為 CentOS Stream（僅 major、偏上游測試），不建議作正式環境；Rocky Linux延續下游穩定版精神。
* OS 體積從數百 MB 的精簡版（如 Alpine、CoreOS）到數 GB 的一般版不等；容器時代 OS 僅是基礎，上層容器/編排能力更關鍵。
* 開源技術迭代快速，需將重心放在應用、容器與編排能力，承接技術演進。
=== 架構演進與雲端成本 ===
* 單體架構穩定易維護但不利快速迭代；微服務/分散式能彈性擴展但維運複雜、問題定位更難。
* K8s 使動態擴展（如節慶高峰）可行；雲端採用有正反兩派，記憶體漲價與硬體採購困難推動雲端採用，但需權衡長期 TCO。
[[檔案:2026-0509-01.png|800px]]

緯育 2026-0509 - 修訂歷史

Kuyohong：​/* 架構演進與雲端成本 */

Kuyohong：​建立內容為「課程路徑為先以 Docker 部署 WordPress，後續在 Kubernetes（K8s）上以同樣應用對照理解差異，並以 Infrastructure as Code（IAC）自動…」的新頁面

Kuyohong：/* 架構演進與雲端成本 */

Kuyohong：建立內容為「課程路徑為先以 Docker 部署 WordPress，後續在 Kubernetes（K8s）上以同樣應用對照理解差異，並以 Infrastructure as Code（IAC）自動…」的新頁面