Pourquoi pas mon ECS service à enregistrer la disposition des instances EC2 avec mon ELB?
J'ai un EC2 de la configuration de lancement qui construit l'ECS optimisé AMI. J'ai un groupe auto scaling qui assure que j'ai au moins deux instances disponibles à tout moment. Enfin, j'ai un équilibreur de charge.
Je suis en train de créer un ECS service qui distribue mes tâches à travers le cas de l'équilibrage de charge.
Après la lecture de la documentation pour l'ECS l'équilibrage de la charge, c'est comprendre que ma ASG ne devrait pas automatiquement enregistrer mon instances EC2 avec le ELB, car ECS prend soin de cela. Donc, mon ASG ne spécifiez pas un ELB. De même, mes ELB ne dispose pas de toutes les instances EC2.
Quand j'ai créer mon ECS service, je choisis la ELB et également sélectionner un ecsServiceRole. Après la création du service, je n'ai jamais voir toutes les instances disponibles dans l'ECS onglet Instances. En outre, le service ne parvient pas à démarrer des tâches, avec un très générique erreur de ...
service a été impossible de placer une tâche parce que les ressources ne pourraient pas être trouvés.
J'ai été à ce sujet deux jours maintenant et n'arrive pas à comprendre ce que les paramètres de configuration ne sont pas correctement configurés. Quelqu'un a une idée de ce qui pourrait être la cause de cette pas de travail?
Mise à jour @ 06/25/2015:
Je pense que cela peut avoir quelque chose à voir avec la ECS_CLUSTER de l'utilisateur des données de réglage.
Dans mon EC2 mise à l'échelle automatique de la configuration de lancement, si je laisse l'utilisateur des données d'entrée complètement vide, les instances sont créées avec une ECS_CLUSTER valeur "par défaut". Lorsque cela arrive, je vois un créé automatiquement cluster, nommé "default". Dans ce cluster par défaut, je vois les instances et peut enregistrer des tâches avec la ELB comme prévu. Mon ELB vérifier l'état de santé (HTTP) passe une fois que les tâches sont enregistrés auprès de l'ELB et tout est bon dans le monde.
Mais, si je change que ECS_CLUSTER paramètre à quelque chose de personnalisé, je ne vois jamais un cluster créé avec ce nom. Si je créer manuellement un cluster avec ce nom, le cas ne jamais devenir visible à l'intérieur du cluster. Je ne peux pas toujours vous inscrire tâches avec la ELB dans ce scénario.
Des idées?
Oui, tout est à l'aide de la même VPC et de sous-réseau. La ELB vérifier l'état de santé est HTTP, qui, si l'ECS registres des conteneurs avec mes instances correctement le travail. Je suis la suite de l'ECS, l'équilibrage de la charge de la documentation, qui dit ignorer l'enregistrement des cas avec la ELB, car ECS prend soin de cela. Je pense que le problème est avec le
ECS_CLUSTER de l'utilisateur des données de réglage. Si je laisse comme défaut, je vois créée automatiquement "par défaut" cluster, dans lequel je peux voir les instances et peut enregistrer des tâches. si je l'ai changer pour quelque chose de personnalisé, je ne vois pas un cluster en cours de création, et ne pouvez pas vous inscrire tâches.OriginalL'auteur Ryan | 2015-06-24
Vous devez vous connecter pour publier un commentaire.
En fin de compte, il a fini par être que mes instances EC2 n'étaient pas attribué des adresses IP publiques. Il semble ECS doit être en mesure de communiquer directement avec chaque instance EC2, qui exige que chaque instance d'avoir une IP publique. Je n'étais pas l'affectation de mon conteneur des instances d'adresses IP publiques parce que je pensais les avoir tous derrière un public d'équilibrage de la charge, et chaque instance de conteneur serait privé.
il semble qu'il n'a besoin d'une adresse IP publique: si j'exécute l'instance dans un sous-réseau avec un IGW sans IP publique, il ne s'enregistre pas. Mêmes paramètres mais avec IP publique et il enregistre. Le groupe de sécurité n'a pas besoin de tous les ports ouverts, de sorte qu'il est sûr de toute façon, avec l'avantage supplémentaire d'être en mesure de SSH si nous en avons besoin.
Merci ! Cela a fonctionné pour moi.
Vous avez certainement n' pas besoin d'adresses IP publiques pour chacun de vos instances privées. La bonne façon de le faire est de configurer une Passerelle Nat et fixer les portes de la table de routage qui est attaché à votre sous-réseau privé.
Mon expérience a aussi été le fait que vous besoin pour associer une adresse IP publique de votre cas. Je suis en cours d'exécution tout en sous-réseaux publics avec IGWs, et l'ECS serait seulement de découvrir le conteneur des cas, si ils avaient des adresses ip publiques associées. Voir forums.aws.amazon.com/message.jspa?messageID=751334#751334
OriginalL'auteur Ryan
J'ai eu des symptômes similaires, mais a fini par trouver la réponse dans les fichiers journaux:
/var/log/ecs/ecs-agent.2016-04-06-03:
Dans mon cas, la ressource existait mais n'était pas accessible. Il sonne comme l'OP est pointant vers une ressource qui n'existe pas ou n'est pas visible. Sont vos clusters et les instances de la même région? Les journaux doivent confirmer les détails.
En réponse à d'autres postes:
Vous n'avez PAS besoin d'adresses IP publiques.
Vous avez besoin de: l'ecsServiceRole ou équivalent IAM rôle attribué à l'instance EC2 afin de parler à l'ECS service. Vous devez également spécifier l'ECS cluster et peut être fait avec les données de l'utilisateur au cours de l'instance de lancement ou de la configuration de lancement de la définition, comme suit:
Si vous omettez de le faire sur le nouvellement lancé cas, vous pouvez le faire après que l'instance a lancé, puis redémarrez le service.
Merci. Comme certains utilisateurs point ci-dessous, c'est le
AmazonEC2ContainerServiceforEC2Rolepolitique qui doit être accordée au rôle que vous avez (typique ecsInstanceRole ou tout autre de votre propre). Dans ce cas, il suffit de fixer la politique de votre rôle devrait fonctionner sans redémarrage ou des rénovations.OriginalL'auteur MrPaws
Un autre problème qui pourrait se poser n'est pas de l'affectation d'un rôle à la véritable politique de la Configuration de Lancement. Mon rôle n'ai pas eu le
AmazonEC2ContainerServiceforEC2Rolepolitique (ou les autorisations qu'il contient)spécifié ici.OriginalL'auteur Nick Spacek
Il pourrait également être que l'ECS agent crée un fichier dans /var/lib/ecs/de données qui stocke le nom du cluster.
Si l'agent démarre pour la première fois avec le nom de cluster de "par défaut", vous devez supprimer ce fichier, puis redémarrez l'agent.
OriginalL'auteur Gareth Harcombe-Minson
Vous certainement ne pas besoin d'adresses IP publiques pour chacun de vos instances privées. La bonne (et la plus sûre façon pour ce faire est de configurer une Passerelle NAT et fixer les portes de la table de routage qui est attaché à votre sous-réseau privé.
Cela est décrit en détail dans la VPC de documentation, plus précisément Scénario 2: VPC Publics et Privés sous-Réseaux (NAT).
OriginalL'auteur Luke Peterson
Là où plusieurs couches de problèmes dans notre cas. Je vais en faire la liste, donc il peut vous donner une idée des questions à poursuivre.
Ma prison a été pour avoir 1 ECS 1 hôte. Mais ECS vous oblige à avoir 2 sous-réseaux sous votre VPC et ont chacun 1 exemple de panneau d'accueil. J'essayais juste 1 panneau d'accueil dans 1 zone de disponibilité et ne pouvait pas le faire fonctionner.
Puis l'autre problème était que le seul de la sous-réseaux a un attaché d'internet face à la passerelle. Alors l'un d'eux n'était pas accessible à partir de public.
Le résultat final a été DNS était de service, 2 IPs pour mon ELB. Et l'un des IPs et l'autre n'a pas. J'ai donc été voir aléatoire d'une erreur 404 lors de l'accès à l'équilibrage de charge réseau en utilisant le DNS public.
OriginalL'auteur David Dehghan