
從黑暗時代到現代化的雲端部署與維運 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


這週在處理在azure自建的elasticsearch相關的狀況，今天處理告一段落後來個小筆記未來遇到才不會又搞了老半天...

為什麼要自建elastic呢？主要因為之前使用azure marketplace建立的elastic cloud的saas服務，現在需要把維運的職責交給SRE團隊，
在移交的過程中發現了azure marketplace所建立的saas服務竟然不能移轉owner！只能將該服務的權限做共享而且必須將訂閱升級到Golden的等級，
代表每個月的azure帳單又要多最少百元美金的支出...未來帳號如果被停用或是變更，有可能elastic cloud上的資料會有所影響，迫於無奈下只好走向自建的路了

在自建時需要選好許多azure的服務相關的infra設計這些工作可少不了...最後決定了這些infra與azure的服務

#### 1. elasticsearch server + kibana server

使用vmss的服務建立虛擬機器，虛擬機器的規格是使用E2s v5的規格，根據過往經驗elasticsearch伺服器在尖峰的狀態下會使用較多的記憶體，而對於cpu要求較少一些
對於網路的頻寬要求與對於硬碟的iops都有較大的要求，所以選用了esv5等級的機器

#### 2. logstash server

logstash 服務也是採用vmss來建立虛擬機器，比較不一樣的是logstash對於cpu的要求較多，他需要去解析log還要針對log做相對應的處理，所以我們選用的是B1s的規格
然後針對他cpu與memory的使用率做scale out/in的處理

在主機中我使用的是container而非直接安裝相關的服務，然後搭配過去preversion的手法來建立伺服器。

#### 3. Storage

存放資料的磁區選用，這個在規劃時的poc最為困擾...在azure直接使用virtual machine的服務可以掛載managed disk的磁區，但使用vmss產生的vm是無法使用managed disk的！
但...vmss或是vm建立的硬碟會隨這vm刪除或關閉而消失，所以我們必須得用另外一組的硬碟...後來找到了另外一種解決方案，azure file的服務，
這樣一來就可以透過SMB掛載一個永久的硬碟，未來的log就能完整地被保留下來不會因為vm被刪除而消彌。

> ps. azure file目前還不知道這樣的使用情境可以支撐多少的iops寫入與讀取，有待未來實驗
> 根據官方文件指出每秒的iops是20,000 IOPS的讀取的速度基本上可以跟SSD差不多

### 內建帳號使用 Service account token

在使用8.0過後的版本kibana的服務官方預設不使用帳號密碼的方式登入，需要使用service account token的方式登入連線，然後按照官方的指引點入的連結會請你呼叫建立token的api
```sh
# create service account token
curl -X POST -u elastic:changeme "localhost:9200/_security/service/elastic/fleet-server/credential/token?pretty"
```
response
```json
{
  "created": true,
  "token": {
    "name": "token1",
    "value": "AAEAAWVsYXN0aWM...vZmxlZXQtc2VydmVyL3Rva2VuMTo3TFdaSDZ"
  }
}
```
然後在kibana上使用service account token登入，但只使用這樣的方式建立的token放在kibana上使用是可以登入elasticsearch，
但在操作indices的時候就會出現錯誤`security_exception`說你沒有權限取得indices的資料
```yaml
# kibana.yml config
server.name: kibana
server.host: 0.0.0.0
elasticsearch.hosts: [ "http://{{elasticsearch}}:{{port}}" ]
xpack.monitoring.ui.container.elasticsearch.enabled: true

elasticsearch.serviceAccountToken: AAEAAWVs......EtHd1E
```
好的，後來發現其實api呼叫的參數不對，官方在錯誤輸出的console上給的網址是會呼叫fleet-server的服務，而不是給kibana使用的所以我們要把fleet-server的token
改成kibana服務的token，這樣就可以登入並且取得indices的資料順利的啟動kibana了
```shell
# for create kibana service account
curl -X POST -u elastic:changeme "localhost:9200/_security/service/elastic/kibana/credential/token?pretty"
```
```shell
# check permission
curl -H "Authorization: Bearer AAE.......1E" -X GET "localhost:9200/_security/user/_has_privileges?pretty" -H 'Content-Type: application/json' -d'
{
  "cluster": [ "cluster:monitor/main" ],
  "index" : [
    {
      "names": [ "logs-apm.app-default", "metrics-apm.app.*-default", "logs-apm.error-default", "metrics-apm.internal-default", "metrics-apm.profiling-default", "traces-apm.rum-default", "traces-apm-default" ],
      "privileges": [ "auto_configure","create_doc" ]
    },
    {
      "names": [ "traces-apm.sampled-default" ],
      "privileges": [ "auto_configure","create_doc","maintenance","monitor","read" ]
    }
  ]
}
'
```

## 後記

因為azure file使用`Transaction optimized`等級的價格每GB花費是1.763台幣，價格並不便宜所以只能將hot data存放在該區域中，
在未來會放上elastic使用cluster的方式將hot data與warm data（使用hot等級）區分開來，減少帳單的開支

## 參考連結

