Problembehebung AWS OpsWorks for Chef Automate - AWS OpsWorks
Allgemeine Tipps zur ProblembehebungBehebung bestimmter FehlerWeitere Hilfe und Support

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.

Problembehebung AWS OpsWorks for Chef Automate

Wichtig

AWS OpsWorks for Chef Automate hat am 5. Mai 2024 das Ende seiner Nutzungsdauer erreicht und wurde sowohl für neue als auch für bestehende Kunden deaktiviert. Wir empfehlen bestehenden Kunden, zu Chef SaaS oder einer alternativen Lösung zu migrieren. Wenn du Fragen hast, kannst du dich auf AWS re:POST oder über den AWS Premium-Support an das AWS Support Team wenden.

Dieses Thema enthält einige häufig auftretende AWS OpsWorks for Chef Automate Probleme und Lösungsvorschläge für diese Probleme.

Allgemeine Tipps zur Problembehebung

Sollte es Ihnen nicht möglich sein, einen Chef-Server zu erstellen oder damit zu arbeiten, können Sie Fehlermeldungen oder Protokolle einsehen, die Ihnen helfen, den Fehler zu beheben. Die folgenden Aufgaben beschreiben allgemeine Ausgangspunkte bei der Fehlerbehebung eines Chef-Server Problems. Weitere Informationen zu bestimmten Fehlern und Lösungen finden Sie im Abschnitt Behebung bestimmter Fehler dieses Themas.

  • Verwenden Sie die AWS OpsWorks for Chef Automate Konsole, um Fehlermeldungen anzuzeigen, wenn ein Chef-Server nicht gestartet werden kann. Fehlermeldungen im Zusammenhang mit dem Starten und Ausführen des Servers werden auf der Detailseite des Chef-Servers oben angezeigt. Fehler können von AWS OpsWorks for Chef Automate AWS CloudFormation, oder Amazon EC2-Diensten herrühren, die zum Erstellen eines Chef-Servers verwendet werden. Auf der Detailseite können Sie auch Ereignisse sehen, die auf einem laufenden Server auftreten und Fehlerereignismeldungen beinhalten können.

  • Zur Lösung der EC2-Probleme können Sie eine Verbindung zu Ihrer Server-Instance über SSH herstellen und die Protokolle überprüfen. EC2-Instance-Protokolle werden im /var/log/aws/opsworks-cm-Verzeichnis gespeichert. Diese Protokolle erfassen Befehlsausgaben beim Starten AWS OpsWorks for Chef Automate eines Chef-Servers.

Behebung bestimmter Fehler

Der Server befindet sich in einem Zustand „Verbindung verloren“

Problem: Der Status eines Servers wird als Verbindung unterbrochen angezeigt.

Ursache: Dies tritt am häufigsten auf, wenn eine Entität außerhalb von Änderungen an einem AWS OpsWorks for Chef Automate Server oder dessen unterstützenden Ressourcen AWS OpsWorks vornimmt. AWS OpsWorks kann im Status „Verbindung verloren“ keine Verbindung zu Chef Automate-Servern herstellen, um Wartungsaufgaben wie das Erstellen von Backups, das Anwenden von Betriebssystem-Patches oder das Aktualisieren von Chef Automate zu erledigen. Infolgedessen fehlen auf Ihrem Server möglicherweise wichtige Updates, er ist anfällig für Sicherheitsprobleme oder er funktioniert auf andere Weise nicht wie erwartet.

