Aufgabendefinitionsparameter - Amazon ECS

Aufgabendefinitionsparameter

Aufgabendefinitionen werden in separate Teile untergliedert: die Aufgabenfamilie, die IAM-Aufgabenrolle, den Netzwerkmodus, Container-Definitionen, Volumes, Aufgaben-Platzierungsbedingungen und Starttypen. Die Familien- und Container-Definitionen sind in einer Aufgabendefinition obligatorisch. Im Gegensatz dazu sind Aufgabenrolle, Netzwerkmodus, Volumes, Aufgabenplatzierungseinschränkungen und Starttyp optional.

Sie können diese Parameter in einer JSON-Datei verwenden, um Ihre Aufgabendefinition zu konfigurieren. Weitere Informationen finden Sie unter Beispiel für Aufgabendefinitionen.

Im Folgenden finden Sie weitere detaillierte Beschreibungen die einzelnen Aufgabendefinitionsparameter.

Familie

family

Typ: Zeichenfolge

Erforderlich: Ja

Wenn Sie eine Aufgabendefinition registrieren, vergeben Sie eine Familie, ähnlich einem Namen für mehrere Versionen der Aufgabendefinition, die mit einer Revisionsnummer angegeben ist. Die erste Aufgabendefinition, die in einer bestimmten Familie registriert wird, erhält die Revision 1 und alle danach registrierten Definitionen erhalten eine sequenzielle Revisionsnummer.

Starttypen

Wenn Sie eine Aufgabendefinition registrieren, können Sie einen Starttyp angeben, an dem Amazon ECS die Aufgabendefinition überprüfen soll. Eine Client-Ausnahme wird zurückgegeben, wenn die Aufgabendefinition nicht anhand der angegebenen Kompatibilitäten validiert. Weitere Informationen finden Sie unter Amazon ECS-Starttypen.

Der folgende Parameter ist in einer Aufgabendefinition zulässig.

requiresCompatibilities

Typ: Zeichenfolgen-Array

Erforderlich: nein

Zulässige Werte: EC2 | FARGATE | EXTERNAL

Der Starttyp, der die Aufgabendefinition validiert. Dadurch kann überprüft werden, ob alle in der Aufgabendefinition verwendeten Parameter den Anforderungen des Starttyps entsprechen.

Aufgabenausführungsrolle

executionRoleArn

Typ: Zeichenfolge

Erforderlich: nein

Der Amazon-Ressourcenname (ARN) der Aufgabenausführungsrolle, die dem Amazon ECS-Containeragenten die Berechtigung erteilt, AWS-API-Aufrufe in Ihrem Namen durchzuführen. Die IAM-Rolle für die Aufgabenausführung ist je nach den Anforderungen Ihrer Aufgabe erforderlich. Weitere Informationen finden Sie unter IAM-Rolle für die Amazon-ECS-Aufgabenausführung.

Netzwerkmodus

networkMode

Typ: Zeichenfolge

Erforderlich: nein

Der Docker-Netzwerkmodus, der für die Container in der Aufgabe verwendet werden soll. Für Amazon-ECS-Aufgaben, die auf Fargate gehostet werden, ist der awsvpc-Netzwerkmodus erforderlich.

Für den Netzwerkmodus awsvpc wird die Aufgabe einer Elastic-Network-Schnittstelle zugeordnet und Sie müssen eine NetworkConfiguration angeben, wenn Sie mit der Aufgabendefinition einen Service erstellen oder eine Aufgabe ausführen wollen. Weitere Informationen finden Sie unter Fargate-Aufgabenvernetzung im Benutzerhandbuch zum Amazon Elastic Container Service für AWS Fargate.

Der Netzwerkmodus awsvpc bietet die höchste Netzwerkleistung für Container, da er den Amazon EC2-Netzwerkstapel verwendet. Offene Container-Ports werden direkt auf dem angeschlossenen Elastic-Network-Schnittstellenport abgebildet. Aus diesem Grund können Sie keine dynamischen Host-Port-Zuordnungen nutzen.

Laufzeit-Plattform

Für Fargate-Starttypen sind folgende Parameter erforderlich.

operatingSystemFamily

Typ: Zeichenfolge

Required: Conditional

Standard: LINUX

Dieser Parameter ist für Amazon-ECS-Aufgaben erforderlich, die auf Fargate gehostet werden.

Wenn Sie eine Aufgabendefinition anmelden, geben Sie die Betriebssystemfamilie an.

Die gültigen Werte für auf Fargate gehostete Amazon-ECS-Aufgaben sind LINUX, WINDOWS_SERVER_2019_FULL und WINDOWS_SERVER_2019_CORE.

Die gültigen Werte für auf EC2 gehostete Amazon-ECS-Aufgaben sind LINUX, WINDOWS_SERVER_2022_CORE, WINDOWS_SERVER_2022_FULL, WINDOWS_SERVER_2019_FULL und WINDOWS_SERVER_2019_CORE, WINDOWS_SERVER_2016_FULL, WINDOWS_SERVER_2004_CORE und WINDOWS_SERVER_20H2_CORE.

Alle Aufgabendefinitionen, die in einem Service verwendet werden, müssen den gleichen Wert für diesen Parameter aufweisen.

Wenn eine Aufgabendefinition Teil eines Services ist, muss dieser Wert mit dem platformFamily-Wert des Services übereinstimmen.

cpuArchitecture

Typ: Zeichenfolge

Required: Conditional

Standard: X86_64

Dieser Parameter ist für Amazon-ECS-Aufgaben erforderlich, die auf Fargate gehostet werden.

Wenn Sie eine Aufgabendefinition anmelden, geben Sie die CPU-Architektur an. Die gültigen Werte sind X86_64 und ARM64.

Alle Aufgabendefinitionen, die in einem Service verwendet werden, müssen den gleichen Wert für diesen Parameter aufweisen.

Wenn Sie Linux-Aufgaben für den Fargate-Launchtyp oder den EC2-Launchtyp haben, können Sie den Wert auf ARM64 setzen. Weitere Informationen finden Sie unter Arbeiten mit 64-Bit-ARM-Workloads auf Amazon ECS.

Aufgabengröße

Wenn Sie eine Aufgabendefinition registrieren, können Sie den gesamten CPU- und Arbeitsspeicher für die Aufgabe angeben. Dies erfolgt separat von den Werten cpu und memory bei der Containerdefinition. Für Aufgaben, die auf Amazon-EC2-Instances gehostet werden, sind diese Felder optional. Für Aufgaben, die auf Fargate (Linux und Windows) gehostet werden, sind diese Felder erforderlich und es gibt für spezifische Werte für cpu und memory, die unterstützt werden.

Anmerkung

CPU- und Speicherparameter auf Aufgabenebene werden für Windows-Container ignoriert. Es wird empfohlen, für Windows-Container Ressourcen auf Container-Ebene festzulegen.

Der folgende Parameter ist in einer Aufgabendefinition zulässig:

cpu

Typ: Zeichenfolge

Erforderlich: Bedingt

Anmerkung

Dieser Parameter wird für Windows-Container nicht unterstützt.

Das harte Limit der CPU-Einheiten, die für die Aufgabe vorhanden sind. Dies kann in einer Aufgabendefinition als Ganzzahl mit CPU-Einheiten ausgedrückt werden, z. B. 1024, oder als Zeichenfolge mit vCPUs, z. B. 1 vCPU oder 1 vcpu. Wenn die Aufgabendefinition registriert ist, wird ein vCPU-Wert in eine Ganzzahl umgewandelt, die die CPU-Einheiten angibt.

Für Aufgaben, die auf Fargate gehostet werden (sowohl Linux- als auch Windows-Container), ist dieses Feld erforderlich, und Sie müssen einen der folgenden Werte verwenden, der den Bereich der unterstützten Werte für den memory-Parameter bestimmt:

CPU-Wert Speicherwert Für Fargate unterstützte Betriebssysteme
256 (0,25 vCPU) 512 MiB, 1 GB, 2 GB Linux
512 (0,5 vCPU) 1 GB, 2 GB, 3 GB, 4 GB Linux
1024 (1 vCPU) 2 GB, 3 GB, 4 GB, 5 GB, 6 GB, 7 GB, 8 GB Linux, Windows
2048 (2 vCPU) Zwischen 4 GB und 16 GB in 1-GB-Schritten Linux, Windows
4096 (4 vCPU) Zwischen 8 GB und 30 GB in 1-GB-Schritten Linux, Windows
memory

Typ: Zeichenfolge

Erforderlich: Bedingt

Anmerkung

Dieser Parameter wird für Windows-Container nicht unterstützt.

Die harte Arbeitsspeichergrenze (in MiB), die für die Aufgabe zur Verfügung steht. Dies kann in einer Aufgabendefinition als Ganzzahl mit MiB ausgedrückt werden, z. B. 1024, oder als Zeichenfolge mit GB, z. B. 1GB oder 1 GB. Wenn die Aufgabendefinition registriert ist, wird ein GB-Wert in eine Ganzzahl umgewandelt, die die MiB angibt.

