☰

AWS ECS: Service + Autoscaling vs. Benutzerdaten-Startaufgabe

tag-icon • tag-icon amazon-web-services autoscaling aws-cli amazon-ecs
AWS ECS: Service + Autoscaling vs. Benutzerdaten-Startaufgabe

Ich versuche, ECS mithilfe des EC2-Starts zu verstehen (zumindest im Moment nicht Fargate).

Nehmen wir an, es handelt sich um eine einzelne, lang andauernde Aufgabe, die ich mit jeder Containerinstanz starten möchte. Der dafür vorgesehene Mechanismus scheint ein Dienst zu sein, der so viele Aufgabeninstanzen startet, wie ich konfiguriere. In diesem Fall beginne ich mit der gleichen Anzahl an Aufgaben wie Containerinstanzen.

Autoscaling scheint hier auf zwei Ebenen zu existieren: Der Cluster kann seine Instanzen automatisch skalieren und der Dienst kann die Anzahl der Aufgaben automatisch skalieren. Es scheint keine Möglichkeit zu geben, diese beiden Ebenen ohne Fargate zu synchronisieren.

Ein Ansatz, den ich mir ausgedacht habe, um diese Einschränkung zu umgehen, besteht darin, Scale-Out durch einen CloudWatch-Alarm auf demCluster-Cluster, und verwenden Sie dann einen Lebenszyklus-Hook bei der Instanzerstellung, um eine horizontale Skalierung des Dienstes auszulösen. Ich habe noch nicht herausgefunden, wie dies bei einer horizontalen Skalierung funktionieren würde – gibt es ein automatisch generiertes Ereignis für die horizontale Skalierung des Dienstes?

Dann

ich saheine AWS-Anleitung zum Starten einer Aufgabe beim ContainerstartDer Kern der Sache scheinen diese MIME-Benutzerdaten zu sein:

Content-Type: multipart/mixed; boundary="==BOUNDARY=="
MIME-Version: 1.0

--==BOUNDARY==
Content-Type: text/x-shellscript; charset="us-ascii"

#!/bin/bash
# Specify the cluster that the container instance should register into cluster=your_cluster_name

# Write the cluster configuration variable to the ecs.config file
# (add any other configuration variables here also)
echo ECS_CLUSTER=$cluster >> /etc/ecs/ecs.config

# Install the AWS CLI and the jq JSON parser
yum install -y aws-cli jq

--==BOUNDARY==
Content-Type: text/upstart-job; charset="us-ascii"

#upstart-job
description "Amazon EC2 Container Service (start task on instance boot)"
author "Amazon Web Services"
start on started ecs

script
    exec 2>>/var/log/ecs/ecs-start-task.log
    set -x
    until curl -s http://localhost:51678/v1/metadata
    do
        sleep 1
    done

    # Grab the container instance ARN and AWS region from instance metadata
    instance_arn=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | 
.ContainerInstanceArn' | awk -F/ '{print $NF}' )
    cluster=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .Cluster' | awk -F/ '{print $NF}' )
    region=$(curl -s http://localhost:51678/v1/metadata | jq -r '. | .ContainerInstanceArn' | awk -F: '{print $4}')

    # Specify the task definition to run at launch
    task_definition=my_task_def

    # Run the AWS CLI start-task command to start your task on this container instance
    aws ecs start-task --cluster $cluster --task-definition $task_definition --container-instances $instance_arn --started-by $instance_arn --region $region
end script
--==BOUNDARY==--

Obwohl am Anfang des Artikels ein Haftungsausschluss steht, habe ich ihn so verstanden, dass mit dieser Methode awsclizum Ausführen einer Aufgabe alle Bedenken ausgeräumt würden.

Habe ich etwas übersehen? Ist das eine brauchbare Alternative zu einem Service mit Autoscaling?

Antwort1

Nachdem ich dies mit einem Support-Mitarbeiter von AWS besprochen habe, scheint dies eine ziemlich gute Lösung für mein Problem zu sein.

Um dies einzurichten, musste ich eine Autoscaling-Gruppe mit einer Startkonfiguration erstellen, die auf einem für Amazon ECS optimierten AMI basierte, und ihr eine Rolle mit ECS-Berechtigungen zuweisen. Dann konnte ich die Benutzerdaten wie gezeigt einbinden. Wenn alles richtig konfiguriert war (und die Instanzen über öffentlichen Internetzugang verfügten), registrierten sich die Instanzen beim Start selbst bei meinem ECS-Cluster und führten meine Aufgabe aus.

Dies wäre KEINE gute Lösung für einen Container, der unabhängig von den auszuführenden Aufgaben existiert, oder für eine Aufgabe, die bei einem Fehler neu gestartet werden kann, ohne den gesamten Container neu zu starten.

verwandte Informationen