終於來到最後一天了！好感動嗚嗚，痛苦(?)的時間總是過得特別快，又到了結束時間，最後總結細節來做個 ending :D

前一篇我們跟著小明登入、換照片、預約健身課，把前面學過的 AWS 服務串了起來

小明剛才看到預約成功，那登出再登入，照片和預約還在嗎？今天先把這段測完，再來看更新程式出了問題，怎麼換回原本能用的版本

最後也一起整理不再使用的練習資源~

小明重新登入，照片和預約還在嗎？

先用自己的測試帳號走一次前篇的流程：上傳照片、儲存個人資料

這裡沿用前篇假設的完整網站。前面的 demo-api 只有 /health、/ready，還沒有會員與預約功能

照片換好後，登出，再登入一次，看看同一張照片還會不會出現

如果只有選取照片時看得到，重新登入就消失，可能只是瀏覽器顯示了本機預覽，還沒完成上傳或儲存。要回頭看圖片有沒有進 S3、會員資料有沒有保存照片的 Key，以及 API 能不能產生新的讀取網址

接著打開「我的預約」，找剛才那一筆，例如編號 123。確認課程與時間正確，再到信箱核對同一筆預約的通知

照片和預約都讀得回來後，再去看這段測試留下的 Logs，以及前面設定的指標與通知。之後每次更新程式，也都照這樣重走一次：

功能能用，也要試試不該通過的操作

剛才我們用登入後的帳號測試，接著換成沒有登入的人，結果也要正確

例如用沒有登入狀態的請求呼叫會員資料 API，應該回 401，不應該直接拿到小明的資料。這裡要檢查的是 API 回應，只有前端把按鈕藏起來還不夠

另外幾個容易漏掉的地方，我會一起檢查：

測試時記下版本、時間和預約編號。這樣發現 123 沒收到通知，回 CloudWatch 找同一段時間的 Logs，才知道程式在哪裡失敗。要留意不要把帳密、登入 Token 或整串預簽名網址貼進公開紀錄

HTTPS 今天能開，之後憑證到期也要能續用。在 EC2 裡照 Day26 確認 Certbot 的續期排程（timer）有啟用，再跑一次 sudo certbot renew --dry-run，試試目前能不能完成續期流程。後續也要留意排程的執行結果

更新之前，先留住目前能用的版本

現在網站能用了，過幾天我們改了一個功能，要再部署新版。假設新版一上去，預約就報錯，要怎麼換回來？

這也是前面要替 Image 取不同 tag 的原因。每次都把同一個 latest 蓋掉，之後光看名稱，很難知道昨天到底跑哪一版

先回 ECR → Private registry → Repositories → 自己的 repository → Images，看 Image tags 與 Image digest。tag 是我們取的版本名稱，digest 則是辨識這份映像內容的值

看好目前用的是哪一版，再把它的 tag 和 digest 記下來。像 v2、v3 這種要保留的版本，這次搭配 ECR 的 Immutable 設定，讓同名 tag 不能再被推成另一份內容，也附上（ECR tag 不可變設定文件）

上圖是之前練習留下的版本，amd64v0.0.3 也是當時取的名稱。這次用 ARM64 主機，就要選自己為 linux/arm64 打包的版本

目前能正常使用的 Image 先保留在 ECR。如果有設定自動清理舊映像，也要確認它不會把準備退回的版本刪掉

剛才測的是完整網站的功能。接下來先拿前面做過的 demo-api 練習換版本

先準備一個已在 ECR 的新版，例如從可正常使用的 v2 改一小段回應、重新打包成 v3

在 SSH 登入 EC2 的 deployer 視窗，執行：

cd ~/demo-api-deploy
cp compose.yaml compose.before-update.yaml
nano compose.yaml

把 image: 的完整 ECR 映像名稱改成已推送的新版，其他設定保留。這份 compose.before-update.yaml 就是更新前的設定

在 nano 按 Ctrl+O、Enter 儲存，Ctrl+X 離開。接著每一步成功再往下執行：

docker compose config --quiet
docker compose pull
docker compose up -d
docker compose ps

config --quiet 先檢查 Compose 格式；pull 下載 Image

