
在佔新作改版時，我們會希望可以先讓一部分使用者先做測試而不是將使用者一次更新。在AWS透過ELB接收網路流量到後面的Container的流量設定該怎麼做呢？
另外我們還希望可以做到如同AWS的新舊版本可以讓使用者自由的切換，這個該又如何處理這樣的需求呢？

## 什麼是金絲雀部署？

金絲雀部署的劉來是在礦工下礦坑時會先讓金絲雀飛進礦坑中，倘若金絲雀沒有了叫聲，表示礦坑底下的瓦斯濃度或是其他氣體濃度太高，礦工下礦坑就會有生命危險。
金絲雀部署也有其他名稱如：礦工部署與灰度部署

## 系統架構配置

當使用者進入系統時，有90%的流量進入了`Old Version`中另外有10%的流量進入`New Version`中

![AWS system architecture](aws-dynamic-site-canary-deployment/system-architecture.png)

## Load balancer的設定

在ELB中的設定呢分成兩個區塊，首先在主要的Rule設定上的`Forward to`中設定兩個target group，權重設定分配比例按照9:1的設定，Group-level stickiness要設定多久後要將重新做分配，就可以自動的建立金絲雀部署了

![第一個TG設定](aws-dynamic-site-canary-deployment/main-tg-setting.png)

但想要想可以自求的切換版本那只單純設定一條rule是不夠的！原因是因為Next.js的靜態檔案ex: js, css 靜態檔案的路徑是`_next/static/{BUILD_ID}`，所以要針對這樣的路徑多設定兩個不同的rule來做指向
所以ELB的設定要多一個Path的條件，match了build id 才能導向該Container，這樣每次部署只要更新相對應的路徑就可以了！

還需要再多一個設定，那就是切換舊版後需要一個條件讓使用者可以導向舊版的網站，所以這邊可以使用Query string或是Header的值來做判斷導向哪一個Target group中

> 以前實作時，Next.js產生靜態檔案的路徑是`_next/{BUILD_ID}`


在佔新作改版時，我們會希望可以先讓一部分使用者先做測試而不是將使用者一次更新。在AWS透過ELB接收網路流量到後面的Container的流量設定該怎麼做呢？ 另外我們還希望可以做到如同AWS的新舊版本可以讓使用者自由的切換，這個該又如何處理這樣的需求呢？

非靜態網站使用AWS做金絲雀部署


從黑暗時代到現代化的雲端部署與維運 July 26 @ DevOps

