102.6 Leçon 1

Certification :

LPIC-1

Version :

5.0

Thème :

102 Installation de Linux et gestion des paquets

Objectif :

102.6 Linux en tant que système virtualisé

Leçon :

1 sur 1

Introduction

Un des principaux atouts de Linux est sa polyvalence. Un aspect de cette polyvalence est la possibilité d’utiliser Linux pour héberger d’autres systèmes d’exploitation ou des applications individuelles dans un environnement complètement isolé et sécurisé. Cette leçon se concentre sur les concepts de virtualisation et de technologies de conteneurs ainsi que sur certains détails techniques à prendre en compte lors du déploiement d’une machine virtuelle sur une plate-forme de cloud computing.

Aperçu de la virtualisation

La virtualisation est une technologie qui permet à une plate-forme logicielle appelée hyperviseur d’exécuter des processus qui renferment un système informatique intégralement émulé. L’hyperviseur est chargé de gérer les ressources physiques du matériel qui pourront être utilisées par les différentes machines virtuelles. Ces machines virtuelles sont appelées des systèmes virtualisés (ou invités) de l’hyperviseur. Dans une machine virtuelle, bon nombre des caractéristiques d’un ordinateur physique sont émulées sous forme logicielle, comme le BIOS du système et les contrôleurs de disques durs. Une machine virtuelle utilise souvent des images disque qui sont stockées sous forme de fichiers individuels, elle aura accès à la RAM et au processeur de la machine hôte par le biais du logiciel hyperviseur. L’hyperviseur répartit l’accès aux ressources matérielles du système hôte entre les invités, ce qui permet à plusieurs systèmes d’exploitation de fonctionner sur un seul système hôte.

Voici les hyperviseurs les plus courants sous Linux :

Xen: Xen est un hyperviseur open source de type 1, ce qui signifie qu’il ne dépend pas d’un système d’exploitation sous-jacent pour fonctionner. Un hyperviseur de ce type est connu sous le nom d’hyperviseur bare metal (natif), étant donné que l’ordinateur peut démarrer directement l’hyperviseur.
KVM: KVM (Kernel-based Virtual Machine) est un module du noyau Linux pour la virtualisation. KVM est à la fois un hyperviseur de type 1 et 2 ; même s’il a besoin d’un système d’exploitation Linux de base pour fonctionner, il est capable d’assumer parfaitement son rôle d’hyperviseur en s’intégrant à une installation Linux en cours d’exécution. Les machines virtuelles déployées avec KVM utilisent le démon libvirt et les logiciels associés pour être créées et gérées.
VirtualBox: Une application de bureau populaire qui permet de créer et de gérer facilement des machines virtuelles. Oracle VM VirtualBox est multiplateforme et fonctionne sous Linux, macOS et Microsoft Windows. Comme VirtualBox a besoin d’un système d’exploitation sous-jacent pour fonctionner, il s’agit d’un hyperviseur de type 2.

Certains hyperviseurs permettent la réaffectation dynamique d’une machine virtuelle. Le fait de transférer une machine virtuelle d’un hyperviseur vers un autre est appelé une migration, les techniques utilisées diffèrent selon les différents types d’hyperviseur. Certaines migrations peuvent être effectuées uniquement lorsque le système invité est complètement à l’arrêt, tandis que d’autres peuvent se faire pendant que l’invité est en cours d’exécution (ce que l’on appelle une migration à chaud). Ces techniques peuvent s’avérer utiles pendant les fenêtres de maintenance des hyperviseurs ou pour la résilience du système, lorsqu’un hyperviseur tombe en panne et que le système virtualisé peut être déplacé vers un hyperviseur en état de marche.

Types de machines virtuelles

On distingue trois types de machines virtuelles, les systèmes invités pleinement virtualisés, les systèmes paravirtualisés et les systèmes hybrides.

