火星蚊的地球記事

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！（本日程式碼）

前面我們用 Gitlab pipeline build docker image 並且推上 ECR repository，ECS service 會用 ECR repository 內對應的 image 執行 container 提供服務。那麼有新 image 後是誰會把新 image deploy 到 ECS service 上呢？總不是要手動按吧？說好的自動化呢～？

今天我們要接上 CD 自動化的最後一塊拼圖：CodePipeline。利用 CodePipeline 在 ECR repository 有新的 image 時 trigger ECS deployment。 （筆者這麼懶怎麼可能自己按