今天的主題是幫我們的 Laravel web service 加上 CDN（Content Delivery Network 或 Content Distribution Network），讓使用者可以更快取得取得服務。AWS 的 CDN 服務是 Cloudfront，是個 global 層級的服務。
之前用 ALB DNS name 連 Laravel 的時候是用 HTTP 連線，但在這時代沒有 HTTPS 大概是很難過下去(?)的，我們要在 ALB 前面加上 CDN，並且由 CDN 提供 HTTPS 的存取。這麼做可以讓從 CDN 往 cloud 內部的 network traffic 都不需要再做加解密的動作，因為已經在 cloud 內部是可以不用在傳輸時加密，稍微可以提昇 performance。
使用 Cloudfront 會需要一個 domain name，我們會以 Route 53 管理的 domain name 來實作。那～就開始吧～
到目前為止我們都只開一個 container instance 跟兩個 task，這樣雖然有兩個 task 可以分擔工作，但都只在一台 EC2 instance 上，如果這台 EC2 instance 掛掉，整個 application 就掛掉了QQ
為了有更好的 availability，在有機器甚至機房出問題時我們的 application 能維持運作，今天我們要把架構改成經典的 High Availability（HA）架構！（本日程式碼）
ECS 預設的 deployment 方式是 Rolling Update，中文稱為「滾動式更新」，是不斷將現有 container 替換成新版本 container 的機制。這個機制可以做到 zero downtime 的 deployment。
Rolling Update 需要 Load Balancer 做流量的切換：開啟新的 container 後要把流量導到新的 container，停止送 request 給舊 container 並等舊 container 消化完正在處理的 request。
等舊 container 消化 request 的過程稱為 draining（排水），draining 的時間可以在 ALB 的 target group 設定，具體要設定多少則要看實際 request 的最大時間多長。
在 rolling update 中，有兩個 ECS service 參數會影響 deployment 的過程：minimumHealthyPercent 以及 maximumPercent 。
昨天把 EC2 instance 搬進 private subnet，如果要 debug 要怎麼連進去呢？今天介紹兩種連進 EC2 instance、一種直接進 container 的方式～
最傳統(?)的方式是在 public subnet 開一台跳板機。連進跳板機後，從跳板機用 private IP address 連到 private subnet 的 EC2 instance。
我們有一台非 terraform 管理、用來當作 Gitlab runner 以及 MySQL server 的 EC2 instance 放在 public subnet，它就可以當作跳板機使用。
這個做法要注意 EC2 instance 的 security group 要打開從 VPC 網段連 SSH 的 inbound rule，以及要把 ssh 連線用的 key pair 放進跳板機。
VPC 的 subnet 簡單分成兩種：
到目前為止我們都只有 public subnet，無論是跑 container 的 EC2 instance 還是 Gitlab Runner，都是在 public subnet 上、有 public IP address、可以直接 access internet。一開始把 EC2 instance 放在 public subnet 可以讓網路環境比較單純、讓我們比較容易找問題，不會 container 開不起來要 debug 的時候光是連進 EC2 instance 就被網路搞得頭昏眼花。現在 ECS service 可以正常運作了，我們要把 container instance 們移到 private subnet，讓 EC2 instance 們更安全。（本日程式碼）
Laravel 有 log 記錄各種錯誤、發生的事情以及開發、debug 需要的訊息，這些 log 在 Laravel 執行在 container 內後都存在 container 內。如果執行在 AWS 的 Laravel 需要 log 資訊來 debug，在開著多台 container 的情況下要連進 container 找到出錯的 log 相當費時費力，而且 container 可能因為 deploy 等因素被關閉，寶貴的 log 可能就這麼隨風而逝……所以我們希望把 log 放在一個比較好查詢及保存的地方，在 AWS 裡就是使用 CloudWatch 這個服務。（本日程式碼）
CloudWatch 是 AWS 提供監控功能的服務，可以收集 log、監控各種服務與系統狀況以及在某些條件下做一些反應。今天要使用收集 log 的部分，我們會收集 container 執行的 log 以及 Laravel application 層的 log。
CloudWatch 收集、儲存 log 的地方稱為 log group，每個 log group 裡會有一到多個 log stream，每個 log stream 分別來自不同來源，像是不同 EC2 instance。
Day 13 講到 Terraform 會把 resource 狀態 state 存在 backend 裡，到目前為止我們的 backend 都是 local 檔案：
terraform.tfstate ：記錄 remote resource state 的檔案
terraform.tfstate.backup ：上述檔案的備份檔，有時候非正常中斷 apply 操作會導致 state file 整個被清空，可以用備份檔救回來
看過 terraform.tfstate 檔案內容的朋友應該知道它就是個文字檔、記錄著所有 terraform 管理的 resource 的資訊，其中包含 credential，例如 IAM user 的 access key id 及 secret。沒錯，它是明碼。所以前面有說 state 檔案不建議 commit 進 git repository，不然就所有 credential 永存 git history 了……安捏母湯～
另外就算 state 檔案裡沒有 credential，以多人協作來說，也不適合使用 local 檔案存放 state。跟程式碼一樣，多人共同改同一個檔案可能會造成 conflict，state 的 conflict 跟 code 不一樣，它會對應 cloud 上真實的 resource，這 conflict 很難解啊～
基於上述原因，我們要改用 remote 且對 state 有所保護的 backend，Gitlab 有提供管理 terraform state 的功能，我們把 state 轉移到 Gitlab 上吧～
Gitlab Terraform State 透過 Terraform 的 http backend 來保存 state file。Gitlab 裡的 terraform state 有 version，我們可以用 api 取得先前版本的 state。重要的是 Gitlab 會加密 state 檔案後才保存，透過 Gitlab API 存取 state 時會自動加解密。
在首爾成功 apply resource 後，我們回到東京 region 對 configuration 做最後的修正。
先把之前移到別的資料夾的 state 檔案 terraform.tfstate 跟 terraform.tfstate.backup 搬回來，import 之前漏掉的 resource，然後用 terraform plan 檢查 cloud 上的 resource 跟 terraform configuration 有什麼差異、修正讓兩者一致，這樣才完成了轉移到 terraform。
昨天我們在 region ap-northeast-2 用 terraform 建立起一套 infrastructure，現在要從 Gitlab deploy Laravel web application 上去確認 web 跟 deployment 都能正常運作。（本日程式碼）
換了 region，ECR repository 的 URI 會不同，我們要修改 Gitlab CI/CD variable 的 ECR_BASE 為 xxxxxxxx.dkr.ecr.ap-northeast-2.amazonaws.com 。
還有 .gitlab-ci.yml 的這行：
1 | aws ecr get-login-password --region ap-northeast-1 | docker login --username AWS --password-stdin $ECR_BASE |
把寫死的 ap-northeast-1 改成 $AWS_DEFAULT_REGION ，然後在 CI/CD variable 設定變數值為 ap-northeast-2 。
import 完 resource 需要 resource 們是否正確及完整，否則佈建另一個環境（例如正式環境）可能才發現 configuration 是無法運作的。那要怎麼驗證呢？可以到另一個 AWS region 進行 terraform apply 把 resource 建立上去，檢查是不是一切正常。（本日程式碼）
