Esecuzione di uno stack in un VPC

Importante

Il AWS OpsWorks Stacks servizio ha raggiunto la fine del ciclo di vita il 26 maggio 2024 ed è stato disabilitato sia per i clienti nuovi che per quelli esistenti. Consigliamo vivamente ai clienti di migrare i propri carichi di lavoro verso altre soluzioni il prima possibile. Se hai domande sulla migrazione, contatta il AWS Support Team su AWS re:post o tramite Premium AWS Support.

Puoi controllare l'accesso utente a istanze di uno stack creandolo in un virtual private cloud (VPC). Ad esempio, supponi di non volere che gli utenti abbiano accesso diretto ai server applicazioni o ai database dello stack e richiedere invece che tutto il traffico pubblico venga incanalato attraverso un sistema di bilanciamento del carico elastico.

Procedura di base per l'esecuzione di uno stack in un VPC:

1. Crea un VPC configurato in modo appropriato, utilizzando la console o l'API Amazon VPC o un modello. AWS CloudFormation

2. Indicazione dell'ID VPC al momento della creazione dello stack.

3. Avvio delle istanze dello stack nella sottorete appropriata.

La sezione seguente descrive in breve il funzionamento dei VPC in AWS OpsWorks Stacks.

Importante

Se utilizzi la funzionalità VPC Endpoint, tieni presente che ogni istanza dello stack deve essere in grado di completare le seguenti azioni da Amazon Simple Storage Service (Amazon S3) Simple Storage Service (Amazon S3):

• Installazione dell'agente dell'istanza.

• Installazione degli asset, come Ruby.

• Caricamento dei log di esecuzione di Chef.

• Recupero dei comandi dello stack.

Per permettere queste operazioni, devi assicurarti che le istanze dello stack abbiano accesso ai bucket seguenti, corrispondenti alla regione dello stack. In caso contrario, le operazioni precedenti non riusciranno.

Per Chef 12 Linux e Chef 12.2 Windows, i bucket sono i seguenti.

Bucket di agenti	Bucket di asset	Bucket di log	Bucket DNA
opsworks-instance-agent-sa-est-1 opsworks-instance-agent-ap-sud-1 opsworks-instance-agent-ap- nord-est-1 opsworks-instance-agent-ap- nord-est-2 opsworks-instance-agent-ap- sud-est - 1 opsworks-instance-agent-ap- sud-est - 2 opsworks-instance-agent-ca-centrale-1 opsworks-instance-agent-eu-centrale-1 opsworks-instance-agent-eu-ovest-1 opsworks-instance-agent-eu-ovest-2 opsworks-instance-agent-eu-ovest-3 opsworks-instance-agent-us-est-1 opsworks-instance-agent-us-est-2 opsworks-instance-agent-us-ovest-1 opsworks-instance-agent-us-ovest-2	opsworks-instance-assets-us-est-2 opsworks-instance-assets-us-est-1 opsworks-instance-assets-ap-sud-1 opsworks-instance-assets-ap- nord-est-1 opsworks-instance-assets-ap- nord-est-2 opsworks-instance-assets-ap- sud-est - 1 opsworks-instance-assets-ap- sud-est - 2 opsworks-instance-assets-ca-centrale-1 opsworks-instance-assets-eu-centrale-1 opsworks-instance-assets-eu-ovest-1 opsworks-instance-assets-eu-ovest-2 opsworks-instance-assets-eu-ovest-3 opsworks-instance-assets-sa-est-1 opsworks-instance-assets-us-ovest-1 opsworks-instance-assets-us-ovest-2	opsworks-us-east-2 registri opsworks-us-east-1 registro opsworks-ap-south-1 registro opsworks-ap-northeast-1 registro opsworks-ap-northeast-2 registri opsworks-ap-southeast-1 registro opsworks-ap-southeast-2 registri opsworks-ca-central-1 registro opsworks-eu-central-1 registro opsworks-eu-west-1 registro opsworks-eu-west-2 registri opsworks-eu-west-3 registri opsworks-sa-east-1 registro opsworks-us-west-1 registro opsworks-us-west-2 registri	opsworks-us-east-2-DNA opsworks-us-east-1 DNA opsworks-ap-south-1 dna opsworks-ap-northeast-1 dna opsworks-ap-northeast-2-dna opsworks-ap-southeast-1 DNA opsworks-ap-southeast-2-dna opsworks-ca-central-1 DNA opsworks-eu-central-1 dna opsworks-eu-west-1 dna opsworks-eu-west-2-dna opsworks-eu-west-3-dna opsworks-sa-east-1 DNA opsworks-us-west-1 dna opsworks-us-west-2-dna

