Azure Image Gallery – Getting Comfortable in the Cloud

Oder: Wie man sich ein Nest baut.

Informatiker sind schon ein komisches Volk: Hyperaktiv, wenn es um kleinste Probleme geht und immer hilfsbereit – mitunter auch weit über die eigene Belastungsgrenze hinaus.

Man arbeitet schließlich an etwas, was einem Spaß macht.

Dennoch bereitet der Umstieg auf Cloudressourcen manch einem Informatiker ein ungutes Gefühl in der Bauchgegend. Es ist schließlich nicht mehr der eigene, selbst zusammengebaute Server auf dem das Unternehmen läuft, sondern ein System in einem Rechenzentrum mit „geteilten Ressourcen“ – Hardware zum Anfassen ist anders.

Oder?

Mit den aktuellen Veränderungen gerade in der IT fällt es vielen Informatikern  schwer, sich in der neuen und „agilen“ Cloud ein solches „Nest“ wie im hauseigenen Rechenzentrum einzurichten.

Im eigenen Rechenzentrum hat man sich eingelebt: auf dem Hypervisor stehen die Images perfekt vorgefertigt bereit, sie enthalten genau die benötigte Konfiguration und beruhen auf jahrelanger Erfahrung.

In Cloud Umgebungen hingegen wirkt alles wie ein Shop. Vorgefertigte Images mit passender Konfiguration für die Cloud liegen bereits vor und das verleitet zur Faulheit. Das antrainierte Wissen kommt nicht mehr zum Zug. Denn in der Cloud Welt funktionieren manche Themen anders als bisher und dadurch kann allein die Recherche zum „WIE?“ ist in manchen Szenarien eine Mammutaufgabe sein.

Dazu kommt, dass diese Images aus dem Cloud-Shop nicht zwangsläufig gleichbleiben.

Diese Shop-Images werden gepatcht und umkonfiguriert. Auch der Shop und dessen Oberfläche wachsen und entwickeln sich weiter.

Aber das tut das Rechenzentrum ebenfalls. Nur musste man sich früher mit den Patches der Storage-Units, denen der Hypervisor, der Switches, der Router und allen anderen, ‚allein‘ rumschlagen.

Das hat auf der einen Seite viel Schweiß gekostet, auf der anderen Seite aber auch eine Bindung hergestellt.

Clusterkonfigurationen über mehrere Rechenzentren waren und sind eine hohe Kunst. Konfigurationsfehler entstehen bei händischer Arbeit viel zu leicht.

Da sind wir wieder am Anfang, bei der jahrelangen Erfahrung und der Arbeit, die in die Konfigurationen geflossen ist bis wir uns wohlfühlten, und bei vorgefertigten Images.

In der Cloud geht alles einfacher

Möchte man also beispielsweise ein Cluster aus mehreren identischen Hosts bereitstellen, dann braucht man einen Bauplan, wie diese auszusehen haben. Diese Konfiguration muss bis auf kleinste Parameter gleich sein.

Es bietet sich also nur bedingt an, diese aus Shop Images zu erstellen und dann zu konfigurieren.

Genauso wie der Hypervisor „zuhause“ bietet Azure aber beispielsweise ein Feature an, welches den fertigen Images einen Platz bietet und das Deployment von identischen Hosts vereinfacht:

Die Azure Shared Image Gallery

Auch Microsoft kocht bei der neuen Azure Cloud mit Wasser. Diese Images liegen auch in Azure auf unserem eigenen Speicher und somit vorerst nur in unserem Tenant.

Speicher in Azure heißt „Storageaccount“ – wir nennen ihn heute „Blob Storage“.

Da dieser die Images bereithält und eine Image-Gallery irgendwann zu einer großen Ansammlung an vorgefertigten Images wachsen soll, sind erste Überlegungen wichtig, allein um die Pflichtfelder der Azure Infrastruktur zu planen:

Fragenkatalog

Wie benennen wir die Ressourcengruppe in der die Images abgelegt werden?

Welche Region wählen wir, um unsere Images zu speichern?

Welche Synchronisationsoptionen nutzen wir?

Welche Namenskonventionen haben wir aktuell für Speicher und wie lassen sich diese auf Azure übertragen?

