Execução de uma Stack em uma VPC

Importante

O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no AWS re:POST ou por meio do Premium AWS Support.

Você pode controlar o acesso de usuário a instâncias de uma stack ao criá-la em uma nuvem privada virtual (VPC). Por exemplo, talvez não seja necessário que os usuários tenham acesso direto aos servidores ou bancos de dados do aplicativo do seu stack e você queira que todo o tráfego público seja canalizado por meio de um elastic load balancer.

O procedimento básico para a execução de uma stack em uma VPC é:

1. Crie uma VPC configurada adequadamente usando o console ou a API da ou um modelo do AWS CloudFormation .

2. Especifique o ID da VPC quando você criar a stack.

3. Inicie as instâncias da stack na sub-rede apropriada.

A seguir, uma breve descrição do funcionamento das VPCs no AWS OpsWorks Stacks.

Importante

Se você usar o atributo Endpoint da VPC, esteja ciente de que cada instância da pilha deverá ser capaz de concluir as ações a seguir no Amazon Simple Storage Service (Amazon S3):

• Instale o agente da instância.

• Instale ativos, como o Ruby.

• Carregue os logs de execução do Chef.

• Recupere comandos da stack.

Para permitir estas ações, você deve garantir que as instâncias da stack tenham acesso aos seguintes buckets, que correspondem à região da stack. Caso contrário, as ações anteriores falharão.

Para o Chef 12 Linux e o Chefe 12.2 Windows, os buckets são os seguintes.

Buckets de agente	Buckets de ativo	Buckets de log	Buckets do DNA
opsworks-instance-agent-sa-leste-1 opsworks-instance-agent-ap-sul-1 opsworks-instance-agent-ap-nordeste-1 opsworks-instance-agent-ap-nordeste-2 opsworks-instance-agent-ap-sudeste-1 opsworks-instance-agent-ap-sudeste-2 opsworks-instance-agent-ca-central-1 opsworks-instance-agent-eu-central-1 opsworks-instance-agent-eu-oeste-1 opsworks-instance-agent-eu-oeste-2 opsworks-instance-agent-eu-oeste-3 opsworks-instance-agent-us-leste-1 opsworks-instance-agent-us-leste-2 opsworks-instance-agent-us-oeste-1 opsworks-instance-agent-us-oeste-2	opsworks-instance-assets-us-leste-2 opsworks-instance-assets-us-leste-1 opsworks-instance-assets-ap-sul-1 opsworks-instance-assets-ap-nordeste-1 opsworks-instance-assets-ap-nordeste-2 opsworks-instance-assets-ap-sudeste-1 opsworks-instance-assets-ap-sudeste-2 opsworks-instance-assets-ca-central-1 opsworks-instance-assets-eu-central-1 opsworks-instance-assets-eu-oeste-1 opsworks-instance-assets-eu-oeste-2 opsworks-instance-assets-eu-oeste-3 opsworks-instance-assets-sa-leste-1 opsworks-instance-assets-us-oeste-1 opsworks-instance-assets-us-oeste-2	opsworks-us-east-2-log opsworks-us-east-1 log opsworks-ap-south-1 log opsworks-ap-northeast-1 log opsworks-ap-northeast-2-log opsworks-ap-southeast-1 log opsworks-ap-southeast-2-log opsworks-ca-central-1 log opsworks-eu-central-1 log opsworks-eu-west-1 log opsworks-eu-west-2-log opsworks-eu-west-3 troncos opsworks-sa-east-1 log opsworks-us-west-1 log opsworks-us-west-2-log	opsworks-us-east2-DNA opsworks-us-east1-dna opsworks-ap-south1-dna opsworks-ap-northeast1-dna opsworks-ap-northeast2-DNA opsworks-ap-southeast1-dna opsworks-ap-southeast2-DNA opsworks-ca-central1-dna opsworks-eu-central1-dna opsworks-eu-west1-dna opsworks-eu-west2-DNA opsworks-eu-west3-DNA opsworks-sa-east1-dna opsworks-us-west1-dna opsworks-us-west2-DNA

Para o Chef 11.10 e versões anteriores para Linux, os buckets são os seguintes. As pilhas do Chef 11.4 não são compatíveis com endpoints regionais fora do Leste dos EUA (N. da Virgínia).

