Amazon Beanstalk-Fehler bei der Bereitstellung

Ich verwende zwei Umgebungen und erhalte bei der Bereitstellung einer Anwendung in beiden Umgebungen die gleichen Fehler. Diese Fehler treten auch bei der Bereitstellung der Beanstalk-Beispielanwendung auf. Die Fehler verschwinden, wenn wir eine neue Umgebung erstellen und dieselben Dateien darin bereitstellen. Zumindest für ein paar Tage, und dann kehren sie zurück.

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

Der Vorgang zum Aktualisieren der Umgebung ist abgeschlossen, jedoch mit Fehlern. Weitere Informationen finden Sie in der Dokumentation zur Fehlerbehebung.

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

Die Anwendung (WordPress-Website) scheint auch mit diesen Fehlern in den Ereignissen gut zu funktionieren, mit Ausnahme von zufälligen Problemen, die sich wie herkömmliche Berechtigungsfehler verhalten (Bilder können nicht hochgeladen werden oder Permalinks funktionieren nicht). Wir hatten die gleiche Anwendung auf Beanstalk ohne Probleme oder Fehler ausgeführt. Diese Fehler treten auch bei der Bereitstellung der Beanstalk-Beispielanwendung auf.

Dies ist der einzige Ausschnitt aus dem Fehlerprotokoll, der relevant zu sein scheint.

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

Was ist hier falsch? Wie beheben wir es?

Möglicherweise zu spät, aber für die Nachwelt festgehalten: Immer wenn das Root-Dateisystem auf der EB-Instanz voll ist, wird dieser Fehler angezeigt. Es kann andere Gründe für diesen Fehler geben, aber das ist sicher einer.

In unserem Fall war es eine geschwätzige Protokollierungseinstellung, die der Entwicklungsumgebung in einem Build entkam und bereitgestellt wurde und verstopfte /var/log. Eine schnelle eb health ergab eine Warnung des Formulars Degraded 100 % of root file system is in use. 0 MB free. Von dort aus war es einfach zu reinigen.

Das Problem lag schließlich bei einem fehlerhaften WordPress-Plugin. Das Plugin erstellte einen neuen Ordner in der /tmp jedes Mal, wenn eine Datei hochgeladen wurde, aber der Ordner wurde nie gelöscht. Es würde alle Dateien im Ordner löschen, aber niemals den Ordner. Als die Kunden die Website nutzten und weiterhin Bilder hochluden, summierten sich diese Ordner und füllten schließlich die /tmp Verzeichnis. Durch die Behebung dieses Plugins wurde das Problem behoben und es ist nicht zurückgekehrt.