Risoluzione dei problemi relativi agli stack AWS OpsWorks

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.

Questa sezione contiene alcuni problemi di AWS OpsWorks Stacks più comuni e le relative soluzioni.

Impossibile gestire le istanze

Problema: non sei in grado di gestire un'istanza che in passato riuscivi invece a gestire. In alcuni casi, nei log è riportato un errore simile al seguente.

Aws::CharlieInstanceService::Errors::UnrecognizedClientException - The security token included in the request is invalid.

Causa: ciò può essere dovuto alla modifica o all'eliminazione di una risorsa esterna a AWS OpsWorks da cui dipende l'istanza. Di seguito sono elencati alcuni esempi di modifiche di risorse che possono interrompere le comunicazioni con un'istanza.

• Un utente o un ruolo IAM associato all'istanza è stato eliminato accidentalmente, all'esterno di AWS OpsWorks Stacks. Ciò causa un errore di comunicazione tra l' AWS OpsWorks agente installato sull'istanza e il servizio AWS OpsWorks Stacks. L'utente associato a un'istanza è un'informazione obbligatoria per tutta la durata dell'istanza.

• La modifica delle configurazioni relative a volumi o storage quando un'istanza è offline può rendere ingestibile un'istanza.

• Aggiungere manualmente istanze EC2 a un ELB. AWS OpsWorks riconfigura un load balancer Elastic Load Balancing assegnato ogni volta che un'istanza entra o esce dallo stato online. AWS OpsWorks considera solo le istanze che conosce come membri validi; le istanze che vengono aggiunte all'esterno o mediante un altro AWS OpsWorks processo vengono rimosse. Ogni altra istanza viene rimossa.

Soluzione: non eliminare gli utenti o i ruoli IAM da cui dipendono le istanze. Se possibile, modificare le configurazioni relative a volumi o storage solo quando le istanze dipendenti sono in esecuzione. Utilizzalo AWS OpsWorks per gestire il bilanciamento del carico o le appartenenze EIP delle istanze. AWS OpsWorks Quando registri un'istanza, per evitare problemi di gestione delle istanze registrate nel caso in cui l'utente venga eliminato accidentalmente, aggiungi il --use-instance-profile parametro al register comando per utilizzare invece il profilo di istanza integrato dell'istanza.

Dopo un'esecuzione di Chef le istanze non vengono avviate

Problema: negli stack Chef 11.10 o di versioni precedenti non configurati per l'uso di libri di ricette personalizzati, dopo un'esecuzione di Chef in cui sono stati utilizzati libri di ricette della community, le istanze non vengono avviate. Nei messaggi di log può essere indicato che la compilazione delle ricette ha avuto esito negativo ("Recipe Compile Error" (Errore di compilazione della ricetta)) oppure che risulta impossibile caricare le ricette perché non è stata trovata alcuna dipendenza.

Causa: la causa più comune è che il libri di ricette personalizzato o della community non supporta la versione di Chef utilizzata dallo stack. Alcuni libri di ricette della community più diffusi, ad esempio apt e build-essential, sono caratterizzati da problemi di compatibilità con Chef 11.10 noti.

Soluzione: negli AWS OpsWorks stack con l'impostazione Usa libri di cucina personalizzati Chef attivata, i ricettari personalizzati o comunitari devono sempre supportare la versione di Chef utilizzata dallo stack. Bloccare i libri di ricette della community a una versione specifica, ovvero impostare il numero di versione dei libri di ricette su una versione specifica che sia compatibile con la versione di Chef configurata nelle impostazioni dello stack. Per trovare una versione di libro di ricette della community supportata, visualizzare i log delle modifiche per un libro di ricette non compilato e utilizzare solo la versione più recente del libro di ricette supportata dallo stack. Per bloccare la versione di un libro di ricette, specificare il numero di versione esatto nel file Berksfile dell'archivio di libri di ricette personalizzati. Ad esempio, cookbook 'build-essential', '= 3.2.0'.

Tutte le istanze di un livello non superano l'Elastic Load Balancing Health Check

Problema: colleghi un load balancer Elastic Load Balancing a un livello di app server, ma tutte le istanze non superano il controllo di integrità.