VM pleinement virtualisée: Toutes les instructions qu’un système d’exploitation invité est censé exécuter doivent pouvoir tourner dans une installation entièrement virtualisée du système d’exploitation. La raison en est qu’aucun pilote logiciel supplémentaire n’est installé dans l’invité pour traduire les instructions en matériel simulé ou réel. Un invité entièrement virtualisé est un système dans lequel l’invité (ou la HardwareVM) ne sait pas qu’il s’agit d’une instance de machine virtuelle en cours d’exécution. Pour que ce type de virtualisation puisse fonctionner sur du matériel x86, les extensions CPU Intel VT-x ou AMD-V doivent être activées sur le système sur lequel l’hyperviseur est installé. Cette opération peut être effectuée à partir du menu de configuration du BIOS ou de l’UEFI.
VM paravirtualisée: Une machine virtuelle paravirtualisée (ou PVM) est un système invité dont l’OS est conscient qu’il s’agit d’une instance de machine virtuelle en cours d’exécution. Ces types de systèmes invités utilisent un noyau modifié et des pilotes spécifiques (appelés pilotes invités) qui aident le système d’exploitation invité à utiliser les ressources logicielles et matérielles de l’hyperviseur. Les performances d’un invité paravirtualisé sont souvent meilleures que celles de l’invité entièrement virtualisé grâce aux avantages que lui procurent ces pilotes logiciels.
VM hybride: La paravirtualisation et la virtualisation complète peuvent être combinées pour permettre aux systèmes d’exploitation non modifiés de bénéficier de performances d’E/S quasi natives en utilisant des pilotes paravirtualisés sur des systèmes d’exploitation entièrement virtualisés. Les pilotes paravirtualisés contiennent des pilotes de périphériques de stockage et de réseau avec des performances améliorées en matière d’E/S de disque et de réseau.

Les plateformes de virtualisation fournissent souvent des pilotes invités sous forme de paquets pour les systèmes d’exploitation virtualisés. KVM utilise les pilotes du projet Virtio tandis qu’Oracle VM VirtualBox utilise les Guest Extensions (Additions Invité) disponibles à partir d’un fichier image ISO CD-ROM téléchargeable.

Exemple de machine virtuelle `libvirt`

Nous allons voir de plus près un exemple de machine virtuelle qui est gérée par libvirt et qui utilise l’hyperviseur KVM. Une machine virtuelle est souvent composée d’un groupe de fichiers, principalement un fichier XML qui définit la machine virtuelle (comme sa configuration matérielle, sa connectivité réseau, ses capacités d’affichage, etc.) et un fichier image disque associé qui contient l’installation du système d’exploitation et de ses logiciels.

Commençons par jeter un œil sur un exemple de fichier de configuration XML pour une machine virtuelle et son environnement réseau :

$ ls /etc/libvirt/qemu
total 24
drwxr-xr-x 3 root root 4096 Oct 29 17:48 networks
-rw------- 1 root root 5667 Jun 29 17:17 rhel8.0.xml

Note

La partie qemu du chemin vers le répertoire fait référence au logiciel sous-jacent sur lequel reposent les machines virtuelles basées sur KVM. Le projet QEMU fournit un logiciel permettant à l’hyperviseur d’émuler les périphériques matériels que la machine virtuelle utilisera, tels que les contrôleurs de disque, l’accès au CPU de l’hôte, l’émulation de la carte réseau, etc.

Notez qu’il y a un répertoire nommé networks. Ce répertoire contient des fichiers de définition (également au format XML) qui créent des configurations réseau que les machines virtuelles pourront utiliser. Cet hyperviseur n’utilise qu’un seul réseau, il n’y a donc qu’un seul fichier de définition qui contient une configuration pour un segment de réseau virtuel que ces systèmes utiliseront.

$ ls -l /etc/libvirt/qemu/networks/
total 8
drwxr-xr-x 2 root root 4096 Jun 29 17:15 autostart
-rw------- 1 root root  576 Jun 28 16:39 default.xml
$ sudo cat /etc/libvirt/qemu/networks/default.xml
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh net-edit default
or other application using the libvirt API.
-->