Für Aufgaben, die auf Fargate gehostet werden (sowohl Linux- als auch Windows-Container), ist dieses Feld erforderlich, und Sie müssen einen der folgenden Werte verwenden, der den Bereich der unterstützten Werte für den cpu-Parameter bestimmt:

Speicherwert (MiB)

CPU-Wert

Für Fargate unterstützte Betriebssysteme

512 (0.5 GB), 1024 (1 GB), 2048 (2 GB)

256 (0,25 vCPU)

Linux

1024 (1 GB), 2048 (2 GB), 3072 (3 GB), 4096 (4 GB)

512 (0,5 vCPU)

Linux

2048 (2 GB), 3072 (3 GB), 4096 (4GB), 5120 (5 GB), 6144 (6 GB), 7168 (7 GB), 8192 (8 GB)

1024 (1 vCPU)

Linux, Windows

Zwischen 4096 (4 GB) und 16384 (16 GB) in Schritten von 1024 (1 GB)

2048 (2 vCPU)

Linux, Windows

Zwischen 8192 (8 GB) und 30720 (30 GB) in Schritten von 1024 (1 GB)

4096 (4 vCPU)

Linux, Windows

Containerdefinitionen

Wenn Sie eine Aufgabendefinition registrieren, müssen Sie eine Liste der Containerdefinitionen angeben, die an den Docker-Daemon auf einer Container-Instance übergeben werden. Die folgenden Parameter sind in einer Containerdefinition zulässig.

Standardparameter für Containerdefinition

Die folgenden Aufgabendefinitionsparameter sind in Containerdefinitionen entweder erforderlich oder werden meistens verwendet.

Name

name

Typ: Zeichenfolge

Erforderlich: Ja

Der Name eines Containers. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern, Bindestriche und Unterstriche sind zulässig. Wenn Sie mehrere Container in einer Aufgabedefinition verknüpfen, kann der name eines Containers in die links eines anderen Containers eingefügt werden. Das dient dazu, die Container zu verbinden.

Image

image

Typ: Zeichenfolge

Erforderlich: Ja

Das Image zum Starten eines Containers. Diese Zeichenfolge wird direkt an den Docker-Daemon übergeben. Images in der Docker Hub-Registrierung sind standardmäßig verfügbar. Sie können entweder mit repository-url/image:tag oder mit repository-url/image@digest auch andere Repositorys angeben. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern, Bindestriche, Unterstriche, Doppelpunkte, Punkte und Schrägstriche sind zulässig. Dieser Parameter wird Image zugeordnet im Abschnitt Create a container (Erstellen eines Containers) im Docker-Remote-API und dem IMAGE-Parameter von docker run.

  • Wenn eine neue Aufgabe gestartet wird, ruft der Amazon ECS-Container-Agent die neueste Version des angegebenen Image und das Tag für den Container ab, der verwendet werden soll. Allerdings werden nachfolgende Aktualisierungen eines Repository-Image nicht an Aufgaben übertragen, die bereits ausgeführt werden.

  • Images in privaten Registrierungen werden unterstützt. Weitere Informationen finden Sie unter Private Registrierungsauthentifizierung für Aufgaben.

  • Images in Amazon ECR-Repositorys können entweder mit der vollständigen registry/repository:tag- oder der registry/repository@digest-Namenskonvention angegeben werden (beispielsweise aws_account_id.dkr.ecr.region.amazonaws.com/my-web-app:latest oder aws_account_id.dkr.ecr.region.amazonaws.com/my-web-app@sha256:94afd1f2e64d908bc90dbca0035a5b567EXAMPLE).

  • Images in offiziellen Repositorys in Docker Hub verwenden einen einzelnen Namen (z. B. ubuntu oder mongo).

  • Images in anderen Repositorys in Docker Hub sind mit einem Organisationsnamen qualifiziert (z. B, amazon/amazon-ecs-agent).

  • Image in anderen Online-Repositorys sind durch einen Domänennamen zusätzlich qualifiziert (z. B, quay.io/assemblyline/ubuntu).

Arbeitsspeicher

memory

Typ: Ganzzahl

Erforderlich: Bedingt

Die Menge des Arbeitsspeichers (in MiB), die dem Container bereitgestellt wird. Wenn Ihr Container versucht, das hier angegebene Limit zu überschreiten, wird der Container beendet. Die gesamte Speicherkapazität, die für alle Container reserviert ist, muss niedriger sein als der Aufgabenwert memory, sofern angegeben. Dieser Parameter ordnet zu Memory im Bereich Erstellen eines Containers der Docker Remote API und der Option --memory für die docker run zu.

Wenn Sie den Fargate-Starttyp verwenden, ist dieser Parameter optional.

Der Docker-Daemon 20.10.0 oder neuer reserviert mindestens 6 MiB Arbeitsspeicher für einen Container. Geben Sie daher nicht weniger als 6 MiB Arbeitsspeicher für Ihre Container an.

Der Docker-Daemon 19.03.13-ce oder älter reserviert mindestens 4 MiB Arbeitsspeicher für einen Container. Geben Sie daher nicht weniger als 4 MiB Arbeitsspeicher für Ihre Container an.

memoryReservation

Typ: Ganzzahl

Erforderlich: nein

Die weiche Arbeitsspeichergrenze (in MiB) für die Reservierung für den Container. Wenn der Systemspeicher strittig ist, versucht Docker den Arbeitsspeicher des Containers innerhalb des weichen Limits zu halten. Ihr Container kann jedoch bei Bedarf mehr Speicher verbrauchen, bis zu dem mit dem Parameter memory (gegebenenfalls) angegebenen Hard Limit, oder den gesamten verfügbaren Speicher auf der Container-Instance, je nachdem, welcher Wert zuerst erreicht wird. Dieser Parameter ordnet zu MemoryReservation im Bereich Erstellen eines Containers der Docker Remote API und der Option --memory-reservation für die docker run zu.

Wenn kein Speicherwert auf Aufgabenebene angegeben ist, müssen Sie eine Ganzzahl ungleich Null für einen oder beide Werte von memory oder memoryReservation in einer Container-Definition angeben. Wenn Sie beide angeben, muss memory größer als memoryReservation sein. Wenn Sie memoryReservation angeben, wird dieser Wert von den verfügbaren Speicherressourcen für die Container-Instance abgezogen, auf der der Container platziert ist. Andernfalls wird der Wert memory verwendet.

Wenn Ihr Container z. B. normalerweise 128 MiB Arbeitsspeicher verbraucht, dieser Wert gelegentlich und kurzzeitig jedoch 256 MiB Arbeitsspeicher erreicht, können Sie eine memoryReservation in Höhe von 128 MiB und ein hartes Limit für memory von 300 MiB einrichten. Mit dieser Konfiguration kann der Container nur 128 MiB Arbeitsspeicher von den verbleibenden Ressourcen auf der Container-Instance reservieren. Gleichzeitig ermöglicht sie auch, dass der Container bei Bedarf mehr Speicherressourcen verwenden kann.

Anmerkung

Dieser Parameter wird für Windows-Container nicht unterstützt.

Der Docker-Daemon 20.10.0 oder neuer reserviert mindestens 6 MiB Arbeitsspeicher für einen Container. Geben Sie daher nicht weniger als 6 MiB Arbeitsspeicher für Ihre Container an.

Der Docker-Daemon 19.03.13-ce oder älter reserviert mindestens 4 MiB Arbeitsspeicher für einen Container. Geben Sie daher nicht weniger als 4 MiB Arbeitsspeicher für Ihre Container an.

Port-Zuweisungen

portMappings

Typ: Objekt-Array

Erforderlich: nein

Port-Zuweisungen ermöglichen Containern den Zugriff auf Ports der Host-Container-Instance, um Datenverkehr zu senden oder zu empfangen.

Legen Sie für Aufgabendefinitionen, die den Netzwerkmodus awsvpc verwenden, nur containerPort fest. hostPort kann leer bleiben oder muss denselben Wert wie containerPort haben.

Dieser Parameter ordnet zu PortBindings im Bereich Erstellen eines Containers der Docker Remote API und der Option --publish für die docker run zu. Wenn der Netzwerkmodus einer Aufgabendefinition auf host festgelegt ist, müssen die Host-Ports entweder undefiniert sein oder mit dem Container-Port in der Port-Zuweisung übereinstimmen.

Anmerkung

Nachdem eine Aufgabe den Status RUNNING erreicht hat, sind manuelle und automatische Host- und Container-Port-Zuordnungen an den folgenden Orten sichtbar:

  • Konsole: Abschnitt Network Bindings (Netzwerk-Bindungen) einer Container-Beschreibung für eine bestimmte Aufgabe.

  • AWS CLI: Der Abschnitt networkBindings der Befehlsausgabe describe-tasks.

  • API: DescribeTasks-Antwort.

containerPort

Typ: Ganzzahl

Erforderlich: ja, wenn portMappings verwendet werden

Die Port-Nummer auf dem Container, der an den vom Benutzer angegebenen oder automatisch zugewiesenen Host-Port gebunden ist.

Wenn Sie Container in einer Aufgabe mit dem Starttyp Fargate verwenden, müssen offengelegte Ports mit containerPort spezifiziert werden.

Für Windows-Container auf Fargate können Sie Port 3150 nicht als containerPort verwenden. Das liegt daran, dass er reserviert ist.

