Chef-Protokolle - AWS OpsWorks

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Chef-Protokolle

Wichtig

Der AWS OpsWorks Stacks Dienst hat am 26. Mai 2024 das Ende seiner Lebensdauer erreicht und wurde sowohl für neue als auch für bestehende Kunden deaktiviert. Wir empfehlen Kunden dringend, ihre Workloads so bald wie möglich auf andere Lösungen zu migrieren. Wenn Sie Fragen zur Migration haben, wenden Sie sich an das AWS Support Team auf AWS re:POST oder über den AWS Premium-Support.

Chef-Logs sind eine Ihrer wichtigsten Ressourcen zur Fehlerbehebung, insbesondere beim Debuggen von Rezepten. AWS OpsWorks Stacks erfasst das Chef-Protokoll für jeden Befehl und speichert die Protokolle für die 30 neuesten Befehle einer Instanz. Da sich die Ausführung im Debug-Modus befindet, enthält das Protokoll eine detaillierte Beschreibung der Chef-Ausführung, einschließlich des Textes, der nach stdout und stderror gesendet wird. Wenn ein Rezept fehlschlägt, enthält das Protokoll den Chef-Stack-Trace.

AWS OpsWorks Stacks bietet Ihnen mehrere Möglichkeiten, Chef-Logs einzusehen. Nachdem Sie über die Protokollinformationen verfügen, können Sie sie verwenden, um fehlgeschlagene Rezepte zu debuggen.

Anmerkung

Sie können sich auch ein bestimmtes Protokollfragment anzeigen lassen, indem Sie SSH verwenden, um eine Verbindung mit der Instance herzustellen und den Agenten-CLI-Befehl show_log auszuführen. Weitere Informationen finden Sie unter Anzeigen von Chef-Protokollen.

Anzeige eines Chef-Protokolls mit der Konsole

Die einfachste Möglichkeit, ein Chef-Protokoll anzuzeigen, ist auf die Instance-Detailseite zu gehen. Der Abschnitt Logs (Protokolle) enthält einen Eintrag für jedes Ereignis und den Befehl Execute Recipes (Rezepte ausführen). Das folgende Beispiel zeigt den Abschnitt Logs (Protokolle) einer Instance mit den Befehlen configure (Konfigurieren) und setup (Einrichten), die dem Konfigurieren und Einrichten von Lebenszyklusereignissen entsprechen.

Logs section showing configure and setup commands with timestamps and durations.

Klicken Sie auf den entsprechenden Befehl show (Anzeigen) in der Spalte Log (Protokoll), um das entsprechende Chef-Protokoll anzuzeigen. Wenn ein Fehler auftritt, öffnet AWS OpsWorks Stacks automatisch das Protokoll mit dem Fehler, das sich normalerweise am Ende der Datei befindet.

Anzeige eines Chef-Protokolls mit CLI oder API

Sie können den AWS OpsWorks describe-commandsStacks-CLI-Befehl oder die DescribeCommandsAPI-Aktion verwenden, um die Protokolle anzuzeigen, die in einem Amazon S3 S3-Bucket gespeichert sind. Das folgende Beispiel zeigt, wie Sie mit der Befehlszeilenschnittstelle (CLI) jeden der aktuellen Protokolldateisätze für eine bestimmte Instance anzeigen. Das Verfahren für die Nutzung von DescribeCommands ist im Wesentlichen ähnlich.