<network>
  <name>default</name>
  <uuid>55ab064f-62f8-49d3-8d25-8ef36a524344</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:b8:e0:15'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254'/>
    </dhcp>
  </ip>
</network>

Cette définition comprend un réseau privé de classe C et un périphérique matériel émulé faisant office de routeur pour ce réseau. Il y a également une plage d’adresses IP que l’hyperviseur utilisera avec une implémentation de serveur DHCP et qui pourront être attribuées aux machines virtuelles utilisant ce réseau. Cette configuration réseau utilise également la translation d’adresse réseau (NAT) pour transférer les paquets vers d’autres réseaux, comme le réseau local de l’hyperviseur.

Nous allons maintenant porter notre attention sur un fichier de définition de machine virtuelle Red Hat Enterprise Linux 8. (Les sections à retenir sont en caractères gras) :

$ sudo cat /etc/libvirt/qemu/rhel8.0.xml
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh edit rhel8.0
or other application using the libvirt API.
-->

<domain type='kvm'>
  <name>rhel8.0</name>
  <uuid>fadd8c5d-c5e1-410e-b425-30da7598d0f6</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://redhat.com/rhel/8.0"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc-q35-3.1'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state='off'/>
  </features>
  <cpu mode='host-model' check='partial'>
    <model fallback='allow'/>
  </cpu>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/rhel8'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </disk>
    <controller type='usb' index='0' model='qemu-xhci' ports='15'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
    </controller>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pcie-root'/>
    <controller type='pci' index='1' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='1' port='0x10'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
    </controller>
    <controller type='pci' index='2' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='2' port='0x11'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
    </controller>
    <controller type='pci' index='3' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='3' port='0x12'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/>
    </controller>
    <controller type='pci' index='4' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='4' port='0x13'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/>
    </controller>
    <controller type='pci' index='5' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='5' port='0x14'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/>
    </controller>
    <controller type='pci' index='6' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='6' port='0x15'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/>
    </controller>
    <controller type='pci' index='7' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='7' port='0x16'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:50:a7:18'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='unix'>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>
    <input type='tablet' bus='usb'>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='spice' autoport='yes'>
      <listen type='address'/>
      <image compression='off'/>
    </graphics>
    <sound model='ich9'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
    </sound>
    <video>
      <model type='virtio' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    </video>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='2'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='3'/>
    </redirdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
    </memballoon>
    <rng model='virtio'>
      <backend model='random'>/dev/urandom</backend>
      <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
    </rng>
  </devices>
</domain>

Ce fichier définit un certain nombre de paramètres matériels qui sont utilisés par ce système virtualisé, comme la quantité de RAM qui lui sera attribuée, le nombre de cœurs de CPU de l’hyperviseur auxquels l’invité aura accès, le fichier image disque qui est associé à cet invité (sous la rubrique disk), ses capacités d’affichage (via le protocole SPICE) et l’accès de l’invité aux périphériques USB ainsi qu’aux entrées émulées du clavier et de la souris.

Exemple de stockage sur disque d’une machine virtuelle

L’image disque de cette machine virtuelle se situe dans /var/lib/libvirt/images/rhel8. Voici l’image disque en question sur cet hyperviseur :

$ sudo ls -lh /var/lib/libvirt/images/rhel8
-rw------- 1 root root 5.5G Oct 25 15:57 /var/lib/libvirt/images/rhel8

La taille actuelle de cette image disque ne prend que 5,5 Go d’espace sur l’hyperviseur. Cependant, le système d’exploitation dans l’invité voit un disque de 23,3 Go, comme le met en évidence la sortie de la commande suivante dans la machine virtuelle en cours d’exécution :

$ lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda           252:0    0 23.3G  0 disk
├─vda1        252:1    0    1G  0 part /boot
└─vda2        252:2    0 22.3G  0 part
  ├─rhel-root 253:0    0   20G  0 lvm  /
  └─rhel-swap 253:1    0  2.3G  0 lvm  [SWAP]

Cela est dû au type de provisionnement de disque utilisé pour ce système virtualisé. Il existe plusieurs types d’images disque qu’une machine virtuelle peut utiliser, mais les deux principaux types sont les suivants :

COW: Le copy-on-write (ou copie sur écriture, également appelé thin provisioning ou allocation dynamique) est une méthode selon laquelle un fichier disque est créé avec une limite de taille supérieure prédéfinie. La taille de l’image disque n’augmente que lorsque de nouvelles données sont écrites sur le disque. Comme dans l’exemple précédent, le système d’exploitation virtualisé voit la limite prédéfinie du disque de 23,3 Go, mais n’a écrit que 5,5 Go de données sur le fichier du disque. Le format d’image disque utilisé pour la machine virtuelle dans l’exemple est qcow2, qui est un format de fichier QEMU COW.
RAW: Un type de disque raw ou brut est un fichier dont tout l’espace est pré-alloué. Par exemple, un fichier image disque brut de 10 Go consomme 10 Go d’espace disque réel sur l’hyperviseur. Ce type de disque présente un avantage en termes de performances, étant donné que tout l’espace disque nécessaire existe déjà, de sorte que l’hyperviseur sous-jacent peut simplement écrire des données sur le disque sans avoir à surveiller l’image disque pour s’assurer qu’elle n’a pas encore atteint sa limite et sans avoir à étendre la taille du fichier au fur et à mesure que de nouvelles données y sont écrites.

Il existe d’autres plateformes de gestion de la virtualisation, telles que Red Hat Enterprise Virtualization et oVirt, qui peuvent utiliser des disques physiques pour servir d’emplacements de stockage pour le système d’exploitation d’une machine virtuelle. Ces systèmes peuvent utiliser des périphériques de stockage SAN (Storage Area Network) ou NAS (Network Attached Storage) pour y écrire leurs données, l’hyperviseur garde la trace des emplacements de stockage appartenant à chaque machine virtuelle. Ces systèmes de stockage peuvent utiliser des technologies telles que la gestion des volumes logiques (LVM) pour augmenter ou réduire la taille du stockage sur disque d’une machine virtuelle selon les besoins et pour faciliter la création et la gestion des instantanés de stockage.

Travailler avec des modèles de machines virtuelles

Étant donné que les machines virtuelles ne sont généralement que des fichiers exécutés sur un hyperviseur, il est facile de créer des modèles (ou templates) qui peuvent être personnalisés pour des scénarios de déploiement particuliers. Souvent, une machine virtuelle aura une installation de base du système d’exploitation et certains paramètres de configuration d’authentification préconfigurés pour faciliter les déploiements ultérieurs du système. Cela permet de réduire le temps nécessaire à la construction d’un nouveau système en réduisant la quantité de tâches répétitives, telles que l’installation des paquets de base et la configuration des paramètres régionaux.

Ce modèle de machine virtuelle pourra ensuite être copié vers un nouveau système invité. Dans ce cas, le nouveau système virtualisé sera renommé, une nouvelle adresse MAC sera générée pour son interface réseau et d’autres modifications pourront être apportées en fonction de l’utilisation prévue.

L’identifiant unique D-Bus machine-id

La plupart des systèmes Linux utilisent un numéro d’identification de la machine généré au moment de l’installation, appelé D-Bus machine ID. Cependant, si une machine virtuelle est clonée en vue d’être utilisée comme modèle pour d’autres installations de machines virtuelles, un nouvel identifiant unique D-Bus devra être créé pour garantir que les ressources système de l’hyperviseur sont dirigées vers le système invité approprié.

La commande suivante peut être utilisée pour valider qu’un identifiant unique D-Bus existe pour le système en cours d’exécution :

$ dbus-uuidgen --ensure