[Service Accounts (Official document)](https://www.elastic.co/guide/en/elasticsearch/reference/current/service-accounts.html)

[Create service account token api (official document)](https://www.elastic.co/guide/en/elasticsearch/reference/current/security-api-create-service-token.html)

[azure file iops](https://docs.microsoft.com/en-us/azure/storage/files/storage-files-scale-targets)


這週在處理自建的elasticsearch相關的狀況，今天處理告一段落後來個小筆記未來遇到才不會又搞了老半天...

自建Elasticsearch 8.2


在之前已經有寫過AWS的裝機處理，這次改用Azure同樣的可以讓系統從scale out到上線不需要人工的處理就可以完成系統的部署與設定

## Azure 的VM Scale Set

在AWS是稱為Auto Scaling Group，在Azure中的名稱是Virtual Machine Scale Set(以下簡稱VMSS)，這也是一個群組設定虛擬機器的規格, 伸縮的條件, 健康檢查等等的設定

custom_data的資料就是我們準備要設定開機後要執行的腳本，這個設定了以後在azure 的Portal是無法再看到的，所以如果不是使用IaC的話一定要找個地方做紀錄
Azure的VMSS就有內建的檢查機制(extension區塊)，可以檢查VM的服務是否正確地被啟動，若沒有在時間內被測試成功的話機器會重新收回部署

在terraform 有另一個設定 extension的module， `azurerm_virtual_machine_extension`設定如果要設定`healthRepairExtension`在我測試時是會失敗的，所以一定要在extension區塊中設定。

```config
resource "azurerm_linux_virtual_machine_scale_set" "sample" {
  name                = "${var.prefix}-vmss"
  resource_group_name = data.azurerm_resource_group.main.name
  location            = data.azurerm_resource_group.main.location
  zone_balance        = true
  zones               = [1, 2, 3]
  sku                 = var.machineSize
  instances           = var.capacity.minimum
  admin_username      = "azureuser"
  custom_data         = filebase64("${path.module}/custom-data.sh")

  admin_ssh_key {
    username   = "azureuser"
    public_key = data.azurerm_ssh_public_key.logstash.public_key
  }

  automatic_instance_repair {
    enabled      = true
    grace_period = "PT10M"
  }

  source_image_reference {
    publisher = "canonical"
    offer     = "0001-com-ubuntu-server-focal"
    sku       = "20_04-lts-gen2"
    version   = "latest"
  }

  os_disk {
    storage_account_type = "Standard_LRS"
    caching              = "ReadWrite"
    disk_size_gb         = 30
  }

  extension {
    name                      = "healthRepairExtension"
    publisher                 = "Microsoft.ManagedServices"
    type                      = "ApplicationHealthLinux"
    type_handler_version      = "1.0"
    automatic_upgrade_enabled = true
    settings                  = <<settings
      {
        "protocol" : "http",
        "port" : 80,
        "requestPath" : "/"
      }
    settings
  }

  network_interface {
    name    = "${var.prefix}-NIC"
    primary = true

    ip_configuration {
      name      = "internal"
      primary   = true
      subnet_id = azurerm_subnet.subnet.id
    }
  }

  tags = {
    env      = var.environment
    service  = "logstash"
    createby = "brunojan"
    docker   = "yes"
    date     = formatdate("YYYY/MM/DD hh:mm:ss", timestamp())
    version  = var.ap_version
  }
}
```
## VMSS的擴展計畫

在Azure的設定呢，說真的我還沒有非常的理解整個設定，但目前看起來的設定較為麻煩...

在Profile中，一定要有一組預設的設定資料，接下來才能在設定其他的擴展策略，所以我直接hard code一組default的設定，這個設定會是主要的擴展策略。
其他的設定基本上可以依照特定的時間，或是情境來做設定

在設定中的時間設定在Azure都是使用ISO-8601的設定標準來設定，這個部份對於我來說真的很不順手，也不容易理解...

```config
resource "azurerm_monitor_autoscale_setting" "autoscale" {
  name                = "${var.prefix}-scale-set"
  resource_group_name = data.azurerm_resource_group.main.name
  location            = data.azurerm_resource_group.main.location
  target_resource_id  = azurerm_linux_virtual_machine_scale_set.sample.id

  profile {
    name = "default"

    capacity {
      default = var.capacity.minimum
      minimum = var.capacity.minimum
      maximum = var.capacity.maximum
    }

    dynamic "rule" {
      for_each = length(var.policies) > 0 ? var.policies : []
      content {
        metric_trigger {
          metric_name        = rule.value.metric
          metric_resource_id = azurerm_linux_virtual_machine_scale_set.sample.id
          time_grain         = rule.value.grain
          statistic          = rule.value.statistic
          time_window        = rule.value.duration
          time_aggregation   = rule.value.statistic
          operator           = rule.value.operation
          threshold          = rule.value.threshold
          metric_namespace   = "microsoft.compute/virtualmachinescalesets"
        }

        scale_action {
          direction = rule.value.action
          type      = "ChangeCount"
          value     = rule.value.count
          cooldown  = rule.value.cooldown
        }
      }
    }
  }

  dynamic "profile" {
    for_each = length(var.schedules) > 0 ? var.schedules : []

    content {
      name = profile.value.name

      capacity {
        default = profile.value.minimum
        minimum = profile.value.minimum
        maximum = profile.value.maximum
      }

      recurrence {
        timezone = "Taipei Standard Time"
        days     = profile.value.days
        hours    = profile.value.hours
        minutes  = profile.value.minutes
      }

    }
  }
```

## Terraform azurerm_virtual_machine_scale_set

這個在未來的版本中已經被棄用了，所以如果有要使用terraform的記得改用`azurerm_linux_virtual_machine_scale_set`(Linux)與azurerm_windows_virtual_machine_scale_set(Windows)
設定上基本差不多

## 參考資料

[ISO-8601 wiki](https://en.wikipedia.org/wiki/ISO_8601)

[Terraform azurerm_virtual_machine_scale_set](https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/virtual_machine_scale_set)


在之前已經有寫過AWS的裝機處理，這次改用Azure同樣的可以讓系統從scale out到上線不需要人工的處理就可以完成系統的部署與設定

Azure 的自動裝機


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

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

自建Elasticsearch 8.2

Azure 的自動裝機

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

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

AWS ECS Preparing Release 紀錄