Per Chef 11.10 e versioni precedenti per Linux, i bucket sono i seguenti. Gli stack Chef 11.4 non sono supportati negli endpoint regionali al di fuori della regione Stati Uniti orientali (Virginia settentrionale).

Bucket di agenti	Bucket di asset	Bucket di log	Bucket DNA
opsworks-instance-agent-us-est-2 opsworks-instance-agent-us-est-1 opsworks-instance-agent-ap-sud-1 opsworks-instance-agent-ap- nord-est-1 opsworks-instance-agent-ap- nord-est-2 opsworks-instance-agent-ap- sud-est - 1 opsworks-instance-agent-ap- sud-est - 2 opsworks-instance-agent-ca-centrale-1 opsworks-instance-agent-eu-centrale-1 opsworks-instance-agent-eu-ovest-1 opsworks-instance-agent-eu-ovest-2 opsworks-instance-agent-eu-ovest-3 opsworks-instance-agent-us-est-1 opsworks-instance-agent-us-ovest-1 opsworks-instance-agent-us-ovest-2	opsworks-instance-assets-us-est-2 opsworks-instance-assets-us-est-1 opsworks-instance-assets-ap-sud-1 opsworks-instance-assets-ap- nord-est-1 opsworks-instance-assets-ap- nord-est-2 opsworks-instance-assets-ap- sud-est - 1 opsworks-instance-assets-ap- sud-est - 2 opsworks-instance-assets-ca-centrale-1 opsworks-instance-assets-eu-centrale-1 opsworks-instance-assets-eu-ovest-1 opsworks-instance-assets-eu-ovest-2 opsworks-instance-assets-eu-ovest-3 opsworks-instance-assets-sa-est-1 opsworks-instance-assets-us-ovest-1 opsworks-instance-assets-us-ovest-2	prod_stage-log	prod_stage-dna

Per ulteriori informazioni, consulta Endpoint VPC.

Nota

Affinché AWS OpsWorks Stacks si connetta agli endpoint VPC abilitati, devi anche configurare il routing per il tuo NAT o IP pubblico, poiché AWS OpsWorks l'agente Stacks richiede ancora l'accesso all'endpoint pubblico.

Nozioni di base sui VPC

Per una descrizione dettagliata dei VPC, consulta Amazon Virtual Private Cloud. In breve, un VPC è costituito da una o più sottoreti, ognuna delle quali contiene una o più istanze. A ogni sottorete è associata una tabella di routing che indirizza il traffico in uscita in base all'indirizzo IP di destinazione.

• Le istanze all'interno di un VPC possono comunicare tra loro per impostazione predefinita, indipendentemente dalla rispettiva sottorete. Tuttavia, le modifiche apportate a liste di controllo accessi di rete, policy dei gruppi di sicurezza o tramite indirizzi IP statici possono interrompere questa comunicazione.

• Le sottoreti le cui istanze sono in grado di comunicare con Internet vengono definite sottoreti pubbliche.

• Le sottoreti le cui istanze possono comunicare solo con altre istanze nel VPC e non direttamente con Internet vengono definite sottoreti private.

AWS OpsWorks Stacks richiede che il VPC sia configurato in modo che ogni istanza dello stack, incluse le istanze nelle sottoreti private, abbia accesso ai seguenti endpoint:

• Uno degli endpoint del servizio AWS OpsWorks Stacks elencati nella sezione «Region Support» di. Guida introduttiva a AWS OpsWorks Stacks

• Uno dei seguenti endpoint del servizio di istanza, utilizzato dall'agente Stacks. AWS OpsWorks L'agente viene eseguito sulle le istanze del cliente gestite per lo scambio dei dati con il servizio.

  • 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-sutheast-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

• Qualsiasi repository di pacchetti da cui dipende il sistema operativo, ad esempio i repository Amazon Linux o Ubuntu Linux.

• I repository della tua app e del libro di ricette personalizzato.

