Cloonix et les conteneurs

Posté par  (site web personnel) . Édité par Benoît Sibaud, palm123, Ysabeau 🧶, Pierre Jarillon et Florent Zara. Modéré par Ysabeau 🧶. Licence CC By‑SA.
Étiquettes :
27
17
jan.
2022
Virtualisation

Cloonix est un logiciel de virtualisation basé sur qemu-kvm, dpdk et openvswitch. Il permet une construction d’un réseau virtuel avec création graphique et visualisation de la topologie.

Logo Cloonix Logotype cloonix
   

En décembre 2021 une nouvelle fonctionnalité a été intégrée dans cloonix : des conteneurs lancés grâce à l’utilisation du logiciel crun par cloonix.

Cet article a une visée plus large que la simple publicité pour l’utilisation de cloonix, il est toujours formateur d’utiliser des commandes de bas niveau afin de créer et lancer un conteneur. Ces commandes sont données en seconde partie.

Sommaire

Les constituants logiques d’un conteneur

Avant de présenter les méthodes utilisées par cloonix pour implémenter la fonctionnalité conteneur, il faut préciser les trois constituants logiques d’un conteneur : le système de fichiers privé, la pile IP privée, et enfin l’exécution privée des processus du conteneur.

Pour l’exécution privée, crun s’en occupe, mais il reste le système de fichiers ainsi que la pile IP à gérer par cloonix.

En premier lieu nous allons décrire le format et la création de l’image représentant le disque tel qu’il est utilisé par cloonix. Cette image contient le système de fichiers racine du conteneur.

Puis nous allons voir comment utiliser cette image de façon à présenter aux conteneurs un système de fichier du style copy-on-write, c’est-à-dire donner au conteneur l’impression qu’il peut écrire son système de fichiers racine sans qu’il ne modifie l’image de référence.

Ensuite, pour la pile IP privée, les commandes associées aux namespaces sont utilisées. Ceci permet d’attribuer des interfaces Ethernet au conteneur.

Enfin, pour faire tourner ce conteneur qui possède donc son système de fichiers racine privé et sa pile IP privée, il y a le logiciel écrit en C nommé crun. Ce logiciel prend en entrée un fichier de configuration nommé config.json dans lequel on doit mettre le chemin du système de fichiers et le nom de l’espace de nommage (namespace) pour les interfaces IP.

Si vous exécutez les commandes données ci-dessous, vous pouvez faire tourner manuellement un conteneur avec la même méthode que le fait cloonix. Pour crun il faut installer le logiciel sur votre hôte.

Les commandes

Voici les commandes utilisées sur une Debian pour créer l’image exemple bookworm.img. Vous pouvez aussi télécharger ce fichier à cette adresse bookworm.img.gz.

    dd if=/dev/zero of=bookworm.img bs=100M count=10
    mkfs.ext4 bookworm.img
    losetup -fP bookworm.img
    mkdir -p tmp_mnt
    DEVLOOP=$(losetup -l | grep bookworm.img | awk '{print $1}')
    echo $DEVLOOP
    mount -o loop $DEVLOOP tmp_mnt
    export DEBOOTSTRAP_DIR=/root/debootstrap-1.0.126+nmu1
    INCLUDES="openssh-client,vim,bash-completion,net-tools,tcpdump,tini"
    cd /root/debootstrap-1.0.126+nmu1
    ./debootstrap  --no-check-certificate \
                   --no-check-gpg \
                   --arch amd64 \
                   --include=${INCLUDES} \
                   bookworm \
                   tmp_mnt \
                   http://deb.debian.org/debian
    umount tmp_mnt
    losetup -d $DEVLOOP
    rmdir tmp_mnt

Voici les commandes qui permettent de présenter un système de fichiers au conteneur, ce système de fichiers sera en /root/overlay/rootfs, et une écriture dans ce système de fichiers ne va pas modifier l’image bookworm.img, toute écriture se retrouvera dans /root/overlay/upper.

losetup -fP bookworm.img
DEVLOOP=$(losetup -l | grep bookworm.img | awk '{print $1}')
mkdir -p /root/overlay/{lower,upper,workdir,rootfs}
mount -o loop $DEVLOOP /root/overlay/lower
LW="/root/overlay/lower"
UP="/root/overlay/upper"
WK="/root/overlay/workdir"
RT="/root/overlay/rootfs"
mount none -t overlay -o lowerdir=${LW},upperdir=${UP},workdir=${WK} ${RT}

Voici les commandes qui permettent de générer le namespace et d’ajouter les interfaces, le principe étant qu’on a une paire d’interfaces connectées dans l’hôte puis on envoie l’interface nommée eth0 dans le namespace cloonix_1_1. Avec ce montage, tout paquet IP émis sur vgt_1_1_0 se retrouvera sur eth0 donc dans le container.

ip netns ls
ip netns add cloonix_1_1
ip link add name vgt_1_1_0 type veth peer name eth0
ip link set eth0 netns cloonix_1_1
ip netns exec cloonix_1_1 ip link set lo up
ip netns exec cloonix_1_1 ip link set eth0 up

