As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Configurando redes para ambientes Beanstalk Cluster

O Beanstalk Cluster executa seu ambiente em um cluster Amazon EKS. As sub-redes que você seleciona fazem duas coisas: determinam onde os nós do cluster são executados e determinam qual cluster executa o ambiente. Se você não selecionar nenhuma sub-rede, o Elastic Beanstalk usa as sub-redes públicas da VPC padrão.

Este tópico aborda as sub-redes do ambiente, como o tráfego chega ao seu aplicativo de fora do cluster e como seus ambientes se relacionam entre si dentro do cluster.

Sub-redes de ambiente

Defina a subnets opção no aws:elasticbeanstalk:eks:environment namespace como uma lista separada por vírgulas de IDs de sub-rede.

Como as sub-redes selecionam o cluster, você as define ao criar o 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"}]'

A configuração é escrita como JSON porque a lista de sub-redes contém uma vírgula, que a forma AWS CLI abreviada trata como um separador entre os campos. Para os formulários que o AWS CLI aceita, consulte Usando sintaxe abreviada no. AWS CLI

O Elastic Beanstalk agrupa ambientes em clusters por esse conjunto de sub-redes, portanto, ambientes na mesma conta que usam as mesmas sub-redes são executados no mesmo cluster, e um ambiente que usa um conjunto diferente é executado em um cluster diferente. A ordem das sub-redes não importa. Para as regras de agrupamento e os eventos que relatam a atribuição de clusters, consulte. Agrupamento de ambientes

Como o tráfego chega ao seu aplicativo

A load-balancer-type opção no aws:elasticbeanstalk:eks:environment namespace escolhe como o tráfego chega ao seu aplicativo. Ele aceita dois valores:

Configurações de rede do balanceador de carga

O Application Load Balancer do ambiente tem suas próprias configurações de rede no aws:elasticbeanstalk:eks:alb namespace.

Ouvintes e HTTPS

A listen-ports opção no aws:elasticbeanstalk:eks:alb namespace lista os ouvintes do balanceador de carga como uma matriz JSON que mapeia cada protocolo para uma porta, por exemplo. [{"HTTPS":443},{"HTTP":80}]

O Elastic Beanstalk garante que o balanceador de carga encerre HTTPS em algum lugar:

O balanceador de carga abre somente os ouvintes com os quais está configurado. Com a configuração padrão, isso é HTTPS na porta 443 e nada na porta 80, portanto, uma solicitação para http:// não se conecta e espera até atingir o tempo limite. O URL do seu ambiente é https:// seguido pelo CNAME do ambiente. DescribeEnvironmentsretorna o CNAME sem um esquema, então adicione https:// ao abri-lo.

Você não fornece um certificado para que isso funcione. O Elastic Beanstalk cria um certificado Gerenciador de certificados da AWS (ACM) para o próprio domínio do ambiente, o anexa ao ouvinte HTTPS e o renova, para que um navegador confie no CNAME do ambiente sem nenhuma configuração. O Elastic Beanstalk cria um certificado para cada ambiente e o exclui quando você encerra o ambiente.

Para atender ao ambiente a partir de um domínio próprio, coloque o ARN do seu certificado na certificate-arn opção. O balanceador de carga então carrega seu certificado além daquele criado pelo Elastic Beanstalk, e você permanece responsável por renovar e excluir o seu.

Para aceitar solicitações HTTP também, adicione um ouvinte HTTP listen-ports e defina-o como ssl-redirect a porta de um ouvinte HTTPS. O Elastic Beanstalk redireciona solicitações em ouvintes HTTP para seu ouvinte HTTPS. Um ouvinte HTTP nunca fornece tráfego de aplicativos diretamente. ssl-redirectseleciona qual porta HTTPS o redirecionamento visa e, se você não a definir, o Elastic Beanstalk usa a porta do seu ouvinte HTTPS. Um listen-ports valor em si é um documento JSON, então passe as configurações em um arquivo em vez de escrevê-las na linha de 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

O Elastic Beanstalk não adiciona o ouvinte HTTPS quando você configura load-balancer-type ou fornece seu próprio balanceador de carga. None arn Como None o ambiente não tem nenhum balanceador de carga, ele não tem ouvintes. Quando você fornece seu próprio balanceador de carga, a configuração do ouvinte é sua para gerenciar.

Usando um balanceador de carga que você possui

Para colocar um balanceador de carga existente na frente do ambiente, defina a arn opção no aws:elasticbeanstalk:eks:alb namespace como seu ARN. O valor deve ser um Application Load Balancer. O Elastic Beanstalk rejeita o ARN de um Network Load Balancer.

Ao fornecer um balanceador de carga, você é o proprietário de sua configuração: seus ouvintes, seu certificado TLS e seu esquema. O Elastic Beanstalk registra seu aplicativo como alvo e relata seu balanceador de carga como o balanceador de carga do ambiente, então DescribeEnvironmentResources retorna o balanceador de carga que você forneceu em vez de um criado pelo Elastic Beanstalk.

Ambientes sem balanceador de carga

Quando você define comoNone, load-balancer-type o Elastic Beanstalk não cria um balanceador de carga para o ambiente e não DescribeEnvironmentResources relata nenhum balanceador de carga. Use isso para um ambiente que atenda apenas a outros ambientes no mesmo cluster, como uma API interna ou um trabalhador que seus chamadores acessam diretamente.

Duas consequências a serem planejadas:

Abordando um ambiente a partir de outro

Cada ambiente do Beanstalk Cluster pode ser acessado dentro de seu cluster em um endereço previsível criado a partir do nome do ambiente:

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

O porto é do meio ambienteservice-port. O Elastic Beanstalk executa cada ambiente em um namespace Kubernetes chamado eb- seguido pelo nome do ambiente, que é o segundo rótulo do endereço. Passe os endereços que seu aplicativo precisa como variáveis de ambiente, usando a env-variables opção no aws:elasticbeanstalk:eks:environment namespace:

O valor de em si env-variables é um documento JSON, então passe as configurações da opção em um arquivo em vez de na linha de comando. Salve o seguinte como options.json:

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

Em seguida, aplique-o:

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

Esse endereçamento funciona somente entre ambientes executados no mesmo cluster, o que significa ambientes que usam as mesmas sub-redes. Resolver o endereço não é o mesmo que ter permissão para se conectar. O Beanstalk Cluster bloqueia o tráfego entre ambientes em um cluster compartilhado por padrão, então o nome é resolvido e a conexão ainda falha até que você permita. Consulte Permitindo que ambientes se comuniquem.

Configurações que você escolhe na criação

Você não pode alterar as sub-redes de um ambiente depois de criá-lo, pois elas selecionam seu cluster. O mesmo se aplica às funções de cluster, nó e observabilidade. Para executar seu aplicativo em sub-redes diferentes, crie um novo ambiente com as sub-redes desejadas e, em seguida, troque os dois CNAMEs do ambiente. Consulte Blue/Green implantações com o Elastic Beanstalk.