Esistono molti modi diversi per configurare un VPC in modo da fornire questa connettività. Di seguito è riportato un semplice esempio di come configurare un VPC per uno stack di server di app AWS OpsWorks Stacks.

Questo VPC include diversi componenti:

Sottoreti

Il VPC ha due sottoreti, una pubblica e una privata.

• La sottorete pubblica contiene un sistema di bilanciamento del carico e un dispositivo NAT (Network Address Translation), che possono comunicare con indirizzi esterni e con le istanze nella sottorete privata.

• La sottorete privata contiene i server applicazioni, che possono comunicare con il dispositivo NAT e il sistema di bilanciamento del carico nella sottorete pubblica, ma non possono comunicare direttamente con indirizzi esterni.

Internet Gateway

Il gateway Internet permette alle istanze con indirizzi IP pubblici, come il sistema di bilanciamento del carico, di comunicare con indirizzi esterni al VPC.

Sistema di bilanciamento del carico

Il sistema di bilanciamento del carico Elastic Load Balancing riceve il traffico in ingresso dagli utenti, lo distribuisce ai server applicazioni nella sottorete privata e restituisce le risposte agli utenti.

NAT

Il dispositivo (NAT) fornisce ai server applicazioni accesso Internet limitato, utilizzato in genere per scopi come il download degli aggiornamenti software da un repository esterno. Tutte le istanze AWS OpsWorks Stacks devono essere in grado di comunicare con AWS OpsWorks Stacks e con i repository Linux appropriati. Un metodo per gestire questo problema consiste nell'inserire un dispositivo NAT con un indirizzo IP elastico (EIP) associato in una sottorete pubblica. Puoi quindi instradare il traffico in uscita dalle istanze nella sottorete privata attraverso il dispositivo NAT.

Nota

Una sola istanza NAT crea un singolo punto di errore nel traffico in uscita della sottorete privata. Puoi migliorare l'affidabilità configurando il VPC con una coppia di istanze NAT che possano subentrare una all'altra quando una delle due è danneggiata. Per ulteriori informazioni, consulta la pagina relativa all'alta disponibilità per istanze NAT VPC. Puoi anche utilizzare un gateway NAT. Per ulteriori informazioni, consulta NAT nella Amazon VPC User Guide.

La configurazione VPC ottimale dipende dallo stack di AWS OpsWorks stack utilizzato. Di seguito vengono forniti alcuni esempi dei casi in cui puoi usare determinate configurazioni VPC. Per esempi di altri scenari VPC, consulta la pagina relativa agli scenari per l'uso di Amazon VPC.

Utilizzo di un'istanza in una sottorete pubblica

Se disponi di uno stack a istanza singola senza risorse private associate, ad esempio un'istanza Amazon RDS che non dovrebbe essere accessibile pubblicamente, puoi creare un VPC con una sottorete pubblica e inserire l'istanza in quella sottorete. Se non utilizzi un VPC predefinito, il livello dell'istanza deve assegnare un indirizzo IP elastico (EIP) all'istanza. Per ulteriori informazioni, consulta OpsWorks Nozioni di base sui livelli.

Utilizzo di risorse private

Se hai risorse che non devono essere accessibili pubblicamente, puoi creare un VPC con una sottorete pubblica e una sottorete privata. Ad esempio, in un ambiente di scalabilità automatica con bilanciamento del carico, puoi inserire tutte le istanze Amazon EC2 nella sottorete privata e il sistema di bilanciamento del carico in una sottorete pubblica. In questo modo non è possibile accedere direttamente alle istanze Amazon EC2 da Internet; tutto il traffico in entrata deve essere instradato attraverso il sistema di bilanciamento del carico.

La sottorete privata isola le istanze dall'accesso diretto degli utenti di Amazon EC2, ma devono comunque inviare richieste in uscita ad AWS e agli archivi di pacchetti Linux appropriati. Per permettere queste richieste, puoi, ad esempio, utilizzare un dispositivo NAT (Network Address Translation) con il relativo indirizzo IP elastico (EIP) e quindi instradare il traffico in uscita delle istanze attraverso il dispositivo NAT. Puoi inserire il dispositivo NAT nella stessa sottorete pubblica del sistema di bilanciamento del carico, come mostrato nell'esempio precedente.

