Différences
Ci-dessous, les différences entre deux révisions de la page.
Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente Prochaine révisionLes deux révisions suivantes | ||
technique:docker:general:quemu_cross_running [2021/01/21 11:53] – Ajout partie exéctution conteneur gblond | technique:docker:general:quemu_cross_running [2021/01/22 13:43] – [Présentation] gblond | ||
---|---|---|---|
Ligne 16: | Ligne 16: | ||
< | < | ||
- | 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 42: | Ligne 42: | ||
< | < | ||
$ docker run --rm --priviledged multiarch/ | $ docker run --rm --priviledged multiarch/ | ||
- | Status: Downloaded newer image for multiarch/ | ||
Setting / | Setting / | ||
Setting / | Setting / | ||
Ligne 67: | Ligne 66: | ||
mask ffffffffffffff00fffffffffffffffffeffffff | mask ffffffffffffff00fffffffffffffffffeffffff | ||
</ | </ | ||
+ | |||
+ | Cette méthode a l' | ||
### Exécuter un conteneur d’une architecture incompatible | ### Exécuter un conteneur d’une architecture incompatible | ||
- | Comme indiqué dans l' | + | Comme indiqué dans l' |
Voici un exemple d' | Voici un exemple d' | ||
+ | |||
< | < | ||
$ uname -a | $ uname -a | ||
Ligne 82: | Ligne 84: | ||
dev home | dev home | ||
</ | </ | ||
+ | |||
+ | < | ||
+ | Si vous obtenez l' | ||
+ | |||
+ | < | ||
+ | standard_init_linux.go: | ||
+ | </ | ||
+ | c’est que vous avez oublié de configurer qemu ! | ||
+ | </ | ||
À partir de maintenant, il est possible d' | À partir de maintenant, il est possible d' | ||
### Créer un conteneur pour une architecture incompatible | ### Créer un conteneur pour une architecture incompatible | ||
+ | |||
+ | De même que pour l' | ||
+ | |||
+ | <code dockerfile> | ||
+ | FROM scratch | ||
+ | </ | ||
+ | |||
+ | Cependant, on peut préciser une image exclusivement disponible pour l' | ||
+ | |||
+ | <code dockerfile Dockerfile> | ||
+ | FROM alpine as first_stage | ||
+ | |||
+ | RUN uname -a > /uname1.txt | ||
+ | |||
+ | FROM arm64v8/ | ||
+ | |||
+ | COPY --from=first_stage /uname1.txt /uname1.txt | ||
+ | |||
+ | CMD echo "First stage: " && cat /uname1.txt && echo "Last stage: " && uname -a | ||
+ | </ | ||
+ | |||
+ | on obtient alors par exemple ces résultats : | ||
+ | |||
+ | <code bash> | ||
+ | $ docker build -t test_docker . | ||
+ | Sending build context to Docker daemon | ||
+ | Step 1/5 : FROM alpine as first_stage | ||
+ | | ||
+ | Step 2/5 : RUN uname -a > /uname1.txt | ||
+ | | ||
+ | | ||
+ | Step 3/5 : FROM arm64v8/ | ||
+ | | ||
+ | Step 4/5 : COPY --from=first_stage /uname1.txt /uname1.txt | ||
+ | | ||
+ | | ||
+ | Step 5/5 : CMD echo "First stage: " && cat /uname1.txt && echo "Last stage: " && uname -a | ||
+ | | ||
+ | Removing intermediate container 33ffd9407823 | ||
+ | | ||
+ | Successfully built b76215700cbb | ||
+ | Successfully tagged test_docker: | ||
+ | |||
+ | $ docker run --rm -it test_docker | ||
+ | First stage: | ||
+ | Linux cd2527490809 5.8.0-38-generic #43-Ubuntu SMP Tue Jan 12 12:42:13 UTC 2021 x86_64 Linux | ||
+ | Last stage: | ||
+ | Linux 211b99ac36e4 5.8.0-38-generic #43-Ubuntu SMP Tue Jan 12 12:42:13 UTC 2021 aarch64 GNU/Linux | ||
+ | </ | ||
+ | |||
+ | De même, il est possible d' | ||
+ | |||
+ | < | ||
+ | Suivant les clients dockers, il est possible que l' | ||
+ | |||
+ | Pour connaître l' | ||
+ | |||
+ | <code bash> | ||
+ | $ docker inspect test_docker | grep Architecture | ||
+ | " | ||
+ | </ | ||
+ | |||
+ | </ | ||
+ | |||
+ | < | ||
+ | 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' | ||
+ | </ |