Gla­zier, ou­til de dé­ploie­ment Win­dows de Google, ar­rive sur Gi­tHub

Google a mis ré­cem­ment sur Gi­tHub le code de Gla­zier, son ou­til mai­son de dé­ploie­ment d’images Win­dows. Son rôle est d’au­to­ma­ti­ser l’ins­tal­la­tion du sys­tème d’ex­ploi­ta­tion de Mi­cro­soft sur les postes de tra­vail de ses 60 000 em­ployés.

L'Informaticien - - SOMMAIRE - THIER­RY THAUREAUX

Gla­zier, qué­sa­co ?

Ayant à gé­rer un parc im­por­tant de postes fonc­tion­nant sous Win­dows, Google a dé­ve­lop­pé en in­terne son propre ou­til de dé­ploie­ment, Gla­zier. Écr it en Py­thon, ce n’est pas un vi­trier mais bien un ou­til de confi­gu­ra­tion d’images sys­tème via des fi­chiers texte. Il per­met no­tam­ment aux ad­mi­nis­tra­teurs de conser­ver les confi­gu­ra­tions dans des sys­tèmes de contrôle de ver­sion (CVS). Ce n’est pas un ou­til of­fi­ciel de Google. En­core au stade de « work in pro­gress », il lui manque no­tam­ment un sup­port et une do­cu­men­ta­tion dignes de ce nom, mais ce­la semble se mettre dou­ce­ment en place. Il peut être uti­li­sé et mo­di­fié se­lon les usages de la li­cence Apache 2.0. Google pro­pose dé­jà plus de 900 lo­gi­ciels et mor­ceaux de codes sur Gi­tHub. Il existe beau­coup d’autres ou­tils de dé­ploie­ment de sys­tèmes d’ex­ploi­ta­tion sur des parcs de ma­chines : les ou­tils Mi­cro­soft comme WDS ( Win­dows De­ploy­ment S er v i ce s , four­ni avec Win­dows Ser ver), MDT ( Mi­cro­sof t De­ploy­ment Tool­kit , dis­po­nible gra­tui­te­ment sur le Tech­net), ADK ( As se s sment and De­ploy­ment Kit, idem), SCCM (Sys­tem Cen­ter Confi­gu­ra­tion Ma­na­ger, payant), des so­lu­tions open source plus ou moins adap­tées (Clo­neZilla, FOG, Par­ti­mage) et des so­lu­tions pro­prié­taires d’autres édi­teurs (Acro­nis, Pa­ra­gon, Sy­man­tec Ghost…). Gla­zier n’a pas pour ob­jec­tif de les concur ren­cer, il peut même les uti­li­ser (sur­tout dism, l’ADK et WDS) et les com­plé­ter.

Fonc­tion­ne­ment gé­né­ral

Gla­zier a pour fi­na­li­té d’ap­pli­quer l’image d’un sys­tème d’ex­ploi­ta­tion ( Win­dows, en l’oc­cur­rence) sur des postes clients – phy­siques ou vir­tuels. Glo­ba­le­ment, un sys­tème de ges­tion d’images doit réa­li­ser les tâches sui­vantes :

• dé­mar­rer les postes d’un en­vi­ron­ne­ment de tra­vail ;

• ap­pli­quer une image d’ins­tal­la­tion (un « mas­ter », en jar­gon sys­tème) sur les postes ;

• pa­ra­mé­trer de ma­nière spé­ci­fique le sys­tème d’ex­ploi­ta­tion.

C’est gros­so mo­do ce que fait Gla­zier. Son ou­til d’au­to­build four­nit un moyen de sé­lec­tion­ner dy­na­mi­que­ment les images, les ap­pli­ca­tions et les confi­gu­ra­tions à ap­pli­quer sur un poste. Il ré­cu­père les fi­chiers né­ces­saires à tra­vers le ré­seau, exé­cute des scripts et des bi­naires et mo­di­fie le poste se­lon les cri­tères re­quis. Gla­zier est to­ta­le­ment dé­pen­dant du ré­seau. Plu­tôt que d’es­sayer de four­nir des images sys­tème pré­con­fi­gu­rées com­plètes, sou­vent dif­fi­ciles à main­te­nir, Gla­zier met en avant la main­te­nance d’images ba­siques et le dé­ploie­ment des per­son­na­li­sa­tions di­verses re­quises via le ré­seau. Il n’offre pas d’in­ter­face gra­phique de ges­tion cen­tra­li­sée des ou­tils. Gla­zier se pré­oc­cupe sur­tout de conser­ver les don­nées con­cer­nant le dé­ploie­ment d’images à dis­po­si­tion des ad­mi­nis­tra­teurs sys­tème. Un en­vi­ron­ne­ment de dis­tri­bu­tion d’images Gla­zier consiste a mi­ni­ma en :

