Zum Hauptinhalt springen

Fehlerbehebung und weiterführende Themen

Was sich hinter den Kulissen verbirgt​

Um Probleme beim Deployment Ihrer Applikation zu verstehen und zu beheben, ist es hilfreich, etwas darüber zu wissen, was sich im Backend abspielt. Bei der erfolgreichen Applikationserstellung kommt es im Wesentlichen zu folgenden durchgeführten Schritten:

  • Das git Repository wird in der festgelegten Revision geklont
  • Die Programmiersprache bzw. das Framework der Applikation wird erkannt
  • Die Anwendung wird erstellt und mit den für die Sprache passenden Tools in einen OCI Container verpackt
  • Das erstellte Anwendungs-Image wird in die Deploio-Image Registry hochgeladen
  • Ein Release wird erstellt, welches das zuvor erstellte Image ausführt
  • Die Anwendung wird an einem HTTP Endpunkt bereitgestellt

Während der Build- und Release-Phasen kann es zu unterschiedlichen Fehlern kommen. Wenn ein Fehler oder eine Inkompatibilität während des Klonens oder des Builds auftritt, zeigt nctl die Build Logs an, um die Fehlerbehebung zu erleichtern. Wenn der Build erfolgreich ist, aber der Release nicht bereitgestellt werden kann, können die Applikations-Logs einen Hinweis auf das Problem geben. Falls die Anwendung allerdings direkt beim Start fehlschlägt, kann dies zu einem leeren Applikations-Log führen.

Einen Build wiederholen​

Build-Prozesse können aus verschiedenen Gründen zu Fehlern führen. Meistens können diese Fehler durch einen Fix im Applikations-Code oder durch das Hinzufügen einer fehlenden Umgebungsvariablen behoben werden. Es kann aber auch zu temporären Fehlern im internen Deploio-System kommen. In derartigen Fällen können Sie die Wiederholung eines Builds mittels nctl anstossen:

$ nctl update app go-example --retry-build

Den Build Output lokal betrachten und ausführen​

Da der Deploio-Build-Prozess ein OCI-/Docker-Image erzeugt, ist es möglich, sich dieses Container Image auf Ihr lokales Gerät herunter zu laden. Das kann hilfreich sein, wenn der Build erfolgreich ist, aber die Applikation dennoch nicht gestartet werden kann. Bitte beachten Sie, dass es nur möglich ist, Images für Fehlerbehebungszwecke herunterzuladen. Das Hochladen von Images in die Registry ist nicht möglich.

$ nctl get build go-example-build-1 --pull-image
Pulling image of build go-example-build-1
739cb80086f0: Download complete
1bfd697887fa: Download complete
aea73d1e202c: Download complete
e4fd482e7de7: Download complete
 ✓ Pulled image deploio.296dc8b.registry.nineapis.ch/nine/go-example 💾

Nach dem Image-Download können Sie Docker oder Podman (bzw. jegliche Tools, welche OCI-Images unterstützen) nutzen, um das Image lokal auszuführen.

$ docker run deploio.296dc8b.registry.nineapis.ch/nine/go-example

Ausführen einer Shell oder eines Befehls in einer Deploio-Applikation​

Sobald mindestens ein erfolgreiches Release einer Deploio-Applikation erstellt wurde, können Sie einen Befehl oder eine Shell in der Applikation ausführen. Bitte beachten Sie dass sich das Release in einem stabilen Zustand befinden muss. Sollte Ihre Applikation aufgrund eines Fehlers wiederholt neustarten, so wird es nicht möglich sein, einen Befehl oder eine Shell zu starten.

Für die Ausführung können Sie nctl nutzen. Standardmässig wird dabei eine Shell in der ersten Replika der Deploio-Applikation gestartet.

$ nctl get app
NAME     HOSTS                        UNVERIFIED_HOSTS
rails    rails.7f0b629.deploio.app    none