Buckets de agente	Buckets de ativo	Buckets de log	Buckets do DNA
opsworks-instance-agent-us-leste-2 opsworks-instance-agent-us-leste-1 opsworks-instance-agent-ap-sul-1 opsworks-instance-agent-ap-nordeste-1 opsworks-instance-agent-ap-nordeste-2 opsworks-instance-agent-ap-sudeste-1 opsworks-instance-agent-ap-sudeste-2 opsworks-instance-agent-ca-central-1 opsworks-instance-agent-eu-central-1 opsworks-instance-agent-eu-oeste-1 opsworks-instance-agent-eu-oeste-2 opsworks-instance-agent-eu-oeste-3 opsworks-instance-agent-us-leste-1 opsworks-instance-agent-us-oeste-1 opsworks-instance-agent-us-oeste-2	opsworks-instance-assets-us-leste-2 opsworks-instance-assets-us-leste-1 opsworks-instance-assets-ap-sul-1 opsworks-instance-assets-ap-nordeste-1 opsworks-instance-assets-ap-nordeste-2 opsworks-instance-assets-ap-sudeste-1 opsworks-instance-assets-ap-sudeste-2 opsworks-instance-assets-ca-central-1 opsworks-instance-assets-eu-central-1 opsworks-instance-assets-eu-oeste-1 opsworks-instance-assets-eu-oeste-2 opsworks-instance-assets-eu-oeste-3 opsworks-instance-assets-sa-leste-1 opsworks-instance-assets-us-oeste-1 opsworks-instance-assets-us-oeste-2	prod_stage-log	prod_stage-dna

Para obter mais informações, consulte VPC Endpoints.

nota

Para que o AWS OpsWorks Stacks se conecte aos VPC endpoints que você habilita, você também deve configurar o roteamento para seu NAT ou IP público, pois AWS OpsWorks o agente Stacks ainda exige acesso ao endpoint público.

Conceitos básicos da VPC

Para ver uma discussão detalhada sobre VPCs, consulte Amazon Virtual Private Cloud. Em resumo, uma VPC consiste em uma ou mais sub-redes, sendo que cada uma delas contém uma ou mais instâncias. Cada sub-rede tem uma tabela de roteamento associada que direciona o tráfego de saída com base em seu endereço IP de destino.

• As instâncias em uma VPC geralmente podem se comunicar entre si por padrão, independentemente da sub-rede. No entanto, as alterações em listas de controle de acesso (ACLs) de rede, políticas de security groups ou o uso de endereços IP estáticos podem interromper essa comunicação.

• As sub-redes cujas instâncias podem se comunicar com a Internet são conhecidas como sub-redes públicas.

• As sub-redes cujas instâncias podem se comunicar apenas com outras instâncias na VPC e não podem se comunicar diretamente com a Internet são conhecidas como sub-redes privadas.

AWS OpsWorks As pilhas exigem que a VPC seja configurada para que todas as instâncias na pilha, incluindo instâncias em sub-redes privadas, tenham acesso aos seguintes endpoints:

• Um dos endpoints do serviço AWS OpsWorks Stacks listados na seção “Region Support” do. Introdução ao AWS OpsWorks Stacks

• Um dos seguintes endpoints de serviço de instância, usado pelo agente AWS OpsWorks Stacks. O agente é executado em instâncias gerenciadas pelo cliente para trocar dados com o serviço.

  • opsworks-instance-service.us-east-2.amazonaws.com

  • opsworks-instance-service.us-east-1.amazonaws.com

  • opsworks-instance-service.us-west-1.amazonaws.com

  • opsworks-instance-service.us-west-2.amazonaws.com

  • opsworks-instance-service.ap-south-1.amazonaws.com

  • opsworks-instance-service.ap-northeast-1.amazonaws.com

  • opsworks-instance-service.ap-northeast-2.amazonaws.com

  • opsworks-instance-service.ap-southeast-1.amazonaws.com

  • opsworks-instance-service.ap-southeast-2.amazonaws.com

  • opsworks-instance-service.ca-central-1.amazonaws.com

  • opsworks-instance-service.eu-central-1.amazonaws.com

  • opsworks-instance-service.eu-west-1.amazonaws.com

  • opsworks-instance-service.eu-west-2.amazonaws.com

  • opsworks-instance-service.eu-west-3.amazonaws.com

