Best Practice bei Serverumzug

Moin,

du schreibst als letzten Punkt "Hobby Setup".
Also ist Downtime schon mal relativ egal

Wie migriere ich zwischen meinen Servern?

Ich mach immer eine Full Fresh Installation und lass Ansible den Server einrichten.

Da bei mir alles Dockerized läuft übertrage ich danach die Docker Daten. Entweder via Copy Job oder indem ich mein Borgbackup auf den neuen Server runterlade.

Dann nutze ich mittlerweile Pangolin. Das heißt ich stelle im Pangolin einfach die neue Adresse ein. IP nach extern ändert sich nicht.

Vorher habe ich die TTL in der Zone auf 300 gestellt und dann die (Sub)Domain auf die neue IP umgestellt und (leicht ungeduldig) gewartet bis das endlich umgestellt wurde.
Dann einmal die Container wieder starten und go.

Aber mir ist der FullFresh vom Server wichtig. Ich will da keine "Altlasten" haben weil ich schon mehrfach das OS und die Configs migriert habe.

Das kommt drauf an

Ich hab einige Systeme mit dem Snapshot/Snapshot-Export umgezogen, hier hast du nur das Thema IP-Adresse lokal (wenn du dhcp durch statische Konfig ersetzt hast) und im DNS. Geht nur, wenn wenn die neue Platte nicht kleiner ist.

Bei fehlenden Snapshots exports geht dass auch mit dd via ssh jeweils im Rettungssystem, ist gefühlt für die Gesamt-Prozedure gar nicht so viel langsamer, aber mehr zu tun.

gparted im Rettungssystem hilft auch, die neue Platte, evtl. größere Platte gleich sinnvoll zu nutzen und den Platz zu verteilen.

Dann bist du in der Regel schon fertig.

Ein paar Systeme habe ich auch neu installiert, weil Alma 8 auf Alma 10 keinen sinnvollen Upgrade-Pfad bietet. Neue Installation, Dienste migieren und Daten syncen, das dauert üblicherweise länger. Da ich mittlerweile viele kleine Systeme für einzelne Aufgabe habe, kann das aber auch das relativ schnell gehen.

Ich migriere oft via Image per Clonezilla, für einen Neubau bin ich meistens zu faul. 🙃

Das hat sich bist jetzt immer bewährt, einzig bei einem Umzug auf eine kleinere Platte muss man etwas Vorarbeit leisten und Partitionen verkleinern. Dann muss man nur noch IPs anpassen und den DNS umhängen. Dafür habe ich vorher immer eine kleine TTL eingestellt, damit der Schwenk nicht ewig dauert.

Nachteil dieser Methode: Man benötigt irgendwo genug Speicher um das Image zwischenzulagern, der irgendwie über das Internet erreichbar sein muss. Bei mir ist es z.B. eine Speicherkiste beim roten H. Und man hat auf jeden Fall eine Downtime, was bei mir in der Regel aber recht egal ist.

Zitat von fvbor

Moin,

du schreibst als letzten Punkt "Hobby Setup".
Also ist Downtime schon mal relativ egal

Ich finde den Anspruch, auch die Hobby Setups mit minimaler Downtime umzuziehen, erst mal ziemlich gut.

Ich erstelle ein Backup mit Veeam for Linux. Auf dem neuen Server wird das Backup wieder eingespielt, IP Adressen ändern, fertig.

Zitat von daq4th

Ich finde den Anspruch, auch die Hobby Setups mit minimaler Downtime umzuziehen, erst mal ziemlich gut.

Zitat von duck

Das ist der Anspruch an mich selbst, auch bei einem Hobby Setup die Downtime so minimal wie möglich zu halten, damit das Ganze schnell wieder am laufen ist.

Ist es auch!

Aber ich hab mir in der Vergangenheit wegen diesem Anspruch Migrationen auch schon unnötig kompliziert gemacht

Im Hobbyumfeld ist eine Downtime nicht so tragisch wie im Gewerblichen Umfeld. Wenn die Private Cloud mal eine halbe Stunde mitten am Tag nicht Verfügbar ist motzt "nur" die Familie und nicht 400 Leute im Unternehmen.