Wenn Sie Container in einer Aufgabe mit dem Starttyp EC2 verwenden und einen Container-Port und keinen Host-Port angeben, erhält Ihr Container automatisch einen Host-Port im flüchtigen Port-Bereich. Weitere Informationen finden Sie unter hostPort. Port-Zuweisungen, die auf diese Weise automatisch zugewiesen werden, werden beim Limit der 100 reservierten Ports für eine Container-Instance nicht mitgezählt.

hostPort

Typ: Ganzzahl

Erforderlich: nein

Die Port-Nummer auf der Container-Instance, die für Ihren Container reserviert werden soll.

Wenn Sie Container in einer Aufgabe mit dem Starttyp Fargate verwenden, kann hostPort entweder leer bleiben oder muss denselben Wert wie containerPort haben.

Wenn Sie Container in einer Aufgabe mit dem EC2-Launchtyp verwenden, können Sie einen nicht reservierten Host-Port für Ihr Container-Port-Mapping festlegen (dies wird als statisches Host-Port-Mapping bezeichnet) oder den hostPort auslassen (bzw. auf 0 setzen), während Sie einen containerPort angeben. Ihr Container erhält dann automatisch einen Port (dies wird als dynamisches Host-Port-Mapping bezeichnet) im flüchtigen Port-Bereich für das Betriebssystem Ihrer Container-Instance und die Docker-Version.

Der standardmäßige flüchtige Port-Bereich für Docker-Version 1.6.0 und später wird in der Instance unter /proc/sys/net/ipv4/ip_local_port_range aufgelistet. Wenn dieser Kernel-Parameter nicht verfügbar ist, wird der standardmäßige flüchtige Port-Bereich von 49153–65535 verwendet. Versuchen Sie nicht, einen Host-Port im flüchtigen Portbereich anzugeben. Das liegt daran, dass diese für die automatische Zuweisung reserviert sind. Im Allgemeinen zählen Ports unter 32768 nicht zum flüchtigen Port-Bereich.

Die standardmäßigen reservierten Ports sind 22 für SSH, die Docker-Ports 2375 und 2376 und der Amazon ECS-Container-Agenten-Port 51678-51680. Ein Host-Port, der zuvor für eine laufende Aufgabe vom Benutzer angegeben wurde, wird ebenfalls reserviert, während die Aufgabe ausgeführt wird (nach Beenden einer Aufgabe wird der Host-Port wieder freigegeben). Die aktuell reservierten Ports werden in remainingResources der describe-container-instances-Ausgabe angezeigt und eine Container-Instance kann bis zu 100 reservierte Ports gleichzeitig haben, einschließlich der standardmäßig reservierten Ports. Automatisch zugewiesene Ports werden nicht auf die 100 reservierten Ports angerechnet.

protocol

Typ: Zeichenfolge

Erforderlich: nein

Das für die Port-Zuweisung verwendete Protokoll. Gültige Werte sind tcp und udp. Der Standardwert ist tcp.

Verwenden Sie die folgende Syntax, um einen Host-Port anzugeben.

"portMappings": [ { "containerPort": integer, "hostPort": integer } ... ]

Verwenden Sie die folgende Syntax, um einen Host-Port automatisch zuzuweisen.

"portMappings": [ { "containerPort": integer } ... ]

Erweiterte Parameter für Containerdefinitionen

Die folgenden erweiterten Parameter für Container-Definitionen bieten erweiterte Funktionen für den docker run-Befehl , der verwendet wird, um Container auf Ihren Amazon-ECS-Container-Instances zu starten.

Zustandsprüfung

healthCheck

Der Befehl für die Container-Zustandsprüfung und die zugehörigen Konfigurationsparameter für den Container. Dieser Parameter ist HealthCheck im Abschnitt Erstellen eines Containers der Docker Remote-API und dem Parameter HEALTHCHECK der Docker-Ausführung zugeordnet.

Anmerkung

Der Amazon-ECS-Container-Agent überwacht die in der Aufgabendefinition angegebenen Zustandsprüfungen und erstellt Berichte darüber. Amazon ECS überwacht keine Docker-Zustandsprüfungen, die in ein Container-Image eingebettet, aber nicht in der Container-Definition angegeben sind. Parameter für die Zustandsprüfung, die in einer Container-Definition angegeben sind, überschreiben Docker-Zustandsprüfungen, die im Container-Image vorhanden sind.

Sie können den Integritätsstatus einzelner Container und einer Aufgabe mit der DescribeTasks-API-Operation oder beim Anzeigen der Aufgabendetails in der Konsole anzeigen.

Im Folgenden werden die möglichen healthStatus-Werte für einen Container beschrieben:

  • HEALTHY: Die Containerintegritätsprüfung wurde erfolgreich bestanden.

  • UNHEALTHY: Die Containerintegritätsprüfung ist fehlgeschlagen.

  • UNKNOWN: Die Container-Zustandsprüfung wird ausgewertet oder es ist keine Container-Zustandsprüfung definiert.

Im Folgenden werden die möglichen healthStatus-Werte für eine Aufgabe beschrieben. Der Status der Container-Zustandsprüfung von nicht entscheidenden Containern hat keine Auswirkungen auf den Integritätsstatus einer Aufgabe.

  • HEALTHY: Alle wichtigen Container innerhalb der Aufgabe haben ihre Integritätsprüfungen bestanden.

  • UNHEALTHY: Ein oder mehrere wesentliche Container haben ihre Integritätsprüfung nicht abgeschlossen.

  • UNKNOWN: Für die wesentlichen Container innerhalb der Aufgabe werden die Integritätsprüfungen weiterhin ausgewertet oder es sind keine Containerintegritätsprüfungen definiert.

Wenn eine Aufgabe manuell und nicht als Teil eines Service ausgeführt wird, wird der Lebenszyklus der Aufgabe fortgesetzt, unabhängig vom Status der Zustandsprüfung. Bei Aufgaben, die Teil eines Service sind, wird die Aufgabe gestoppt und vom Service-Scheduler ersetzt, wenn sie als fehlerhaft gemeldet wird.

Im Folgenden finden Sie Hinweise zur Unterstützung von Container-Zustandsprüfungen:

  • Container-Zustandsprüfungen werden für Aufgaben vom Typ Fargate unterstützt, wenn Sie die Linux-Plattform-Version 1.1.0 oder höher verwenden. Weitere Informationen finden Sie unter AWS Fargate-Plattformversionen.

  • Container-Zustandsprüfungen werden nicht für Aufgaben unterstützt, die Teil eines Services sind, der für die Nutzung eines Classic Load Balancers konfiguriert ist.

command

Ein Zeichenfolgen-Array, das den vom Container ausgeführten Befehl darstellt, um zu bestimmen, ob er fehlerfrei ist. Das Zeichenfolge-Array kann mit CMD beginnen, um die Befehlsargumente direkt auszuführen, oder mit CMD-SHELL, um den Befehl mit der Standard-Shell des Containers auszuführen. Ist nichts davon angegeben, wird CMD verwendet.

Wenn Sie eine Aufgabendefinition in der AWS Management Console registrieren, verwenden Sie eine durch Kommas getrennte Liste von Befehlen, die in eine Zeichenfolge konvertiert werden, nachdem die Aufgabendefinition erstellt wurde. Im Folgenden finden Sie eine Beispieleingabe für eine Zustandsprüfung.

CMD-SHELL, curl -f http://localhost/ || exit 1

Bei der Registrierung einer Aufgabendefinition mithilfe der JSON-Panel-AWS Management Console, der AWS CLI, oder den APIs sollten Sie die Liste der Befehle in eckigen Klammern einschließen. Im Folgenden finden Sie eine Beispieleingabe für eine Zustandsprüfung.

[ "CMD-SHELL", "curl -f http://localhost/ || exit 1" ]

Ein Beendigungscode von 0 ohne stderr-Ausgabe zeigt einen Erfolg an, und der Beendigungscode ungleich Null zeigt einen Fehler an. Weitere Informationen finden Sie unter HealthCheck im Bereich Create a container der Docker Remote API.

interval

Der Zeitraum (in Sekunden) zwischen den Ausführungen der Zustandsprüfung. Sie können zwischen 5 und 300 Sekunden angeben. Der Standardwert liegt bei 30 Sekunden.

timeout

Der Zeitraum (in Sekunden), der angibt, wie lange gewartet wird, bis eine Zustandsprüfung erfolgreich ist, bevor sie als fehlerhaft betrachtet wird. Sie können zwischen 2 und 60 Sekuden angeben. Der Standardwert liegt bei 5 Sekunden.

retries

Die Anzahl, wie oft eine fehlgeschlagene Zustandsprüfung wiederholt wird, bevor der Container als fehlerhaft betrachtet wird. Sie können zwischen 1 und 10 Wiederholungen angeben. Der Standardwert ist drei Wiederholungsversuche.

startPeriod

Der optionale Übergangszeitraum, der angibt, wie lange der Container Zeit für einen Bootstrap hat, bevor fehlgeschlagene Zustandsprüfungen der maximalen Anzahl an Wiederholungen angerechnet werden. Sie können zwischen 0 und 300 Sekunden angeben. Standardmäßig ist startPeriod deaktiviert.

