在首爾成功 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 建立上去，檢查是不是一切正常。（本日程式碼）
今天要 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 怎麼辦？
有兩個選項：
全部砍掉重新用 terraform 寫！
把手動建立的 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。 （筆者這麼懶怎麼可能自己按
綜合前兩天的基本 ECS service 跟 load balancing，我們要來幫 ECS service 加上 load balancing 了！（本日程式碼）
