檢視緯育 2026-0528 的原始碼

本次講座系列主要探討了軟體開發與部署的演進，從傳統手動部署的挑戰，到引入 CI/CD（持續整合/持續部署）、版本控制（Git）、容器化（Docker）與雲端技術（AWS）後的現代自動化流程。講師透過實作與理論結合的方式，帶領學員完成從程式碼開發、版本控制、容器封裝、雲端部署與權限管理的完整迴圈。
系列課程首先介紹了傳統手動部署的痛點，如版本混亂、難以回溯及擴展性差，並引入 CI/CD 與 Jenkins 自動化打包流程以解決這些問題。接著，課程深入講解 Git 的核心概念與實務操作，包括分支管理、Pull Request、合併與認證方式（HTTPS Token）。<br><br>
隨著課程推進，重點轉向容器化與雲端遷移。講師指導學員撰寫 Dockerfile，將應用程式封裝成 Docker 映像檔（Image），並推送到 Docker Hub。最後，將容器化的應用程式部署到 AWS EC2 實例上，並深入探討雲端環境下的權限管理，強調應使用 IAM 角色（Role）而非寫死金鑰（Access Key）來確保 EC2 與 S3 等服務間的安全通訊。整個過程旨在建立一個標準化、自動化且安全的開發與部署流程，並培養學員的流程思維與雲端架構觀念。<br><br>

=== 軟體部署的演進與挑戰 ===
* 傳統手動部署流程與挑戰
** 流程：開發者手動打包程式碼，透過網路磁碟機或訊息通知維運人員，再由維運人員手動登入實體伺服器進行部署。
** 挑戰：
*** 版本控制脫鉤：打包與上線流程分離，易因人為失誤導致生產環境問題。
*** 擴展性不足：地端實體伺服器硬體擴充不易，缺乏彈性。
*** 回溯困難：版本出錯時，需人工找出舊版檔案重新部署，過程耗時且風險高。
* CI/CD 與雲端技術的導入
** 初步自動化 (CI)：透過 Jenkins 等工具，監控 Git 倉庫，一旦主分支有更新，便自動拉取、打包並部署程式碼，減少人為介入。
** 雲端架構：將後端伺服器從實體機遷移至雲端 EC2 實例，利用 CloudWatch 進行監控、IAM 進行權限管理、RDS 管理資料庫、Route 53 處理 DNS。雲端提供隨需擴展的彈性。
** 容器化 (Docker)：為了解決本地與雲端環境不一致的問題，引入 Docker 將應用程式及其環境封裝成 Image，實現「一次建置，到處運行」。
** 容器管理：可使用 EKS (Elastic Kubernetes Service) 等服務對容器進行管理。
=== DevOps 角色與 CI/CD 核心概念 ===
* DevOps 角色與職責
** Software Engineer (軟體工程師)：主要負責開發商業邏輯與功能。
** DevOps Engineer (DevOps工程師)：負責系統上線後的持續監控與維運，確保基礎設施穩定。
** System Architecture (SAA, 系統架構師)：負責規劃整體系統架構。
** Site Reliability Engineer (SRE, 網站可靠性工程師)：負責確保雲端平台本身的品質與可靠性。
* DevOps 流程
** 一個將開發（Dev）與維運（Ops）整合的自動化循環流程：規劃 -&gt; 編寫 -&gt; 建置 -&gt; 測試 -&gt; 發布 -&gt; 部署 -&gt; 維運 -&gt; 監控 -&gt; 回到規劃。
* CI (Continuous Integration, 持續整合)
** 核心精神是頻繁將小的程式碼變更合併到主分支，並確保主分支永遠是「可上線的版本」。每次合併前都需通過自動化測試。
* CD (Continuous Delivery/Deployment, 持續交付/部署)
** CI 流程的延伸，當 CI 階段成功後，自動化後續的部署工作。
=== Git 版本控制實務 ===
* 核心概念
** Repository (儲存庫)：專案資料夾，存放所有程式碼與版本紀錄。
** Commit (提交)：每一個版本的紀錄點（本地操作）。
** Branch (分支)：為開發新功能而開立的平行工作區，避免污染主線（main）。
** Push / Pull：將本地變更推送到遠端 / 將遠端最新變更拉回本地。
** Pull Request (PR)：開發者完成功能後，發起請求讓同事或主管審核程式碼，通過後才合併回主線。
* 實作流程
  1. git clone：從遠端（如 GitHub）複製專案到本地。
  2. git checkout -b <new-branch>：建立並切換到新的開發分支。
  3. 修改程式碼後，使用 git add . 將變更加入暫存區。
  4. git commit -m "訊息"：建立一個新的版本紀錄。
  5. git push origin <new-branch>：將新分支推送到遠端。
  6. 在 GitHub 上發起 Pull Request 進行程式碼審核。
  7. 審核通過後，執行 Merge 將程式碼合併回 main 分支。
  8. 合併後，應刪除已無用的開發分支。
* 認證方式
** GitHub 已廢除使用帳號密碼進行 HTTPS 推送的方式。
** 現在需使用 個人存取權杖 (Personal Access Token) 作為密碼進行認證。Token 僅在生成時顯示一次，需立即複製保存。
=== 容器化 (Docker) 與雲端部署 (AWS) ===
* 開發與部署完整流程 (第三次部署)
  1. 需求與權限申請：當需要開發新功能（如上傳檔案至 S3），開發人員需向雲端管理員申請對應服務（S3）的操作權限。
  2. 本地環境設定：
* 管理員為開發人員或其群組授予 IAM Policy (如 AmazonS3FullAccess)。
* 管理員為開發人員生成存取金鑰 (Access Key ID & Secret Access Key)。
* 開發人員在本地安裝 AWS CLI，並使用 aws configure 配置金鑰，使本地環境具備操作 AWS 資源的能力。
  3. 本地開發與測試：
* 開發人員撰寫串接 AWS 服務（如 S3）的應用程式程式碼。
* 安全實踐：嚴禁將金鑰寫死在程式碼中。
  4. 容器化封裝：
* 在專案中撰寫 Dockerfile。
* 使用 docker build 將應用程式封裝成 Docker Image。
* 使用 docker run 在本地啟動容器，並透過端口映射 (Port Mapping) 進行功能驗證。
  5. 推送至映像檔倉庫：將驗證通過的 Docker Image 推送到 Docker Hub。
  6. 雲端部署與權限問題：
* 在 AWS 上啟動一台 EC2 實例（如 Amazon Linux 2023）。
* EC2 實例預設沒有權限存取其他 AWS 服務。直接在 EC2 內配置金鑰是不安全且錯誤的做法。
* 正確做法：建立一個 IAM 角色 (Role)，選擇其服務對象為 EC2，並為該角色附加所需權限的 Policy（如 S3 存取權）。
* 將此 IAM 角色指派給目標 EC2 實例。
  7. 遠端測試與驗證：
* 在 EC2 上安裝 Docker。
* 從 Docker Hub 拉取 Image 並啟動容器。
* EC2 上的應用程式會自動繼承實例的 IAM 角色權限，從而能夠安全地存取 S3 等服務。
* 設定 EC2 的安全群組（防火牆），開放相應端口，即可從外部訪問並測試服務。
  8. 版本控制迴圈：遠端測試通過後，回到 GitHub 發起 Pull Request，完成程式碼審核與合併，結束一個開發週期。
[[檔案:2026-0528-01.png|800px]]