Dienste verwalten

Sobald ein Dienst erstellt ist, kannst du seinen Lebenszyklus direkt über das calmo.cloud-Dashboard verwalten.

Starten und Stoppen #

Dienst starten #

Wenn ein Dienst gestoppt ist, öffne oben auf der Dienstseite das Menü Dienst und klicke auf Start. Der Container startet und Odoo wird unter seiner URL erreichbar.

Dienst stoppen #

Öffne Dienst und klicke auf Stop, um einen laufenden Dienst herunterzufahren. Dies stoppt den Container, bewahrt aber alle Daten — Datenbank, Dateien und Konfiguration bleiben intakt. Du kannst ihn jederzeit wieder starten.

Dienst neustarten #

Öffne Dienst und klicke auf Restart, um den Dienst zu stoppen und sofort wieder zu starten. Dies ist nützlich wenn:

• Du ein Addon installiert oder aktualisiert hast
• Odoo nicht mehr reagiert
• Du Konfigurationsänderungen vorgenommen hast, die einen Neustart erfordern

Ein Neustart behält den Container des Dienstes und damit das Image, aus dem er erstellt wurde. Ein neu abgerufenes Image geht erst mit dem nächsten Redeploy oder Start live (siehe Basis-Image aktualisieren).

Dienst löschen #

Um einen Dienst dauerhaft zu entfernen:

1. Öffne den Dienst, den du löschen möchtest
2. Öffne das Menü ⋮ am Ende der Kopfzeile und klicke auf Delete Odoo
3. Bestätige die Löschung

Dienst neutralisieren #

Die Aktion Neutralize entfernt sensible Daten aus einem Dienst. Dies ist nützlich, wenn du eine sichere Demo- oder Testkopie einer Produktionsinstanz erstellen möchtest — es anonymisiert Daten, damit echte Kundeninformationen nicht offengelegt werden.

Basis-Image aktualisieren #

Jeder Odoo-Dienst basiert auf einem Basis-Image. Das Abrufen des neuesten Basis-Images bringt Sicherheitspatches und Odoo-Updates, ohne die Konfiguration deines Dienstes zu verändern. calmo.cloud baut die Basis-Images jeden Abend (UTC) aus dem aktuellen Stand von Odoo und Odoo Enterprise neu, ein Pull bringt also mit, was Odoo bis zu diesem Abend veröffentlicht hat.

Image-Pull-Strategie #

Die Einstellung Image pull strategy am Dienst steuert, wie das Basis-Image aktuell gehalten wird:

Automatische Pulls laufen nur für laufende Dienste und werden einmal täglich geprüft, um Mitternacht UTC, ein paar Stunden nach dem abendlichen Build. Jeder Build zählt als neueres Image, deshalb bittet die Dienstseite mit Täglich nach fast jedem Pull um Upgrade all modules (siehe Nach einem neueren Image).

Manuell abrufen #

Du kannst einen Pull jederzeit auslösen, unabhängig von der Strategie, es sei denn, der Dienst ist auf ein tägliches Image festgelegt:

• Öffne auf der Dienstseite Dienst und klicke auf Pull Image
• Öffne in der Dienstliste das Zeilenaktionen-Menü und klicke auf Pull Image
• Um mehrere Dienste gleichzeitig zu aktualisieren, wähle sie in der Dienstliste aus und verwende die Massenaktion Queue: Pull Image

Jeder Pull wird im Actions-Tab und in der Timeline des Dienstes protokolliert, und die Spalte Last image pull in der Dienstliste zeigt, wann jeder Dienst sein Image zuletzt abgerufen hat.

Welcher Odoo-Commit läuft #

Der Abschnitt Odoo source auf der Dienstseite zeigt die Commits von Odoo und Odoo Enterprise, mit denen dein Odoo läuft, und wann sie jeweils committet wurden. Der Odoo-Commit verlinkt auf GitHub; das Repository von Odoo Enterprise ist privat, deshalb hat sein Commit keinen Link. Die Dienstliste hat dieselben Commits als Spalten Odoo commit und Odoo Enterprise commit, ausgeblendet, bis du sie einschaltest.

calmo.cloud liest die Commits jedes Mal aus dem Container, wenn er gestartet wird, und einmal am Tag. Sie ändern sich, sobald ein neueres Image live gegangen ist, nicht schon beim Pull. Solange der Container eines Dienstes noch nicht gelesen wurde, zeigt der Abschnitt Not known yet.

