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?
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:]
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
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.
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 ..."
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é.
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.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!
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.
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.