Causa: quando crei un load balancer Elastic Load Balancing, devi specificare il percorso ping chiamato dal load balancer per determinare se l'istanza è integra. Assicurarsi di specificare un percorso di ping appropriato per l'applicazione. Il valore predefinito è /index.html. Se l'applicazione non include un file index.html, è necessario specificare un percorso appropriato. In caso contrario, il controllo dello stato avrà esito negativo. Ad esempio, l'applicazione SimplePHPApp utilizzata in Nozioni di base sugli stack Linux Chef 11 non utilizza index.html; il percorso di ping appropriate per tali server è /.

Soluzione: modificare il percorso di ping del sistema di bilanciamento del carico. Per ulteriori informazioni, consulta Elastic Load Balancing.

Impossibile comunicare con un Elastic Load Balancing Load Balancer

Problema: crei un load balancer Elastic Load Balancing e lo colleghi a un livello di app server, ma quando fai clic sul nome DNS o sull'indirizzo IP del load balancer per eseguire l'applicazione, ricevi il seguente errore: «Il server remoto non risponde».

Causa: se lo stack è in esecuzione in un VPC predefinito, quando crei un sistema di bilanciamento del carico Elastic Load Balancing nella regione, devi specificare un gruppo di sicurezza. Il gruppo di sicurezza deve avere regole in entrata che consentono il traffico in entrata dall'indirizzo IP in uso. Se si specifica un valore nel campo default VPC security group (gruppo di sicurezza del VPC predefinito), la regola in entrata predefinita non accetta traffico in entrata.

Soluzione: modificare le regole in entrata del gruppo di sicurezza in modo che venga accettato il traffico in entrata dagli indirizzi IP appropriati.

1. Fai clic su Gruppi di sicurezza nel pannello di navigazione della console Amazon EC2.

2. Impostare il gruppo di sicurezza del sistema di bilanciamento del carico.

3. Fare clic su Edit (Modifica) nella scheda Inbound (In entrata).

4. Aggiungere una regola in entrata con l'opzione Source (Origine) impostata su un CIDR appropriato.

   Ad esempio, se si specifica Anywhere (Ovunque), il CIDR viene impostato su 0.0.0.0/0, ovvero viene indicato al sistema di bilanciamento del carico di accettare il traffico in entrata da qualsiasi indirizzo IP.

Un'istanza in locale di rilievo non completa la configurazione del volume dopo il riavvio

Problema: riavvii un'istanza EC2 che hai importato in AWS OpsWorks Stacks e la console AWS OpsWorks Stacks visualizza lo stato dell'istanza con errore. Ciò si può verificare su istanze Chef 11 o Chef 12.

Causa: AWS OpsWorks Stacks potrebbe non essere in grado di collegare un volume all'istanza durante il processo di configurazione. Una causa possibile è che AWS OpsWorks Stacks sovrascrive la configurazione del volume sull'istanza quando esegue il comando setup.

Soluzione: aprire la pagina Details (Dettagli) relativa all'istanza, quindi controllare la configurazione del volume nell'area Volumes (Volumi). Si noti che è possibile modificare la configurazione del volume solo quando lo stato dell'istanza è stopped (arrestato). Assicurarsi che ogni volume disponga di un punto di montaggio e di un nome. Verifica di aver fornito il punto di montaggio corretto nella configurazione in AWS OpsWorks Stacks prima di riavviare l'istanza.

Un volume EBS non viene ricollegato dopo un riavvio

Problema: usi la console Amazon EC2 per collegare un volume Amazon EBS a un'istanza, ma quando riavvii l'istanza, il volume non è più collegato.

Causa: AWS OpsWorks gli stack possono ricollegare solo i volumi Amazon EBS di cui è a conoscenza, limitati a quanto segue:

• Volumi creati da Stacks. AWS OpsWorks

• I volumi dell'account in uso esplicitamente registrati con uno stack utilizzando la pagina Resources (Risorse).

Soluzione: gestisci i tuoi volumi Amazon EBS solo utilizzando la console AWS OpsWorks Stacks, l'API o la CLI. Se desideri utilizzare uno dei volumi Amazon EBS del tuo account con uno stack, utilizza la pagina Risorse dello stack per registrare il volume e collegarlo a un'istanza. Per ulteriori informazioni, consulta Gestione delle risorse.

Impossibile eliminare i gruppi di sicurezza di AWS OpsWorks Stacks

Problema: dopo aver eliminato uno stack, rimangono diversi gruppi di sicurezza AWS OpsWorks Stacks che non possono essere eliminati.