$ nctl exec app rails
cnb@rails-5fcc67cc-89fd2:/workspace$

Sie können auch einen einzelnen Befehl starten indem Sie diesen durch -- vom Rest des Kommandos abtrennen.

$ nctl exec app rails -- hostname
rails-5fcc67cc-89fd2

Bitte beachten Sie, dass jeder Befehl, welcher gestartet wird, Ihrem Arbeitsspeicher-Quota angerechnet wird. Dieses hängt von der gewählten Deploio- Applikationsgrösse ab. Sollte der Befehl zu viel Arbeitsspeicher verbrauchen, so wird die Deploio-Applikations-Replika beendet (OOM) und der nctl-Befehl wird mit einem Exit Code von 137 beendet.

nctl: error: command terminated with exit code 137

Beachten Sie bitte weiterhin, dass sämtliche Änderungen, welche an lokalen Dateien durchgeführt werden, nur temporär verfügbar sind. Nach einem Neustart der Deploio-Applikations-Replika gehen die gemachten Änderungen verloren.

Lets Encrypt-Zertifikate​

Applikationen, welche auf Deploio laufen, werden von Haus aus über eine generierte URL zugänglich gemacht. Auf diesem Weg können Sie an Ihrer Applikation entwickeln und testen, ohne dass eine eigene Domain/Hostname genutzt werden muss. Die Kommunikation wird zusätzlich durch ein TLS-Zertifikat von Lets Encrypt, welches direkt bei der Deploio-Applikationserstellung ausgestellt wird, verschlüsselt. Für die Erstellung von Lets Encrypt-Zertifikaten nutzen wir generell den HTTP-01 Challenge Typ. Um den Status des Standard-TLS-Zertifikates zu sehen, können Sie nctl nutzen:

nctl get app <APP NAME> -o yaml

kind: Application
apiVersion: apps.nine.ch/v1alpha1
...
status:
  atProvider:
    ...
    defaultHostsCertificateStatus: Issued

Sobald Sie eigene Host- oder Domainnamen zu ihrer Deploio-Applikation hinzufügen, wird ein zusätzliches Lets Encrypt- Zertifikat, welches alle eigenen Hostnamen beinhaltet, ausgestellt. Um den Status dieses Zertifikats zu sehen, können Sie wieder nctl nutzen:

nctl get app <APP NAME> -o yaml

kind: Application
apiVersion: apps.nine.ch/v1alpha1
...
status:
  atProvider:
    ...
    customHostsCertificateStatus: Pending

Da wir den HTTP-01 Challenge-Typ verwenden, um alle Domain-/Hostnamen von Lets Encrypt verifizieren zu lassen, kann das TLS-Zertifikat nur erfolgreich ausgestellt werden, sobald alle eigenen Host-/Domainnamen korrekt auf die Deploio-Infrastruktur zeigen. Unsere Prozesse zur Ausstellung des Zertifikats verwenden bereits eine optimierte DNS-Auflösung, um möglichst schnell auf Änderungen reagieren zu können. Beachten Sie bitte, dass es trotzdem einige Minuten dauern kann, bis das TLS-Zertifikat korrekt erstellt wird. Dies ist besonders wichtig, falls eine bereits vorhandene Applikation von einem anderen Anbieter zu Deploio migriert werden soll. Da die Erstellung des TLS-Zertifikats einige Minuten dauern kann, sollte die Migration besser zu Randzeiten, wie beispielsweise nachts, durchgeführt werden.

Es gilt weiterhin zu beachten, dass Lets Encrypt eventuell vorhandene IPv6 DNS- Einträge bevorzugt. Sollten Sie daher gleichnamige A und AAAA DNS-Einträge für Ihre Applikation angelegt haben, so bitten wir Sie, die AAAA-Einträge zu löschen, um die Zertifikatserstellung zu ermöglichen (Deploio unterstützt derzeit kein IPv6).