Open Source für Dummies 6

Auch wenn ich versucht habe, euch das Thema Open-Source in dieser sechsteiligen Serie so neutral wie möglich zu erklären, so bin ich doch im SUSE-Grün eingefärbt. Ich möchte euch für eure Zukunft als Entwickler (egal ob privat oder professionell) ans Herz legen, euch damit zu beschäftigen, wie ihr eure Anwendungen in die Welt schicken wollt. Es gibt natürlich die klassischen Methoden über Installer (Windows-Welt) und Packages (Linux/Unix/...) oder auch modernere Varianten wie Container. Wenn ihr der Meinung seid, dass eure Anwendung/Projekt etwas sehr komplexes ist, dann würde ich euch empfehlen, diese auf einer Virtuellen Maschine zu deployen. So, ich habe jetzt mal wieder eine ganze Menge Begriffe herumgeworfen, was heißt das alles?

Bevor wir uns aber den letzten Ausführungen dieser Serie widmen, möchte ich mich bei den beiden Menschen bedanken, die mich angeregt haben, diese Serie zu verfassen und sie mit euch zu teilen. Danke auch an alle, die das hier gegen gelesen haben und auf Fehler überprüft haben!

Installer (Windows-Welt)

Unter Windows ist mein Wissen sehr beschränkt, aber hauptsächlich wird hier das MSI Format verwendet. Um Installer im MSI Format zu erstellen, wird häufig das Wix Toolset (https://wixtoolset.org/) verwendet. Die Bedienung des Toolsets, um einen Installer zu erstellen, sollte verhältnismäßig einfach sein. Im Grunde ist das Wix Toolset eine Implementierung des Microsoft Software Installers.

Packages

DEBs

Dieses native Linux Paket-Format ist die Grundlage für alle Debian basierten Linux Distributionen. Sie sind Archive mit speziellen Metadaten, die für "dpkg" (das Verwaltungs-Werkzeug) bzw. "apt" (ein Wrapper um dpkg) anzeigen, ob das Paket mit dem lokalen System kompatibel ist.

RPMs

Dieses native Linux Paket-Format ist die Grundlage für openSUSE, Red Hat, Oracle Linux und weitere Betriebssysteme (sogar nicht Unix basierte Systeme). Auch RPMs sind Archive mit speziellen Metadaten, die für "rpm" (den Paketmanager) anzeigen, ob das Paket auf dem lokalen System installierbar ist.

Flatpaks

Webseite: https://flatpak.org/

Dieses Paketformat ist Image basiert und konkuriert mit "Snap" (siehe unten). Der Vorteil an Flatpaks ist, dass alle Abhängigkeiten im Image sind. Das heißt, das außer der Runtime von Flatpak keine weitere Software benötigt wird, um das Paket auszuführen. Die Kommunikation mit dem Host System wird über sogenannte Portals geregelt, die klare Schnittstellen für die Applikation zur Verfügung stellen.

Snaps

Webseite: https://snapcraft.io/

Dieses Paketformat ist ebenfalls Image basiert und enthält somit alle Abhängigkeiten für die Anwendung im Image. Der große Unterschied zu Flatpak ist, das es einen Daemon benötigt, welcher die Snaps verwaltet. Es gibt nur einen einzigen Server, von dem Snaps bezogen werden, dieser ist von Canonical verwaltet und nicht quelloffen. Die Kommunikation mit dem Host wird ähnlich wie bei Flatpaks geregelt. Snap nennt diese Schnittstellen jedoch "Interfaces", "Slots" und "Plugs".

Andere Packaging Formate

Es gibt noch zahlreiche andere Formate die ich hier übergangen habe. Falls euch eines der Formate über den Weg läuft und ihr mehr wissen wollt, könnt ihr mich gerne über den Kontakt anschreiben.

Virtuelle Maschinen

Virtuelle Maschinen sind ein sehr einfacher Weg, Software in einer stabilen Umgebung zu entwickeln. Virtuelle Maschinen können einfach weiter gegeben werden und sind einfach verschiebbar im Falle, dass der phyische Host nicht verfügbar sein sollte. Man emuliert einen kompletten Computer (manchmal inklusive der verwendeten Hardware) und kann so die exakte Laufzeitumgebung der Software nachstellen. Auch komplexe Netzwerkgeräte und Setups können in vielen Fällen so repliziert werden.

Virtuelle Maschinen bieten auch einen schönen Weg, um große physikalische Hosts (zumeist Server) in kleinere Computer zu unterteilen. VMs sind auch eine der zentralen Technologien, um die Public Cloud (AWS, Azure, ...) zu ermöglichen.

Container

Container sind eine leichtgewichtige Alternative zu Virtuellen Maschinen. Sie erfreuen sich einer immer größeren Beliebtheit, da sie extrem einfach zu managen sind. Besonders angenehm sind Container für Anwendungen, welche kein vollständiges eigenes Betriebssystem benötigen.

Open Container Initiative

Gegründet wurde die Open Container Initiative (OCI) von Docker. Docker entwickelt die Container Runtime "moby", welche von der Software Docker verwendet wird. Die OCI hat einen Standard entwickelt, welcher die Interfaces zwischen dem Container und Host-System definiert.

Podman ist von Red Hat entwickelt und eine Alternative zu Docker. Der große Vorteil ist, dass Podman keinen Daemon benötigt und als erste Container Runtime von nichtprivilegierten Nutzern (siehe unten) ausführbar war. Diese beiden großen Pluspunkte haben Podman zu großer Beliebtheit im Enterprise Umfeld geführt.

Anmerkung: In Linux Systemen unterscheidet man zwischen priviligierten Nutzern, welche weitrechende Rechte im System haben, und nichtpriviligierten Nutzern, welche lediglich auf ihre eigenen Dateien zugreifen können. Das Rechtekonzept in Linux hat im Detail noch weitere komplexe Einstellungmöglichkeiten, diese sollen an dieser Stelle aber nicht von Relevanz sein.

LXD

Webseite: https://linuxcontainers.org/

LXD ist eine alternative Spezifikation und Implementierung zur OCI. Es bietet ähnliche Funktionalitäten an und verspricht, ebenso schlank zu sein. Wie Snap ist LXD von Canonical entwickelt und hat einige Eigenheiten. Es verspricht die Komfortabilität von VMs, aber die Leichtgewichtigkeit von Containern.