Zu einem anderen täglichen Image wechseln #

Das Image jedes Abends bleibt erhalten, und ein Dienst bietet dir die Images der letzten 60 Tage an, jedes mit dem Tag, an dem es gebaut wurde, und den Commits von Odoo und Odoo Enterprise, aus denen es entstanden ist. Angeboten werden nur Images, die gebaut wurden, seit calmo.cloud ihre Commits erfasst: ältere entstanden für einen früheren Stand der Plattform. Wähle eines in der Einstellung Odoo image am Dienst, um den Dienst darauf festzulegen, zum Beispiel um zum Odoo vom Vortag zurückzugehen, bis Odoo einen Fehler behoben hat.

Der Wechsel wird mit dem nächsten Redeploy wirksam: Nach dem Speichern zeigt die Seite den Hinweis Redeploy required, und View changes führt das Odoo image auf. Das Redeploy ruft das gewählte Image ab, während der Dienst noch läuft, und bringt es dann live. Mit der Redeploy-Strategie Automatic geschieht das von selbst. Lässt sich das Image weder abrufen noch auf dem Server finden, bricht das Redeploy ab, bevor es den Dienst herunterfährt, und der Dienst läuft mit seinem bisherigen Image weiter; automatische Redeploys versuchen dieses Image eine Stunde später erneut, oder sofort, sobald du ein anderes wählst.

Ein Dienst, der auf ein Image festgelegt ist, bleibt darauf: Automatische Pulls lassen ihn aus, und Pull Image lehnt ihn ab. Um zurückzuwechseln, leere die Einstellung Odoo image mit dem × neben dem gewählten Image, sodass sie Latest image zeigt, und speichere. Das nächste Redeploy ruft dann das neueste Image ab, und die Image-Pull-Strategie gilt wieder.

Wie nach einem Pull auf ein neueres Image kann die Dienstseite nach einem Wechsel um Upgrade all modules bitten (siehe Nach einem neueren Image). Gehst du zu einem älteren Image zurück, läuft älterer Odoo-Code auf einer Datenbank, die der neuere Code womöglich schon aktualisiert hat. Innerhalb einer Odoo-Version geht das meist gut; schlagen danach Seiten oder Berichte fehl, führe Upgrade all modules aus.

Kopien, Vorschauen und Agent-Kopien, die aus einem festgelegten Dienst entstehen, werden auf dasselbe Image festgelegt.

Nach einem neueren Image #

Hat ein Pull den Dienst auf einem neueren Odoo-Basis-Image neu gebaut, vermerkt die Timeline, dass ein neueres Odoo-Image gebaut wurde, und die Dienstseite zeigt Modules need an upgrade, ebenso der Module-Tab. Das neue Image bringt neuen Odoo-Code mit, deine Datenbank ist aber noch auf dem Stand, für den ihre Module zuletzt aktualisiert wurden. Sobald der Container neu erstellt wird, läuft der neue Code auf ihr, und wo er Änderungen an der Datenbank erwartet, können Seiten oder Berichte fehlschlagen, bis die Module nachgezogen sind.

Klicke in diesem Hinweis oder im Module-Tab auf Upgrade all modules. Odoo aktualisiert dann jedes installierte Modul, damit die Datenbank zum neuen Code passt, und das neue Image geht gleichzeitig live. Der Dienst steht still, während Odoo arbeitet, was bei einer großen Datenbank viele Minuten dauern kann, und ein Live-Dienst wird vorher gesichert. Siehe Alle Module aktualisieren.

calmo.cloud aktualisiert die Module nie von selbst, auch nicht nach einem automatischen Pull: Die Aktualisierung nimmt den Dienst vom Netz, deshalb entscheidest du, wann sie passiert. Ein Pull, der kein neueres Basis-Image gefunden hat, fügt keinen Hinweis hinzu, auch wenn er die Python-Pakete deiner Addons neu gebaut hat.

Der Hinweis erfasst nur Pulls, seit calmo.cloud neuere Images verfolgt. Ein Image, das davor gebaut wurde, eine Kopie und eine Datenbank, die auf ein neueres Image wiederhergestellt wurde, zeigen ihn nicht. Fehlt der Hinweis, heißt das also nicht, dass die Datenbank zum Code passt. Schlagen Seiten oder Berichte nach einem Image-Wechsel oder einer Wiederherstellung mit einem Fehler wie column … does not exist fehl, führe trotzdem Upgrade all modules aus.