Umgebung

cpu

Typ: Ganzzahl

Erforderlich: Bedingt

Die Anzahl der physischen cpu-Einheiten, die der Amazon-ECS-Container-Agent für den Container reserviert. In Linux ordnet dieser Parameter zu CpuShares im Bereich Erstellen eines Containers der Docker Remote API und der Option --cpu-shares für die docker run zu.

Dieses Feld ist für Aufgaben mit dem Fargate-Starttyp optional. Die Gesamtmenge an CPU, die für alle Container innerhalb einer Aufgabe reserviert ist, muss niedriger sein als der cpu-Wert auf Aufgabenebene.

Anmerkung

Sie können die Anzahl der CPU-Einheiten ermitteln, die für jeden Amazon-EC2-Instance-Typ verfügbar sind, indem Sie die Anzahl vCPUs, die für den jeweiligen Instance-Typ auf der Detailseite Amazon-EC2-Instances aufgeführt sind, mit 1 024 multiplizieren.

Linux-Container teilen sich nicht zugewiesene CPU-Einheiten mit anderen Containern auf der Container-Instance im gleichen Verhältnis wie die ihnen zugewiesene Menge. Angenommen, Sie führen eine Aufgabe für einen einzelnen Container auf einem Instance-Typ mit einem Kern aus, für den 512 CPU-Einheiten angegeben sind, und dies ist die einzige Aufgabe, die auf der Container-Instance ausgeführt wird. In diesem Beispiel kann der Container jederzeit die gesamte Menge von 1 024 CPU-Einheiten nutzen. Angenommen, Sie haben jedoch auf dieser Container-Instance eine weitere Kopie der gleichen Aufgabe gestartet. Jede Aufgabe würde bei Bedarf eine garantierte Menge von mindestens 512 CPU-Einheiten erhalten. Jeder der Container könnte automatisch mehr CPU-Einheiten nutzen, wenn diese vom anderen Container nicht verwendet werden. Wenn jedoch beide Aufgaben die ganze Zeit 100 % aktiv sind, stünden ihnen jeweils nur 512 CPU-Einheiten zur Verfügung.

Auf Linux-Container-Instances verwendet der Docker-Daemon auf der Container-Instance den CPU-Wert, um das relative CPU-Anteilsverhältnis für die laufenden Container zu berechnen. Weitere Informationen finden Sie unter CPU share constraint in der Docker-Dokumentation. Der kleinste gültige CPU-Freigabe wert, den der Linux-Kernel zulässt, ist 2. Der CPU-Parameter ist jedoch nicht erforderlich und Sie können CPU-Werte unter 2 in Ihren Container-Definitionen verwenden. Bei CPU-Werten unter 2 (einschließlich 0) variiert das Verhalten je nach Version Ihres Amazon-ECS-Container-Agenten:

  • Agentenversionen <= 1.1.0: Null-CPU-Werte werden an Docker als 0 übergeben, die von Docker dann in 1.024 CPU-Anteile konvertiert werden. CPU-Werte von 1 werden an Docker als 1 übergeben, die der Linux-Kernel in zwei CPU-Freigaben konvertiert.

  • Agentenversionen >= 1.2.0: Null-CPU-Werte und CPU-Werte von 1 werden an Docker als zwei CPU-Anteile übergeben.

Auf Windows-Container-Instances wird der CPU-Grenzwert als absolutes Kontingent festgelegt. Windows-Container haben nur auf die angegebene CPU-Menge Zugriff, die in der Aufgabendefinition definiert wird. Ein CPU-Wert mit dem Wert „NULL“ oder „null“ wird als 0 an Docker übergeben, die von Windows als 1 % einer CPU interpretiert wird.

Weitere Beispiele finden Sie unter So verwaltet Amazon ECS CPU- und Arbeitsspeicher-Ressourcen.

essential

Typ: Boolesch

Erforderlich: nein

Wenn der Parameter essential eines Containers als true gekennzeichnet ist und dieser Container ausfällt oder aus irgendeinem Grund beendet wird, werden auch alle anderen Container in der Aufgabe beendet. Wenn der Parameter essential eines Containers als false gekennzeichnet ist, wirkt sich ein Ausfall dieses Containers nicht auf die anderen Container in der Aufgabe aus. Wenn dieser Parameter ausgelassen wird, wird davon ausgegangen, dass ein Container „essential“ (entscheidend) ist.

Alle Aufgaben müssen über mindestens einen entscheidenden Container verfügen. Wenn eine Anwendung aus mehreren Containern besteht, gruppieren Sie die Container, die für einen gemeinsamen Zweck verwendet werden, in Komponenten und trennen Sie die verschiedenen Komponenten in mehrere Aufgabendefinitionen. Weitere Informationen finden Sie unter Anwendungsarchitektur.

"essential": true|false
entryPoint
Wichtig

Von frühen Versionen des Amazon-ECS-Container-Agenten werden die entryPoint-Parameter nicht korrekt verarbeitet. Wenn Sie Probleme bei der Verwendung von entryPoint haben, aktualisieren Sie Ihren Container-Agenten oder geben Sie Ihre Befehle und Argumente stattdessen als command-Array-Objekte an.

Typ: Zeichenfolgen-Array

Erforderlich: nein

Der Eintrittspunkt, der an den Container übergeben wird. Dieser Parameter ordnet zu Entrypoint im Bereich Erstellen eines Containers der Docker Remote API und der Option --entrypoint für die docker run zu. Weitere Informationen zum Docker-Parameter ENTRYPOINT finden Sie unter https://docs.docker.com/engine/reference/builder/#entrypoint.

"entryPoint": ["string", ...]
command

Typ: Zeichenfolgen-Array

Erforderlich: nein

Der Befehl, der an den Container übergeben wird. Dieser Parameter ist Cmd im Abschnitt Erstellen eines Containers der Docker Remote-API und dem Parameter COMMAND von docker run zugeordnet. Weitere Informationen zum Docker-Parameter CMD finden Sie unter https://docs.docker.com/engine/reference/builder/#cmd. Wenn mehrere Argumente vorhanden sind, stellen Sie sicher, dass jedes Argument eine getrennte Zeichenfolge im Array ist.

"command": ["string", ...]
workingDirectory

Typ: Zeichenfolge

Erforderlich: nein

Das Arbeitsverzeichnis, in dem Befehle im Container ausgeführt werden sollen. Dieser Parameter ordnet zu WorkingDir im Bereich Erstellen eines Containers der Docker Remote API und der Option --workdir für die docker run zu.

"workingDirectory": "string"
environment

Typ: Objekt-Array

Erforderlich: nein

Die Umgebungsvariablen, die an einen Container übergeben werden. Dieser Parameter ordnet zu Env im Bereich Erstellen eines Containers der Docker Remote API und der Option --env für die docker run zu.

Wichtig

Die Verwendung von Klartext-Umgebungsvariablen für sensitive Informationen (wie etwa Zugangsdaten) wird nicht empfohlen.

name

Typ: Zeichenfolge

Erforderlich: ja, wenn environment verwendet wird

Der Name der Umgebungsvariable.

value

Typ: Zeichenfolge

Erforderlich: ja, wenn environment verwendet wird

Der Wert der Umgebungsvariable.

"environment" : [ { "name" : "string", "value" : "string" }, { "name" : "string", "value" : "string" } ]
secrets

Typ: Objekt-Array

Erforderlich: Nein

Ein Objekt, durch das das Geheimnis dargestellt wird, das dem Container zur Verfügung gestellt werden soll. Weitere Informationen finden Sie unter Angabe sensibler Daten.

name

Typ: Zeichenfolge

Erforderlich: Ja

Der Wert, der als Umgebungsvariable auf dem Container eingestellt werden soll.

valueFrom

Typ: Zeichenfolge

Erforderlich: Ja

Das Geheimnis, das dem Container exponiert werden muss. Die unterstützten Werte sind entweder der vollständige Amazon Resource Name (ARN) des AWS Secrets Manager-Secrets oder der vollständige ARN des Parameters im AWS Systems Manager-Parameterspeicher.

Anmerkung

Wenn sich der Systems Manager Parameter Store-Parameter in der gleichen AWS-Region wie die Aufgabe befindet, die Sie starten, können Sie entweder den vollständigen ARN oder den Namen des Secrets verwenden. Wenn der Parameter in einer anderen Region existiert, muss der volle ARN angegeben werden.

"secrets": [ { "name": "environment_variable_name", "valueFrom": "arn:aws:ssm:region:aws_account_id:parameter/parameter_name" } ]

Network settings (Netzwerkeinstellungen)

dnsServers

Typ: Zeichenfolgen-Array

Erforderlich: nein

Eine List der DNS-Server, die dem Container bereitgestellt werden. Dieser Parameter ordnet zu Dns im Bereich Erstellen eines Containers der Docker Remote API und der Option --dns für die docker run zu.

Anmerkung

Dieser Parameter wird nicht für Windows-Container oder Aufgaben unterstützt, die den Netzwerkmodus awsvpc verwenden.

"dnsServers": ["string", ...]

Speicher und Protokollierung

readonlyRootFilesystem

