Errori di Amazon Beanstalk in fase di distribuzione

Question

Sono in esecuzione due ambienti e ricevo gli stessi errori su ciascuna distribuzione di un'applicazione. Questi errori si verificano anche durante l'implementazione dell'applicazione di esempio Beanstalk. Gli errori scompaiono quando creiamo un nuovo ambiente e distribuiamo gli stessi file in esso .. per alcuni giorni almeno e poi ritorneranno.

Instance: i-72715b7f Command failed on instance. An unexpected error has occurred ErrorCode: 0000000001. 

L'operazione di aggiornamento dell'ambiente è completa, ma con errori. Per ulteriori informazioni, consultare la documentazione sulla risoluzione dei problemi.

Instance: i-85437188 Module: AWSEBAutoScalingGroup ConfigSet: null Command failed on instance. Return code: 1 Output: Error occurred during build: Command hooks failed . 

Script /opt/elasticbeanstalk/hooks/appdeploy/enact/99_reload_app_server.sh failed with returncode 1 

Script /opt/elasticbeanstalk/hooks/appdeploy/pre/12_update_permissions.sh failed with returncode 1 

L'applicazione (sito WordPress) sembra funzionare bene anche con questi errori nelle manifestazioni, tranne che per i problemi casuali che agiscono come errori di autorizzazione tradizionali (non può caricare immagini o permalink non funziona). Avevamo eseguito la stessa applicazione su beanstalk senza problemi o errori. Questi errori si verificano anche durante l'implementazione dell'applicazione di esempio Beanstalk.

Questo è l'unico frammento dal log degli errori che sembra avere rilevanza.

2014-09-17 19:47:08,825 ERROR Error encountered during build of Hook-EnactAppDeploy: Command hooks failed 
Traceback (most recent call last): 
File "/usr/lib/python2.6/site-packages/cfnbootstrap/construction.py", line 511, in run_config 
CloudFormationCarpenter(config, self._auth_config).build(worklog) 
File "/usr/lib/python2.6/site-packages/cfnbootstrap/construction.py", line 247, in build 
changes = CommandTool().apply(self._config.commands) 
File "/usr/lib/python2.6/site-packages/cfnbootstrap/command_tool.py", line 113, in apply 
raise ToolError(u"Command %s failed" % name) 
ToolError: Command hooks failed 
2014-09-17 19:47:08,826 ERROR Unhandled exception during build: Command hooks failed 
Traceback (most recent call last): 
File "/opt/aws/bin/cfn-init", line 122, in <module> 
worklog.build(detail.metadata, configSets) 
File "/usr/lib/python2.6/site-packages/cfnbootstrap/construction.py", line 117, in build 
Contractor(metadata).build(configSets, self) 
File "/usr/lib/python2.6/site-packages/cfnbootstrap/construction.py", line 502, in build 
self.run_config(config, worklog) 
File "/usr/lib/python2.6/site-packages/cfnbootstrap/construction.py", line 511, in run_config 
CloudFormationCarpenter(config, self._auth_config).build(worklog) 
File "/usr/lib/python2.6/site-packages/cfnbootstrap/construction.py", line 247, in build 
changes = CommandTool().apply(self._config.commands) 
File "/usr/lib/python2.6/site-packages/cfnbootstrap/command_tool.py", line 113, in apply 
raise ToolError(u"Command %s failed" % name) 
ToolError: Command hooks failed 

Cosa c'è di sbagliato qui? Come lo ripariamo?

Answer 1

Il problema si è verificato con un plug-in di WordPress difettoso. Il plugin stava creando una nuova cartella nella directory /tmp ogni volta che un file è stato caricato ma non stava mai eliminando la cartella. Cancellerebbe tutti i file all'interno della cartella, ma mai la cartella. Poiché i client utilizzavano il sito e continuavano a caricare immagini, queste cartelle si sommavano e alla fine riempiva la directory /tmp. La correzione di questo plugin ha risolto il problema e non è stato restituito.

Answer 2

Potrebbe essere troppo tardi, ma la registrazione per i posteri: ogni volta che il file system di root è pieno sull'istanza EB, viene visualizzato questo errore. Ci possono essere altri motivi per questo errore, ma questo è sicuro.

Nel nostro caso si trattava di un'impostazione di registrazione chatty che sfuggiva a un ambiente di sviluppo in una build e veniva implementata, intasando /var/log. Un rapido eb health ha rivelato un avviso del modulo Degraded 100 % of root file system is in use. 0 MB free. Da lì, è stato facile da pulire.