Um die AWS OpsWorks Stacks zum Anzeigen der Chef-Logs einer Instance zu verwenden
  1. Öffnen Sie die Detailseite der Instanz und kopieren Sie ihren OpsWorksID-Wert.

  2. Verwenden Sie den ID-Wert, um den CLI-Befehl describe-commands wie folgt auszuführen:

    aws opsworks describe-commands --instance-id 67bf0da2-29ed-4217-990c-d895d51812b9

    Der Befehl gibt für jeden Befehl, den AWS OpsWorks Stacks auf der Instanz ausgeführt hat, ein JSON-Objekt mit einem eingebetteten Objekt zurück, wobei der neueste Befehl an erster Stelle steht. Der Parameter Type enthält den Befehlstyp für jedes eingebettete Objekt, in diesem Beispiel einen Befehl configure und einen Befehl setup.

    { "Commands": [ { "Status": "successful", "CompletedAt": "2013-10-25T19:38:36+00:00", "InstanceId": "67bf0da2-29ed-4217-990c-d895d51812b9", "AcknowledgedAt": "2013-10-25T19:38:24+00:00", "LogUrl": "https://s3.amazonaws.com/prod_stage-log/logs/b6c402df-5c23-45b2-a707-ad20b9c5ae40?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE &Expires=1382731518&Signature=YkqS5IZN2P4wixjHwoC3aCMbn5s%3D&response-cache-control=private&response-content-encoding=gzip&response-content- type=text%2Fplain", "Type": "configure", "CommandId": "b6c402df-5c23-45b2-a707-ad20b9c5ae40", "CreatedAt": "2013-10-25T19:38:11+00:00", "ExitCode": 0 }, { "Status": "successful", "CompletedAt": "2013-10-25T19:31:08+00:00", "InstanceId": "67bf0da2-29ed-4217-990c-d895d51812b9", "AcknowledgedAt": "2013-10-25T19:29:01+00:00", "LogUrl": "https://s3.amazonaws.com/prod_stage-log/logs/2a90e862-f974-42a6-9342-9a4f03468358?AWSAccessKeyId=AKIAIOSFODNN7EXAMPLE &Expires=1382731518&Signature=cxKYHO8mCCd4MvOyFb6ywebeQtA%3D&response-cache-control=private&response-content-encoding=gzip&response-content- type=text%2Fplain", "Type": "setup", "CommandId": "2a90e862-f974-42a6-9342-9a4f03468358", "CreatedAt": "2013-10-25T19:26:01+00:00", "ExitCode": 0 } ] }
  3. Kopieren Sie den Wert LogUrl in den Browser, um das Protokoll anzuzeigen.

Wenn die Instance mehr als einige Befehle enthält, können Sie describe-commands Parameter hinzufügen, um zu filtern, welche Befehle in dem Antwortobjekt enthalten sind. Weitere Informationen finden Sie unter describe-commands.

Anzeige eines Chef-Protokolls auf einer Instance

Anmerkung

Die Themen in diesem Abschnitt gelten für Chef 12. Weitere Informationen zu dem Speicherort von Chef-Protokollen für Chef 11.10 und niedriger finden Sie unter Troubleshooting Chef 11.10 and Earlier Versions for Linux (Fehlerbehebung bei Chef 11.10 und früheren Versionen für Linux).

Linux-Instances

AWS OpsWorks Stacks speichert die Chef-Logs jeder Instanz in ihrem /var/chef/runs Verzeichnis. (Dieses Verzeichnis umfasst für Linux-Instances auch die zugehörigen Datenbehälter, die als JSON-formatierte Dateien gespeichert werden.) Sie benötigen Sudo-Berechtigungen, um auf dieses Verzeichnis zuzugreifen. Das Protokoll für jede Ausführung befindet sich in einer Datei mit dem Namen chef.log innerhalb des Unterverzeichnisses, das einzeln ausgeführt wird.

AWS OpsWorks Stacks speichert seine internen Protokolle im Ordner der /var/log/aws/opsworks Instanz. Die Informationen sind in der Regel nicht sehr hilfreich für Fehlerbehebungszwecke. Diese Protokolle sind jedoch für den AWS OpsWorks Stacks-Support nützlich, und Sie werden möglicherweise aufgefordert, sie bereitzustellen, wenn Sie auf ein Problem mit dem Dienst stoßen. Die Linux-Protokolle können manchmal auch nützliche Daten zur Fehlerbehebung liefern.

Windows-Instances

Agenten-Protokolle

Auf Windows-Instanzen werden OpsWorks Protokolle in einem ProgramData Pfad wie dem folgenden gespeichert. Die Anzahl umfasst einen Zeitstempel.

C:\ProgramData\OpsWorksAgent\var\logs\number
Anmerkung

Standardmäßig handelt es sich bei ProgramData um einen versteckten Ordner. Navigieren Sie zu Folder Options (Ordneroptionen), um ihn wieder einzublenden. Klicken Sie unter View (Anzeigen) auf die Option zum Anzeigen der ausgeblendeten Dateien.

Das folgende Beispiel zeigt Agenten-Protokolle auf einer Windows-Instance.

Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 5/24/2015 11:59 PM 127277 command.20150524.txt -a--- 5/25/2015 11:59 PM 546772 command.20150525.txt -a--- 5/26/2015 11:59 PM 551514 command.20150526.txt -a--- 5/27/2015 9:43 PM 495181 command.20150527.txt -a--- 5/24/2015 11:59 PM 24353 keepalive.20150524.txt -a--- 5/25/2015 11:59 PM 106232 keepalive.20150525.txt -a--- 5/26/2015 11:59 PM 106208 keepalive.20150526.txt -a--- 5/27/2015 8:54 PM 92593 keepalive.20150527.txt -a--- 5/24/2015 7:19 PM 3891 service.20150524.txt -a--- 5/27/2015 8:54 PM 1493 service.20150527.txt -a--- 5/24/2015 11:59 PM 112549 wire.20150524.txt -a--- 5/25/2015 11:59 PM 501501 wire.20150525.txt -a--- 5/26/2015 11:59 PM 499640 wire.20150526.txt -a--- 5/27/2015 8:54 PM 436870 wire.20150527.txt
Chef-Protokolle

