Image: Update -> Test -> Rollout

Hallo,

ich suche einen Workflow für die V7.2, wie ich erst ein produktiv eingesetztes Image so updaten kann, dass ich es erst an einer Gruppe von Test-Clients testen kann, bevor ich es auf alle produktiven Clients ausrolle.
In der V6 hatte ich das in der Schulkonsole durch einfaches Duplizieren und Umbenennen des Images machen können - aber in der V7 ist ja vieles anders.

Für Tipps, Stolperfallen und Erfahrungsberichte dankbar!

Stefan

Hallo Stefan,
die prinzipielle Vorgehensweise hat sich seit V6 mMn nicht verändert.
Daher würde ich auf dem v7-Server z.B. so vorgehen…

Zuerst die neue Hardwareklasse erzeugen:
cp start.conf.produktive-HWK start.conf.test-HWK
und dann einen Client in der devices.csv in die test-Hardwareklasse aufnehmen:

# Example:
r100;r100-pc01;test-HWK;00:11:22:33:44:55;10.16.1.101;;;;classroom-studentcomputer;;1

Anschließend linuxmuster-import-devices laufen lassen, den neuen Client starten und mit F1 unter LINBO nachschauen, ob er auch wirklich in der neuen HWK gelandet ist.

Dann kannst Du auf diesem Client alles installieren, was Du willst und ganz am Ende für diesen Client ein neues Basis-Image mit anderem Namen (!!!) hochladen.
Wenn Du nun in der start.conf.test-HWK den neuen Namen für das neu hochgeladene Basisimage einträgst, hast Du einen Parallelbetrieb beider Images und kannst gefahrlos alles testen.
Aber wie gesagt: Das ging unter v6 nicht anders, meine ich :thinking:

Viele Grüße, :wave:
Michael

Hallo Stefan,

ich hab zwei virtuele Clients. Auf dem einen erstelle ich das Image mit allen anpassungen und auf den zweiten spiele ich es zurück um zu testen. Dabei ändere ich nix am Imagenamen oder schraube auch nix an den Hardwareklassen: ich hab für die Linuxclients nur eine und für Windowsclients auch nur eine.
Da ich das nachts von ZUhause aus mache, laufe ich auch nicht Gefahr, dass Jemand gerade einen Client synct …

LG
Holger

Hallo und Danke für die Tipps,

@baumhof: Über die Arbeitszeit und die virtuellen Clients kann ich das leider nicht regeln - aber immer gut zu wissen, was es für funktionierende Möglichkeiten gibt. Wer weiß schon, wie sich die Umstände weiter entwickeln?

@Michael: Für mich ändert sich von V6 zu V7 da etwas, da ich in V6 immer nur das eine produktive bzw. Test-Image umbenannt habe und nicht die Eintragungen in mehreren Konfig-Dateien der Hardwareklassen (start.conf) angepasst habe.

Nachfrage: Wäre das Umbenennen von Images auch ein gangbarer Weg, oder ist davon eher abzuraten? Wir verwenden „torrent“ (und auch einen Cache-Server für Linbo - aber das ist ein anderes Thema).

Mit besten Grüßen,
Stefan

Meinst Du das so, dass Du die .qcow2-Datei umbenennst und stattdessen dem System eine andere unterjubeln willst? Prinzipiell funktioniert das, aber ob Torrent das einfach so mitmacht, weiß ich nicht.

Man kann jedenfalls die zugehörige .torrent-Datei auch neu erzeugen lassen.
In meinem Logbuch steht ein (alter) Eintrag, der so aussieht:

Neuerstellung der .torrent-Datei erzwingen: 
# /etc/init.d/linbo-bittorrent restart image.cloop force 
oder auch so (dauert aber entsprechend länger!):
service linbo-bittorrent restart all force

Das bezieht sich noch auf das alte Format (cloop anstelle von qcow2) aber dürfte im Prinzip egal sein …

Hallo Stefan,

ich bin kein Freund vom Umbenennen bei jedem neuen Image, weil sich so die alten Images auch im Cache der Clients kumulieren, was beachtet werden muss, sonst fällt man da auf die Nase.

Gernell spricht aber nichts dagegen in der V7 genau so wie in der V6 zu verfahren: umnennen in der start.conf.GRUPPE.

LG
Holger

Danke für die klaren Erläuterungen!
Dann mache ich es über „Umbenennen in der start.conf.GRUPPE“

Beste Wünsche,
Stefan

Korrektur:
Wir nutzen rsync (nicht torrent).

Nachtrag:

Das habe ich nicht hinbekommen - ich konnte an dieser Stelle im LINBO kein neues Basisimage mit neuem Namen vom Client auf den Server hochladen. Habe ich die Funktion einfach nicht gefunden - oder gibt es diese nicht?

Ich habe den Workflow darum so geändert:

  1. Kopie des produktiven Images per Schulkonsole erstellen
  2. Die Imagekopie einer neuen (oder einer dafür angelegten) Image-Update-Hardwareklasse („Gruppe“) zuweisen per Schulkonsole
  3. Imagekopie auf einem Client der Image-Update-Hardwareklasse updaten und danach per LINBO als neues Basisimage auf Server hochladen
  4. Auf weiterem Client der Image-Update-Hardwareklasse die upgedatete Imagekopie testen
  5. Den produktiven Hardwareklassen die upgedatete Imagekopie zuweisen per Schulkonsole

Ich bin heute bis 4. gekommen - das sieht alles bis jetzt gut aus.

Vielleicht kann mir jemand noch meine o.a. Frage beantworten. Das wäre hilfreich.

MbW,
Stefan

(Beitrag vom Verfasser gelöscht)

gerade nochmal nachgesehen … stimmt – man kann zwar ein Basisimage hochladen aber scheinbar keinen anderen/neuen Namen (mehr?) angeben. Das hatte ich tatsächlich anders in Erinnerung. Sorry.

Kein Problem - Danke für’s Nachschauen!