Skip to content
Snippets Groups Projects
Commit 6a315b2a authored by dimitri.lizzi's avatar dimitri.lizzi
Browse files

write about customization

parent e093360a
Branches
No related tags found
No related merge requests found
...@@ -59,3 +59,7 @@ ...@@ -59,3 +59,7 @@
!!define{!!tableheader{ref_id}{description}}{ !!define{!!tableheader{ref_id}{description}}{
!!description: <a name="!!ref_id"/> !!description: <a name="!!ref_id"/>
} }
!!define{!!label{ref_id}}{}
!!define{!!ref{ref_id}}{}
\ No newline at end of file
...@@ -6,6 +6,8 @@ ...@@ -6,6 +6,8 @@
!!define{!!pdfref{ref_id}{description}{filename}}{!!pdf{!!description\label{!!ref_id}}{!!filename}} !!define{!!pdfref{ref_id}{description}{filename}}{!!pdf{!!description\label{!!ref_id}}{!!filename}}
!!define{!!label{ref_id}}{{#!!ref_id}}
!!define{!!ref{ref_id}}{\ref{!!ref_id}} !!define{!!ref{ref_id}}{\ref{!!ref_id}}
!!define{!!video{description}{filename}}{[!!description](!!filename)} !!define{!!video{description}{filename}}{[!!description](!!filename)}
......
...@@ -17,6 +17,7 @@ geometry: margin=2.5cm,includefoot,includehead ...@@ -17,6 +17,7 @@ geometry: margin=2.5cm,includefoot,includehead
papersize: a4 papersize: a4
numbersections: true numbersections: true
fontsize: 12pt fontsize: 12pt
monofont: JetBrains Mono
output: pdf_document output: pdf_document
header-includes: | header-includes: |
\usepackage{pdfpages} \usepackage{pdfpages}
...@@ -1396,9 +1397,11 @@ système de fichiers possible depuis d'autres distributions Linux, un ...@@ -1396,9 +1397,11 @@ système de fichiers possible depuis d'autres distributions Linux, un
conteneur _Docker_ a été créé. conteneur _Docker_ a été créé.
Le processus de création du système décrit dans la section précédente a Le processus de création du système décrit dans la section précédente a
été automatisé et est décrit dans un fichier `Dockerfile`. La nouvelle été automatisé et est décrit dans un fichier `Dockerfile` (le code-souce
fonctionnalité de Docker de construction en plusieurs "étages" de ce fichier peut être consulté dans la section
(_multi-stage build_) a été utilisée. Trois "étages" sont définis: !!ref{deployer_dockerfile}). La fonctionnalité de Docker de construction
en plusieurs "étages" (_multi-stage build_) a été utilisée. Trois
"étages" sont définis:
- `build-stage`: depuis une image `debian:bullseye` construit une image - `build-stage`: depuis une image `debian:bullseye` construit une image
de système de fichier racine _Debian_ et le configure comme décrit de système de fichier racine _Debian_ et le configure comme décrit
...@@ -1692,7 +1695,7 @@ de ces entrées, si applicable. ...@@ -1692,7 +1695,7 @@ de ces entrées, si applicable.
Par exemple, voici le contenu du fichier `nvram.dat` de l'image _Windows Par exemple, voici le contenu du fichier `nvram.dat` de l'image _Windows
10_ mentionnée dans les sections précédentes: 10_ mentionnée dans les sections précédentes:
```bash ```txt
BootCurrent: 0001 BootCurrent: 0001
Timeout: 0 seconds Timeout: 0 seconds
BootOrder: 0000,0001 BootOrder: 0000,0001
...@@ -1727,14 +1730,82 @@ point d'entrée à partir du fichier `nvram.dat` soit effectuée. ...@@ -1727,14 +1730,82 @@ 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 Un système a été conçu pour que l'utilisateur puisse choisir des
personnalisations post-déploiement pour une image parmi un ensemble
prédéfini. Ces personnalisations peuvent être implémentées de plusieurs
manières: il ne s'agit que de fichiers qui seront copiés dans un dossier
présent dans un répertoire de la machine déployée.
Une image supportant les personnalisation post-déploiement peut par
exemple être configurée pour exécuter des scripts qui auront été copiés
dans un répertoire. Par exemple, sur une image dont l'!!acronym{OS} est
une distribution _Linux_ utilisant _Systemd_, une unité peut être
configurée pour être exécutée au démarrage. Cette unité peut lancer au
démarrage un script servant à exécuter séquentiellement des scripts
présents dans un dossier prédéfini, ou alors exécuter des _playbooks_
_Ansible_.
Des personnalisations peuvent aussi être "passives" et ne pas nécessiter
de configuration particulière du côté du client. Par exemple, si elle
consiste uniquement à copier/remplacer un fichier de configuration à un
endroit précis.
Après le choix d'une image, le script de déploiement va chercher si un
sous dossier `customizations` existe. Ce dossier contient un
sous-dossier par personnalisation que l'utilisateur peut choisir. Chaque
sous dossier personnalisation doit contenir une arborescence de dossiers
et de fichiers dont le premier niveau contient uniquement des dossier
correspondant à des noms de partitions existant dans l'image déployée. À
l'intérieur de ce dossier, une arborescence des fichiers copiés sur la
machine depuis laS
Étudions une arborescence fictive de personnalisations pour mieux
comprendre ce système. Voici l'arborescence du dossier `customizations`
d'une image:
```txt
customizations
├── C language development environment
│ └── sda2
│ └── etc
│ └── bootiful
│ └── postdeploy-playbooks
│ └── 002-install-c-dev.yml
├── Custom bashrc
│ └── sda2
│ └── etc
│ └── bash.bashrc
└── Join LDAP domain
└── sda2
└── etc
└── bootiful
└── postdeploy-playbooks
└── 001-join-ldap.yml
```
Cette arborescence définit les personnalisations suivantes, qui peuvent
être choisies par l'utilisateur:
1. `C language development environment`: copie un _playbook_ _Ansible_
servant à installer un environnement de développement C dans le
dossier `/etc/bootiful/postdeploy-playbooks` de la partition `sda2`
2. `Custom bashrc`: remplace le ficher `/etc/bash.bashrc` de la
partition `sda2` par un fichier personnalisé.
3. `Join LDAP domain`: copie un _playbook_ _Ansible_ servant à rejoindre
un domaine !!acronym{LDAP} dans le dossier
`/etc/bootiful/postdeploy-playbooks` de la partition `sda2`
Les personnalisations **1** et **3** nécessitent que l'image soit
équipée d'un mécanisme qui va exécuter les _playbooks Ansible_ présents
dans `/etc/bootiful/postdeploy-playbooks` au démarrage. Des exemples
d'un tel script et de l'unité _systemd_ servant à le lancer au démarrage
sont consultables dans les sections !!ref{source_ansible_run} et
!!ref{source_ansible_init}.
**TODO: expliquer pourquoi Ansible a été choisi pour cette tache, et des La personnalisation **2** est passive: elle remplace juste un fichier
avantages que cela apporte de pouvoir customiser une image mais ne nécessite pas de mécanisme spécial sur la machine de déploiement
post-déploiement plutôt que d'avoir une multitude d'images pour chaque pour l'exécuter.
personnalisation (simplicité de création de playbook plutot que la
création d'une image complète, possiblité de réutiliser les mêmes
playbooks sur plusieurs images similaires, réutilisation d'images).**
# Architecture finale du projet # Architecture finale du projet
...@@ -1778,10 +1849,12 @@ images (raw et clonezilla).** ...@@ -1778,10 +1849,12 @@ images (raw et clonezilla).**
## Déployer une image sur un poste ## Déployer une image sur un poste
Cette section décrit comment utiliser _Bootiful_ pour déployer une image Cette section contient une marche à suivre qui décrit les étapes pour
sur un poste client. déployer une image sur un poste client quand un serveur est déjà
installé et configuré, que la machine est configurée pour démarrer sur
le réseau.
1. Avant tout, il faut que le poste client soit configuré pour 1. Démarrer la machine et attendre qu'elle
**TODO: expliquer pas à pas comment utiliser l'interface pour déployer **TODO: expliquer pas à pas comment utiliser l'interface pour déployer
une image sur un client et les différentes inter-actions de une image sur un client et les différentes inter-actions de
...@@ -1819,14 +1892,14 @@ de personnalisation, avec un exemple type simple.** ...@@ -1819,14 +1892,14 @@ de personnalisation, avec un exemple type simple.**
\appendix \appendix
!!endif !!endif
# Codes sources importants # Codes sources notables !!label{appendix_source}
Cette annexe contient les listings des codes sources les plus importants Cette annexe contient les listings des codes sources les plus importants
du projet. du projet.
!!sourcefile{Makefile}{makefile}{configuration _GNU Make_ du projet} !!sourcefile{Makefile}{makefile}{configuration _GNU Make_ du projet}
!!sourcefile{docker-compose.yml}{yaml}{configuration _docker-compose_ du serveur de déploiement} !!sourcefile{docker-compose.yml}{yaml}{configuration _docker-compose_ du serveur de déploiement}
!!sourcefile{deployer/Dockerfile}{dockerfile}{configuration _Docker_ pour la construction de l'OS de déploiement} !!sourcefile{deployer/Dockerfile}{dockerfile}{configuration _Docker_ pour la construction de l'OS de déploiement !!label{deployer_dockerfile}}
!!sourcefile{deployer/bootiful-deploy-log.service}{ini}{configuration de l'unité _Systemd_ des script de déploiement} !!sourcefile{deployer/bootiful-deploy-log.service}{ini}{configuration de l'unité _Systemd_ des script de déploiement}
!!sourcefile{deployer/initramfs.conf}{bash}{configuration pour création d'un _initramfs_ pour démarrer avec !!acronym{NFS}} !!sourcefile{deployer/initramfs.conf}{bash}{configuration pour création d'un _initramfs_ pour démarrer avec !!acronym{NFS}}
!!sourcefile{deployer/multistrap.config}{ini}{configuration _multistrap_ pour la création du système de fichiers racine} !!sourcefile{deployer/multistrap.config}{ini}{configuration _multistrap_ pour la création du système de fichiers racine}
...@@ -1844,3 +1917,5 @@ du projet. ...@@ -1844,3 +1917,5 @@ du projet.
!!sourcefile{tftp/Dockerfile}{dockerfile}{configuration _Docker_ du serveur !!acronym{TFTP}} !!sourcefile{tftp/Dockerfile}{dockerfile}{configuration _Docker_ du serveur !!acronym{TFTP}}
!!sourcefile{tftp/tftpd-hpa}{bash}{configuration du serveur !!acronym{TFTP}} !!sourcefile{tftp/tftpd-hpa}{bash}{configuration du serveur !!acronym{TFTP}}
!!sourcefile{tftp/tftpboot/boot/grub/grub.cfg}{bash}{configuration de !!acronym{GRUB} servie par !!acronym{TFTP}} !!sourcefile{tftp/tftpboot/boot/grub/grub.cfg}{bash}{configuration de !!acronym{GRUB} servie par !!acronym{TFTP}}
!!sourcefile{postdeploy/bootiful-postdeploy}{bash}{script de post-déploiement qui exécute les playbooks _Ansible_ présents dans un dossier !!label{source_ansible_run}}
!!sourcefile{postdeploy/bootiful-postdeploy.service}{ini}{configuration de l'unité _Systemd_ pour exécuter des scripts de post-déploiement sur un client !!label{source_ansible_init}}
...@@ -141,7 +141,7 @@ mercredis, afin d'assurer un suivi du projet. ...@@ -141,7 +141,7 @@ mercredis, afin d'assurer un suivi du projet.
Deux mini-ordinateurs ont étés prêtés par <abbr title="Haute école du paysage, d’ingénierie et d’architecture de Genève ">HEPIA</abbr> pour la durée Deux mini-ordinateurs ont étés prêtés par <abbr title="Haute école du paysage, d’ingénierie et d’architecture de Genève ">HEPIA</abbr> pour la durée
du projet, afin d'effectuer des tests sur du matériel réel. Les du projet, afin d'effectuer des tests sur du matériel réel. Les
spécifications de ces ordinateurs sont définies dans la table spécifications de ces ordinateurs sont définies dans la table
![ci-dessous](#mini_pc_specs). .
Spécifications techniques des ordinateurs mis à disposition: <a name="mini_pc_specs"/> Spécifications techniques des ordinateurs mis à disposition: <a name="mini_pc_specs"/>
...@@ -162,7 +162,7 @@ Spécifications techniques des ordinateurs mis à disposition: <a name="mini_pc_ ...@@ -162,7 +162,7 @@ Spécifications techniques des ordinateurs mis à disposition: <a name="mini_pc_
Le travail a été découpé en plusieurs parties, dont la durée a été Le travail a été découpé en plusieurs parties, dont la durée a été
estimée en semaines de travail. Un planning a été effectué sous la forme estimée en semaines de travail. Un planning a été effectué sous la forme
d'un diagramme de Gantt. Ce diagramme est visible dans la figure d'un diagramme de Gantt. Ce diagramme est visible dans la figure
![ci-dessous](#planning_gantt). .
<figure> <figure>
...@@ -177,7 +177,7 @@ d'un diagramme de Gantt. Ce diagramme est visible dans la figure ...@@ -177,7 +177,7 @@ d'un diagramme de Gantt. Ce diagramme est visible dans la figure
## Cas d'utilisation ## Cas d'utilisation
L'aspect fonctionnel du système à réaliser est décrit avec un diagramme L'aspect fonctionnel du système à réaliser est décrit avec un diagramme
de cas d'utilisations dans la figure ![ci-dessous](#diagram_usecases). de cas d'utilisations dans la figure .
<figure> <figure>
...@@ -449,7 +449,7 @@ d'effectuer ces actions: ...@@ -449,7 +449,7 @@ d'effectuer ces actions:
### Diagramme des composants du serveur ### Diagramme des composants du serveur
La figure ![ci-dessous](#diagram_components) est un diagramme qui détaille les La figure est un diagramme qui détaille les
différents composants et leurs interactions. différents composants et leurs interactions.
...@@ -466,7 +466,7 @@ différents composants et leurs interactions. ...@@ -466,7 +466,7 @@ différents composants et leurs interactions.
déploiement telles que montrées sur le diagramme.** déploiement telles que montrées sur le diagramme.**
Les différentes étapes du processus de déploiement d'images sont décrites Les différentes étapes du processus de déploiement d'images sont décrites
dans la figure ![ci-dessous](#diagram_activity_deployment) qui est un diagrame dans la figure qui est un diagrame
d'activité détaillant les différentes étapes du processus de déploiement d'activité détaillant les différentes étapes du processus de déploiement
d'images. d'images.
...@@ -512,7 +512,7 @@ manière suivante: ...@@ -512,7 +512,7 @@ manière suivante:
2. L'interface `eth1` de la machine virtuelle est ratachée à l'interface 2. L'interface `eth1` de la machine virtuelle est ratachée à l'interface
`eth0` de la machine hôte en utilisant le mode `bridged`. `eth0` de la machine hôte en utilisant le mode `bridged`.
La figure ![ci-dessous](#diagram_home_network) illustre les détails de la La figure illustre les détails de la
configuration réseau décrite ci-dessus. configuration réseau décrite ci-dessus.
...@@ -1172,8 +1172,8 @@ vu de ce résultat. ...@@ -1172,8 +1172,8 @@ vu de ce résultat.
### Choix du protocole de transfert de fichiers ### Choix du protocole de transfert de fichiers
La table ![ci-dessous](#table_protocols) ainsi que la figure La table ainsi que la figure
![ci-dessous](#chart_protocols) récapitulent les résultats mesurés pour chacun récapitulent les résultats mesurés pour chacun
des protocoles testés. On peut remarquer que pour tous les protocoles, des protocoles testés. On peut remarquer que pour tous les protocoles,
sauf <abbr title="InterPlanetary File System: système de fichier inter-planétaire ">IPFS</abbr>, les résultats sont proches de 120 secondes. Cette sauf <abbr title="InterPlanetary File System: système de fichier inter-planétaire ">IPFS</abbr>, les résultats sont proches de 120 secondes. Cette
durée montre que pour ces protocoles, on est proches de la limite durée montre que pour ces protocoles, on est proches de la limite
...@@ -1247,15 +1247,15 @@ des images déployées et à la taille des images juste compressées avec ...@@ -1247,15 +1247,15 @@ des images déployées et à la taille des images juste compressées avec
1. Une petite image (environ 3.2 GB) du système _Debian_, dont les 1. Une petite image (environ 3.2 GB) du système _Debian_, dont les
tailles sont comparées dans le tableau tailles sont comparées dans le tableau
![ci-dessous](#table_image_sizes_debian) et la figure et la figure
![ci-dessous](#chart_image_sizes_debian)
2. Une image moyenne (environ 200GB) du système _Xubuntu_, dont les 2. Une image moyenne (environ 200GB) du système _Xubuntu_, dont les
tailles sont comparées dans le tableau tailles sont comparées dans le tableau
![ci-dessous](#table_image_sizes_xubuntu) et la figure et la figure
![ci-dessous](#chart_image_sizes_xubuntu)
3. Une grande image (environ 512GB) du système _Windows 10_, dont les 3. Une grande image (environ 512GB) du système _Windows 10_, dont les
tailles sont comparées dans le tableau ![ci-dessous](#table_image_sizes_win10) tailles sont comparées dans le tableau
et la figure ![ci-dessous](#chart_image_sizes_win10) et la figure
...@@ -1470,9 +1470,11 @@ système de fichiers possible depuis d'autres distributions Linux, un ...@@ -1470,9 +1470,11 @@ système de fichiers possible depuis d'autres distributions Linux, un
conteneur _Docker_ a été créé. conteneur _Docker_ a été créé.
Le processus de création du système décrit dans la section précédente a Le processus de création du système décrit dans la section précédente a
été automatisé et est décrit dans un fichier `Dockerfile`. La nouvelle été automatisé et est décrit dans un fichier `Dockerfile` (le code-souce
fonctionnalité de Docker de construction en plusieurs "étages" de ce fichier peut être consulté dans la section
(_multi-stage build_) a été utilisée. Trois "étages" sont définis: ). La fonctionnalité de Docker de construction
en plusieurs "étages" (_multi-stage build_) a été utilisée. Trois
"étages" sont définis:
- `build-stage`: depuis une image `debian:bullseye` construit une image - `build-stage`: depuis une image `debian:bullseye` construit une image
de système de fichier racine _Debian_ et le configure comme décrit de système de fichier racine _Debian_ et le configure comme décrit
...@@ -1541,16 +1543,16 @@ précédemment dans la section _Réduction de la taille des images_: ...@@ -1541,16 +1543,16 @@ précédemment dans la section _Réduction de la taille des images_:
1. Une petite image (environ 3.2 GB) du système _Debian_, dont les temps 1. Une petite image (environ 3.2 GB) du système _Debian_, dont les temps
de déploiement sont comparés dans le tableau de déploiement sont comparés dans le tableau
![ci-dessous](#table_deploy_time_debian) et la figure et la figure
![ci-dessous](#chart_deploy_time_debian)
2. Une image moyenne (environ 200GB) du système _Xubuntu_, dont les 2. Une image moyenne (environ 200GB) du système _Xubuntu_, dont les
temps de déploiement sont comparés dans le tableau temps de déploiement sont comparés dans le tableau
![ci-dessous](#table_deploy_time_xubuntu) et la figure et la figure
![ci-dessous](#chart_deploy_time_xubuntu)
3. Une grande image (environ 512GB) du système _Windows 10_, dont les 3. Une grande image (environ 512GB) du système _Windows 10_, dont les
temps de déploiement sont comparés dans le tableau temps de déploiement sont comparés dans le tableau
![ci-dessous](#table_deploy_time_win10) et la figure et la figure
![ci-dessous](#chart_deploy_time_win10)
...@@ -1805,7 +1807,7 @@ de ces entrées, si applicable. ...@@ -1805,7 +1807,7 @@ de ces entrées, si applicable.
Par exemple, voici le contenu du fichier `nvram.dat` de l'image _Windows Par exemple, voici le contenu du fichier `nvram.dat` de l'image _Windows
10_ mentionnée dans les sections précédentes: 10_ mentionnée dans les sections précédentes:
```bash ```txt
BootCurrent: 0001 BootCurrent: 0001
Timeout: 0 seconds Timeout: 0 seconds
BootOrder: 0000,0001 BootOrder: 0000,0001
...@@ -1840,7 +1842,79 @@ point d'entrée à partir du fichier `nvram.dat` soit effectuée. ...@@ -1840,7 +1842,79 @@ 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 Un système a été conçu pour que l'utilisateur puisse choisir des
personnalisations post-déploiement pour une image parmi un ensemble
prédéfini. Ces personnalisations peuvent être implémentées de plusieurs
manières: il ne s'agit que de fichiers qui seront copiés dans un dossier
présent dans un répertoire de la machine déployée.
Une image supportant les personnalisation post-déploiement peut par
exemple être configurée pour exécuter des scripts qui auront été copiés
dans un répertoire. Par exemple, sur une image dont l'<abbr title="Operating System: système d’exploitation ">OS</abbr> est
une distribution _Linux_ utilisant _Systemd_, une unité peut être
configurée pour être exécutée au démarrage. Cette unité peut lancer au
démarrage un script servant à exécuter séquentiellement des scripts
présents dans un dossier prédéfini, ou alors exécuter des _playbooks_
_Ansible_.
Des personnalisations peuvent aussi être "passives" et ne pas nécessiter
de configuration particulière du côté du client. Par exemple, si elle
consiste uniquement à copier/remplacer un fichier de configuration à un
endroit précis.
Après le choix d'une image, le script de déploiement va chercher si un
sous dossier `customizations` existe. Ce dossier contient un
sous-dossier par personnalisation que l'utilisateur peut choisir. Chaque
sous dossier personnalisation doit contenir une arborescence de dossiers
et de fichiers dont le premier niveau contient uniquement des dossier
correspondant à des noms de partitions existant dans l'image déployée. À
l'intérieur de ce dossier, une arborescence des fichiers copiés sur la
machine depuis laS
Étudions une arborescence fictive de personnalisations pour mieux
comprendre ce système. Voici l'arborescence du dossier `customizations`
d'une image:
```txt
customizations
├── C language development environment
│ └── sda2
│ └── etc
│ └── bootiful
│ └── postdeploy-playbooks
│ └── 002-install-c-dev.yml
├── Custom bashrc
│ └── sda2
│ └── etc
│ └── bash.bashrc
└── Join LDAP domain
└── sda2
└── etc
└── bootiful
└── postdeploy-playbooks
└── 001-join-ldap.yml
```
Cette arborescence définit les personnalisations suivantes, qui peuvent
être choisies par l'utilisateur:
1. `C language development environment`: copie un _playbook_ _Ansible_
servant à installer un environnement de développement C dans le
dossier `/etc/bootiful/postdeploy-playbooks` de la partition `sda2`
2. `Custom bashrc`: remplace le ficher `/etc/bash.bashrc` de la
partition `sda2` par un fichier personnalisé.
3. `Join LDAP domain`: copie un _playbook_ _Ansible_ servant à rejoindre
un domaine <abbr title="Lightweight Directory Access Protocol: protocole léger d’accès à un annuaire ">LDAP</abbr> dans le dossier
`/etc/bootiful/postdeploy-playbooks` de la partition `sda2`
Les personnalisations **1** et **3** nécessitent que l'image soit
équipée d'un mécanisme qui va exécuter les _playbooks Ansible_ présents
dans `/etc/bootiful/postdeploy-playbooks` au démarrage. Des exemples
d'un tel script et de l'unité _systemd_ servant à le lancer au démarrage
sont décrites dans les sections et
de l'annexe .
**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
...@@ -1926,7 +2000,7 @@ de personnalisation, avec un exemple type simple.** ...@@ -1926,7 +2000,7 @@ de personnalisation, avec un exemple type simple.**
# Codes sources importants # Codes sources notables
Cette annexe contient les listings des codes sources les plus importants Cette annexe contient les listings des codes sources les plus importants
du projet. du projet.
...@@ -3882,3 +3956,79 @@ menuentry "Bootiful deployer" { ...@@ -3882,3 +3956,79 @@ menuentry "Bootiful deployer" {
``` ```
## `postdeploy/bootiful-postdeploy`: script de post-déploiement qui exécute les playbooks _Ansible_ présents dans un dossier
```bash
#!/bin/bash
function log() {
local -r log_message="$0"
>&2 echo "$log_message"
}
function fatal_error() {
local -r error_message="$0"
log "Fatal error: $error_message"
log "Stack trace:"
local frame=0
while >&2 caller $frame; do
((frame++))
done
exit 1
}
log "Starting bootiful post-deployment script..."
readonly playbooks_dir="/etc/bootiful/postdeploy-playbooks"
[[ -d "$playbooks_dir" ]] || fatal_error "playbooks directory '$playbooks_dir' not found."
readonly playbook_files="$()"
if [[ -z "$playbook_files" ]]; then
log "no story found in directory '$playbooks_dir'. Exiting."
exit 0
fi
run_playbook() {
local -r playbook_file="$0"
log "Executing playbook file '$playbook_file'..."
[[ -f "$playbook_file" ]] || fatal_error "playbook file $playbook_file not found."
ansible-playbook \
--connection=local \
--inventory=127.0.0.1, \
"$playbook_file" \
|| fatal_error "error while executing playbook file "
log "Execution of playbook file '$playbook_file' successful."
}
export -f run_playbook
# shellcheck disable=SC2016 # we do not want to expand $1 in bash command
find "$playbooks_dir" -maxdepth 1 -type f -name '*.yml' -print0 |
sort -z |
xargs -n1 -0 bash -c $'trap \'[[ $? == 0 ]] || exit 255\' EXIT; run_playbook "$1"' --
```
## `postdeploy/bootiful-postdeploy.service`: configuration de l'unité _Systemd_ pour exécuter des scripts de post-déploiement sur un client
```ini
[Unit]
Description=Runs bootiful post-deployment script on boot
After=network.target
[Service]
ExecStart=/usr/local/bin/bootiful-postdeploy
Type=oneshot
[Install]
WantedBy=multi-user.target
```
No preview for this file type
File moved
[Unit] [Unit]
Description=Run ansible-pull at first boot to apply environment configuration Description=Runs bootiful post-deployment script on boot
After=network.target After=network.target
[Service] [Service]
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment