
dotnetconf 2021 ＠ study4 從黑暗時代到現代化的雲端部署與維運

[投影片下載](https://cdn.adhome.com.tw/blogger/dotnetconf2021@STUDY4.pdf)

## IAC 說明

[IaC Repo](https://github.com/Yi-Shiuan/dotnet-conf-iac)

### website 資料夾

website資料夾是建立各個環境的資源檔案，內容記載該服務需要產生哪些的資源項目以及各個環境上的配置，裡面的部分採用terraform撰寫

- `main.tf` => 用來設定資院建立的內容與設定
- `variable.tf` => 定義整個腳本中有哪些變數
- `vars 資料夾` => 每一個環境上的設定值

### initial-script

自動安裝腳本，這裡面的`main.sh`是整個警本的進入點，每一個服務都會有一個資料夾，資料夾內會有一個`install.sh`的檔案，這是實際上application真正執行部署的腳本
由main.sh去下載install.sh，並且執行install.sh




dotnetconf 2021 ＠ study4 從黑暗時代到現代化的雲端部署與維運

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


## 寫在前面

在雲端服務一定會遇到的是機器的擴展(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開機後就能上線


## 寫在前面

我們在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 EC2開機後就能上線

AWS ECS Preparing Release 紀錄