Différences

Ci-dessous, les différences entre deux révisions de la page.

Lien vers cette vue comparative

Les deux révisions précédentes Révision précédente
Prochaine révision
Révision précédente
technique:docker:general:quemu_cross_running [2021/01/22 11:33] – [QEMU dans Docker : le meilleur des 2 mondes] gblondtechnique:docker:general:quemu_cross_running [2021/10/16 18:19] (Version actuelle) qduchemi
Ligne 1: Ligne 1:
 {{indexmenu_n>70}} {{indexmenu_n>70}}
  
-# QEMU : Utiliser des conteneurs avec une architecture a priori incompatible avec l'hôte+# QEMU : utiliser une architecture incompatible avec l'hôte 
 + 
 +<bootnote warning> 
 +Cet article est très spécifique, vous n'avez probablement pas besoin de le lire si vous voulez découvrir Docker! 
 +</bootnote> 
 Saviez-vous que l'utilisation conjointe de Docker et QEMU permet d'utiliser par exemple un conteneur ARMv7 sur un hôte x86-AMD64 de manière (presque) totalement transparente ? Non vous ne rêvez pas, c'est même très simple à mettre en place ! Saviez-vous que l'utilisation conjointe de Docker et QEMU permet d'utiliser par exemple un conteneur ARMv7 sur un hôte x86-AMD64 de manière (presque) totalement transparente ? Non vous ne rêvez pas, c'est même très simple à mettre en place !
  
Ligne 16: Ligne 21:
 <bootnote question>Mais pourquoi aurait-on besoin de mélanger ces architectures ?</bootnote> <bootnote question>Mais pourquoi aurait-on besoin de mélanger ces architectures ?</bootnote>
  
-Il y a plusieurs cas d’utilisation où il est utile émuler un microprocesseur différent de celui de la machine hôte, notamment durant des phases de développement ou de test d’un programme. Imaginez que vous développez un gros logiciel compilé pour des Raspberry Pi, architecture ARMv7, mais que votre poste de travail est équipé d’un microprocesseur x86-AMD64. Il y a alors 4 manières de compiler ce programme :+Il y a plusieurs cas d’utilisation où il est utile d’émuler un microprocesseur différent de celui de la machine hôte, notamment durant des phases de développement ou de test d’un programme. Imaginez que vous développez un gros logiciel compilé pour des Raspberry Pi, architecture ARMv7, mais que votre poste de travail est équipé d’un microprocesseur x86-AMD64. Il y a alors 4 manières de compiler ce programme :
  
   * Compiler depuis une Raspberry Pi : cette solution fonctionne pour des petits projets, mais montre rapidement ses limites en matières de ressources matérielles disponibles (surtout la RAM), et est en général la plus lente des 4 solutions ;   * Compiler depuis une Raspberry Pi : cette solution fonctionne pour des petits projets, mais montre rapidement ses limites en matières de ressources matérielles disponibles (surtout la RAM), et est en général la plus lente des 4 solutions ;
Ligne 66: Ligne 71:
 mask ffffffffffffff00fffffffffffffffffeffffff mask ffffffffffffff00fffffffffffffffffeffffff
 </code> </code>
 +
 +Cette méthode a l'avantage de ne pas nécessiter d'installer des paquets supplémentaires sur la machine hôte. Mais tout ce qui suit est tout-à-fait valable si vous avez installé qemu en global (''apt install qemu-user-static'').
  
 ### Exécuter un conteneur d’une architecture incompatible ### Exécuter un conteneur d’une architecture incompatible
  
-Comme indiqué dans l'introduction, ici rien ne change, on peut utiliser docker normalement. Enfin presque, car docker sélectionnera toujours l'architecture hôte pour une image disponible avec plusieurs architecture. Il n'y a malheureusement pas à ce jour de solution pour forcer docker à utiliser une architecture spécifiqueCette fonctionnalité existe pourtant dans d'autres outilscomme skopeo.+Comme indiqué dans l'introduction, ici rien ne change, on peut utiliser docker normalement. Enfin presque, car docker sélectionnera toujours l'architecture hôte pour une image disponible avec plusieurs architecture. Pour sélectionner l'architecture voulue, il faut utiliser l'option ''--platform=linux/arm64''. À ce jour (docker v19.03.13)cette option n'est disponible que en [[https://docs.docker.com/engine/reference/commandline/dockerd/#description | mode experimental]].
  
 Voici un exemple d'exécution : Voici un exemple d'exécution :
 +
 <code> <code>
 $ uname -a $ uname -a
Ligne 82: Ligne 90:
 </code> </code>
  
-<bootnote information>+<bootnote>
 Si vous obtenez l'erreur Si vous obtenez l'erreur
  
Ligne 88: Ligne 96:
 standard_init_linux.go:211: exec user process caused "exec format error" standard_init_linux.go:211: exec user process caused "exec format error"
 </code> </code>
-c’est que vous avez oublié d'installer qemu ! +c’est que vous avez oublié de configurer qemu ! 
-<bootnote>+</bootnote>
  
 À partir de maintenant, il est possible d'utiliser une image docker contenant un compilateur d'une autre architecture pour effectuer de la cross-compilation. Mais on peut encore aller plus loin : créer une image pour une autre architecture ! À partir de maintenant, il est possible d'utiliser une image docker contenant un compilateur d'une autre architecture pour effectuer de la cross-compilation. Mais on peut encore aller plus loin : créer une image pour une autre architecture !
Ligne 143: Ligne 151:
 Linux 211b99ac36e4 5.8.0-38-generic #43-Ubuntu SMP Tue Jan 12 12:42:13 UTC 2021 aarch64 GNU/Linux Linux 211b99ac36e4 5.8.0-38-generic #43-Ubuntu SMP Tue Jan 12 12:42:13 UTC 2021 aarch64 GNU/Linux
 </code> </code>
 +
 +De même, il est possible d'utiliser l'option ''--platform=linux/arm64'' dans l'instruction ''FROM'' si docker est en mode experimental.
 +
 +<bootnote important>
 +Suivant les clients dockers, il est possible que l'architecture indiquée dans l'image ne corresponde pas à celle réelle ; dans ce cas vous pourriez par mégarde écraser une image de l'architecture hôte au moment de pousser l'image sur un serveur multi-arch !
 +
 +Pour connaître l'architecture que docker a associé avec une image, on peut utiliser la commande suivante :
 +
 +<code bash>
 +$ docker inspect test_docker | grep Architecture
 +        "Architecture": "arm64",
 +</code>
 +
 +</bootnote>
 +
 +<bootnote>
 +En théorie, rien ne vous interdit de copier un binaire d'une architecture A dans une image d'une architecture B. Cependant, vous ne pourrez pas l'exécuter, même si qemu est configuré sur la machine hôte.
 +</bootnote>
  • technique/docker/general/quemu_cross_running.1611311583.txt.gz
  • de gblond