• une image de boot avec un in­ter­pré­teur Py­thon et les ou­tils Gla­zier ;

• un ser­veur HTTP pour dis­tri­buer les confi­gu­ra­tions, les scripts et les bi­naires ;

• un jeu de fi­chiers de confi­gu­ra­tions avec les scripts et les bi­naires as­so­ciés.

Pre­mier boot

En fonc­tion de la plate-forme, la ges­tion d’images né­ces­site un en­vi­ron­ne­ment de poste de tra­vail ca­pable d’exé­cu­ter les ou­tils d’ins­tal­la­tion. Gla­zier peut, en théo­rie, être exé­cu­té de­puis tout type d’en­vi­ron­ne­ment de dé­mar­rage, mais il a été conçu pour fonc­tion­ner prin­ci­pa­le­ment avec WinPE ( Win­dows Preins­tal­la­tion En­vi­ron­ment). WinPE donne la pos­si­bi­li­té de ré­cu­pé­rer des in­for­ma­tions sur le poste lo­cal, d’ex­traire les fi­chiers d’ins­tal­la­tion et de dé­mar­rer le pro­gramme d’ins­tal­la­tion. Le pa­ra­mé­trage d’un en­vi­ron­ne­ment WinPE est plu­tôt simple et fa­mi­lier à la plu­part des ad­mi­nis­tra­teurs Win­dows, pour ne pas dire à tous. Les images WinPE peuvent être dis­tri­buées via le ré­seau (en boot In­tel PXE, Pre- eXe­cu­tion En­vi­ron­ment), via un fi­chier ( ISO ou WIM, le for­mat d’images de boot et d’ins­tal­la­tion de Mi­cro­soft) ou via un pé­ri­phé­rique de sto­ckage amo­vible ( USB ou autre).

Ins­tal­la­teurs per­son­na­li­sés

Gla­zier étant ba­sé sur Py­thon, le WinPE ou tout autre mé­dia de boot doit conte­nir un in­ter­pré­teur Py­thon. Vous pou­vez pla­cer le code de Gla­zier et ses dé­pen­dances (scripts, bi­naires et fi­chiers de confi­gu­ra­tion) di­rec­te­ment dans le PE ou, pour les uti­li­sa­teurs les plus avan­cés, vous pou­vez co­der un ins­tal­la­teur per­son­na­li­sé char­gé d’ef­fec­tuer cette tâche. WinPE doit être confi­gu­ré pour lan­cer au­to­ma­ti­que­ment l’ou­til d’ins­tal­la­tion. Pour Gla­zier, c’est le rôle d’Au­to­build (le fi­chier au­to­build.py). La créa­tion d’une nou­velle image PE peut être source d’er­reurs et consom­ma­teur de temps. Gla­zier est un sys­tème ba­sé sur le ré­seau et suit comme prin­cipe que les fi­chiers re­quis peuvent être té­lé­char­gés d’un point de dis­tri­bu­tion sur le ré­seau au cours de l’ins­tal­la­tion. Il est plus fa­cile de mo­di­fier des fi­chiers sto­ckés sur le ré­seau de ma­nière contro­lée, pré­vi­sible et à peu de frais plu­tôt que de ré­gé­né­rer une image WIM ou PE conte­nant ces mo­di­fi­ca­tions. Google es­saye tou­jours de mi­ni­mi­ser les be­soins en termes de gé­né­ra­tion de nou­velles images de boot en in­jec­tant le plus pos­sible de mo­di­fi­ca­tions de rou­tine dans l’en­vi­ron­ne­ment dy­na­mique de Gla­zier. Les uti­li­sa­teurs les plus avan­cés crée­rons sou­vent un simple ins­tal­la­teur qui dé­mar­re­ra d’un fi­chier start­net.cmd et ré­cu­pé­re­ra Py­thon et Gla­zier à tra­vers le ré­seau. Ce­la dis­pense de gé­né­rer un nou­veau PE si des mo­di­fi­ca­tions doivent être ap­por­tées con­cer­nant (l’in­ter­pré­teur) Py­thon, les ou­tils de Gla­zier ou tout autre pa­ckage de dé­pen­dances.

