Suses Image-Dienst Studio geht in Version 1.3 an den Start und bringt viel Neues. Per Webinterface sollen selbst Nicht-Experten OS-Images auf Suse-Basis bauen, neben Open Stack auch für Hyper-V und KVM.

Die älteren Admins werden sich noch erinnern: Bevor Virtualisierung ins Rechenzentrum einzog, war das Aufsetzen eines neuen Servers eine überaus langwierige Angelegenheit. Von der Beschaffung der Hardware bis zur fertigen Installation mit allen OS-Anpassungen vergingen durchaus einige Tage, inklusive Planung auch mal Wochen. Durch Virtualisierung hat sich dieser Umstand zumindest etwas gebessert, denn wenn nicht ausgelastete Hardware bereits im Rack steht, entfallen Vorbereitungs- und Planungsarbeiten.

Ein OS ist immer noch nötig

Geblieben ist hingegen die Tatsache, dass auch für eine virtuelle Maschine ein vollständiges Betriebssystem nötig ist, dessen Installation sich vom Ablauf auf echtem Blech leider nur wenig unterscheidet. Um diesen Vorgang angenehmer zu gestalten, springen immer mehr RZ-Betreiber auf den automatisierenden Zug von Konfigurationstoools wie Puppet [1] oder Chef [2] auf. Wer solch ein Setup mit Diensten wie Cobbler [3] kombiniert, erspart sich viel Arbeit.

Aber solche maßgeschneiderten Setups sind in der Regel spezifisch für ein einzelnes Unternehmen. Wer eine öffentliche Wolke betreibt, ist mit unterschiedlichen und sich teils widersprechenden Anforderungen von Kunden konfrontiert, sodass es ihm unmöglich ist, Puppet oder Chef sinnvoll einzusetzen.

Praktisch alle Cloud-Computing-Umgebungen sind deshalb so konstruiert, dass sie die Verantwortung für das Betriebssystem auf den Benutzer schieben. Sie bieten dazu Dienste an, die auf Namen wie “Image Service” (bei Open Stack) hören und im Grunde nur Betriebssystem-Images bereithalten, um sie auf Zuruf per REST-ful-API-Befehl auf einen Hypervisor-Knoten zu kopieren.

Die Anbieter von Cloudumgebungen geben dabei einige grundlegende Images vor, erlauben ihren Kunden aber auch, eigene Images zu installieren, die im Hinblick auf bestimmte Einsatzbereiche optimiert sein können. An diese Kunden richtet sich auch Suses Studio: Es bietet Admins die Möglichkeit, per Webinterface OS-Images auf Suse-Basis zu bauen, ohne Experten zu sein (siehe Abbildungen 1 bis 4).

Abbildung 2: Die textbasierte Installation mit Yast 2 in virtuellen Maschinen ist eine langwierige Aufgabe, an der Nicht-Geeks oft scheitern.

Abbildung 3: Suse Studio erlaubt es, fertige Images für den Betrieb in der Cloud oder in klassischen Virtualisierungslösungen per Mausklick zu bauen.

Abbildung 4: Suse Studio führt den Benutzer mit Tabs und dem freundlichen Roboter durch die Installation. Wahlweise per Wizard oder über die zahlreichen Tabs hangelt sich der Anweder zum kompletten Betriebssystem.

De facto unterscheidet sich die Installation eines Betriebssystems in einer virtuellen Maschine kaum von der Installation auf echter Hardware: Das virtuelle System braucht eine Festplattenkonfiguration, einen Satz Basispakete und viele Konfigurationseinstellungen. Anders als auf echtem Blech sind bei virtuellen Systemen in der Cloud die Kunden aber oft eben keine erfahrenen Admins, sondern Endanwender, die schnell mal einen Server für eine spezifische Aufgabe brauchen.

Suse Studio verspricht, ein passendes Image für den Einsatz in virtualisierten Umgebungen in Sekundenschnelle zum Download anzubieten – abgestimmt auf die Bedürfnisse des Anwenders, aber ohne von ihm technisches Detailwissen zu erwarten. Seit Kurzem steht Suse Studio in der offiziellen Version 1.3 zur Verfügung, und die kommt mit einigen Neuerungen daher.

