Szenario Voraussetzungen Schritt 1: Erstellen von einem Mesh und einem virtuellen Service Schritt 2: Erstellen von einem virtuellen Knoten Schritt 3: Erstellen von einem virtuellen Router und einer Route Schritt 4: Überprüfen und Erstellen Schritt 5: Erstellen zusätzlicher Ressourcen Schritt 6: Aktualisieren der Services Fortschrittliche Themen

Erste Schritte mit AWS App Mesh und Amazon ECS

Wichtig

Hinweis zum Ende des Supports: Am 30. September 2026 AWS wird der Support für eingestellt. AWS App Mesh Nach dem 30. September 2026 können Sie nicht mehr auf die AWS App Mesh Konsole oder die Ressourcen zugreifen. AWS App Mesh Weitere Informationen finden Sie in diesem Blogbeitrag Migration von AWS App Mesh zu Amazon ECS Service Connect.

Dieses Thema hilft Ihnen bei der Verwendung AWS App Mesh mit einem aktuellen Service, der auf Amazon läuftECS. Dieses Tutorial behandelt die grundlegenden Funktionen verschiedener App Mesh Mesh-Ressourcentypen.

Szenario

Gehen Sie zur Veranschaulichung der Verwendung von App Mesh davon aus, dass Sie über eine Anwendung mit den folgenden Eigenschaften verfügen:

Besteht aus zwei Diensten mit dem Namen serviceA undserviceB.
Beide Services sind in einem Namespace namens apps.local registriert.
ServiceAkommuniziert mit serviceB über HTTP /2, Port 80.
Sie haben bereits Version 2 von serviceB bereitgestellt und mit dem Namen serviceBv2 im apps.local-Namespace registriert.

Es gelten die folgenden Anforderungen:

Sie möchten 75 Prozent des Datenverkehrs von serviceA bis serviceB und 25 Prozent des Datenverkehrs an serviceBv2 First weiterleiten. Wenn Sie nur 25 Prozent des Datenverkehrs an sendenserviceBv2, können Sie überprüfen, ob es fehlerfrei ist, bevor Sie 100 Prozent des Datenverkehrs von sendenserviceA.
Sie möchten in der Lage sein, die Datenverkehrsgewichtung so anzupassen, dass 100 Prozent des Datenverkehrs an serviceBv2 gehen, sobald sich die Zuverlässigkeit davon erwiesen hat. Sobald der gesamte Datenverkehr an gesendet wurdeserviceBv2, möchten Sie den Vorgang beendenserviceB.
Sie möchten für Ihre eigentlichen Dienste keinen bestehenden Anwendungscode oder eine Registrierung zur Serviceerkennung ändern müssen, um die vorherigen Anforderungen zu erfüllen.

Um Ihren Anforderungen gerecht zu werden, entscheiden Sie sich dafür, ein App Mesh Service Mesh mit virtuellen Diensten, virtuellen Knoten, einem virtuellen Router und einer Route zu erstellen. Nach der Implementierung Ihres Meshs aktualisieren Sie Ihre Dienste so, dass sie den Envoy-Proxy verwenden. Nach der Aktualisierung kommunizieren Ihre Services miteinander über den Envoy-Proxy und nicht direkt miteinander.

Voraussetzungen

Wichtig

Ein vorhandenes Verständnis der App Mesh Mesh-Konzepte. Weitere Informationen finden Sie unter Was ist AWS App Mesh?.
Ein bestehendes Verständnis der ECSs Amazon-Konzepte. Weitere Informationen finden Sie unter Was ist Amazon ECS im Amazon Elastic Container Service Developer Guide.
App Mesh unterstützt Linux-Dienste DNS AWS Cloud Map, die bei oder beiden registriert sind. Um dieses Handbuch für die ersten Schritte verwenden zu können, empfehlen wir, dass Sie über drei bestehende Dienste verfügen, bei denen Sie registriert sindDNS. Bei den Verfahren in diesem Thema wird davon ausgegangen, dass die vorhandenen Dienste benannt serviceA sind serviceBv2 und dass alle Dienste über einen Namespace mit dem Namen auffindbar sind. serviceB apps.local

Sie können ein Service-Mesh und seine Ressourcen erstellen, auch wenn die Services nicht vorhanden sind. Sie können das Mesh jedoch erst verwenden, wenn Sie tatsächliche Services bereitgestellt haben. Weitere Informationen zu Service Discovery bei Amazon ECS finden Sie unter Service Discovery. Informationen zum Erstellen eines ECS Amazon-Service mit Service Discovery finden Sie unter Tutorial: Einen Service mithilfe von Service Discovery erstellen. Wenn Sie noch keine Dienste ausführen, können Sie einen ECS Amazon-Service mit Service Discovery erstellen.

Schritt 1: Erstellen von einem Mesh und einem virtuellen Service

Ein Service Mesh ist eine logische Begrenzung für den Netzwerkdatenverkehr zwischen den darin vorhandenen Services. Weitere Informationen finden Sie unter Servicenetze. Ein virtueller Service ist eine Abstraktion eines tatsächlichen Services. Weitere Informationen finden Sie unter Virtuelle Dienste.

Erstellen Sie die folgenden Ressourcen:

Ein Mesh mit dem Namen apps, da alle Services im Szenario im apps.local-Namespace registriert sind.
Einen virtuellen Service mit dem Namen serviceb.apps.local, da der virtuelle Service einen Service darstellt, der mit diesem Namen gefunden werden kann, und Sie Ihren Code nicht ändern möchten, um auf einen anderen Namen zu verweisen. Ein virtueller Service mit dem Namen servicea.apps.local wird in einem späteren Schritt hinzugefügt.

