Как автоматически перезапускать таск в ECS при пуше нового image?

Question

[ttmje]

Есть пайплайн, который пушит новый docker image в Amazon ECR.
Есть кластер, который использует последний запушенный image.
Чтобы изменения из нового image вступили в силу, нужно перезапустить этот таск в ECS.
Как это можно автоматизировать?

Answer 1

[Vitaly Karasik]

Использовать latest image - это неправильная практика.
Как сказал akelsey, нужно обновить Task Defintion, и тогда ничего перезапускать не надо.
Я для это в Github Actions использую
aws-actions/amazon-ecs-render-task-definition
и
aws-actions/amazon-ecs-deploy-task-definition

Comments

[ttmje]

Почти освоился. Остался вопрос:
При использовании aws-actions/amazon-ecs-render-task-definition и aws-actions/amazon-ecs-deploy-task-definition новая версия таска с новым имеджем попадает в кластер - все ок.
Но автоматически кластер новую версию таска не запускает. Как можно это сделать?

[Vitaly Karasik]

автоматически кластер новую версию таска не запускает.

ttmje, У меня запускает.
Покажите ваш task definition и service конфиг, я попробую сравнить.

[ttmje]

Vitaly Karasik, Сейчас в кластере бежит вот эта версия таска (7я версия)

Task Definition

{
"ipcMode": null,
"executionRoleArn": "arn:aws:iam::948206608465:role/ecsTaskExecutionRole",
"containerDefinitions": [
{
"dnsSearchDomains": null,
"environmentFiles": null,
"logConfiguration": {
"logDriver": "awslogs",
"secretOptions": null,
"options": {
"awslogs-group": "/ecs/tenders",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
}
},
"entryPoint": null,
"portMappings": [
{
"hostPort": 80,
"protocol": "tcp",
"containerPort": 80
}
],
"command": null,
"linuxParameters": null,
"cpu": 0,
"environment": [],
"resourceRequirements": null,
"ulimits": null,
"dnsServers": null,
"mountPoints": [],
"workingDirectory": null,
"secrets": null,
"dockerSecurityOptions": null,
"memory": null,
"memoryReservation": null,
"volumesFrom": [],
"stopTimeout": null,
"image": "948206608465.dkr.ecr.us-east-1.amazonaws.com/tender_notify:latest",
"startTimeout": null,
"firelensConfiguration": null,
"dependsOn": null,
"disableNetworking": null,
"interactive": null,
"healthCheck": null,
"essential": true,
"links": null,
"hostname": null,
"extraHosts": null,
"pseudoTerminal": null,
"user": null,
"readonlyRootFilesystem": null,
"dockerLabels": null,
"systemControls": null,
"privileged": null,
"name": "notify"
}
],
"placementConstraints": [],
"memory": "512",
"taskRoleArn": null,
"compatibilities": [
"EC2",
"FARGATE"
],
"taskDefinitionArn": "arn:aws:ecs:us-east-1:948206608465:task-definition/tenders:7",
"family": "tenders",
"requiresAttributes": [
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.logging-driver.awslogs"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "ecs.capability.execution-role-awslogs"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.ecr-auth"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.docker-remote-api.1.19"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "ecs.capability.execution-role-ecr-pull"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.docker-remote-api.1.18"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "ecs.capability.task-eni"
}
],
"pidMode": null,
"requiresCompatibilities": [
"FARGATE"
],
"networkMode": "awsvpc",
"runtimePlatform": null,
"cpu": "256",
"revision": 7,
"status": "ACTIVE",
"inferenceAccelerators": null,
"proxyConfiguration": null,
"volumes": []
}

После этой версии я запушил еще две: 8 и 9, соответственно. Сервис как крутил 7ю версию так и продолжает.

[Vitaly Karasik]

Страннно!
1) Посмотрите в табе "tasks/events/deployemnts" под service, возможно новые таски пытаются стартовать, но падают.
2) Посмотрите на task definition 7 vs 8, убедитесь что там разные image
3) Я был неправ - деплой зависит от конфигурации service, не task, но там у меня вроде все по умолчанию

UPDATE - я кажется понял!!!
В task definition #7 у вас

"image": "948206608465.dkr.ecr.us-east-1.amazonaws.com/tender_notify:latest"

По-моему это и мешает ему обновиться.
Сделайте один раз upgrade вручную на 8 версию, а потом уже будет работать само.

[ttmje]

Vitaly Karasik, Спасибо за помощь. Сейчас бежит девятая версия. Вот ее описание.

Task Definition: tenders:9