Funktionsweise und Varianten

Zwei Varianten des Studios stellt Suse zur Verfügung. Einerseits die Onlineversion, die unter [4] erreichbar ist und kostenlos für jedermann offen steht, andererseits eine kostenpflichtige Enterprise-Version zum Kauf. Voraussetzung für die kostenlose Ausgabe ist lediglich ein eigener Account, wer einen Open-ID-fähigen Dienst nutzt, beispielsweise Google+, kann auch dessen Credentials zum Login beim Suse Studio verwenden. Die Technik und die verbandelten Projekte hinter Suse Studio erläutert der Kasten “Studio, Kiwi, Build Service”.

Eine eigene Installation

Alternativ zur Onlineversion kann ein Unternehmen auch seine eigene, lokale Suse-Studio-Instanz betreiben (Abbildung 5). Auch bei dieser Variante ist die gesamte Suse-Studio-Funktionalität vorhanden, Suses Onlineservice bleibt außen vor. So gebaute Images stehen lokal sofort bereit, ohne dass der Admin sie erst von einem Suse-Studio-Service im Web laden muss.

Abbildung 5: “Preise auf individuelle Anfrage” lautet Suses Antwort auf eine entsprechende Frage. Zwar gibt es das Studio auch für die eigene Infrastruktur, doch wie teuer das wird, darüber schweigt sich Suse aus.

Außerdem ist es in diesem Konstrukt auch möglich, solche Daten innerhalb der Cloudimages zu halten, die man auf die offizielle Suse-Studio-Seite aus verschiedenen Gründen nicht hochladen möchte oder darf, zum Beispiel aus Datenschutzgründen, oder wenn dies der Entwicklungsabteilung verboten ist, weil ein NDA untersagt bestimmte Daten Dritten zugänglich zu machen.

Aber so eine lokale Suse-Studio-Installation hat auch einen ernst zu nehmenden Haken: Es hängt ein Preisschild dran. Wie teuer das wird, darüber schweigt sich Suse aus, konkrete Zahlen gibt’s nur individuell und auf Nachfrage.

Enterprise- und Webversion

Ganz gleich, ob sich ein Unternehmen für die öffentlich zugängliche Version von Suse Studio entscheidet oder für eine eigene Instanz: Die Funktionsweise der Applikation selbst ist im Grunde immer gleich. Unter einem hübschen, betont Suse-grünen Webinterface verstecken sich vielerlei Funktionen, die das Erstellen eines Image innerhalb kurzer Zeit gelingen lassen. Der Benutzer legt lediglich fest, um welches Basissystem es sich handeln soll (Open Suse oder doch SLES), und gibt an, welcher Standardsatz an Paketen in seinem neuen Image enthalten sein soll.

Vorsicht ist hier besser als Nachsicht, denn aufgeblähte Images führen gerade innerhalb der Cloud oft zu langen Wartezeiten beim Deployen neuer VMs. Hat der Admin sich die Konfiguration für sein Image zusammengeklickt, erzeugt Suse Studio das angeforderte Image und stellt es zum Download bereit. Zwischen Login und dem fertigen Image auf der lokalen Festplatte liegen im Idealfall keine zehn Minuten. In der Praxis kann es allerdings vorkommen, dass das Herunterladen des fertigen Image aus dem Suse Studio einige Zeit in Anspruch nimmt.

Suse macht übrigens keinen Hehl daraus, dass man in Nürnberg das Suse Studio für eine von mehreren Komponenten hält, deren Anschaffung im Paket nur logisch sei. Geht es nach dem Hersteller, dann soll der Kunde gleich auch Enterprise-Betriebsystem, -Cloud, -Management und -Support einkaufen.

Alles nur grün

Das macht sich am deutlichsten dadurch bemerkbar, dass das Suse Studio ausschließlich mit Suse-basierten Distributionen zurechtkommt. Alles, was die Software an Images ausspuckt, fußt also auf einer der Suse-Varianten, sei es die Desktop-Version Open Suse oder die Enterprise-Variante SLES.