Sie können die AWS Management Console oder die AWS CLI Version 1.18.116 oder höher oder 2.0.38 oder höher verwenden, um die folgenden Schritte auszuführen. Wenn Sie die verwenden AWS CLI, verwenden Sie den aws --version Befehl, um Ihre installierte Version zu überprüfen. AWS CLI Wenn Sie Version 1.18.116 oder höher oder 2.0.38 oder höher nicht installiert haben, müssen Sie die installieren oder aktualisieren. AWS CLI Wählen Sie die Registerkarte für das Werkzeug aus, das Sie verwenden möchten.

Schritt 2: Erstellen von einem virtuellen Knoten

Ein virtueller Knoten fungiert als ein logischer Verweis auf einen tatsächlichen Service. Weitere Informationen finden Sie unter Virtuelle Knoten.

Erstellen Sie einen virtuellen Knoten mit dem Namen serviceB, da einer der virtuellen Knoten den tatsächlichen Service mit dem Namen serviceB darstellt. Der tatsächliche Service, den der virtuelle Knoten darstellt, kann über DNS mit dem Hostnamen von serviceb.apps.local gefunden werden. Alternativ können Sie aktuelle Dienste mithilfe von ermitteln. AWS Cloud Map Der virtuelle Knoten wartet auf Datenverkehr, der das HTTP /2-Protokoll an Port 80 verwendet. Auch andere Protokolle werden unterstützt, ebenso wie Zustandsprüfungen. Sie erstellen virtuelle Knoten für serviceA und serviceBv2 in einem späteren Schritt.

Schritt 3: Erstellen von einem virtuellen Router und einer Route

Virtuelle Router routen den Datenverkehr für einen oder mehrere virtuelle Services innerhalb Ihres Meshes. Weitere Informationen erhalten Sie unter Virtuelle Router und Routen.

Erstellen Sie die folgenden Ressourcen:

Einen virtuellen Router mit dem Namen serviceB, da der virtuelle serviceB.apps.local-Service keine ausgehende Kommunikation mit einem anderen Service initiiert. Denken Sie daran, dass der virtuelle Service, den Sie zuvor erstellt haben, eine Abstraktion Ihres tatsächlichen serviceb.apps.local-Services ist. Der virtuelle Service sendet Datenverkehr an den virtuellen Router. Der virtuelle Router überwacht den Datenverkehr mithilfe des HTTP /2-Protokolls an Port 80. Andere Protokolle werden ebenfalls unterstützt.
Eine Route namens serviceB. Er leitet 100 Prozent seines Datenverkehrs an den serviceB virtuellen Knoten weiter. Die Gewichtung erfolgt in einem späteren Schritt, sobald Sie den serviceBv2 virtuellen Knoten hinzugefügt haben. Obwohl in diesem Handbuch nicht behandelt, können Sie zusätzliche Filterkriterien für die Route hinzufügen und eine Wiederholungsrichtlinie hinzufügen, damit der Envoy-Proxy mehrere Versuche unternimmt, Datenverkehr an einen virtuellen Knoten zu senden, wenn ein Kommunikationsproblem auftritt.

AWS Management Console

Geben Sie für Virtual router name (Name des virtuellen Routers) serviceB ein.
Wählen Sie unter Listener-Konfiguration http2 als Protokoll und geben Sie als Port 80 an.
Geben Sie unter Route name (Name der Route) serviceB ein.
Wählen Sie für Route type (Routentyp) die Option http2.
Wählen Sie für den Namen des virtuellen Knotens unter Zielkonfiguration die Option Gewicht aus serviceB und geben 100 Sie den Wert ein.
Wählen Sie unter Konfiguration anpassen eine Methode aus.
Wählen Sie Next, um fortzufahren.

AWS CLI

Erstellen Sie einen virtuellen Router.

Erstellen Sie eine Datei create-virtual-router.json mit dem folgenden Inhalt:


{
    "meshName": "apps",
    "spec": {
        "listeners": [
            {
                "portMapping": {
                    "port": 80,
                    "protocol": "http2"
                }
            }
        ]
    },
    "virtualRouterName": "serviceB"
}

Erstellen Sie den virtuellen Router mit dem create-virtual-routerBefehl und verwenden Sie dabei die JSON Datei als Eingabe.
```
aws appmesh create-virtual-router --cli-input-json file://create-virtual-router.json
```

Erstellen Sie eine Route.

Erstellen Sie eine Datei create-route.json mit dem folgenden Inhalt:


{
    "meshName" : "apps",
    "routeName" : "serviceB",
    "spec" : {
        "httpRoute" : {
            "action" : {
                "weightedTargets" : [
                    {
                        "virtualNode" : "serviceB",
                        "weight" : 100
                    }
                ]
            },
            "match" : {
                "prefix" : "/"
            }
        }
    },
    "virtualRouterName" : "serviceB"
}

Erstellen Sie die Route mit dem Befehl create-route und verwenden Sie dabei die JSON Datei als Eingabe.
```
aws appmesh create-route --cli-input-json file://create-route.json
```

Schritt 4: Überprüfen und Erstellen

Überprüfen Sie die Einstellungen anhand der vorherigen Anweisungen.

Schritt 5: Erstellen zusätzlicher Ressourcen

Um das Szenario abzuschließen, müssen Sie:

