web-dev-qa-db-fra.com

Modèle de cloudformation pour la création de service ECS bloqué dans CREATE_IN_PROGRESS

Je crée un service AWS ECS à l'aide de Cloudformation.

Tout semble se terminer avec succès, je peux voir que l'instance est attachée à l'équilibreur de charge, l'équilibreur de charge déclare l'instance comme étant saine et si j'atteins l'équilibreur de charge, je suis correctement transféré dans mon conteneur en cours d'exécution. 

En regardant le panneau de commande ECS, je peux voir que le service s'est stabilisé et que tout semble aller pour le mieux. Je peux également voir que le conteneur est stable et qu'il n'est pas arrêté/recréé.

Cependant, le modèle Cloudformation ne se termine jamais, il est bloqué dans CREATE_IN_PROGRESS jusqu'à environ 30 à 60 minutes plus tard, lorsqu'il revient en arrière, affirmant que le service ne s'est pas stabilisé. En regardant CloudTrail, je peux voir un certain nombre de RegisterInstancesWithLoadBalancer instanciées par ecs-service-scheduler, toutes avec les mêmes paramètres, à savoir le même identifiant d'instance et le même équilibreur de charge. J'utilise des rôles et des autorisations IAM standard pour ECS. Par conséquent, il ne devrait pas s'agir d'un problème d'autorisations.

Quelqu'un a eu un problème similaire?

amazon-web-servicesamazon-cloudformationec2-container-service
14
Anvar

Votre AWS::ECS::Service doit enregistrer l'ARN complet pour la TaskDefinition (Source: Voir la réponse de ChrisB @ AWS sur les forums AWS ). L'essentiel est de définir votre TaskDefinition avec le ARN complet, révision comprise. Si vous ignorez la révision (:123 dans l'exemple ci-dessous), la dernière révision est utilisée, mais CloudFormation continue de déjeuner avec "CREATE_IN_PROGRESS" pendant environ une heure avant d'échouer. Voici une façon de le faire:

"MyService": {
    "Type": "AWS::ECS::Service",
    "Properties": {
        "Cluster": { "Ref": "ECSClusterArn" },
        "DesiredCount": 1,
        "LoadBalancers": [
            {
                "ContainerName": "myContainer",
                "ContainerPort": "80",
                "LoadBalancerName": "MyELBName"
            }
        ],
        "Role": { "Ref": "EcsElbServiceRoleArn" },
        "TaskDefinition": {
            "Fn::Join": ["", ["arn:aws:ecs:", { "Ref": "AWS::Region" },
            ":", { "Ref": "AWS::AccountId" },
            ":task-definition/my-task-definition-name:123"]]}
        }
    }
}

Voici un moyen astucieux de récupérer la dernière révision de MyTaskDefinition via les commandes aws cli et jq : 

aws ecs list-task-definitions --family-prefix MyTaskDefinition | jq --raw-output .taskDefinitionArns[0][-1:]
12
Pete

Il n'est pas nécessaire d'enregistrer l'ARN complet pour la définition de tâche, car lorsque l'ID logique de cette ressource est fourni à la fonction intrinsèque de Ref, Ref renvoie l'ARN (Amazon Resource Name).

Dans l'exemple suivant, la fonction Ref renvoie l'ARN de la tâche MyTaskDefinition, telle que arn: aws: ecs: us-west-2: 123456789012: task/1abf0f6d-a411-4033-b8eb-a4eed3ad252a.

{"Ref": "MyTaskDefinition"}

Source http://docs.aws.Amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-ecs-taskdefinition.html

6
adilr00t

Je pense que j'ai eu le même problème. Essayez de rechercher la propriété "DesiredCount" dans le modèle de service. Je pense que CloudFormation indiquera que la création/mise à jour est toujours en cours jusqu'à ce que le Service atteigne ce nombre de "DesiredCount" dans votre cluster.

6
Aymen Chetoui