Wer seine VMs in der Cloud lieber mit Ubuntu oder Centos betreiben möchte, muss sich modifizierte Images woanders besorgen; Suse Studio scheidet als Hilfe aus. Die fränkische Ideal-Vorstellung besteht offenbar aus einem homogenen System, in dem sich SLES- und Suse-Cloud-Rechner die Klinke in die Hand geben – fertig ist das grüne Wunderland.

Letztlich schränkt die vollständige Fixierung auf Suse das Studio allerdings eher ein, als ihm zu nützen. Denn vergleichbare Dienste für Ubuntu oder Red-Hat-Klone sind schlicht nicht vorhanden. Öffnete Suse sein Studio auch für andere Systeme – so wie den Build Service – dann fänden die Nürnberger sicher viel mehr Interesse und könnten auch Nutzer an sich binden, die sonst eher nicht grün unterwegs wären.

Studio 1.3 und die Cloud

Im April 2013 hat Suse die neueste Version 1.3 des Studios veröffentlicht und sich dabei vor allem und ausdrücklich auf Veränderungen in Sachen Cloud Computing konzentriert. Mit Erfolg: Die Integration mit den gängigen Cloudstacks gelingt Suse Studio jetzt deutlich besser als vorher.

Ursache dafür ist allerdings nicht eine große Veränderung, sondern viele kleine: Den Anfang machen die unterstützten Imageformate: Suse Studio bietet nunmehr die Möglichkeit, mit Hyper-V kompatible Images zu erzeugen, die sich dann problemlos in Microsofts Virtualisierung einbinden lassen. Wer also beispielsweise innerhalb einer Open-Stack-Umgebung auch Hyper-V als Hypervisor einsetzt, hat es ab sofort deutlich leichter.

Noch ein Format hat es endlich in Suse Studio 1.3 geschafft: Das native KVM-Format Qcow2. Selbstverständlich konnte Suse Studio auch bisher Images für KVM ausgeben, allerdings nur über den Umweg von VMwares VMDK-Format, das sich meist als deutlich weniger performant und weniger effizient erwies als Qcow2. Diesen Umweg haben die Suse-Studio-Entwickler in Version 1.3 abgekürzt und so die Unterstützung für die wichtigsten Hypervisoren praktisch vervollständigt. VMware und Xen gehörten ja schon seit Längerem zum Lieferumfang.

Auch für den Amazonas

Wer selbst gar keinen eigenen Hypervisor betreibt, sondern seine VMs in Amazons öffentlicher Wolke laufen lassen will, freut sich über die neue EC2-Exportmöglichkeit, die in die Studio-Version 1.3 ebenfalls Einzug gehalten hat. Damit wandern EC2-Images direkt “in den Amazonas”.

Eine weitere Cloud-spezifische Neuerung ist die direkte Integration mit anderen Cloudprodukten. Natürlich bringt das Studio ein Interface zu Suses eigener Cloudlösung Suse Cloud ([6], [7]) mit, die bekanntlich auf Open Stack aufbaut. Im Release-Announcement zu Studio 1.3 findet sich der Hinweis, dass die direkte Verbindung auch mit einer normalen Open-Stack-Basis funktioniert, es braucht also nicht zwingend die spezielle Versionen von Suse.

Hat ein Benutzer die Cloudintegration aktiviert, speichert Studio die per Webinterface erstellten Images unmittelbar und direkt in Open Stack Glance, dem Imagedienst der Cloudumgebung, sodass sie dort für das Projekt (vormals Tenant) zur Verfügung stehen.

Eine ausführliche Anleitung, wie für Admins solch eine vollautomatische Cloudintegration erreichbar ist, haben die Entwickler von Studio auf ihrem Weblog unter [8] online gestellt, ein Artikel im Linux-Magazin erklärt Open Stacks Komponenten [9].

Patch- und Lifecycle-Management