Über die API und KI-Assistenten #

Die REST-API ruft das Image mit POST /api/service-odoo/{uuid}/pull-image ab, und ein KI-Assistent kann das ebenso. Der Dienst meldet danach modules_upgrade_due, das wahr ist, solange die Module einem neueren Image nachgezogen werden sollten, und odoo_commit_sha, odoo_commit_date, enterprise_commit_sha und enterprise_commit_date nennen die Commits, mit denen er läuft (null, solange sie nicht bekannt sind). Wie beim Hinweis gilt false nur für die Pulls, die calmo.cloud verfolgt hat; alle Module zu aktualisieren ist eine Moduloperation. Für den Pull braucht das API-Token die Berechtigung Start, stop and redeploy Odoo services. Bei einem Odoo, das ein anderes Team mit deinem teilt, braucht der Pull die Rolle Operator.

GET /api/service-odoo/{uuid}/odoo-images listet die täglichen Images, zu denen ein Dienst wechseln kann, jeweils mit den Commits von Odoo und Odoo Enterprise. Das Image, auf das der Dienst festgelegt ist, meldet er als odoo_image_tag, zum Beispiel 19.0-20261023, oder null für das neueste Image. Sende einen Tag aus dieser Liste als odoo_image_tag mit PATCH /api/service-odoo/{uuid}, um den Dienst festzulegen, oder null, um zurückzuwechseln; ein laufender Dienst wird sofort neu deployt. Ein KI-Assistent kann das ebenso. Für den Wechsel braucht das API-Token die Berechtigung Manage Odoo services.

Performance einstellen #

Im Bereich Performance legst du fest, wie viel von seinem Server ein Odoo nutzen darf. Hier stehen die Einstellungen, die am häufigsten angepasst werden:

Wie viel ein Dienst angeboten bekommt, hängt davon ab, was für ein Dienst er ist. Ein Live-System wird auf alles bemessen, was der Server noch übrig hat; ein Test- oder Demo-System auf etwa ein Drittel davon, eine Kopie, Vorschau oder Agent-Kopie auf ein Fünftel. Eine Testkopie, die so gross bemessen ist wie die Produktion, nähme den Platz weg, den die Produktion braucht, und das auf einem Server, der für die Produktion da ist. Ausserdem entscheidet so nicht mehr der zuerst angelegte Dienst darüber, wie viel für die übrigen bleibt. Das ist nur eine Obergrenze für die Empfehlung: Von Hand kannst du weiterhin jeden Wert setzen. Neue Kopien, Vorschauen und Agent-Kopien von Coding-Agents starten im Threaded-Modus mit eigenen, kleinen Einstellungen; Test- und Demo-Kopien starten mit der Empfehlung für ihren Server.

Auf einem Server mit aktiviertem Monitoring füllt Use recommended values den ganzen Bereich anhand der Hardware, die der Server meldet: ein Worker pro halbem Kern plus einer, zwei Cron-Threads und der Arbeitsspeicher, der für diesen Dienst tatsächlich übrig ist — nach dem Anteil des Betriebssystems, nach dem, was PostgreSQL reserviert, und nachdem die anderen Dienste auf demselben Server ihren Teil genommen haben. Auf einem kleinen Server werden dir womöglich weniger Worker angeboten, als die Kerne hergeben, weil ein Worker mit zu wenig Arbeitsspeicher mitten in einer Anfrage neu gestartet wird. Der Wert Database connections ist ein Anteil an dem Verbindungslimit, das das PostgreSQL des Servers annimmt.

Der Block oben im Bereich zeigt diese Aufteilung, sodass du siehst, was noch übrig ist, bevor du etwas erhöhst. Datenbank-Performance behandelt die andere Hälfte: wie das PostgreSQL des Servers bemessen wird und was passiert, wenn mehr versprochen wird, als die Maschine hat. Sieh die Empfehlung als Ausgangspunkt und beobachte danach die Server-Metriken.

Das sind ganz normale Odoo-Einstellungen. Sie landen in derselben Konfigurationsdatei wie alles Weitere unten und lassen sich daher auch über die API als Teil von extra_config setzen.

Der Bereich warnt dich und klappt sich von selbst auf, wenn seine Einstellungen Odoo am Laufen hindern würden: ein Wert, der keine ganze Zahl ist, oder eine Job-Queue, die so viele Jobs gleichzeitig ausführen darf, wie Odoo Worker hat, sodass kein Worker für die Leute bleibt, die Odoo benutzen. Warnungen verhindern das Speichern nie. Die API liefert dieselben Warnungen als config_warnings.