Voici les commandes qui permettent de créer le fichier config.json puis de l’adapter de façon à lui donner le répertoire du système de fichiers et le namespace pour l’interface eth0.

crun spec
sed -i s"%\"path\": \(.*\)%\"path\": \"/root/overlay/rootfs\",%" config.json
sed -i s"/\"readonly\": \(.*\)/\"readonly\": \"false\"/" config.json
sed -i s"%\"network\"%\"network\",\n\t\t\t\t\"path\": \"/var/run/netns/cloonix_1_1\"%" config.json
sed -i s"/\"terminal\": \(.*\)/\"terminal\": \"false\",/" config.json
sed -i s"%\"CAP_KILL\",%\"CAP_KILL\",\n\t\t\t\t\"CAP_NET_RAW\",%" config.json
sed -i s"%\"CAP_KILL\",%\"CAP_KILL\",\n\t\t\t\t\"CAP_NET_ADMIN\",%" config.json

Enfin tout est prêt pour que crun tourne, voici les commandes pour que le conteneur tourne. La commande crun exec Cloon1 bash donne un shell dans le conteneur.

crun list
crun create --config=/root/config.json Cloon1
crun list
crun exec Cloon1 bash
crun list

Nettoyage complet quand la manipulation est terminée :

crun list
kill -9 <pid>
crun list
crun delete Cloon1
crun list
umount /root/overlay/rootfs
umount /root/overlay/lower
DEVLOOP=$(losetup -l | grep bookworm.img | awk '{print $1}')
losetup -d $DEVLOOP

Et voila une méthode maison pour faire tourner un conteneur, cloonix prend ces manipulations à sa charge lorsque vous lui demandez de créer un conteneur.

