Ihren Stack zu Opfield umziehen

Diese Anleitung zieht einen bestehenden Stack zu Opfield um: Server, Zugriff, Ingress, Workloads, Datenbanken mit Backups und Monitoring. Jeder Schritt endet mit einer Prüfung. Die Ebenen ziehen unabhängig voneinander um, sodass Sie einen Dienst vollständig oder eine Ebene für alle Dienste auf einmal umziehen können. Kurze Antworten auf Fragen vor dem Kauf finden Sie unter Opfield bewerten.

1. Opfield installieren und Ihre Server verbinden

1. Installieren Sie Opfield und schließen Sie die Ersteinrichtung ab: Administrator, MFA, öffentliche URL.
2. Fügen Sie jeden Server unter Nodes > Add Node mit seinem einzeiligen Befehl hinzu oder erstellen Sie neue Server über eine Integration mit einem Hosting-Anbieter. Geben Sie jedem Node die Rollen, die er braucht: Ingress, Docker, Storage, Build Worker, Monitoring.
3. Betreiben Sie für die Produktion mindestens zwei Relays auf anderen Hosts als dem Opfield-Host.
4. Stellen Sie das Wiederherstellungsset der Control Plane zusammen und bewahren Sie den Master-Schlüssel getrennt von den Datenbank-Backups auf.

Prüfung: Jeder Node ist mit seinen Rollen online. Container und Compose-Projekte, die bereits auf Docker Nodes laufen, erscheinen ohne Import unter Docker.

2. Zugriff einrichten

Legen Sie Gruppen entlang der Aufgabenbereiche an, verbinden Sie Ihren SSO-Anbieter, falls vorhanden, und laden Sie das Team ein. Geben Sie jeder Gruppe Zugriff auf die Routen, Workloads, Datenbanken und Nodes, mit denen sie arbeitet, bis hinunter zu einer einzelnen Ressource. Siehe Berechtigungen.

Prüfung: Ein Operator ohne Administratorrechte schließt eine normale Änderung ab und wird außerhalb seiner Berechtigungen abgewiesen; beides erscheint im Audit-Log.

3. Ingress umziehen

Für jeden Hostnamen:

1. Erstellen Sie die Domain und eine Route zur Anwendung. Eine Anwendung auf einem Docker Node wird über einen Secure Link erreicht, ohne veröffentlichten Port.
2. Stellen Sie ein Let’s-Encrypt-Zertifikat über HTTP-01 oder DNS-01 aus oder laden Sie das vorhandene hoch. HTTP-01 erfordert, dass der Ingress Node auf Port 80 erreichbar ist; DNS-01 funktioniert über die Cloudflare-Integration, noch bevor DNS umzieht.
3. Fügen Sie Access Lists und eine Wartungsseite hinzu, wo der alte Proxy sie hatte.
4. Richten Sie DNS auf den Ingress Node aus.

Siehe Domains, Routen und TLS.

Prüfung: Eine echte HTTPS-Anfrage über die Domain erreicht die Anwendung. Entfernen Sie danach den Host aus dem alten Proxy und sein Zertifikat aus dem Cron-Job zur Verlängerung.

4. Workloads umziehen

• Eigenständige Container sind bereits auf ihrem Docker Node aufgeführt. Vergeben Sie Zugriff darauf und lesen Sie sofort ihre Logs.
• Compose-Projekte: Übernehmen Sie das Projekt (Personal und höher). Ersetzen Sie env_file durch environment: und Opfield-Variablen, verlagern Sie Host-Bind-Mounts in das Image oder ein benanntes Volume und behalten Sie die Volume-Schlüssel bei: Benannte Volumes behalten ihre Namen und Daten. Das erste Anwenden erstellt die Dienstcontainer neu, planen Sie es also wie jedes erneute Deployment ein.
• Dienste, die Sie häufig veröffentlichen: Betreiben Sie sie als Deployments mit Slot-Umschaltung und Rollback, gebaut aus Git auf einem Build Worker (Business und höher).
• Dienste, die einen Serverausfall überstehen müssen: Aktivieren Sie Docker Availability (Business und höher), damit sie auf einen anderen Node wechseln, wenn einer ausfällt.
• Umzug zwischen Servern: Migrieren Sie einen eigenständigen Container samt seinen Volume-Daten auf einen anderen Node.

Prüfung: Der Workload ist fehlerfrei, seine Route antwortet, und ein Release sowie ein Rollback werden über Opfield abgeschlossen.

5. Datenbanken und Backups umziehen

1. Registrieren Sie jede bestehende Datenbank als externe Verbindung. Sie erhält sofort Health Checks, Metriken, Explorer, Konsole und geplante Backups.
2. Um sie in eine verwaltete Datenbank zu überführen, stoppen Sie Schreibzugriffe, führen ein Backup aus und stellen es über die Konsole wieder her. Die Wiederherstellung erstellt eine neue verwaltete Datenbank auf einem Storage Node und überschreibt niemals die Quelle.
3. Verbinden Sie die Anwendung über ein privates Binding. Die Anwendung erhält ihre eigene Datenbankidentität und keinen offenen Port.
4. Für automatisches Failover betreiben Sie die Datenbank auf mehreren Servern (Business und höher).
5. Planen Sie Backups nach S3, FTP, FTPS oder SFTP.

Prüfung: Die Anwendung funktioniert über das Binding, und eine Wiederherstellung des neuesten Backups in eine neue Datenbank gelingt.

6. Monitoring, Alarme und Status umziehen

Zustand und Metriken der Nodes kommen ab der Registrierung an, und die Logs von Containern und Routen befinden sich bei den Ressourcen, zu denen sie gehören. Fügen Sie Alarmregeln und Benachrichtigungskanäle für das hinzu, worüber das Team informiert werden muss, und veröffentlichen Sie eine Statusseite mit Komponenten für die öffentlichen Dienste. Siehe Observability.

Prüfung: Ein Testalarm erreicht seinen Kanal, und die Statusseite zeigt jede öffentliche Komponente. Schalten Sie danach die alten Dashboards, Alarmierungen und Uptime-Prüfungen für die umgezogenen Dienste ab.

7. Die alten Werkzeuge außer Betrieb nehmen

Geben Sie jeder Ressource einen Eigentümer: Entfernen Sie umgezogene Ressourcen aus den alten Proxy-Konfigurationen, Skripten, Panels und Cron-Jobs, damit nichts überschreibt, was jetzt Opfield gehört. Schließen Sie die Verwaltungsports und Panels, die Opfield überflüssig gemacht hat; Nodes verbinden sich ausgehend.

Für jeden Dienst festhalten

• wem er gehört und welche Gruppe ihn betreibt;
• das Ergebnis eines Releases und eines Rollbacks;
• das Ergebnis einer Backup-Wiederherstellung;
• den Alarmkanal und die Komponente auf der Statusseite.

Hilfe beim Umzug

Business enthält Guided Onboarding and Configuration Review und Enterprise enthält Assisted Deployment and Migration als Tarifleistungen; die kommerzielle Vereinbarung legt ihren Umfang fest. Für Hilfe in einem anderen Tarif wenden Sie sich an [email protected].