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à.

Configurazione della rete per ambienti Beanstalk Cluster

Beanstalk Cluster esegue il tuo ambiente su un cluster Amazon EKS. Le sottoreti selezionate fanno due cose: determinano dove vengono eseguiti i nodi del cluster e determinano quale cluster esegue l'ambiente. Se non si seleziona alcuna sottorete, Elastic Beanstalk utilizza le sottoreti pubbliche del VPC predefinito.

Questo argomento illustra le sottoreti dell'ambiente, il modo in cui il traffico raggiunge l'applicazione dall'esterno del cluster e il modo in cui gli ambienti si indirizzano l'un l'altro all'interno del cluster.

Sottoreti di ambiente

Imposta l'subnetsopzione nel aws:elasticbeanstalk:eks:environment namespace su un elenco di ID di sottorete separati da virgole.

Poiché le sottoreti selezionano il cluster, le imposti quando crei l'ambiente:

$ aws elasticbeanstalk create-environment \
    --application-name my-app \
    --environment-name my-cluster-env \
    --option-settings '[{"Namespace":"aws:elasticbeanstalk:eks:environment","OptionName":"subnets","Value":"subnet-abc123,subnet-def456"}]'

L'impostazione è scritta come JSON perché l'elenco delle subnet contiene una virgola, che nel formato AWS CLI abbreviato considera un separatore tra i campi. Per i moduli AWS CLI accettati, consulta Using shorthand syntax in. AWS CLI

Elastic Beanstalk raggruppa gli ambienti in cluster in base a questo set di sottoreti, in modo che gli ambienti dello stesso account che utilizzano le stesse sottoreti vengano eseguiti sullo stesso cluster e un ambiente che utilizza un set diverso venga eseguito su un cluster diverso. L'ordine delle sottoreti non ha importanza. Per le regole di raggruppamento e gli eventi che segnalano l'assegnazione dei cluster, vedere. Raggruppamento degli ambienti

In che modo il traffico raggiunge la tua applicazione

L'load-balancer-typeopzione nel aws:elasticbeanstalk:eks:environment namespace sceglie il modo in cui il traffico raggiunge l'applicazione. Accetta due valori:

Impostazioni di rete del Load Balancer

L'Application Load Balancer dell'ambiente ha le proprie impostazioni di rete nel namespace. aws:elasticbeanstalk:eks:alb

Listener e HTTPS

L'listen-portsopzione nel aws:elasticbeanstalk:eks:alb namespace elenca i listener del load balancer come un array JSON che mappa ogni protocollo su una porta, ad esempio. [{"HTTPS":443},{"HTTP":80}]

Elastic Beanstalk si assicura che il load balancer termini HTTPS da qualche parte:

Il load balancer apre solo i listener con cui è configurato. Con la configurazione predefinita, è HTTPS sulla porta 443 e niente sulla porta 80, quindi una richiesta a http:// non si connette e attende che scada il timeout. L'URL dell'ambiente è https:// seguito dal CNAME dell'ambiente. DescribeEnvironmentsrestituisce il CNAME senza uno schema, quindi aggiungilo https:// quando lo apri.

Non è necessario fornire un certificato perché funzioni. Elastic Beanstalk crea un certificato AWS Certificate Manager (ACM) per il dominio dell'ambiente, lo collega al listener HTTPS e lo rinnova, in modo che un browser si fida del CNAME dell'ambiente senza alcuna configurazione. Elastic Beanstalk crea un certificato per ogni ambiente e lo elimina quando si chiude l'ambiente.

Per servire l'ambiente da un tuo dominio, inserisci l'ARN del tuo certificato nell'opzione. certificate-arn Il load balancer trasporta quindi il tuo certificato oltre a quello creato da Elastic Beanstalk e tu rimani responsabile del rinnovo e dell'eliminazione del tuo.

Per accettare anche richieste HTTP, aggiungi un listener HTTP listen-ports e imposta ssl-redirect la porta di un listener HTTPS. Elastic Beanstalk reindirizza le richieste sui listener HTTP al tuo listener HTTPS. Un listener HTTP non serve mai direttamente il traffico delle applicazioni. ssl-redirectseleziona a quale porta HTTPS è indirizzato il reindirizzamento e, se non la imposti, Elastic Beanstalk utilizza la porta del tuo listener HTTPS. Un listen-ports valore è esso stesso un documento JSON, quindi passa le impostazioni in un file anziché scriverle sulla riga di comando:

