火星蚊的地球記事

昨天我們在 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。 （筆者這麼懶怎麼可能自己按

綜合前兩天的基本 ECS service 跟 load balancing，我們要來幫 ECS service 加上 load balancing 了！（本日程式碼）

前面我們建立了 ECS cluster 跟 service，並且用一台 EC2 instance 作為 container instance 來執行 task，最後用 EC2 instance 的 public IP address 連到 Laravel。

等等，如果只是要這樣，直接開台 EC2 instance 把 web server、php、database 裝一裝就好了吧？幹麻搞得那麼複雜？

沒錯，前面先了解如何建立 ECS cluster 跟 service，接下來我們要讓 ECS service 可以執行多個 task，並且以 load balancer 進行負載平衡、將 request 分散到多個 container 上。這麼一來，只要連到 load balancer 就能連到我們的 application 了。

今天我們先來玩玩 load balancer～