Einen virtuellen Knoten mit dem Namen serviceBv2 und einen anderen mit dem Namen serviceA erstellen. Beide virtuellen Knoten warten auf Anfragen über HTTP /2 Port 80. Konfigurieren Sie für den serviceA virtuellen Knoten ein Backend vonserviceb.apps.local. Der gesamte ausgehende Datenverkehr vom serviceA virtuellen Knoten wird an den genannten virtuellen Dienst gesendet. serviceb.apps.local Obwohl dies in diesem Handbuch nicht behandelt wird, können Sie auch einen Dateipfad angeben, in den Zugriffsprotokolle für einen virtuellen Knoten geschrieben werden sollen.
Erstellen Sie einen zusätzlichen virtuellen Dienst mit dem Namenservicea.apps.local, der den gesamten Datenverkehr direkt an den serviceA virtuellen Knoten sendet.
Aktualisieren Sie die serviceB-Route, die Sie in einem vorherigen Schritt erstellt haben, so, dass 75 Prozent des Datenverkehrs an den virtuellen serviceB- Knoten und 25 Prozent des Datenverkehrs an den virtuellen serviceBv2-Knoten gesendet werden. Im Laufe der Zeit können Sie die Gewichtungen weiter ändern, bis serviceBv2 100 Prozent des Datenverkehrs erhält. Sobald der gesamte Datenverkehr an gesendet wurdeserviceBv2, können Sie den serviceB virtuellen Knoten und den eigentlichen Dienst herunterfahren und beenden. Wenn Sie Gewichtungen ändern, erfordert Ihr Code keine Änderung, da sich die Namen des virtuellen serviceb.apps.local- und des tatsächlichen Services nicht ändern. Denken Sie daran, dass der virtuelle serviceb.apps.local-Service Datenverkehr an den virtuellen Router sendet, der den Datenverkehr an die virtuellen Knoten weiterleitet. Die Serviceerkennungsnamen für die virtuellen Knoten können jederzeit geändert werden.

AWS Management Console

Wählen Sie im linken Navigationsbereich Meshes.
Wählen Sie das apps-Mesh aus, das Sie in einem vorherigen Schritt erstellt haben.
Wählen Sie im linken Navigationsbereich Virtual nodes (Virtuelle Knoten) aus.
Wählen Sie Create virtual node (Virtuellen Knoten erstellen).
Geben Sie für den Namen des virtuellen Knotens den serviceBv2 Wert ein, für die Methode zur Diensterkennung wählen Sie DNSund für DNSHostname den Wert. servicebv2.apps.local
Wählen Sie für die Listener-Konfiguration http2 als Protokoll und geben 80 Sie für Port den Wert ein.
Wählen Sie Create virtual node (Virtuellen Knoten erstellen).
Wählen Sie erneut Create virtual node (Virtuellen Knoten erstellen) aus. Geben Sie „serviceA“ als Virtual node name (Name des virtuellen Knotens) ein. Wählen Sie für Service Discovery-Methode die Option aus DNS, und geben Sie als DNSHostname ein. servicea.apps.local
Geben Sie bei Enter a virtual service name (Neuen virtuellen Service-Name eingeben) unter New backend (Neues Backend) den Wert „serviceb.apps.local“ ein.
Wählen Sie unter Listener configuration (Listener-Konfiguration) die Option http2 für Protocol (Protokoll) aus, geben Sie „80“ bei Port ein, und wählen Sie dann Create virtual node (Virtuellen Knoten erstellen) aus.
Wählen Sie im linken Navigationsbereich Virtual routers (Virtuelle Router) aus, und wählen Sie dann den virtuellen Router serviceB aus der Liste aus.
Wählen Sie unter Routes (Routen) die Route ServiceB aus, die Sie in einem vorherigen Schritt erstellt haben, und wählen Sie dann Edit (Bearbeiten) aus.
Ändern Sie unter Targets (Ziele), Virtual node name (Name des virtuellen Knotens) den Wert von Weight (Gewicht) für serviceB zu 75.
Wählen Sie Ziel hinzufügen, wählen Sie serviceBv2 aus der Dropdownliste und legen Sie den Wert für Gewicht auf fest. 25
Wählen Sie Save (Speichern) aus.
Wählen Sie im linken Navigationsbereich Virtual services (Virtuelle Services) aus, und wählen Sie dann Create virtual service (Virtuellen Dienst erstellen) aus.
Geben Sie „servicea.apps.local“ bei Virtual service name (Virtueller Dienstname) ein, wählen Sie Virtual node (Virtueller Knoten) als Provider (Anbieter), wählen Sie „serviceA“ bei Virtual node (Virtueller Knoten) und dann Create virtual service (Virtuellen Dienst erstellen) aus.

AWS CLI

Erstellen Sie den virtuellen Knoten serviceBv2.

Erstellen Sie eine Datei create-virtual-node-servicebv2.json mit dem folgenden Inhalt:


{
    "meshName": "apps",
    "spec": {
        "listeners": [
            {
                "portMapping": {
                    "port": 80,
                    "protocol": "http2"
                }
            }
        ],
        "serviceDiscovery": {
            "dns": {
                "hostname": "serviceBv2.apps.local"
            }
        }
    },
    "virtualNodeName": "serviceBv2"
}

Erstellen Sie den virtuellen Knoten.


aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-servicebv2.json

Erstellen Sie den virtuellen Knoten serviceA.

Erstellen Sie eine Datei create-virtual-node-servicea.json mit dem folgenden Inhalt:


{
   "meshName" : "apps",
   "spec" : {
      "backends" : [
         {
            "virtualService" : {
               "virtualServiceName" : "serviceb.apps.local"
            }
         }
      ],
      "listeners" : [
         {
            "portMapping" : {
               "port" : 80,
               "protocol" : "http2"
            }
         }
      ],
      "serviceDiscovery" : {
         "dns" : {
            "hostname" : "servicea.apps.local"
         }
      }
   },
   "virtualNodeName" : "serviceA"
}