Si aucun message d’erreur ne s’affiche, cela signifie qu’un ID existe pour le système. Pour afficher l’ID D-Bus en vigueur, exécutez la commande suivante :

$ dbus-uuidgen --get
17f2e0698e844e31b12ccd3f9aa4d94a

La chaîne de caractères qui s’affiche est le numéro d’identification actuel. Deux systèmes Linux tournant sur un même hyperviseur ne doivent pas avoir le même identifiant de machine.

L’ID D-Bus de la machine se trouve dans /var/lib/dbus/machine-id avec un lien symbolique vers /etc/machine-id. Il est déconseillé de modifier ce numéro d’identification sur un système en cours, étant donné que cela entraînerait une instabilité du système et une série de pannes. Au cas où deux machines virtuelles auraient le même ID de machine, suivez la procédure ci-dessous pour en générer un nouveau :

$ sudo rm -f /etc/machine-id
$ sudo dbus-uuidgen --ensure=/etc/machine-id

Au cas où /var/lib/dbus/machine-id ne serait pas un lien symbolique vers /etc/machine-id, il faudra supprimer /var/lib/dbus/machine-id.

Déployer des machines virtuelles dans le cloud

Il existe une multitude de fournisseurs IaaS (Infrastructure as a Service) qui font tourner des systèmes d’hyperviseurs et qui peuvent déployer des images de systèmes virtualisés pour une organisation. Pratiquement tous ces fournisseurs disposent d’outils qui permettent à un administrateur de construire, déployer et configurer des machines virtuelles personnalisées basées sur une panoplie de distributions Linux. Nombre de ces entreprises disposent également de systèmes qui permettent le déploiement et la migration de machines virtuelles construites au sein de l’organisation d’un client.

Le déploiement d’un système Linux dans un environnement IaaS doit prendre en compte certains éléments clés dont l’administrateur devra tenir compte :

Instances: Beaucoup de fournisseurs de cloud facturent des tarifs d’utilisation basés sur des "instances de calcul", c’est-à-dire la quantité de temps CPU que votre infrastructure cloud utilisera. Une planification minutieuse du temps de traitement dont les applications auront réellement besoin permettra de maîtriser les coûts d’une solution cloud.

Les instances désignent tout aussi bien le nombre de machines virtuelles provisionnées dans un environnement cloud. Là encore, le nombre d’instances exécutées en même temps influera sur le temps CPU global facturé à l’organisation.
Stockage en mode bloc: Les fournisseurs de cloud proposent également différents niveaux de stockage en bloc qu’une organisation pourra utiliser. Certaines offres sont simplement destinées à servir de stockage réseau basé sur le web pour les fichiers, alors que d’autres offres concernent le stockage externe pour une machine virtuelle provisionnée dans le cloud à utiliser pour héberger des fichiers.

Le coût de ces offres varie en fonction de la quantité de stockage utilisée et de la vitesse du stockage dans les centres de données du fournisseur. Un accès plus rapide au stockage coûte généralement plus cher, et inversement, les données "au repos" (comme c’est le cas pour le stockage d’archives) sont souvent très peu coûteuses.
Mise en réseau: L’un des principaux aspects à prendre en compte lorsqu’on travaille avec un fournisseur de solutions cloud est la manière dont le réseau virtuel sera configuré. Beaucoup de fournisseurs IaaS disposent d’une interface web qui permet de concevoir et de mettre en œuvre toutes sortes de configurations de routage, de sous-réseaux et de pare-feu. Certains vont même fournir des solutions DNS afin que des noms de domaine pleinement qualifiés (FQDN) publiquement routables puissent être attribués à vos systèmes avec une ouverture frontale sur Internet. Il existe même des solutions "hybrides" qui permettent de connecter une infrastructure réseau existante sur site à une infrastructure cloud par le biais d’un VPN (réseau privé virtuel), reliant ainsi les deux infrastructures.

