Bestehenden Stack übernehmen

Übersicht

Läuft auf Ihrem Server bereits eine WORKSPACE.PM-2.x-Installation, die nicht mit wsp eingerichtet wurde, stellt wsp adopt sie unter dessen Verwaltung. Danach stehen Update, Sicherung, Wiederherstellung und alle übrigen Kommandos zur Verfügung. Kein Dienst wird dabei angefasst: Die Übernahme ist reine Buchhaltung, Ihre Anwendung läuft ohne Unterbrechung weiter.

Voraussetzungen

Der Server ist im Swarm-Betrieb und der Stack läuft
Die bisherige zentrale Konfigurationsdatei ist vorhanden und lesbar, voreingestellt /opt/workspace-2/deployment/.env
Ihr Lizenzschlüssel liegt vor, als .license-Datei oder als Zeichenkette
Auf diesem Server läuft noch keine von wsp verwaltete Installation

Es gibt genau eine Übernahme je Server. Ein zweiter Versuch bricht ab.

Schritt-für-Schritt-Anleitung

Über die Oberfläche übernehmen
```
sudo wsp
```
- Bestehenden Stack übernehmen wählen
Oder ohne Oberfläche
```
sudo wsp --headless adopt \
  --env-file /opt/workspace-2/deployment/.env \
  --license-file /root/tenant.license \
  --version 2.6.1
```
- Ist die laufende Version bekannt, geben Sie sie an: wsp kann das nächste Update dann in Stufen fahren
- Bleibt die Angabe leer, springt das nächste Update direkt auf die neueste freigegebene Version
Den Ablauf nachvollziehen
- Bestand erkennen: Swarm, Stack, Dienste, Ablagen und die bisherige Konfiguration werden gelesen
- Geheimniswerte übernehmen: die bestehenden Werte werden als einzelne Dateien unter /etc/wsp/secrets/ abgelegt
- Konfiguration schreiben: /etc/wsp/env entsteht aus den bisherigen Werten, zugleich die Kennung dieser Instanz
- Datenablagen vermerken: die tatsächlichen Namen werden aufgeschrieben, nichts angelegt und nichts gelöscht
- Zustand schreiben: ab jetzt gilt der Server als von wsp verwaltet
Die Prüfliste danach abarbeiten
```
sudo wsp status
sudo wsp doctor
sudo wsp backup
```
- Lizenzschlüssel prüfen und gegebenenfalls in /etc/wsp/env als LICENSE_KEY=… nachtragen
- /etc/wsp auslagern
- Die bisherigen Skripte nicht mehr verwenden; sie erkennen die Übernahme und verweigern die Arbeit

Warum die Geheimnisse übernommen und nicht neu erzeugt werden

Ein neu erzeugtes Datenbankpasswort würde die laufende Datenbank aussperren, ein neuer Signaturschlüssel alle angemeldeten Nutzer hinauswerfen, ein neuer Verschlüsselungsschlüssel bereits verschlüsselte Daten unlesbar machen. Deshalb werden die bestehenden Werte unverändert übernommen. Fehlt einer davon, bricht die Übernahme mit einer Aufzählung ab - lieber ein sauberer Abbruch als eine ausgesperrte Instanz.

Ebenso behalten Datenablagen ihre alten Namen. Sie umzubenennen hieße, Daten zu kopieren, mit Ausfallzeit und Risiko.

Häufige Fehler und Tipps

Hinweis: Nach der Übernahme lesen die Dienste noch ihre alten Werte.
- Erst das nächste reguläre Update stellt sie rollierend auf Datei-Geheimnisse um, ohne Ausfall. Bis dahin weisen wsp status und wsp doctor darauf hin. Das ist ein Hinweis, kein Fehler.
Hinweis: Erfinden Sie keine fehlenden Geheimniswerte.
- Falsche Werte sperren die Instanz aus. Suchen Sie die genannten Werte in der alten Konfiguration.
Hinweis: Ohne Lizenzschlüssel kommt das nächste Update nicht an die Abbilder.
- Wurde keiner angegeben und stand auch keiner in der alten Konfiguration, sagt wsp das ausdrücklich.
Hinweis: Die Übernahme setzt den Stack-Namen wsp voraus.
- Heißt der laufende Stack anders, wenden Sie sich an den Support.
Tipp: Läuft der Stack gar nicht als Swarm, gehört hierher wsp install.
- docker info zeigt den Betriebsmodus.

Wie stelle ich einen bestehenden Stack unter die Verwaltung von wsp?