Erstellen Sie den virtuellen Knoten.


aws appmesh create-virtual-node --cli-input-json file://create-virtual-node-servicea.json

Aktualisieren Sie den virtuellen Service serviceb.apps.local, den Sie in einem vorherigen Schritt erstellt haben, um seinen Datenverkehr an den virtuellen Router serviceB zu senden. Als der virtuelle Service ursprünglich erstellt wurde, sendete er keinen Datenverkehr, da der virtuelle Router serviceB noch nicht erstellt war.
1. Erstellen Sie eine Datei update-virtual-service.json mit dem folgenden Inhalt:
```
{
   "meshName" : "apps",
   "spec" : {
      "provider" : {
         "virtualRouter" : {
            "virtualRouterName" : "serviceB"
         }
      }
   },
   "virtualServiceName" : "serviceb.apps.local"
}
```
2. Aktualisieren Sie den virtuellen Dienst mit dem update-virtual-serviceBefehl.
```
aws appmesh update-virtual-service --cli-input-json file://update-virtual-service.json
```

Aktualisieren Sie die Route serviceB, die Sie in einem vorherigen Schritt erstellt haben.

Erstellen Sie eine Datei update-route.json mit dem folgenden Inhalt:


{
   "meshName" : "apps",
   "routeName" : "serviceB",
   "spec" : {
      "http2Route" : {
         "action" : {
            "weightedTargets" : [
               {
                  "virtualNode" : "serviceB",
                  "weight" : 75
               },
               {
                  "virtualNode" : "serviceBv2",
                  "weight" : 25
               }
            ]
         },
         "match" : {
            "prefix" : "/"
         }
      }
   },
   "virtualRouterName" : "serviceB"
}

Aktualisieren Sie die Route mit dem Befehl update-route .


aws appmesh update-route --cli-input-json file://update-route.json

Erstellen Sie den virtuellen Service serviceA.

Erstellen Sie eine Datei create-virtual-servicea.json mit dem folgenden Inhalt:


{
   "meshName" : "apps",
   "spec" : {
      "provider" : {
         "virtualNode" : {
            "virtualNodeName" : "serviceA"
         }
      }
   },
   "virtualServiceName" : "servicea.apps.local"
}

Erstellen Sie den virtuellen Service.


aws appmesh create-virtual-service --cli-input-json file://create-virtual-servicea.json

Mesh-Zusammenfassung

Bevor Sie das Service-Mesh erstellt haben, hatten Sie drei aktuelle Services mit den Namen servicea.apps.local, serviceb.apps.local und servicebv2.apps.local. Zusätzlich zu den tatsächlichen Services verfügen Sie jetzt über ein Service-Mesh, das die folgenden Ressourcen enthält, die die tatsächlichen Services darstellen:

Zwei virtuelle Services. Der Proxy sendet den gesamten Datenverkehr vom virtuellen Service servicea.apps.local über einen virtuellen Router an den virtuellen Service serviceb.apps.local.
Drei virtuelle Knoten mit den Namen serviceA, serviceB und serviceBv2. Der Envoy-Proxy verwendet die für die virtuellen Knoten konfigurierten Service-Erkennungsinformationen, um die IP-Adressen der tatsächlichen Services zu suchen.
Einen virtuellen Router mit einer Route, die den Envoy-Proxy anweist, 75 Prozent des eingehenden Datenverkehrs an den virtuellen Knoten serviceB und 25 Prozent des Datenverkehrs an den virtuellen Knoten serviceBv2 zu leiten.

Schritt 6: Aktualisieren der Services

Nachdem Sie Ihr Mesh erstellt haben, müssen Sie die folgenden Aufgaben ausführen:

Autorisieren Sie den Envoy-Proxy, den Sie mit jeder ECS Amazon-Aufgabe bereitstellen, die Konfiguration eines oder mehrerer virtueller Knoten zu lesen. Weitere Informationen zum Autorisieren des Proxys finden Sie unter Proxy-Autorisierung.
Aktualisieren Sie jede Ihrer vorhandenen ECS Amazon-Aufgabendefinitionen, um den Envoy-Proxy zu verwenden.

Anmeldeinformationen

Der Envoy-Container benötigt AWS Identity and Access Management Anmeldeinformationen zum Signieren von Anfragen, die an den App Mesh Mesh-Dienst gesendet werden. Für ECS Amazon-Aufgaben, die mit dem EC2 Amazon-Starttyp bereitgestellt werden, können die Anmeldeinformationen aus der Instance-Rolle oder aus einer IAMAufgabenrolle stammen. ECSAmazon-Aufgaben, die mit Fargate auf Linux-Containern bereitgestellt werden, haben keinen Zugriff auf den EC2 Amazon-Metadatenserver, der die Anmeldeinformationen für das IAM Instance-Profil bereitstellt. Um die Anmeldeinformationen bereitzustellen, müssen Sie allen Aufgaben, die mit dem Containertyp Fargate on Linux bereitgestellt werden, eine IAM Aufgabenrolle zuordnen.

Wenn eine Aufgabe mit dem EC2 Amazon-Starttyp bereitgestellt wird und der Zugriff auf den EC2 Amazon-Metadatenserver blockiert ist, wie in der Anmerkung Wichtig unter IAMRolle für Aufgaben beschrieben, muss der Aufgabe auch eine IAM Aufgabenrolle zugewiesen werden. Der Rolle, die Sie der Instance oder Aufgabe zuweisen, muss eine IAM Richtlinie zugeordnet sein, wie unter Proxy-Autorisierung beschrieben.