Accès sécurisé aux VM dans le cloud

La méthode la plus courante pour accéder à une VM distante sur une plate-forme cloud repose sur l’utilisation du logiciel OpenSSH. Un système Linux qui tourne dans le cloud dispose du serveur OpenSSH, tandis qu’un administrateur utilise un client OpenSSH avec des clés pré-partagées pour l’accès à distance.

Un administrateur exécutera la commande suivante :

$ ssh-keygen

et suivra les instructions pour créer une paire de clés SSH publique et privée. La clé privée reste sur le système local de l’administrateur (stockée dans ~/.ssh/) et la clé publique est copiée sur le système cloud distant, exactement la même méthode que celle utilisée pour travailler avec des machines en réseau sur un LAN d’entreprise.

L’administrateur exécutera alors la commande suivante :

$ ssh-copy-id -i <public_key> user@cloud_server

Cette opération va copier la clé publique SSH de la paire de clés qui vient d’être générée vers le serveur cloud distant. La clé publique sera enregistrée dans le fichier ~/.ssh/authorized_keys du serveur cloud, avec les permissions appropriées sur le fichier.

Note	S’il n’y a qu’un seul fichier de clé publique dans le répertoire `~/.ssh/`, alors l’option `-i` peut être omise, car la commande `ssh-copy-id` prendra par défaut le fichier de clé publique du répertoire (typiquement le fichier se terminant par l’extension `.pub`).

Certains fournisseurs de cloud vont générer automatiquement une paire de clés lorsqu’un nouveau système Linux est approvisionné. L’administrateur devra ensuite télécharger la clé privée du nouveau système depuis le fournisseur de cloud et la stocker sur son système local. Notez que les permissions pour les clés SSH doivent être 0600 pour une clé privée, et 0644 pour une clé publique.

Préconfiguration des systèmes cloud

Parmi les outils pratiques qui simplifient les déploiements de machines virtuelles dans le cloud, on trouve l’utilitaire cloud-init. Cette commande, ainsi que les fichiers de configuration correspondants et l’image de machine virtuelle prédéfinie, constitue une méthode agnostique en termes de fournisseur pour déployer une VM Linux sur une multitude de plate-formes IaaS. À l’aide de fichiers texte YAML (YAML Ain’t Markup Language), un administrateur peut préconfigurer les paramètres réseau, la sélection des paquets logiciels, la configuration des clés SSH, la création des comptes utilisateurs, les paramètres régionaux ainsi qu’une myriade d’autres options qui permettent de déployer rapidement de nouveaux systèmes.

Lors du démarrage initial d’un nouveau système, cloud-init va lire les paramètres depuis les fichiers de configuration YAML pour les appliquer ensuite. Ce processus ne s’applique que lors de la configuration initiale d’un système et facilite le déploiement d’une série de nouveaux systèmes sur la plate-forme d’un fournisseur de cloud computing.

La syntaxe du fichier YAML utilisé avec cloud-init est appelée cloud-config. Voici un exemple de fichier cloud-config :

#cloud-config
timezone: Africa/Dar_es_Salaam
hostname: test-system

# Update the system when it first boots up
apt_update: true
apt_upgrade: true

# Install the Nginx web server
packages:
 - nginx