Wie bekomme ich meinen Speicher sicher?

(zu Role Based Access Control (RBAC) hat mein Kollege Dominic Iselt bereits einen Blogbeitrag verfasst)

Wie liegen Images im Rechenzentrum aktuell ab?

In diesem Storage Account brauchen wir nun einen Blob-Container.

Namenskonventionen sollten hier schon angewendet werden, da die Links in die ImageGallery auf den jeweiligen Blob zugreifen. Eine Konvention für ein bestimmtes Betriebssystem wäre zum Beispiel sinnvoll als Containername. Darin können wir dann alle auf diesem OS basierenden Images ablegen.

Im Container laden wir dann unser generalisiertes Image hoch, sofern wir dieses selbst erstellen wollen. Das bietet sich bei Cloud-Provider Verwendung nicht unbedingt an – daher empfehlen wir hier einen anderen Weg.

Um ein verwaltetes Image aus einer Azure VM zu erstellen, ist eine VM in Azure notwendig, die vorkonfiguriert wird.

Zuerst suchen wir unsere zukünftige Image-VM in den bestehenden VMs im Azure Portal.

Von dieser kann im Portal ein Snapshot erstellt werden. Darunter verbirgt sich auch das Erstellen eines Images. Achtung, zuerst muss die Maschine generalisiert werden, was klassisch via Sysprep oder generalize für Linux erfolgt. Die Image Gallery kann jedoch auch mit spezialisierten Images umgehen.

Nach Erstellung des Images müssen dann Name, Ressourcengruppe und weitere Aktionen mit der VM bestätigt werden. Es ist möglich die VM nur für eine Imageerstellung zu verwenden und anschließend direkt zu löschen – Praktisch!

Gerade wenn die Images für den Clusterbetrieb genutzt werden sollen, ist die Auswahl der verschiedenen Verfügbarkeitsoptionen enorm wichtig, da diese nicht mehr nachträglich konfiguriert werden können.

 

Eine Galerie daraus machen

Eine Image Gallery erstellen wir, wie jede Ressource in Azure, in eine Ressourcengruppe. Es bietet sich an, diese in derselben Ressourcengruppe zu kreieren wie auch den Blob und alle Images.

Danach sind die Imagedefinitionen zu erstellen, hier werden bereits erste Limits des Features sichtbar:

Quelle: Microsoft

Innerhalb eines „Images“ (in der Gallery) werden dann die Versionen hinterlegt, damit auch diese sauber strukturiert und vor allem vom Administrator verwaltet und gepatcht werden können.

Quelle: Microsoft

Der Name der Imageversion sollte dem Format Major(int).Minor(int).Patch(int) entsprechen. Zum Beispiel: 0.0.1, 1.5.13

Eine andere Versionssyntax lässt Azure hier nicht zu.

Quelle: Microsoft

Ein Image erstellen kann man über den Punkt „Images“; hier werden dann nur noch die Blobs aus dem Storage Account verlinkt.

Ein Skript, um neue, generalisierte Images in den Storage Account zu übertragen, stellt Microsoft im Storage-Account Artikel bereit.

Alternativ: via GUI ist dies mit dem Storage Explorer möglich.

Skype for Business

Johannes Suckow

Infrastructure Consultant

Scheer GmbH
Bismarckalleee 17
79098 Freiburg
Germany

T+49 761 76613-273
Kontakt

Über den Autor

Als Infrastructure Consultant arbeite ich täglich mit den Möglichkeiten der Azure Cloud sowie diversen Tools im Rechenzentrum von Scheer. Ursprünglich aus der Monitoring und Automation Sparte kommend, betreue ich die Kundenumgebungen in Azure ganzheitlich – von der Migration bis hin zur Optimierung nach Best Practice. Die Neu- und Weiterentwicklung bestehender Services ist durch den täglichen Kontakt eine dauerhafte Herausforderung. Der Weg zum Azure Architect ist lang, aber man kommt mit kleinen Schritten am besten voran.

Facebook Icon Twitter icon - Logo Xing Icon - Logo Linkedin Logo - Icon Icon von Youtube Contact icon