Lösung: Führen Sie die folgenden Schritte aus, um die Serververbindung wiederherzustellen.

  1. Stellen Sie sicher, dass Ihre Servicerolle über alle erforderlichen Berechtigungen verfügt.

    1. Wählen Sie auf der Seite Einstellungen für Ihren Server unter Netzwerk und Sicherheit den Link für die Servicerolle aus, die der Server verwendet. Dadurch wird die Servicerolle zur Anzeige in der IAM-Konsole geöffnet.

    2. Vergewissern Sie sich, dass auf der Registerkarte Berechtigungen der Eintrag in der Liste der Berechtigungsrichtlinien aufgeführt AWSOpsWorksCMServiceRole ist. Wenn sie nicht aufgeführt ist, fügen Sie die AWSOpsWorksCMServiceRole verwaltete Richtlinie manuell zur Rolle hinzu.

    3. Stellen Sie auf der Registerkarte Vertrauensbeziehungen sicher, dass die Servicerolle über eine Vertrauensrichtlinie verfügt, die darauf vertraut, dass der opsworks-cm.amazonaws.com Dienst Rollen in Ihrem Namen übernimmt. Weitere Informationen zur Verwendung von Vertrauensrichtlinien mit Rollen finden Sie unter Ändern einer Rolle (Konsole) oder im AWS Sicherheits-Blogbeitrag So verwenden Sie Vertrauensrichtlinien mit IAM-Rollen.

  2. Stellen Sie sicher, dass Ihr Instanzprofil über alle erforderlichen Berechtigungen verfügt.

    1. Wählen Sie auf der Seite Einstellungen für Ihren Server unter Netzwerk und Sicherheit den Link für das Instanzprofil aus, das der Server verwendet. Dadurch wird das Instanzprofil zur Anzeige in der IAM-Konsole geöffnet.

    2. Stellen Sie auf der Registerkarte Berechtigungen sicher, dass AmazonEC2RoleforSSM beide in der Liste der Berechtigungsrichtlinien aufgeführt AWSOpsWorksCMInstanceProfileRole sind. Wenn eine oder beide nicht aufgeführt sind, fügen Sie diese verwalteten Richtlinien manuell zur Rolle hinzu.

    3. Vergewissern Sie sich auf der Registerkarte Vertrauensbeziehungen, dass die Servicerolle über eine Vertrauensrichtlinie verfügt, die darauf vertraut, dass der ec2.amazonaws.com Dienst Rollen in Ihrem Namen übernimmt. Weitere Informationen zur Verwendung von Vertrauensrichtlinien mit Rollen finden Sie unter Ändern einer Rolle (Konsole) oder im AWS Sicherheits-Blogbeitrag So verwenden Sie Vertrauensrichtlinien mit IAM-Rollen.

  3. Stellen Sie in der Amazon EC2 EC2-Konsole sicher, dass Sie sich in derselben Region wie die Region des AWS OpsWorks for Chef Automate Servers befinden, und starten Sie dann die EC2-Instance neu, die Ihr Server verwendet.

    1. Wählen Sie die EC2-Instance mit dem Namen Servername aus. aws-opsworks-cm-instance-

    2. Wählen Sie im Menü Instanzstatus die Option Reboot instance aus.

    3. Warten Sie bis zu 15 Minuten, bis Ihr Server neu gestartet und vollständig online ist.

  4. Stellen Sie in der AWS OpsWorks for Chef Automate Konsole auf der Seite mit den Serverdetails sicher, dass der Serverstatus jetzt fehlerfrei ist.

Wenn der Serverstatus nach Durchführung der vorherigen Schritte immer noch Verbindung verloren lautet, versuchen Sie es mit einer der folgenden Methoden.

Verwaltete Knoten im Chef Automate-Dashboard in der Spalte für fehlende Einträge

Problem: Ein verwalteter Knoten erscheint in der Chef Automate-Dashboard-Spalte Missing (Fehlend).

Ursache: Wenn ein Knoten sich länger als 12 Stunden nicht mit dem Chef Automate-Server verbunden hat und chef-client nicht auf dem Knoten ausgeführt werden kann, ändert sich der Status des Knotens zurück in den Status, der vor den 12 Stunden aktiv war, und der Knoten wird in die Spalte Missing (Fehlend) des Chef Automate-Dashboard verschoben.

Lösung: Überprüfen Sie, ob der Knoten online ist. Versuchen Sie, knife node show node_name --run-list auszuführen, um zu sehen, ob chef-client auf dem Knoten ausgeführt werden kann, oder knife node show -l node_name, um alle Informationen über den Knoten anzuzeigen. Der Knoten könnte offline oder vom Netzwerk abgemeldet sein.