{
"ipcMode": null,
"executionRoleArn": "arn:aws:iam::948206608465:role/ecsTaskExecutionRole",
"containerDefinitions": [
{
"dnsSearchDomains": null,
"environmentFiles": null,
"logConfiguration": {
"logDriver": "awslogs",
"secretOptions": null,
"options": {
"awslogs-group": "/ecs/tenders",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
}
},
"entryPoint": null,
"portMappings": [
{
"hostPort": 80,
"protocol": "tcp",
"containerPort": 80
}
],
"command": null,
"linuxParameters": null,
"cpu": 0,
"environment": [],
"resourceRequirements": null,
"ulimits": null,
"dnsServers": null,
"mountPoints": [],
"workingDirectory": null,
"secrets": null,
"dockerSecurityOptions": null,
"memory": null,
"memoryReservation": null,
"volumesFrom": [],
"stopTimeout": null,
"image": "948206608465.dkr.ecr.us-east-1.amazonaws.com/tender_notify:2b9501a0746c4158f7914f49e89159118448e625",
"startTimeout": null,
"firelensConfiguration": null,
"dependsOn": null,
"disableNetworking": null,
"interactive": null,
"healthCheck": null,
"essential": true,
"links": null,
"hostname": null,
"extraHosts": null,
"pseudoTerminal": null,
"user": null,
"readonlyRootFilesystem": null,
"dockerLabels": null,
"systemControls": null,
"privileged": null,
"name": "notify"
}
],
"placementConstraints": [],
"memory": "512",
"taskRoleArn": null,
"compatibilities": [
"EC2",
"FARGATE"
],
"taskDefinitionArn": "arn:aws:ecs:us-east-1:948206608465:task-definition/tenders:9",
"family": "tenders",
"requiresAttributes": [
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.logging-driver.awslogs"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "ecs.capability.execution-role-awslogs"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.ecr-auth"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.docker-remote-api.1.19"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "ecs.capability.execution-role-ecr-pull"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.docker-remote-api.1.18"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "ecs.capability.task-eni"
}
],
"pidMode": null,
"requiresCompatibilities": [
"FARGATE"
],
"networkMode": "awsvpc",
"runtimePlatform": null,
"cpu": "256",
"revision": 9,
"status": "ACTIVE",
"inferenceAccelerators": null,
"proxyConfiguration": null,
"volumes": []
}

Только что запушил 10ю версию и сделал, чтобы тег у имеджа был хешем коммита. Но почему то как бежала 9я версия таска так и осталась. Где-то я делаю что-то не так. В табах tasks/events/Deployments ничего, ктороме текущего 9 таска нет. Прикладываю обе версии для сравнения.

tenders:10

{
"ipcMode": null,
"executionRoleArn": "arn:aws:iam::948206608465:role/ecsTaskExecutionRole",
"containerDefinitions": [
{
"dnsSearchDomains": null,
"environmentFiles": null,
"logConfiguration": {
"logDriver": "awslogs",
"secretOptions": null,
"options": {
"awslogs-group": "/ecs/tenders",
"awslogs-region": "us-east-1",
"awslogs-stream-prefix": "ecs"
}
},
"entryPoint": null,
"portMappings": [
{
"hostPort": 80,
"protocol": "tcp",
"containerPort": 80
}
],
"command": null,
"linuxParameters": null,
"cpu": 0,
"environment": [],
"resourceRequirements": null,
"ulimits": null,
"dnsServers": null,
"mountPoints": [],
"workingDirectory": null,
"secrets": null,
"dockerSecurityOptions": null,
"memory": null,
"memoryReservation": null,
"volumesFrom": [],
"stopTimeout": null,
"image": "948206608465.dkr.ecr.us-east-1.amazonaws.com/tender_notify:fbad76ea37a79bf3d9947f30128242cf066973c8",
"startTimeout": null,
"firelensConfiguration": null,
"dependsOn": null,
"disableNetworking": null,
"interactive": null,
"healthCheck": null,
"essential": true,
"links": null,
"hostname": null,
"extraHosts": null,
"pseudoTerminal": null,
"user": null,
"readonlyRootFilesystem": null,
"dockerLabels": null,
"systemControls": null,
"privileged": null,
"name": "notify"
}
],
"placementConstraints": [],
"memory": "512",
"taskRoleArn": null,
"compatibilities": [
"EC2",
"FARGATE"
],
"taskDefinitionArn": "arn:aws:ecs:us-east-1:948206608465:task-definition/tenders:10",
"family": "tenders",
"requiresAttributes": [
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.logging-driver.awslogs"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "ecs.capability.execution-role-awslogs"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.ecr-auth"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.docker-remote-api.1.19"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "ecs.capability.execution-role-ecr-pull"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "com.amazonaws.ecs.capability.docker-remote-api.1.18"
},
{
"targetId": null,
"targetType": null,
"value": null,
"name": "ecs.capability.task-eni"
}
],
"pidMode": null,
"requiresCompatibilities": [
"FARGATE"
],
"networkMode": "awsvpc",
"runtimePlatform": null,
"cpu": "256",
"revision": 10,
"status": "ACTIVE",
"inferenceAccelerators": null,
"proxyConfiguration": null,
"volumes": []
}