OpsWorks-Protokolle werden auf Windows-Instances unter dem Pfad ProgramData wie folgt gespeichert. Die Anzahl umfasst einen Zeitstempel.

C:\ProgramData\OpsWorksAgent\var\commands\number
Anmerkung

Dieses Verzeichnis enthält nur die Ausgabe des ersten (OpsWorks eigenen) Chef-Laufs.

Das folgende Beispiel zeigt OpsWorks eigene Chef-Protokolle auf einer Windows-Instanz.

Mode LastWriteTime Name ---- ------------- ---- d---- 5/24/2015 7:23 PM configure-7ecb5f47-7626-439b-877f-5e7cb40ab8be d---- 5/26/2015 8:30 PM configure-8e74223b-d15d-4372-aeea-a87b428ffc2b d---- 5/24/2015 6:34 PM configure-c3980a1c-3d08-46eb-9bae-63514cee194b d---- 5/26/2015 8:32 PM grant_remote_access-70dbf834-1bfa-4fce-b195-e50e85402f4c d---- 5/26/2015 10:30 PM revoke_remote_access-1111fce9-843a-4b27-b93f-ecc7c5e9e05b d---- 5/24/2015 7:21 PM setup-754ec063-8b60-4cd4-b6d7-0e89d7b7aa78 d---- 5/26/2015 8:27 PM setup-af5bed36-5afd-4115-af35-5766f88bc039 d---- 5/24/2015 6:32 PM setup-d8abeffa-24d4-414b-bfb1-4ad07319f358 d---- 5/24/2015 7:13 PM shutdown-c7130435-9b5c-4a95-be17-6b988fc6cf9a d---- 5/26/2015 8:25 PM sync_remote_users-64c79bdc-1f6f-4517-865b-23d2def4180c d---- 5/26/2015 8:48 PM update_custom_cookbooks-2cc59a94-315b-414d-85eb-2bdea6d76c6a
Benutzer-Chef-Protokolle

Die Protokolle für Ihre Chef-Ausführungen finden Sie in den Dateien namens logfile.txt in einem Ordner, der nach dem nummerierten Chef-Befehl, wie im folgenden Diagramm, benannt wird.

C:/chef └── runs └── command-12345 ├── attribs.json ├── client.rb └── logfile.txt

Interpretieren eines Chef-Protokolls

Der Anfang des Protokolls besteht hauptsächlich aus einer internen Chef-Protokollierung.

# Logfile created on Thu Oct 17 17:25:12 +0000 2013 by logger.rb/1.2.6 [2013-10-17T17:25:12+00:00] INFO: *** Chef 11.4.4 *** [2013-10-17T17:25:13+00:00] DEBUG: Building node object for php-app1.localdomain [2013-10-17T17:25:13+00:00] DEBUG: Extracting run list from JSON attributes provided on command line [2013-10-17T17:25:13+00:00] INFO: Setting the run_list to ["opsworks_custom_cookbooks::load", "opsworks_custom_cookbooks::execute"] from JSON [2013-10-17T17:25:13+00:00] DEBUG: Applying attributes from json file [2013-10-17T17:25:13+00:00] DEBUG: Platform is amazon version 2013.03 [2013-10-17T17:25:13+00:00] INFO: Run List is [recipe[opsworks_custom_cookbooks::load], recipe[opsworks_custom_cookbooks::execute]] [2013-10-17T17:25:13+00:00] INFO: Run List expands to [opsworks_custom_cookbooks::load, opsworks_custom_cookbooks::execute] [2013-10-17T17:25:13+00:00] INFO: Starting Chef Run for php-app1.localdomain [2013-10-17T17:25:13+00:00] INFO: Running start handlers [2013-10-17T17:25:13+00:00] INFO: Start handlers complete. [2013-10-17T17:25:13+00:00] DEBUG: No chefignore file found at /opt/aws/opsworks/releases/20131015111601_209/cookbooks/chefignore no files will be ignored [2013-10-17T17:25:13+00:00] DEBUG: Cookbooks to compile: ["gem_support", "packages", "opsworks_bundler", "opsworks_rubygems", "ruby", "ruby_enterprise", "dependencies", "opsworks_commons", "scm_helper", :opsworks_custom_cookbooks] [2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook gem_support's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/gem_support/libraries/current_gem_version.rb [2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook packages's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/packages/libraries/packages.rb [2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook dependencies's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/dependencies/libraries/current_gem_version.rb [2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook opsworks_commons's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/opsworks_commons/libraries/activesupport_blank.rb [2013-10-17T17:25:13+00:00] DEBUG: Loading cookbook opsworks_commons's library file: /opt/aws/opsworks/releases/20131015111601_209/cookbooks/opsworks_commons/libraries/monkey_patch_chefgem_resource.rb ...