Au­to­build

Au­to­build est le com­po­sant cen­tral du sys­tème Gla­zier. Il contient la lo­gique de dé­cou­verte des postes clients, de ré­cu­pé­ra­tion de fi­chiers, de ges­tion de confi­gu­ra­tion et d’im­plé­men­ta­tion d’un cer­tain nombre d’ac­tions d’ins­tal­la­tion ba­siques. Lors de son pre­mier lan­ce­ment, Au­to­build doit être di­ri­gé, via un flag, vers le ser­veur web hé­ber­geant les fi­chiers de confi­gu­ra­tion d’ins­tal­la­tion. Le fi­chier de confi­gu­ra­tion ra­cine est ex­trait et exé­cu­té pas à pas. Il va com­pa­rer les com­mandes qu’il trouve dans ces fi­chiers à ce qu’il va dé­cou­vrir sur l’état du poste (hard­ware, ré­seau, etc). Il peut aus­si être confi­gu­ré pour in­ter­agir avec l’uti­li­sa­teur via un me­nu. En se ba­sant sur les fi­chiers de confi­gu­ra­tion et l’état des postes, Au­to­build va com­pi­ler une liste d’ac­tions à exé­cu­ter en sé­rie. Ces ac­tions, consi­dé­rées de ma­nière glo­bale, vont réa­li­ser toutes les opé­ra­tions re­quises afin de pro­duire une image de poste mas­te­ri­sé com­plète. Lorsque au­to­build at­teint la fin des fi­chiers de confi­gu­ra­tion dis­po­nibles, il a pro­duit une liste d’ac­tions en at­tente de réa­li­sa­tion pour le poste client. Il va en­suite com­men­cer à les exé­cu­ter de ma­nière or­don­née. Il se ter­mine lorsque la der­nière ac­tion de la liste a été ef­fec­tuée ou si l’une d’entre elles échoue.

Flux de confi­gu­ra­tion

La ca­pa­ci­té d’Au­to­build à gé­rer des confi­gu­ra­tions est ba­sée sur une struc­ture to­ta­le­ment libre. Une confi­gu­ra­tion réus­sie a ten­dance à suivre une sé­rie com­mune d’évé­ne­ments :

1. boo­ter en WinPE et lan­cer Au­to­build ;

2. af­fi­cher un prompt de sai­sie pour l’uti­li­sa­teur, si né­ces­saire, afin de re­cueillir des élé­ments sur la confi­gu­ra­tion des postes sur les­quels les images doivent être dé­ployées ;

3. ré­cu­pé­rer une image de sys­tème d’ex­ploi­ta­tion plus ou moins per­son­na­li­sée – le moins pos­sible, se­lon les prin­cipes in­vo­qués plus haut ;

4. ré­cu­pé­rer les pi­lotes né­ces­saires à la per­son­na­li­sa­tion de l’image et les ap­pli­quer ;

5. par­ti­tion­ner le disque et ap­pli­quer l’image ;

6. char­ger le code Gla­zier, l’in­ter­pré­teur Py­thon et tous les autres fi­chiers re­quis dans le nou­veau disque ;

7. re­dé­mar­rer le nou­veau sys­tème d’ex­ploi­ta­tion et le « sys­pre­per » (exé­cu­ter le pro­gramme d’ini­tia­li­sa­tion sys­prep four­ni par Mi­cro­soft pour la pré­pa­ra­tion des mas­ters) ;

8. re­dé­mar­rer sous Gla­zier afin d’ef­fec­tuer la per­son­na­li­sa­tion dé­taillée du poste : • ins­tal­ler les ap­pli­ca­tions ; • ins­tal­ler les pi­lotes ; • per­son­na­li­ser le sys­tème d’ex­ploi­ta­tion ;

• et réa­li­ser toute autre tâche spé­ci­fique de confi­gu­ra­tion du poste à dé­ployer ;

