火星蚊的地球記事

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～

終於要開始建立 ECS service 了！今天我們的目標是讓 Laravel 成功在 ECS service 上運作～

ECS Service 簡介

ECS service 是 AWS ECS 用來執行長期運作且 stateless 的 application 的功能，我們用 Laravel 開發的 web application 就是需要長期運作的 application，不像影片轉檔之類的工作，只在需要的時候執行一次。

一個 ECS cluster 可以建立多個 ECS service，每個 ECS service 會指定一個 task definition 及希望執行的 task 數量（task desired count）。

task 的數量由ECS service scheduler 負責維持，它以我們指定的 scheduling strategy 來決定 task 要放在哪台 container instance 上（task placement）。如果有 task fail 或 stop，ECS service scheduler 會啟動新的 task 以確保 task 數量。service 的 scheduling strategy 也被稱為 service type，有 REPLICA 跟 DAEMON 兩種。

接下來我們會啟動一個 MySQL container 作為 Database，然後建立一個基本的 ECS Service 並且看到 Laravel 的歡迎畫面。

昨天我們建立了 ECS cluster 並且用 Auto Scaling Group 啟動 EC2 instance、向 ECS cluster 註冊為 Container Instance。今天我們來了解魔法作為 Container Instance 的 EC2 instance 有哪些必要的設定，然後建立 ECS Task Definition 來定義要做什麼工作。

終於要進入這 30 天的核心服務 ECS 了！

ECS 全名為 Elastic Container Service，是讓我們可以在上面執行 container 的 service，是這 30 天我們要使用的 container 服務。

完成經典的 Hello World，我們來做點正經事啦～（本日程式碼）

把「build docker image 並 push 到 ECR repository」的工作丟給 Gitlab Pipeline 做，然後我們就可以去打電動/追劇惹～