PlattformServerless-Deployment

Serverless-Deployment

Apps, die eigenständig skalieren — vom Marketplace zur Laufzeit.

Im Deployment betreiben Entwickler ihre eigenen Apps in der eQuantic Cloud als Serverless-Dienste, die automatisch skalieren, im Leerlauf auch auf null.

Einen Dienst erstellen

Der Assistent ist ein Marketplace nach Kategorie. Die Kategorie Custom (Standard) deckt vier Quellen ab:

app.equantic.space/deploy/gateway
gatewayLiveGit
api.equantic.space
CPU
MEM
automatische Skalierung · 1–6 Instanzen
1Automatische Skalierung
Jeder Dienst skaliert eigenständig (auch auf null) — CPU, Speicher und Instanzen auf einen Blick.
QuelleWas sie tut
Git-RepositoryWir erkennen den Stack, erzeugen das Dockerfile und ermitteln Port und Variablen — Auto-Detect.
DockerfileBuild aus einem Dockerfile im Repository.
Docker ComposeStartet mehrere Dienste aus einer compose.yml.
Docker-ImageVerwendet ein fertiges Image aus einer Registry.

Die übrigen Kategorien bringen ~40 fertige Open-Source-Dienste (Postgres, Redis, RabbitMQ, MinIO, Grafana, n8n, Metabase, Keycloak, WordPress…), jeweils mit eigenem Installationsformular.

Den Dienst betreiben

  • Überblick mit CPU-/Speicher-Diagrammen und Quelle/Build.
  • Deployments mit Live-Build-Stream und Rollback.
  • Skalierung & Ressourcen — Skalierungs-Trigger (KEDA), Scale-to-Zero, Instanzbereich und CPU/Speicher jederzeit änderbar — eine Größenänderung rollt einen laufenden Dienst mit dem neuen Zuschnitt vorwärts, ohne ihn neu anzulegen.
  • Health-Check — verweisen Sie die Plattform auf den eigenen Probe-Endpunkt Ihrer App, und überschreiben Sie command/args des Containers, wenn die Vorgaben des Images nicht Ihre sind.
  • Interaktive Konsole (Drawer), Live-Runtime-Logs, Variablen und Domains (automatisches TLS).
  • www auf jeder eigenen Domain — ein Schalter pro Domain, der www.beispiel.de per 301 auf beispiel.de weiterleitet (die Voreinstellung, und was Suchmaschinen wollen: zwei Hosts mit identischem Inhalt sind zwei kanonische URLs für eine Seite) oder beide ausliefert. Ein www-CNAME hierher genügt allein nicht: DNS löst den Namen auf, und wer antwortet — und für welchen Host das Zertifikat ausgestellt wird — entscheidet sich danach anhand der Anfrage. Die Domain muss www also beanspruchen, damit die Plattform es routet und TLS dafür ausstellt.
  • Die eigene Adresse des Dienstes — im Tab Domains wählen Sie den Namen, unter dem der Dienst unter der Domain der Plattform antwortet: cura-accounts.apps.equantic.space statt des generierten cura-accounts-e49f09.apps.equantic.space. Die generierte Adresse funktioniert weiter, mit einer 301-Weiterleitung auf die gewählte, die Pfad und Query behält, sodass ein bereits geteilter Link nicht bricht. Ein Name gehört dem, der ihn zuerst wählt, auf der ganzen Plattform, und ein aufgegebener Name ist sofort für jeden frei. Jede Adresse im Tab hat einen Button zum Kopieren.
  • Erweiterte Konfiguration (EXPERT) — Overrides für Ressourcen/Probes und Inspektion des generierten Manifests.

Die erweiterten Einstellungen des Assistenten bieten dieselben Regler schon beim Anlegen — mit den dort gewählten Ressourcen und dem Instanzbereich läuft bereits das erste Deployment.

Offene Pull Requests können außerdem ephemere Preview-Umgebungen erhalten, die wie reguläre Dienste deployt und beim Merge oder Schließen automatisch zerstört werden — siehe Repositories & CI/CD.

Die Plattform exponiert keine Server/Nodes — sie ist serverless. Jedes Projekt ist eine isolierte Umgebung und jeder Dienst skaliert über Instanzen.

Woher eine Version stammt

Der Tab Übersicht eines Dienstes zeigt, welche Version läuft, und — wenn das Image eines von unseren ist — woher sie kommt: der Pipeline-Lauf, der sie gepusht hat, der Commit dahinter und das Repository. Der Lauf-Bildschirm beantwortet dieselbe Frage von der anderen Seite, mit einer Leiste Bereitgestellt in, die jede Umgebung nennt, in der seine Images laufen.

Die Verbindung wird aufgezeichnet, nie geraten. Ein Job, der mit dem Token pusht, das die Plattform ohnehin injiziert, wird diesem Lauf zugeordnet:

yaml
- run: docker login registry.equantic.space -u eqs -p $EQS_TOKEN
- run: docker push registry.equantic.space/acme/api:${{ github.sha }}

Ein Image aus einer Registry, die wir nicht betreiben, hat keine Herkunft, und der Bildschirm sagt das, statt ein leeres Panel zu zeigen.

Einen Dienst von einem anderen aus erreichen

Die Verbindungszeichenfolge eines Dienstes nennt ihn vollständig — postgres.p-1a2b3c-production.svc.cluster.local — und nicht nur postgres. Der kurze Name löst nur innerhalb seines eigenen Space auf, und ein Space ist ein Kubernetes-Namespace: eine App in einem anderen Space, die den kurzen Namen bekommen hatte, lief, bis etwas sie neu startete, und konnte danach ihre eigene Datenbank nicht mehr auflösen.

Kopieren Sie die Verbindung aus dem Verbinden-Panel des Dienstes (oder eqs db url <dienst>), dann funktioniert sie von überall im Workspace.