RancherOS wurde abgekündigt und was nun?

Migration2021 13. Juli 2021

Image by dlohner from Pixabay

Ok, dann hole ich erstmal ein wenig aus. RancherOS war vor langer Zeit ein Betriebssystem von den Machern von Rancher. Mit Rancher kann und konnte man leicht eine Infrastruktur organisieren und managen. Früher ging das mit Docker Swarm und dann kam der Wechsel auf Kubernetes. Zu dieser Zeit kam auch RancherOS heraus und das wurde damals von mir auf meinem Servern installiert. Es war leichtgewichtig und gut supportet.

Seit einiger Zeit kamen aber weniger Updates und dann habe ich den folgenden Beitrag von April 2020 gefunden:

RancherOS 1.x is currently in a maintain-only-as-essential mode. It is no longer being actively maintained at a code level other than addressing critical or security fixes. For more information about the support status of RancherOS, see this page

Puh, habe ich also ein Jahr lang die Info verschlafen und habe ein System benutzt, was nicht unbedingt geupdatet wird. Das ist immer schlecht und daher muss ich nun das Betriebssystem wechseln. Ich möchte von RancherOS zu Ubuntu und von Docker Swarm zu Kubernetes.

Aber erstmal der Reihe nach. Welche Herausforderungen habe ich?

Herausforderungen und Vorgehen

Naja, da sind schon ein paar: Ingesamt habe ich 10 Docker Stacks.

  • AppWrite mit 2 Backends
  • Nextcloud mit gut 60GB an Daten
  • Ghost mit gut 20 Beiträgen
  • Ghost für das Testen
  • Gitlab mit gut 20 Repos
  • Monitoring (Grafana, Prometheus etc.)
  • eigenes Projekt
  • Portainer mit diesen 10 Stacks
  • Gitlab Runner
  • Traefik

Alle Stacks müssen umgezogen werden und die Docker Compose muss zu einen Kubernetes Deployment werden.

Ich denke, so werde ich auch die Beiträge aufbauen:

  • Daten sichern und auf einem Computer/Server zwischenspeichern
  • Server mit neuem Betriebssystem versehen und absichern
  • Rancher installieren und die Installation von Kubernetes auf dem eigenen Server ausprobieren
    oder doch wieder zurück auf Portainer mit Docker Stacks
  • erste Stacks deployen
  • diesen Beitrag im eigenen Ghost veröffentlichen
  • die nächsten Stacks deployen und dabei die Daten migrieren

Damit dieser Beitrag noch ein wenig Inhalt bekommt, fange ich direkt an …

Daten sichern und auf einem Server/Computer zwischenspeichern

Docker Stacks sichern

Klar, bevor ich so richtig loslegen kann, muss ich erstmal den Stand sichern. Die Docker Stacks habe ich schon mal in Dateien auf dem heimischen Laptop gespeichert. Dafür habe ich kein besonderen Shortcut genutzt: Nur einfaches Copy, Datei in Visual Studio Code anlegen und Paste. Am Ende die Datei noch speichern, aber das ist ja klar.

An sich könnte man die Stacks jetzt noch in eine Versionsverwaltung legen.

Da müsste ich aber bedenken, das dort Klartext Passwörter vorhanden sind und diese nichts in einem Git zu suchen haben. Ach, das bleibt einfach lokal und wird dann ja bald in Kubernetes Secrets überführt.

Daten sichern

Was das anbetrifft bin ich etwas oldschool unterwegs. Klar, man könnte nun RSync oder so nehmen und damit die Dateien irgendwo hinspeichern, oder einen Cloud Speicher wie S3 oder Google Drive für die Sicherung anbinden, aber das alles kostet etwas Zeit und so nehme ich die Tools, die ich kenne: TAR Archiv und SCP.

Ich habe das Glück, das ich immer schon alle Applikationsdaten in einem bestimmten Ordner gespeichert hatte. So muss ich nur diesen Ordner als Archiv verpacken und dann per SCP auf den heimischen Laptop oder Server speichern. Für das Letztere würde ich dann SCP nehmen.

Nun muss aber erstmal das TAR Archiv erstellt werden. Der Ordner ist riesig und so kann der folgende Befehl lange dauern:

sudo tar -zcvf backup.tar.gz ordner

Wenn etwas lange dauert, gibt es eine Grundregel: Bedenke wie lange deine Session hält und ob sie nicht zwischendurch beendet werden kann… und das ist immer blöd. Da ich bei sowas immer unsicher bin, installiere ich lieber ein Helferlein. In diesem Falle installieren ich screen.

Danach wird schnell eine Screen Session mit screen erstellt und der obige Befehl abgeschickt. Wenn nun meine Command Line Session unterbrochen wird, kann ich mich jederzeit wieder auf den Server verbinden und screen -r eingeben. Der Befehl oben hat glaube bei mir 2h gebraucht.