[Vitaly Karasik]

ttmje, Даже не знаю что сказать.

олько что запушил 10ю версию

через https://github.com/aws-actions/amazon-ecs-deploy-t...?

Я посылаю один из своих сервисов - "aws ecs describe-services --cluster sandbox-cluster0-ecs --services sandbox-portal-ecs-service", можно сравнить настройки, но я ничего там специально не менял. Возможно у меня FARGATE, а у вас кластер на EC2, но очень странно если это меняет поведение.

[Vitaly Karasik]

Можно спросить в https://github.com/aws-actions/amazon-ecs-deploy-t...

[ttmje]

Vitaly Karasik, Таск бежит на fargate

Делаю через github-actions

[Vitaly Karasik]

У меня то же самое, но я задаю и сервис:

uses: aws-actions/amazon-ecs-deploy-task-definition@v1
      with:
        task-definition: ${{ steps.task-def.outputs.task-definition }}
        service: ${{ env.ECS_SERVICE }}
        cluster: ${{ env.ECS_CLUSTER }}
        wait-for-service-stability: true

[ttmje]

Vitaly Karasik, Огромное спасибо! Это помогло.
Нужно было в amazon-ecs-deploy-task-definitio указать название сервиса.

[hesher_wise]

ttmje Vitaly Karasik
Ребята не подскажите, у меня таска в EC2. Тоже пушу через гитхаб экшн, но таска пушится но старая не удаляется(. Не подскажите решение такой проблемы ? Или мб премер есть какой-то?

[Vitaly Karasik]

hesher_wise, Что видно в ECS? Новая версия появляется?

[hesher_wise]

Vitaly Karasik, видно что таска подымается, но не хочет удаляться старая. Попробовал через AWS cli, тоже не получилось.

[hesher_wise]

jobs:
  deploy:
    name: Deploy ubuntu
    runs-on: ubuntu-latest
    environment: production

    steps:
    - name: Git clone repo
      uses: actions/checkout@v3

    - name: Configure AWS credentials
      uses: aws-actions/configure-aws-credentials@v1
      with:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ github.event.inputs.AWS_REGION }}
        
    - name: Login to Amazon ECR
      uses: aws-actions/amazon-ecr-login@v1
    

        
    - name: Render Amazon ECS task definition for first container nginx
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: ${{ env.ECS_TD_JSON_FILE }}
        container-name: ${{ github.event.inputs.CONTAINER_NAME_NGINX }}
        image: ${{ github.event.inputs.AWS_ACCOUNT }}.dkr.ecr.${{ github.event.inputs.AWS_REGION }}.amazonaws.com/${{ github.event.inputs.ECR_REPO }}:${{ github.event.inputs.IMAGE_TAG_NGINX }}
    
    - name: Render Amazon ECS task definition for second container php
      uses: aws-actions/amazon-ecs-render-task-definition@v1
      with:
        task-definition: ${{ env.ECS_TD_JSON_FILE }}
        container-name: ${{ github.event.inputs.CONTAINER_NAME_PHP }}
        image: ${{ github.event.inputs.AWS_ACCOUNT }}.dkr.ecr.${{ github.event.inputs.AWS_REGION }}.amazonaws.com/${{ github.event.inputs.ECR_REPO }}:${{ github.event.inputs.IMAGE_TAG_PHP }}


    - name: Deploy task definition in ECS service
      env:
        aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
        aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        aws-region: ${{ github.event.inputs.AWS_REGION }}
      run: aws ecs update-service --cluster ${{ github.event.inputs.ECS_CLUSTER_NAME }} --service ${{ github.event.inputs.ECS_SERVICE_NAME }} --task-definition CccomboEXIT:3 --force-new-deployment

Vitaly Karasik пробовал много разного методом тыка и чтением документации, и ни кчему нормальному не пришел((

[Vitaly Karasik]

hesher_wise, на скриншоте видно что новая версия задачи не поднялась (0 running tasks), поэтому ECS не убирает предыдущую версию.

Answer 2

[akelsey]

Самый лучший вариант при настроенном сервисе (desired tasks 1) это пушать имидж присвоив номер версии, например номер билда, и обновлять Task Defintion, тогда ECS сам сделает текущий имидж INACTIVE, параллельно инициализировав второй (плавно выведет старый из сервиса, когда новый станет активным).
Если же предложенный вариант не вариант - так же в пайплайне стопать таску и запускать aws cli.

Answer 3

[Вадим]

Привет, используй EventBridge (раньше cloudwatch events) - https://docs.aws.amazon.com/codepipeline/latest/us... который будет вызывать не codepipeline (как в примере) при пуше нового образа в ECR, а например Lambda function, которая будет обновлять таск ECS

удачи, Вадим