Typ: Boolesch

Erforderlich: nein

Wenn dieser Parameter den Wert „true“ aufweist, erhält der Container Lesezugriff auf das Root-Dateisystem. Dieser Parameter ordnet zu ReadonlyRootfs im Bereich Erstellen eines Containers der Docker Remote API und der Option --read-only für die docker run zu.

Anmerkung

Dieser Parameter wird für Windows-Container nicht unterstützt.

"readonlyRootFilesystem": true|false
mountPoints

Typ: Objekt-Array

Erforderlich: Nein

Die Mountingpunkte für Daten-Volumes in Ihrem Container.

Dieser Parameter ordnet zu Volumes im Bereich Erstellen eines Containers der Docker Remote API und der Option --volume für die docker run zu.

Windows-Container können ganze Verzeichnisse auf dem gleichen Laufwerk wie $env:ProgramData mounten. Windows-Container können keine Verzeichnisse auf einem anderen Laufwerk mounten, und es ist kein laufwerksübergreifender Mountingpunkt möglich.

sourceVolume

Typ: Zeichenfolge

Erforderlich: Ja, wenn mountPoints verwendet werden

Der Name des zu mountenden Volumes.

containerPath

Typ: Zeichenfolge

Erforderlich: Ja, wenn mountPoints verwendet werden

Der Pfad auf dem Container, auf dem das Volume gemountet werden soll.

readOnly

Typ: Boolesch

Erforderlich: Nein

Wenn dieser Wert true lautet, verfügt der Container über schreibgeschützten Zugriff auf das Volume. Lautet der Wert false, dann verfügt der Container über Schreibzugriff auf das Volume. Der Standardwert ist false.

volumesFrom

Typ: Objekt-Array

Erforderlich: Nein

Die Daten-Volumens, die von einem anderen Container gemountet werden sollen. Dieser Parameter ordnet zu VolumesFrom im Bereich Erstellen eines Containers der Docker Remote API und der Option --volumes-from für die docker run zu.

sourceContainer

Typ: Zeichenfolge

Erforderlich: ja, wenn volumesFrom verwendet wird

Der Name des Containers, von dem die Volumes gemountet werden.

readOnly

Typ: Boolesch

Erforderlich: nein

Wenn dieser Wert true lautet, verfügt der Container über schreibgeschützten Zugriff auf das Volume. Lautet der Wert false, dann verfügt der Container über Schreibzugriff auf das Volume. Der Standardwert ist false.

"volumesFrom": [ { "sourceContainer": "string", "readOnly": true|false } ]
logConfiguration

Typ: LogConfiguration-Objekt

Erforderlich: nein

Die Angabe der Protokollkonfiguration für den Container.

Beispiele für Aufgabendefinitionen, die eine Protokollkonfiguration verwenden, finden Sie unter Beispiel für Aufgabendefinitionen.

Dieser Parameter ordnet zu LogConfig im Bereich Erstellen eines Containers der Docker Remote API und der Option --log-driver für die docker run zu. Standardmäßig verwenden Container den gleichen Protokolltreiber wie der Docker-Daemon. Allerdings kann der Container einen anderen Protokolltreiber als der Docker-Daemon verwenden, indem Sie einen Protokolltreiber mit diesem Parameter in der Container-Definition angeben. Um für einen Container einen anderen Protokolltreiber zu verwenden, muss das Protokollsystem auf der Container-Instance (oder einem anderen Protokollserver für die Remote-Protokollierung) ordnungsgemäß konfiguriert sein. Weitere Informationen zu den Optionen für die verschiedenen unterstützten Protokolltreiber finden Sie unter Configure logging drivers (Protokolltreiber konfigurieren) in der Docker-Dokumentation.

Beachten Sie die folgenden Punkte, wenn eine Protokollkonfiguration für Ihre Container angegeben ist:

  • Amazon ECS unterstützt einen Teil der Protokolltreiber, die für den Docker-Daemon verfügbar sind (siehe folgende gültige Werte). Es ist möglich, dass in zukünftigen Releases des Amazon-ECS-Container-Agenten weitere Protokolltreiber zur Verfügung stehen.

  • Für diesen Parameter muss Ihre Docker Remote API Version 1.18 oder höher in Ihrer Container-Instance verwenden.

  • Für Aufgaben mit dem Fargate-Starttyp muss jegliche zusätzliche erforderliche Software außerhalb der Aufgabe installiert werden, da Sie keinen Zugriff auf die zugrunde liegende Infrastruktur haben, auf der Ihre Aufgaben gehostet werden. Beispiel: Die Fluentd-Ausgangsaggregatoren oder ein Remote-Host, auf dem Logstash ausgeführt wird, um Gelf-Protokolle dorthin zu senden.

"logConfiguration": { "logDriver": "awslogs","fluentd","gelf","json-file","journald","logentries","splunk","syslog","awsfirelens", "options": {"string": "string" ...}, "secretOptions": [{ "name": "string", "valueFrom": "string" }] }
logDriver

Typ: Zeichenfolge

Zulässige Werte: "awslogs","fluentd","gelf","json-file","journald","logentries","splunk","syslog","awsfirelens"

Erforderlich: ja, wenn logConfiguration verwendet wird

Der für den Container zu verwendende Protokolltreiber. Standardmäßig sind die zuvor aufgeführten gültigen Werte Protokolltreiber, mit denen der Amazon-ECS-Container-Agent kommunizieren kann.

Für Aufgaben mit dem Fargate-Starttyp lauten die unterstützten Protokolltreiber awslogs, splunk und awsfirelens.

Weitere Informationen zur Verwendung des Protokolltreibers awslogs in Aufgabendefinitionen zum Senden Ihrer Containerprotokolle an Amazon CloudWatch Logs finden Sie unter Verwenden des awslogs-Protokolltreibers.

Weitere Informationen zur Verwendung des Protokolltreibers awsfirelens finden Sie unter Routing benutzerdefinierter Protokolle.

Für diesen Parameter muss Ihre Docker Remote API Version 1.18 oder höher in Ihrer Container-Instance verwenden.

options

Typ: Abbildung einer Zeichenfolge auf eine Zeichenfolge

Erforderlich: nein

Die Konfigurationsoptionen zum Senden an den Protokolltreiber.

Wenn Sie FireLens zum Weiterleiten von Protokollen an einen AWS-Service oder ein AWS-Partnernetzwerk (APN)-Ziel für die Protokollspeicherung und -Analytik verwenden, können Sie die Option log-driver-buffer-limit festlegen, um die Anzahl der Ereignisse zu begrenzen, bevor sie an den Protokollroutercontainer gesendet werden. Es kann helfen, ein potenzielles Problem mit dem Verlust von Protokollen zu beheben, da ein hoher Durchsatz dazu führen könnte, dass der Speicher für Puffer innerhalb von Docker ausgeht. Weitere Informationen finden Sie unter Fluentd-Pufferlimit.

Für diesen Parameter muss Ihre Docker Remote API Version 1.19 oder höher in Ihrer Container-Instance verwenden.

secretOptions

Typ: Objekt-Array

Erforderlich: nein

Ein Objekt, welches das Secret darstellt, der an die Protokollkonfiguration übergeben werden soll. Secrets, die in der Protokollkonfiguration verwendet werden, können z. B, ein Authentifizierungstoken, ein Zertifikat oder einen Verschlüsselungsschlüssel enthalten. Weitere Informationen finden Sie unter Angabe sensibler Daten.

name

Typ: Zeichenfolge

Erforderlich: Ja

Der Wert, der als Umgebungsvariable auf dem Container eingestellt werden soll.

valueFrom

Typ: Zeichenfolge

Erforderlich: Ja

Das Geheimnis zur Bereitstellung der Protokollkonfiguration des Containers.

"logConfiguration": { "logDriver": "splunk", "options": { "splunk-url": "https://cloud.splunk.com:8080", "splunk-token": "...", "tag": "...", ... }, "secretOptions": [{ "name": "splunk-token", "valueFrom": "/ecs/logconfig/splunkcred" }] }
firelensConfiguration

Typ: Objekt FirelensConfiguration

Erforderlich: Nein

Die FireLens-Konfiguration für den Container. Dies wird verwendet, um einen Protokollrouter für Container-Protokolle anzugeben und zu konfigurieren. Weitere Informationen finden Sie unter Routing benutzerdefinierter Protokolle.

{ "firelensConfiguration": { "type": "fluentd", "options": { "KeyName": "" } } }
options

Typ: Abbildung einer Zeichenfolge auf eine Zeichenfolge

Erforderlich: Nein

