Einführung
CoreOS stellt eine Reihe interessanter Technologien vor, die das Erstellen verteilter Systeme vereinfachen. Diese Tools können jedoch für neue Benutzer ungewohnt sein und ihre eigenen Besonderheiten aufweisen. Eines der Hauptprobleme ist, dass viele Abstraktionsebenen am Werk sind und es schwierig sein kann, festzustellen, wo ein Problem auftritt.
In diesem Handbuch werden einige grundlegende Fehlerbehebungsverfahren für die Arbeit mit CoreOS-Hosts, den von ihnen ausgeführten Docker-Containern und den Dienstverwaltungstools erläutert, mit denen einige der unterschiedlichen Komponenten zusammengeführt werden.
Debuggen Ihrer Cloud-Config-Datei
Eines der häufigsten Probleme, auf das neue und erfahrene CoreOS-Benutzer stoßen, wenn ein Cluster nicht ordnungsgemäß gestartet wird, ist eine ungültige Cloud-Konfigurationsdatei.
Für CoreOS muss beim Erstellen eine Cloud-Konfigurationsdatei an Ihren Server übergeben werden. Es verwendet die in dieser Datei enthaltenen Informationen, um sich selbst zu booten und einen vorhandenen Cluster zu initiieren oder diesem beizutreten. Es startet auch wichtige Dienste und kann Systemgrundlagen wie Benutzer und Gruppen konfigurieren.
Einige Dinge, die Sie mit Ihrer Cloud-Konfigurationsdatei überprüfen sollten:
-
* Beginnt es mit "# cloud-config"? *: Jede übergebene Cloud-Config-Datei muss mit "# cloud-config" in der ersten Zeile beginnen. Während dies in YAML normalerweise ein ignorierter Kommentar ist, wird in diesem Fall diese Zeile verwendet, um dem Cloud-Init-System zu signalisieren, dass dies Konfigurationsdaten enthält.
-
* Enthält Ihre Datei gültiges YAML? *: Cloud-Konfigurationsdateien sind in YAML geschrieben, einem Daten-Serialisierungsformat mit Schwerpunkt auf Lesbarkeit. Wenn Sie Probleme haben, fügen Sie Ihre Cloud-Konfiguration in einen YAML validator ein. Ihre Datei sollte keine Fehler enthalten. CoreOS bietet ein hilfreiches Tool, mit dem Sie die Syntax Ihrer Cloud-Konfigurationsdatei überprüfen können: Cloud-Config Validator.
-
* Verwenden Sie ein neues Erkennungstoken? *: Die Erkennungsadresse protokolliert die Daten Ihres Computers, auch wenn der gesamte Cluster inaktiv ist. Die Discovery-Registrierung schlägt fehl, wenn Sie mit einem alten Token starten, insbesondere, wenn Sie bereits zuvor dieselbe IP-Adresse registriert hatten. Verwenden Sie bei jedem Start eines Clusters ein neues Erkennungstoken, um dieses Problem zu vermeiden.
-
* Starten Sie die Flotten- und etcd-Dienste? *: Zwei Dienste, die gestartet werden müssen, damit Ihr Cluster ordnungsgemäß funktioniert, sind "+ fleet " und " etcd +". Sie sollten unseren Leitfaden unter getting a CoreOS cluster running on DigitalOcean für eine grundlegende Cloud-Konfigurationsdatei, die diese Mindestanforderungen erfüllt.
Sie können die Cloud-Konfigurationsdatei nur übergeben, wenn der Computer erstellt wurde. Wenn Sie also einen Fehler gemacht haben, zerstören Sie die Serverinstanz und starten Sie sie erneut (in den meisten Fällen mit einem neuen Token).
Sobald Sie sicher sind, dass die Cloud-Konfigurationsdatei selbst korrekt ist, müssen Sie sich beim Host anmelden, um sicherzustellen, dass die Datei korrekt verarbeitet wurde.
Dies sollte in den meisten Fällen einfach sein, da Sie bei DigitalOcean während der Erstellung SSH-Schlüssel zum Server hinzufügen müssen. Dies bedeutet, dass Sie in der Regel problemlos eine SSH-Verbindung zum Server herstellen können, um Fehler zu beheben.
Anmelden über die DigitalOcean-Systemsteuerung
Es kann jedoch vorkommen, dass Ihre Cloud-Konfiguration die Netzwerkverfügbarkeit Ihres Servers nach dem Start tatsächlich beeinträchtigt hat. In diesem Fall müssen Sie sich über das DigitalOcean-Bedienfeld anmelden. Dies stellt ein Problem dar, da aus Sicherheitsgründen standardmäßig keine Kennwörter für das CoreOS-Image festgelegt sind.
Um dies zu umgehen, müssen Sie den Server mit einer neuen Cloud-Konfigurationsdatei neu erstellen, die einen Kennworteintrag für den Benutzer "+ core +" enthält. Aufgrund des Erholungsbedarfs ist dies wahrscheinlich nur dann sinnvoll, wenn Sie dieses Problem ständig sehen und weitere Informationen erhalten möchten. Möglicherweise möchten Sie die Kennwortinformationen in der Regel zu allen Cloud-Konfigurationsdateien hinzufügen, um Fehler zu beheben. Sie können das Kennwort manuell deaktivieren, nachdem Sie Ihre Verbindung überprüft haben.
Das Passwort muss in Form eines Hashs vorliegen. Sie können diese auf verschiedene Arten generieren, je nachdem, welche Software Sie zur Verfügung haben. Jedes der folgenden Verfahren funktioniert, verwenden Sie also die für Sie am besten geeignete Option:
mkpasswd --method=SHA-512 --rounds=4096
openssl passwd -1
python -c "import crypt, getpass, pwd; print crypt.crypt('password', '\$6\$SALT\$')"
perl -e 'print crypt("password","\$6\$SALT\$") . "\n"'Sobald Sie einen Hash haben, können Sie Ihrer Cloud-Konfiguration einen neuen Abschnitt (außerhalb des "Coreos" -Bereichs) mit dem Namen "+ users +" hinzufügen, um diese Informationen abzulegen:
#cloud-config
users:
- name: core
passwd:
coreos:
. . .Validieren Sie Ihre YAML-Syntax und verwenden Sie diese neue Cloud-Konfiguration, wenn Sie den Server erneut erstellen. Sie sollten dann in der Lage sein, das Kennwort zu verwenden, das Sie zum Anmelden über das DigitalOcean-Bedienfeld ausgewählt haben.
Überprüfen des einzelnen Hosts
Sobald Sie angemeldet sind, sollten Sie einige Dinge überprüfen, um festzustellen, ob Ihre Cloud-Konfiguration korrekt verarbeitet wurde.
Überprüfen Sie die Essential Services auf Fehler
Ein einfacher Einstieg besteht darin, nach den bekannten Maschinen zu fragen. Wenn dies ohne Fehler zurückgegeben wird, bedeutet dies, dass "+ fleet " und " etcd +" korrekt gestartet wurden und dass sie mit anderen Hosts kommunizieren.
fleetctl list-machinesWenn Sie hier eine Fehlermeldung erhalten, sollten Sie einige Dinge beachten. Ein häufiger Fehler sieht folgendermaßen aus:
2014/09/18 17:10:50 INFO client.go:278: Failed getting response from http://127.0.0.1:4001/: dial tcp 127.0.0.1:4001: connection refused
2014/09/18 17:10:50 ERROR client.go:200: Unable to get result for {Get /_coreos.com/fleet/machines}, retrying in 100ms
2014/09/18 17:10:50 INFO client.go:278: Failed getting response from http://127.0.0.1:4001/: dial tcp 127.0.0.1:4001: connection refused
2014/09/18 17:10:50 ERROR client.go:200: Unable to get result for {Get /_coreos.com/fleet/machines}, retrying in 200msDa dies einen Stapel verschiedener Komponenten darstellt, beginnen wir auf der obersten Ebene und arbeiten weiter. Überprüfen Sie den Dienst "+ Flotte +", um festzustellen, welche Fehler es uns gibt:
systemctl status -l fleet● fleet.service - fleet daemon
Loaded: loaded (/usr/lib64/systemd/system/fleet.service; static)
Drop-In: /run/systemd/system/fleet.service.d
└─20-cloudinit.conf
Active: active (running) since Thu 2014-09-18 17:10:50 UTC; 2min 26s ago
Main PID: 634 (fleetd)
CGroup: /system.slice/fleet.service
└─634 /usr/bin/fleetd
Sep 18 17:13:07 dumb1 fleetd[634]: INFO client.go:278: Failed getting response from http://localhost:4001/: dial tcp 127.0.0.1:4001: connection refused
Sep 18 17:13:07 dumb1 fleetd[634]: ERROR client.go:200: Unable to get result for {Update /_coreos.com/fleet/machines/795de101bcd24a3a96aa698f770f0074/object}, retrying in 800ms
Sep 18 17:13:08 dumb1 fleetd[634]: INFO client.go:278: Failed getting response from http://localhost:4001/: dial tcp 127.0.0.1:4001: connection refusedWie Sie sehen, wird der Dienst ausgeführt, kann jedoch keine Verbindung zum Port "+ 4001 " herstellen, bei dem es sich um den Port " etcd " handelt. Dies weist darauf hin, dass das Problem möglicherweise bei " etcd +" liegt.
Für jeden unserer wesentlichen Dienste sollten wir den Status und die Protokolle überprüfen. Die allgemeine Vorgehensweise ist:
systemctl status -l
journalctl -b -uDer Befehl "status" gibt den Status des Dienstes und die letzten Protokollzeilen an. Mit dem Befehl journal können wir auf die vollständigen Protokolle zugreifen.
Wenn wir diese mit + etcd + als nächstes versuchen, können wir sehen, dass der + etcd + - Dienst in unserem Fall nicht ausgeführt wird:
systemctl status -l etcd● etcd.service - etcd
Loaded: loaded (/usr/lib64/systemd/system/etcd.service; static)
Drop-In: /run/systemd/system/etcd.service.d
└─20-cloudinit.conf
Active: activating (auto-restart) (Result: exit-code) since Thu 2014-09-18 17:17:03 UTC; 9s ago
Process: 938 ExecStart=/usr/bin/etcd (code=exited, status=1/FAILURE)
Main PID: 938 (code=exited, status=1/FAILURE)
Sep 18 17:17:03 dumb1 systemd[1]: etcd.service: main process exited, code=exited, status=1/FAILURE
Sep 18 17:17:03 dumb1 systemd[1]: Unit etcd.service entered failed state.Wenn wir die "+ etcd +" - Protokolle überprüfen, werden wir so etwas sehen:
journalctl -b -u etcdSep 18 17:21:27 dumb1 systemd[1]: Starting etcd...
Sep 18 17:21:27 dumb1 systemd[1]: Started etcd.
Sep 18 17:21:27 dumb1 etcd[1160]: [etcd] Sep 18 17:21:27.966 INFO | The path /var/lib/etcd/log is in btrfs
Sep 18 17:21:27 dumb1 etcd[1160]: [etcd] Sep 18 17:21:27.967 INFO | Set NOCOW to path /var/lib/etcd/log succeeded
Sep 18 17:21:27 dumb1 etcd[1160]: [etcd] Sep 18 17:21:27.967 INFO |
Sep 18 17:21:28 dumb1 etcd[1160]: [etcd] Sep 18 17:21:28.422 WARNING | Discovery encountered an error: invalid character 'p' after top-level value
Sep 18 17:21:28 dumb1 etcd[1160]: [etcd] Sep 18 17:21:28.423 WARNING | 795de101bcd24a3a96aa698f770f0074 failed to connect discovery service[https://discovery.etcd.io/]: invalid character 'p' after top-level value
Sep 18 17:21:28 dumb1 etcd[1160]: [etcd] Sep 18 17:21:28.423 CRITICAL | 795de101bcd24a3a96aa698f770f0074, the new instance, must register itself to discovery service as required
Sep 18 17:21:28 dumb1 systemd[1]: etcd.service: main process exited, code=exited, status=1/FAILURE
Sep 18 17:21:28 dumb1 systemd[1]: Unit etcd.service entered failed state.Die hervorgehobene Zeile zeigt, dass für diese bestimmte Instanz kein Erkennungstoken vorhanden war.
Überprüfen Sie das Dateisystem, um die von Cloud-Config generierten Konfigurationsdateien anzuzeigen
Als Nächstes müssen Sie überprüfen, welche Servicedateien von der Cloud-Konfiguration generiert wurden.
Wenn Ihr CoreOS-Rechner die Cloud-Konfigurationsdatei verarbeitet, generiert er Stub-Unit-Dateien, mit denen + systemd + und + etcd + gestartet werden. Um die Konfigurationsdateien + systemd + anzuzeigen, die erstellt wurden und zum Starten Ihrer Dienste verwendet werden, wechseln Sie in das Verzeichnis, in dem sie abgelegt wurden:
cd /run/systemd/system
ls -Fetcd.service.d/ fleet.service.d/ oem-cloudinit.serviceSie sehen die verallgemeinerte Datei "+ oem-cloudinit.service ", die von CoreOS automatisch gepflegt wird, und die Verzeichnisse, in denen sich Dienstinformationen befinden. Wir können sehen, mit welchen Informationen unser " etcd +" - Dienst startet, indem wir Folgendes eingeben:
cat etcd.servicd.d/20-cloudinit.conf[Service]
Environment="ETCD_ADDR=10.132.247.162:4001"
Environment="ETCD_DISCOVERY=https://discovery.etcd.io/"
Environment="ETCD_NAME=795de101bcd24a3a96aa698f770f0074"
Environment="ETCD_PEER_ADDR=10.132.247.162:7001"Dies ist eine Stub-Unit-Datei "+ systemd ", mit der dem Dienst zusätzliche Informationen hinzugefügt werden, wenn er gestartet wird. Wie Sie hier sehen können, stimmt die Adresse " ETCD_DISCOVERY +" mit dem Fehler überein, den wir in den Protokollen gefunden haben: Am Ende ist kein Erkennungstoken angehängt. Wir müssen unsere Maschinen mithilfe einer Cloud-Konfiguration mit einem gültigen Erkennungstoken neu erstellen.
Sie können ähnliche Informationen zu + fleet + erhalten, indem Sie Folgendes eingeben:
cat fleet.service.d/20-cloudinit.conf[Service]
Environment="FLEET_METADATA=region=nyc,public_ip=104.131.1.89"
Environment="FLEET_PUBLIC_IP=10.132.247.162"Hier können wir sehen, dass + fleet + einige Metadateninformationen in der Cloud-Konfiguration erhalten hat. Dies kann zum Planen beim Erstellen von Service-Unit-Dateien verwendet werden.
Überprüfen auf Zugriff auf den Metadatendienst
Die eigentliche Cloud-Konfigurationsdatei, die beim Erstellen des CoreOS-Servers mit DigitalOcean angegeben wird, wird mithilfe eines Metadatendienstes gespeichert. Wenn Sie keine Beweise für Ihre Cloud-Konfiguration auf Ihrem Server finden konnten, konnten die Informationen möglicherweise nicht aus dem DigitalOcean-Metadatendienst abgerufen werden.
Geben Sie auf Ihrem Hostcomputer Folgendes ein:
curl -L 169.254.169.254/metadata/v1id
hostname
user-data
vendor-data
public-keys
region
interfaces/
dns/Sie müssen "+ -L " eingeben, um Weiterleitungen zu folgen. Die " 169.254.169.254 +" - Adresse wird für jeden Server verwendet, daher sollten Sie diese Adresse nicht ändern. Hier werden die Metadatenfelder und Verzeichnisse angezeigt, die Informationen zu Ihrem Server enthalten. Wenn Sie dies nicht über Ihren DigitalOcean CoreOS-Server erreichen können, müssen Sie möglicherweise ein Support-Ticket öffnen.
Sie können diese URL abfragen, um Informationen zu Ihrem Server zu erhalten. Sie können jeden der Einträge hier mit zusätzlichen Curl-Befehlen untersuchen, aber der, der die Cloud-Konfigurationsdatei enthält, ist das Feld "+ Benutzerdaten +":
curl -L 169.254.169.254/metadata/v1/user-data#cloud-config
users:
- name: core
passwd: $6$CeKTMyfClO/CPSHB$02scg00.FnwlEYdq/oXiXoohzvvlY6ykUck1enMod7VKJrzyGRAtZGziZh48LNcECu/mtgPZpY6aGCoj.h4bV1
coreos:
etcd:
# generated token from https://discovery.etcd.io/new
discovery: https://discovery.etcd.io/
# multi-region and multi-cloud deployments need to use $public_ipv4
addr: $private_ipv4:4001
peer-addr: $private_ipv4:7001
fleet:
public-ip: $private_ipv4
metadata: region=nyc,public_ip=$public_ipv4
units:
- name: etcd.service
command: start
- name: fleet.service
command: startWenn Sie Ihre Cloud-Konfiguration von diesem Speicherort aus lesen können, bedeutet dies, dass Ihr Server die Cloud-Konfigurationsdaten lesen kann und seine Anweisungen beim Booten des Servers implementieren sollte.
Fehlerbehebung bei anderen Problemen mit einem CoreOS-Hostcomputer
Wenn Sie weiter debuggen müssen, stellen Sie möglicherweise schnell fest, dass CoreOS eine sehr minimale Basisinstallation enthält. Da erwartet wird, dass die gesamte Software in Containern ausgeführt wird, sind nicht einmal einige der grundlegendsten Hilfsprogramme enthalten.
Glücklicherweise bieten die CoreOS-Entwickler eine elegante Lösung für dieses Problem. Mithilfe des in jedem Host enthaltenen Skripts "Toolbox" können Sie einen Fedora-Container mit Zugriff auf die Hostsysteme starten. In diesem Container können Sie alle zum Debuggen des Hosts erforderlichen Dienstprogramme installieren.
Verwenden Sie zum Starten einfach den Befehl + toolbox +:
toolboxDadurch wird das neueste Fedora-Image heruntergeladen und Sie werden in eine Befehlszeile innerhalb des Containers versetzt. Wenn Sie einige schnelle Überprüfungen durchführen, werden Sie feststellen, dass Sie Zugriff auf das Netzwerk des Hostsystems haben:
ip addr show1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 04:01:28:7c:39:01 brd ff:ff:ff:ff:ff:ff
inet 169.254.180.43/16 brd 169.254.255.255 scope link eth0
valid_lft forever preferred_lft forever
. . .Sie haben auch vollen Zugriff auf die Prozesse des Hosts:
ps auxUSER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.1 106024 4912 ? Ss 17:10 0:04 /usr/lib/systemd/systemd --switched-root --system --deserialize 19
root 2 0.0 0.0 0 0 ? S 17:10 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S 17:10 0:00 [ksoftirqd/0]
root 5 0.0 0.0 0 0 ? S< 17:10 0:00 [kworker/0:0H]
root 6 0.0 0.0 0 0 ? S 17:10 0:00 [kworker/u4:0]
root 7 0.0 0.0 0 0 ? S 17:10 0:00 [rcu_sched]
root 8 0.0 0.0 0 0 ? S 17:10 0:00 [rcu_bh]
. . .Sie können alle benötigten Tools in dieser Umgebung installieren. Zum Beispiel können wir + htop +, einen Top-Klon mit zusätzlichen Funktionen, mithilfe des Fedora-Paketmanagers installieren:
yum install htop -y && htopDadurch wird der Prozessmonitor mit allen geladenen Prozessen des Hosts aufgerufen.
Um die Container-Umgebung zu verlassen, geben Sie "exit" ein oder drücken Sie dreimal schnell die Tastenkombination "+ STRG -] +". Sie werden zurück in die Shell-Sitzung des Hosts versetzt.
Fehlerbehebung bei Diensten von jedem Host aus
Ein weiterer Bereich, den Sie möglicherweise zur Fehlerbehebung benötigen, sind die tatsächlich ausgeführten Dienste. Da wir "+ fleet " und " fleetctl +" haben, um unsere Dienste clusterweit zu verwalten, können unsere ersten Schritte auf jedem Server in unserem Cluster ausgeführt werden.
Zunächst sollten wir uns einen Überblick über den Zustand Ihrer Dienste verschaffen, sowohl aus der Sicht von "+ Flotte " als auch von den einzelnen Hosts, die für die Ausführung der einzelnen Dienste zugewiesen wurden. Das ` fleetctl +` Tool gibt uns Befehle, um diese Informationen einfach zu erhalten.
Verschaffen Sie sich zunächst einen Überblick darüber, wie "+ fleet +" den Dienststatus sieht, indem Sie Folgendes eingeben:
fleetctl list-unit-filesUNIT HASH DSTATE STATE TARGET
[email protected] 06d78fb loaded loaded 04856ec4.../10.132.249.212
[email protected] 06d78fb loaded loaded 197a1662.../10.132.249.206
[email protected] 06d78fb loaded loaded e3ca8fd3.../10.132.252.37
[email protected] 0f7f53b launched launched 04856ec4.../10.132.249.212
[email protected] 0f7f53b launched launched 197a1662.../10.132.249.206
[email protected] 0f7f53b launched launched e3ca8fd3.../10.132.252.37
nginx_lb.service c8541af launched launched 96ec72cf.../10.132.248.177Auf diese Weise erhalten Sie einen Überblick über alle Dienste, die "+ fleet +" kennt. Diese Ausgabe enthält einige sehr wichtige Informationen. Lass uns mal sehen.
-
* UNIT *: Dies ist der Name der Einheit. In unserem Fall sind die sechs wichtigsten Dienste alle Instanzeinheiten (weitere Informationen finden Sie unter https://www.digitalocean.com/community/tutorials/how-to-create-flexible-services-for-a-coreos-cluster-with- Fleet-Unit-Dateien [Vorlagen und Instanzen] hier) und der untere Teil scheint eine statische Instanz zu sein. Dies sind die Namen, die wir verwenden können, um Befehle auszugeben, die sich auf jeden dieser Dienste auswirken.
-
* HASH *: Dies ist der Hash der Unit-Datei, die zur Steuerung dieses Dienstes verwendet wird. Wie Sie sehen, werden alle Apache-Discovery-Instanzen aus derselben Vorlagendatei erzeugt. Die "+ apache" -Instanzen werden alle von einem anderen erzeugt. Dies kann hilfreich sein, um mithilfe einer veralteten Einheitendatei festzustellen, ob sich bei einem Ihrer Dienste ein ungewöhnliches Verhalten zeigt.
-
* DSTATE *: Dies ist der gewünschte Status des Geräts. Wenn Sie einen Befehl an "+ flottektl +" senden, um den Status einer Einheit zu ändern, ändert sich diese Spalte, um den gewünschten Status für diese Einheit wiederzugeben.
-
* STATE *: Dies ist der aktuelle Status der Einheit, wie er
+ fleet +bekannt ist. Wenn dies vom DSTATE abweicht, kann dies bedeuten, dass eine Operation fehlgeschlagen ist. -
* ZIEL *: Der Computer, auf dem dieser Dienst ausgeführt werden soll. Dies ist verfügbar, wenn eine Einheit gestartet oder geladen wird. Es enthält die Geräte-ID und die IP-Adresse des Geräts.
Wie Sie sehen, gibt es einige Informationen, die Ihnen beim Debuggen eines Problems helfen können.
Dies ist jedoch nicht die einzige wichtige Stelle, die überprüft werden muss. Es ist wichtig zu wissen, dass es Zeiten gibt, in denen "+ fleet " nicht mit der lokalen " systemd +" - Instanz der Maschine über den Status eines Dienstes übereinstimmt. Dies kann verschiedene Gründe haben, z. B. wenn eine Einheit eine andere Einheit intern startet oder stoppt.
Verwenden Sie stattdessen den Befehl + list-units +, um Informationen über den Status jedes Dienstes abzurufen, der der + systemd + -Instanz des Hosts entnommen wurde, auf dem dieser Dienst ausgeführt wird:
fleetctl list-unitsUNIT MACHINE ACTIVE SUB
[email protected] 04856ec4.../10.132.249.212 active running
[email protected] 197a1662.../10.132.249.206 active running
[email protected] e3ca8fd3.../10.132.252.37 active running
[email protected] 04856ec4.../10.132.249.212 active running
[email protected] 197a1662.../10.132.249.206 active running
[email protected] e3ca8fd3.../10.132.252.37 active running
nginx_lb.service 96ec72cf.../10.132.248.177 active runningHier können wir sehen, dass alle Dienste als ausgeführt aufgeführt sind. Dies stimmt nicht mit den Informationen überein, die "+ list-unit-files +" anzeigt. Das liegt daran, dass jeder der Apache-Dienste den zugehörigen Apache-Discovery-Dienst startet, ohne dass die Flotte davon erfährt. Dies ist kein Fehler, kann jedoch zu Verwirrung über den tatsächlichen Status eines Dienstes führen.
Um weitere Informationen zu einem der Dienste zu erhalten, können Sie mit "+ fleetctl " auf die Informationen " systemctl status " und " journalctl -u +" des Hostsystems zugreifen. Tipp einfach:
fleetctl status● [email protected] - Apache web server service on port 4444
Loaded: loaded (/run/fleet/units/[email protected]; linked-runtime)
Active: active (running) since Thu 2014-09-18 18:50:00 UTC; 7min ago
Process: 3535 ExecStartPre=/usr/bin/docker pull imchairmanm/apache (code=exited, status=0/SUCCESS)
Process: 3526 ExecStartPre=/usr/bin/docker rm apache.%i (code=exited, status=0/SUCCESS)
Process: 3518 ExecStartPre=/usr/bin/docker kill apache.%i (code=exited, status=0/SUCCESS)
Main PID: 3543 (docker)
CGroup: /system.slice/system-apache.slice/[email protected]
└─3543 /usr/bin/docker run -t --name apache.4444 -p 10.132.249.212:4444:80 imchairmanm/apache /usr/sbin/apache2ctl -D FOREGROUNDOder lesen Sie das Tagebuch, indem Sie Folgendes eingeben:
fleetctl journal-- Logs begin at Mon 2014-09-15 14:54:12 UTC, end at Thu 2014-09-18 18:57:51 UTC. --
Sep 17 14:33:20 lala2 systemd[1]: Started Apache web server service on port 4444.
Sep 17 14:33:20 lala2 docker[21045]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 172.17.0.10. Set the 'ServerName' directive globally to suppress this message
Sep 18 18:49:29 lala2 systemd[1]: Stopping Apache web server service on port 4444...
Sep 18 18:49:39 lala2 docker[3500]: apache.4444
Sep 18 18:49:39 lala2 systemd[1]: Stopped Apache web server service on port 4444.
Sep 18 18:49:58 lala2 systemd[1]: Starting Apache web server service on port 4444...
Sep 18 18:49:58 lala2 docker[3518]: apache.4444
Sep 18 18:49:58 lala2 docker[3526]: apache.4444
Sep 18 18:49:58 lala2 docker[3535]: Pulling repository imchairmanm/apache
Sep 18 18:50:00 lala2 systemd[1]: Started Apache web server service on port 4444.Dies kann einige gute Informationen darüber liefern, warum Ihre Dienste ausfallen. Wenn Ihre Unit-Datei beispielsweise eine nicht verfügbare Abhängigkeit deklariert, wird dies hier angezeigt (dies kann passieren, wenn die Abhängigkeit noch nicht in "+ fleet +" geladen wurde).
Ein Fehler, auf den Sie möglicherweise stoßen, wenn Sie einige dieser Befehle ausführen, ist:
Error running remote command: SSH_ AUTH _SOCK environment variable is not set. Verify ssh-agent is running. See https://github.com/coreos/fleet/blob/master/Documentation/using-the-client.md for help.Dies ist ein Hinweis darauf, dass Sie Ihren ssh-Benutzeragenten nicht weitergeleitet haben, als Sie eine Verbindung zu diesem Host hergestellt haben. Damit + fleet + Informationen zu anderen Maschinen im Cluster abrufen kann, wird eine Verbindung mit den SSH-Anmeldeinformationen hergestellt, die Sie auf Ihrem lokalen Computer gespeichert haben.
Dazu müssen Sie einen ssh-Agenten auf Ihrem lokalen Computer ausführen und Ihren privaten Schlüssel hinzufügen. Sie können dies auf Ihrem lokalen Computer tun, indem Sie Folgendes eingeben:
eval $(ssh-agent)
ssh-addIdentity added: /home//.ssh/id_rsa (/home//.ssh/id_rsa)Sobald Ihr ssh-Agent Zugriff auf Ihren privaten Schlüssel hat, sollten Sie sich mit der Option "+ -A +" mit Ihrem CoreOS-Host verbinden, um diese Informationen weiterzuleiten:
ssh -A core@Auf diese Weise kann der Computer, auf dem Sie ssh-en, Ihre Anmeldeinformationen verwenden, um Verbindungen zu den anderen Computern im Cluster herzustellen. Hiermit können Sie die "+ systemd +" - Informationen von Remote-Clustermitgliedern lesen. Es ermöglicht Ihnen auch, direkt mit anderen Mitgliedern zu sshen.
Fehlerbehebung bei Containern vom Host aus, auf dem der Dienst ausgeführt wird
Obwohl Sie viele großartige Informationen nur mit + fleetctl + erhalten können, müssen Sie manchmal zu dem Host gehen, der für die Ausführung des Dienstes verantwortlich ist, um Fehler zu beheben.
Wie oben erwähnt, ist dies einfach, wenn Sie Ihre SSH-Informationen beim Herstellen einer Verbindung weitergeleitet haben. Von dem Host, mit dem Sie verbunden sind, können Sie mit + fleetctl + zu anderen Rechnern „springen“. Sie können entweder eine Rechner-ID oder einfach den Servicenamen angeben. Der Prozess + fleetctl + ist intelligent genug, um zu wissen, auf welchen Host Sie sich beziehen:
fleetctl sshDadurch erhalten Sie eine SSH-Verbindung zu dem Host, der für die Ausführung dieses Dienstes zuständig ist. Ein Dienst muss sich im Status "geladen" oder "gestartet" befinden, damit dies funktioniert.
Von hier aus haben Sie Zugriff auf alle lokalen Tools zur Fehlerbehebung. Zum Beispiel können Sie auf die umfassenderen + journalctl + Flags zugreifen, die möglicherweise nicht über den Befehl + fleetctl journal + verfügbar sind:
journalctl -b --no-pager -u apache@4444An dieser Stelle möchten Sie möglicherweise Docker-Probleme beheben. Geben Sie Folgendes ein, um die Liste der ausgeführten Container anzuzeigen:
docker psCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
imchairmanm/apache:latest "/usr/sbin/apache2ct 30 minutes ago Up 30 minutes 10.132.249.212:4444->80/tcp apache.4444Wir können sehen, dass derzeit ein Container läuft. Die hervorgehobene Container-ID ist nützlich für viele weitere Docker-Vorgänge.
Wenn Ihr Dienst nicht gestartet werden konnte, wird Ihr Container nicht ausgeführt. Übergeben Sie das Flag "+ -a +", um eine Liste aller Container anzuzeigen, einschließlich derjenigen, die beendet wurden / fehlgeschlagen sind:
docker ps -aCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b68139630337 imchairmanm/apache:latest "/usr/sbin/apache2ct 31 minutes ago Up 31 minutes 10.132.249.212:4444->80/tcp apache.4444
4389108bff1a imchairmanm/apache:latest "/usr/sbin/apache2ct 28 hours ago Exited (-1) 28 hours ago apache.8888
5af6e4f95642 imchairmanm/lalala:latest "/usr/sbin/apache2ct 3 days ago Exited (-1) 3 days ago apache.7777Um den last-Container anzuzeigen, der unabhängig von seinem Status gestartet wurde, können Sie stattdessen das Flag + -l + verwenden:
docker ps -lCONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b68139630337 imchairmanm/apache:latest "/usr/sbin/apache2ct 33 minutes ago Up 33 minutes 10.132.249.212:4444->80/tcp apache.4444Sobald Sie die Container-ID des gesuchten Containers haben, können Sie auf Docker-Ebene nachforschen. Zunächst können Sie die Protokolle anzeigen:
docker logsDadurch erhalten Sie die Protokollinformationen, die aus dem Container gesammelt werden können. Dies sollte funktionieren, unabhängig davon, ob der Container ausgeführt wird oder nicht. Wenn der Container interaktiv ausgeführt wurde (mit den Flags "+ -i " und " -t +" und einer Shell-Sitzung), ist die gesamte Sitzung in den Protokollen verfügbar.
Sie können eine Liste der ausgeführten Prozesse für jeden aktiven Container abrufen, indem Sie Folgendes eingeben:
docker topErzeugen einer Shell-Sitzung in einem Container
Einer der nützlichsten Schritte besteht darin, eine Shell-Sitzung in einem laufenden Container zu öffnen, um zu sehen, was von innen geschieht. Zu diesem Zweck wird CoreOS mit einem Hilfsprogramm namens "+ nsenter +" ausgeliefert.
Docker-Container richten Kernel-Namespaces ein, und dieses Tool kann eine Sitzung in diesen Umgebungen starten. Der erste Schritt besteht darin, die PID des Containers zu ermitteln, den Sie eingeben möchten:
PID=$(docker inspect --format {{.State.Pid}} )Jetzt können Sie eine Shell-Sitzung in dieser Container-Umgebung eröffnen, indem Sie Folgendes eingeben:
sudo nsenter -t $PID -m -u -i -n -pSie erhalten eine Shell-Sitzung innerhalb der Container-Umgebung. Von hier aus können Sie Protokolle anzeigen oder andere erforderliche Fehler beheben.
Abhängig von der Art und Weise, in der der Container erstellt wurde, wird möglicherweise die Meldung angezeigt, dass "+ bash " nicht gefunden wurde. In diesem Fall müssen Sie die generische " sh +" - Shell verwenden, indem Sie diese am Ende Ihres Befehls anhängen:
sudo nsenter -t $PID -m -u -i -n -p /bin/shFazit
Dies sind nur einige der Verfahren, mit denen Sie Probleme mit Ihren CoreOS-Clustern beheben können. Diese Informationen sollen Ihnen dabei helfen, Probleme mit Ihrer Cloud-Konfigurationsdatei aufzuspüren und die Fähigkeit Ihres Computers zu beheben, Dienste richtig zu gruppieren und zu starten. Ein weiterer Bereich, den wir behandelt haben, ist das Aufspüren von Problemen mit den Docker-Containern und -Diensten.
Eines der wichtigsten Dinge, die Sie beachten sollten, ist, dass das Debuggen umso einfacher wird, je mehr Informationen Sie über Ihr System haben. Es ist hilfreich, einen soliden Überblick über die Rolle der einzelnen Komponenten und deren Interaktion zu haben, um die Systemfunktion zu unterstützen. Wenn Sie sich beim Aufspüren eines Problems verloren fühlen, kann es hilfreich sein, sich über die Grundlagen von CoreOS zu informieren.