• Amazon S3

• Todos os repositórios de pacote dos quais seu sistema operacional depende, como os repositórios do Amazon Linux ou do Ubuntu Linux.

• Seus repositórios de aplicativos e de livros de receitas personalizados.

Há uma série de maneiras de configurar uma VPC para fornecer essa conectividade. Veja a seguir um exemplo simples de como você pode configurar uma VPC para uma pilha de servidores de aplicativos AWS OpsWorks Stacks.

Esta VPC tem vários componentes:

Subredes

A VPC tem duas sub-redes, uma pública e uma privada.

• A sub-rede pública contém um load balancer e um dispositivo de conversão de endereços de rede (NAT), que podem se comunicar com os endereços externos e com as instâncias na sub-rede privada.

• A sub-rede privada contém os servidores de aplicativos, que podem se comunicar com a NAT e o load balancer na sub-rede pública, mas não podem se comunicar diretamente com os endereços externos.

gateway da Internet

O Internet gateway permite que as instâncias com endereços IP públicos, como o load balancer, se comuniquem com endereços fora da VPC.

Load balancer

O load balancer do Elastic Load Balancing leva o tráfego de entrada de usuários, o distribui para os servidores de aplicativos na sub-rede privada e retorna as respostas aos usuários.

NAT

O dispositivo (NAT) fornece os servidores de aplicativos com acesso limitado à Internet, que normalmente é usado para fins como o download de atualizações de software de um repositório externo. Todas as instâncias do AWS OpsWorks Stacks devem ser capazes de se comunicar com o AWS OpsWorks Stacks e com os repositórios Linux apropriados. Uma forma de lidar com esse problema é colocar um dispositivo NAT com um Endereço IP elástico associado em uma sub-rede pública. Você pode então rotear o tráfego de saída de instâncias na sub-rede privada pro meio da NAT.

nota

Uma única instância NAT cria um ponto único de falha no tráfego de saída em sua sub-rede privada. Você pode melhorar a confiabilidade ao configurar a VPC com um par de instâncias NAT que assuma o lugar da outra em caso de falha. Para obter mais informações, consulte Alta disponibilidade para instâncias NAT da Amazon VPC. Você também pode usar um gateway NAT. Para obter mais informações, consulte NAT no Guia do usuário da Amazon VPC.

A configuração ideal de VPC depende da sua AWS OpsWorks pilha de pilhas. A seguir, alguns exemplos de quando você pode usar determinadas configurações da VPC. Para obter exemplos de outros cenários da VPC, consulte Cenários de uso da Amazon VPC.

Working with one instance in a public subnet (Trabalhar com uma instância em uma sub-rede pública)

Se você tiver uma pilha com uma única instância sem recursos privados associados, como uma instância do Amazon RDS que não deve ficar acessível publicamente, poderá criar uma VPC com uma sub-rede pública e colocar a instância na sub-rede. Se você não estiver usando uma VPC padrão, deverá fazer com que a layer da instância atribua um Endereço IP elástico à instância. Para ter mais informações, consulte OpsWorks Noções básicas sobre camadas.

Working with private resources (Trabalhar com recursos privados)

Se você tiver recursos que não devem ficar acessíveis publicamente, poderá criar uma VPC com uma sub-rede pública e uma sub-rede privada. Por exemplo, em um ambiente de escalabilidade automática com balanceamento de carga, você pode colocar todas as instâncias do Amazon EC2 na sub-rede privada e o balanceador de carga em uma sub-rede pública. Dessa forma, as instâncias do Amazon EC2 não podem ser diretamente acessadas da Internet, todo o tráfego de entrada deve ser roteado por meio do balanceador de carga.

A sub-rede privada isola as instâncias do acesso de usuário direto do Amazon EC2, mas elas ainda devem enviar solicitações de saída para o AWS e os repositórios de pacotes do Linux apropriados. Para permitir essas solicitações, você pode, por exemplo, usar um dispositivo de conversão de endereços de rede (NAT) com seu próprio Endereço IP elástico e então rotear o tráfego de saída das instâncias por meio da NAT. Você pode colocar a NAT na mesma sub-rede pública do load balancer, como mostrado no exemplo anterior.

