« Conteneurs - systemd » : différence entre les versions
Correction de mise en forme du code de certains titres + ajout de la section "Montages" + ajout d'un encart "attention" à l'intention de l'usage simultané d'une option de montage et d'éphémérité. |
Correction de fautes de Français + ajout d'une précision sur l'utilité du paquet "systemd-container" dans le conteneur + corrections de formatage + ajouts des paramètres de fichier de configuration pour les sections "Éphémérité" et "Non privilégié". |
||
| Ligne 1 : | Ligne 1 : | ||
[[Category:systemd]] | [[Category:systemd]] | ||
[[:Category:Systemd|Systemd]] permet d'exécuter des conteneurs système à la manière de [[lxc|LXC]]. L'avantage de cette solution est qu'elle est extrêmement simple et rapide à mettre en œuvre, ce qui en fait une option de choix pour faire des tests sans prises de tête ou conteneuriser une production | [[:Category:Systemd|Systemd]] permet d'exécuter des conteneurs système à la manière de [[lxc|LXC]]. L'avantage de cette solution est qu'elle est extrêmement simple et rapide à mettre en œuvre, ce qui en fait une option de choix pour faire des tests sans prises de tête ou conteneuriser une production. | ||
Il existe deux façons de procéder: | Il existe deux façons de procéder : | ||
# [[#Systemd-nspawn|Systemd-nspawn]], réalise une exécution simple, manuelle et sans possibilité de quitter le conteneur (il ne rend pas la main et doit être terminé pour cela). Le principal intérêt est selon moi, le test rapide et l'expérimentation de paramètres. | # [[#Systemd-nspawn|Systemd-nspawn]], réalise une exécution simple, manuelle et sans possibilité de quitter le conteneur (il ne rend pas la main et doit être terminé pour cela). Le principal intérêt est selon moi, le test rapide et l'expérimentation de paramètres. | ||
# [[#Machinectl|Machinectl]], s'apparente plus à ''LXC'' (il est pour ''Nspawn'' ce qu'est [[Libvirt]] pour [[Qemu]]) en proposant, | # [[#Machinectl|Machinectl]], s'apparente plus à ''LXC'' (il est pour ''Nspawn'' ce qu'est [[Libvirt]] pour [[Qemu]]) en proposant, notamment, un démarrage automatique configurable des conteneurs avec le système ainsi qu'un attachement/détachement à leur console. La production est envisageable avec cette méthode. | ||
{{info|Une grande partie de cette page est issue de cet [https://www.blog-libre.org/2020/04/17/une-presentation-de-systemd-nspawn/ article source] que je vous encourage à consulter.}} | {{info|Une grande partie de cette page est issue de cet [https://www.blog-libre.org/2020/04/17/une-presentation-de-systemd-nspawn/ article source] que je vous encourage à consulter.}} | ||
| Ligne 21 : | Ligne 21 : | ||
debootstrap --arch amd64 --include=systemd-container buster modèle.buster http://deb.debian.org/debian/ | debootstrap --arch amd64 --include=systemd-container buster modèle.buster http://deb.debian.org/debian/ | ||
le paramètre <source lang="bash" inline>--include=systemd-container</source> permet d'installer ledit paquet dans le système invité. Vous pouvez en préciser plusieurs en les séparent par des virgules. | le paramètre <source lang="bash" inline>--include=systemd-container</source> permet d'installer ledit paquet dans le système invité (au passage, ce paquet doit être présent dans le conteneur pour pouvoir être utilisé avec la fonction <source lang="bash" inline>login</source> de [[#Machinectl|Machinectl]]). Vous pouvez en préciser plusieurs en les séparent par des virgules. | ||
{{attention|Si la commande vous renvoie un message du genre: | {{attention|Si la commande vous renvoie un message du genre: | ||
| Ligne 57 : | Ligne 57 : | ||
==Paramétrage== | ==Paramétrage== | ||
Pour aller plus loin, il est possible de passer un ensemble de paramètres à la ligne de démarrage précédente afin d'affiner l'usage du conteneur. | Pour aller plus loin, il est possible de passer un ensemble de paramètres via un [[#Fichier_de_configuration|fichier de configuration]] propre au conteneur ainsi qu'à la ligne de démarrage précédente (les deux modes de configuration peuvent être combinés) afin d'affiner l'usage du conteneur. Je vous recommande la lecture des pages de manuel (très bien faites) cités en [[#sources|sources]] au bas de la page. | ||
===Réseau=== | ===Réseau=== | ||
Avec la commande précédente, le conteneur va se lancer avec l'ensemble des interfaces réseaux de l'hôte, ce qui peux s'avérer utiles dans les cas où l'on veut proposer un service à un ensemble de VLAN sans routage par exemple. | Avec la commande précédente, le conteneur va se lancer avec l'ensemble des interfaces réseaux de l'hôte, ce qui peux s'avérer utiles dans les cas où l'on veut proposer un service à un ensemble de VLAN sans routage par exemple ou pour exécuter une application comme depuis l'hôte. | ||
Cependant, si l'on veut que notre conteneur soit limité à un ou plusieurs réseaux, il existe une section dédiée dans le [https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#Networking%20Options manuel]. J'affectionne tout particulièrement l'usage de <source lang="bash" inline>--network-interface</source> qui permet de déplacer une interface ''veth'' dans l'espace de nom réseau du conteneur (ces interfaces doivent au préalable être créées). Ce paramètre peut être utilisé plusieurs fois afin de mettre notre système invité dans plusieurs ''VLAN'' par exemple: | Cependant, si l'on veut que notre conteneur soit limité à un ou plusieurs réseaux, il existe une section dédiée dans le [https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html#Networking%20Options manuel]. J'affectionne tout particulièrement l'usage de <source lang="bash" inline>--network-interface</source> qui permet de déplacer une interface ''veth'' dans l'espace de nom réseau du conteneur (ces interfaces doivent au préalable être créées). Ce paramètre peut être utilisé plusieurs fois afin de mettre notre système invité dans plusieurs ''VLAN'' par exemple: | ||
| Ligne 139 : | Ligne 139 : | ||
===Éphémérité=== | ===Éphémérité=== | ||
Il est également possible de lancer le conteneur en mode éphémère via un instantané (avec BTRFS ou XFS) ou via une copie liée ''reflinks'' (avec EXT4) en utilisant le paramètre <source lang="bash" inline>-x</source>. Ceci offre une liberté non négligeable pour vos tests vous puisque vous pouvez tout péter, une extinction supprimera l'instantané et votre conteneur n'aura pas été modifié d'un bit. Cerise sur le gâteau, un redémarrage du conteneur éphémère ne supprime pas cet instantané donc vous pouvez même tester des applications nécessitant un redémarrage contrairement aux [[Squashfs]] ! | Il est également possible de lancer le conteneur en mode éphémère via un instantané (avec ''BTRFS'' ou ''XFS'') ou via une copie liée ''reflinks'' (avec ''EXT4'') en utilisant le paramètre <source lang="bash" inline>-x</source>. Ceci offre une liberté non négligeable pour vos tests vous puisque vous pouvez tout péter, une extinction supprimera l'instantané et votre conteneur n'aura pas été modifié d'un bit. Cerise sur le gâteau, un redémarrage du conteneur éphémère ne supprime pas cet instantané donc vous pouvez même tester des applications nécessitant un redémarrage contrairement aux [[Squashfs]] ! | ||
Encore plus fou, il est possible de conteneuriser son propre système alors qu'il est [https://unix.stackexchange.com/questions/211225/how-do-i-background-a-systemd-nspawn-container lui-même démarré] ! | Encore plus fou, il est possible de conteneuriser son propre système alors qu'il est [https://unix.stackexchange.com/questions/211225/how-do-i-background-a-systemd-nspawn-container lui-même démarré] ! | ||
systemd-nspawn -bxD / | systemd-nspawn -bxD / | ||
Lorsque le conteneur est utilisé avec un [[#Fichier_de_configuration|fichier de configuration]], la journalisation doit être désactivée pour pouvoir le démarrer en mode éphémère. Les paramètres de configuration sont : | |||
<source lang="bash"> | |||
LinkJournal=no | |||
Ephemeral=on | |||
</source> | |||
===Montage=== | ===Montage=== | ||
| Ligne 150 : | Ligne 157 : | ||
====Montage lié==== | ====Montage lié==== | ||
L'outil permet de copier le comportement d'un <source lang="bash" inline>mount --bind</source> via le paramètre <source lang="bash" inline>--bind</source>. En voici un exemple: | L'outil permet de copier le comportement d'un <source lang="bash" inline>mount --bind</source> via le paramètre <source lang="bash" inline>--bind</source>. En voici un exemple : | ||
mkdir -p /tmp/toto/{titi,tata/{tutu,tyty}} | mkdir -p /tmp/toto/{titi,tata/{tutu,tyty}} | ||
systemd-nspawn --bind=/tmp/toto:/mnt -bxD /root/conteneurs/apache/ | systemd-nspawn --bind=/tmp/toto:/mnt -bxD /root/conteneurs/apache/ | ||
| Ligne 167 : | Ligne 174 : | ||
====Montage superposé==== | ====Montage superposé==== | ||
Un ou plusieurs montages superposés (''overlay'') peuvent être ajoutés. Le premier répertoire sert de base en lecture seule et le second enregistre les modifications | Un ou plusieurs montages superposés (''overlay'') peuvent être ajoutés. Le premier répertoire sert de base en lecture seule et le second enregistre les modifications tandis que le troisième sera le point de montage final (son omission présente la même arborescence que l'hôte). | ||
mkdir -p /tmp/{ycharbi/{1,2,3/{3.1,3.2}},lesmorin} | mkdir -p /tmp/{ycharbi/{1,2,3/{3.1,3.2}},lesmorin} | ||
systemd-nspawn --overlay=/tmp/ycharbi:/tmp/lesmorin:/toto -bxD /root/conteneurs/apache/ | systemd-nspawn --overlay=/tmp/ycharbi:/tmp/lesmorin:/toto -bxD /root/conteneurs/apache/ | ||
| Ligne 174 : | Ligne 181 : | ||
===Non privilégié=== | ===Non privilégié=== | ||
Un conteneur ''Nspawn'' peut-être exécuté dans un espace de noms utilisateur afin de cloisonner les | Un conteneur ''Nspawn'' peut-être exécuté dans un espace de noms utilisateur afin de cloisonner les privilèges du ''root'' invité (cela rend encore plus compliqué le piratage du système puisque en plus d'exploiter une faille pour sortir du conteneur, l'attaquant devra également user d'une élévation de privilèges pour nuire) via le paramètre <source lang="bash" inline>-U</source>. | ||
Tout cumulé, on en arrive à la commande suivante: | Tout cumulé, on en arrive à la commande suivante : | ||
systemd-nspawn -b --network-interface=apache_c -xUD /root/conteneurs/apache | systemd-nspawn -b --network-interface=apache_c -xUD /root/conteneurs/apache | ||
Le paramètre de configuration est <source lang="bash" inline>PrivateUsers=pick</source>. | |||
==Fichier de configuration== | ==Fichier de configuration== | ||
Pour chaque conteneurs démarrés, ''Systemd-nspawn'' va regarder le contenu des fichiers de configuration présents dans les répertoires suivants (qui n'existent pas forcément, il suffit de créer celui qui vous chante): | Pour chaque conteneurs démarrés, ''Systemd-nspawn'' va regarder le contenu des fichiers de configuration présents dans les répertoires suivants (qui n'existent pas forcément, il suffit de créer celui qui vous chante) : | ||
* /etc/systemd/nspawn/''machine''.nspawn | * /etc/systemd/nspawn/''machine''.nspawn | ||
* /run/systemd/nspawn/''machine''.nspawn | * /run/systemd/nspawn/''machine''.nspawn | ||
| Ligne 186 : | Ligne 195 : | ||
Vous pouvez donc définir des configurations personnalisées pour chacun des conteneurs que vous exécuterez afin d'alléger leur commande de démarrage. La syntaxe est documenté dans le [https://www.freedesktop.org/software/systemd/man/systemd.nspawn.html manuel dédié]. Ces fichiers sont bien entendus | Vous pouvez donc définir des configurations personnalisées pour chacun des conteneurs que vous exécuterez afin d'alléger leur commande de démarrage (le nom du fichier doit être identique au nom du conteneur). La syntaxe est documenté dans le [https://www.freedesktop.org/software/systemd/man/systemd.nspawn.html manuel dédié]. Ces fichiers sont bien entendus également utilisés par [[#Machinectl|Machinectl]]. Vous pouvez donc paramétrer vos conteneurs gérés par cet outil. | ||
Par exemple, un fichier de configuration correspondant à cette ligne de commande: <source lang="bash" inline>systemd-nspawn -b --network-interface=apache180_c --network-interface=apache181_c -D /root/conteneurs/apache</source> est le suivant (<source lang="bash" inline>/etc/systemd/nspawn/apache.nspawn</source>): | Par exemple, un fichier de configuration correspondant à cette ligne de commande: <source lang="bash" inline>systemd-nspawn -b --network-interface=apache180_c --network-interface=apache181_c -D /root/conteneurs/apache</source> est le suivant (<source lang="bash" inline>/etc/systemd/nspawn/apache.nspawn</source>) : | ||
<source lang="bash"> | <source lang="bash"> | ||
| Ligne 207 : | Ligne 216 : | ||
==Mise en œuvre== | ==Mise en œuvre== | ||
Création d'un conteneur ''Debian Sid'' en ''amd64'' avec les branches de dépôt ''main'', ''contrib'' et ''non-free'' s'appelant "sid1" et comportant le paquet supplémentaire <source lang="bash" inline>systemd-container</source>: | Création d'un conteneur ''Debian Sid'' en ''amd64'' avec les branches de dépôt ''main'', ''contrib'' et ''non-free'' s'appelant "sid1" et comportant le paquet supplémentaire <source lang="bash" inline>systemd-container</source> : | ||
apt install --no-install-recommends debootstrap systemd-container debian-archive-keyring | apt install --no-install-recommends debootstrap systemd-container debian-archive-keyring | ||
| Ligne 216 : | Ligne 225 : | ||
''Note: Vous pouvez sinon tout bêtement copier votre conteneur précédent: <source lang="bash" inline>cp -a /root/conteneurs/buster1 /var/lib/machines/</source>.'' | ''Note: Vous pouvez sinon tout bêtement copier votre conteneur précédent: <source lang="bash" inline>cp -a /root/conteneurs/buster1 /var/lib/machines/</source>.'' | ||
Lors de l'exécution d'un conteneur par l'outil, le modèle de service <source lang="bash" inline>/lib/systemd/system/systemd-nspawn@.service</source> est utilisé. Ce dernier passe un ensemble de paramètres à la commande <source lang="bash" inline>systemd-nspawn</source> (qui lance réellement le conteneur, ''machinectl'' n'étant qu'une interface de gestion), dont le <source lang="bash" inline>-U</source> (utilisateur non privilégié), qui peut se retrouver bloquant pour certaines tâches. Si vous voulez outrepasser cette option, il faut spécifier l'usage du mode privilégié dans le [[#Fichier_de_configuration|fichier de configuration]] propre au conteneur avec le paramètre <source lang="bash" inline>PrivateUsers=0</source>. | |||
==Commandes utiles== | ==Commandes utiles== | ||
Voici les commandes utiles: | Voici les commandes utiles : | ||
{| class="wikitable" | {| class="wikitable" | ||
| Ligne 259 : | Ligne 270 : | ||
=Sources= | =Sources= | ||
* Très largement inspirée: https://www.blog-libre.org/2020/04/17/une-presentation-de-systemd-nspawn/ | * Très largement inspirée: https://www.blog-libre.org/2020/04/17/une-presentation-de-systemd-nspawn/ | ||
* Complémentaires: | * Complémentaires : | ||
** https://wiki.archlinux.org/index.php/Systemd-nspawn | ** https://wiki.archlinux.org/index.php/Systemd-nspawn | ||
** https://cmdref.net/middleware/container/systemd-nspawn/index.html | ** https://cmdref.net/middleware/container/systemd-nspawn/index.html | ||
* Pages de manuels: | * Pages de manuels : | ||
** https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html | ** https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html | ||
** https://www.freedesktop.org/software/systemd/man/systemd.nspawn.html | ** https://www.freedesktop.org/software/systemd/man/systemd.nspawn.html | ||
** https://www.freedesktop.org/software/systemd/man/machinectl.html | ** https://www.freedesktop.org/software/systemd/man/machinectl.html | ||
Version du 14 novembre 2020 à 22:27
Systemd permet d'exécuter des conteneurs système à la manière de LXC. L'avantage de cette solution est qu'elle est extrêmement simple et rapide à mettre en œuvre, ce qui en fait une option de choix pour faire des tests sans prises de tête ou conteneuriser une production.
Il existe deux façons de procéder :
- Systemd-nspawn, réalise une exécution simple, manuelle et sans possibilité de quitter le conteneur (il ne rend pas la main et doit être terminé pour cela). Le principal intérêt est selon moi, le test rapide et l'expérimentation de paramètres.
- Machinectl, s'apparente plus à LXC (il est pour Nspawn ce qu'est Libvirt pour Qemu) en proposant, notamment, un démarrage automatique configurable des conteneurs avec le système ainsi qu'un attachement/détachement à leur console. La production est envisageable avec cette méthode.
INFORMATION
Une grande partie de cette page est issue de cet article source que je vous encourage à consulter.Systemd-nspawn
Installation
Installation des paquets
apt install --no-install-recommends debootstrap systemd-container debian-archive-keyring
Note: seul <source lang="bash" inline>systemd-container</source> est nécessaire au fonctionnement des conteneurs.
Création d'un répertoire d'accueil
mkdir -p ~/conteneurs && cd $_
Importation d'une racine Debian pour le système du conteneur
debootstrap --arch amd64 --include=systemd-container buster modèle.buster http://deb.debian.org/debian/
le paramètre <source lang="bash" inline>--include=systemd-container</source> permet d'installer ledit paquet dans le système invité (au passage, ce paquet doit être présent dans le conteneur pour pouvoir être utilisé avec la fonction <source lang="bash" inline>login</source> de Machinectl). Vous pouvez en préciser plusieurs en les séparent par des virgules.
ATTENTION
{{{1}}}Note: Vous pouvez utiliser ce système comme un modèle que vous copierez afin de faire un nouveau conteneur. Cette pratique est plus rapide si vous n'avez pas de miroir de dépôt local mais n'oubliez pas de mettre à jour le système après la copie (si votre modèle est vieux).
Se connecter au conteneur sans le démarrer (identique à un chroot)
systemd-nspawn -D modèle.buster
Si vous rencontrez une impossibilité de vous connecter au shell de votre conteneur par la suite, il faudra supprimer le fichier de liste blanche des TTY autorisés pour la connexion (/etc/securetty) afin de permettre l'authentification comme suit:
rm /etc/securetty
On assignera enfin un mot de passe root et supprimera l'historique Bash avant de quitter le conteneur.
passwd history -c <ctrl+d>
Copie du modèle
cp -a modèle.buster buster1
Démarrer le conteneur et s'y connecter
systemd-nspawn -bD buster1
Il n'est pas possible de se détacher du conteneur avec cette méthode (pour cela, il faudra se tourner vers Machinectl). Pour sortir, il faut soit éteindre le conteneur (via les commandes habituelles), soit le terminer par la force via la répétition successive de trois fois la combinaison de touches suivante: <source lang="bash" inline><ctrl> + ]</source>.
Paramétrage
Pour aller plus loin, il est possible de passer un ensemble de paramètres via un fichier de configuration propre au conteneur ainsi qu'à la ligne de démarrage précédente (les deux modes de configuration peuvent être combinés) afin d'affiner l'usage du conteneur. Je vous recommande la lecture des pages de manuel (très bien faites) cités en sources au bas de la page.
Réseau
Avec la commande précédente, le conteneur va se lancer avec l'ensemble des interfaces réseaux de l'hôte, ce qui peux s'avérer utiles dans les cas où l'on veut proposer un service à un ensemble de VLAN sans routage par exemple ou pour exécuter une application comme depuis l'hôte.
Cependant, si l'on veut que notre conteneur soit limité à un ou plusieurs réseaux, il existe une section dédiée dans le manuel. J'affectionne tout particulièrement l'usage de <source lang="bash" inline>--network-interface</source> qui permet de déplacer une interface veth dans l'espace de nom réseau du conteneur (ces interfaces doivent au préalable être créées). Ce paramètre peut être utilisé plusieurs fois afin de mettre notre système invité dans plusieurs VLAN par exemple:
<source lang="bash">
- Allumage de l'interface servant les services des conteneurs (reliée à un commutateur matériel)
ip link set eth2 up
- Création du pont avec gestion du 802.1Q
ip link add br0 type bridge vlan_filtering 1 ip link set br0 up
- Ajout de l'interface physique au pont
ip link set eth2 master br0
- Désactivation du VLAN par défaut sur le pont afin de l'isoler
bridge vlan del dev br0 vid 1 self bridge vlan del dev eth2 vid 1 master
- Création et configuration des interfaces VLAN ###
- Interface vlan 180
ip link add link br0 name vlan180 type vlan id 180 ip link set vlan180 up ip address add 2001:db8:0:180::1/64 dev vlan180 bridge vlan add dev br0 vid 180 tagged self bridge vlan add dev eth2 vid 180 tagged master
- Interface vlan 181
ip link add link br0 name vlan181 type vlan id 181 ip link set vlan181 up ip address add 2001:db8:0:181::1/64 dev vlan181 bridge vlan add dev br0 vid 181 tagged self bridge vlan add dev eth2 vid 181 tagged master
- Création du couple de VETH pour interfacer mon conteneur "apache" avec le VLAN 180
ip link add apache180_c type veth peer name apache180_h ip link set apache180_h up ip link set apache180_h master br0 bridge vlan del dev apache180_h vid 1 PVID untagged master bridge vlan add dev apache180_h vid 180 pvid untagged master
- Création du couple de VETH pour interfacer mon conteneur "apache" avec le VLAN 181
ip link add apache181_c type veth peer name apache181_h ip link set apache181_h up ip link set apache181_h master br0 bridge vlan del dev apache181_h vid 1 PVID untagged master bridge vlan add dev apache181_h vid 181 pvid untagged master
- Démarrage de mon conteneur apache
systemd-nspawn -b --network-interface=apache180_c --network-interface=apache181_c -D /root/conteneurs/apache </source>
Le réseau dans mon conteneur est définit comme suit:
vim /root/conteneurs/apache/etc/network/interfaces
<source lang="bash"> auto lo iface lo inet loopback
up /usr/bin/confint
</source>
vim /root/conteneurs/apache/usr/bin/confint
<source lang="bash">
- !/bin/bash
- Configuration des interfaces
ip addr add fd00:0:0:180::a0/64 dev apache180_c ip link set apache180_c up
ip addr add fd00:0:0:181::a0/64 dev apache181_c ip link set apache181_c up </source>
chmod u+x /root/conteneurs/apache/usr/bin/confint
Éphémérité
Il est également possible de lancer le conteneur en mode éphémère via un instantané (avec BTRFS ou XFS) ou via une copie liée reflinks (avec EXT4) en utilisant le paramètre <source lang="bash" inline>-x</source>. Ceci offre une liberté non négligeable pour vos tests vous puisque vous pouvez tout péter, une extinction supprimera l'instantané et votre conteneur n'aura pas été modifié d'un bit. Cerise sur le gâteau, un redémarrage du conteneur éphémère ne supprime pas cet instantané donc vous pouvez même tester des applications nécessitant un redémarrage contrairement aux Squashfs !
Encore plus fou, il est possible de conteneuriser son propre système alors qu'il est lui-même démarré !
systemd-nspawn -bxD /
Lorsque le conteneur est utilisé avec un fichier de configuration, la journalisation doit être désactivée pour pouvoir le démarrer en mode éphémère. Les paramètres de configuration sont :
<source lang="bash"> LinkJournal=no Ephemeral=on </source>
Montage
Il est possible de monter des arborescences dans les conteneurs directement depuis la ligne de commande. Dans le cas d'un usage de ces notions dans un fichier de configuration, il faudra mettre les paramètres adéquats dans la section <source lang="bash" inline>[Files]</source>.
Les options sont combinables.
Montage lié
L'outil permet de copier le comportement d'un <source lang="bash" inline>mount --bind</source> via le paramètre <source lang="bash" inline>--bind</source>. En voici un exemple :
mkdir -p /tmp/toto/{titi,tata/{tutu,tyty}}
systemd-nspawn --bind=/tmp/toto:/mnt -bxD /root/conteneurs/apache/
Ceci aura pour effet de monter le contenu du répertoire /tmp/toto/ de l'hôte dans le répertoire /mnt/ de l'invité (en cas d'omission de ce dernier paramètre, le répertoire sera monté dans le même que l'hôte).
Le paramètre de configuration est <source lang="bash" inline>Bind=/tmp/toto:/mnt</source>.
Montage tmpfs
Il est possible de monter un tmpfs dans le conteneur afin de disposer d'un ramdisk. Après les <source lang="bash" inline>:</source>, les paramètres sont les même que pour un tmpfs traditionnel.
systemd-nspawn --tmpfs=/tmp/ramdisk:rw,size=2G -bxD /root/conteneurs/apache/
Le répertoire /tmp/ramdisk est monté dans l'invité en tmpfs en lecture/écriture et limité à 2Go.
Le paramètre de configuration est <source lang="bash" inline>TemporaryFileSystem=/tmp/ramdisk:rw,size=2G</source>.
Montage superposé
Un ou plusieurs montages superposés (overlay) peuvent être ajoutés. Le premier répertoire sert de base en lecture seule et le second enregistre les modifications tandis que le troisième sera le point de montage final (son omission présente la même arborescence que l'hôte).
mkdir -p /tmp/{ycharbi/{1,2,3/{3.1,3.2}},lesmorin}
systemd-nspawn --overlay=/tmp/ycharbi:/tmp/lesmorin:/toto -bxD /root/conteneurs/apache/
Le paramètre de configuration est <source lang="bash" inline>Overlay=/tmp/ycharbi:/tmp/lesmorin:/toto</source>.
Non privilégié
Un conteneur Nspawn peut-être exécuté dans un espace de noms utilisateur afin de cloisonner les privilèges du root invité (cela rend encore plus compliqué le piratage du système puisque en plus d'exploiter une faille pour sortir du conteneur, l'attaquant devra également user d'une élévation de privilèges pour nuire) via le paramètre <source lang="bash" inline>-U</source>.
Tout cumulé, on en arrive à la commande suivante :
systemd-nspawn -b --network-interface=apache_c -xUD /root/conteneurs/apache
Le paramètre de configuration est <source lang="bash" inline>PrivateUsers=pick</source>.
Fichier de configuration
Pour chaque conteneurs démarrés, Systemd-nspawn va regarder le contenu des fichiers de configuration présents dans les répertoires suivants (qui n'existent pas forcément, il suffit de créer celui qui vous chante) :
- /etc/systemd/nspawn/machine.nspawn
- /run/systemd/nspawn/machine.nspawn
- /var/lib/machines/machine.nspawn
Vous pouvez donc définir des configurations personnalisées pour chacun des conteneurs que vous exécuterez afin d'alléger leur commande de démarrage (le nom du fichier doit être identique au nom du conteneur). La syntaxe est documenté dans le manuel dédié. Ces fichiers sont bien entendus également utilisés par Machinectl. Vous pouvez donc paramétrer vos conteneurs gérés par cet outil.
Par exemple, un fichier de configuration correspondant à cette ligne de commande: <source lang="bash" inline>systemd-nspawn -b --network-interface=apache180_c --network-interface=apache181_c -D /root/conteneurs/apache</source> est le suivant (<source lang="bash" inline>/etc/systemd/nspawn/apache.nspawn</source>) :
<source lang="bash"> [Exec] Boot=on
[Network] Interface=apache180_c Interface=apache181_c </source>
Il est à noté que les paramètres sont à mettre sous les bonnes sections comme dans un service Systemd. Faites-y attention lors de la lecture du manuel.
ATTENTION
{{{1}}}Machinectl
Cet outil ressemble plus à la gestion traditionnelle d'un LXC. Il se base sur Systemd-nspawn (c'est lui qui est appelé en arrière plan) et travail exclusivement dans le répertoire <source lang="bash" inline>/var/lib/machines</source> (là où Systemd-nspawn s'adaptait au paramètre passé).
Mise en œuvre
Création d'un conteneur Debian Sid en amd64 avec les branches de dépôt main, contrib et non-free s'appelant "sid1" et comportant le paquet supplémentaire <source lang="bash" inline>systemd-container</source> :
apt install --no-install-recommends debootstrap systemd-container debian-archive-keyring debootstrap --arch amd64 --include=systemd-container --components=main,contrib,non-free sid /var/lib/machines/sid http://deb.debian.org/debian/ machinectl clone sid sid1 machinectl start sid1 machinectl shell sid1
Note: Vous pouvez sinon tout bêtement copier votre conteneur précédent: <source lang="bash" inline>cp -a /root/conteneurs/buster1 /var/lib/machines/</source>.
Lors de l'exécution d'un conteneur par l'outil, le modèle de service <source lang="bash" inline>/lib/systemd/system/systemd-nspawn@.service</source> est utilisé. Ce dernier passe un ensemble de paramètres à la commande <source lang="bash" inline>systemd-nspawn</source> (qui lance réellement le conteneur, machinectl n'étant qu'une interface de gestion), dont le <source lang="bash" inline>-U</source> (utilisateur non privilégié), qui peut se retrouver bloquant pour certaines tâches. Si vous voulez outrepasser cette option, il faut spécifier l'usage du mode privilégié dans le fichier de configuration propre au conteneur avec le paramètre <source lang="bash" inline>PrivateUsers=0</source>.
Commandes utiles
Voici les commandes utiles :
| Argument | Signification |
|---|---|
| <source lang="bash" inline>machinectl</source> ou <source lang="bash" inline>machinectl list</source> | Liste les conteneurs actifs |
| <source lang="bash" inline>machinectl list-images</source> | Liste les conteneurs sans distinctions |
| <source lang="bash" inline>machinectl start sid1</source> | Démarre le conteneur et rend la main (il se comporte comme un service) |
| <source lang="bash" inline>machinectl poweroff sid1</source> ou <source lang="bash" inline>machinectl stop sid1</source> | Éteint le conteneur sid1 proprement, stop est un alias de poweroff |
| <source lang="bash" inline>machinectl terminate sid1</source> | Tue le conteneur (force l'arrêt) |
| <source lang="bash" inline>machinectl clone sid sid1</source> | Copie le conteneur (un <source lang="bash" inline>cp -a /var/lib/machines/conteneur_source /var/lib/machines/conteneur_destination</source> fait la même chose) |
| <source lang="bash" inline>machinectl remove sid1</source> | Supprime le conteneur (un <source lang="bash" inline>rm -rf /var/lib/machines/conteneur_source conteneur_destination</source> fait la même chose si tant est qu'il est bien arrêté) |
| <source lang="bash" inline>machinectl clean --all</source> | Supprime tout les conteneurs |
| <source lang="bash" inline>machinectl login sid1</source> | Attache un conteneur en passant par l'outil de connexion du système (pour sortir, il faut utiliser la répétition successive de trois fois la combinaison de touches suivante: <source lang="bash" inline><ctrl> + ]</source>) |
| <source lang="bash" inline>machinectl shell sid1</source> | Se connecte automatiquement au conteneur sans demander de mot de passe (identique à un <source lang="bash" inline>chroot</source> ou un <source lang="bash" inline>su - utilisateur</source> depuis root). Pour sortir, il faut faire un <source lang="bash" inline>exit</source> ou <source lang="bash" inline><ctrl> + d</source> |
| <source lang="bash" inline>machinectl enable</source> | Ajoute le conteneur au démarrage système. Cela créer un lien symbolique de /lib/systemd/system/systemd-nspawn@.service dans /etc/systemd/system/machines.target.wants/ |
| <source lang="bash" inline>machinectl disable</source> | Enlève le conteneur du démarrage système |
| <source lang="bash" inline>machinectl copy-to sid1 ~/Documents/proc.jpeg /root/image.jpg</source> | Copie un fichier dans le conteneur (la syntaxe pour un dossier est identique sans paramètres supplémentaires). Est identique à une copie standard mais part de la racine du conteneur |
| <source lang="bash" inline>machinectl copy-from sid1 /root/xyz abc</source> | Même chose dans l'autre sens. Permet de récupérer un fichier/dossier |
| <source lang="bash" inline>machinectl export-tar sid1 /tmp/sid1.tar.gz</source> | Réalise une sauvegarde du conteneur sous forme d'archive compressée (tar.gz) |
| <source lang="bash" inline>machinectl import-tar /tmp/sid1.tar.gz sid2</source> | Importe un conteneur précedemment sauvegardé. En dehors des deux dernières commandes, ces opérations sont réalisables manuellements via les commandes standards. |
Sources
- Très largement inspirée: https://www.blog-libre.org/2020/04/17/une-presentation-de-systemd-nspawn/
- Complémentaires :
- Pages de manuels :