Zitat von duck

Ansible kann ich dann dazu nutzen automatisiert die Grundkonfiguration des Servers vorzunehmen?

Z.B. Fail2Ban, unattented Updates, Docker-Dienst, rstric Einrichtung usw, richtig?

Ansible kann sehr viel Konfigurieren.

Ich hab mein Playbook welches die ganze Grundinstallationen durchführt und meinen Serverzoo mit Updates versorgt.

Aber hab auch noch so die Sachen die ich bei der frischen Installation erst einmal händisch konfiguriere. Ja, könnte man automatisieren, war ich aber zu Faul zu

Ich kann es wirklich empfehlen sich damit einmal auseinander zu setzen.

Im Sinne von Infrasturcture as Code

Ich nutze neue Server dazu, Debian von einer früheren Version auf die aktuelle Version abzudaten (11 -> 13 bzw. 12 -> 13 bei meinen beiden). Ansonsten lasse ich alles über Docker laufen und ziehe in erster Linie die Docker Compose Files rüber, mache mir dabei Gedanken, ob ich noch alles benötige und verbessere dabei an vielen Stellen (z.B. Healthchecks bei allen Containern, Modernisierung von App Komponenten z.B. Postgres 15.2 -> 17, dank Claude Code sogar wenns das Original Compose File eigentlich gar nicht vorsieht).

Ansible o. ä. hat natürlich den Vorteil, daß das Aufsetzen des Servers "auf Knopfdruck" jederzeit wiederholbar ist und man dann ein sauberes System ohne Altlasten (inkl. möglicher Schadsoftware) hat. Außerdem kann man die Konfiguration in einem Git-Repository versionieren. Ein kleiner separater Server zum Testen von Konfigurationsänderungen wäre dabei sicher ganz praktisch. Ich selbst bin aber auch noch nicht so weit...

Was die DNS-Umstellung angeht, solltest Du den TTL-Wert schon einige Tage vor der Migration runtersetzen, damit die Umschaltung am Migrationstag schneller geht.

Zitat von duck

Playbook ist dann ein kleiner Server auf dem die Ansible Konfiguration läuft und Serverzoo dann deine produktiven Server?

Nein.
Ansible ist ein kleines Tool um Server zu verwalten.
Das alles ist hier, im Gegensatz zu Terraform, Stateless.

Terraform verwendest du für die Infrastruktur (Server Provisionieren, Netzwerke, Storages u.s.w.), Ansible für die Server (Config auf dem Server, Updates, Tools).

Das heißt: Terraform hat seine Statefile und weiß wie die Umgebung ist, Ansible hat sein Playbook und arbeitet das einfach ab.

Einfach gerade einmal kurz bisschen Background

Bei Ansible hast du auf deinem System - Bei mir ist es ein Ubuntu als WSL - wo Ansible drauf läuft.

Dort hast du deine Inventory (Hier sind deine Server eingetragen) und deine Playbooks. In einem Playbook steht dann sowas wie dieses hier:

- hosts: all
  become: true
  pre_tasks:

  - name: install updates
    tags: always
    apt:
      upgrade: dist
      update_cache: yes
    when: ansible_distribution == "Ubuntu"

Also bei welchen Host soll er was machen. Become: true bedeutet: Hier braucht er root rechte und fragt nach dem sudo Passwort.

Wenn du dann Ansbile startest connected er sich via SSH (Mit SSH Key) gegen die Server in der inventory.yml und führt das Playbook aus. Anbei mein Default Befehl. Wenn er das ganze Playbook ausführen soll mit Pakete installieren lass ich das -t always weg.

ansible-playbook --ask-become-pass -t always basic-installation.yml

Jetzt rattert Ansible einmal durch und guckt: Was habe ich im Playbook stehen? Das führt er aus. Updates installieren, Pakete installieren, Configs anpassen u.s.w.

Da gibt es viele Beispiele und viel Doku. Offizielle und YouTube und co.