• Se você estiver usando um banco de dados de back-end, como uma instância do Amazon RDS, você pode colocar essas instâncias na sub-rede privada. Para instâncias do Amazon RDS, você deve especificar pelo menos duas sub-redes diferentes em Zonas de disponibilidade diferentes.

• Se você precisar de acesso direto para instâncias em uma sub-rede privada, por exemplo, você deseja usar o SSH para fazer login em uma instância, você pode colocar um bastion host na sub-rede pública que faz solicitações de proxy da Internet.

Extending your own network into AWS (Como estender sua própria rede na AWS)

Se você quiser estender sua própria rede para a nuvem e também acessar diretamente a Internet de sua VPC, poderá criar um gateway de VPN. Para obter mais informações, consulte Cenário 3: VPC com sub-redes pública e privada e acesso a VPN de hardware.

Crie uma VPC para uma pilha de pilhas AWS OpsWorks

Esta seção mostra como criar uma VPC para uma pilha de AWS OpsWorks pilhas usando um exemplo de modelo da AWS. CloudFormation Você pode baixar o modelo no arquivo OpsWorks VPCtemplates.zip. Para obter mais informações sobre como criar manualmente uma VPC como a discutida neste tópico, consulte Cenário 2: VPC com sub-redes pública e privada. Para obter detalhes sobre como configurar tabelas de roteamento, security groups e assim por diante, consulte o modelo de exemplo.

nota

Por padrão, o AWS OpsWorks Stacks exibe os nomes das sub-redes concatenando o intervalo CIDR e a zona de disponibilidade, como. 10.0.0.1/24 - us-east-1b Para tornar os nomes mais legíveis, crie uma tag para cada sub-rede com a chave definida como Name e o valor definido como o nome da sub-rede. AWS OpsWorks Em seguida, Stacks acrescenta o nome da sub-rede ao nome padrão. Por exemplo, a sub-rede privada no exemplo a seguir tem uma tag com Nome definido comoPrivate, que é OpsWorks exibida como10.0.0.1/24 us-east - 1b - Private.

Você pode iniciar um modelo de VPC usando o AWS CloudFormation console com apenas algumas etapas. O procedimento a seguir usa o modelo de exemplo para criar uma VPC no Leste dos EUA (N. da Virgínia). Para obter instruções sobre como usar o modelo para criar uma VPC em outras regiões, consulte a observação que segue o procedimento.

Como criar a VPC

1. Abra o console do AWS CloudFormation, selecione a região US East (N. Virginia) (Leste dos EUA (Norte da Virgínia)) e a opção Create Stack (Criar pilha).

2. Na página Select Template (Escolher modelo), selecione Upload a template (Fazer upload de um modelo). Procure o OpsWorksinVPC.template arquivo que você baixou no arquivo OpsWorks VPCtemplates.zip. Escolha Continuar.

   

   Você também pode iniciar essa pilha abrindo modelos de CloudFormation amostra da AWS, localizando o modelo de VPC do AWS OpsWorks Stacks e escolhendo Launch Stack.

3. Na página Specify Parameters (Especificar parâmetros), aceite os valores padrão e escolha Continue (Continuar).

4. Na página Add Tags (Adicionar tags), crie uma tag com Key (Chave) definida como Name e Value (Valor) definido como o nome da VPC. Essa tag facilitará a identificação de sua VPC ao criar uma AWS OpsWorks pilha de pilhas.

5. Escolha Continue (Continuar) e depois Close (Fechar) para iniciar a pilha.

Observação: você pode criar a VPC em outras regiões usando uma das seguintes abordagens.

• Acesse Usando modelos em diferentes regiões, escolha a região apropriada, localize o modelo de VPC do AWS OpsWorks Stacks e escolha Launch Stack.

• Copie o arquivo de modelo para seu sistema, selecione a região apropriada no console do AWS CloudFormation e use a opção Upload a template to Amazon S3 do assistente Create Stack para fazer o upload do modelo do seu sistema.

O modelo de exemplo inclui saídas que fornecem os IDs de VPC, sub-rede e balanceador de carga necessários para criar a pilha Stacks. AWS OpsWorks Você pode vê-las escolhendo a guia Saídas na parte inferior da janela do AWS CloudFormation console.