Tout ce qui empêche la définition du service ECS d'atteindre le nombre souhaité . Un exemple est l'absence d'autorisations dans les stratégies attachées au rôle utilisé par les instances. Consultez les journaux de l'agent ECS d'instances (/var/log/ecs/ecs-agent.log. timestamp ).

Autre exemple: Les instances ne disposent pas de suffisamment de mémoire pour correspondre aux événements demandés Nombre souhaité .... 

"... service myService n'a pas pu placer de tâche car aucune instance de conteneur ne répond à toutes ses exigences. L'instance de conteneur la plus proche, 123456789, dispose de suffisamment de mémoire ..."

2
user6118264

J'ai trouvé un autre scénario connexe qui provoquerait ceci et j'ai pensé le mettre ici au cas où quelqu'un d'autre le rencontrerait. Si vous définissez une TaskDefinition avec une image qui n'existe pas réellement dans sa ContainerDefinition et que vous essayez ensuite d'exécuter cette TaskDefinition en tant que service, vous rencontrerez le même problème de blocage (ou du moins quelque chose qui ressemble au même problème). .

NOTE: Les exemples de fragments YAML ci-dessous étaient tous dans le même modèle CloudFormation

Ainsi, à titre d'exemple, j'ai créé cette Repository:

MyRepository:
    Type: AWS::ECR::Repository

Et puis j'ai créé cette Cluster:

MyCluster:
    Type: AWS::ECS::Cluster

Et cette TaskDefinition (abrégée):

MyECSTaskDefinition:
    Type: AWS::ECS::TaskDefinition
    Properties:
        # ...
        ContainerDefinitions:
            # ...
              Image: !Join ["", [!Ref "AWS::AccountId", ".dkr.ecr.", !Ref "AWS::Region", ".amazonaws.com/", !Ref MyRepository, ":1"]]
            # ...

Avec ceux définis, je suis allé créer une Service comme ceci:

MyECSServiceDefinition:
    Type: AWS::ECS::Service
    Properties:
        Cluster: !Ref MyCluster
        DesiredCount: 2
        PlacementStrategies:
            - Type: spread
              Field: attribute:ecs.availability-zone
        TaskDefinition: !Ref MyECSTaskDefinition

Tout cela me semblait raisonnable, mais il s’avère qu’il ya deux problèmes avec l’écriture/déploiement qui l’ont causé.

  1. La valeur DesiredCount est définie sur 2, ce qui signifie qu'il essaiera de lancer le service et de l'exécuter, pas seulement de le définir. Si je règle DesiredCount à 0, cela fonctionne très bien.
  2. La Image définie dans MyECSTaskDefinition n'existe pas encore. J'ai créé le référentiel dans le cadre de ce modèle, mais je n'y ai rien poussé. Ainsi, lorsque la MyECSServiceDefinition a essayé de créer la DesiredCount de 2 instances, elle s’est bloquée car l’image n’était pas réellement disponible dans le référentiel (car le référentiel venait littéralement d’être créé dans le même modèle).

Donc, pour l'instant, la solution consiste à créer la pile CloudFormation avec une DesiredCount de 0 pour la Service, télécharger la Image appropriée dans le référentiel, puis mettre à jour la pile CloudFormation pour mettre à l'échelle le service. Ou bien, vous pouvez également utiliser un modèle distinct pour configurer l’infrastructure principale, comme le référentiel, télécharger les versions correspondantes, puis créer un modèle distinct pour configurer la Services.

Espérons que cela aide quiconque ayant ce problème!

2
Brent Writes Code

J'ai eu le même problème. J'ai résolu en augmentant la taille de mémoire allouée pour la définition de tâche.

Le ou les conteneurs que vous exécutez ne doivent pas dépasser la mémoire disponible sur votre instance ECS.

0
thishandp7

Pour ajouter une autre possibilité, j’ai rencontré ce problème une fois où tout fonctionnait bien avec le modèle, le nombre de tâches souhaitées = nombre de tâches en cours, etc. EC2 le voyait comme "sain"). Cela empêchait CloudFormation de valider cette instance particulière. J'ai tué la mauvaise instance EC2 et ECS en a créé une vraiment saine.

0
iandw