Wenn etwas nicht läuft

Fang hier an

klickops versucht, in einem Satz am Workload selbst zu sagen, was los ist. Lies also zuerst die Statuszeile. Danach den Tab Logs, denn dort steht der Bericht des Containers über sein eigenes Ende.

Drei Fragen klären das meiste. Ist er je gestartet? Ist er gestartet und dann gestorben? Oder läuft er und ist bloss nicht erreichbar? Das sind verschiedene Probleme, und die Abschnitte unten folgen dieser Reihenfolge.

Er startet gar nicht

Das Image lässt sich nicht ziehen. Der Name stimmt nicht, der Tag existiert nicht, oder die Registry braucht Zugangsdaten, die klickops nicht hat. Prüf die genaue Referenz, und bei einer privaten Registry, ob Pull-Credentials hinterlegt sind. Ein Tippfehler im Tag sieht genauso aus wie ein fehlendes Image.

Die Kapazität des Projekts blockiert ihn. Der Status sagt das direkt, mit den Zahlen: Im Projekt ist nicht genug CPU oder Memory übrig, um ihn zu starten. Entferne oder verkleinere einen Workload, oder wechsle auf einen grösseren Tarif, der die Kapazität jedes Projekts anhebt. Eine so abgelehnte Datenbank sagt das auf ihrer Karte.

Die Tarifgrenze hat abgelehnt. Das scheitert schon beim Anlegen, mit einer Meldung, die die Grenze benennt. Also sofort sichtbar statt als Hänger. Siehe Tarif und Kosten.

Er startet und stirbt

Er beendet sich sauber. klickops startet ihn neu, weil eine App laufen soll. Wenn die Sache wirklich einmal laufen und fertig sein soll, ist sie ein Scheduled Job und keine App.

Er stürzt beim Start ab. Der Grund steht in den Logs des gescheiterten Versuchs, und es ist meistens eines von drei Dingen: eine fehlende Umgebungsvariable, eine Datenbank, die er noch nicht erreicht, oder ein falscher Port. Prüf, ob der konfigurierte Port der ist, auf dem der Prozess tatsächlich lauscht.

Ihm geht der Speicher aus. Der Container wird beendet und neu gestartet, und die Zahl der Neustarts klettert weiter. Memory wird auf den tatsächlichen Verbrauch zugeschnitten, ein Prozess, der wirklich mehr braucht, bekommt also mehr. Ein Leck wird schlicht wiederholt beendet.

Er läuft, ist aber nicht erreichbar

Prüf zuerst den Health-Check. Datenverkehr wartet, bis der Port eine Verbindung annimmt. Ein Prozess, der auf einem anderen Port lauscht als dem konfigurierten, ist von innen gesund und von aussen unsichtbar.

Dann DNS. Löst der Hostname nicht auf, wurde nie ein Zertifikat ausgestellt und die Domain-Prüfung nie grün. Siehe Domains.

Dann die Firewall. Eine blockierte Verbindung läuft in einen Timeout statt abgewiesen zu werden, das sieht also nach Langsamkeit aus und nicht nach Ablehnung. Der Tab Firewall der App zeigt die Verbindungen, die in den letzten 15 Minuten blockiert wurden, mit einem Klick zum Erlauben. Das geht schneller als raten. Siehe Firewall.

Eine Datenbank hängt im Provisioning

Gib ihr zwei Minuten: ein PostgreSQL-Cluster braucht die wirklich zum Hochfahren. Danach ist die übliche Ursache die Kapazität des Projekts, siehe oben.

Meldet sie sich gesund und deine App kommt trotzdem nicht dran, liegt es fast nie an der Datenbank. Prüf, ob die App die Verknüpfung hat und ob beide im selben Projekt liegen: Eine App erreicht keine Datenbank in einem anderen Projekt, und keine Firewall-Regel öffnet diesen Weg.

Wann du fragst

Wenn du den Namen des Workloads hast, den Zeitpunkt, ab dem es schiefging, und die genaue Meldung. Diese drei machen aus einem Gespräch eine Antwort.

Verwandt

• Backups und Wiederherstellung, wenn die Lösung zurück statt vorwärts heisst.
• Apps dazu, was jeder Tab zeigt.