9. net­toyer tous les fi­chiers d’ins­tal­la­tion ré­si­duels et re­dé­mar­rer le poste une fois la confi­gu­ra­tion to­ta­le­ment fi­na­li­sée. La pre­mière concep­tion d’une confi­gu­ra­tion com­plète du dé­but à la fin peut être longue et la­bo­rieuse. Néan­moins, une fois qu’elle est ef­fec­tuée, les mo­di­fi­ca­tions ul­té­rieures sont sou­vent in­si­gni­fiantes et il devient très simple de la di­ver­si­fier en dif­fé­rentes confi­gu­ra­tions lorsque vous avez une bonne base.

Fi­chiers de confi­gu­ra­tion

L’uti­li­sa­tion de simples fi­chiers textes peu sem­bler sur­pre­nante pour un sys­tème de ges­tion d’images sys­tème, néan­moins ils re­pré­sentent l ’une des op­tions les plus puis­santes et les plus souples. Les sys­tèmes of­frant une in­ter­face gra­phique li­mitent les ad­mi­nis­tra­teurs aux fonc­tion­na­li­tés et pos­si­bi­li­tés di­verses pro­po­sées dans l’in­ter­face créée par l’édi­teur. Les don­nées gé­rées de fa­çon sous­ja­cente à la­dite in­ter­face sont sou­vent mas­quées et in­ac­ces­sibles. Avec Gla­zier, les fi­chiers de confi­gu­ra­tion gèrent vos don­nées d’images sous une forme na­tu­relle et fa­cile à mo­di­fier.

Choix d’un édi­teur

Vous pou­vez assurer la main­te­nance des confi­gu­ra­tions Gla­zier avec l’édi­teur de votre choix, ce qui veut dire que des mil­liers d’op­tions sont dis­po­nibles, gra­tui­te­ment, sur chaque pla­te­forme. YAML étant un stan­dard ou­vert, un édi­teur de texte le sup­por­tant vous sim­pli­fie­ra la vie, ne se­rait-ce que grâce à la co­lo­ra­tion syn­taxique au­to­ma­tique.

Contrôle de ver­sion

Comme tout code in­for­ma­tique, les fi­chiers textes de Gla­zier sont par­fai­te­ment adap­tés à un sys­tème de contrôle de ver­sion. Il est for­te­ment re­com­man­dé de main­te­nir votre ar­bo­res­cence de confi­gu­ra­tion Gla­zier – et tous les

scripts as­so­ciés – via un CVS. Ce­la vous ap­por­te­ra de nom­breux avan­tages, tels que :

• un his­to­rique com­plet des mo­di­fi­ca­tions de votre en­vi­ron­ne­ment de ges­tion d’images ;

• la pos­si­bi­li­té de re­ve­nir en ar­rière à tout mo­ment en re­char­geant une an­cienne confi­gu­ra­tion ;

• la pos­si­bi­li­té d’im­plé­men­ter une éva­lua­tion des mo­di­fi­ca­tions, comme avec du code « clas­sique ».

Test & si­mu­la­tion

Au­to­build est le client cen­tral des fi­chiers de confi­gu­ra­tion dans le sys­tème Gla­zier, mais comme les fi­chiers textes sont ba­sés sur le stan­dard ou­vert YAML, les ad­mi­nis­tra­teurs peuvent im­plé­men­ter de nou­veaux par­sers de confi­gu­ra­tion dans n’im­porte quel lan­gage ou pour n’im­porte quelle plate-forme. Une uti­li­sa­tion pra­tique de ce concept est de tes­ter les fra­me­works. Il est ai­sé d’écrire du code qui va consom­mer les fi­chiers de confi­gu­ra­tion dans le but d’ef­fec­tuer des tests de concep­tion ou de l’au­dit de confi­gu­ra­tion. Une autre pos­si­bi­li­té est la si­mu­la­tion de concep­tion. Les fi­chiers de confi­gu­ra­tion peuvent être par­sés et re­tra­cés, des­si­nés ou im­pri­més pour ob­ser­ver leur com­por­te­ment lors­qu’ils sont ali­men­tés avec des don­nées ar­bi­traires, sans avoir be­soin d’em­ployer du ma­té­riel phy­sique ou de dé­pendre de dé­lais in­hé­rents à l’exé­cu­tion de l’ins­tal­la­tion d’un poste – phy­sique comme vir­tuel.

Dis­tri­bu­tion de fi­chiers

