火星蚊的地球記事

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 都能正常運作。（本日程式碼）

修改 Gitlab Pipeline & CI/CD Variable

換了 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 建立上去，檢查是不是一切正常。（本日程式碼）

今天要 import ECS 跟 CodePipeline 相關的 resource，分別把 ECS 的 resource 放到 container.tf 、CodePipeline 相關 resource 放到 codepipeline.tf 。（本日程式碼）

今天繼續 import 跟 compute 相關 resource，昨天把 .tf 拆開了，今天直接新增一個 compute.tf 來放 compute resource。（本日程式碼）

import ECR repository 後，我們要把 application 有關的 resource 全部 import、改由 terraform 管理。執行 Gitlab Runner 以及單純用來實驗的 MySQL server 的 EC2 instance 不在 import 範圍內，因為它們屬於輔助實驗才產生的 infrastructure，對 application 來說非必要，在不同環境與情境中可能會使用其他方式運行 Gitlab runner 跟 Database。

在 import 跟撰寫 terraform configuration 時，terraform 的 aws resource reference 是好夥伴，我們會在 import 需要知道 id（cloud 上真實 resource 的 identifier，不是 terraform resource id）是什麼、寫 configuration 時查閱有哪些參數可用…等等。

今天我們會先 import 跟網路有關的 resource，分別是 VPC、Subnet、Internet Gateway 以及 Route Table 相關 的 resource。（原本想一口氣把所有 resource import 進來的飛速前進，結果馬上踩到問題，只好一個個慢慢來…）

我們進到 IaC 的世界了～那…前面在 AWS 手動建立的各種 resource 怎麼辦？

有兩個選項：

1. 全部砍掉重新用 terraform 寫！

2. 把手動建立的 resource import 進 terraform

哪個比較容易呢……？

不好說。

到昨天我們建立好最基本的 Gitlab + AWS ECS 的 CI/CD 流程跟 infrastructure 了～

這時候老闆突然說：「欸那可以在另一個帳號也建一個嗎？」

請問還記得所有設定怎麼按、參數要設什麼嗎？

筆者不記得 ._./ （也沒有想要記的意思

為了不用記得各種設定，今天開始我們要進入 Infrastructure as Code 的世界啦～這 30 天我們會用的工具是 Terraform！（本日程式碼）