Für Administratoren ebenfalls zentral dürfte die Funktion sein, die Suse etwas sperrig “Suse Lifecycle Management Server” nennt: Die Idee hinter diesem Feature ist, bereits ausgerollte Images innerhalb einer Cloudinstallation im Nachhinein zu verändern, indem es Befehle an virtuelle Images sendet. Wird bei einem schon ausgerollten Image eine Änderung notwendig, beispielsweise um Security-Fixes zu installieren, kümmert sich Suse Studio automatisch darum.

Vorgekaut

Wer auf den öffentlichen Studio-Dienst von Suse zurückgreift, kriegt einen echten Mehrwert: Verschiedene Images, die andere Benutzer auf Grundlage der Vanilla-Distributionen erstellt haben, stehen dort als geteilte Images nach dem Login zur Verfügung. Suse Studio bietet viele Konfigurationsmöglichkeiten im Hinblick auf die zu erstellenden Images (Abbildungen 6 und 7); ausgehend von einem Basissystem lässt sich nahezu jeder Parameter beliebig modifizieren. Auch die Software, die Bestandteil des Image sein soll, passt der Admin per Mausklick den eigenen Wünschen an.

Abbildung 6: Obgleich das Webinterface von Suse Studio leicht ist, erlaubt es doch die Konfiguration vieler Parameter.

Abbildung 7: Eigene Images verwaltet der Anwender in der »Gallery« in Suse Studio, hier kann er auch neue hinzufügen oder bestehende konfigurieren. Neben Amazon geht das auch mit Microsofts Azure-Cloud.

Kein Wunder, dass bereits einige Projekte das öffentliche Suse-Studio für sich entdeckt haben. Unter dem Menüpunkt »Gallery« (Abbildung 8) finden sich verschiedene vordefinierte Appliances, darunter eine Open-Suse-Version, die die komplette Android-Entwicklungsumgebung enthält, oder ein SLES mit vorkonfiguriertem Samba 4.

Abbildung 8: Aus den Images anderer Benutzer entsteht ein Abbild-Flohmarkt.

Gut, aber noch zu grün

Hier wird deutlich, dass Studio eben nicht nur ein Clouddienst ist, als den Suse es vermarkten will. Denn weil Studio in viele verschiedene Diskformate exportieren kann, sind die zum Download angebotenen Appliances auch für Entwickler und Admins interessant, die auf ihrem System zu Hause schnell in einer VM etwas ausprobieren möchten.

Suse Studio 1.3 kommt mit einigen Veränderungen, die besonders im Cloudkontext eine Rolle spielen. Sehr gelegen kommt vielen Admins die unmittelbare Integration von Suse Studio mit Open Stack, die wohl maßgeblich dem Umstand geschuldet ist, dass Suse selbst in Sachen Cloud wie so viele Anbieter auf den Open-Stack-Zug gesprungen ist. Wer in seiner eigenen Cloud das Produkt Suse Cloud nicht nutzt, dafür aber eine andere Open-Stack-Distribution (oder gar pures Open Stack) kommt also klar.

Gut tut dem Produkt auch der Reigen verschiedener vordefinierter Images, die auf der offiziellen Suse-Studio-Seite zur Verfügung stehen. Sie bieten echten Mehrwert und ersparen im Zweifelsfall viel Arbeit. Der große Haken am Suse Studio ist allerdings die Fixiertheit auf das eigene Elternhaus. Zumindest auf Außenstehende wirkt es so, als habe Suse bis dato die Option, andere Distributionen in Suse Studio zu unterstützen, noch gar nicht in Betracht gezogen.

Gleichzeitig müssen sich die Projektverantwortlichen von Ubuntu, Fedora und anderen Distributionen die Frage gefallen lassen, warum sie nicht selbst einen ähnlichen Dienst offerieren (siehe Kasten “Alternativen für andere Distributionen”) oder das Mitwirken an der Integration anderer Systeme als Suse im Studio anbieten. An einem solchen Publicity-trächtigen Mehrwert sollte Suse eigentlich unbedingt interessiert sein. Bis dahin gilt allerdings: für Suse hui, für alle anderen Distributionen pfui. Aber Admins, die schon Suse einsetzen, ob Open oder Enterprise, werden das Studio 1.3 jedenfalls als funktionelle Bereicherung empfinden.