Notez que sur la première ligne, il n’y a pas d’espace entre le signe dièse (#) et le terme cloud-config.

Note	`cloud-init` n’est pas réservé aux machines virtuelles. La suite d’outils `cloud-init` peut également être utilisée pour préconfigurer les conteneurs (par exemple les conteneurs Linux LXD ) avant leur déploiement.

Les conteneurs

La technologie des conteneurs ressemble dans une certaine mesure à une machine virtuelle, dans le sens où l’on obtient un environnement isolé pour déployer facilement une application. Tandis qu’avec une machine virtuelle, un système entier est émulé, un conteneur utilise juste assez de ressources logicielles pour exécuter une application. Cette façon de procéder permet de réduire considérablement le gaspillage des ressources.

Les conteneurs offrent une plus grande flexibilité que les machines virtuelles. Un conteneur d’application peut être migré d’un hôte vers un autre, tout comme une machine virtuelle peut être migrée d’un hyperviseur vers un autre. Cependant, une machine virtuelle nécessite parfois d’être arrêtée avant la migration, alors qu’avec un conteneur, l’application reste en cours d’exécution pendant la migration. Les conteneurs facilitent également le déploiement de nouvelles versions d’applications en parallèle avec une version existante. Au fur et à mesure que les utilisateurs ferment leurs sessions avec des conteneurs en cours d’exécution, ces conteneurs peuvent être automatiquement retirés du système par le logiciel d’orchestration de conteneurs et remplacés par la nouvelle version, ce qui réduit les temps d’arrêt.

Note	Il existe de nombreuses technologies de conteneurs disponibles pour Linux, telles que Docker, Kubernetes, LXD/LXC, systemd-nspawn, OpenShift, etc. La mise en œuvre détaillée d’un logiciel de conteneur dépasse le cadre de l’examen LPIC-1.

Les conteneurs utilisent le mécanisme des control groups (communément appelés cgroups) au sein du noyau Linux. Les cgroups permettent de partitionner les ressources système telles que la mémoire, le temps processeur ainsi que la bande passante disque et réseau pour une application individuelle. Un administrateur peut utiliser directement les cgroups pour fixer des limites de ressources système pour une application ou un groupe d’applications pouvant exister dans un seul cgroup. C’est essentiellement ce que font les logiciels de conteneurs pour l’administrateur, en plus de fournir des outils qui facilitent la gestion et le déploiement des cgroups.

Note

Actuellement, la connaissance des cgroups n’est pas nécessaire pour passer l’examen LPIC-1. Le concept des cgroups est mentionné ici afin que le candidat ait au moins quelques connaissances de base sur la manière dont une application est isolée dans un souci d’utilisation des ressources du système.

Exercices guidés

Quelles extensions de CPU sont nécessaires sur une plate-forme matérielle de type x86 qui fera fonctionner des systèmes invités entièrement virtualisés ?
Une installation de serveur de production nécessitant les performances les plus rapides utilisera probablement quel type de virtualisation ?
Deux machines virtuelles clonées à partir du même template et qui utilisent D-Bus se comportent de manière erratique. Elles ont toutes deux des noms d’hôtes et des paramètres réseau distincts. Quelle commande permet de déterminer si chacune des machines virtuelles dispose de son propre identifiant de machine D-Bus distinct ?

Exercices d’approfondissement

Exécutez la commande suivante pour voir si votre système a déjà des extensions de CPU activées pour exécuter une machine virtuelle (vos résultats peuvent varier en fonction de votre CPU) :

grep --color -E "vmx|svm" /proc/cpuinfo

Selon le résultat, vous pouvez avoir vmx en surbrillance (pour les CPU Intel VT-x) ou svm en surbrillance (pour les CPU AMD SVM). Si vous n’obtenez aucun résultat, consultez les instructions de votre BIOS ou de votre firmware UEFI pour savoir comment activer la virtualisation pour votre processeur.
Si votre processeur gère la virtualisation, consultez la documentation de votre distribution pour faire tourner un hyperviseur KVM.
- Installez les paquets nécessaires pour faire tourner un hyperviseur KVM.
- Si vous utilisez un environnement de bureau graphique, il est recommandé d’installer également l’application virt-manager, un frontal graphique qui peut être utilisé sur une installation KVM. Cela facilitera l’installation et la gestion des machines virtuelles.
- Téléchargez une image ISO d’une distribution Linux de votre choix et, en suivant la documentation de cette distribution, créez une nouvelle machine virtuelle à l’aide de l’image ISO.

Résumé

Dans cette leçon, nous avons abordé les concepts de base des machines virtuelles et des conteneurs et comment ces technologies peuvent être utilisées avec Linux.

Nous avons décrit succinctement les commandes suivantes :

dbus-uuidgen: Utilisé pour vérifier et afficher l’identifiant D-Bus d’un système.
ssh-keygen: Utilisé pour générer une paire de clés SSH publique et privée pour accéder à des systèmes distants basés sur le cloud.
ssh-copy-id: Utilisé pour copier la clé publique SSH d’un système vers un système distant afin de faciliter l’authentification à distance.
cloud-init: Utilisé pour faciliter la configuration et le déploiement de machines virtuelles et de conteneurs dans un environnement cloud.

Réponses aux exercices guidés

Quelles extensions de CPU sont nécessaires sur une plate-forme matérielle de type x86 qui fera fonctionner des systèmes invités entièrement virtualisés ?

VT-x pour les CPU Intel ou AMD-V pour les CPU AMD.
Une installation de serveur de production nécessitant les performances les plus rapides utilisera probablement quel type de virtualisation ?

Un système d’exploitation qui utilise la paravirtualisation, comme Xen, pourra mieux utiliser les ressources matérielles à sa disposition en tant que système d’exploitation invité grâce à l’utilisation de pilotes logiciels conçus pour fonctionner avec l’hyperviseur.
Deux machines virtuelles clonées à partir du même template et qui utilisent D-Bus se comportent de manière erratique. Elles ont toutes deux des noms d’hôtes et des paramètres réseau distincts. Quelle commande permet de déterminer si chacune des machines virtuelles dispose de son propre identifiant de machine D-Bus distinct ?

dbus-uuidgen --get

Réponses aux exercices d’approfondissement

Exécutez la commande suivante pour voir si votre système a déjà des extensions de CPU activées pour exécuter une machine virtuelle (vos résultats peuvent varier en fonction de votre CPU) :

grep --color -E "vmx|svm" /proc/cpuinfo

Selon le résultat, vous pouvez avoir vmx en surbrillance (pour les CPU Intel VT-x) ou svm en surbrillance (pour les CPU AMD SVM). Si vous n’obtenez aucun résultat, consultez les instructions de votre BIOS ou de votre firmware UEFI pour savoir comment activer la virtualisation pour votre processeur.

Les résultats varieront en fonction du CPU que vous possédez. Voici un exemple de résultats obtenus sur un ordinateur équipé d’un CPU Intel avec des extensions de virtualisation activées dans le firmware UEFI :

$ grep --color -E "vmx|svm" /proc/cpuinfo
flags	 : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d

Si votre processeur gère la virtualisation, consultez la documentation de votre distribution pour faire tourner un hyperviseur KVM.
- Installez les paquets nécessaires pour faire tourner un hyperviseur KVM.
  
  Cela variera en fonction de votre distribution, mais voici quelques pistes de réflexion :
  
  Ubuntu — https://help.ubuntu.com/lts/serverguide/libvirt.html
  
  Fedora — https://docs.fedoraproject.org/en-US/quick-docs/getting-started-with-virtualization/
  
  Arch Linux — https://wiki.archlinux.org/index.php/KVM
- Si vous utilisez un environnement de bureau graphique, il est recommandé d’installer également l’application virt-manager, un frontal graphique qui peut être utilisé sur une installation KVM. Cela facilitera l’installation et la gestion des machines virtuelles.
  
  Là encore, cela varie selon la distribution. Un exemple avec Ubuntu ressemble à ceci :
  $ sudo apt install virt-manager
- Téléchargez une image ISO d’une distribution Linux de votre choix et, en suivant la documentation de cette distribution, créez une nouvelle machine virtuelle à l’aide de l’image ISO.
  
  Cette tâche est gérée facilement par le paquet virt-manager. Cependant, une machine virtuelle peut être créée en ligne de commande à l’aide de la commande virt-install. Essayez les deux méthodes pour vous faire une idée de la façon dont les machines virtuelles sont déployées.