Ist eine kleine Lernkurve, aber dafür hast du dann IaC. Jeder Server hat damit die Basisinstallation die er haben soll. Alle sind da gleich. (Außer natürlich du hast im Playbook und Inventory noch mal abgrenzungen, weil die Mailserver (Mailcow) jq noch als Paket benötigen.

- hosts: mail
  become: true
  tasks:
  
  - name: Mailcow Requirements (jq, git)
    tags: mail, prod, test
    apt:
      name:
        - jq
        - git
      state: latest
    when: ansible_distribution == "Ubuntu"

Doku:

https://docs.ansible.com/projects/ansible/latest/getting_started/index.html

Und ich meine ich hab es mal mit dieser Playlist hier bei mir eingerichtet. Zumindest habe ich die immer noch gespeichert

Zitat von duck

Ist Veeam für Linux nicht kostenpflichtig?

Gibt es auch kostenfreie Version.

Zitat von duck

TBT

Hast du dann auf deinem Servern nur Docker laufen oder auch noch weitere Software, die deinen Server absichern wie Fail2Ban oder nutzt du sowas nicht?

Nur Docker, SSH ist durch die NC Firewall zu und nur via Tailscale offen.

Zitat von duck

Also bedeutet das in deinem Fall, dass du beim Serverumzug das System einfach neu aufsetzt, anschließend Tailscale sowie Docker installierst und damit direkt wieder einen sauberen, frischen Stand hast? In der netcup-Firewall wären dann lediglich die Ports 80 und 443 freigegeben, beispielsweise für einen im Docker laufenden Caddy-Reverse-Proxy, und der restliche Zugriff erfolgt über Tailscale.

Jep. So in etwa. Wenn ich noch die Daten mitnehmen will, übertrage ich über SSH direkt zwischen alt und neu noch die Docker Volumes, bei meinen aktuell verwendeten Containern ist das nicht nötig. Ja, Port 80 und 443 sind freigegeben, ich verwende https://nginxproxymanager.com , weil ich mich damit schon immer am Besten anfreunden konnte (vs. Caddy, Traefik). Pangolin könnte jedoch den NPM ersetzen.

Und ja, der Zugriff auf die https://dockhand.pro/ Weboberfläche erfolgt ausschließlich über Tailscale, wie auch der Zugriff auf https://getwud.github.io/wud/#/ (automatische Docker Updates), beides braucht ja nicht ins Internet gelegt werden.

Es gibt noch einige weitere Anwendungen, die dann neben dem Webinterface eigene Ports brauchen, hierzu lege ich in der FW jeweils ein Profil an, das dann pro Server aktiv oder eben nicht aktiv geschaltet werden kann. Ich baue da für jede Anwendung ein Set aus allen Ports, TCP/UDP etc.

Zitat von duck

Nutzt du ausschließlich Docker-Volumes oder arbeitest du auch mit gemappten Host-Pfaden, in denen die Daten abgelegt werden?

Ich nutze zum Teil Docker Volumes (Nextcloud All in One), aber zum größtenteil habe ich folgende Ordnerstruktur

/opt/containers/
|-> sub.domain.tld (Wie der Service verfügbar ist)
    |-> compose.yml, .env und ggf. weitere Files
    |-> data
        |-> Hier liegen dann Die Daten des Containers und deren Datenbank und so weiter in weiteren Unterordnern

So habe ich alles, was einen Service betrifft, in einem Ordner.

Der wird auch via Borgbackup gesichert und kann in kürzester Zeit auf jedem Server wieder aufgebaut werden.

Da ich persönlich auf Pangolin setze muss ich keine Config in der Caddyfile oder in der compose.yml (wie z.B. bei der Verwendung von traefik) anpassen.

Falls Du tailscale nutzen willst, solltest Du den entsprechenden UDP-Port in der nc-Firewall freigeben. Siehe https://tailscale.com/docs/reference/faq/firewall-ports

Zu bedenken ist, daß man sich mit tailscale eine Abhängigkeit zu deren Control-Servern einhandelt. Das gilt es also abzuwägen.