
在dotent conf 2022中分享的投影片內容

[投影片下載](https://cdn.adhome.com.tw/blogger/dotnet-conf-2022@study4/dotent-conf-2022@study4.pdf)

[從黑暗時代到現代化的雲端部署與維運](https://brunojan.net/posts/2021/12/20/dotnetconf-2021@study4)

元宇宙是一個陌生的名詞，今天我用它來當作下一個世代的部署方式
這個世代部署，我們要盡可能地減少config的設定或者是零Config，要達成這樣的狀態首先需要有各式的infra來支援，不然很難達成這樣的操作模式。

當你的config越變越少，你的程式碼不再需要環境設定，那你在DevOps又更近了一步！


dotnetconf 2022 ＠ study4 邁向元宇宙部署模式

邁向元宇宙部署模式


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


在之前已經有寫過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 從黑暗時代到現代化的雲端部署與維運

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


在網頁開發中，SSL憑證已經是一個不可或缺的一件事情！網路上可以找到許多免費的憑證使用，如[let's encrypt](https://letsencrypt.org/zh-tw/)、
[ZeroSSL](https://zerossl.com/)都可以幫你產生免費的憑證，唯一麻煩的事情是三個月就需要重新處理憑證問題，當然熟悉腳本處理的可以透過一些自動化的方式來處理只是需要花點時間撰寫這些腳本
在雲端供應商中AWS有提供ACM微軟也有提供類似於ACM的服務，只要你使用了這些雲端供應商就可以免費的為你產生憑證

## 設定方式

Azure 坦白說UI真的不是很直覺，這也是微軟一直以來的硬傷，這個設定其實藏在我們一直看得到的地方但又不會去點他的一個按鈕

再進入設定之前，必須要將自訂的domain綁在Azure app service上（或Azure functions）才能夠產生憑證，點下`Create App Service Managed Certificate`
後只需要點選你要的Domain 就可以產生了，整個過程約3-5分鐘左右，如果有多個子網域都需要SSL的話就多點幾次

![Azure 受管的 SSL](azure-managed-certificate-app-service/azure-managed-ssl.png)

![Azure 產生 SSL](azure-managed-certificate-app-service/create-ssl.png)

產生SSL憑證後需要到`TSL/SSL Setting`中，將剛才建立的SSL綁定到相對應的Domain name上就可以了

![Azure 綁定 SSL](azure-managed-certificate-app-service/azure-ssl-binding.png)

## 使用條件與限制

憑證一定位有到期日期，在微軟提供的憑證中有效期間是6個月，在六個月到期後會自動的幫你renew這個憑證直到你刪除app service或azure functions等服務，
必須要可以自訂domain name的規格才能夠產生免費的憑證(B1等級以上)

> 此免費憑證有下列限制：
>
>  - 不支援萬用字元憑證。
>  - 不支援以憑證指紋作為用戶端憑證的使用方式， (移除憑證指紋的) 計畫。
>  - 不可匯出。
>  - App Service 環境 (ASE) 上並不支援。
>  - 與流量管理員整合的根域不支援。
>  - 如果是 CNAME 對應網域的憑證，則 CNAME 必須直接對應至 {app-name}.azurewebsites.net 。
>
> [在 Azure App Service 中新增 TLS/SSL 憑證](https://docs.microsoft.com/zh-tw/azure/app-service/configure-ssl-certificate)


在網頁開發中，SSL憑證已經是一個不可或缺的一件事情！網路上可以找到許多免費的憑證使用，如let's encrypt、ZeroSSL 都可以幫你產生免費的憑證，唯一麻煩的事情是三個月就需要重新處理憑證問題，在雲端供應商中AWS有提供ACM微軟也有提供類似於ACM的服務， 只要你使用了這些雲端供應商就可以免費的為你產生憑證

受Azure管理的免費憑證


## 針對index的一些效能調校

在Index Management中有個index templates的頁簽，在這裡可以改變一些index的行為或是屬性，
有些index屬性對於整個ELK的查詢或是機器的影響是很巨大的，當Log量越大的時候就需要改變一些設定，
尤其是放在雲端的ELK，如果使用越大的機器消費金額就會變得很可觀，在不是賺錢的機器上還是能省則省。

`index.codec`在官方的文件中有兩個選項，預設是Default採用LZ4的壓縮，另一個選項是*best_compression*，
使用它可以得到更高的壓縮效率但會增加CPU的附載，不過減少硬碟的空間是可觀的

`refresh_interval`這個在官方文件說明是index的刷新頻率，這個選項會影響到新增的log多久內可能不會被看見，
但refresh index他需要消耗許多的CPU來處理，這個值如果越大刷新的頻率就會降低，機器的CPU usage就不會被這個吃掉，
可以減少一些CPU的運算

`number_of_replicas`是Elasticsearch會建立多少個副本，但複本越多所需要消耗的CPU與硬碟空間就會加大

```json
{
  "index": {
    "lifecycle": {
      "name": "production"
    },
    "codec": "best_compression",
    "refresh_interval": "15s",
    "number_of_replicas": 0
  }
}
```

## 自動維運Index的小技巧

通常架設了ELK初期會常常觀看一些硬碟空間, CPU usage, Memory usage等等的，時間久了就會忘記了...

但是硬碟的空間是有限的，Application Log其實也是有時效性的，他不需要永久的存在在硬碟上(畢竟要花錢的...)所以自動刪除index就變得很重要，
在Index Lifecycle Policies中我會設定兩個policy，一個production跟一個non-production的，production通常會留存30天以，
而非production的一般來說在兩週到三週就沒有參考價值了，所以非production只留存14天。

![ELK index lifecycle](elasticsearch-tuning-and-auto-operation/index-lifecycle.png)

## 參考連結
[Elasticsearch Index Module](https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules.html)

[Tune for indexing speed](https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-indexing-speed.html)


在Index Management中有個index templates的頁簽，在這裡可以改變一些index的行為或是屬性， 有些index屬性對於整個ELK的查詢或是機器的影響是很巨大的，當Log量越大的時候就需要改變一些設定， 尤其是放在雲端的ELK，如果使用越大的機器消費金額就會變得很可觀，在不是賺錢的機器上還是能省則省。

Elasticsearch 效能調整與自動維運


## 寫在前面

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