Im ersten Teil habe ich die Installation einer LXD Umgebung beschrieben. Im zweiten Teil soll es um die weitere Konfiguration und den Umgang mit LXD Containern gehen:
Es gibt eine gute grundlegende Doku, ich will nur ein paar praktische Versuche dokumentieren.
aber diesmal mit viel mehr Tiefe. đ
Ich bin ein Fan von Virtualisierung, habe mich schon mit Containern (docker) beschÀftigt und habe irgendwann von LXC gelesen.
Ubuntu wirbt mit LXD, seit ein paar Monaten gibt es einen Fork von LXD mit dem Namen Incus. - was verbirgt sich dahinter? UrsprĂŒnglich wollte ich auf einem Host Libvirt und LXC parallel betreiben und die Möglichkeit fĂŒr Docker haben.
Ich meine, ich habe nach einigen Wochen lesen folgendes verstanden: Virtualisierung emuliert und isoliert Hardware und schafft eine Umgebung fĂŒr jedes OS, LXC schafft eine isolierte Linux System Umgebung, Docker schafft eine isolierte Linux Applikationsumgebung, LXD ist eine Verwaltungsumgebung fĂŒr LXC. Der Unterschied zwischen LXC und docker Container: fĂŒr den Anwender ist docker eine Black Box, die Applikation wird vom Entwickler gewartet und vom Anwender angewendet. LXC ist fĂŒr den Anwender ein "fertiges" Linux System in dem er seine Applikation installieren und es warten muss.
Was mich eine Weile verwirrt hat: FĂŒr LXC gibt es 2 (oder mehr?) Verwaltungssysteme: lxc-utils und LXD. Bei LXD heiĂt das fĂŒhrende Verwaltungskommando lxc. WĂ€hrend ich immer weiterlese, beschleicht mich das ungute GefĂŒhl, dass es alles Schnee von gestern wird, was ich hier aufschreibe.
In meinem Beitrag "Verbundene Netzwerke" hatte ich mit PiVPN begonnen.
PiVPN wird eventuell nicht mehr weiterentwickelt -> Zeit eine eigene, möglichst zeitlose Konfiguration zu beschreiben!
Die Idee: irgendwo im Internet (oder an einem Standort in der DMZ) befindet sich ein Einwahlknoten und alle Peers verbinden sich zu diesem Knoten. Es gibt zwei Sorten Peers:
Der Knoten ist möglichst isoliert. Die Peers mĂŒssen keine Port öffnen, am eigenen Netzwerk nichts verĂ€ndern.
Ausgangspunkt fĂŒr meine Beschreibung ist ein aktualisiertes, minimales Debian (Bookworm) System, 1-2 CPUs, 1-2GB RAM, 10-20 GB Disk, eine Netzwerkkarte, Internet Zugang. Wahrscheinlich braucht man noch weniger (Container). Kein Desktop, kein Gnome, nur sshd und Standard Systemwerkzeuge.
Hier kommt noch ein Diagramm, bis dahin muss der Link hier genĂŒgen.
Da hab ich ein "neues" Projekt gefunden (gibt es offenbar schon 2 Jahre) womit es nun möglich ist USB GerÀte in WSL 2 zu verwenden. Ich probiere solche Dinge gerne in einer virtuellen Maschine - damit geht die Odyssee der Stolpersteine los ...
Manchmal entdeckt man dabei Dinge die man schon immer wissen wollte, die habe ich jetzt einfach mit aufgeschrieben. Das Ergebnis diese Artikels ist ein WSL/Linux auf einem Windows/Hyper-V welches auf Linux/KVM auf einer physischen CPU lÀuft! In dem WSL könnte man noch Docker installieren!
Ein typisches Webhosting besteht aus diesen Servicekomponenten :
Normalerweise befindet sich alles bei einem Provider, die Verwaltung und die Funktionen können sich individuell unterscheiden. Es ist aber auch möglich Services bei einem anderen Provider zu nutzen. Warum sollte man das tun?
Möglich wird dies durch Manipulation der DNS EintrÀge.
Alle PHP basierten Websites (Applikationen) sind nach dem gleichen Schema aufgebaut: Datenbank plus viele Dateien in einem Pfad. Das bedeutet prinzipiell:
Wie alle PHP Web Applikationen besteht auch joomla im wesentlich aus einem Sack Dateien (ca. 10.000 gegenĂŒber Wordpress ca. 3000 bei etwa gleicher GröĂe knapp 30 MB) und einer SQL Datenbank. In der Datei configuration.php steht die Datenbankanbindung drin. Als Sicherung vom alten Server benötigt man ein Backup der Dateien vom gesamten Pfad sowie ein Backup/Export/SQL Dump der Datenbank.
