5

Wir haben eine Situation, in der wir einen Django-Server in der üblichen Elastic Beanstalk-Art ausführen und einen benutzerdefinierten Docker-Container anschließen möchten, der von der Django-Website verwendet wird. Bisher hat ich im Grunde die folgenden .ebextensions Konfigurationsdatei:So führen Sie Elastic Beanstalk-Befehle auf der EC2-Instanz aus, bevor Sie Ressourcen verbinden

packages: 
    yum: 
    ecs-init: [] 

files: 
    /etc/ecs/ecs.config: 
    mode: "000644" 
    owner/group: root 
    content: ECS_CLUSTER=${Ref: MyCluster} 

commands: 
    01_start_docker: sudo service docker start 
    02_start_ecs: sudo start ecs 

Resources: 
    MyCluster: 
    Type: AWS::ECS::Cluster 
    MyService: 
    Type: AWS::ECS::Service 
    Properties: 
     Cluster: ${Ref: MyCluster} 
     DesiredCount: 1 
     TaskDefinition: ${Ref: MyTask} 
    MyTask: 
    Type: AWS::ECS::TaskDefinition 
    Properties: 
     ContainerDefinitions: 
     - ... 

Das Problem ist, dass der ECS-Dienst zu starten versucht, bevor die Elastic Beanstalk-bereitgestellt EC2-Instanz mit dem Cluster registriert ist. Daher hängt die Bereitstellung in Elastic Beanstalk ab. Wenn ich manuell in die EC2-Instanz SSH-gesteuert und manuell ecs-init installiert, ecs.config erstellt und die Befehle ausgeführt habe, wird der Dienst weiterhin erstellt, und die EB-Umgebung wird erfolgreich erstellt.

Gibt es eine Möglichkeit, dem Dienst mitzuteilen, dass er warten soll, bis die von der Autoscaling-Gruppe von EB erstellte EC2-Instanz im Cluster registriert ist?

Weiterer Kontext:

  • Wir wollen, dass der Django Server in der Lage sein, die Docker-Container mit localhost zugreifen zu können, aber ich würde nicht mit einer EC2-Instanz in Ressourcen speziell Behälter bewirten die Docker entgegengesetzt werden, Wenn es leicht ist, in den automatisch skalierten EC2-Instanzen zu referenzieren
  • Wir haben den Multi-Docker-Container-Ansatz ausprobiert, aber dieser Weg scheint näher an der Verwendung von EB zu liegen (die Webserver-Dateien direkt in der Umgebung zu haben, anstatt ein Andockfenster zu erstellen) Bild für die Umgebung zu laufen)

Antwort

0

Ich löste es selbst nach dem Nachdenken darüber klarer.

Es ist nicht sinnvoll, jede EC2-Instanz zu registrieren, die Elastic Beanstalk (via AutoScaling) zum ECS-Cluster hochfährt. Es sollte nur eine Instanz der ECS-Aufgabe geben. Es ist also notwendig, eine separate EC2-Instanz zu erstellen, die eine Verbindung zum ECS-Cluster herstellt (dessen Dienst nun von der EC2-Instanz abhängen kann).

1

Versuchen Sie etwas wie unten. Da EB nur CloudFormation-Stacks ist, schauen Sie sich die Stacks an, die mit awseb anfangen - um Ihre zu finden. Sehen Sie sich dann die CF-Ressourcen an, während Ihre EB-Anwendung die Namen der vordefinierten EB-Ressourcen anzeigt, die Sie nicht in den .extensions-Erweiterungen angeben. Ich sehe AWSEBInstanceLaunchWaitCondition in meinem, was sich auf den Start der ersten Instanzen bezieht.

Resources: 
    MyService: 
    Type: AWS::ECS::Service 
    Properties: 
     Cluster: ${Ref: MyCluster} 
     DesiredCount: 1 
     TaskDefinition: ${Ref: MyTask} 
    DependsOn: AWSEBInstanceLaunchWaitCondition 
+0

Unglücklicherweise denke ich, dass die Wartebedingung für das Starten der EC2-Instanz ist. Ich würde eine Wartebedingung benötigen, die wartet, bis die 'commands'-Hooks ausgeführt werden. –

+0

Sie müssen wahrscheinlich Ihre eigene CreationPolicy-Ressource als Abhängigkeit hinzufügen (oder vielleicht eine WaitCondition) und das cfn-Signal als Befehl 03 aufrufen. Http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide /aws-attribute-creationpolicy.html – NHol

Verwandte Themen