Alternativen für andere Distributionen

Wie im Artikel beschrieben ist, spuckt Suse Studio nur Images aus, die auf einer der Suse-Distributionen basieren. Wer in seiner VM-Umgebung kein Suse betreiben möchte, sondern Red Hat, einen Klon davon, Debian oder Ubuntu, muss aber nicht automatisch auf modifizierte Images verzichten.

Trotzdem bleibt Suse Studio sicherlich die leichteste Art und Weise, ein eigenes Image auf die Beine zu stellen, denn die verfügbaren Alternativen für andere Distributionen sind deutlich weniger intuitiv. Wer keine Angst vorm Basteln hat, kommt aber auch auf anderen Wegen zum eigenen Image.

Ubuntu: Vmbuilder

Für die Freunde von Ubuntu wäre da beispielsweise Vmbuilder zu nennen. Das Werkzeug kommt von Serge Hallyn und hat seine Website unter [13]. Es ist ein in Python geschriebenes Skript, das auf der Kommandozeile das Bauen eines Image nach vorher festgelegten Parametern ermöglicht. Werte wie die Partitionierung der Festplatte oder die gewünschte Netzwerkkonfiguration innerhalb der VM sind direkt auf der Kommandozeile anzugeben. Eine direkte Integration mit Libvirt existiert, die Ausgabe in verschiedenen Formaten (Xen, Qcow2, VMware) beherrscht Vmbuilder ebenfalls.

Im Gegensatz zu Suse Studio fehlt allerdings ein einfaches, Enduser-taugliches GUI für die Komponente. Erprobt ist das Werkzeug jedenfalls: Die offiziellen Images von Ubuntu für die Amazon-Cloud entstehen ebenfalls mit Vmbuilder (Abbildung 9).

Abbildung 9: Die offiziellen Ubuntu-UEC-Images bauen die Entwickler mit dem Vmbuilder-Tool, das aber auch als eigene Anwendung zur Verfügung steht.

Red Hat und Libvirt: Virt-install

Für RHEL-Systeme oder Klone steht ebenfalls ein Tool zur Verfügung, um VM-Images zu bauen. Es heißt »virt-install« und gehört eigentlich direkt zur Libvirt. Es funktioniert nach einem sehr simplen Prinzip, indem es ein Kickstart-File für den Red-Hat-Installer generiert. Anaconda holt sich dann alle weiteren Informationen direkt aus dem Netz. Per Kommandozeile lässt sich auch eine Liste von Zusatzpaketen angeben, die im neuen System von Anfang an enthalten sein sollen.

Aber wirklich Distributions-spezifisch oder -abhängig ist das Tool dennoch nicht, sodass sich auch nicht alle Red-Hat-Spezifika direkt beim Start abarbeiten lassen. Andererseits ermöglicht dies aber auch die Zusammenarbeit mit anderen Distributionen, die Libvirt einsetzen. Und für die grundlegende Konfiguration eines Linux-Gastes im Alltag-Admin reichen die Möglichkeiten allemal.

Virt-install auf Ubuntu

Wie Abbildung 10 zeigt, steht Virt-install auch auf Ubuntu zur Verfügung – weil die Libvirt-Pakete es mitliefern. Auf Raring Ringtail beispielsweise startet der Befehl

Abbildung 10: Der Virt-Manager ist ein von Red Hat entwickeltes Tool aus der Libvirt-Bibliothek, das es dem Benutzer einfach macht, schnell eine VM nach bestimmten Vorgaben anzufertigen

virt-install --connect qemu:///system --virt-type kvm --name demo --ram 500 --disk path=~/Temp/debian.img,size=8 --graphics vnc --cdrom ~/Downloads/debian-5010-amd64-netinst.iso

unter KVM innerhalb von Sekunden eine neue Debian-Instanz mit einem 8 GByte großen Raw-File als Storage und 500 MByte RAM. Auch Netzwerke und andere Peripherie lassen sich so zuordnen, mehr Informationen dazu bietet die Manpage.