[投影片下載](https://cdn.adhome.com.tw/blogger/從黑暗時代到現代化的雲端部署與維運July-26@DevOps.pdf)

### 影片

[YouTube 直播回放](https://www.youtube.com/watch?v=M0Am63ehgvE&ab_channel=DevOpsTaiwan)

### 參考資料

[如何讓AWS EC2開機後就能上線](https://brunojan.net/posts/2020/12/09/ec2-provisioned-self-install)


從黑暗時代到現代化的雲端部署與維運 July 26 @ DevOps


## 寫在前面

在雲端服務一定會遇到的是機器的擴展(scale out)與縮編(scale in)的問題，如果一個AutoScaling Group觸發了機器的成長時肯定是無法靠手動
的方式來安裝機器，所以必須要透過全資動畫的方式進行，這時候我一開始的想法是在AutoScaling發生的時候觸法Jenkins的Job來安裝系統，
但這有個問題是我整個aws的服務都必須依賴在Jenkins上，後來同事指導了一個做法只需要透過AWS的設定就可以自動裝機了！

## User Data

一直以來都沒從還沒注意過AWS在建立EC2或是在Launch template介面上的`user data`，user data中的指令AWS會在我們EC2開機的過程中為我們執行
如此一來就可以不需要依賴任何一個工具就可以完成茲動畫的作業了。

![create instance 的 user data](ec2-provisioned-self-install/ec2-create-instance.png)

![launch template 的 user data](ec2-provisioned-self-install/launch-template.png)

```sh
#!/bin/bash -xe
aws s3 cp s3://{{your s3 bucket}}/main.sh main.sh --region {{your region}}
bash main.sh
```

> 在我同事的指點中，他建議在user data中不要放置帶多的指令碼而是用來下載入口指令碼與執行入口指令碼的內容就好

### main.sh

在入口腳本中一個很重要的事情是辨識機器需要安裝哪些東西以及要做哪些事情，但不太想讓user data有太多的版本避免團隊成員中複製時出錯，
所以在EC2的Tag中做了一些手腳，依照EC2 Tag的設定安裝不同的軟體

在取得EC2 Tag時其實需要先做很多事情，首先要先取得EC2 instance Id...但取的EC2 Instance Id前要先取得Region....
然後發現有個的API endpoint，這API endpoint 主要是取得主機的相關資料，然侯回傳的是一個Json的資料格式

在shell 操作Json的資料格式，不外乎就是jq這個套件了...所以我的入口腳本第一件事就是安裝jq，接下來才是去取得EC2 instance的資料

當有了instance id與region時就可以取得Tag資訊了

> EC2的Tag
> 1. Service: 設定機器主要承載的服務類型
> 2. Docker: 是否為這台機器安裝docker

```sh
#!/bin/bash -xe

exec > >(tee /var/log/user-data.log|logger -t user-data -s 2>/dev/console) 2>&1
sudo yum install -y jq
sudo apt-get install -y jq

REGION=`curl -s http://169.254.169.254/latest/dynamic/instance-identity/document | jq .region -r`
aws s3 cp s3://ec2-initial-script/functions.sh ./functions.sh --region ap-northeast-1
source ./functions.sh
log "Start setup script"

log "EC2 Instance Process" "Region:" $REGION
EC2_INSTANCE_ID=`curl -s http://169.254.169.254/latest/dynamic/instance-identity/document | jq .instanceId -r`
log "EC2 instance Id: ${EC2_INSTANCE_ID}"
TAGS="$(aws ec2 describe-tags --filter "Name=resource-id,Values=${EC2_INSTANCE_ID}" --region ${REGION})"

log "DOCKER Process"
DOCKER=`echo $TAGS | jq -r '.Tag[] | select(.Key == "Docker").Value'`
log "DOCKER Install ${DOCKER}"

if [[ "$DOCKER" == "yes" ]]; then
    log "DOCKER Install ... "
    sudo yum update -y
    sudo amazon-linux-extras install docker -y
    sudo service docker start
    sudo usermod -a -G docker ec2-user
    sudo systemctl restart docker
    log "DOCKER Install Successfully"

    log "DOCKER-COMPOSE Install ... "
    sudo curl -L "https://github.com/docker/compose/releases/download/1.25.0/docker-compose-$(uname -s)-$(uname -m)" \
              -o /usr/local/bin/docker-compose
    sudo chmod +x /usr/local/bin/docker-compose
    sudo ln -s /usr/local/bin/docker-compose /usr/bin/docker-compose
    sudo systemctl enable docker
    log "DOCKER-COMPOSE Install Successfully "
fi;

SERVICE=`echo $TAGS | jq -r '.Tag[] | select(.Key == "Service").Value'`
log "Download ${SERVICE}.sh"
aws s3 cp s3://{{s3 bucket}}/$SERVICE/install.sh /install.sh

log "Execute ${SERVICE} script"
bash install.sh "${TAGS}" "${REGION}" "${EC2_INSTANCE_ID}"

log "End scripting"
```
### install.sh

user data只負責下載與執行入口腳本在入口腳本中還要執行服務腳本，服務腳本是用來安裝application的！
在入口腳本中會用EC2的Service Tag到S3 Bucket下載對應的install.sh來安裝與設定application所需要的設定

#### ECS的安裝腳本

```sh
#!/bin/bash -xe

source ./functions.sh
TAGS=$1
REGION=$2
INSTANCE=$3

log "ECS Install ... "

ECS_CLUSTER=`echo $TAGS | jq -r '.Tag[] | select(.Key == "ECS:cluster").Value'`
sudo mkdir /etc/ecs
cat << EOF > /etc/ecs/ecs.config
ECS_DATADIR=/data
ECS_ENABLE_TASK_IAM_ROLE=true
ECS_ENABLE_TASK_IAM_ROLE_NETWORK_HOST=true
ECS_LOGFILE=/log/ecs-agent.log
ECS_AVAILABLE_LOGGING_DRIVERS=["json-file","awslogs"]
ECS_LOGLEVEL=info
ECS_CLUSTER=$ECS_CLUSTER
EOF

docker run -d --name ecs-agent \
    --detach=true \
    --restart=always \
    --volume=/var/run:/var/run \
    --volume=/var/log/ecs/:/log \
    --volume=/var/lib/ecs/data:/data \
    --volume=/etc/ecs:/etc/ecs \
    --net=host \
    --env-file=/etc/ecs/ecs.config \
    --log-driver json-file \
    --log-opt max-size=100m \
    amazon/amazon-ecs-agent:latest

log "ECS Install Successfully "
```

### 總結

使用user data可以做到系統自動化而且還不需要依賴任何的工具，不過在使用這樣的方式時需要對整個OS, shell script（如果用windows就得對powershell熟悉）
以及對aws cli有足夠的能力才有機會做出這樣的腳本，有了這樣的腳本才能做到100％的自動化。
在目前已經做到完整的自動化的部署模式，我們團隊的CI server, Staging環境每天下班後自動關機上班前會自動開機並且安裝整個application
在production的環境裡，自動化擴展時Windows的機器約莫15分鐘，Linux的機器約莫5~7分鐘就能設定完成並且服務

> 在AWS的Image中只設定了預先裝好IIS的Windows機器，此目的是為了節省安裝IIS的時間成本讓機器可以更快的上線服務減少支出
> 其他Linux的機器都只有選擇AWS Linux2的image，並沒有特別做任何設定
>
> windows的機器在AWS開機使用T3.Medium的速度一般來說都在15分鐘左右完成

### EC2 instance 的相關時間估算

| Target         | Script  | 請求機器    | 移交機器    | Provisioned | Health check | 上線時間      |
|----------------|---------|---------|---------|-------------|--------------|-----------|
| Windows Server | 3~5 min | 1.5 min | 7~9 min | 5 min       | 1.5min       | 15~22 min |
| Linux Server   | 3~5 min | 1.5 min | 5~7 min | 3 min       | 1.5min       | 9~13 min  |

## 相關連結

[JQ github page](https://stedolan.github.io/jq/)


在雲端服務一定會遇到的是機器的擴展(scale out)與縮編(scale in)的問題，如果一個AutoScaling Group觸發了機器的成長時肯定是無法靠手動 的方式來安裝機器，所以必須要透過全資動畫的方式進行，這時候我一開始的想法是在AutoScaling發生的時候觸法Jenkins的Job來安裝系統， 但這有個問題是我整個aws的服務都必須依賴在Jenkins上，後來同事指導了一個做法只需要透過AWS的設定就可以自動裝機了！

如何讓AWS EC2開機後就能上線


## 寫在前面

一直在公司使用ansible來做Cloud configuration但是ansible在cloud configuration上說真的略顯不足，
在之前的文章中我們很常使用`aws cli`來做相對應的處理。使用aws cli時要有更好的可讀性與維護性，通常都以JSON的格式輸入
因此在ansible中的playbook上就會有多餘的一些步驟去設定餵給aws cli的JSON。

這一篇就用terraform來建立一個aws AutoScaling Group吧！

## 安裝Terraform

terraform的安裝其實非常簡單，在下方的參考連結中有其他的安裝方式，我這邊主要會使用mac的安裝方式

在mac安裝terraform我是透過[Homebrew](https://brew.sh/index_zh-tw)來安裝terraform

```shell script
# For mac
brew install hashicorp/tap/terraform
```

安裝完成後做一個簡單的驗證，開啟你習慣的terminal執行以下的command就可以知道我們是不是有安裝成功了，
如果安裝成功就會出現跟下圖一樣的資訊出來，就可以進行下一步了！


```shell script
terraform -help
```

![安裝terrafrom的驗證](terraform-aws-infrastructure-as-code/terraform-install.png)

> 如果透過Homebrew安裝不成功，可以試試看brew upgrade，更新一下homebrew

因terraform最後會產生aws cli的command，在安裝完畢後需要安裝aws cli並且設定aws的一些infomation
並且設定aws的access key跟secert key的部分

```shell script
# install aws cli
brew install awscli

# configure aws setting
aws configure
```

## 初始化terraform

這一篇的目標是要用terrafrom建立aws 的auto scaling group，在達成目標前terraform前需要先做初始化

初始化其實非常容易，先在你的terraform的資料夾下先建立一個`main.tf`的黨案，定義provider

執行`init`後會有下方的資訊出現並且在資料夾中會有一個`.terraform`的資料夾

```hlc
terraform {
  required_version = ">= 0.13"
}

provider "aws"
  region = "ap-northeast-1"
}
```


```shell script
terraform init
```

![terraform init訊息](terraform-aws-infrastructure-as-code/terraform-init.png)

## 透過terrafrom 建立 AWS AutoScaling Group

接下來要建立一個`main.tf`或是使用前一步的`main.tf`，撰寫resource的設定有關於aws 的resource定義資料
可以參考下方的參考連結中的**terraform aws provider**

```hlc
resource "aws_autoscaling_group" "asg" {
  name                      = "test-autoscaling-group"
  max_size                  = 1
  min_size                  = 1
  health_check_grace_period = 300
  health_check_type         = "ELB"
  desired_capacity          = 1
  force_delete              = true
  availability_zones        = ["ap-northeast-1a", "ap-northeast-1d"]
  launch_template {
    id      = "lt-xxxxxxxx" # 使用前需要把Id置換掉
    version = "$Latest"
  }
}
```

### Apply
在terraform要真的去建立資源的command 是`apply`，在真正到aws上建立資源前會有一個預覽資料等待你的確認才會真正的建立資源

```shell script
terraform apply
```

> 如果在CI的魔是可以透過auto-approve，來略過確認輸入的情況

### Plan

如果你想先看看資源變更的情況或是dry run時可以使用`plan`來先做預覽
預覽後可以直接變更資源如下方圖片中的的文字 **terraform apply "plan"**

```shell script
terraform plan -out plan

#確認後可以執行
terraform apply "plan"
```

![terraform plan](terraform-aws-infrastructure-as-code/terraform-plan.png)

## Oops！我的Resource被修改了！

在完成第一個resource的建立後，要建立第二個autoscaling時我用了這樣的main.tf，但是出現了一些狀況...

```hlc
resource "aws_autoscaling_group" "asg" {
  name                      = "test-autoscaling-group2"
  max_size                  = 1
  min_size                  = 1
  health_check_grace_period = 300
  health_check_type         = "ELB"
  desired_capacity          = 1
  force_delete              = true
  availability_zones        = ["ap-northeast-1a", "ap-northeast-1d"]
  launch_template {
    id      = "lt-xxxxxxxx" # 使用前需要把Id置換掉
    version = "$Latest"
  }
}
```

這時候發現剛才建立的resource被刪除並重新建立了，
這個原因是因為你當下的資料夾出現了terraform.tfstate的檔案，將你剛才的資源資訊存放在此以便後續的資源管理
但...我該如何產生其他新的auto scaling group呢？

答案是使用terraform workspace的方式去建立一個新的workspace，讓每一個資源都是互相獨立的

```shell script
terraform workspace new auto-scaling-group-2
```

![terraform workspace](terraform-aws-infrastructure-as-code/terraform-workspace.png)

接下來再重新執行一次plan指令就會發現預覽的資訊上變成了新建而不是刪除重建的狀態

## Terraform的文件管理分享

隨著管理的資源的建立開始會發現有許多重複的main.tf，然後要修改某個資訊要修改多個main.tf，那要如何去共用這些main.tf呢？

在結構分享前我先介紹幾個terraform重要的檔案，詳細的設定請看參考連結中的`terraform configuration language`官網介紹

- main.tf

    main.tf是要設定AWS或是其他雲端的資源設定

- variables.tf

    variables.tf 則是預先定義變數，在main.tf中所用的變數資料都要在此先做定義

- xxxxx.tfvars

    `.tfvars` 則是預先輸入好的參數設定，後續就不需要在cli中輸入大量的資訊


![terraform 的資料夾結構](terraform-aws-infrastructure-as-code/terraform-folder.png)

在資料夾結構中，我依照aws的服務去建立相關的資料夾（如：alb, auto scaling group等等）去建立資料夾
在每個資料夾下都會有main.tf, variables.tf, xxxxx.tfvars的檔案，在workspace的命名上會採用與tfvars的檔名相同
並且會把workspace的名稱打在aws 服務的tag中方便未來做管理。

> Tips: 在variables.tf中的變數宣告建議都放上預設值，未來要刪除資源時會更加方便！


## 參考連結

[Install Terraform](https://learn.hashicorp.com/tutorials/terraform/install-cli#install-terraform)

[terraform aws provider](https://registry.terraform.io/providers/hashicorp/aws/latest/docs)

[terraform configuration language](https://www.terraform.io/docs/configuration/index.html)


一直在公司使用ansible來做Cloud configuration但是ansible在cloud configuration上說真的略顯不足， 在之前的文章中我們很常使用`aws cli`來做相對應的處理。使用aws cli時要有更好的可讀性與維護性，通常都以JSON的格式輸入 因此在ansible中的playbook上就會有多餘的一些步驟去設定餵給aws cli的JSON。

Terraform 做 AWS IaC


## 寫在前面

我們在aws 做Production deploy的時候，都會有一個pre production的環境，這個環境主要是為了在部署流程結束後可以做概念性驗證的環境
（主要測試：db connection是否正常、網路連線、裝機腳本等等）另一個方面可以預熱application，不過我們開始有越來越多採用docker的
application並且使用ECS的部署模式，但是ECS的Service建立後就無法修改Target Group，因此沒辦法如同EC2的部署模式只在最後切換Target Group

## 構思&實作

一開始其實想得很簡單，就是每次部署時都要產生新的 Target group 與新的ECS Service，
將新產生的Target Group掛載到ELB的preparing規則上，然後驗證完畢後就把這組Target Group掛載到ELB的 public規則上就完成了一次的部署

但...事件總是沒想像中的美好，原先預計兩週內可以完成的項目變到了三週(其實中間也有對自己的要求增加ex: script可以重跑、自動移除舊版本等等)

### Deploy Configuration

這個是為了減少使用者輸入資訊所做的一個設定，內容主要如下

```yaml
VPC:
Region:
HealthCheck:
    Path: "/"
    UnhealthyThreshold: 2
    HealthyThreshold: 5
LoadBalancer:
    Preparing:
    Public:
AutoScaling:
    Desired: 2
    MaxCount: 10
    MinCount: 2
Policies:
    - Name: Scale-By-CPU-Usage
      CoolDown: 150
      Threshold: 75.0
      Metric: ECSServiceAverageCPUUtilization
    - Name: Scale-By-Memory-Usage
      CoolDown: 150
      Threshold: 75.0
      Metric: ECSServiceAverageMemoryUtilization
```

### Step1. 建立Target Group

在建立Target Group其實沒什麼坑主要踩到的就是Target group的名字不能超過**32**個字所以在命名規劃上需要思考一下該如何呈現
> 我的命名規則是：環境-服務名稱-版本號

這一步執行的結果需要將內容記錄下來，在修改ELB的rule時會需要用到

```yaml
- name: Create Target Group
  elb_target_group:
    vpc_id: "{{ VPC }}"
    region: "{{ Region }}"
    state: present
    name: "{{ name }}"
    protocol: http
    port: 80
    health_check_protocol: http
    health_check_interval: 30
    health_check_timeout: 5
    health_check_path: "{{ HealthCheck.Path }}"
    unhealthy_threshold_count: "{{ HealthCheck.UnhealthyThreshold }}"
    healthy_threshold_count: "{{ HealthCheck.HealthyThreshold }}"
    successful_response_codes: "200"
    target_type: instance
    deregistration_delay_timeout: 60
    tags:
      Cluster: "{{ cluster }}"
      ENV: "{{ env }}"
      Version: "{{ version }}"
      Name: "{{ name }}"
      CreateTime: "{{ lookup('pipe','date +%Y%m%d') }}"
  register: target_group_result
```

### Step2. 連結ELB 的規則

這一步在ansible中這定較為複雜所以改用了aws cli來處理，如果你想用純的ansible的方式處理，可以參考
[這篇(elb_application_lb)](https://docs.ansible.com/ansible/latest/modules/elb_application_lb_module.html#elb-application-lb-module)

ansible的回傳都是陣列的形式所以在存取result的時候需要取得第一筆資料（如果你建立了多個target group
就可以用loop來處理）

```yaml
- name: Attach new target group to preparing load balancer rule
  shell: |
    aws elbv2 modify-rule \
      --actions Type=forward,TargetGroupArn={{ target_group_result.results[0].target_group_arn }} \
      --rule-arn {{ LoadBalancer.Preparing }} \
      --region {{ Region }}
```

### Step3. 註冊新的Task Definition

這一步驟來說應該是最複雜的一部分，我的Task Definition是由專案中的一個Configuration檔案設定
在CI建置完成後上傳到artifact server，在執行部屬時用ansible下載到Deploy server上在讀取到
ansible的變數中。

在專案中的Configuration不是一整份的設定值，他只記錄了一部分的資訊(ex: cpu, memory, family等)
主要的原因是有些資料需要在deploy時才能決定(ex: image version, env...)，
所以我會在註冊task definition前先透過configuration建立一份完整的task definition，
再透過aws cli來註冊新的task definition

這邊你會有個疑問，為何不直接採用
[ansible module](https://docs.ansible.com/ansible/latest/modules/ecs_taskdefinition_module.html#ecs-taskdefinition-module)
呢?主要原因是之前我們就有ecs deploy的CD流程，當時候有些參數我們需要但ansible無法支援
所以轉用aws cli的方式進行。

```yaml
- name: "Register Task Definition"
  shell: |
    aws ecs register-task-definition \
      --cli-input-json '{{ td_setting | to_json }}' \
      --region {{ Region }};
```

### Step4. 新建ECS Service

這一步我依舊採用aws cli來建立service，主要的原因是我的service通常會由兩個target group
指向兩個不同的ELB與domain，在ansible官方網站上並沒有太多的說明與所需要的參數，因此我轉用了
aws cli，如同step3我會先將所需要的設定在一個ansible task上做好 產生了`service_setting`的參數
在執行cli時將參數轉換成JSON代入

```yaml
- name: "Create ECS service {{ service_setting.serviceName }}"
  shell: |
    aws ecs create-service \
      --service-name '{{ service_setting.serviceName }}' \
      --cli-input-json '{{ service_setting | to_json }}' \
      --region {{ Region }};
  register: ecs_service_create
```

## 切換Service Version

切換服務版本這是一個比較大的工程，剛才的部署的複雜度更高一些，主要概念就是將新產生的target group
掛載到真正線上服務的ELB上，不過呢這件事情衍生了許多細細小小的項目要處理的細節也比較多

### Step1. 確認Target group health count

要切換前一定要先檢查Target group的target狀態，如果沒確認切換了一個還在做health check的target
group就會發生線上可能當下沒有機器服務的窘境，所以第一步肯定就是確認health count

```yaml
- name: Get Target Group Informantion
  elb_target_group_info:
    region: "{{ Region }}"
    collect_targets_health: yes
    names: "{{ switch_target_group }}"
  register: target_group_result
  failed_when: (target_group_result | json_query('target_groups[].targets_health_description[].target_health.state') | length) < {{ AutoScaling.Desired }}
```

當如果target的health count沒有達到要求數量我就讓playbook失敗，之前在ec2的做法是要完全healthy
才能夠往下運行但這樣會遇到當下要switch會無法switch，所以這次改變一下做法讓target的health count
只要大於要求數量即可

### Step2. 取得public當前的target group

為什麼要取得當前的target group？主要原因是怕瞬斷的情況發生，所以在切換的時候會有一個時間區間同時
有兩個版本在運行最後再將舊版本移除

取得ELB中的rule資料ansible並沒有太好的方式處理，所以這道題還是只能靠aws cli來協助了，aws cli 只需要輸入public rule的arn就可以取得了
詳細可以看[aws cli](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/elbv2/describe-rules.html) 的官方文件

```yaml
- name: "Get load balancer rule for {{ service_name | upper }}"
  shell: |
    aws elbv2 describe-rules \
      --rule-arns {{ LoadBalancer.Public | join(' ') }} \
      --region {{ Region }}
  register: current_rules
```

接下來這個就需要比較耐心地來處理了，因為ansible shell的回傳result會有個stdout屬性，這就是aws cli最後回傳的資料，所以我們要解析這個
資訊，然後ansible 的json_query是用[這個](https://jmespath.org/)來實作的，所以我們可以透過這個先取得我們想要的結果，當然他會有一個target group arn資料
不過我們後面需要一些壓在target group tag上的資料，所以我在這邊把他先取回來

```yaml
- name: Get target group informantion of current load balance setting
  elb_target_group_info:
    region: "{{ Region }}"
    target_group_arns: "{{ current_rules.stdout | from_json | json_query('Rules[].Actions[].ForwardConfig.TargetGroups[].TargetGroupArn') }}"
  register: current_target_group_result
```

### Step3. 把Prepare的target group跟public的整合在一起

在ansible還時沒有一個簡單的設定，去修改ELB rule的target group連結，所以還是得透過aws cli來作了

>下面的ansible tasks我將它設定成一個role，主要原因是我有兩個target group在處理，
>`set_fact`去跑loop的情況會比較複雜所以我設計成一個role，在playbook上採用loop
>來執行這個role，如此一來邏輯比較清晰也比較好維護

如此一來在public 的規則上就有兩個target group的容器在服務了，這樣的情況我會讓他維持約1分鐘，再將原先的target group移除

 ```yaml
- name: Generate load balance rule setting
  set_fact:
    target_rule_setting: |
      [
        {
          "Type": "forward",
          "ForwardConfig": {
            "TargetGroups": [
              {
                "TargetGroupArn": '{{ target_group[0].arn }}',
                "Weight": {{ target_group[0].weight }}
              },
              {
                "TargetGroupArn": '{{ target_group[1].arn }}',
                "Weight": {{ target_group[1].weight }}
              }
            ],
            "TargetGroupStickinessConfig": {
              "Enabled": false
            }
          }
        }
      ]
- name: "Attach to public rule"
  shell: |
    aws elbv2 modify-rule \
      --actions '{{ target_rule_setting | to_json }}' \
      --rule-arn {{ target_rule }} \
      --region {{ Region }}

 - name: "Remove old version"
  shell: |
    aws elbv2 modify-rule \
      --actions Type=forward,TargetGroupArn={{ item }} \
      --rule-arn {{ LoadBalancer.Release[ansible_loop.index0].Rule }} \
      --region {{ Region }}
  ```

### Step4. 處置舊版本的服務

移轉成功後需要把舊版本的service關機或是移除，我的選擇是暫時關閉

關閉服務聽起來很簡單，但我用aws cli執行將需求值改成0，但....一點效果都沒有！！

還記得一開始設定的autoscaling嗎....沒錯就是他！當你把desired改成0，會跟autoscaling設定的發生衝突所以變得無效

在調整desired改成0前，要把autoscaling設定移除才能順利的關閉service將cluster的資源釋出！

```yaml
- name: Shutdown ECS service
  shell: |
    aws application-autoscaling register-scalable-target \
      --service-namespace ecs \
      --scalable-dimension ecs:service:DesiredCount \
      --resource-id service/{{ current_target_group_result.target_groups[0].tags["Cluster"] }}/{{ current_target_group_result.target_groups[0].tags["Name"] }} \
      --min-capacity 0 \
      --max-capacity 0 \
      --region {{ Region }};
    aws ecs update-service \
      --cluster {{ current_target_group_result.target_groups[0].tags["Cluster"] }} \
      --service {{ current_target_group_result.target_groups[0].tags["Name"] }} \
      --desired-count 0 \
      --region {{ Region }};
```

### Step5. 移除

這是整個部署流程的尾聲了（或是你可以選擇不做....）

我的做法是先將整個ecs cluster的service列出來，然後取得target group資料，再由target group資料取得tag是否含有`obsolete`的tag

```yaml
- name: Get obsolete target group info
  elb_target_group_info:
    region: "{{ Region }}"
    target_group_arns: "{{ target_group_arn | json_query('loadBalancers[].targetGroupArn') }}"
  register: ecs_tg_result

- name: Delete obsolete ECS service and target group
  shell: |
    aws ecs delete-service \
      --cluster {{ ecs_tg_result.target_groups[0].tags['Cluster'] }} \
      --service {{ ecs_tg_result.target_groups[0].tags['Service'] }} \
      --region {{ Region }} ;
    aws elbv2 delete-target-group \
      --target-group-arn {{ ecs_tg_result.target_groups[0].target_group_arn }} \
      --region {{ Region }} ;
    aws elbv2 delete-target-group \
      --target-group-arn {{ ecs_tg_result.target_groups[1].target_group_arn }} \
      --region {{ Region }} ;
  when: ecs_tg_result.target_groups[0].tags['Obsolete'] is defined
```

### Step6. 標記

部署的最後一步，標記已經被關閉的服務變成`obsolete`

這是為了下次部署可以把這些服務刪除，如果前一個步驟不做的話，這個步驟也是可以省略的。

 ```yaml
- name: Configure obsolete target group
  shell: |
    aws elbv2 add-tags \
      --resource-arns {{ item.target_group_arn }} \
      --tags '[{"Key": "Obsolete", "Value": "yes"}]' \
      --region {{ Region }}
  loop: "{{ current_target_group_result.target_groups }}"
```


我們在aws 做Production deploy的時候，都會有一個pre production的環境，這個環境主要是為了在部署流程結束後可以做概念性驗證的環境 （主要測試：db connection是否正常、網路連線、裝機腳本等等）另一個方面可以預熱application，不過我們開始有越來越多採用docker的 application並且使用ECS的部署模式，但是ECS的Service建立後就無法修改Target Group，因此沒辦法如同EC2的部署模式只在最後切換Target Group

非靜態網站使用AWS做金絲雀部署

從黑暗時代到現代化的雲端部署與維運 July 26 @ DevOps

如何讓AWS EC2開機後就能上線

Terraform 做 AWS IaC

AWS ECS Preparing Release 紀錄