$ cat listeners.json
[
  {
    "Namespace": "aws:elasticbeanstalk:eks:alb",
    "OptionName": "listen-ports",
    "Value": "[{\"HTTPS\":443},{\"HTTP\":80}]"
  },
  {
    "Namespace": "aws:elasticbeanstalk:eks:alb",
    "OptionName": "ssl-redirect",
    "Value": "443"
  }
]
$ aws elasticbeanstalk update-environment \
    --environment-name my-cluster-env \
    --option-settings file://listeners.json

Elastic Beanstalk non aggiunge il listener HTTPS quando lo load-balancer-type imposti o quando fornisci il tuo load balancer. None arn Con None l'ambiente non ha affatto un sistema di bilanciamento del carico, quindi non ha listener. Se fornite il vostro load balancer, potete gestirne la configurazione del listener.

Usare un sistema di bilanciamento del carico di tua proprietà

Per mettere un load balancer esistente davanti all'ambiente, imposta l'arnopzione nel aws:elasticbeanstalk:eks:alb namespace sul relativo ARN. Il valore deve essere un Application Load Balancer. Elastic Beanstalk rifiuta l'ARN di un Network Load Balancer.

Quando fornisci un load balancer, ne possiedi la configurazione: i suoi listener, il suo certificato TLS e il suo schema. Elastic Beanstalk registra l'applicazione come destinazione e segnala il load balancer come load balancer dell'ambiente, quindi DescribeEnvironmentResources restituisce il load balancer che hai fornito anziché quello creato da Elastic Beanstalk.

Ambienti senza un sistema di bilanciamento del carico

Se impostato su load-balancer-typeNone, Elastic Beanstalk non crea un sistema di bilanciamento del carico per l'ambiente e DescribeEnvironmentResources non segnala alcun sistema di bilanciamento del carico. Usalo per un ambiente che serve solo altri ambienti sullo stesso cluster, come un'API interna o un worker a cui i chiamanti raggiungono direttamente.

Due conseguenze da pianificare:

Indirizzare un ambiente da un altro

Ogni ambiente Beanstalk Cluster è raggiungibile all'interno del cluster a un indirizzo prevedibile creato a partire dal nome dell'ambiente:

service-environment-name.eb-environment-name.svc.cluster.local:service-port

La porta è quella dell'ambiente. service-port Elastic Beanstalk esegue ogni ambiente in uno spazio dei nomi Kubernetes denominato eb- seguito dal nome dell'ambiente, che è la seconda etichetta dell'indirizzo. Passa gli indirizzi necessari all'applicazione come variabili di ambiente, utilizzando l'opzione nel namespace: env-variables aws:elasticbeanstalk:eks:environment

Il valore di env-variables è esso stesso un documento JSON, quindi passate le impostazioni delle opzioni in un file anziché nella riga di comando. Salva quanto segue comeoptions.json:

[
  {
    "Namespace": "aws:elasticbeanstalk:eks:environment",
    "OptionName": "env-variables",
    "Value": "{\"NOTIFIER_URL\":\"http://service-my-notifier.eb-my-notifier.svc.cluster.local:8080\"}"
  }
]

Quindi applicalo:

$ aws elasticbeanstalk update-environment \
    --environment-name my-frontend \
    --option-settings file://options.json

Questo indirizzamento funziona solo tra ambienti eseguiti sullo stesso cluster, ovvero ambienti che utilizzano le stesse sottoreti. Risolvere l'indirizzo non equivale a consentire la connessione. Per impostazione predefinita, Beanstalk Cluster blocca il traffico tra gli ambienti su un cluster condiviso, quindi il nome si risolve e la connessione continua a fallire finché non viene autorizzata. Consulta Consentire agli ambienti di comunicare.

Impostazioni che scegli al momento della creazione

Non puoi modificare le sottoreti di un ambiente dopo averlo creato, perché ne selezionano il cluster. Lo stesso vale per i ruoli del cluster, del nodo e dell'osservabilità. Per eseguire l'applicazione in sottoreti diverse, create un nuovo ambiente con le sottoreti desiderate, quindi sostituite i due CNAME di ambiente. Consulta Blue/Green implementazioni con Elastic Beanstalk.