10 Minuten
Sie haben eine virtuelle Arbeitsplatzumgebung. Mehrere Server oder Desktops, eine Reihe von Images, Hunderte von Benutzern. Und jedes Mal, wenn etwas geändert werden muss, beginnt das gleiche Ritual: Sie melden sich an einem Rechner an, nehmen die Änderung vor, hoffen, dass Sie sie auf den anderen Rechnern nicht vergessen, und stellen Wochen später fest, dass die Produktionsumgebung anders ist als erwartet.
Dies kommt in jeder Umgebung zum Tragen, in der virtuelle Desktops oder Anwendungen bereitgestellt werden. Ob Sie nun mit Citrix, Microsoft Azure Virtual Desktop, Parallels oder Remote Desktop Services arbeiten. Die Technologie ist unterschiedlich, der Schmerz ist derselbe.
Und dieser Schmerz ist größer als es scheint.
Wie die Bildverwaltung in der Praxis funktioniert und warum sie Probleme verursacht
In den meisten Unternehmen ist das Image-Management etwas Gewachsenes, nicht etwas, das entworfen wurde. Vor langer Zeit wurde ein Image geschaffen. Dieses Image wurde im Laufe der Jahre verändert. Software wurde hinzugefügt, Software wurde entfernt, Updates wurden durchgeführt, Einstellungen wurden geändert. Das Ergebnis ist ein Image, das die gesamte Historie aller Änderungen enthält, die jemals an ihm vorgenommen wurden.
Es klingt harmlos, ist aber ein schleichendes Problem. Entfernte Software hinterlässt Rückstände. Anwendungen, die aktualisiert, aber nie sauber neu installiert wurden, verhalten sich etwas anders, als sie sollten. Einstellungen, die einmal geändert, aber nie wiederhergestellt wurden, verursachen ein unerwartetes Verhalten.
Wir nennen dies Bildverschmutzung. Sie ist nicht sichtbar, aber Sie bemerken sie. In Vorfällen, die Sie sich nicht erklären können. In einem Verhalten, das von dem abweicht, was Sie erwarten. In einer Umgebung, in der es immer schwieriger wird, Fehler zu beheben.
Gartner schätzt, dass mehr als 60 % der IT-Ausfälle in Unternehmensumgebungen auf Konfigurationsfehler oder ungeplante Änderungen zurückgeführt werden können. Ein kontaminiertes Image ist eine strukturelle Quelle für genau diese Art von Fehlern.
Wie variiert dies je nach Plattform?
Nicht jede Plattform behandelt Bilder auf dieselbe Weise. Das bestimmt, wie groß die Auswirkungen einer schlechten Bildverwaltung sind.
Citrix, AVD und Parallels: ein gemeinsames Image für den gesamten Pool
Mit Citrix Virtual Apps and Desktops, Azure Virtual Desktop und Parallels RAS können Sie mit einem gemeinsamen Image für eine Gruppe von virtuellen Maschinen arbeiten. Sie ändern das Image und der gesamte Pool erhält diese Änderung. Das ist ein großer Vorteil, aber dadurch bestimmt die Qualität dieses einen Images, was alle Ihre Benutzer jeden Tag erleben.
Wenn dieses Image verunreinigt ist oder die Änderungen nicht konsequent verfolgt werden, arbeitet der gesamte Pool suboptimal. Und wenn Sie Änderungen direkt am laufenden Image vornehmen, ohne es neu zu erstellen, kumuliert sich die Verschmutzung mit jeder Änderung.
RDS: jeden Server einzeln aktualisieren
Bei Remote Desktop Services gibt es kein gemeinsames Image-Modell. Jeder RDS-Server ist ein unabhängiger Rechner. Eine Änderung, die Sie vornehmen möchten, muss auf jedem Server einzeln vorgenommen werden. Bei fünf Servern ist das noch überschaubar. Bei zwanzig Servern ist es eine zeitraubende, fehleranfällige Handarbeit.
In der Praxis führt dies dazu, dass sich die Server im Laufe der Zeit voneinander entfernen. Auf dem einen Server läuft eine Anwendung in Version 3.2, auf dem anderen noch in 3.0. Patches werden auf einigen Rechnern ausgerollt, auf anderen nicht. Je nachdem, auf welchem Server sie landen, haben die Benutzer ein anderes Erlebnis. Dies wird als Konfigurationsdrift bezeichnet und ist in RDS-Umgebungen ohne automatisierte Tools besonders schwer zu kontrollieren.
Das Problem mit der Aktualisierung anstelle eines Neuaufbaus
Angenommen, Sie arbeiten seit drei Jahren mit demselben Basis-Image. In diesen drei Jahren wurden Dutzende von Aktualisierungen vorgenommen. Anwendungen wurden aktualisiert. Einige wurden entfernt. Treiber wurden installiert und ersetzt. Einstellungen wurden angepasst.
Dieses Bild ist nicht mehr das, was es einmal war. Es ist die Summe aller Änderungen, die jemals daran vorgenommen wurden. Und jede Änderung, die nicht sauber vorgenommen wurde, hinterlässt eine Spur.
Denken Sie darüber nach:
- Software, die zwar deinstalliert wurde, aber Registrierungseinträge oder Restdateien hinterlassen hat
- Anwendungen, die über ein Installationsprogramm aktualisiert wurden, das die vorherige Version nicht vollständig bereinigt hat
- Dienste deaktiviert, aber nicht entfernt
- Treiber, die ersetzt wurden, während sich die vorherige Version noch im Treiberspeicher befindet
- Konfigurationsdateien, die einmal geändert und nie wieder in einen bekannten guten Zustand versetzt wurden
Das Ergebnis ist ein Bild, das immer schwerer wird, immer mehr verrauscht und immer schwerer zu durchschauen ist. Und wenn dann etwas schief geht, wissen Sie nicht, wo Sie anfangen sollen.
Die Lösung ist nicht eine bessere Verfolgung. Die Lösung ist der Wiederaufbau.
Zusätzlicher Vorteil: Einfacher Wechsel des Hypervisors oder der Plattform
Ein unterschätzter Vorteil der Arbeit mit IaC ist die Freiheit, die Sie haben, wenn Sie migrieren möchten. Jeder, der schon einmal eine Umgebung von VMware auf Citrix Hypervisor oder von vor Ort in die Cloud verschoben hat, weiß, wie schwierig es ist, wenn Ihr Image mit plattformspezifischen Tools erstellt wurde.
Denken Sie an VMware Tools, die tief mit dem Image verwoben sind, oder an Konfigurationen, die für den zugrunde liegenden Hypervisor spezifisch sind. Bei einer Migration müssen Sie diese Tools entfernen, die neuen installieren und hoffen, dass nichts übrig bleibt, was Probleme verursacht. Bei einem Image, das über Jahre hinweg manuell gepflegt wurde, ist das ein riskantes Unterfangen.
Mit IaC bauen Sie das Image für die neue Umgebung neu auf. Sie ändern das Konfigurationsskript, geben an, welche Tools und Treiber für die neue Plattform benötigt werden, und starten den Build. Das Ergebnis ist ein sauberes Image, das speziell für die neue Umgebung erstellt wurde und keine Überbleibsel der alten Plattform enthält.
Das macht Migrationen deutlich einfacher und weniger riskant. Ob Sie nun von:
- VMware zu XenServer oder Citrix Hypervisor
- Vor-Ort zu Azure, AWS oder einem anderen Cloud-Anbieter
- Von einer Version von Windows Server zur nächsten
- Citrix zu AVD, oder umgekehrt
In all diesen Fällen ist ein sauberes, reproduzierbares Bild Ihre beste Ausgangsbasis. Und IaC sorgt dafür, dass Sie das immer haben.
Was ist Infrastructure as Code und was löst es?
Infrastructure as Code ist ein Ansatz, bei dem Sie Ihr Image nicht pflegen, sondern es neu erstellen. Sie beschreiben im Code oder in einer Konfigurationsdatei, was in dem Image enthalten sein soll: welche Software, welche Versionen, welche Einstellungen. Und jedes Mal, wenn Sie ein neues Image benötigen, bauen Sie es auf einer sauberen Basis auf.
Keine Anhäufung von Änderungen. Keine Überreste von alter Software. Kein unerklärliches Verhalten. Jeder Build ist ein sauberer Start mit vollständig dokumentiertem Inhalt.
Der Bauprozess in der Praxis
Kurz gesagt, eine IaC-basierte Bildpipeline funktioniert wie folgt:
- Beginnen Sie mit einem sauberen Basis-Image, Windows Server oder Windows 11
- Das Konfigurationsskript installiert die gewünschte Software in den entsprechenden Versionen
- Windows-Updates sind integriert
- Der entsprechende Agent ist installiert, für Citrix, AVD, RDS oder Parallels
- Anwendungsspezifische Einstellungen werden konfiguriert
- Das Image wird validiert und für die Bereitstellung freigegeben
Jeder Schritt wird im Code dokumentiert. Jede Version jeder Anwendung ist dokumentiert. Sie können jederzeit zu einem früheren Build zurückkehren, und Sie können immer genau sehen, was im aktuellen Image enthalten ist.
Wie New Yard dies für Sie erledigt
Bei New Yard bieten wir IaC-basiertes Image-Management als fortlaufenden Service an. Das bedeutet, dass wir in festen Abständen ein neues Image für Sie erstellen, in das alle Aktualisierungen und Änderungen eingearbeitet werden, ohne dass Sie oder Ihr Team dies manuell tun müssen. Sie zahlen eine feste monatliche Gebühr und wissen, was Sie bekommen.
Feste Bauzeiten, zugeschnitten auf Ihre Umgebung
Standardmäßig erstellen wir nach jedem Patch Tuesday, dem monatlichen Microsoft-Update-Zyklus, ein neues Image. Wir können aber auch mehrmals im Monat ein neues Image erstellen. Anwendungen wie Microsoft Edge, Google Chrome und Adobe Reader erhalten regelmäßige Updates außerhalb des monatlichen Zyklus. Wenn Sie möchten, dass diese Anwendungen in Ihrer Umgebung immer auf dem neuesten Stand sind, passen wir die Häufigkeit der Erstellung entsprechend an.
Unbegrenzte Änderungen beantragen
Sie können unbegrenzte Änderungen pro Bild beantragen. Fügen Sie eine neue Anwendung hinzu, ersetzen Sie eine vorhandene Anwendung, ändern Sie eine Einstellung. Wir verarbeiten die Änderung im Code und erstellen dann das Image neu. Keine manuelle Arbeit auf den Rechnern, kein Risiko einer unvollständigen Bereitstellung.
Detaillierter Build-Bericht nach jedem Build
Nach jedem Build erhalten Sie eine vollständige Übersicht über alle installierten Programme, einschließlich der Versionsnummern. So können Sie den neuen Build leicht mit dem vorherigen vergleichen. Sie können genau sehen, welche Anwendungen aktualisiert wurden, welche neu hinzugekommen sind und ob Sie vollständig auf dem neuesten Stand sind. Dies ist nicht nur für die tägliche Verwaltung nützlich, sondern auch für die Einhaltung von Vorschriften und Audits.
Die Risiken, wenn Sie so weitermachen, wie Sie jetzt arbeiten
Nicht reduzierbare Vorfälle
Wenn Ihre Umgebung nicht konsistent ist, nimmt die Fehlersuche unverhältnismäßig viel Zeit in Anspruch. Sie wissen nicht, ob das Problem in der Konfiguration dieses bestimmten Rechners, in einem Update, das irgendwo halb implementiert wurde, oder in etwas anderem liegt. Ohne eine reproduzierbare Grundlage haben Sie keinen Bezugspunkt, von dem aus Sie arbeiten können.
Sicherheitslücken durch unvollständiges Patching
Manuell bereitgestellte Patches erreichen nicht immer alle Rechner. Dies führt zu einem uneinheitlichen Patch-Level. Daten von Microsoft zeigen, dass mehr als 80% der erfolgreichen Cyberangriffe bekannte Schwachstellen ausnutzen, für die Patches verfügbar waren. Ein automatisierter Build-Zyklus nach dem Patch Tuesday begrenzt dieses Risiko strukturell.
Abhängigkeit von individuellem Wissen
Wenn der Administrator, der die Umgebung kennt, geht oder krank ist, stehen Sie still. Was genau sich auf welchem Rechner befindet, ist nicht aufgezeichnet oder zumindest nicht auf dem neuesten Stand. Bei IaC ist der Code die Dokumentation. Immer aktuell, immer aufschlussreich.
Skalierbarkeit
Wächst Ihre Umgebung? Dann wachsen die Probleme mit. Was bei fünf Rechnern noch überschaubar ist, wird bei 50 Rechnern zu einem Verwaltungsaufwand. IaC ist von Natur aus skalierbar: Sie fügen einen Parameter hinzu und der Build-Prozess kümmert sich um den Rest.
Häufige Einwände und ehrliche Antworten
Wir haben bereits ein goldenes Bild, das gut funktioniert.
Ein goldenes Bild ist eine gute Ausgangsbasis. Aber wenn Sie dieses Bild über Jahre hinweg mit losen Anpassungen aktualisiert haben, sammelt sich die Verschmutzung an. IaC baut das Bild jedes Mal neu auf, und zwar sauber. Das ist ein grundlegender Unterschied zum Tracking.
Das klingt kompliziert, dafür haben wir nicht das nötige Wissen.
Sie müssen dieses Wissen auch nicht im Haus haben. Wir implementieren die Pipeline und verwalten sie für Sie. Sie geben an, was geändert werden muss, wir sorgen dafür, dass es korrekt in das Image eingepflegt wird und dass der Build korrekt ist.
Wir sind gerade dabei, die Plattform zu wechseln.
Dann ist jetzt der richtige Zeitpunkt. Mit IaC bauen Sie ein sauberes Image für die neue Plattform auf, ohne das Durcheinander der alten Plattform. Ganz gleich, ob Sie von VMware auf XenServer oder von vor Ort auf die Cloud umsteigen, Sie gehen mit einer soliden Grundlage.
‚Das braucht jetzt mehr Zeit als wir haben'.
Die Implementierung erfordert eine einmalige Investition. Aber sehen Sie sich an, wie viel Zeit jetzt jeden Monat für manuelle Patches, das Ausrollen von Updates und die Behebung von Vorfällen aufgrund von inkonsistenten Umgebungen draufgeht. Diese Zeit macht sich bezahlt.
Praktische Checkliste: Wo stehen Sie jetzt?
- Sind alle Änderungen an Ihren Bildern dokumentiert und reproduzierbar?
- Können Sie derzeit ein komplett neues Image ohne manuelle Schritte erstellen?
- Sind alle Maschinen in Ihrem Pool auf demselben Patch-Level?
- Verfügen Sie über eine aktuelle Liste aller installierten Software einschließlich der Versionen?
- Können Sie den aktuellen Build mit dem vorherigen vergleichen, um zu sehen, was sich geändert hat?
- Gibt es einen festen Zyklus für die Aktualisierung Ihres Images nach dem Patch Tuesday?
- Können Sie bei einer Plattformmigration ein sauberes Image ohne Überbleibsel der alten Umgebung erstellen?
Je öfter Sie mit ‚Nein' antworten, desto wahrscheinlicher ist es, dass Ihre Bildumgebung stillschweigend verschmutzt und an Qualität verliert.
Sind Sie bereit, Ihre Bildverwaltung zu rationalisieren?
Wenn Sie sich in diesem Artikel wiedererkennen, ist ein unverbindliches Beratungsgespräch der logische nächste Schritt. Gemeinsam schauen wir uns Ihre aktuelle Umgebung an, identifizieren die Risiken und zeigen Ihnen, wie eine automatisierte Image-Pipeline für Ihre Situation aussehen könnte.
Vereinbaren Sie ein kostenloses Beratungsgespräch über newyard.co.uk. Keine Verpflichtungen, aber konkrete Einblicke.