Um Ihre Aufgabendefinition mit dem zu aktualisieren AWS CLI

Sie verwenden den ECS AWS CLI Amazon-Befehl register-task-definition. Die folgende Beispielaufgabendefinition zeigt, wie Sie App Mesh für Ihren Dienst konfigurieren.

Anmerkung

Die Konfiguration von App Mesh für Amazon ECS über die Konsole ist nicht verfügbar.

Proxykonfiguration

Um Ihren ECS Amazon-Service für die Verwendung von App Mesh zu konfigurieren, muss die Aufgabendefinition Ihres Services den folgenden Abschnitt zur Proxykonfiguration enthalten. Stellen Sie die Proxy-Konfiguration type auf APPMESH und containerName auf envoy ein. Legen Sie die folgenden Eigenschaftswerte entsprechend fest.

IgnoredUID: Der Envoy-Proxy leitet keinen Datenverkehr von Prozessen weiter, die diese Benutzer-ID verwenden. Sie können eine beliebige Benutzer-ID für diesen Eigenschaftswert auswählen, diese ID muss jedoch mit der user-ID für den Envoy-Container in der Aufgabendefinition übereinstimmen. Diese Übereinstimmung ermöglicht Envoy, eigenen Datenverkehr zu ignorieren, ohne den Proxy zu verwenden. Unsere Beispiele verwenden 1337 für historische Zwecke.
ProxyIngressPort: Dies ist der eingehende Port für den Envoy-Proxycontainer. Legen Sie diesen Wert auf 15000 fest.
ProxyEgressPort: Dies ist der ausgehende Port für den Envoy-Proxycontainer. Legen Sie diesen Wert auf 15001 fest.
AppPorts: Geben Sie alle eingehenden Ports an, auf die Ihre Anwendungscontainer warten. In diesem Beispiel wird vom Anwendungs-Container Port 9080 überwacht. Der angegebene Port muss mit dem Port übereinstimmen, der auf dem virtuellen Knoten-Listener konfiguriert ist.
EgressIgnoredIPs: Envoy führt keine Proxy-Weiterleitung an diese IP-Adressen durch. Setzen Sie diesen Wert auf169.254.170.2,169.254.169.254, wodurch der EC2 Amazon-Metadatenserver und der ECS Amazon-Aufgabenmetadaten-Endpunkt ignoriert werden. Der Metadaten-Endpunkt stellt IAM Rollen für Anmeldeinformationen für Aufgaben bereit. Sie können zusätzliche Adressen hinzufügen.
EgressIgnoredPorts: Sie können eine Liste der Ports (mit Kommas als Trennzeichen) hinzufügen. Envoy führt keine Proxy-Weiterleitung an diese Ports durch. Auch wenn Sie keine Ports auflisten, wird Port 22 ignoriert.

Anmerkung
Die maximale Anzahl von ausgehenden Ports, die ignoriert werden können, ist 15.


"proxyConfiguration": {
	"type": "APPMESH",
	"containerName": "envoy",
	"properties": [{
			"name": "IgnoredUID",
			"value": "1337"
		},
		{
			"name": "ProxyIngressPort",
			"value": "15000"
		},
		{
			"name": "ProxyEgressPort",
			"value": "15001"
		},
		{
			"name": "AppPorts",
			"value": "9080"
		},
		{
			"name": "EgressIgnoredIPs",
			"value": "169.254.170.2,169.254.169.254"
		},
		{
			"name": "EgressIgnoredPorts",
			"value": "22"
		}
	]
}

Envoy-Abhängigkeit des Anwendungs-Containers

Die Anwendungs-Container in Ihren Aufgabendefinitionen müssen mit dem Starten warten, bis der Envoy-Proxy den Bootstrap-Vorgang durchgeführt hat und gestartet wurde. Um sicherzustellen, dass dies geschieht, legen Sie in jeder Anwendungscontainer-Definition einen dependsOn Abschnitt fest, der darauf wartet, dass sich der Envoy-Container als meldet. HEALTHY Der folgende Codeblock zeigt ein Beispiel für eine Anwendungs-Containerdefinition mit dieser Abhängigkeit. Alle Eigenschaften im folgenden Beispiel sind erforderlich. Einige Eigenschaftswerte sind ebenfalls erforderlich, andere jedoch replaceable.


{
	"name": "appName",
	"image": "appImage",
	"portMappings": [{
		"containerPort": 9080,
		"hostPort": 9080,
		"protocol": "tcp"
	}],
	"essential": true,
	"dependsOn": [{
		"containerName": "envoy",
		"condition": "HEALTHY"
	}]
}

Envoy-Containerdefinition

Ihre ECS Amazon-Aufgabendefinitionen müssen ein App Mesh Envoy-Container-Image enthalten.

Alle unterstützten Regionen außerme-south-1,ap-east-1,ap-southeast-3, eu-south-1il-central-1, undaf-south-1. Sie können ersetzen Region-code mit einer anderen Region als me-south-1ap-east-1,ap-southeast-3,eu-south-1,il-central-1, undaf-south-1.

Standard


840364872350.dkr.ecr.region-code.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod

FIPS-konform


840364872350.dkr.ecr.region-code.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod-fips

me-south-1

Standard


772975370895.dkr.ecr.me-south-1.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod

FIPS-konform


772975370895.dkr.ecr.me-south-1.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod-fips

ap-east-1

Standard


856666278305.dkr.ecr.ap-east-1.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod

FIPS-konform