Aller plus loin

  • # Des questions

    Posté par  . Évalué à 5.

    Est-ce que quelqu'un peut présenter les différences fondamentales entre l'approche de Cloonix et celle d'un Docker ? Est-ce que les deux ont même des choses en commun ?

    Si j'en crois le github de crun, cela se veut comme une option ultra légère pour faire tourner des containers. Déjà que les containers sont une approche ultra légère comparés à de la virtualisation "à la papa", on peut tout faire ensuite avec ça ?

    Si je veux me créer mon petit environnement pour faire tourner mes micro-services Java, c'est quoi les grandes étapes ?

    • [^] # Re: Des questions

      Posté par  (Mastodon) . Évalué à 10.

      Si je veux me créer mon petit environnement pour faire tourner mes micro-services Java, c'est quoi les grandes étapes ?

      1) acheter des barettes de RAM

    • [^] # Re: Des questions

      Posté par  (site web personnel) . Évalué à 4.

      Ce n'est pas encore près mais dans 1 mois, il y aura la possibilité de passer à la construction du containeur un chemin d'executable et des parametres.
      Le containeur va alors executer cet executable (qui doit etre dans le systeme de fichier du containeur).

      Mais en effet, pour l'instant c'est pas vraiment une fonctionnalitée utile:)
      Cette nouvelle a surtout un but de partage d'infos que j'ai trouvé sympa.

      Dans l'avenir on verra bien si cela devient utile…

    • [^] # Re: Des questions

      Posté par  . Évalué à 2.

      Déjà que les containers sont une approche ultra légère comparés à de la virtualisation "à la papa", on peut tout faire ensuite avec ça ?

      J'ai entendu des retours (mais je n'ai rien vu) de gens qui font des hyperviseurs très léger et des vm à base de micro kernel. Leur idée c'est d'avoir des vm qui peuvent faire tourner du code wasm et de lancer ça avec un hyperviseur aussi léger que possible tout en ayant un cloisonnement fort. C'est sexy (ils parlaient de démarrage de vm de l'orde de la ms). Mais rien est dispo pour le faire (hors de leur dépôt non publique)…

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Docker a la mano ?

    Posté par  . Évalué à 1.

    Effectivement, ça ressemble beaucoup à du Docker mais fais à la main.

    Il y a évidemment un intérêt pédagogique à devoir comprendre et s'occuper de tous les détails mais dans un contexte professionnel, ça me semble être beaucoup de travail pour la même chose.

    Docker a l'avantage d'être très répandu, quasiment un standard maintenant. Du coup, à part pour un labo de test ou des expérimentations, je vois pas bien l'intérêt de crun.

    • [^] # Re: Docker a la mano ?

      Posté par  . Évalué à 2.

      Disons que Docker et les interfaces réseau, c'est un peu deux ennemis jurés. Dès que tu sors des 2 modes dans la doc (nat et proxy), t'es mort. Cloonix, c'est un peu plus fluide pour ça, à ce que j'ai compris (pas testé donc).

      Aussi, docker propose bien plus que ce que Cloonix propose, notamment avec ses dépôts d'images. Le corolaire, c'est que le moindre conteneur est souvent énorme, vu que la majorité des utilisateurs se prennent pas la tête à le configurer au minimum de ce qu'il faut et démarre d'un Ubuntu ou un Alpine. Avec Cloonix, vu que c'est à la mano, je pense que tu ne mets rien en plus que nécessaire.

      • [^] # Re: Docker a la mano ?

        Posté par  (site web personnel) . Évalué à 4.

        Oui, en ce qui concerne l'open-source il faut à la fois utiliser les softs bien finis comme docker mais aussi en comprendre les ficelles et pouvoir zapper sur d'autres possibilités. Pour ce qui est des interfaces réseau, cloonix integre le superbe openvswitch dans son utilisation kvm usuelle et en effet cela simplifie.

    • [^] # Re: Docker a la mano ?

      Posté par  (site web personnel) . Évalué à 1.

      Dans les exemples de crun, ils utilisent podman et crun:

      https://github.com/containers/crun

      $ podman --runtime /usr/bin/crun run --rm --memory 4M fedora echo it works

      Est-ce possible de changer le runtime de docker pour utiliser crun?

      Sinon, le fait de ne pas fournir un oneliner a la Docker est problematique.

  • # Utilisable pour simuler un environnement de VM kvm complet?

    Posté par  . Évalué à 1.

    Bonjour,
    J'ai plusieurs VM Kvm, 1 AD windows, 1 windows 10, 1 debian 11, 1 opnsense (vm firewall).
    J'ai essayé de lancer le tout sous virt-manager, mais je trouve assez compliqué la configuration des bridges, et des réseau isolés.
    Idéalement je voudrais que les Vm soient dans un réseau isolé et puissent communiquer avec internet via la VM opnsense.
    Le but est de pouvoir expérimenter dans un environnement type entreprise. Je voudrais par exemple assez facilement echanger des fichiers entre mon host et les VM isolés, (fichiers de scripts ansible), pouvoir analyser ce qui se passe sur le réseau isolé (wireshark).

    J'ai parcouru (rapidement) le site de cloonix, la partie wireshark a l'air top, vswitch, ca ressemble vraiment a ce que je cherche. Par contre je ne sais si je pourrais mettre la partie "firewall", j'ai l'impression que dans les exemples du site on reste sur du reseau purement isolé.

    Penses-tu que cloonix pourrais me permettre cela, ou il ne peut pas réaliser la partie connection avec le réseau coté internet? Si c'est possibel j'ai l'intuition que j'aurais plus de possibilités que ma solution actuelle.

    Ps: pour les machines windows (non supportées par cloonix), j'ai juste besoin d'une visu de l'écran comme dans virt-manager, je n'ai pas besoin de lui envoyer des fichiers depuis le host.

    • [^] # Re: Utilisable pour simuler un environnement de VM kvm complet?

      Posté par  (site web personnel) . Évalué à 4.

      Il y a dans cloonix un objet "nat", il permet de faire des apt-get par exemple ou lancer un browser sur le vrai internet…
      Il suffit de creer le nat, le connecter à une interface d'une vm puis faire dhclient sur l'interface de la vm connecté (dhclient de l'interieur de la vm).

      Les windows fonctionnent mais il faut utiliser des utilitaires pour la para-virtualisation:

      https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.215-2/

      C'est pas vraiment simple mais je l'ai fait plusieurs fois…
      Avec une windows, il n'y a pas la console sur double-click comme pour une linux.

      • [^] # Re: Utilisable pour simuler un environnement de VM kvm complet?

        Posté par  . Évalué à 0.

        Merci pour la réponse, pour virtio, pas de soucis, c'est effectivement ce que j'ai fait.
        Est il possible d'avoir un interface bridge plutot que NAT?
        Le NAT est limité dans les ports, un bridge (de ce que j'ai expérimenté) semble plus adapaté à la simulation réelle, on se retrouve presque comme un nouveau PC sur le réseau. (idéal pour simuler un firewall)

        Je vais quand même regarder ton logiciel, ca m'a l'air intéressant pour mon cas!

        • [^] # Re: Utilisable pour simuler un environnement de VM kvm complet?

          Posté par  (site web personnel) . Évalué à 4.

          Pour les bridges: 2 solutions, en demandant une interface vhost sur une vm, on obtient une interface visible dans la machine hote de nom vho_1_1_0 par exemple et qui est extremement rapide (plusieurs giga-octets ou dizaine de giga-bits) ou alors demander un tap qui possede la fonctionnalité wireshark mais d'un seul giga-bit par seconde.

          http://clownix.net/doc_stored/build-22-01/html/doc/ovs.html

          Bien sur, le tap comme le vho_x_y_z peuvent etre configuré avec une address et donnent acces à la machine hote. Dans cette configuration, c'est plus difficile d'acceder à internet qu'avec le nat.

          Le nat se branche sur une vm mais utilise udp et tcp de l'hote qui a un acces directe à internet en général alors que si on a fait un tap, il faut encore bosser pour passer sur internet surtout si on est derriere un routeur adsl qui normalement ne gère qu'un réseau local en 192.168…

  • # Avoir un bonne image, c'est important.

    Posté par  (site web personnel) . Évalué à 2.

    Cloonix (le produit) ou Clownix (le site web), c'est confus.
    La repompe du logo Google, bon, c'est pas suuuper professionel.
    Enfin, le poisson fait un peu… comment dire… poupée gonflable.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.