Release und Patch Manage­ment mit SUSE Mana­ger 3

von Nico­las Chris­tener | 16.03.2016

Das SUSE Mana­ger 3 beta Pro­gramm ist Ende Dezem­ber 2015 gestar­tet wor­den. Diese Gele­gen­heit woll­ten wir nut­zen, um uns einen ers­ten Über­blick zu ver­schaf­fen, was die kom­mende Ver­sion beinhal­ten wird.

Vor­ne­weg, die wich­tigste Ände­rung ist die Inte­gra­tion von Salt­Sack als Remote Exe­cu­tion und Con­fi­gu­ra­tion Manage­ment Frame­work.
Für die­sen Blog Post haben wir uns fol­gen­den Anwen­dungs­fall aus­ge­sucht und ein kurze Anlei­tung, wie es in der Pra­xis umge­setzt würde, verfasst.

Sze­na­rio

Damit in grös­se­ren IT-​Systemlandschaften ein ver­nünf­ti­ges Release und Patch Manage­ment durch­ge­führt wer­den kann, wer­den oft iden­ti­sche Sys­teme in unter­schied­li­chen Umge­bun­gen (pha­ses oder sta­ges) betrie­ben. Steht ein neuer Release oder ein Patch zur Ver­fü­gung, wer­den diese zuerst auf den Ent­wick­lungs­sys­te­men ein­ge­spielt und durch­lau­fen dann einige Tests und even­tu­elle Anpas­sun­gen, bevor sie auf den pro­duk­ti­ven Sys­te­men aus­ge­rollt werden.

Der SUSE Mana­ger lie­fert für die­ses Sze­na­rio eine ein­fa­che Lösung. Damit ein­zelne Patches und Pakete von einer Umge­bung in die nächste wei­ter­ge­reicht wer­den kön­nen. Zudem ist es mög­lich einen gesam­ten Stand oder ein Snap­shot eines defi­nier­ten Zeit­punkts von einer Umge­bung in die nächste zu synchronisieren.

Vor­aus­set­zun­gen

Die beschrie­be­nen Kon­fi­gu­ra­tio­nen set­zen vor­aus, dass ein SUSE Man­ger 3 instal­liert und min­des­tens ein Cli­ent Sys­tem mit SLES11 oder SLES12 als Salt Minion ange­bun­den ist.

Kon­fi­gu­ra­tion

Damit das kom­plette Setup in der Shell durch­ge­führt wer­den kann, müs­sen die Pakete spacewalk-​utils und spacecmd instal­liert werden.

— — — -

suma3:~ # zyp­per in –y spacewalk-​utils spacecmd

— — — -

Dann las­sen wir uns die beste­hen­den Soft­ware Chan­nels anzeigen.

— — — -

suma3:~ # spacewalk-​manage-​channel-​lifecycle \ –u admin –p $PASS­WORD –l

— — — -

Zum jet­zi­gen Zeit­punkt ist nur ein Chan­nel zu sehen. Im soge­nannte Ven­dor Chan­nel lie­gen alle Pakete und Patches die vom SCC her­un­ter­ge­la­den wer­den.
Also ein Mir­ror der aktu­ells­ten Pake­ten von SUSE.

Nun wer­den die vier Umge­bun­gen (pha­ses) erstellt.

— — — -

suma3:~ # spacewalk-​manage-​channel-​lifecycle \ –u admin –p $PASS­WORD \ –chan­nel sles12-​sp1-​pool-​x86_​64 –init \ –P devl,test,inte,prod suma3:~ # for PHASE in devl test inte prod ; do > spacewalk-​manage-​channel-​lifecycle \ > –u admin –p $PASS­WORD \ > –chan­nel $PHASE-​sles12-​sp1-​pool-​x86_​64 \ > –pro­mote –P devl,test,inte,prod > done

— — — -