Die Optionen, die bei der Konfiguration des Protokollrouters verwendet werden sollen. Dieses Feld ist optional und kann verwendet werden, um eine benutzerdefinierte Konfigurationsdatei anzugeben oder dem Protokollereignis zusätzliche Metadaten hinzuzufügen, z. B. Aufgaben-, Aufgabendefinitions-, Cluster- und Container-Instance-Details. Wenn angegeben, ist die zu verwendende Syntax "options":{"enable-ecs-log-metadata":"true|false","config-file-type:"s3|file","config-file-value":"arn:aws:s3:::mybucket/fluent.conf|filepath"}. Weitere Informationen finden Sie unter Erstellen einer Aufgabendefinition, die eine FireLens-Konfiguration verwendet.

type

Typ: Zeichenfolge

Erforderlich: Ja

Der zu verwendende Protokollrouter. Die gültigen Werte sind fluentd und fluentbit.

Sicherheit

user

Typ: Zeichenfolge

Erforderlich: nein

Der Benutzer, der im Container verwendet werden soll. Dieser Parameter ordnet zu User im Bereich Erstellen eines Containers der Docker Remote API und der Option --user für die docker run zu.

Sie können den user mit den folgenden Formaten angeben. Wenn Sie eine UID oder GID angeben, müssen Sie sie als positive Ganzzahl angeben.

  • user

  • user:group

  • uid

  • uid:gid

  • user:gid

  • uid:group

Anmerkung

Dieser Parameter wird für Windows-Container nicht unterstützt.

"user": "string"

Ressourcenlimits

ulimits

Typ: Objekt-Array

Erforderlich: nein

Eine Liste von ulimit-Werten, die für einen Container definiert werden sollen. Dieser Wert überschreibt die Standardeinstellung für das Ressourcenkontingent für das Betriebssystem. Dieser Parameter ordnet zu Ulimits im Bereich Erstellen eines Containers der Docker Remote API und der Option --ulimit für die docker run zu.

Amazon-ECS-Aufgaben, die auf Fargate gehosted werden, verwenden die Standardwerte für Ressourcenlimits, die vom Betriebssystem gesetzt wurden. Ausgenommen ist der Ressourcenlimitparameter nofile, den Fargate überschreibt. Das Ressourcenlimit nofile beschränkt die Anzahl der geöffneten Dateien, die ein Container verwenden kann. Das weiche nofile-Standardlimit ist 1024, das harte Limit 4096.

Für diesen Parameter muss Ihre Docker Remote API Version 1.18 oder höher in Ihrer Container-Instance verwenden.

Anmerkung

Dieser Parameter wird für Windows-Container nicht unterstützt.

"ulimits": [ { "name": "core"|"cpu"|"data"|"fsize"|"locks"|"memlock"|"msgqueue"|"nice"|"nofile"|"nproc"|"rss"|"rtprio"|"rttime"|"sigpending"|"stack", "softLimit": integer, "hardLimit": integer } ... ]
name

Typ: Zeichenfolge

Zulässige Werte: "core" | "cpu" | "data" | "fsize" | "locks" | "memlock" | "msgqueue" | "nice" | "nofile" | "nproc" | "rss" | "rtprio" | "rttime" | "sigpending" | "stack"

Erforderlich: ja, wenn ulimits verwendet werden

Der type des ulimit-Werts.

hardLimit

Typ: Ganzzahl

Erforderlich: ja, wenn ulimits verwendet werden

Das harte Limit für den ulimit-Typ.

softLimit

Typ: Ganzzahl

Erforderlich: ja, wenn ulimits verwendet werden

Das weiche Limit für den ulimit-Typ.

Docker-Bezeichnungen

dockerLabels

Typ: Abbildung einer Zeichenfolge auf eine Zeichenfolge

Erforderlich: nein

Eine Schlüssel-/Wertzuordnung von Bezeichnungen, die dem Container hinzugefügt werden sollen. Dieser Parameter ordnet zu Labels im Bereich Erstellen eines Containers der Docker Remote API und der Option --label für die docker run zu.

Für diesen Parameter muss Ihre Docker Remote API Version 1.18 oder höher in Ihrer Container-Instance verwenden.

"dockerLabels": {"string": "string" ...}

Andere Parameter für die Containerdefinition

Die folgenden Parameter für die Containerdefinition können beim Registrieren von Aufgabendefinitionen in der Amazon-ECS-Konsole mit der Option Configure via JSON (Über JSON konfigurieren) verwendet werden. Weitere Informationen finden Sie unter Erstellen einer Aufgabendefinition mit der neuen Konsole.

Linux-Parameter

linuxParameters

Typ: LinuxParameters-Objekt

Erforderlich: nein

Linux-spezifische Optionen für den Container, wie z. B. KernelCapabilities.

Anmerkung

Dieser Parameter wird für Windows-Container nicht unterstützt.

"linuxParameters": { "capabilities": { "add": ["string", ...], "drop": ["string", ...] } }
capabilities

Typ: KernelCapabilities-Objekt

Erforderlich: nein

Die Linux-Funktionen für den Container, die zur von Docker bereitgestellten Standardkonfiguration werden. Weitere Informationen zu den Standardfunktionen und anderen verfügbaren Funktionen finden Sie unter Runtime privilege and Linux capabilities (Runtime-Berechtigungen und Linux-Funktionen) in der Referenz „Docker rund“. Weitere Informationen zu diesen Linux-Funktionen finden Sie auf der Linux-Handbuchseite Funktionen (7).

add

Typ: Zeichenfolgen-Array

Zulässige Werte: "SYS_PTRACE"

Erforderlich: nein

Die Linux-Funktionen für den Container, die zu der von Docker bereitgestellten Standardkonfiguration hinzugefügt werden sollen. Dieser Parameter ist CapAdd im Abschnitt Erstellen eines Containers der Docker Remote-API und der Option --cap-add für die Docker-Ausführung zugeordnet.

drop

Typ: Zeichenfolgen-Array

Zulässige Werte: "ALL" | "AUDIT_CONTROL" | "AUDIT_WRITE" | "BLOCK_SUSPEND" | "CHOWN" | "DAC_OVERRIDE" | "DAC_READ_SEARCH" | "FOWNER" | "FSETID" | "IPC_LOCK" | "IPC_OWNER" | "KILL" | "LEASE" | "LINUX_IMMUTABLE" | "MAC_ADMIN" | "MAC_OVERRIDE" | "MKNOD" | "NET_ADMIN" | "NET_BIND_SERVICE" | "NET_BROADCAST" | "NET_RAW" | "SETFCAP" | "SETGID" | "SETPCAP" | "SETUID" | "SYS_ADMIN" | "SYS_BOOT" | "SYS_CHROOT" | "SYS_MODULE" | "SYS_NICE" | "SYS_PACCT" | "SYS_PTRACE" | "SYS_RAWIO" | "SYS_RESOURCE" | "SYS_TIME" | "SYS_TTY_CONFIG" | "SYSLOG" | "WAKE_ALARM"

Erforderlich: nein

Die Linux-Funktionen für den Container, die aus der von Docker bereitgestellten Standardkonfiguration entfernt werden sollen. Dieser Parameter ist CapDrop im Abschnitt Erstellen eines Containers der Docker Remote-API und der Option --cap-drop für die Docker-Ausführung zugeordnet.

initProcessEnabled

Führen Sie einen init-Prozess innerhalb des Containers aus, der Signalen weiterleitet und Prozesse aufnimmt. Dieser Parameter wird der Option --init für die Docker-Ausführung zugeordnet.

Für diesen Parameter muss Ihre Docker Remote API Version 1.25 oder höher in Ihrer Container-Instance verwenden.

Container-Abhängigkeit

dependsOn

Typ: Array von ContainerDependency-Objekten

Erforderlich: nein

Die für das Starten und Herunterfahren des Containers definierten Abhängigkeiten. Ein Container kann mehrere Abhängigkeiten enthalten. Wenn eine Abhängigkeit für das Starten und das Herunterfahren des Containers definiert ist, ist sie reserviert. Ein Beispiel finden Sie unter Beispiel: Container-Abhängigkeit.

Anmerkung

Wenn ein Container keine Abhängigkeitsbeschränkung erfüllt oder ein Timeout vor dem Erfüllen der Einschränkung erfüllt, führt Amazon ECS abhängige Container nicht in den nächsten Zustand.

Für Amazon-ECS-Aufgaben, die auf Fargate gehostet werden, erfordert dieser Parameter, dass die Aufgabe oder der Service die Plattformversion 1.3.0 oder höher (Linux) oder 1.0.0 (Windows) verwendet.

"dependsOn": [ { "containerName": "string", "condition": "string" } ]
containerName

Typ: Zeichenfolge

Erforderlich: Ja

Der Container-Name, der die angegebene Bedingung erfüllen muss.

condition

Typ: Zeichenfolge

Erforderlich: Ja

Die Abhängigkeitsbedingung des Containers. Der folgenden Tabelle sind die verfügbaren Bedingungen und deren Verhalten zu entnehmen:

  • START – Diese Bedingung emuliert das heutige Verhalten von Links und Volumes. Sie überprüft, ob ein abhängiger Container gestartet wurde, bevor das Starten anderer Container zugelassen wird.

  • COMPLETE – Diese Bedingung überprüft, ob ein abhängiger Container vollständig ausgeführt (beendet) wurde, bevor das Starten anderer Container zugelassen wird. Dies kann für nicht benötigte Container hilfreich sein, die ein Skript ausführen und dann beendet werden. Diese Bedingung kann nicht für einen essentiellen Container festgelegt werden.

  • SUCCESS – Diese Bedingung ist mit COMPLETE identisch, erfordert aber auch, dass der Container mit dem Status zero beendet wird. Diese Bedingung kann nicht für einen essentiellen Container festgelegt werden.

  • HEALTHY – Diese Bedingung überprüft, ob der abhängige Container seine Docker-Zustandsprüfung bestanden hat, bevor das Starten anderer Container zugelassen wird. Dies setzt voraus, das für den abhängigen Container Zustandsprüfungen konfiguriert wurden. Diese Bedingung wird nur beim Start der Aufgabe bestätigt.

Container-Timeouts

startTimeout

Typ: Ganzzahl

Erforderlich: nein

Beispielwerte: 120

Zeitdauer (in Sekunden), die gewartet wird, bevor die Auflösung von Abhängigkeiten für einen Container aufgegeben wird.

Angenommen, Sie geben zwei Container in einer Aufgabendefinition an und containerA ist abhängig davon, dass containerB den Status COMPLETE, SUCCESS oder HEALTHY erreicht. Wenn ein startTimeout-Wert für containerB angegeben ist und es den gewünschten Status nicht innerhalb dieses Zeitraums erreicht, wird containerA nicht gestartet.

Anmerkung

Wenn ein Container keine Abhängigkeitsbeschränkung erfüllt oder ein Timeout vor dem Erfüllen der Einschränkung erfüllt, führt Amazon ECS abhängige Container nicht in den nächsten Zustand.

Für Amazon-ECS-Aufgaben, die auf Fargate gehostet werden, erfordert dieser Parameter, dass die Aufgabe oder der Service die Plattformversion 1.3.0 oder höher (Linux) verwendet.

stopTimeout

Typ: Ganzzahl

Erforderlich: nein

Beispielwerte: 120

Dauer (in Sekunden), die gewartet werden soll, bevor der Container zwangsweise beendet wird, wenn er nicht normal beendet wird.

Für Aufgaben, die den Fargate-Starttyp verwenden, erfordert die Aufgabe oder der Service die Plattformversion 1.3.0 oder höher (Linux) oder 1.0.0 oder höher (Windows). Der maximale Timeout-Wert ist 120 Sekunden. Wenn der Parameter jedoch nicht angegeben wird, wird der Standardwert 30 Sekunden verwendet.

Systemkontrollen

systemControls

Typ: SystemControl-Objekt

Erforderlich: nein

Eine Liste der einem Namespace zugeordneten Kernel-Parameter, die im Container festgelegt werden Dieser Parameter ordnet zu Sysctls im Bereich Erstellen eines Containers der Docker Remote API und der Option --sysctl für die docker run zu.

Es wird nicht empfohlen, netzwerkbezogene systemControls-Parameter für mehrere Container in einer einzelnen Aufgabe festzulegen, die den Netzwerkmodus awsvpc oder host verwendet. Dies hat folgende Gründe:

  • Wenn Sie für Aufgaben mit dem Netzwerkmodus awsvpc systemControls für einen Container festlegen, werden diese auf alle Container in der Aufgabe angewendet. Wenn Sie unterschiedliche systemControls für mehrere Container innerhalb einer einzelnen Aufgabe festlegen, werden die systemControls des zuletzt gestarteten Containers für alle Container übernommen.

  • Für Aufgaben, die den Netzwerkmodus host verwenden, wird der Netzwerk-Namespace systemControls nicht unterstützt.

Wenn Sie einen IPC-Ressourcen-Namespace für die Container in der Aufgabe einrichten, gelten folgende Bedingungen für Ihre Systemsteuerungen. Weitere Informationen finden Sie unter IPC-Modus.

  • Für Aufgaben, die den IPC-Modus host verwenden, wird der IPC-Namespace systemControls nicht unterstützt.

  • Für Aufgaben, die den IPC-Modus task verwenden, gelten die Werte des IPC-Namespace systemControls für alle Container innerhalb einer Aufgabe.

Anmerkung

Dieser Parameter wird für Windows-Container oder -Aufgaben mit dem Starttyp Fargate nicht unterstützt.

"systemControls": [ { "namespace":"string", "value":"string" } ]
namespace

Typ: Zeichenfolge

Erforderlich: nein

Der einem Namespace zugeordnete Kernel-Parameter, für den ein value festgelegt wird

Gültige IPC-Namespace-Werte: "kernel.msgmax" | "kernel.msgmnb" | "kernel.msgmni" | "kernel.sem" | "kernel.shmall" | "kernel.shmmax" | "kernel.shmmni" | "kernel.shm_rmid_forced" sowie Sysctls, die mit "fs.mqueue.*" beginnen

Gültige Netzwerk-Namespace-Werte: Sysctls, die mit "net.*" beginnen

value

Typ: Zeichenfolge

Erforderlich: nein

Der Wert für den einem Namespace zugeordneten Kernel-Parameter, der in namespace angegeben ist.

Interactive

interactive

Typ: Boolesch

Erforderlich: nein

Wenn dieser Parameter true lautet, können Sie Container-Anwendungen bereitstellen, für die stdin oder tty zugeordnet werden muss. Dieser Parameter ordnet zu OpenStdin im Bereich Erstellen eines Containers der Docker Remote API und der Option --interactive für die docker run zu.

Pseudo-Terminal

pseudoTerminal

Typ: Boolesch

Erforderlich: nein

Wenn dieser Parameter true lautet, wird ein TTY zugeordnet. Dieser Parameter ordnet zu Tty im Bereich Erstellen eines Containers der Docker Remote API und der Option --tty für die docker run zu.

Proxykonfiguration

proxyConfiguration

Typ: ProxyConfiguration-Objekt

Erforderlich: nein

Die Konfigurationsdetails für den App Mesh-Proxy.

Für Aufgaben mit dem Starttyp Fargate erfordert diese Funktion, dass die Aufgabe oder der Service von Plattformversion 1.3.0 oder höher Gebrauch macht.

Anmerkung

Dieser Parameter wird für Windows-Container nicht unterstützt.

"proxyConfiguration": { "type": "APPMESH", "containerName": "string", "properties": [ { "name": "string", "value": "string" } ] }
type

Typ: Zeichenfolge

Gültige Werte: APPMESH

Erforderlich: Nein

Der Proxy-Typ. Der einzige unterstützte Wert ist APPMESH.

containerName

Typ: Zeichenfolge

Erforderlich: Ja

Der Name des Containers, der als App Mesh-Proxy dient.

properties

Typ: Array von KeyValuePair-Objekten

Erforderlich: Nein

Der dem Container Network Interface (CNI)-Plug-In bereitzustellende Satz von Netzwerkkonfigurationsparametern, die als Schlüssel-Wert-Paare angegeben werden.

  • IgnoredUID – (Erforderlich) Die Benutzer-ID (UID) des Proxy-Containers gemäß der Definition durch den user-Parameter in einer Containerdefinition. Dadurch wird sichergestellt, dass der Proxy eigenen Datenverkehr ignoriert. Wenn IgnoredGID angegeben wird, kann dieses Feld leer sein.

  • IgnoredGID – (Erforderlich) Die Gruppen-ID (GID) des Proxy-Containers gemäß der Definition durch den user-Parameter in einer Containerdefinition. Dadurch wird sichergestellt, dass der Proxy eigenen Datenverkehr ignoriert. Wenn IgnoredUID angegeben wird, kann dieses Feld leer sein.

  • AppPorts – (Erforderlich) Die Liste der Ports, welche die Anwendung verwendet. Der Netzwerkdatenverkehr zu diesen Ports wird an den ProxyIngressPort und den ProxyEgressPort weitergeleitet.

  • ProxyIngressPort – (Erforderlich) Gibt den Port an, an den eingehender Datenverkehr zu den AppPorts geleitet wird.

  • ProxyEgressPort – (Erforderlich) Gibt den Port an, an den ausgehender Datenverkehr zu den AppPorts geleitet wird.

  • EgressIgnoredPorts – (Erforderlich) Der ausgehende Datenverkehr zu diesen angegebenen Ports wird ignoriert und nicht an den ProxyEgressPort umgeleitet. Es kann sich um eine leere Liste handeln.

  • EgressIgnoredIPs – (Erforderlich) Der ausgehende Datenverkehr zu diesen angegebenen IP-Adressen wird ignoriert und nicht an den ProxyEgressPort umgeleitet. Es kann sich um eine leere Liste handeln.

name

Typ: Zeichenfolge

Erforderlich: Nein

Der Name des Schlüssel-Wert-Paares.

value

Typ: Zeichenfolge

Erforderlich: Nein

Der Wert des Schlüssel-Wert-Paares.

Datenträger

Wenn Sie eine Aufgabendefinition registrieren, können Sie optional eine Liste von Volumes angeben, die an den Docker-Daemon auf einer Container-Instance übergeben werden sollen, die dann für den Zugriff durch andere Container auf derselben Container-Instance verfügbar ist.

Weitere Informationen finden Sie unter Verwendung von Daten-Volumes in Aufgaben.

Die folgenden Parameter sind in einer Containerdefinition zulässig.

name

Typ: Zeichenfolge

Erforderlich: Nein

Der Name des Volumes. Bis zu 255 Buchstaben (Groß- und Kleinbuchstaben), Ziffern, Bindestriche und Unterstriche sind zulässig. Auf diesen Namen wird im Parameter sourceVolume der Containerdefinitions-Objekt mountPoints verwiesen.

efsVolumeConfiguration

Typ: Objekt

Erforderlich: Nein

Dieser Parameter wird nur bei der Verwendung von Amazon EFS-Volumes angegeben.

fileSystemId

Typ: Zeichenfolge

Erforderlich: Ja

Die zu verwendende Amazon EFS-Dateisystem-ID.

rootDirectory

Typ: Zeichenfolge

Erforderlich: Nein

Das Verzeichnis im Amazon EFS-Dateisystem, das als Stammverzeichnis im Host bereitgestellt werden soll. Wenn dieser Parameter weggelassen wird, wird der Stamm des Amazon EFS-Volumes verwendet. Die Angabe / hat denselben Effekt wie das Weglassen dieses Parameters.

Wichtig

Wenn ein EFS-Zugriffspunkt in der authorizationConfig angegeben ist, muss der Stammverzeichnis-Parameter entweder weggelassen oder auf / festgelegt werden, was erzwingt, dass der Pfad für den EFS-Zugriffspunkt festgelegt wird.

transitEncryption

Typ: Zeichenfolge

Zulässige Werte: ENABLED | DISABLED

Erforderlich: Nein

Gibt an, ob die Verschlüsselung für Amazon-EFS-Daten bei der Übertragung zwischen dem Amazon-ECS-Host und dem Amazon-EFS-Server aktiviert werden soll oder nicht. Die Transit-Verschlüsselung muss aktiviert sein, wenn die Amazon-EFS-IAM-Autorisierung verwendet wird. Wenn dieser Parameter nicht angegeben ist, wird der Standardwert DISABLED verwendet. Weitere Informationen finden Sie unter Verschlüsseln von Daten während der Übertragung im Benutzerhandbuch für Amazon Elastic File System.

transitEncryptionPort

Typ: Ganzzahl

Erforderlich: Nein

Der zu verwendende Port zum Senden verschlüsselter Daten zwischen dem Amazon ECS-Host und dem Amazon EFS-Server. Wenn Sie keinen Transit-Verschlüsselungsport angeben, wird die Port-Auswahlstrategie verwendet, die der Amazon EFS-Mount-Helfer verwendet. Weitere Informationen finden Sie unter EFS-Mount-Helfer im Benutzerhandbuch für Amazon Elastic File System.

authorizationConfig

Typ: Objekt

Erforderlich: Nein

Die Autorisierungskonfigurationsdetails für das Amazon EFS-Dateisystem.

accessPointId

Typ: Zeichenfolge

Erforderlich: Nein

Die zu verwendende Zugriffspunkt-ID. Wenn ein Zugriffspunkt angegeben wird, muss der Stammverzeichniswert in efsVolumeConfiguration ausgelassen oder auf / festgelegt werden, was den auf dem EFS-Zugriffspunkt festgelegten Pfad erzwingt. Wenn ein Zugriffspunkt verwendet wird, muss in EFSVolumeConfiguration die Transitverschlüsselung aktiviert sein. Weitere Informationen finden Sie unter Arbeiten mit Amazon EFS-Zugriffspunkten im Amazon Elastic File System-Benutzerhandbuch.

iam

Typ: Zeichenfolge

Zulässige Werte: ENABLED | DISABLED

Erforderlich: Nein

Gibt an, ob die in einer Aufgabendefinition definierte Amazon-ECS-Aufgaben-IAM-Rolle beim Mounten des Amazon EFS-Dateisystems verwendet werden soll. Wenn diese Option aktiviert ist, muss die Transit-Verschlüsselung in EFSVolumeConfiguration aktiviert sein. Wenn dieser Parameter nicht angegeben ist, wird der Standardwert DISABLED verwendet. Weitere Informationen finden Sie unter IAM-Rollen für Aufgaben.

Tags (Markierungen)

Wenn Sie eine Aufgabendefinition registrieren, können Sie optional Metadatentags angeben, die auf die Aufgabendefinition angewendet werden. Mithilfe von Tags können Sie Ihre Aufgabendefinition kategorisieren und organisieren. Jedes Tag (Markierung) besteht aus einem Schlüssel und einem optionalen Wert. Sie können beide definieren. Weitere Informationen finden Sie unter Markieren Ihrer Amazon ECS-Ressourcen.

Wichtig

Fügen Sie keine personenbezogenen Daten (Personally Identifiable Information, PII) oder andere vertrauliche Informationen in Tags hinzu. Tags sind für viele AWS-Dienste zugänglich, einschließlich der Abrechnung. Tags sind nicht für private oder vertrauliche Daten gedacht.

Die folgenden Parameter sind in einem Tag-Objekt zulässig.

key

Typ: Zeichenfolge

Erforderlich: nein

Ein Teil eines Schlüssel-Wert-Paares, aus dem ein Tag besteht. Ein Schlüssel ist eine allgemeine Bezeichnung, die wie eine Kategorie für spezifischere Tag-Werte fungiert.

value

Typ: Zeichenfolge

Erforderlich: nein

Der optionale Teil eines Schlüssel-Wert-Paares, aus dem ein Tag besteht. Ein Wert fungiert als Deskriptor in einer Tag-Kategorie (Schlüssel).

Andere Parameter der Aufgabendefinition

Die folgenden Parameter für die Aufgabendefinition können beim Registrieren von Aufgabendefinitionen in der Amazon ECS-Konsole mit der Option Configure via JSON (Über JSON konfigurieren) verwendet werden. Weitere Informationen finden Sie unter Erstellen einer Aufgabendefinition mit der neuen Konsole.

Flüchtiger Speicher

ephemeralStorage

Typ: Objekt

Erforderlich: Nein

Die Menge des flüchtigen Speichers (in GB), der für die Aufgabe zugewiesen werden soll. Dieser Parameter wird verwendet, um die Gesamtmenge des flüchtigen Speichers über den Standardbetrag hinaus für Aufgaben zu erweitern, die auf AWS Fargate gehostet werden. Weitere Informationen finden Sie unter Bind-Mounts.

Anmerkung

Der Parameter wird nur für Aufgaben unterstützt, die auf AWS Fargate mit einer Plattformversion 1.4.0 oder höher (Linux) gehostet werden. Dies wird für Windows-Container auf Fargate nicht unterstützt.

IPC-Modus

ipcMode

Typ: Zeichenfolge

Erforderlich: Nein

Der IPC-Ressourcen-Namespace, der für die Container in der Aufgabe verwendet werden soll. Die gültigen Werte sind host, task oder none. Wenn host angegeben ist, dann teilen sich alle Container innerhalb der Aufgaben, die den IPC-Modus host auf derselben Container-Instance angegeben haben, die gleichen IPC-Ressourcen mit der Amazon EC2-Host-Instance. Wenn task angegeben ist, teilen sich alle Container innerhalb der angegebenen Aufgabe die gleichen IPC-Ressourcen. Wenn none angegeben ist, dann sind die IPC-Ressourcen innerhalb der Container einer Aufgabe privat und werden nicht mit anderen Containern einer Aufgabe oder der Container-Instance geteilt. Wenn kein Wert angegeben ist, wird der Wert für ipcMode auf shareable gesetzt. Weitere Informationen finden Sie unter IPC-Einstellungen in der Docker Run Referenz.

Wenn der IPC-Modus host verwendet wird, ist das Risiko einer unerwünschten Exposition des IPC-Namespace erhöht. Weitere Informationen finden Sie unter Docker-Sicherheit.

Wenn Sie im Namespace bezogene Kernelparameter mit systemControls für die Container in der Aufgabe festlegen, gilt Folgendes für Ihren IPC-Ressourcen-Namespace. Weitere Informationen finden Sie unter Systemkontrollen.

  • Für Aufgaben, die den IPC-Modus host verwenden, werden IPC-Namespace bezogene systemControls nicht unterstützt.

  • Für Aufgaben, die den IPC-Modus task verwenden, gelten IPC-Namespace bezogene systemControls für alle Container innerhalb einer Aufgabe.

Anmerkung

Dieser Parameter wird für Windows-Container oder -Aufgaben mit dem Starttyp Fargate nicht unterstützt.

PID-Modus

pidMode

Typ: Zeichenfolge

Erforderlich: Nein

Der Prozess-Namespace, der für die Container in der Aufgabe verwendet werden soll. Die gültigen Werte sind host und task. Wenn host angegeben ist, teilen sich alle Container innerhalb der Aufgaben, die den PID-Modus host auf derselben Container-Instance angegeben haben, denselben Prozess-Namespace mit der Amazon EC2-Host-Instance. Wenn task angegeben ist, teilen sich alle Container innerhalb der angegebenen Aufgabe den gleichen Prozess-Namespace. Wenn kein Wert angegeben wird, ist der Standard ein privater Namespace. Weitere Informationen finden Sie unter PID-Einstellungen in der Docker Run Referenz.

Wenn der PID-Modus host verwendet wird, ist das Risiko einer unerwünschten Exposition des Prozess-Namespace erhöht. Weitere Informationen finden Sie unter Docker-Sicherheit.

Anmerkung

Dieser Parameter wird für Windows-Container oder -Aufgaben mit dem Starttyp Fargate nicht unterstützt.