Causa: i gruppi di sicurezza devono essere eliminati in base a un determinato ordine.

Soluzione: accertarsi innanzitutto che nessuna istanza stia utilizzando i gruppi di sicurezza. Eliminare quindi i seguenti gruppi di sicurezza, se esistenti, nell'ordine indicato:

1. AWS- OpsWorks -Server vuoto

2. Server principale di monitoraggio OpsWorks AWS

3. Server principale AWS OpsWorks -DB

4. Server AWS OpsWorks Memcached

5. AWS- OpsWorks -Server personalizzato

6. AWS- OpsWorks -NodeJS-App-Server

7. Server di app AWS per OpsWorks PHP

8. Server di app AWS OpsWorks Rails

9. Server Web OpsWorks AWS

10. AWS- OpsWorks -Server predefinito

11. AWS- OpsWorks -LB-Server

Eliminato accidentalmente un gruppo di sicurezza Stacks AWS OpsWorks

Problema: hai eliminato uno dei gruppi di sicurezza AWS OpsWorks Stacks e devi ricrearlo.

Causa: questi gruppi di sicurezza vengono in genere eliminati per errore.

Soluzione: il gruppo ricreato deve essere la copia esatta dell'originale, rispettando anche l'uso di maiuscole e minuscole per il nome del gruppo. Anziché ricreare il gruppo manualmente, ti consigliamo di far eseguire l'attività automaticamente da AWS OpsWorks Stacks. Basta creare un nuovo stack nella stessa regione AWS e il VPC, se AWS OpsWorks presente, e Stacks ricreerà automaticamente tutti i gruppi di sicurezza integrati, incluso quello che hai eliminato. È quindi possibile eliminare lo stack se non è più necessario. I gruppi di sicurezza verranno conservati.

Interruzione imprevista del log di Chef

Problema: Un log di Chef viene interrotto in modo imprevisto. Ciò non indica una corretta esecuzione, né visualizza un'eccezione o una traccia di stack.

Causa: questo comportamento è in genere causato da memoria insufficiente.

Soluzione: creare un'istanza di dimensioni maggiori e utilizzare il comando run_command della CLI dell'agente per eseguire di nuovo le ricette. Per ulteriori informazioni, consulta Esecuzione di ricette.

Il libro di ricette non viene aggiornato

Problema: è stato eseguito l'aggiornamento dei libri di ricette, ma le istanze dello stack continuano a eseguire le vecchie ricette.

Causa: AWS OpsWorks Stacks memorizza nella cache i libri di cucina su ogni istanza ed esegue le ricette dalla cache, non dal repository. Quando avvii una nuova istanza, AWS OpsWorks Stacks scarica i tuoi libri di cucina dal repository nella cache dell'istanza. Tuttavia, se in seguito i libri di ricette personalizzati vengono modificati, AWS OpsWorks Stacks non aggiorna automaticamente le cache delle istanze online.

Soluzione: esegui il comando Update Cookbooks stack per indirizzare esplicitamente a AWS OpsWorks Stacks l'aggiornamento delle cache dei libri di cucina delle tue istanze online.

Le istanze si bloccano sullo stato Booting (Avvio in corso)

Problema: quando si riavvia un'istanza oppure quando la diagnostica automatica la riavvia automaticamente, l'operazione di avvio si blocca sullo stato booting.

Causa: una possibile causa di questo problema è la configurazione del VPC, compresa la configurazione di un VPC predefinito. Le istanze devono essere sempre in grado di comunicare con il servizio AWS OpsWorks Stacks, Amazon S3 e gli archivi di pacchetti, libri di cucina e app. Se, ad esempio, rimuovi un gateway predefinito da un VPC predefinito, le istanze perdono la connessione al AWS OpsWorks servizio Stacks. Poiché AWS OpsWorks Stacks non può più comunicare con l'agent dell'istanza, considera l'istanza come fallita e la guarisce automaticamente. Tuttavia, senza una connessione, AWS OpsWorks Stacks non può installare un agent di istanza sull'istanza riparata. Senza un agente, AWS OpsWorks Stacks non può eseguire le ricette di installazione sull'istanza, quindi l'operazione di avvio non può andare oltre lo stato di «avvio».

Soluzione: modificare la configurazione del VPC in modo che le istanze dispongano della connettività richiesta.