Chef-Tresor kann nicht erstellt werden; der Befehl knife vault schlägt fehl

Problem: Sie versuchen, einen Tresor auf Ihrem Chef Automate-Server zu erstellen (z. B. einen Tresor zum Speichern von Anmeldeinformationen für die Domäneneinbindung von Windows-basierten Knoten), indem Sie den Befehl knife vault ausführen. Der Befehl gibt eine ähnliche Fehlermeldung wie die diese zurück.

WARN: Auto inflation of JSON data is deprecated. Please pass in the class to inflate or use #edit_hash (CHEF-1) 
at /opt/chefdk/embedded/lib/ruby/2.3.0/forwardable.rb:189:in `edit_data'.Please see https://docs.chef.io/deprecations_json_auto_inflate.html 
for further details and information on how to correct this problem.
WARNING: pivotal not found in users, trying clients.
ERROR: ChefVault::Exceptions::AdminNotFound: FATAL: Could not find pivotal in users or clients!

Der pivotale Benutzer wird nicht zurückgegeben, wenn Sie knife user list remote ausgeführt haben. Sie können jedoch den pivotalen Benutzer in den Ergebnissen sehen, wenn Sie den Befehl chef-server-ctl user-show lokal auf Ihrem Chef Automate-Server ausführen. Mit anderen Worten: Ihr Befehl knife vault kann den pivotalen Benutzer nicht finden, aber Sie wissen, dass er vorhanden ist.

Ursache: Obwohl der pivotale Benutzer in Chef als Superuser gilt und über vollständige Berechtigungen verfügt, ist er nicht Mitglied irgendeiner Organisation, einschließlich der default-Organisation, die in AWS OpsWorks for Chef Automate verwendet wird. Der Befehl knife user list gibt alle Benutzer zurück, die sich in der aktuellen Organisation in Ihrer Chef-Konfiguration befinden. Der Befehl chef-server-ctl user-show gibt alle Benutzer zurück, unabhängig von der Organisation und einschließlich des pivotalen Benutzers.

Lösung: Um das Problem zu beheben, fügen Sie den pivotalen Benutzer der Standard-Organisation hinzu, indem Sie knife opc ausführen.

Zunächst müssen Sie das Plug-In knife opc installieren.

chef gem install knife-opc

Nach der Installation des Plug-Ins führen Sie den folgenden Befehl aus, um den pivotalen Benutzer der Standard-Organisation hinzuzufügen.

knife opc org user add default pivotal

Sie können überprüfen, ob der pivotale Benutzer Teil der Standard-Organisation ist, indem Sie knife user list erneut ausführen. pivotal sollte in den Ergebnissen aufgeführt sein. Starten Sie anschließend knife vault erneut.

Servererstellung schlägt mit der Nachricht "Die angefragte Konfiguration wird derzeit nicht unterstützt" fehl

Problem: Sie versuchen einen Chef Automate-Server zu erstellen. Die Servererstellung schlägt jedoch mit einer Fehlermeldung wie "Die angefragte Konfiguration wird derzeit nicht unterstützt" fehl. Bitte überprüfen Sie die Dokumentation auf unterstützte Konfigurationen.

Ursache: Ein nicht unterstützter Instance-Typ könnte für den Chef Automate-Server angegeben worden sein. Wenn Sie einen Chef Automate-Server in einer VPC erstellen möchten, die über eine nicht standardmäßige Tenancy verfügt, z. B. eine für dedizierte Instances, müssen alle Instances innerhalb der angegebenen VPC auch einer dedizierten oder Host-Tenancy angehören. Da einige Instance-Typen, z. B. t2, nur mit einem Standard-Abonnement verfügbar sind, könnte der Chef Automate-Server-Instance-Typ möglicherweise nicht durch die angegebene VPC unterstützt werden. Außerdem schlägt die Servererstellung fehl.

Lösung: Wenn Sie eine VPC mit einer Nicht-Standard-Tenancy auswählen, nutzen Sie einen m4-Instance-Typ, der eine dedizierte Tenancy unterstützt.

Der Chef-Server erkennt keine Organisationsbezeichnungen, die dem Chef Automate-Dashboard hinzugefügt wurden.

Problem: Sie haben dem Chef Automate-Dashboard neue Workflow-Organisationsnamen hinzugefügt oder einen anderen CHEF_AUTOMATE_ORGANIZATION-Wert als "default" im unbeaufsichtigten Knoten-Zuordnungsskript angegeben. Die Knotenzuordnung schlägt jedoch fehl. Ihr AWS OpsWorks for Chef Automate -Server erkennt die neuen Organisationsnamen nicht.

Ursache: Workflow-Organisationsnamen und Chef-Server-Organisationsnamen sind nicht identisch. Sie können neue Workflow-Organisationen in dem webbasierten Chef Automate-Dashboard erstellen, aber keine Chef-Server-Organisationsnamen. Sie können das Chef Automate-Dashboard nur nutzen, um vorhandene Chef-Server-Organisationen anzuzeigen. Eine neue Organisation, die Sie in dem Chef Automate-Dashboard erstellen, ist eine Workflow-Organisation und wird von dem Chef-Server nicht erkannt. Sie können keine neuen Organisationsnamen erstellen, indem Sie sie in dem Knoten-Zuordnungsskript angeben. Der Verweis auf einen Organisationsnamen in einem Knoten-Zuordnungsskript bewirkt, dass die Knotenzuordnung fehlschlägt, falls die Organisation nicht zuerst dem Chef-Server hinzugefügt wurde.

Lösung: Um neue Organisationen zu erstellen, die auf dem Chef-Server erkannt werden, verwenden Sie den Befehl knife opc org create oder führen Sie chef-server-ctl org-create aus.

Die Amazon EC2 EC2-Instance des Servers konnte nicht erstellt werden

Problem: Die Servererstellung schlug mit einer ähnlichen Fehlermeldung wie dieser fehl: "Die folgende Ressource(n) konnte(n) nicht erstellt werden: [EC2Instance]. Fehler beim Empfang von 1 Ressource-Signal innerhalb der angegebenen Dauer."

Ursache: Dies ist am wahrscheinlichsten, da die EC2-Instance keinen Zugriff auf das Netzwerk hat.

Lösung: Stellen Sie sicher, dass die Instance über einen ausgehenden Internetzugang verfügt und der AWS Service-Agent Befehle ausgeben kann. Stellen Sie sicher, dass Ihre VPC (eine VPC mit einem einzigen öffentlichen Subnetz) DNS resolution (DNS-Auflösung) aktiviert hat und Ihr Subnetz die Einstellung Auto-assign Public IP (Öffentliche IP-Adresse automatisch zuweisen) aktiviert hat.

Service-Rollen-Fehler verhindert die Servererstellung

Problem: Die Servererstellung schlägt fehl und es wird eine Fehlermeldung angezeigt, die besagt: „Nicht autorisiert, sts auszuführen:AssumeRole.“

Ursache: Dies kann auftreten, wenn die Service-Rolle, die Sie nutzen, nicht über die erforderlichen Berechtigungen zum Erstellen eines neuen Servers verfügt.

Lösung: Öffnen Sie die AWS OpsWorks for Chef Automate Konsole und verwenden Sie die Konsole, um eine neue Servicerolle und eine Instanzprofilrolle zu generieren. Wenn Sie lieber Ihre eigene Servicerolle verwenden möchten, fügen Sie die AWSOpsWorksCMServiceRoleRichtlinie der Rolle hinzu. Vergewissern Sie sich, dass opsworks-cm.amazonaws.com unter den Diensten in den Vertrauensbeziehungen der Rolle aufgeführt ist. Stellen Sie sicher, dass der Servicerolle, die dem Chef-Server zugeordnet ist, die verwaltete Richtlinie angehängt ist. AWSOpsWorksCMServiceRole

Elastisches Limit der IP-Adresse überschritten

Problem: Servererstellung schlägt fehl mit folgender Fehlermeldung: "Die folgende Ressource(n) konnte(n) nicht erstellt werden: [EIP, EC2Instance]. Ressourcenerstellung abgebrochen, die maximale Anzahl an Adressen wurde erreicht."

Ursache: Dieses Problem tritt auf, wenn Ihr Konto die maximale Anzahl an Elastic IP (EIP)-Adressen genutzt hat. Das standardmäßige EIP-Adressenlimit ist fünf.

Lösung: Sie können entweder bestehende EIP-Adressen freigeben oder solche löschen, die Ihr Konto nicht aktiv verwendet, oder Sie können sich an den AWS Kundensupport wenden, um das Limit an EIP-Adressen zu erhöhen, das mit Ihrem Konto verknüpft ist.

Anmeldung beim Chef Automate-Dashboard nicht möglich

Problem: Das Chef Automate-Dashboard zeigt eine ähnliche Fehlermeldung wie diese an: "Ursprungsübergreifende Anfrage blockiert: Die gleiche Ursprungsrichtlinie verbietet das Lesen der Remote-Ressource auf https://myserver-name.region.opsworks-cm.io/api/v0/e/default/verify-token. (Grund: CORS-Header "Access-Control-Allow-Origin" fehlt)". Der Fehler kann folgendermaßen aussehen: "Die eingegebene Benutzer-ID/Passwort-Kombination ist falsch."

Ursache: Das Chef Automate-Dashboard legt ausdrücklich den FQDN fest und akzeptiert keine relativen URLs. Derzeit ist es nicht möglich, sich über die Chef-Server-IP-Adresse anzumelden. Sie können sich nur anmelden, indem Sie den DNS-Namen des Servers nutzen.

Lösung: Melden Sie sich beim Chef Automate-Dashboard nur an, indem Sie den DNS-Namenseintrag des Servers nutzen und nicht seine IP-Adresse. Sie können auch versuchen, die Chef Automate-Dashboard-Anmeldeinformationen zurückzusetzen, indem Sie einen AWS CLI -Befehl ausführen, der in Zurücksetzen der Anmeldeinformationen für das Chef Automate-Dashboard beschrieben wird.

Unbeaufsichtigte Knotenzuordnung fehlgeschlagen

Problem: Die unbeaufsichtigte oder automatische Zuordnung neuer Amazon EC2 EC2-Knoten schlägt fehl. Knoten, die dem Chef-Server hinzugefügt werden sollten, erscheinen nicht im Chef Automate-Dashboard und sind nicht in den Ergebnisse der Befehle knife client show oder knife node show aufgeführt.

Ursache: Dies kann auftreten, wenn Sie nicht über eine IAM-Rolle verfügen, die als Instance-Profil eingerichtet wurde und die gestattet, dass opsworks-cm-API-Aufrufe mit neuen EC2-Instances kommunizieren können.

Lösung: Fügen Sie Ihrem EC2-Instance-Profil eine Richtlinie an, die es erlaubt, dass die API-Aufrufe AssociateNode und DescribeNodeAssociationStatus mit EC2 zusammenarbeiten können, wie in Automatisches Hinzufügen von Knoten AWS OpsWorks for Chef Automate beschrieben.

Die Systemwartung schlägt fehl

AWS OpsWorks CM führt wöchentliche Systemwartungen durch, um sicherzustellen, dass die neuesten Nebenversionen von Chef Server und Chef Automate Server, einschließlich Sicherheitsupdates, immer auf einem AWS OpsWorks for Chef Automate-Server laufen. Wenn die Systemwartung aus irgendeinem Grund fehlschlägt, werden Sie über den Fehler AWS OpsWorks CM informiert. Weitere Hinweise zur Systemwartung finden Sie unterSystemwartung in AWS OpsWorks for Chef Automate.

In diesem Abschnitt werden mögliche Fehlerursachen beschrieben und Lösungen vorgeschlagen.

Ein Fehler im Servicerollen- oder Instanzprofil verhindert die Systemwartung

Problem: Die Systemwartung schlägt fehl und es wird eine Fehlermeldung angezeigt, die besagt, dass Sie nicht berechtigt sind, sts auszuführen:AssumeRole, oder es wird eine ähnliche Fehlermeldung zu den Berechtigungen angezeigt.

Ursache: Dieses Problem kann auftreten, wenn entweder die von Ihnen verwendete Servicerolle oder das Instanzprofil nicht über ausreichende Berechtigungen für die Durchführung der Systemwartung auf dem Server verfügt.

Lösung: Stellen Sie sicher, dass Ihre Servicerolle und Ihr Instanzprofil über alle erforderlichen Berechtigungen verfügen.

  1. Stellen Sie sicher, dass Ihre Servicerolle über alle erforderlichen Berechtigungen verfügt.

    1. Wählen Sie auf der Seite Einstellungen für Ihren Server unter Netzwerk und Sicherheit den Link für die Servicerolle aus, die der Server verwendet. Dadurch wird die Servicerolle zur Anzeige in der IAM-Konsole geöffnet.

    2. Vergewissern Sie sich auf der Registerkarte „Berechtigungen“, dass sie der Servicerolle zugeordnet AWSOpsWorksCMServiceRole ist. Wenn sie nicht aufgeführt AWSOpsWorksCMServiceRole ist, fügen Sie diese Richtlinie der Rolle hinzu.

    3. Vergewissern Sie sich, dass opsworks-cm.amazonaws.com unter den Diensten in den Vertrauensbeziehungen der Rolle aufgeführt ist. Weitere Informationen zur Verwendung von Vertrauensrichtlinien mit Rollen finden Sie unter Rolle ändern (Konsole) oder im AWS Sicherheits-Blogbeitrag So verwenden Sie Vertrauensrichtlinien mit IAM-Rollen.

  2. Stellen Sie sicher, dass Ihr Instanzprofil über alle erforderlichen Berechtigungen verfügt.

    1. Wählen Sie auf der Seite Einstellungen für Ihren Server unter Netzwerk und Sicherheit den Link für das Instanzprofil aus, das der Server verwendet. Dadurch wird das Instanzprofil zur Anzeige in der IAM-Konsole geöffnet.

    2. Stellen Sie auf der Registerkarte Berechtigungen sicher, dass AmazonEC2RoleforSSM beide in der Liste der Berechtigungsrichtlinien aufgeführt AWSOpsWorksCMInstanceProfileRole sind. Wenn eine oder beide nicht aufgeführt sind, fügen Sie diese verwalteten Richtlinien manuell zur Rolle hinzu.

    3. Vergewissern Sie sich auf der Registerkarte Vertrauensbeziehungen, dass die Servicerolle über eine Vertrauensrichtlinie verfügt, die darauf vertraut, dass der ec2.amazonaws.com Dienst Rollen in Ihrem Namen übernimmt. Weitere Informationen zur Verwendung von Vertrauensrichtlinien mit Rollen finden Sie unter Ändern einer Rolle (Konsole) oder im AWS Sicherheits-Blogbeitrag So verwenden Sie Vertrauensrichtlinien mit IAM-Rollen.

Weitere Hilfe und Support

Wenn Ihr spezifisches Problem in diesem Thema nicht beschrieben wird oder Sie die Vorschläge in diesem Thema ausprobiert und weiterhin Probleme haben, besuchen Sie die AWS OpsWorks -Foren.

Sie können auch das AWS Support-Center besuchen. Das AWS Support Center ist die zentrale Anlaufstelle für die Erstellung und Verwaltung von AWS Support-Fällen. Das AWS Support Center enthält auch Links zu anderen hilfreichen Ressourcen wie Foren, technischen FAQs, Servicestatus und AWS Trusted Advisor.