Betriebsart wählen
Alle drei Varianten betreiben dieselbe Software. Sie unterscheiden sich darin, wie sie gestartet, aktualisiert und skaliert wird.
Hast du keinen Grund, anders zu entscheiden, wähle Docker auf einem Server. Betreibt dein Betriebsteam bereits eine Kubernetes-Plattform und will Collabase mit denselben Werkzeugen betreiben wie alles andere, wähle Kubernetes. Beides wird vollständig unterstützt.
Betriebssystem und Plattform
macOS und Windows mit Docker Desktop (WSL2) eignen sich für Tests und lokale Versuche. Eine Produktionsplattform sind sie nicht.
CPU und Arbeitsspeicher
Dimensioniere für die Personen, die gleichzeitig arbeiten, nicht für die Zahl der Konten. Dimensionierung und Skalierung ordnet gleichzeitige Benutzer den Ressourcen zu. Das sind die Ausgangswerte:
Bei Docker bricht der Installer unter 2 GB RAM oder 10 GB freiem Speicher ab. Unter 4 GB schaltest du die Live-Zusammenarbeit aus.
Bei Kubernetes reservierst du dieselbe Kapazität im Namespace. Was die einzelnen Teile von Collabase höchstens nutzen dürfen, steht unter Was im Cluster läuft. Die Speicherlimits aller Teile ergeben zusammen gut 11 GB, und der Speicher, den der Scheduler dafür reserviert, liegt bei etwa 1,75 GB. Im Normalbetrieb liegt der Verbrauch weit unter den Limits. Die Limits schützen den Cluster vor einem ausser Kontrolle geratenen Prozess.
Betreibe Test- und Produktivsystem als getrennte Installationen mit je eigener Datenbank. Ein Testsystem kommt mit dem Minimum aus.
Speicher
Insgesamt sind es etwa 45 GB bei Kubernetes und 20 GB bei einem einzelnen Docker-Server, dazu die Backups. Bei Kubernetes brauchst du eine Standard-Storage-Klasse mit
ReadWriteOnce-Volumes, oder du setzt die Klasse pro Volume. Behalte den Speicher im Auge und vergrössere ihn, bevor er voll ist. Hosting und Architektur listet auf, was Platz braucht.
Datenbank
Collabase bringt eine eigene PostgreSQL mit. Betreibt deine Organisation stattdessen einen verwalteten oder zentralen Datenbankdienst, muss er Folgendes bieten:- PostgreSQL 16 oder neuer
- Die Erweiterung
pgvector, die Collabase bei der Installation mitCREATE EXTENSION vectoraktiviert. Der Datenbankbenutzer, der installiert, braucht das Recht dazu, oder dein Datenbankteam aktiviert die Erweiterung vorab einmalig. - Eine Datenbank und einen Benutzer, dem sie gehört
pgvector startet Collabase nicht. Kläre das mit deinem Datenbankteam, bevor du dich für eine externe Datenbank entscheidest.
Netzwerk
Eingehend
Von aussen ist sonst nichts erreichbar. Die Teile von Collabase sprechen über ein internes Netzwerk miteinander.
Die Live-Zusammenarbeit nutzt eine WebSocket-Verbindung auf derselben Adresse unter
/collab. Ein Load Balancer oder Proxy vor Collabase muss WebSocket-Upgrades durchreichen und Uploads von mindestens 32 MB erlauben.
Ausgehend
Collabase baut nur die Verbindungen auf, die du einrichtest. Erlaube die, die du nutzt:Collabase prüft den Lizenzschlüssel auf dem Server und braucht dafür keine Verbindung zu Collabase. Nutzungstelemetrie ist ausgeschaltet, bis ein Administrator zustimmt, und ein Administrator kann sie wieder ausschalten.
Zertifikate
Eine interne Adresse wie
collabase.company.local braucht ein Zertifikat deiner eigenen Zertifizierungsstelle, und jeder Browser muss dieser Stelle vertrauen.
Container-Images
Die Collabase-Images teilen sich eine Versionsnummer und sind öffentlich, das Laden braucht also keine Anmeldung. Viele Organisationen kopieren die Images zuerst in eine interne Registry. Bei Kubernetes setzt du das Repository jedes Images in deiner Werte-Datei, siehe Eigene Image-Registry nutzen.
Optionale Integrationen
Diese richtest du nach der Installation in Collabase ein. Plane sie vorab mit deinen Identitäts- und Mail-Teams.Informationen für dein Betriebsteam
Installiert und wartet ein anderes Team als deines Collabase, klärt diese Punkte vorher gemeinsam.Weiterführende Seiten
Installation mit Docker
Auf einem Linux-Server installieren.
Installation auf Kubernetes
Mit dem Helm-Chart installieren.
Dimensionierung und Skalierung
Ressourcen auf dein Team abstimmen.