856666278305.dkr.ecr.ap-east-1.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod-fips

ap-southeast-3

Standard


909464085924.dkr.ecr.ap-southeast-3.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod

FIPS-konform


909464085924.dkr.ecr.ap-southeast-3.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod-fips

eu-south-1

Standard


422531588944.dkr.ecr.eu-south-1.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod

FIPS-konform


422531588944.dkr.ecr.eu-south-1.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod-fips

il-central-1

Standard


564877687649.dkr.ecr.il-central-1.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod

FIPS-konform


564877687649.dkr.ecr.il-central-1.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod-fips

af-south-1

Standard


924023996002.dkr.ecr.af-south-1.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod

FIPS-konform


924023996002.dkr.ecr.af-south-1.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod-fips

Public repository

Standard


public.ecr.aws/appmesh/aws-appmesh-envoy:v1.29.9.0-prod

FIPS-konform


public.ecr.aws/appmesh/aws-appmesh-envoy:v1.29.9.0-prod-fips

Wichtig

Nur Version v1.9.0.0-prod oder höher wird für die Verwendung mit App Mesh unterstützt.

Sie müssen das App Mesh Envoy-Container-Image verwenden, bis das Envoy-Projektteam Änderungen zusammenführt, die App Mesh unterstützen. Weitere Informationen finden Sie in der GitHub Roadmap-Ausgabe.

Alle Eigenschaften im folgenden Beispiel sind erforderlich. Einige Eigenschaftswerte sind ebenfalls erforderlich, andere jedoch replaceable.

Anmerkung

Die Envoy-Containerdefinition muss als essential gekennzeichnet sein.
Wir empfehlen, dem Envoy-Container 512 CPU Einheiten und mindestens 64 MiB Speicher zuzuweisen. Bei Fargate ist der niedrigste Wert, den Sie einstellen können, 1024 MiB Arbeitsspeicher.
Der Name des virtuellen Knotens für den ECS Amazon-Service muss auf den Wert der APPMESH_RESOURCE_ARN Eigenschaft gesetzt werden. Für diese Eigenschaft ist eine Version 1.15.0 oder eine neuere Version des Envoy-Images erforderlich. Weitere Informationen finden Sie unter Bild des Gesandten.
Der Wert für die user-Einstellung muss mit dem IgnoredUID-Wert aus der Proxykonfiguration der Aufgabendefinition übereinstimmen. In diesem Beispiel verwenden wir 1337.
Die hier gezeigte Integritätsprüfung wartet, bis der Envoy-Container ordnungsgemäß gestartet wurde, bevor Amazon gemeldet wirdECS, dass der Envoy-Container fehlerfrei und bereit für den Start der Anwendungscontainer ist.
Standardmäßig verwendet App Mesh den Namen der Ressource, die Sie in APPMESH_RESOURCE_ARN angegeben haben, wenn sich Envoy in Metriken und Ablaufverfolgungen auf sich selbst bezieht. Sie können dieses Verhalten übergehen, indem Sie die APPMESH_RESOURCE_CLUSTER-Umgebungsvariable mit Ihrem eigenen Namen festlegen. Für diese Eigenschaft ist eine Version 1.15.0 oder eine neuere Version des Envoy-Images erforderlich. Weitere Informationen finden Sie unter Bild des Gesandten.

Der folgende Codeblock zeigt ein Beispiel einer Envoy-Containerdefinition.


{
	"name": "envoy",
	"image": "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod",
	"essential": true,
	"environment": [{
		"name": "APPMESH_RESOURCE_ARN",
		"value": "arn:aws:appmesh:us-west-2:111122223333:mesh/apps/virtualNode/serviceB"
	}],
	"healthCheck": {
		"command": [
			"CMD-SHELL",
			"curl -s http://localhost:9901/server_info | grep state | grep -q LIVE"
		],
		"startPeriod": 10,
		"interval": 5,
		"timeout": 2,
		"retries": 3
	},
	"user": "1337"
}

Beispiel für Aufgabendefinitionen

Die folgenden ECS Amazon-Beispiel-Aufgabendefinitionen zeigen, wie Sie die obigen Beispiele zu einer Aufgabendefinition für zusammenführentaskB. Es werden Beispiele für die Erstellung von Aufgaben für beide ECS Amazon-Starttypen mit oder ohne Verwendung bereitgestellt AWS X-Ray. Ändern Sie die replaceable Werte, falls erforderlich, um Aufgabendefinitionen für die genannten Aufgaben taskBv2 und für die Aufgaben taskA aus dem Szenario zu erstellen. Geben Sie in Ihrer Proxykonfiguration als Wert für APPMESH_RESOURCE_ARN den Namen Ihres Mesh und den Namen des virtuellen Knotens an. Geben Sie zudem als Wert für AppPorts eine Liste der Ports an, die von Ihrer Anwendung überwacht werden. Standardmäßig verwendet App Mesh den Namen der Ressource, die Sie in APPMESH_RESOURCE_ARN angegeben haben, wenn sich Envoy in Metriken und Ablaufverfolgungen auf sich selbst bezieht. Sie können dieses Verhalten übergehen, indem Sie die APPMESH_RESOURCE_CLUSTER-Umgebungsvariable mit Ihrem eigenen Namen festlegen. Alle Eigenschaften in den folgenden Beispielen sind erforderlich. Einige Eigenschaftswerte sind ebenfalls erforderlich, andere jedoch replaceable.

Wenn Sie eine ECS Amazon-Aufgabe ausführen, wie im Abschnitt Anmeldeinformationen beschrieben, müssen Sie den Beispielen eine bestehende IAMAufgabenrolle hinzufügen.

