Da keine Opsworks-Protokolle für die Instanzen erstellt werden, habe ich nicht viele Debug-Informationen, aber ich werde versuchen, so aussagekräftig wie möglich zu sein. Irgendwelche Hinweise oder Ideen werden sehr geschätzt.Instanzen in benutzerdefinierten Layern erhalten immer den Status "start_failed"
Ich habe eine Reihe von benutzerdefinierten Schichten, einige sind Service-Schichten, einige sind mongodb und einer ist ein Kunde memcached Schicht.
Ich habe versucht, eine Instanz in jeder Schicht zu starten, sowohl auf RHEL7- und Amazon Linux-Instanzen (2016.03) (beide neueste Versionen mit dem neuesten opsworks-Agent, Version 3436) als auch auf Koch 11.10.
Wenn die mongodb-Layer Instanzen enthalten, die sich nicht mit den Service-Layern überschneiden, schlagen sie mit dem Status start_failed jedes Mal auf beiden Betriebssystemen zu 100% fehl.
Wenn ich Instanzen erstelle, die sowohl von einer Mongodb-Schicht als auch von einer Serviceschicht verwendet werden, wird die Instanz immer in die Setup-Phase und dann durch den Rest des Prozesses verschoben (abgesehen von meinem Chefcode).
Von EC2 wird die Instanz gestartet und online und alle Statusprüfungen funktionieren. Ich habe in den Instanzsystemprotokollen vom ec2-Dashboard aus nachgeschaut, und es treten keine Fehler auf Systemebene auf. Ich kann die Instanz nicht weiter untersuchen, da die IAM-Benutzer nie geladen werden.
Alle Instanzen erhalten dieselben benutzerdefinierten Rezepte, und dann wird ausgeführt, ob mit der Ausführung für diese Instanz fortgefahren wird, ob sie übersprungen wird, wenn Layer und Bereitstellung nicht übereinstimmen. Daher glaube ich das nicht eine Rezeptdiskrepanz sein.
Meine beste Vermutung ist, dass dies ein Agent-Problem sein könnte, aber das ist nichts mehr als ein Bauchgefühl an diesem Punkt?
Hat jemand sonst ein ähnliches Problem oder kann er mir sogar in die richtige Richtung zeigen?
aktualisieren
habe ich herausgefunden, wie man in der Instanz ssh. Es hatte eine private IP, aber keine öffentliche IP, also musste ich es von einer anderen opsworks-Instanz aus tun. Wie dem auch sei, fand ich den folgenden Fehler in /var/log/aws/opsworks/user-data.log:
/tmp/opsworks-agent-installer/opsworks-agent/lib/bootstrap/utils.rb:111:in `block (2 levels) in execute': Failed to execute "yum --assumeyes update" pid 9536 exit 1: Loaded plugins: amazon-id, rhui-lb, search-disabled-repos (RuntimeError)
Could not contact any CDS load balancers: rhui2-cds01.us-east-1.aws.ce.redhat.com, rhui2-cds02.us-east-1.aws.ce.redhat.com.
Could not contact CDS load balancer rhui2-cds01.us-east-1.aws.ce.redhat.com, trying others.
from /tmp/opsworks-agent-installer/opsworks-agent/lib/bootstrap/utils.rb:99:in `loop'
from /tmp/opsworks-agent-installer/opsworks-agent/lib/bootstrap/utils.rb:99:in `block in execute'
from /tmp/opsworks-agent-installer/opsworks-agent/lib/bootstrap/utils.rb:98:in `chdir'
from /tmp/opsworks-agent-installer/opsworks-agent/lib/bootstrap/utils.rb:98:in `execute'
from /tmp/opsworks-agent-installer/opsworks-agent/lib/bootstrap/utils.rb:14:in `yum'
from /tmp/opsworks-agent-installer/opsworks-agent/lib/bootstrap/instance_agent_installer.rb:57:in `install_system_updates'
from /tmp/opsworks-agent-installer/opsworks-agent/lib/bootstrap/instance_agent_installer.rb:25:in `block in run'
from /tmp/opsworks-agent-installer/opsworks-agent/lib/bootstrap/log.rb:96:in `measure'
from /tmp/opsworks-agent-installer/opsworks-agent/lib/bootstrap/instance_agent_installer.rb:25:in `run'
from /tmp/opsworks-agent-installer/opsworks-agent/lib/bootstrap/instance_agent_installer.rb:10:in `run'
from /tmp/opsworks-agent-installer/opsworks-agent/bin/opsworks-agent-installer.rb:8:in `<main>'
Stellen Sie sicher, dass Sie beim Hinzufügen der Instanz einen privaten Schlüssel zum Hinzufügen auswählen, sodass Sie sich mit dem ec2-Benutzer anstelle der IAM-Benutzer mit Berechtigungen anmelden können. –
Das würde helfen, weiter zu debuggen. Ich möchte nicht root ssh, aber ich kann es vorübergehend einschalten, um weiter zu debuggen –
Frage aktualisiert mit Fehler aus aws-opsworks Agentenprotokolle –