Wer­den die Umge­bun­gen (pha­ese) nicht expli­zit mit –P ange­ge­ben, wird als Stan­dard (dev, test, prod) ver­wen­det. Wird der Chan­nel tree jetzt noch ein­mal mit dem oben genann­ten Befehl ange­zeigt, sind die fünf Base Chan­nels zu sehen. Der Ven­dor– und die vier erstell­ten Umgebungs-​Channels (devl, test, inte, prod).

Damit wir die Kon­fi­gu­ra­tion tes­ten kön­nen, wei­sen wir ein SUSE Mana­ger Cli­ent Sys­tem einer Umge­bung zu, in unse­rem Bei­spiel der Test-​Umgebung.

— — — -

suma3:~ # spacecmd –u admin –p $PASS­WORD –y \ system_​setbasechannel suma3-client1.example \ test-​sles12-​sp1-​pool-​x86_​64

— — — -

Auf dem Cli­ent Sys­tem kann mit fol­gen­dem Befehl über­prüft wer­den, ob die Zuwei­sung funk­tio­niert hat.

— — — -

suma3-​client1:~ # zyp­per lr

— — — -

Es erschei­nen nur Repo­si­to­ries der zuge­teil­ten Umgebung.

Ab jetzt ist es mög­lich, über das WebUI oder das CLI ein­zelne Pakete oder Patches in eine Umge­bung zu impor­tie­ren, oder eine Umge­bung mit einer ande­ren zu synchronisieren.

Hin­ter den Kulissen

Sobald ein Cli­ent Sys­tem einem Base Chan­nel zuge­wie­sen ist, wird auf dem SUSE Mana­ger, wel­cher als Salt Mas­ter läuft, eine Datei mit den ent­spre­chen­den Repo­si­to­ries erstellt.

— — — -

suma3:~ # cd /​srv/​susemanager/​salt/​channels ; \ > cat channels.repo.044625baad3d49889f067f14d7cae86f [susemanager:test-sles12-sp1-pool-x86_64] name=test-sles12-sp1-pool-x86_64 enabled=1 autorefresh=1 baseurl=https://suma3.example/rhn/manager/download/test-sles12-sp1-pool-x86_64?eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE0ODc4MzU1NDgsImlhdCI6MTQ1NjI5OTU0OCwibmJmIjoxNDU2Mjk5NDI4LCJvcmciOjEsImp0aSI6IlRrYldFQWUwaHZGdzNZUklQQk1aWmcifQ.cmGZyuMU_SJT_fHRmj9X0zP7vM1A2KwWgNRp6m4BDcI […]

— — — -

Das Suf­fix des Datei­na­mens ent­spricht der Salt Minion ID des jewei­li­gen Cli­ent, in unse­rem Falle der ID von [suma3-client1.example].

Anschlies­send führt der SUSE Mana­ger den fol­gen­den Befehl aus, wel­cher die Datei [/etc/zypp/repos.d/susemanager:channels.repo] auf dem Ziel­sys­tem [suma3-client1.example] neu schreibt, falls es Abwei­chun­gen zur loka­len Ver­sion gibt.

— — — -

suma3:~ # salt ‘suma3-client1.example’ state.apply

— — — -

Inter­ak­tion Space­walk /​Salt­Stack

Space­walk über­gibt dem Salt Mas­ter seine Befehle über des­sen Rest API, und als Cli­ent Library wird die von SUSE ent­wi­ckelte salt-​netapi-​client verwendet.

Fazit

Die­ses Setup liess sich dank dem Con­fi­gu­ra­tion Manage­ment von Salt­Stack sehr ein­fach durch­füh­ren. Im Ver­gleich zu Vor­gän­ger­ver­sio­nen des SUSE Mana­ger, die als Cli­ent Stack rhns ver­wen­de­ten, war die Kon­fi­gu­ra­tion um eini­ges schlan­ker und die Repository-​Quellen wur­den schnel­ler den Cli­ents zuge­teilt.
Die Inte­gra­tion von Salt­Stack ist eine Berei­che­rung für den SUSE Mana­ger, wel­che nicht nur im beschrie­be­nen Anwen­dungs­fall erheb­li­che Vor­teile mit sich bringt.