Wichtig

Fargate muss einen Portwert verwenden, der größer als 1024 ist.

Beispiel JSONfür die ECS Amazon-Aufgabendefinition — Fargate auf Linux-Containern


{
   
   "family" : "taskB",
   "memory" : "1024",
   "cpu" : "0.5 vCPU",
   "proxyConfiguration" : {
      "containerName" : "envoy",
      "properties" : [
         {
            "name" : "ProxyIngressPort",
            "value" : "15000"
         },
         {
            "name" : "AppPorts",
            "value" : "9080"
         },
         {
            "name" : "EgressIgnoredIPs",
            "value" : "169.254.170.2,169.254.169.254"
         },
         {
            "name": "EgressIgnoredPorts",
            "value": "22"
         },
         {
            "name" : "IgnoredUID",
            "value" : "1337"
         },
         {
            "name" : "ProxyEgressPort",
            "value" : "15001"
         }
      ],
      "type" : "APPMESH"
   },
   "containerDefinitions" : [
      {
         "name" : "appName",
         "image" : "appImage",
         "portMappings" : [
            {
               "containerPort" : 9080,
               "protocol" : "tcp"
            }
         ],
         "essential" : true,
         "dependsOn" : [
            {
               "containerName" : "envoy",
               "condition" : "HEALTHY"
            }
         ]
      },
      {         
         "name" : "envoy",
         "image" : "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod",
         "essential" : true,
         "environment" : [
            {
               "name" : "APPMESH_VIRTUAL_NODE_NAME",
               "value" : "mesh/apps/virtualNode/serviceB"
            }
         ],
         "healthCheck" : {
            "command" : [
               "CMD-SHELL",
               "curl -s http://localhost:9901/server_info | grep state | grep -q LIVE"
            ],
            "interval" : 5,
            "retries" : 3,
            "startPeriod" : 10,
            "timeout" : 2
         },
         "memory" : 500,
         "user" : "1337"
      }
   ],
   "requiresCompatibilities" : [ "FARGATE" ],
   "taskRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskRole",
   "executionRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
   "networkMode" : "awsvpc"
}

Beispiel JSONfür die ECS Amazon-Aufgabendefinition mit AWS X-Ray - Fargate auf Linux-Containern

X-Ray ermöglicht es Ihnen, Daten über Anfragen zu sammeln, die eine Anwendung bedient, und stellt Tools bereit, mit denen Sie den Verkehrsfluss visualisieren können. Durch die Verwendung des X-Ray-Treibers für Envoy kann Envoy Tracing-Informationen an X-Ray melden. Sie können X-Ray Tracing mit der Envoy-Konfiguration aktivieren. Je nach Konfiguration sendet Envoy Tracing-Daten an den X-Ray-Daemon, der als Sidecar-Container läuft, und der Daemon leitet die Traces an den X-Ray-Dienst weiter. Sobald die Traces auf X-Ray veröffentlicht wurden, können Sie die X-Ray-Konsole verwenden, um das Diagramm der Serviceanrufe zu visualisieren und Trace-Details anzufordern. Im Folgenden finden JSON Sie eine Aufgabendefinition zur Aktivierung der X-Ray-Integration.


{
   
   
   "family" : "taskB",
   "memory" : "1024",
   "cpu" : "512",
   "proxyConfiguration" : {
      "containerName" : "envoy",
      "properties" : [
         {
            "name" : "ProxyIngressPort",
            "value" : "15000"
         },
         {
            "name" : "AppPorts",
            "value" : "9080"
         },
         {
            "name" : "EgressIgnoredIPs",
            "value" : "169.254.170.2,169.254.169.254"
         },
         {
            "name": "EgressIgnoredPorts",
            "value": "22"
         },
         {
            "name" : "IgnoredUID",
            "value" : "1337"
         },
         {
            "name" : "ProxyEgressPort",
            "value" : "15001"
         }
      ],
      "type" : "APPMESH"
   },
   "containerDefinitions" : [
      {
         "name" : "appName",
         "image" : "appImage",
         "portMappings" : [
            {
               "containerPort" : 9080,
               "protocol" : "tcp"
            }
         ],
         "essential" : true,
         "dependsOn" : [
            {
               "containerName" : "envoy",
               "condition" : "HEALTHY"
            }
         ]
      },
      {
         
         "name" : "envoy",
         "image" : "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod",
         "essential" : true,
         "environment" : [
            {
               "name" : "APPMESH_VIRTUAL_NODE_NAME",
               "value" : "mesh/apps/virtualNode/serviceB"
            },
            {
               "name": "ENABLE_ENVOY_XRAY_TRACING",
               "value": "1"
            }
         ],
         "healthCheck" : {
            "command" : [
               "CMD-SHELL",
               "curl -s http://localhost:9901/server_info | grep state | grep -q LIVE"
            ],
            "interval" : 5,
            "retries" : 3,
            "startPeriod" : 10,
            "timeout" : 2
         },
         "memory" : 500,
         "user" : "1337"
      },
      {
         "name" : "xray-daemon",
         "image" : "amazon/aws-xray-daemon",
         "user" : "1337",
         "essential" : true,
         "cpu" : "32",
         "memoryReservation" : "256",
         "portMappings" : [
            {
               "containerPort" : 2000,
               "protocol" : "udp"
            }
         ]
      }
   ],
   "requiresCompatibilities" : [ "FARGATE" ],
   "taskRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskRole",
   "executionRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
   "networkMode" : "awsvpc"
}

Beispiel JSONfür ECS Amazon-Aufgabendefinition — EC2 Starttyp