Gla­zier re­pose for­te­ment sur les pro­to­coles HTTP et HTTPS comme mé­ca­nismes de dis­tri­bu­tion de conte­nu. Le HTTP a été choi­si pour di­verses rai­sons, dont prin­ci­pa­le­ment les sui­vantes :

• c’est un pro­to­cole ou­vert et om­ni­pré­sent ;

• il existe de nom­breuses im­plé­men­ta­tions libres et gra­tuites de ser­veurs HTTP ;

• il existe des mé­thodes lar­ge­ment uti­li­sées pour dis­tri­buer de ma­nière glo­bale des don­nées via le HTTP ; Le HTTPS, la ver­sion sé­cu­ri­sée du HTTP, est for­te­ment re­com­man­dé lors­qu’il est dis­po­nible. Dans un en­vi­ron­ne­ment Gla­zier, les ser­veurs web conservent tous les conte­nus à dis­po­si­tion, à l’ex­cep­tion du mé­dia de boot ini­tial. Ce­la in­clue tous les fi­chiers de confi­gu­ra­tion ain­si que les bi­naires (ins­tal­la­teurs, images et autres) et les scripts. Quand Au­to­build s’exé­cute, il ré­cu­père ces fi­chiers à la de­mande. C’est à l’ad­mi­nis­tra­teur de dé­ci­der comment struc­tu­rer de ma­nière pré­cise les fi­chiers dans le ser­vice web et comment dé­ployer les fi­chiers vers le ser­vice web. Dans un en­vi­ron­ne­ment de test, l’ad­mi­nis­tra­teur peut sim­ple­ment pla­cer et édi­ter les fi­chiers di­rec­te­ment sur le ser­veur web. Dans un en­vi­ron­ne­ment de pro­duc­tion, il est re­com­man­dé de dé­ve­lop­per un sys­tème de dé­ploie­ment plus for­mel. Idéa­le­ment, il de­vrait être pos­sible de syn­chro­ni­ser du conte­nu à par­tir d’un sys­tème de contrôle de ver­sion di­rec­te­ment vers le ser­veur web.

Py­thon

Gla­zier est im­plé­men­té en Py­thon, lan­gage libre et mul­ti plate- forme. Cer­taines par­ties de Gla­zier dé­pendent de fonct ion­na­li­tés spé­ci - fiques à Win­dows, comme WMI ( Win­dows Ma­na­ge­ment Ins­tru­men­ta­tion). Ce­la ne veut pas dire qu’il ne peut pas être por­té sous d’autres sys­tèmes d’ex­ploi­tat ion, mais ce­la de­man­de­ra un tra­vail sup­plé­men­taire d’adap­ta­tion. Py­thon né­ces­site un in­ter­pré­teur adap­té au sys­tème d’ex­ploi­ta­tion sur le­quel Gla­zier s’exé­cute. Les in­ter­pré­teurs Py­thon pour Win­dows sont dis­po­nibles gra­tui­te­ment. Gla­zier n’est pas four­ni sous forme de code com­pi­lé. Les fi­chiers Py­thon de Gla­zier peuvent être li­bre­ment ou­verts et mo­di­fiés. C’est l’une de ses plus grandes forces : en lan­gage Py­thon, avec juste quelques connais sances, vous pou­vez ai­sé­ment étendre Gla­zier avec des fonc­tion­na­li­tés per­son­na­li­sées.

La page de la spé­ci­fi­ca­tion YAML de concep­tion de Gla­zier (https:// gi­thub.com/ google/ gla­zier/blob/ mas­ter/doc/ yaml/in­dex. md) pré­sente de ma­nière dé­taillée le for­mat des fi­chiers de confi­gu­ra­tion de Gla­zier.

Vous trou­ve­rez Gla­zier et les autres pro­jets Google sur le dé­pôt à l’adresse https://gi­thub. com/google.

Matt LaP­lante, ad­mi­nis­tra­teur sys­tème chez Google, a dé­po­sé le code de Gla­zier sur Gi­tHub : https://gi­thub. com/google/ gla­zier.

L’ADK (As­sess­ment and De­ploy­ment Kit) de Mi­cro­soft pro­pose di­vers ou­tils de dé­ploie­ment in­con­tour­nables tels que l’ACT, USMT et des images de dé­mar­rage WinPE.

Newspapers in French

Newspapers from France

© PressReader. All rights reserved.