Riavvio imprevisto delle istanze

Problema: un'istanza arrestata viene riavviata inaspettatamente.

Causa 1: se hai abilitato la riparazione automatica per le tue istanze, AWS OpsWorks Stacks esegue periodicamente un controllo dello stato delle istanze Amazon EC2 associate e riavvia quelle non integre. Se interrompi o interrompi un'istanza AWS OpsWorks gestita da Stacks utilizzando la console, l'API o la CLI di Amazon EC2, Stacks non riceve alcuna notifica. AWS OpsWorks Considererà invece l'istanza arrestata come un'istanza non integra e pertanto la riavvierà automaticamente.

Soluzione: gestire le istanze solo utilizzando la console AWS OpsWorks Stacks, l'API o la CLI. Se usi AWS OpsWorks Stacks per interrompere o eliminare un'istanza, questa non verrà riavviata. Per ulteriori informazioni, consulta Avvio, arresto e riavvio manuali delle istanze 24 ore su 24, 7 giorni su 7 e Eliminazione delle AWS OpsWorks istanze di Stacks.

Causa 2: le istanze possono avere esito negativo per una serie di motivi. Se hai abilitato la riparazione automatica, AWS OpsWorks Stacks riavvia automaticamente le istanze non riuscite.

Soluzione: si tratta di un'operazione normale; non è necessario fare nulla a meno che non si desideri che AWS OpsWorks Stacks riavvii le istanze non riuscite. In questo caso, è necessario disabilitare la diagnostica automatica.

opsworks-agent Processi in esecuzione nelle istanze

Problema: sulle istanze sono in esecuzione diversi processi opsworks-agent. Per esempio:

aws 24543 0.0 1.3 172360 53332 ? S Feb24 0:29 opsworks-agent: master 24543
aws 24545 0.1 2.0 208932 79224 ? S Feb24 22:02 opsworks-agent: keep_alive of master 24543
aws 24557 0.0 2.0 209012 79412 ? S Feb24 8:04 opsworks-agent: statistics of master 24543
aws 24559 0.0 2.2 216604 86992 ? S Feb24 4:14 opsworks-agent: process_command of master 24

Causa: si tratta di processi validi necessari per il normale funzionamento dell'agente. Vengono eseguite attività quali la gestione delle distribuzioni e l'invio di messaggi keep-alive al servizio.

Soluzione: questo comportamento è normale. Non arrestare questi processi per evitare di compromettere il funzionamento dell'agente.

Comandi execute_recipes imprevisti

Problema: la sezione Logs (Log) nella pagina dei dettagli di un'istanza include comandi execute_recipes imprevisti. I comandi execute_recipes imprevisti possono venire visualizzati anche nelle pagine Stack e Deployments (Distribuzioni).

Causa: questo problema è spesso causato da modifiche apportate alle autorizzazioni. Quando modifichi le autorizzazioni SSH o sudo di un utente o di un gruppo, AWS OpsWorks Stacks viene eseguito execute_recipes per aggiornare le istanze dello stack e attiva anche un evento Configure. Un'altra origine del comando execute_recipes è l'aggiornamento da parte di AWS OpsWorks Stacks dell'agente dell'istanza.

Soluzione: si tratta di un'operazione normale. Non è necessario eseguire alcuna azione.

Per controllare le operazioni eseguite da un comando execute_recipes, passare alla pagina Deployments (Distribuzioni) e fare clic sul timestamp del comando. Viene visualizzata la pagina dei dettagli del comando, dove sono elencate le ricette chiave eseguite. Ad esempio, la seguente pagina dei dettagli fa riferimento a un comando execute_recipes che ha eseguito ssh_users per aggiornare le autorizzazioni SSH.

Per visualizzare tutti i dettagli, fare clic su show (mostra) nella colonna Log del comando per visualizzare il log di Chef associato. Cerca nel registro. Run List AWS OpsWorks Le ricette per la manutenzione delle pile saranno disponibili. OpsWorks Custom Run List Ad esempio, di seguito è riportato l'elenco di esecuzioni per il comando execute_recipes visualizzato nel precedente screenshot e mostra ogni ricetta associata al comando.

[2014-02-21T17:16:30+00:00] INFO: OpsWorks Custom Run List: ["opsworks_stack_state_sync",
  "ssh_users", "test_suite", "opsworks_cleanup"]