web-dev-qa-db-fra.com

Cloudwatch a échoué erreur d'invocation aucun journal disponible

J'ai configuré un événement de règle Cloudwatch où une définition de tâche ECS est démarrée lorsqu'une définition de tâche précédente est terminée.

Je peux voir l'événement déclencher la définition de la tâche, mais elle échoue.

La seule visibilité de cet échec se trouve dans les métriques de règle, où je vois les invocations d'échec de la métrique.

Question, existe-t-il des journaux pour voir pourquoi le déclencheur a échoué?

Je peux configurer manuellement la règle via la console de gestion et tout fonctionne bien.

L'erreur se produit lorsque j'ai configuré la règle via un modèle de cloudformation.

J'ai comparé les deux règles et les deux sont identiques, sauf le rôle. Cependant, les deux rôles ont les mêmes autorisations.

amazon-web-servicesamazon-ec2amazon-cloudformationamazon-cloudwatchamazon-ecs
22
Nathan B

Cela nous a bloqué pendant des siècles, le principal problème est le problème de rôle mentionné par Nathan B, mais quelque chose d'autre qui nous a fait trébucher est que les conteneurs programmés ne fonctionneront pas en mode awsvpc (et par extension Fargate). Voici un exemple de modèle CloudFormation:

---
AWSTemplateFormatVersion: 2010-09-09
Description: Fee Recon infrastructure

Parameters:

  ClusterArn:
    Type: String
    Description: The Arn of the ECS Cluster to run the scheduled container on

Resources:

  TaskRole:
    Type: AWS::IAM::Role
    Properties:
      Path: /
      AssumeRolePolicyDocument:
        Statement:
          - Action:
              - sts:AssumeRole
            Effect: Allow
            Principal:
              Service:
                - ecs-tasks.amazonaws.com
        Version: 2012-10-17
      Policies:
       - PolicyName: TaskPolicy
         PolicyDocument:
           Version: 2012-10-17
           Statement:
             - Effect: Allow
               Action:
                 - 'ses:SendEmail'
                 - 'ses:SendRawEmail'
               Resource: '*'

  TaskDefinition:
    Type: AWS::ECS::TaskDefinition
    Properties:
      TaskRoleArn: !Ref TaskRole
      ContainerDefinitions:
        - Name: !Sub my-container
          Essential: true
          Image: !Sub <aws-account-no>.dkr.ecr.eu-west-1.amazonaws.com/mycontainer
          Memory: 2048
          Cpu: 1024

  CloudWatchEventECSRole:
   Type: AWS::IAM::Role
   Properties:
     AssumeRolePolicyDocument:
       Version: 2012-10-17
       Statement:
         - Effect: Allow
           Principal:
             Service:
               - events.amazonaws.com
           Action:
             - sts:AssumeRole
     Path: /
     Policies:
       - PolicyName: CloudwatchEventsInvokeECSRunTask
         PolicyDocument:
           Version: 2012-10-17
           Statement:
             - Effect: Allow
               Action: 'ecs:RunTask'
               Resource: !Ref TaskDefinition

  TaskSchedule:
    Type: AWS::Events::Rule
    Properties:
      Description: Runs every 10 minutes
      Name: ScheduledTask
      ScheduleExpression: cron(0/10 * * * ? *)
      State: ENABLED
      Targets:
        - Id: ScheduledEcsTask
          RoleArn: !GetAtt CloudWatchEventECSRole.Arn
          EcsParameters:
            TaskDefinitionArn: !Ref TaskDefinition
            TaskCount: 1
          Arn: !Ref ClusterArn

Remarque: J'ai ajouté le ClusterArn en tant que paramètre au script mais bien sûr, il est préférable de le faire avec une instruction CloudFormation ImportValue.

Il y a deux rôles dont vous devez vous soucier, le premier est le rôle (TaskRole) pour la tâche elle-même: dans cet exemple, le conteneur envoie simplement un e-mail à l'aide de SES afin qu'il dispose des autorisations nécessaires. Le deuxième rôle (CloudWatchEventECSRole) est celui qui fait tout fonctionner, notez que dans son tableau Policies le principe est events.amazonaws.com et la ressource est la tâche ECS définie dans le modèle.

8
Stefano

Ce problème était dû au fait de ne pas définir les principaux services pour inclure events.amazonaws.com. La tâche ne pouvait pas assumer le rôle.

Shame aws n'a pas de meilleure journalisation pour les invocations infructueuses.

3
Nathan B

Si la règle a été correctement déclenchée, mais que l'appel sur la cible a échoué, vous devriez voir une trace de l'appel d'API dans l'historique des événements à l'intérieur d'AWS CloudTrail en regardant les propriétés errorCode et errorMessage :

{
   [..]
   "errorCode": "InvalidInputException",
   "errorMessage": "Artifacts type is required",
   [..]
}
1
Nicolas Barbé

Au cas où d'autres personnes viendraient ici à la recherche de la configuration nécessaire pour que cela fonctionne pour une tâche dans Fargate. Il y a une configuration supplémentaire en plus de la réponse de Stefano. L'exécution de tâches dans Fargate nécessite la configuration d'un rôle d'exécution, vous devez donc activer CloudWatchEventECSRole pour l'utiliser. Ajoutez cette déclaration à ce rôle:

{
    "Effect": "Allow",
    "Action": "iam:PassRole",
    "Resource": [
        "arn:aws:iam::<account>:role/<executionRole>"
    ]
}
1
Jonny Cundall

Pour ceux qui ont du mal à configurer des tâches planifiées sur Fargate et qui utilisent Terraform pour configurer leur cloud, jetez un œil à ce module. https://github.com/dxw/terraform-aws-ecs-scheduled-task

Il aide à configurer les tâches planifiées via CloudEvents et définit les rôles IAM appropriés.

1
bo-oz

J'ai passé des heures à essayer de résoudre ce problème, lors de la création d'une tâche planifiée ECS via la ligne de commande, la tâche a été créée mais n'a jamais démarré. Merci pour ce post, j'ai découvert en regardant EventHistory dans CloudTrail que les instances ECS étaient toutes mortes et qu'aucune instance EC2 n'était en cours d'exécution!

{
   [..]
 "errorCode": "InvalidParameterException",
 "errorMessage": "No Container Instances were found in your cluster.",
   [..]
}
0
Bisquite