« Conteneurs - systemd » : différence entre les versions

De Wiki doc

(Ajout d'une précision concernant la liste blanche des TTY + ajout des commandes d'import/export + ajout d'une source + correction de fautes.)
(Correction de fautes + ajouts de sections + ajout de la notion de fichiers de configuration + ajout des paramètres 'ajout au démarrage.)
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 (waw j'ai vraiment écrit ça au sujet d'un composant ''Systemd'' ! Comme quoi tout est possible...).
[[: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 (waw j'ai vraiment écrit ça au sujet d'un composant ''Systemd'' ! Comme quoi tout est possible...).


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 éphémère 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'' avec un démarrage automatique possible des conteneurs avec le système (non testé). La production est envisageable avec cette méthode.
# [[#Machinectl|Machinectl]], s'apparente plus à ''LXC'' (il est pour ''Nspawn'' ce qu'est [[Libvirt]] pour [[Qemu]]) en proposant, nottament, 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.}}


=Systemd-nspawn=
=Systemd-nspawn=
==Installation==
'''Installation des paquets'''
'''Installation des paquets'''
  apt install --no-install-recommends debootstrap systemd-container debian-archive-keyring
  apt install --no-install-recommends debootstrap systemd-container debian-archive-keyring


''Note: seul <source lang="bash" inline>systemd-container</source> est nécessaire.''
''Note: seul <source lang="bash" inline>systemd-container</source> est nécessaire au fonctionnement des conteneurs.''


'''Création d'un répertoire d'accueil'''
'''Création d'un répertoire d'accueil'''
  mkdir -p ~/tmp/conteneur && cd $_
  mkdir -p ~/conteneurs && cd $_


'''Importation d'une racine Debian pour le système du conteneur'''
'''Importation d'une racine Debian pour le système du conteneur'''
Ligne 22 : Ligne 23 :
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é. Vous pouvez en préciser plusieurs en les séparent par des virgules.


{{attention|Si la commande vous renvoie:
{{attention|Si la commande vous renvoie un message du genre:


<source lang="bash">
<source lang="bash">
/usr/sbin/debootstrap: 1578: /usr/sbin/debootstrap: cannot create /tmp/conteneur/modèle.buster/test-dev-null: Permission denied
/usr/sbin/debootstrap: 1578: /usr/sbin/debootstrap: cannot create /tmp/conteneurs/modèle.buster/test-dev-null: Permission denied
E: Cannot install into target '/tmp/conteneur/modèle.buster' mounted with noexec or nodev
E: Cannot install into target '/tmp/conteneurs/modèle.buster' mounted with noexec or nodev
</source>
</source>


c'est que le système de fichiers cible ne supporte pas l'exécution de binaires (ce serai le cas de certains d'entre eux dans un volume Luks non root). Là en l'occurence c'est par ce que mon <source lang="bash" inline>/tmp</source> est un ''tmpfs'' (mais on va partir du principe qu'il s'agit d'un <source lang="bash" inline>/home/toto</source>). Pour corriger cela, il faut remonter le système de fichier avec les bons paramètres: <source lang="bash" inline>mount -i -o remount,exec,dev /home/toto</source>.
c'est que le système de fichiers cible ne supporte pas l'exécution de binaires (ce serai le cas de certains d'entre eux dans un volume Luks non root). Là en l’occurrence c'est par ce que mon <source lang="bash" inline>/tmp</source> est un ''tmpfs'' (mais on va partir du principe qu'il s'agit d'un <source lang="bash" inline>/home/toto</source>). Pour corriger cela, il faut remonter le système de fichier avec les bons paramètres: <source lang="bash" inline>mount -i -o remount,exec,dev /home/toto</source>.
}}
}}


''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 [[Apt-mirror|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).''
''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 [[Apt-mirror|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).''


'''Copie du modèle'''
'''Se connecter au conteneur sans le démarrer (identique à un ''chroot'')'''
cp -a modèle.buster buster1
  systemd-nspawn -D modèle.buster
 
'''Se connecter au conteneur sans le démarrer (identique à un chroot)'''
  systemd-nspawn -D buster1


Si vous rencontrez une impossibilité de vous connecter au shell de votre conteneur par la suite (ça n'a pas été mon cas), il faudra supprimer le fichier de liste blanche des ''TTY'' autorisés pour la connexion ([https://unix.stackexchange.com/questions/41840/effect-of-entries-in-etc-securetty /etc/securetty]) afin de permettre l'authentification comme suit.
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 ([https://unix.stackexchange.com/questions/41840/effect-of-entries-in-etc-securetty ''/etc/securetty'']) afin de permettre l'authentification comme suit:


  rm /etc/securetty
  rm /etc/securetty


On assignera enfin un mot de passe ''root'' avant de quitter le conteneur.
On assignera enfin un mot de passe ''root'' et supprimera l'historique ''Bash'' avant de quitter le conteneur.


  passwd
  passwd
  exit
  history -c
<ctrl+d>
 
'''Copie du modèle'''
cp -a modèle.buster buster1


'''Démarrer le conteneur et s'y connecter'''
'''Démarrer le conteneur et s'y connecter'''
  systemd-nspawn -bD buster1
  systemd-nspawn -bD buster1


Il n'est pas possible de se détacher du conteneur avec cette méthode. Pour sortir, il faut soir é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>.
Il n'est pas possible de se détacher du conteneur avec cette méthode (pour cela, il faudra se tourner vers [[#Machinectl|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 à la ligne de démarrage précédente afin d'affiner l'usage du conteneur.
 
===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.
 
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:
 
<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 [https://unix.stackexchange.com/questions/211225/how-do-i-background-a-systemd-nspawn-container lui-même démarré] !
systemd-nspawn -bxD /
 
===Non privilégié===
 
Un conteneur ''Nspawn'' peut-être exécuté dans un espace de noms utilisateur afin de cloisonner les privilège 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
 
==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. La syntaxe est documenté dans le [https://www.freedesktop.org/software/systemd/man/systemd.nspawn.html manuel dédié]. Ces fichiers sont bien entendus égalements 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>):
 
<source lang="bash">
[Exec]
Boot=on
 
[Network]
Interface=apache180_c
Interface=apache181_c
</source>


=Machinectl=
=Machinectl=
Cet outil ressemble plus à la gestion traditionnelle d'un ''LXC''. Il travail exclusivement dans le répertoire <source lang="bash" inline>/var/lib/machines</source> là où [[#Systemd-nspawn|Systemd-nspawn]] s'adaptait au paramètre passé
Cet outil ressemble plus à la gestion traditionnelle d'un ''LXC''. Il se base sur [[#Systemd-nspawn|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==
==Mise en œuvre==
Ligne 66 : Ligne 185 :
  machinectl start sid1
  machinectl start sid1
  machinectl shell 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>.''


==Commandes utiles==
==Commandes utiles==
Ligne 93 : Ligne 214 :
|-
|-
| <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 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-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
Ligne 110 : Ligne 235 :
* 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/machinectl.html
** https://www.freedesktop.org/software/systemd/man/machinectl.html

Version du 8 mai 2020 à 13:10

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 (waw j'ai vraiment écrit ça au sujet d'un composant Systemd ! Comme quoi tout est possible...).

Il existe deux façons de procéder:

  1. 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.
  2. Machinectl, s'apparente plus à LXC (il est pour Nspawn ce qu'est Libvirt pour Qemu) en proposant, nottament, 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 systemd-container 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 --include=systemd-container permet d'installer ledit paquet dans le système invité. Vous pouvez en préciser plusieurs en les séparent par des virgules.

ATTENTION

Si la commande vous renvoie un message du genre:
/usr/sbin/debootstrap: 1578: /usr/sbin/debootstrap: cannot create /tmp/conteneurs/modèle.buster/test-dev-null: Permission denied
E: Cannot install into target '/tmp/conteneurs/modèle.buster' mounted with noexec or nodev

c'est que le système de fichiers cible ne supporte pas l'exécution de binaires (ce serai le cas de certains d'entre eux dans un volume Luks non root). Là en l’occurrence c'est par ce que mon /tmp est un tmpfs (mais on va partir du principe qu'il s'agit d'un /home/toto). Pour corriger cela, il faut remonter le système de fichier avec les bons paramètres: mount -i -o remount,exec,dev /home/toto.

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: <ctrl> + ].

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.

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.

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 --network-interface 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:

# 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

Le réseau dans mon conteneur est définit comme suit:

vim /root/conteneurs/apache/etc/network/interfaces
auto lo
iface lo inet loopback
        up /usr/bin/confint
vim /root/conteneurs/apache/usr/bin/confint
#!/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
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 -x. 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 /

Non privilégié

Un conteneur Nspawn peut-être exécuté dans un espace de noms utilisateur afin de cloisonner les privilège 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 -U.

Tout cumulé, on en arrive à la commande suivante:

systemd-nspawn -b --network-interface=apache_c -xUD /root/conteneurs/apache

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. La syntaxe est documenté dans le manuel dédié. Ces fichiers sont bien entendus égalements 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: systemd-nspawn -b --network-interface=apache180_c --network-interface=apache181_c -D /root/conteneurs/apache est le suivant (/etc/systemd/nspawn/apache.nspawn):

[Exec]
Boot=on

[Network]
Interface=apache180_c
Interface=apache181_c

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 /var/lib/machines (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 systemd-container:

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: cp -a /root/conteneurs/buster1 /var/lib/machines/.

Commandes utiles

Voici les commandes utiles:

Argument Signification
machinectl ou machinectl list Liste les conteneurs actifs
machinectl list-images Liste les conteneurs sans distinctions
machinectl start sid1 Démarre le conteneur et rend la main (il se comporte comme un service)
machinectl poweroff sid1 ou machinectl stop sid1 Éteint le conteneur sid1 proprement, stop est un alias de poweroff
machinectl terminate sid1 Tue le conteneur (force l'arrêt)
machinectl clone sid sid1 Copie le conteneur (un cp -a /var/lib/machines/conteneur_source /var/lib/machines/conteneur_destination fait la même chose)
machinectl remove sid1 Supprime le conteneur (un rm -rf /var/lib/machines/conteneur_source conteneur_destination fait la même chose si tant est qu'il est bien arrêté)
machinectl clean --all Supprime tout les conteneurs
machinectl login sid1 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: <ctrl> + ])
machinectl shell sid1 Se connecte automatiquement au conteneur sans demander de mot de passe (identique à un chroot ou un su - utilisateur depuis root). Pour sortir, il faut faire un exit ou <ctrl> + d
machinectl enable 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/
machinectl disable Enlève le conteneur du démarrage système
machinectl copy-to sid1 ~/Documents/proc.jpeg /root/image.jpg 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
machinectl copy-from sid1 /root/xyz abc Même chose dans l'autre sens. Permet de récupérer un fichier/dossier
machinectl export-tar sid1 /tmp/sid1.tar.gz Réalise une sauvegarde du conteneur sous forme d'archive compressée (tar.gz)
machinectl import-tar /tmp/sid1.tar.gz sid2 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