@@ -1513,20 +1519,223 @@ Table des temps de déploiement d'une grande image _Windows 10_ dans plusieurs f
...
@@ -1513,20 +1519,223 @@ Table des temps de déploiement d'une grande image _Windows 10_ dans plusieurs f
Plusieurs choses
Ces mesures permettent de se rendre contre de plusieurs faits
remarquables, qui ne sont pas forcément intuitifs.
Sur des très petites images le déploiement au format _raw_ compressé
avec _gzip_ est plus rapide que le déploiement avec _Clonezilla_. Ceci
peut s'expliquer par le fait que _Clonezilla_ prend du temps pour créer
une table des partitions, un système de fichiers pour chacune de ces
partitions et copie ensuite les blocs un à un sur chaque système de
fichiers. Sur une grande image, ce mode de fonctionnement est "rentable"
car il y a beaucoup de blocs qui n'auront pas à être copiés, alors
qu'une image _raw_ devra passer du temps à copier les données de chacun
de ces blocs. Sur une très petite image comme l'image _Debian_ mesurée
ici, presque tous les blocs du système de fichiers sont déjà utilisés,
donc la copie brute des données des partitions est plus rapide car tout
le temps est passé à copier les données.
Sur les plus grosses images, cependant, _Clonezilla_ a clairement
l'avantage, car de nombreux blocs vides n'ont pas besoin d'être copiés.
Ainsi, avec les images plus larges utilisées dans les mesures, le temps
de déploiement des images plus larges au format _raw_ prend environ 5 à
9 fois plus de temps que le temps de déploiement avec _Clonezilla_.
Un autre fait remarquable est que le déploiement d'une image _raw_ déjà
mise en cache prend plus de temps que le déploiement avec une copie
simultanée dans le cache. Cela s'explique peut être par le fait que dans
le premier cas, des données doivent être lues depuis le disque et
écrites sur le même disque, tandis que dans le second cas, seule de
l'écriture est effectuée.
Par contre, dans le cas des images _Clonezilla_, le déploiement d'une
image déjà présente en cache s'effectue plus rapidement que le
déploiement d'une image présente en cache. C'est l'inverse de ce qui se
passe avec les images _raw_. Cela s'explique par le fait que les images
_Clonezilla_ sont copiées avant d'être déployées, alors que les images
_raw_ sont copiées et déployées simultanément.
Il est important de se rappeller que les mesures montrées ici sont
effectuées dans des circonstances idéales: il n'y a qu'un seul client
qui télécharge l'image, seul un switch réseau sépare le client du
serveur et le client et le serveur sont les appareils connectés à ce
réseau local. Dans des conditions réelles, plusieurs machines seront
fréquemment en train de télécharger des images depuis le serveur en même
temps. Dans ce cas, le temps de déploiement d'une image non présente en
cache risque de prendre beaucoup plus de temps. Au contraire, le
déploiement d'une image déjà mise en cache devrait théoriquement prendre
le même temps que dans ces circonstances idéales.
## Amélioration des scripts de déploiement
## Amélioration des scripts de déploiement
**TODO: Expliquer les problèmes rencontrés avec les scripts de
De très nombreuses améliorations ont été apportées aux scripts de
déploiement initiaux et les nombreuses améliorations apportées par leur
déploiement, au point qu'ils sont presque complètement différents des
ré-écriture
scripts initiaux.
quasi-complète (gestion des erreurs, stack traces, amélioration des
logs, gestion des images plus grandes que le cache, mesure des timings,
### Gestion des erreurs
scripts utilitaires de maintenance, possibilité d'utiliser clonezilla,
détection du point d'entrée EFI).**
Premièrement, la gestion des erreurs, inexistante dans le script initial
a été rajoutée. Les codes de retour des commandes sont vérifiés et les
données récupérées depuis la sortie de ces commandes sont validées avant
utilisation. Si un code de retour ou une donnée récupérée n'est pas au
format attendu, une fonction spéciale `fatal_error` est appelée avec
comme argument un message d'erreur adapté à la situation. Cette fonction
va afficher le message d'erreur, ainsi qu'une trace de la pile des
appels (_stack trace_ en anglais). Cette trace permet d'identifier
précisément à quelle ligne de quel fonction et dans quel fichier une
erreur a eu lieu.
Finalement, le script de déploiement `bootiful-deploy` sera quitté avec
un code d'erreur, ce qui permet au script parent, `bootiful-init`, de
détecter qu'une erreur a eu lieu et de proposer à l'utilisateur quelle
action il souhaite effectuer parmi les choix suivants:
- Recommencer le déploiement
- Redémarrer la machine
- Éteindre la machine
- Ouvrir un _shell_ interactif (`/bin/bash`) pour étudier la cause de
l'erreur. Une fois le _shell_ terminé, l'utilisateur peut à nouveau
choisir ce qu'il souhaite faire.
Le mécanisme de gestion d'erreurs a été très utile lors du développement
et du test des scripts de déploiement pour comprendre pourquoi certaines
erreurs arrivaient et adapter les scripts pour les éviter. Ce mécanisme
sera aussi utile pour aider un futur administrateur du système à
comprendre ce qu'il se passe si un déploiement ne se déroule pas comme
prévu.
### Mesure du temps écoulé
Un système permettant de mesurer et d'afficher le temps passé dans
chaque section du script de déploiement a été créé. Il permet de mesurer
chacune des parties et d'afficher le temps passé dans chaque partie à la
fin du script. Les parties mesurées sont classées en deux catégories:
_batch_ et _interactive_. Les parties _batch_ sont celles qui sont
exécutées automatiquement, sans intervention de l'utilisateur, tandis
que les parties _interactive_ sont celles où le système attend un choix
de l'utilisateur, comme par exemple le choix de l'image à déployer.
Cette catégorisation des parties permet d'afficher à la fin du script
combien de temps a été passé dans les parties _batch_ sans prendre en
compte le temps passé à attendre un choix de l'utilisateur.
### Amélioration des logs
Plusieurs améliorations ont été apportées au mécanisme de logging. Dans
le système initial, les flux `stdin` et `stdout` du script de
déploiement étaient redirigés vers un fichier de log sur le serveur.
Cela permet d'étudier à _posteriori_ comment le déploiement s'est
effectué, et de vérifier la durée d'exécution. Cela permet aussi de
comprendre ce qui s'est mal passé en cas d'erreur.
Dans le système initial, étant donné que les flux sont redirigés vers un
fichier, un écran noir est affiché sur l'écran du poste client. Cela a
l'inconvénient de ne pas permettre à l'utilisateur du poste client de
savoir ce qu'il est en train de se passer. Il n'est pas possible pour
l'utilisateur de savoir si le déploiement est en cours ou s'il est
bloqué sur une étape. La première modification apportée au système de
logging a été d'utiliser la commande `tee` pour écrire dans les fichiers
de log, au lieu d'une simple redirection. Cela permet aux sorties d'être
simultanément affichées sur l'écran du client et sauvegardée dans les
logs.
De nombreux textes informatifs ont aussi été rajoutés dans la sortie du
script pour expliquer ce qu'il est en train de se passer petit à petit.
Cela permet de mieux contextualiser chaque ligne de log. Une barre de
progression a aussi été rajoutée lors du déploiement d'une image au
format _raw_ pour que l'utilisateur puisse suivre la progression du
déploiement et qu'il puisse voir le temps écoulé ainsi qu'une estimation
du temps restant.
Le mécanisme initial de logging créait un fichier de log par poste
client, en le nommant avec l'adresse <abbrtitle="Media Access Control (address): adresse physique ">MAC</abbr> du poste. Chaque
déploiement successif était loggué dans ce même fichier. Pour bien
différencier le début et la fin d'un log, une ligne facilement
reconnaissable contenant la date et l'heure était affichée. Il y a
plusieurs problèmes avec ce système:
- Les fichiers de log peuvent devenir très gros après de nombreux
déploiements.
- Le nettoyage du dossier de logs pour ne garder que les plus récents
est compliqué, car chaque fichier contient les logs de plusieurs
déploiements.
- La manipulation avec des commandes standard telles que `grep`, `awk`,
`tail` du log d'un déploiement précis est compliqué.
- La comparaison de deux logs de déploiement sur la même machine est
difficile car il faut trouver où les déploiements commencent et se
terminent dans le même fichier.
Le système de log a donc été modifié pour qu'un fichier par déploiement
soit créé par déploiement. Chaque fichier de log est nommé selon
l'adresse mac de la machine ainsi que la date et l'heure du début du
déploiement.
### Intégration de _Clonezilla_ comme type d'image
Le script de déploiement a été modifié pour pouvoir détecter si une
image est au format _raw_ ou s'il s'agit d'une image _Clonezilla_. Selon
le type d'image, des stratégies différentes sont utilisées pour
différentes étapes du déploiement:
- Détermination de la place nécessaire sur le disque pour déployer
l'image
- Commandes utilisées pour le déploiement
- Détermination du point d'entrée EFI.
### Détection automatique du point d'entrée <abbr title="Extensible Firmware Interface: interface micrologicielle extensible unifiée ">EFI</abbr>
Si l'image est au format _Clonezilla_, le script de déploiement est
capable de déterminer automatiquement quel sera le programme
<abbrtitle="Extensible Firmware Interface: interface micrologicielle extensible unifiée ">EFI</abbr> qui sera exécuté au prochain démarrage pour démarrer
l'<abbrtitle="Operating System: système d’exploitation ">OS</abbr> déployé.
En effet, les images _Clonezilla_ de systèmes <abbrtitle="Extensible Firmware Interface: interface micrologicielle extensible unifiée ">EFI</abbr> contiennent
un fichier spécial, `efi-nvram.dat`, qui contient les variables
contenues dans la <abbrtitle="Non-Volatile Random Access Memory: mémoire vive non volatile ">NVRAM</abbr> du système <abbrtitle="Extensible Firmware Interface: interface micrologicielle extensible unifiée ">EFI</abbr> au moment
de la création de l'image. Cette mémoire contient notemment l'ordre des
entrées de boot et les programmes <abbrtitle="Extensible Firmware Interface: interface micrologicielle extensible unifiée ">EFI</abbr> à exécuter pour chacune
de ces entrées, si applicable.
Par exemple, voici le contenu du fichier `nvram.dat` de l'image _Windows
10_ mentionnée dans les sections précédentes:
```bash
BootCurrent: 0001
Timeout: 0 seconds
BootOrder: 0000,0001
Boot0000* Windows Boot Manager HD(1,GPT,0cccfd69-e584-4e2d-8a5d-6afa7130fcab,0x800,0x15e000) /File(\EFI\Microsoft\Boot\bootmgfw.efi) WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}....................
Boot0001* UEFI: USB DISK 3.0 PMAP PciRoot(0x0)/Pci(0x14,0x0)/USB(16,0)/CDROM(1,0x344,0x5e00)..BO
```
Le script de déploiement est capable de lire ce fichier, de trouver la
première entrée contenant un chemin vers un exécutable <abbrtitle="Extensible Firmware Interface: interface micrologicielle extensible unifiée ">EFI</abbr>,
et transformer ce chemin en un chemin _Unix_, c'est à dire avec
le caractère `/` au lieu de `\` et des noms de dossiers et fichiers
sensibles à la casse, qui correspondent à des dossiers et fichiers
présents sur la partition <abbr title="EFI System Partition: partition système EFI ">ESP</abbr> qui vient d'être déployée.
Cette conversion est importante car ce chemin devra être passé à
<abbr title="GRand Unified Bootloader ">GRUB</abbr>, qui ne sait lire que des chemins au format _Unix_.
Une fois le point d'entrée déterminé un fichier `efi_entrypoint` est
écrit à la racine de la partition <abbr title="EFI System Partition: partition système EFI ">ESP</abbr>. Il sera ensuite lu par
<abbr title="GRand Unified Bootloader ">GRUB</abbr> au prochain démarrage pour trouver le point d'entrée à
exécuter. Le contenu de ce fichier ressemblera à ceci:
```bash
set efi_entrypoint=/efi/Microsoft/Boot/bootmgfw.efi
```
Si l'image est au format _raw_, ou alors qu'il est souhaité
d'outrepasser la lecture automatique du point d'entrée d'une image
_Clonezilla_, il suffit de rajouter un fichier `efi_entrypoint` dans le
dossier de l'image. Ce fichier sera directement copié dans
l'<abbr title="EFI System Partition: partition système EFI ">ESP</abbr>, sans qu'une tentative de détermination automatique du
point d'entrée à partir du fichier `nvram.dat` soit effectuée.
## Personnalisation d'images post-déploiement
## Personnalisation d'images post-déploiement
Un système de personnalisation
**TODO: expliquer pourquoi Ansible a été choisi pour cette tache, et des
**TODO: expliquer pourquoi Ansible a été choisi pour cette tache, et des
avantages que cela apporte de pouvoir customiser une image
avantages que cela apporte de pouvoir customiser une image
post-déploiement plutôt que d'avoir une multitude d'images pour chaque
post-déploiement plutôt que d'avoir une multitude d'images pour chaque