Dieser Teil der Datei ist vor allem für Chef-Experten nützlich. Beachten Sie, dass die Ausführungsliste nur zwei Rezepte enthält, obwohl die meisten Befehle viele mehr umfassen. Diese beiden Rezepte bewältigen die Aufgabe, das Laden und die Ausführung aller anderen integrierten und benutzerdefinierten Rezepte durchzuführen.

Der interessanteste Teil der Datei befindet sich hauptsächlich am Ende. Wenn eine Ausführung erfolgreich endet, sollten Sie etwas wie das Folgende sehen:

... [Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: STDERR: [Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: ---- End output of /sbin/service mysqld restart ---- [Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: Ran /sbin/service mysqld restart returned 0 [Tue, 11 Jun 2013 16:00:50 +0000] INFO: service[mysql]: restarted successfully [Tue, 11 Jun 2013 16:00:50 +0000] INFO: Chef Run complete in 84.07096 seconds [Tue, 11 Jun 2013 16:00:50 +0000] INFO: cleaning the checksum cache [Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: removing unused checksum cache file /var/chef/cache/checksums/chef-file--tmp-chef-rendered-template20130611-4899-8wef7e-0 [Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: removing unused checksum cache file /var/chef/cache/checksums/chef-file--tmp-chef-rendered-template20130611-4899-1xpwyb6-0 [Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: removing unused checksum cache file /var/chef/cache/checksums/chef-file--etc-monit-conf [Tue, 11 Jun 2013 16:00:50 +0000] INFO: Running report handlers [Tue, 11 Jun 2013 16:00:50 +0000] INFO: Report handlers complete [Tue, 11 Jun 2013 16:00:50 +0000] DEBUG: Exiting
Anmerkung

Sie können die Agenten-CLI verwenden, um das Protokollfragment während oder nach der Ausführung anzuzeigen. Weitere Informationen finden Sie unter Anzeigen von Chef-Protokollen.

Wenn ein Rezept fehlschlägt, sollten Sie nach einer Ausgabe auf ERROR-Ebene suchen, die eine Ausnahme gefolgt von einem Chef-Stack-Trace enthalten wird, wie z. B. die folgende:

... Please report any problems with the /usr/scripts/mysqlbug script! [ OK ] MySQL Daemon failed to start. Starting mysqld: [FAILED]STDERR: 130611 15:07:55 [Warning] The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-query-log'/'--slow-query-log-file' instead. 130611 15:07:56 [Warning] The syntax '--log-slow-queries' is deprecated and will be removed in a future release. Please use '--slow-query-log'/'--slow-query-log-file' instead. ---- End output of /sbin/service mysqld start ---- /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/mixin/command.rb:184:in `handle_command_failures' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/mixin/command.rb:131:in `run_command' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/provider/service/init.rb:37:in `start_service' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/provider/service.rb:60:in `action_start' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource.rb:406:in `send' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource.rb:406:in `run_action' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:53:in `run_action' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:89:in `converge' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:89:in `each' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:89:in `converge' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection.rb:94:in `execute_each_resource' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in `call' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:116:in `call_iterator_block' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:85:in `step' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:104:in `iterate' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection/stepable_iterator.rb:55:in `each_with_index' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/resource_collection.rb:92:in `execute_each_resource' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/runner.rb:84:in `converge' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/client.rb:268:in `converge' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/client.rb:158:in `run' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application/solo.rb:190:in `run_application' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application/solo.rb:181:in `loop' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application/solo.rb:181:in `run_application' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/../lib/chef/application.rb:62:in `run' /opt/aws/opsworks/releases/20130605160141_122/vendor/bundle/ruby/1.8/gems/chef-0.9.15.5/bin/chef-solo:25 /opt/aws/opsworks/current/bin/chef-solo:16:in `load' /opt/aws/opsworks/current/bin/chef-solo:16

Das Dateiende ist der Chef-Stack-Trace. Sie sollten auch die Ausgabe direkt vor der Ausnahme überprüfen, da sie oft einen Systemfehler, wie z. B. package not available enthält, der auch nützlich sein kann, die Ursache des Fehlers zu ermitteln. In diesem Fall konnte MySQL-Daemon nicht gestartet werden.

Häufige Chef-Protokollfehler

Es folgen einige gängige Chef-Protokollfehler und wie diese behoben werden.

Das Protokoll konnte nicht gefunden werden

Zu Beginn eines Chef-Laufs erhalten Instances eine vorsignierte Amazon S3 S3-URL, mit der Sie das Protokoll auf einer Webseite anzeigen können, wenn der Chef-Lauf abgeschlossen ist. Da diese URL nach zwei Stunden abläuft, wird kein Protokoll auf die Amazon S3 S3-Website hochgeladen, wenn ein Chef-Lauf länger als zwei Stunden dauert, auch wenn während des Chef-Laufs keine Probleme aufgetreten sind. Der Befehl zum Erstellen eines Protokolls wird erfolgreich ausgeführt, aber das Protokoll kann nur auf der Instance angezeigt werden und nicht auf der vorsignierten URL.

Das Protokoll endet abrupt

Wenn ein Chef-Protokoll abrupt endet, ohne entweder einen Erfolg anzugeben oder eine Fehlerinformation anzuzeigen, ist wahrscheinlich ein niedriger Speicherstatus aufgetreten, der Chef daran hindert, das Protokoll abzuschließen. Die einfachste Lösung ist der erneute Versuch mit einer größeren Instance.

Fehlendes Rezeptbuch oder Rezept

Wenn die Chef-Ausführung ein Rezeptbuch oder ein Rezept antrifft, das nicht im Rezeptbuchzwischenspeicher vorhanden ist, sehen Sie Folgendes:

DEBUG: Loading Recipe mycookbook::myrecipe via include_recipe ERROR: Caught exception during execution of custom recipe: mycookbook::myrecipe: Cannot find a cookbook named mycookbook; did you forget to add metadata to a cookbook?

Dieser Eintrag gibt an, dass sich das Rezeptbuch mycookbook nicht im Rezeptbuchzwischenspeicher befindet. Mit Chef 11.4 kann dieser Fehler auch auftreten, wenn Sie Abhängigkeiten in metadata.rb nicht korrekt angeben.

AWS OpsWorks Stacks führt Rezepte aus dem Kochbuch-Cache der Instanz aus. Es lädt Rezeptbücher von Ihrem Repository auf diesen Zwischenspeicher herunter, wenn die Instance gestartet wird. AWS OpsWorks Stacks aktualisiert den Cache einer Online-Instanz jedoch nicht automatisch, wenn Sie die Kochbücher in Ihrem Repository nachträglich ändern. Wenn Sie seit dem Start der Instance Ihre Rezeptbücher geändert oder neue Rezeptbücher hinzugefügt haben, führen Sie die folgenden Schritte aus:

  1. Stellen Sie sicher, dass Sie Ihre Änderungen an das Repository übergeben haben.

  2. Führen Sie den Stack-Befehl Update Cookbooks (Rezeptbücher aktualisieren) aus, um den Rezeptbuchzwischenspeicher mit der jeweils aktuellen Version aus dem Repository zu aktualisieren.

Lokaler Befehlsausfall

Wenn bei einer Chef-Ressource execute die Ausführung des angegebenen Befehls fehlschlägt, sehen Sie Folgendes:

DEBUG: ---- End output of ./configure --with-config-file-path=/ returned 2 ERROR: execute[PHP: ./configure] (/root/opsworks-agent/site-cookbooks/php-fpm/recipes/install.rb line 48) had an error: ./configure --with-config-file-path=/

Navigieren Sie in dem Protokoll nach oben. Sie sollten die Ausgaben stderr und stdout des Befehls sehen, mit denen Sie ermitteln können, warum der Befehl fehlgeschlagen ist.

Paketausfall

Wenn eine Paketinstallation fehlschlägt, sehen Sie Folgendes:

ERROR: package[zend-server-ce-php-5.3] (/root/opsworks-agent/site-cookbooks/zend_server/recipes/install.rb line 20) had an error: apt-get -q -y --force-yes install zend-server-ce-php-5.3=5.0.4+b17 returned 100, expected 0

Navigieren Sie in dem Protokoll nach oben. Sie sollten eine STDOUT- und STDERROR-Ausgabe des Befehls sehen, mit denen Sie ermitteln können, warum die Paketinstallation fehlgeschlagen ist.