• Se utilizzi un database di back-end come un'istanza Amazon RDS, puoi inserire tali istanze nella sottorete privata. Per le istanze Amazon RDS, devi specificare almeno due sottoreti diverse in zone di disponibilità diverse.

• Se hai bisogno dell'accesso diretto alle istanze in una sottorete privata, ad esempio, desideri utilizzare SSH per accedere a un'istanza, puoi inserire un bastion host nella sottorete pubblica che invia tramite proxy le richieste da Internet.

Estensione della rete in AWS

Se vuoi estendere la rete nel cloud e anche accedere direttamente a Internet dal VPC, puoi creare un gateway VPN. Per ulteriori informazioni, consulta lo scenario 3: VPC con sottoreti pubbliche e private e accesso VPN hardware.

Crea un VPC per uno stack di pile AWS OpsWorks

Questa sezione mostra come creare un VPC per uno stack AWS OpsWorks Stacks utilizzando un modello AWS di esempio. CloudFormation Puoi scaricare il modello nel file VPCtemplates.zip. OpsWorks Per ulteriori informazioni su come creare manualmente un VPC come quello descritto in questo argomento, consulta lo scenario 2: VPC con sottoreti pubbliche e private. Per informazioni su come configurare tabelle di routing, gruppi di sicurezza e così via, consulta il modello di esempio.

Nota

Per impostazione predefinita, AWS OpsWorks Stacks visualizza i nomi delle sottoreti concatenando l'intervallo CIDR e la zona di disponibilità, ad esempio. 10.0.0.1/24 - us-east-1b Per rendere i nomi più leggibili, crea un tag per ogni sottorete con Key impostato su e Value impostato sul nome della sottorete. Name AWS OpsWorks Stacks aggiunge quindi il nome della sottorete al nome predefinito. Ad esempio, la sottorete privata dell'esempio seguente ha un tag con Nome impostato suPrivate, che viene visualizzato come. OpsWorks 10.0.0.1/24 us-east - 1b - Private

Puoi avviare un modello VPC utilizzando la AWS CloudFormation console con pochi passaggi. La procedura seguente utilizza il modello di esempio per creare un VPC nella regione Stati Uniti orientali (Virginia settentrionale). Per indicazioni su come utilizzare il modello per creare un VPC in altre regioni, consulta la nota che segue la procedura.

Per creare il VPC

1. Aprire la console AWS CloudFormation, selezionare la regione US East (N. Virginia) (Stati Uniti orientali (Virginia settentrionale)) e scegliere Create Stack (Crea stack).

2. Nella pagina Select Template (Seleziona modello), selezionare Upload a template to Amazon S3 (Carica un modello in Amazon S3). Cercate il OpsWorksinVPC.template file scaricato nel file OpsWorks VPCtemplates.zip .Scegliete Continua.

   

   Puoi anche avviare questo stack aprendo AWS CloudFormation Sample Templates, individuando il modello VPC AWS OpsWorks Stacks e scegliendo Launch Stack.

3. Nella pagina Specify Parameters (Specifica parametri) accettare i valori predefiniti e scegliere Continue (Continua).

4. Nella pagina Add Tags (Aggiungi tag) creare un tag con Key (Chiave) impostato su Name e Value (Valore) impostato sul nome del VPC. Questo tag faciliterà l'identificazione del tuo VPC quando crei uno AWS OpsWorks stack Stacks.

5. Scegliere Continue (Continua), quindi Close (Chiudi) per avviare lo stack.

Nota: puoi creare il VPC in altre regioni utilizzando uno dei metodi seguenti.

• Vai a Utilizzo di modelli in diverse regioni, scegli la regione appropriata, individua il modello VPC AWS OpsWorks Stacks, quindi scegli Launch Stack.

• Copia il file del modello nel sistema, seleziona la regione appropriata nella console AWS CloudFormation e utilizza l'opzione Upload a template to Amazon S3 (Carica un modello in Amazon S3) della procedura guidata Create Stack (Crea stack) per caricare il modello dal sistema.

Il modello di esempio include output che forniscono gli ID VPC, subnet e load balancer necessari per creare lo stack Stacks. AWS OpsWorks Puoi vederli scegliendo la scheda Output nella parte inferiore della finestra della console. AWS CloudFormation