Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Guida introduttiva AWS App Mesh ad Amazon EC2
Importante
Avviso di fine del supporto: il 30 settembre 2026, AWS verrà interrotto il supporto per. AWS App Mesh Dopo il 30 settembre 2026, non potrai più accedere alla AWS App Mesh console o alle risorse. AWS App Mesh Per ulteriori informazioni, consulta questo post di blog Migrazione AWS App Mesh da Amazon ECS Service Connect.
Questo argomento ti aiuta a utilizzarlo AWS App Mesh con un servizio effettivo in esecuzione su Amazon EC2. Questo tutorial copre le funzionalità di base di diversi tipi di risorse App Mesh.
Scenario
Per illustrare come utilizzare App Mesh, supponiamo di avere un'applicazione con le seguenti caratteristiche:
-
È costituito da due servizi denominati
serviceA
eserviceB
. -
Entrambi i servizi sono registrati in uno spazio dei nomi denominato
apps.local
. -
ServiceA
comunica conserviceB
su HTTP/2, porta 80. -
Hai già distribuito la versione 2 di
serviceB
e l'hai registrata con il nomeserviceBv2
nello spazio dei nomiapps.local
.
I requisiti sono i seguenti:
-
Vuoi inviare il 75 percento del traffico da
serviceA
aserviceB
e il 25 percento del traffico aserviceBv2
First. Inviando solo il 25 percento aserviceBv2
, puoi verificare che sia privo di bug prima di inviare il 100% del traffico daserviceA
. -
Vuoi essere in grado di regolare facilmente la ponderazione del traffico in modo che il 100% del traffico vada a
serviceBv2
una volta dimostrato essere affidabile. Una volta inviato tutto il traffico aserviceBv2
, vuoiserviceB
interromperlo. -
Per soddisfare i requisiti precedenti non è necessario modificare il codice dell'applicazione esistente o la registrazione di Service Discovery per usufruire dei servizi effettivi.
Per soddisfare le tue esigenze, decidi di creare una mesh di servizi App Mesh con servizi virtuali, nodi virtuali, un router virtuale e un percorso. Dopo aver implementato la mesh, aggiorni i servizi per utilizzare il proxy Envoy. Una volta aggiornati, i servizi comunicano tra loro tramite il proxy Envoy anziché direttamente tra loro.
Prerequisiti
App Mesh supporta i servizi Linux registrati con DNS o entrambi. AWS Cloud Map Per utilizzare questa guida introduttiva, è consigliabile avere tre servizi esistenti registrati con DNS. Puoi creare una mesh dei servizi e le relative risorse anche se i servizi non esistono, ma non puoi utilizzare la mesh fino a quando non hai distribuito i servizi effettivi.
Se non disponi già di servizi in esecuzione, puoi avviare EC2 istanze Amazon e distribuirvi applicazioni. Per ulteriori informazioni, consulta Tutorial: Guida introduttiva alle istanze Amazon EC2 Linux nella Amazon EC2 User Guide. Le fasi rimanenti presuppongono che i servizi effettivi siano denominati serviceA
, serviceB
e serviceBv2
e che tutti i servizi siano individuabili tramite uno spazio dei nomi denominato apps.local
.
Fase 1: creare una mesh e un servizio virtuale
Una mesh dei servizi è un limite logico per il traffico di rete tra i servizi che si trovano al suo interno. Per ulteriori informazioni, consulta Reti di servizio. Un servizio virtuale è un'astrazione di un servizio effettivo. Per ulteriori informazioni, consulta Servizi virtuali.
Crea le seguenti risorse:
-
Una mesh denominata
apps
, perché tutti i servizi nello scenario sono registrati nello spazio dei nomiapps.local
. -
Un servizio virtuale denominato
serviceb.apps.local
perché il servizio virtuale rappresenta un servizio individuabile tramite questo nome e non vuoi modificare il codice per fare riferimento a un altro nome. Un servizio virtuale denominatoservicea.apps.local
viene aggiunto in una fase successiva.
Puoi utilizzare la AWS CLI versione 1.18.116 AWS Management Console o successiva o 2.0.38 o successiva per completare i seguenti passaggi. Se si utilizza il AWS CLI, utilizzare il aws --version
comando per verificare la versione installata. AWS CLI Se non hai installato la versione 1.18.116 o successiva o 2.0.38 o successiva, devi installare o aggiornare la. AWS CLI Seleziona la scheda relativa allo strumento che desideri utilizzare.
Fase 2: creare un nodo virtuale
Un nodo virtuale funziona come un puntatore logico a un servizio effettivo. Per ulteriori informazioni, consulta Nodi virtuali.
Crea un nodo virtuale denominato serviceB
perché uno dei nodi virtuali rappresenta il servizio effettivo denominato serviceB
. Il servizio effettivo rappresentato dal nodo virtuale è individuabile tramite DNS
con il nome host serviceb.apps.local
. In alternativa, puoi individuare i servizi effettivi utilizzando AWS Cloud Map. Il nodo virtuale ascolta il traffico utilizzando il protocollo HTTP/2 sulla porta 80. Sono supportati anche altri protocolli, così come i controlli di stato. I nodi virtuali vengono creati per serviceA
e serviceBv2
in una fase successiva.
Fase 3: creare un router virtuale e una route
I router virtuali gestiscono il traffico per uno o più servizi virtuali all'interno della mesh. Per ulteriori informazioni, consulta Router virtuali e Route.
Crea le seguenti risorse:
-
Un router virtuale denominato
serviceB
perché il servizio virtualeserviceB.apps.local
non avvia la comunicazione in uscita con altri servizi. Tieni presente che il servizio virtuale creato in precedenza è un'astrazione del servizioserviceb.apps.local
effettivo. Il servizio virtuale invia il traffico al router virtuale. Il router virtuale ascolta il traffico utilizzando il protocollo HTTP/2 sulla porta 80. Sono supportati anche altri protocolli. -
Una route denominata
serviceB
. Indirizza il 100% del traffico verso ilserviceB
nodo virtuale. Il peso viene calcolato in una fase successiva dopo l'aggiunta del nodoserviceBv2
virtuale. Sebbene non sia trattato in questa guida, è possibile impostare criteri di filtro aggiuntivi per la route e aggiungere una policy per i nuovi tentativi per far sì che il proxy Envoy effettui più tentativi di invio del traffico a un nodo virtuale quando si verifica un problema di comunicazione.
Fase 4: Revisione e creazione
Rivedi le impostazioni in relazione alle istruzioni precedenti.
Fase 5: creare risorse aggiuntive
Per completare lo scenario è necessario:
-
Creare un nodo virtuale denominato
serviceBv2
e un altro denominatoserviceA
. Entrambi i nodi virtuali ascoltano le richieste su HTTP/2, porta 80. Per il nodoserviceA
virtuale, configura un backend diserviceb.apps.local
. Tutto il traffico in uscita dal nodoserviceA
virtuale viene inviato al servizio virtuale denominato.serviceb.apps.local
Sebbene non sia trattato in questa guida, è anche possibile specificare un percorso file in cui scrivere i log degli accessi per un nodo virtuale. -
Crea un servizio virtuale aggiuntivo denominato
servicea.apps.local
, che invia tutto il traffico direttamente al nodoserviceA
virtuale. -
Aggiornare la route
serviceB
creata in una fase precedente per inviare il 75% del traffico al nodo virtualeserviceB
e il 25% del traffico al nodo virtualeserviceBv2
. È possibile continuare a modificare i pesi finchéserviceBv2
riceva il 100% del traffico. Una volta inviato tutto il traffico aserviceBv2
, puoi chiudere e interrompere il nodoserviceB
virtuale e il servizio effettivo. Quando si cambiano i pesi, il codice non richiede alcuna modifica perché i nomi dei servizi virtuali ed effettiviserviceb.apps.local
non cambiano. Tenere presente che il servizio virtualeserviceb.apps.local
invia il traffico al router virtuale che instrada il traffico ai nodi virtuali. I nomi di individuazione dei servizi per i nodi virtuali possono essere modificati in qualsiasi momento.
Riepilogo della mesh
Prima di creare la mesh dei servizi, erano presenti tre servizi effettivi denominati servicea.apps.local
, serviceb.apps.local
e servicebv2.apps.local
. Oltre ai servizi effettivi, ora hai una mesh dei servizi che contiene le seguenti risorse che rappresentano i servizi effettivi:
-
Due servizi virtuali. Il proxy invia tutto il traffico dal servizio virtuale
servicea.apps.local
al servizio virtualeserviceb.apps.local
tramite un router virtuale. -
Tre nodi virtuali denominati
serviceA
,serviceB
eserviceBv2
. Il proxy Envoy utilizza le informazioni di individuazione dei servizi configurate per i nodi virtuali per cercare gli indirizzi IP dei servizi effettivi. -
Un router virtuale con una route che indica al proxy Envoy di indirizzare il 75% del traffico in ingresso al nodo virtuale
serviceB
e il 25% del traffico al nodo virtualeserviceBv2
.
Fase 6: aggiornare i servizi
Dopo aver creato la mesh, è necessario completare le seguenti attività:
-
Autorizza il proxy Envoy che distribuisci con ogni servizio a leggere la configurazione di uno o più nodi virtuali. Per ulteriori informazioni su come autorizzare il proxy, vedere. Autorizzazione Envoy Proxy
-
Per aggiornare il servizio esistente, completa i passaggi seguenti.
Per configurare un' EC2 istanza Amazon come membro di un nodo virtuale
-
Crea un ruolo IAM.
-
Crea un file denominato
ec2-trust-relationship.json
con i seguenti contenuti.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "ec2.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
-
Crea un ruolo IAM con il seguente comando.
aws iam create-role --role-name
mesh-virtual-node-service-b
--assume-role-policy-document file://ec2-trust-relationship.json
-
-
Allega le policy IAM al ruolo che gli consentono di leggere da Amazon ECR e solo la configurazione di uno specifico nodo virtuale App Mesh.
-
Crea un file denominato
virtual-node-policy.json
con il seguente contenuto.apps
è il nome della mesh creata in Fase 1: creare una mesh e un servizio virtuale eserviceB
è il nome del nodo virtuale creato in Fase 2: creare un nodo virtuale. Sostituiscilo111122223333
con l'ID del tuo account eus-west-2
con la regione in cui hai creato la mesh.{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "appmesh:StreamAggregatedResources", "Resource": [ "arn:aws:appmesh:
us-west-2
:111122223333
:mesh/apps
/virtualNode/serviceB
" ] } ] } -
Creare la policy con il seguente comando.
aws iam create-policy --policy-name
virtual-node-policy
--policy-document file://virtual-node-policy.json -
Allega la policy che hai creato nel passaggio precedente al ruolo in modo che il ruolo possa leggere la configurazione solo per il nodo
serviceB
virtuale da App Mesh.aws iam attach-role-policy --policy-arn arn:aws:iam::
111122223333
:policy/virtual-node-policy --role-namemesh-virtual-node-service-b
-
Allega la policy
AmazonEC2ContainerRegistryReadOnly
gestita al ruolo in modo che possa estrarre l'immagine del contenitore Envoy da Amazon ECR.aws iam attach-role-policy --policy-arn arn:aws:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly --role-name
mesh-virtual-node-service-b
-
-
Avvia un' EC2 istanza Amazon con il ruolo IAM che hai creato.
-
Eseguire la connessione all'istanza tramite SSH.
-
Installa Docker and the AWS CLI sulla tua istanza in base alla documentazione del sistema operativo.
-
Effettua l'autenticazione nel repository Amazon ECR di Envoy nella regione da cui desideri che il client Docker estragga l'immagine.
-
Tutte le regioni tranne
me-south-1
,,,, eap-east-1
.ap-southeast-3
eu-south-1
il-central-1
af-south-1
È possibileus-west-2
sostituirla con qualsiasi regione supportata ad eccezione dime-south-1
ap-east-1
ap-southeast-3
,eu-south-1
,il-central-1
,, eaf-south-1
.$
aws ecr get-login-password \ --region
us-west-2
\ | docker login \ --username AWS \ --password-stdin 840364872350.dkr.ecr.us-west-2
.amazonaws.com -
Regione
me-south-1
$
aws ecr get-login-password \ --region me-south-1 \ | docker login \ --username AWS \ --password-stdin 772975370895.dkr.ecr.me-south-1.amazonaws.com
-
Regione
ap-east-1
$
aws ecr get-login-password \ --region ap-east-1 \ | docker login \ --username AWS \ --password-stdin 856666278305.dkr.ecr.ap-east-1.amazonaws.com
-
-
Esegui uno dei seguenti comandi per avviare il contenitore App Mesh Envoy sulla tua istanza, a seconda della regione da cui desideri estrarre l'immagine. I
serviceB
valoriapps
e sono i nomi della mesh e dei nodi virtuali definiti nello scenario. Queste informazioni indicano al proxy quale configurazione del nodo virtuale leggere da App Mesh. Per completare lo scenario, devi anche completare questi passaggi per le EC2 istanze Amazon che ospitano i serviziserviceBv2
rappresentati dai nodiserviceA
virtuali. Per la propria applicazione, sostituire questi valori con quelli appropriati.-
Tutte le regioni tranne
me-south-1
,ap-east-1
,ap-southeast-3
,eu-south-1
il-central-1
, eaf-south-1
. È possibileRegion-code
sostituirla con qualsiasi regione supportata ad eccezione dime-south-1
ap-east-1
,ap-southeast-3
,eu-south-1
,il-central-1
, eaf-south-1
Regioni. Puoi sostituire
con qualsiasi valore compreso tra1337
0
e2147483647
.sudo docker run --detach --env APPMESH_RESOURCE_ARN=
mesh/
\ -uapps
/virtualNode/serviceB
1337
--network host 840364872350.dkr.ecr.region-code
.amazonaws.com/aws-appmesh-envoy:v1.29.12.0-prod -
Regione
me-south-1
. Puoi sostituire
con qualsiasi valore compreso tra1337
0
e2147483647
.sudo docker run --detach --env APPMESH_RESOURCE_ARN=
mesh/
\ -uapps
/virtualNode/serviceB
1337
--network host 772975370895.dkr.ecr.me-south-1.amazonaws.com/aws-appmesh-envoy:v1.29.12.0-prod -
Regione
ap-east-1
. Puoi sostituire
con qualsiasi valore compreso tra1337
0
e2147483647
.sudo docker run --detach --env APPMESH_RESOURCE_ARN=
mesh/
\ -uapps
/virtualNode/serviceB
1337
--network host 856666278305.dkr.ecr.ap-east-1.amazonaws.com/aws-appmesh-envoy:v1.29.12.0-prod
Nota
La
APPMESH_RESOURCE_ARN
proprietà richiede una versione1.15.0
o successiva dell'immagine Envoy. Per ulteriori informazioni, consulta Immagine dell'inviato.Importante
Solo la versione v1.9.0.0-prod o successiva è supportata per l'uso con App Mesh.
-
Seleziona
Show more
di seguito. Crea un file denominatoenvoy-networking.sh
nell'istanza con i seguenti contenuti.8000
Sostituiscila con la porta utilizzata dal codice dell'applicazione per il traffico in entrata. Puoi modificare il valore perAPPMESH_IGNORE_UID
, ma il valore deve essere uguale a quello specificato nel passaggio precedente, ad esempio1337
. Se necessario puoi aggiungere altri indirizzi inAPPMESH_EGRESS_IGNORED_IP
. Non modificare altre righe.#!/bin/bash -e # # Start of configurable options # #APPMESH_START_ENABLED="0" APPMESH_IGNORE_UID="
1337
" APPMESH_APP_PORTS="8000
" APPMESH_ENVOY_EGRESS_PORT="15001" APPMESH_ENVOY_INGRESS_PORT="15000" APPMESH_EGRESS_IGNORED_IP="169.254.169.254,169.254.170.2" # Enable routing on the application start. [ -z "$APPMESH_START_ENABLED" ] && APPMESH_START_ENABLED="0" # Enable IPv6. [ -z "$APPMESH_ENABLE_IPV6" ] && APPMESH_ENABLE_IPV6="0" # Egress traffic from the processess owned by the following UID/GID will be ignored. if [ -z "$APPMESH_IGNORE_UID" ] && [ -z "$APPMESH_IGNORE_GID" ]; then echo "Variables APPMESH_IGNORE_UID and/or APPMESH_IGNORE_GID must be set." echo "Envoy must run under those IDs to be able to properly route it's egress traffic." exit 1 fi # Port numbers Application and Envoy are listening on. if [ -z "$APPMESH_ENVOY_EGRESS_PORT" ]; then echo "APPMESH_ENVOY_EGRESS_PORT must be defined to forward traffic from the application to the proxy." exit 1 fi # If an app port was specified, then we also need to enforce the proxies ingress port so we know where to forward traffic. if [ ! -z "$APPMESH_APP_PORTS" ] && [ -z "$APPMESH_ENVOY_INGRESS_PORT" ]; then echo "APPMESH_ENVOY_INGRESS_PORT must be defined to forward traffic from the APPMESH_APP_PORTS to the proxy." exit 1 fi # Comma separated list of ports for which egress traffic will be ignored, we always refuse to route SSH traffic. if [ -z "$APPMESH_EGRESS_IGNORED_PORTS" ]; then APPMESH_EGRESS_IGNORED_PORTS="22" else APPMESH_EGRESS_IGNORED_PORTS="$APPMESH_EGRESS_IGNORED_PORTS,22" fi # # End of configurable options # function initialize() { echo "=== Initializing ===" if [ ! -z "$APPMESH_APP_PORTS" ]; then iptables -t nat -N APPMESH_INGRESS if [ "$APPMESH_ENABLE_IPV6" == "1" ]; then ip6tables -t nat -N APPMESH_INGRESS fi fi iptables -t nat -N APPMESH_EGRESS if [ "$APPMESH_ENABLE_IPV6" == "1" ]; then ip6tables -t nat -N APPMESH_EGRESS fi } function enable_egress_routing() { # Stuff to ignore [ ! -z "$APPMESH_IGNORE_UID" ] && \ iptables -t nat -A APPMESH_EGRESS \ -m owner --uid-owner $APPMESH_IGNORE_UID \ -j RETURN [ ! -z "$APPMESH_IGNORE_GID" ] && \ iptables -t nat -A APPMESH_EGRESS \ -m owner --gid-owner $APPMESH_IGNORE_GID \ -j RETURN [ ! -z "$APPMESH_EGRESS_IGNORED_PORTS" ] && \ for IGNORED_PORT in $(echo "$APPMESH_EGRESS_IGNORED_PORTS" | tr "," "\n"); do iptables -t nat -A APPMESH_EGRESS \ -p tcp \ -m multiport --dports "$IGNORED_PORT" \ -j RETURN done if [ "$APPMESH_ENABLE_IPV6" == "1" ]; then # Stuff to ignore ipv6 [ ! -z "$APPMESH_IGNORE_UID" ] && \ ip6tables -t nat -A APPMESH_EGRESS \ -m owner --uid-owner $APPMESH_IGNORE_UID \ -j RETURN [ ! -z "$APPMESH_IGNORE_GID" ] && \ ip6tables -t nat -A APPMESH_EGRESS \ -m owner --gid-owner $APPMESH_IGNORE_GID \ -j RETURN [ ! -z "$APPMESH_EGRESS_IGNORED_PORTS" ] && \ for IGNORED_PORT in $(echo "$APPMESH_EGRESS_IGNORED_PORTS" | tr "," "\n"); do ip6tables -t nat -A APPMESH_EGRESS \ -p tcp \ -m multiport --dports "$IGNORED_PORT" \ -j RETURN done fi # The list can contain both IPv4 and IPv6 addresses. We will loop over this list # to add every IPv4 address into `iptables` and every IPv6 address into `ip6tables`. [ ! -z "$APPMESH_EGRESS_IGNORED_IP" ] && \ for IP_ADDR in $(echo "$APPMESH_EGRESS_IGNORED_IP" | tr "," "\n"); do if [[ $IP_ADDR =~ .*:.* ]] then [ "$APPMESH_ENABLE_IPV6" == "1" ] && \ ip6tables -t nat -A APPMESH_EGRESS \ -p tcp \ -d "$IP_ADDR" \ -j RETURN else iptables -t nat -A APPMESH_EGRESS \ -p tcp \ -d "$IP_ADDR" \ -j RETURN fi done # Redirect everything that is not ignored iptables -t nat -A APPMESH_EGRESS \ -p tcp \ -j REDIRECT --to $APPMESH_ENVOY_EGRESS_PORT # Apply APPMESH_EGRESS chain to non local traffic iptables -t nat -A OUTPUT \ -p tcp \ -m addrtype ! --dst-type LOCAL \ -j APPMESH_EGRESS if [ "$APPMESH_ENABLE_IPV6" == "1" ]; then # Redirect everything that is not ignored ipv6 ip6tables -t nat -A APPMESH_EGRESS \ -p tcp \ -j REDIRECT --to $APPMESH_ENVOY_EGRESS_PORT # Apply APPMESH_EGRESS chain to non local traffic ipv6 ip6tables -t nat -A OUTPUT \ -p tcp \ -m addrtype ! --dst-type LOCAL \ -j APPMESH_EGRESS fi } function enable_ingress_redirect_routing() { # Route everything arriving at the application port to Envoy iptables -t nat -A APPMESH_INGRESS \ -p tcp \ -m multiport --dports "$APPMESH_APP_PORTS" \ -j REDIRECT --to-port "$APPMESH_ENVOY_INGRESS_PORT" # Apply AppMesh ingress chain to everything non-local iptables -t nat -A PREROUTING \ -p tcp \ -m addrtype ! --src-type LOCAL \ -j APPMESH_INGRESS if [ "$APPMESH_ENABLE_IPV6" == "1" ]; then # Route everything arriving at the application port to Envoy ipv6 ip6tables -t nat -A APPMESH_INGRESS \ -p tcp \ -m multiport --dports "$APPMESH_APP_PORTS" \ -j REDIRECT --to-port "$APPMESH_ENVOY_INGRESS_PORT" # Apply AppMesh ingress chain to everything non-local ipv6 ip6tables -t nat -A PREROUTING \ -p tcp \ -m addrtype ! --src-type LOCAL \ -j APPMESH_INGRESS fi } function enable_routing() { echo "=== Enabling routing ===" enable_egress_routing if [ ! -z "$APPMESH_APP_PORTS" ]; then enable_ingress_redirect_routing fi } function disable_routing() { echo "=== Disabling routing ===" iptables -t nat -F APPMESH_INGRESS iptables -t nat -F APPMESH_EGRESS if [ "$APPMESH_ENABLE_IPV6" == "1" ]; then ip6tables -t nat -F APPMESH_INGRESS ip6tables -t nat -F APPMESH_EGRESS fi } function dump_status() { echo "=== iptables FORWARD table ===" iptables -L -v -n echo "=== iptables NAT table ===" iptables -t nat -L -v -n if [ "$APPMESH_ENABLE_IPV6" == "1" ]; then echo "=== ip6tables FORWARD table ===" ip6tables -L -v -n echo "=== ip6tables NAT table ===" ip6tables -t nat -L -v -n fi } function clean_up() { disable_routing ruleNum=$(iptables -L PREROUTING -t nat --line-numbers | grep APPMESH_INGRESS | cut -d " " -f 1) iptables -t nat -D PREROUTING $ruleNum ruleNum=$(iptables -L OUTPUT -t nat --line-numbers | grep APPMESH_EGRESS | cut -d " " -f 1) iptables -t nat -D OUTPUT $ruleNum iptables -t nat -X APPMESH_INGRESS iptables -t nat -X APPMESH_EGRESS if [ "$APPMESH_ENABLE_IPV6" == "1" ]; then ruleNum=$(ip6tables -L PREROUTING -t nat --line-numbers | grep APPMESH_INGRESS | cut -d " " -f 1) ip6tables -t nat -D PREROUTING $ruleNum ruleNum=$(ip6tables -L OUTPUT -t nat --line-numbers | grep APPMESH_EGRESS | cut -d " " -f 1) ip6tables -t nat -D OUTPUT $ruleNum ip6tables -t nat -X APPMESH_INGRESS ip6tables -t nat -X APPMESH_EGRESS fi } function main_loop() { echo "=== Entering main loop ===" while read -p '> ' cmd; do case "$cmd" in "quit") clean_up break ;; "status") dump_status ;; "enable") enable_routing ;; "disable") disable_routing ;; *) echo "Available commands: quit, status, enable, disable" ;; esac done } function print_config() { echo "=== Input configuration ===" env | grep APPMESH_ || true } print_config initialize if [ "$APPMESH_START_ENABLED" == "1" ]; then enable_routing fi main_loop-
Per configurare le regole
iptables
per instradare il traffico dell'applicazione al proxy Envoy, esegui lo script creato nel passaggio precedente.sudo ./envoy-networking.sh
-
Avviare il codice dell'applicazione del nodo virtuale.
Nota
Per altri esempi e procedure dettagliate per App Mesh, consulta l'archivio degli esempi di App Mesh