{
  "family": "taskB",
  "memory": "256",
  "proxyConfiguration": {
    "type": "APPMESH",
    "containerName": "envoy",
    "properties": [
      {
        "name": "IgnoredUID",
        "value": "1337"
      },
      {
        "name": "ProxyIngressPort",
        "value": "15000"
      },
      {
        "name": "ProxyEgressPort",
        "value": "15001"
      },
      {
        "name": "AppPorts",
        "value": "9080"
      },
      {
        "name": "EgressIgnoredIPs",
        "value": "169.254.170.2,169.254.169.254"
      },
      {
        "name": "EgressIgnoredPorts",
        "value": "22"
      }
    ]
  },
  "containerDefinitions": [
    {
      "name": "appName",
      "image": "appImage",
      "portMappings": [
        {
          "containerPort": 9080,
          "hostPort": 9080,
          "protocol": "tcp"
        }
      ],
      "essential": true,
      "dependsOn": [
        {
          "containerName": "envoy",
          "condition": "HEALTHY"
        }
      ]
    },
    {
      "name": "envoy",
      "image": "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod",
      "essential": true,
      "environment": [
        {
          "name": "APPMESH_VIRTUAL_NODE_NAME",
          "value": "mesh/apps/virtualNode/serviceB"
        }
      ],
      "healthCheck": {
        "command": [
          "CMD-SHELL",
          "curl -s http://localhost:9901/server_info | grep state | grep -q LIVE"
        ],
        "startPeriod": 10,
        "interval": 5,
        "timeout": 2,
        "retries": 3
      },
      "user": "1337"
    }
  ],
  "requiresCompatibilities" : [ "EC2" ],
  "taskRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskRole",
  "executionRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "networkMode": "awsvpc"
}

Beispiel JSONfür ECS Amazon-Aufgabendefinition mit AWS X-Ray - EC2 Starttyp


{
  "family": "taskB",
  "memory": "256",
   "cpu" : "1024",
  "proxyConfiguration": {
    "type": "APPMESH",
    "containerName": "envoy",
    "properties": [
      {
        "name": "IgnoredUID",
        "value": "1337"
      },
      {
        "name": "ProxyIngressPort",
        "value": "15000"
      },
      {
        "name": "ProxyEgressPort",
        "value": "15001"
      },
      {
        "name": "AppPorts",
        "value": "9080"
      },
      {
        "name": "EgressIgnoredIPs",
        "value": "169.254.170.2,169.254.169.254"
      },
      {
        "name": "EgressIgnoredPorts",
        "value": "22"
      }
    ]
  },
  "containerDefinitions": [
    {
      "name": "appName",
      "image": "appImage",
      "portMappings": [
        {
          "containerPort": 9080,
          "hostPort": 9080,
          "protocol": "tcp"
        }
      ],
      "essential": true,
      "dependsOn": [
        {
          "containerName": "envoy",
          "condition": "HEALTHY"
        }
      ]
    },
    {
      "name": "envoy",
      "image": "840364872350.dkr.ecr.us-west-2.amazonaws.com/aws-appmesh-envoy:v1.29.9.0-prod",
      "essential": true,
      "environment": [
        {
          "name": "APPMESH_VIRTUAL_NODE_NAME",
          "value": "mesh/apps/virtualNode/serviceB"
        },
        {
         "name": "ENABLE_ENVOY_XRAY_TRACING",
         "value": "1"
        }
      ],
      "healthCheck": {
        "command": [
          "CMD-SHELL",
          "curl -s http://localhost:9901/server_info | grep state | grep -q LIVE"
        ],
        "startPeriod": 10,
        "interval": 5,
        "timeout": 2,
        "retries": 3
      },
      "user": "1337"
    },
    {
      "name": "xray-daemon",
      "image": "amazon/aws-xray-daemon",
      "user": "1337",
      "essential": true,
      "cpu": 32,
      "memoryReservation": 256,
      "portMappings": [
        {
          "containerPort": 2000,
          "protocol": "udp"
        }
      ]
    }
  ],
  "requiresCompatibilities" : [ "EC2" ],
  "taskRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskRole",
  "executionRoleArn" : "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "networkMode": "awsvpc"
}

Fortschrittliche Themen

Kanarische Bereitstellungen mit App Mesh

Mithilfe von Bereitstellungen und Releases auf Canary können Sie den Datenverkehr zwischen einer alten Version einer Anwendung und einer neu bereitgestellten Version umschalten. Außerdem wird der Zustand der neu bereitgestellten Version überwacht. Falls es Probleme mit der neuen Version gibt, kann das Canary-Deployment den Traffic automatisch wieder auf die alte Version umschalten. Mit Bereitstellungen auf Canary hast du die Möglichkeit, den Datenverkehr zwischen den Anwendungsversionen mit mehr Kontrolle umzuschalten.

Weitere Informationen zur Implementierung von Canary-Bereitstellungen für Amazon ECS mithilfe von App Mesh finden Sie unter Erstellen einer Pipeline mit Canary-Bereitstellungen für Amazon ECS mithilfe von App Mesh

Anmerkung

Weitere Beispiele und Komplettlösungen für App Mesh finden Sie im App Mesh Mesh-Beispiel-Repository.

Warnung JavaScript ist in Ihrem Browser nicht verfügbar oder deaktiviert.

Zur Nutzung der AWS-Dokumentation muss JavaScript aktiviert sein. Weitere Informationen finden auf den Hilfe-Seiten Ihres Browsers.

Dokumentkonventionen

Erste Schritte

App Mesh und Kubernetes