So zumindest erscheint es mir immer mehr und vor allem immer wieder. Das bewusstsein, dass es sich dabei nur um "somebody else computer" handelt scheint weitestgehend zu verschwinden. Umso lustiger ist es dann für mich, wenn man mit den ganzen Fehlerhaften annahmen aufräumen kann. das heißt dann auch, dass man mal bei einem Outtake schauen kann, was da so los ist.
Heute ist so ein Denkwürdiger Tag. Die Amazon S3 Cloud hat Schluckauf und die darin genutztne mehr als 143,000 Webseiten ebenso.
Rechner von der Hardware zu virtuellen Maschinen umzufunktionieren ist ja mittlerweile eine ziemlich langweilige Aufgabe geworden. Wenn man das ganze allerdings anders herum probiert, dann braucht man zwar keine riesen Hilfsmittel, aber ein wenig Umdenken ist schon gefragt.
In diesem Beitrag beschreibe ich, kurz und knapp, wie man aus einem eine Festplatte über das Netzwerk auf eine andere (auch gern ein Imagefile) clont.
Genutzt wird dd. Mit Hilfe von dd kann man einen Datenstrom von Blockdevices abgreifen und zum Beispiel in einer Datei speichern. Da es auf diesem Weg funktioniert, funktioniert es auch im Netzwerk mit Hilfe von SSH ziemlich einfach.
Wir greifen einfach die Daten von der Festplatte/dem Image ab
dd if=/mnt/storage/vm1234.raw
und geben es mit einer Pipe an SSH weiter
| ssh root@111.222.333.444
wo wir es dann an die entgültige Stelle bewegen:
dd of=/dev/sda
Vollständig sieht das dann so aus:
dd if=/mnt/storage/vm1234.raw | ssh root@111.222.333.444 dd of=/dev/sda
Auf diesem Weg kann man dann ziemlich einfach die Daten einer Festplatte/eines Images durch das Netz an einen anderen Ort bewegen, um dort dann zum Beispiel seinen neuen Rechner in Betrieb zu nehmen.
Geholfen hat:
Das Ansible für mich der logische nächste schritt nach der Shell ist, sobald es um die Verwaltung von Servern geht, habe ich vielleicht hier und da schon mal durchblicken lassen. Der Hintergrund ist einfach:
Mit Ansible Playbooks habe ich als Systemverwalter die Möglichkeit meine Schritte in einfacher Art und Weise (fast schon stenografisch) nieder zuschreiben und so einen Ablauf zu skizzieren, welche Arbeiten/Schritte/Rahmenbedingungen auf dem von mir zu verwaltenden System durchgeführt/vorhanden sein sollen.
Ansible selbst kümmert sich dann um die Abstraktion zum System hin, auf dem ich dann letztendlich die Skizze ausführe.
Wenn ich nun eine gewachsene Landschaft mit unterschiedlichen Linux-Distributionen habe, kann Ansible mir helfen diese aktuell zu halten. Das einfache Playbook dazu sieht wie folgt aus:
--- - hosts: all:!switche:!windows user: root gather_facts: true tasks: - name: apt update action: apt update_cache=yes when: ansible_distribution == "Ubuntu" or ansible_distribution == "Debian" - name: apt upgrade action: apt upgrade=dist force=yes when: ansible_distribution == "Ubuntu" or ansible_distribution == "Debian" - name: yum upgrade action: yum name=* state=latest when: ansible_distribution == "CentOS" - name: dnf upgrade action: yum name=* state=latest when: ansible_distribution == "Fedora"
Wenn ich dieses Playbook nun auf meine Landschaft loslasse:
ansible-playbook playbooks/linux-upgrade.yml
spielt es keine Rolle mehr, ob die Eingesetzte Distribution ein Debian, Ubuntu, Fedora oder CentOS ist. Alle werden mit den eigenen Paketmanagern aktualisiert