Nun habe ich also ein TAR Archiv und kann das verschieben. Dazu nutzt man SCP aka Secure Shell Copy. Sprich, wir kopieren nun die Datei via SSH Shell. Da ich eine normale Internetverbindung mit 50mbit habe, könnte der Download noch moderat dauern. Das Hochladen auf einen anderen, bzw. auf den gleichen Server, der dann ein neues Betriebssystem hat, könnte aber ewig dauern. Und so komme ich zu meinem 2. Glücksfall: Ich habe beim gleichen Hostinganbieter einen zweiten Server mit ausreichend Speicher und so werde ich die Datei zwischen zwei Servern verschieben und meine Internetleitung muss nicht darunter leiden.

Server1 (mit RancherOS) <——> Server2 (mit Ubuntu)

Auf Server2 muss ich jetzt also ein Schlüsselpaar erstellen und den öffentlichen Schlüssel auf Server1 in der authorizedkeys Datei hinterlegen. Danach kann ich mich dann via SSH von Server2 auf Server1 verbinden. Genau diese Verbindung wird dann auch mit SCP funktionieren.

Server2

ssh-keygen # und alle Fragen bestätigen

Ihr findet nun im Homeverzeichnis im Ordner .ssh ein Schlüsselpaar

pwd
# /home/user/.ssh
ls -al
# total 20
# drwx------ 2 user user 4096 Jun 27 12:47 .
# drwxr-xr-x 6 user user 4096 May 30 19:23 ..
# -rw------- 1 user user  576 May 19 17:34 authorized_keys
# -rw------- 1 user user 2622 Jun 27 12:47 id_rsa
# -rw-r--r-- 1 user user  584 Jun 27 12:47 id_rsa.pub
cat id_rsa.pub

Bei einen Schlüsselpaar gibt es immer den privaten und den öffentlichen Teil. Den öffentlichen Teil dürft ihr theoretisch überall sagen und posten. Na klar, er ist ja auch öffentlich. Der private Teil sollte aber auch immer privat und geheim bleiben. Der Schüssel sollte also niemals in einer Versionsverwaltung, in Foren, in Chats oder sonstwo hinterlegt und geschrieben werden. Behandelt den privaten Schlüssel einfach wie einen PIN von eurer Bankkarte. Und nein, den PIN schreibt man auch nirgends hin…

Nun habe ich also das Paar und nutze nun den öffentlichen Teil (id_rsa.pub) und kopiere diesen auf Server1 in die authorizedkeys Datei. Damit mache ich quasi dem Server1 bekannt, das da ein anderer Server mit einen privaten Schlüssel anfragen darf.

Server2

pwd
# /home/user/.ssh
cat id_rsa.pub
ssh-rsa AAAA*************** user@server2

Server1

pwd
# /home/user/.ssh
cat authorized_keys
# ssh-rsa AAAA*************** user1@serverBla
# ssh-rsa AAAA*************** user2@serverX
# ssh-rsa AAAA*************** user3@home
# ...
vi authorized_keys
# nun gehe ich zur letzten Zeile, springe zum Ende, drücke die <i> Taste zum einfügen, füge eine neue Zeile ein und füge den Inhalt von id_rsa.pub ein
# nun drücke ich die <ESC> Taste und drücke die folgende Kombination <:wq> 
cat authorized_keys
# ssh-rsa AAAA*************** user1@serverBla
# ssh-rsa AAAA*************** user2@serverX
# ssh-rsa AAAA*************** user3@home
# ...
# ssh-rsa AAAA*************** user@server2

Server2

Nun kann ich via ssh die Verbindung probieren und validieren.

ssh user@serverip # Wenn der Login funktioniert, sollte ich mich wieder ausloggen
exit

Wenn der Login funktioniert hat, kann ich nun auch hier eine Screen Session eröffnen und den folgenden Befehl ausführen:

scp user@server1:/home/user/backup.tar.gz .

Und nun heißt es wieder warten…. und darüber nachdenken, ob noch irgendwo Dinge gesichert werden müssen.

backup.tar.gz                              24%   15GB 101.2MB/s   07:45 ETA

Damit wäre der heutige Teil erstmal geschafft. Ich habe die Daten gesichert und diese auf einem anderen Server abgespeichert. Im nächsten Beitrag werde ich zeigen, wie ich bei Netcup, meinem Hosting Anbieter, ein neues Betriebssystem (Ubuntu) auf dem RancherOS Server installiere, absichere und dann Richtung Kubernetes mit Rancher schaue. Hier darf dann aber Rancher nicht mit RancherOS verwechselt werden. Letzteres wird nicht mehr supportet und ersteres geht total steil.

Tags

Tim Friedrich

Hausherr des Blogs, - an mir kommst du hier nicht vorbei! Daher ein fröhliches Hallo und herzliches Willkommen im Blog.

Großartig! Das Abonnement wurde erfolgreich abgeschlossen.
Großartig! Schließen Sie als Nächstes die Kaufabwicklung ab, um vollen Zugriff zu erhalten.
Willkommen zurück! Sie haben sich erfolgreich angemeldet.
Erfolg! Ihr Konto ist vollständig aktiviert, Sie haben jetzt Zugang zu allen Inhalten.