up -d 依新設定重建並在背景執行容器。ECR 登入到期時，再照 Day23 用 EC2 Role 重新登入，再執行 pull

看 docker compose ps 的狀態，等前面設定的健康檢查變成 healthy，再執行：

curl -i http://127.0.0.1:8080/health
curl -i http://127.0.0.1:8080/ready

兩個網址應該都回 HTTP 200。剛啟動時還在 starting，可以稍後再看

接著從自己的電腦測公開 HTTPS 網址，完整網站則重走照片與預約流程。單台主機重建容器時可能短暫中斷，這次練習不是零停機部署，有興趣可以看這篇（Docker Compose up 的文件~）

新版有問題，怎麼退回來？

如果新版程式不正常，且我們沒有改資料庫結構與其他設定，就在同一個 EC2 部署資料夾把原設定放回來：

cp compose.before-update.yaml compose.yaml
docker compose config --quiet
docker compose pull
docker compose up -d
docker compose ps

同樣等到 healthy，再用剛才兩個 curl 檢查 /health、/ready。這樣就是重新部署原本那份 Image，常叫做 rollback（退版）

退回以後，一樣要再測公開網址與實際功能，確認原本的問題消失。下面的 v1、v2 是舊版、新版的示意，操作時換成自己真正保留的版本：

資料出問題，備份要怎麼用？

如果不小心刪掉了預約，光把程式換回舊版，資料也不會自己出現。這時候就要找資料庫備份了

有重要資料後，可以另外安排一次還原演練。這一段先認識要檢查什麼，有備份與專用測試環境再做

先到 RDS → Databases → 自己的 DB → Maintenance & backups，往下找 Backup。下面沿用之前拍的畫面：

Automated backups: Enabled (3 Days) 表示這台 DB 啟用了自動備份，保存三天。Latest restore time 是當時最新可以還原到的時間，截圖裡的日期不會跟著你現在的資料庫更新

有備份以後，也要試過程式能不能讀到還原後的資料。RDS 從快照還原，會另外建立一台 DB instance，不會直接覆蓋原本那台，附上（RDS 從快照還原 文件）

最後，把不再使用的練習環境收好

假使你跟著這 30 天開始練習，最後還是要持續確認費用。已經練完、不打算再用，才開始清除

最容易誤會的是：按了 EC2 的 Stop，其他 AWS 服務不會一起停止

EC2 停止後，EBS 磁碟與配置給帳號的 Elastic IP 還會保留。一般自動配發的公有 IPv4 會在停止時釋放，EIP 則要自己解除關聯並釋放，兩種不太一樣哦，也附上（EC2 停止與資源保留文件）

RDS 也有自己的開關。可停止的 DB instance 暫停後仍有儲存與備份費用，而且停止滿七天會自動啟動，不能靠 Stop 一直放著不管（也附RDS 停止限制與費用）(我好囉唆(欸

S3 開了 Versioning 時，一般刪除可能只是加上「刪除標記」，舊版本還在的哦！所以清空時要把版本也列出來看，不要看到物件列表空了就以為全部刪完，附上（S3 刪除標記文件）

如果你另外試過 NAT Gateway、付費 Endpoint，也別漏掉。最後回 Billing and Cost Management，依服務與區域確認費用來源；帳務資料會延遲，清完資源後還要再回來看後續更新，最後再附上（Cost Explorer 資料更新）

好像個老媽子，但我很常都關掉才發現有額外費用在跑 XDD

30 天小結

從一開始的 Region、IAM，到網路、主機、資料庫，再把程式打包部署，我們這次先把一個網站需要的環節走過一遍了

之後遇到問題，可以依卡住的位置回來找~

我會建議拿自己熟悉的小專案再練一次，先畫出程式放哪、資料放哪、誰要連誰，再回 AWS 設定

像照片傳不上去，就先確認 API 有沒有產生網址，再看瀏覽器傳到 S3 時發生什麼事，不用一出錯就把所有服務重設一次

謝謝大家跟到這裡，我們的 AWS 雲端架構勇者之路，這次先寫到這邊勒，希望大家都會喜歡，我們明年見 :D