Odoo-Einstellungen konfigurieren #

Der Bereich Extra Configuration ermöglicht es dir, benutzerdefinierte Odoo-Konfigurationseinstellungen direkt zu deinem Dienst hinzuzufügen. Diese Einstellungen werden beim Start des Dienstes in die Odoo-Konfigurationsdatei (.odoorc) eingefügt.

Die Odoo-Konfigurationsdatei ist in Abschnitte unterteilt, und der Bereich Extra Configuration zeigt pro Abschnitt einen Block:

• Odoo options — die Einstellungen, die Odoo selbst liest, zum Beispiel workers oder limit_time_real. Das ist der Abschnitt [options] der Datei.
• Job queue — die Einstellungen, die das Modul queue_job liest, geschrieben in den Abschnitt [queue_job].
• Other section — jeder andere Abschnitt, den ein Modul erwartet, benannt von dir.

Konfiguration hinzufügen #

1. Öffne den Dienst, den du konfigurieren möchtest
2. Klappe den Bereich Extra Configuration auf (standardmässig eingeklappt)
3. Klicke auf Add section und wähle den Block, den du brauchst
4. Fülle die Einstellungen aus
5. Speichere die Änderungen
6. Deploye den Dienst neu, damit die neuen Einstellungen wirksam werden: Öffne Dienst und klicke auf Redeploy Service. Mit der Redeploy-Strategie Automatic geschieht das von selbst.

Häufige Einstellungen #

Die Einstellungen unter Performance haben eigene Felder; die folgenden gibst du als Zeilen ein.

Die Job-Queue betreiben #

Odoos Modul queue_job führt lange Aufgaben im Hintergrund aus. Dafür braucht es drei Dinge:

1. Das Modul muss verfügbar sein — füge das Repository, das es bereitstellt, unter Addons hinzu — und in der Datenbank installiert sein.
2. Trage es in Odoo options in server_wide_modules ein, zum Beispiel base,web,queue_job. Setze unter Performance die Workers auf mindestens 2: Der Job-Runner braucht einen eigenen Worker und würde bei nur einem Worker diesen einzigen belegen.
3. Setze im Block Job queue die Channels auf die Anzahl der Jobs, die gleichzeitig laufen dürfen, zum Beispiel root:2, und den Host auf localhost. Halte die Channels unter der Anzahl der Worker. Die Hälfte der Worker ist ein guter Anfang. Use recommended values unter Performance senkt die Channels, wenn die neue Worker-Anzahl sie nicht tragen könnte.

root:0 schaltet den Job-Runner ab, ohne die Konfiguration zu entfernen.

Der Block Job queue zeigt die Warnung Queued jobs cannot run, wenn etwas fehlt: queue_job steht nicht in server_wide_modules, das Modul ist nicht in der synchronisierten Modulliste, oder es ist nicht in der Datenbank installiert. Installiere es im Tab Modules.

Einstellungen über die API konfigurieren #

Die API schreibt dieselben Einstellungen als eine Map, in der ein Schlüssel den Abschnitt trägt, zu dem er gehört:

{
  "extra_config": {
    "workers": "4",
    "server_wide_modules": "base,web,queue_job",
    "queue_job.channels": "root:2",
    "queue_job.host": "localhost"
  }
}

Ein Schlüssel ohne Präfix gehört zum Abschnitt [options]. Wer extra_config sendet, ersetzt die gesamte Map, und ein laufender Dienst wird neu deployt, wenn sich die Einstellungen ändern.

Logs ansehen #

Du kannst die Odoo-Logs direkt von der Dienstseite aus live verfolgen und ältere Einträge nachlesen. Dies ist nützlich zum Debuggen von Problemen, Überwachen des Startverhaltens oder Beobachten der Anfragenaktivität.

Logs anzeigen #

1. Öffne einen laufenden Dienst
2. Klicke auf den View Logs-Button in der Kopfzeile
3. Ein Seitenpanel öffnet sich mit den letzten 100 Zeilen und streamt weiter neue

Logs werden bis zu 5 Minuten pro Sitzung live gestreamt. Du kannst das Panel schliessen und jederzeit wieder öffnen, um eine neue Sitzung zu starten.

Die Logs lesen #

