Organisationen, Projekte, Workloads
Die drei Ebenen, an denen alles andere hängt, und wem was gehört.
Drei Ebenen, mehr nicht
| Was es ist | Was dazugehört | |
|---|---|---|
| Organisation | Deine Firma auf klickops | Tarif, Rechnung, Personen und alle Projekte darunter |
| Projekt | Eine Klammer um zusammengehörende Workloads | Apps, Datenbanken, Buckets, Scheduled Jobs, Volumes und die Netzwerkregeln dazwischen |
| Workload | Eine laufende Sache | Eigene Domains, Konfiguration, Speicher und Backups |
Eine vierte Ebene gibt es nicht. Was danach aussieht, gehört zu einem Workload: Eine Domain gehört zur App, auf die sie zeigt. Ein Volume gehört zur App, die es einbindet. Ein Zertifikat gehört zu seiner Domain.
Organisationen
Die Organisation begrenzt alles, was kein laufender Container ist. Hier vergibst du Zugriff, hier gilt der Tarif, hier entsteht die Rechnung. Wer zur Organisation gehört, sieht ihre Projekte. Eine eigene Anmeldung pro Projekt gibt es nicht.
Eine bekommst du bei der Anmeldung. Die meisten brauchen nie eine zweite. Eine zweite trennt wirklich: eigene Rechnung, eigene Mitglieder, nichts wird geteilt.
Projekte
Im Projekt gruppierst du, was zusammengehört. Die brauchbare Frage lautet: Sprechen die Dinge miteinander? Eine App und die Datenbank, die sie abfragt, gehören in ein Projekt. Innerhalb eines Projekts erreichen sie einander über den Namen, in einem privaten Netz, ohne dass etwas nach aussen offen ist.
Zwei Punkte solltest du vorher kennen.
- Ein Workload wechselt das Projekt nicht. Weder eine App noch eine Datenbank. Ein Projekt später zu teilen heisst, Dinge neu anzulegen. Eine Minute Nachdenken am Anfang lohnt sich.
- Wer ein Projekt löscht, löscht seinen Inhalt. Genau dafür ist die Klammer da. Es ist auch der schnellste Weg, ein Experiment aufzuräumen.
Projektnamen sind innerhalb einer Organisation eindeutig, sonst nirgends. Zwei Organisationen dürfen also beide ein Projekt api haben, ohne sich abzusprechen.
Unter der Haube ist ein Projekt ein Kubernetes-Namespace mit zufälligem Namen. Jeder Workload darin ist darunter gewöhnliches Kubernetes. Das zählt, falls du je wechseln willst: Deine Ressourcen sind normale Kubernetes-Objekte und kein eigenes Format. Nimmst du die klickops-Labels weg, laufen sie einfach weiter.
Workloads
Ein Workload ist eine laufende Sache, auf die du zeigen kannst. Heute sind das eine App, eine Datenbank, ein Bucket, ein Scheduled Job oder ein Volume.
Alles, was du konfigurierst, hängt an einem davon. Deshalb hat das Handbuch eine Seite pro Workload und nicht eine pro Einstellung. Suchst du, wo etwas geändert wird, fang bei der Sache an, die es betrifft.
Benennung
Namen bestehen aus Kleinbuchstaben, Ziffern und Bindestrichen. Sie sind endgültig: Projekte und Workloads lassen sich nicht umbenennen, weil der Name die Identität ist, auf die anderes verweist.
Benenn nach dem, was etwas ist, nicht danach, wo es läuft. orders-db übersteht den Weg von Staging nach Produktion. prod-db-v2 fängt an zu lügen, sobald sich etwas ändert.
Grenzen
Der Tarif hängt an der Organisation. Er begrenzt, wie viel du von jeder Sache bekommst: Projekte, Apps, Datenbanken, Replicas, eigene Domains sowie CPU, Memory und Speicher pro Projekt.
Die Grenzen greifen beim Anlegen und nicht auf der Rechnung. Stösst du an eine, siehst du einen Fehler im Formular statt einer Überraschung später. Die aktuellen Zahlen je Tarif stehen im Produkt auf der Tarif-Seite.