• Log activity zeigt die geladenen Zeilen im Zeitverlauf als Diagramm, nach Level eingefärbt. Klicke auf einen Balken, um nur die Zeilen aus diesem Moment anzuzeigen.
• Die Buttons Error, Warning, Info und Debug filtern die Zeilen nach Level. Fehler sind rot, Warnungen gelb.
• Find in logs durchsucht die geladenen Zeilen und hebt die Treffer hervor.
• Wrap lines bricht lange Zeilen wie Tracebacks um, statt seitlich zu scrollen.
• Scrolle nach oben, um ältere Zeilen nachzuladen, jeweils 1.000 auf einmal, bis zu den ältesten Einträgen, die der Server noch aufbewahrt.
• Kopiere oder lade die sichtbaren Zeilen herunter, oder wechsle in den Vollbildmodus.

Der Viewer merkt sich deine Einstellungen für Farbe, Filter und Mitlaufen in deinem Browser.

Log-Verlauf #

Der Server bewahrt nur eine begrenzte Menge an Logs auf. Mit dem Log-Verlauf werden die Logs jedes Odoo auf einem Server zusätzlich an den Log-Speicher von calmo.cloud gesendet, sodass ältere Logs lesbar bleiben, nachdem der Server sie rotiert hat. Öffne die Einstellungen des Servers, wähle den Tab Log history und schalte Keep log history ein. Du kannst es jederzeit wieder ausschalten. Provisionierungsvorlagen haben denselben Schalter, sodass neue Server ihren Log-Verlauf von Anfang an behalten.

Der Log-Viewer jedes Odoo auf diesem Server bekommt dann neben Live eine Zeitraumauswahl: die letzte Stunde, 24 Stunden, 3, 7 oder 30 Tage oder einen Custom-Zeitraum. Das Aktivitätsdiagramm deckt dann den ganzen Zeitraum ab, und du kannst über seine Balken ziehen, um hineinzuzoomen. Back to live bringt dich zurück zum Stream.

Wie lange Logs aufbewahrt werden, hängt vom Plan des Teams ab, das das Odoo hostet:

Logs eines gelöschten Odoo werden mit ihm gelöscht.

Web-Terminal #

Der Tab Terminal eines laufenden Dienstes öffnet ein Terminal in deinem Browser. Wähle, was geöffnet werden soll:

Jede Sitzung öffnet sich in einem eigenen Tab, und New session öffnet eine weitere, bis zu fünf gleichzeitig. Beim Start zeigt jede Sitzung den Dienst, seine Odoo-Version und seine Datenbank.

In der Shell gilt:

• odoo shell braucht keine zusätzlichen Optionen. Es startet ohne Webserver und ohne Cron-Worker und konkurriert daher nicht mit dem laufenden Odoo.
• calmo-storage zeigt die Grösse der Datenbank, des Filestores und des Datenverzeichnisses, die fünf grössten Tabellen und wie viel Speicherplatz noch frei ist.
• Dateien ausserhalb von /home/odoo/data werden zurückgesetzt, wenn der Dienst neu deployt wird.

In der Odoo shell werden Änderungen zurückgerollt, es sei denn, du rufst env.cr.commit() auf. Verlasse sie mit Strg+D. Zeichen, die du auf dem Mac mit Option oder anderswo mit AltGr tippst, etwa \, | oder @ auf einer deutschen Tastatur, kommen im Terminal so an, wie du sie getippt hast.

Eine Sitzung schliesst sich nach 10 Minuten ohne Eingabe und spätestens nach einer Stunde. Klicke auf Reconnect, um sie neu zu starten. Leute aus einem Team, mit dem der Dienst geteilt ist, brauchen die Rolle Developer, um das Terminal zu öffnen.

Aktionen anzeigen #

Jede auf einem Dienst durchgeführte Operation wird im Aktionen-Tab protokolliert. Jede Aktion zeigt:

• Die durchgeführte Operation
• Ob sie erfolgreich war oder fehlgeschlagen ist
• Wann sie ausgeführt wurde
• Detaillierte Ausgabe (zur Fehlerbehebung)

Dies gibt dir ein vollständiges Protokoll von allem, was mit einem Dienst passiert ist.

Webhooks #

Jeder Dienst hat ein einzigartiges Webhook-Token, das es externen Systemen ermöglicht, Benachrichtigungen an calmo.cloud zu senden. Dies wird verwendet für:

• Synchronisierung der Liste installierter Module
• Verfolgung von Modul-Upgrades
• Integration mit CI/CD-Pipelines