[docker] premiers pas avec Moby et LinuxKit
Posted by herve on 19 Avr 2017 in Linux et logiciel libre
Intro
Lors de la Dockercon, Docker vient d'annoncer
- Moby: "A new open-source project for to advance the software containerization movement" (https://blog.docker.com/2017/04/introducing-the-moby-project/)
- Linuxkit: "A toolkit for building secure, lean and portable Linux subsystems" (https://blog.docker.com/2017/04/introducing-linuxkit-container-os-toolkit/)
Je ne sais pas pour vous, mais j'ai trouvé ces annonces un peu nébuleuses.
Si on y ajoute le fait que github.com/docker/docker a été renommé en moby/moby, il y a vraiment de quoi se perdre.
Le meilleur de moyen de se faire une idée, c'est de jouer avec!
Direction le github de linuxkit: https://github.com/linuxkit/linuxkit
Prise en main
Et c'est parti pour un essai, en suivant les instructions.
Récupération du dépôt:
[herve@salon git]$ git clone https://github.com/linuxkit/linuxkit.gitClonage dans 'linuxkit'...remote: Counting objects: 19756, done.remote: Compressing objects: 100% (10/10), done.remote: Total 19756 (delta 1), reused 0 (delta 0), pack-reused 19746Réception d'objets: 100% (19756/19756), 15.66 MiB | 703.00 KiB/s, fait.Résolution des deltas: 100% (11869/11869), fait.Vérification de la connectivité... fait.[herve@salon git]$ cd linuxkit/
Compilation de moby:
[herve@salon linuxkit]$ maketar cf - vendor src/initrd src/pad4 -C src/cmd/moby . | docker run --rm --net=none --log-driver=none -i linuxkit/go-compile:4513068d9a7e919e4ec42e2d7ee879ff5b95b7f5@sha256:bdfadbe3e4ec699ca45b67453662321ec270f2d1a1dbdbf09625776d3ebd68c5 --package github.com/linuxkit/linuxkit --ldflags "-X main.GitCommit=f2d6752751318477ec86e4677514d5a4890249c1 -X main.Version="0.0" " -o bin/moby > tmp_moby_bin.tarUnable to find image 'linuxkit/go-compile:4513068d9a7e919e4ec42e2d7ee879ff5b95b7f5@sha256:bdfadbe3e4ec699ca45b67453662321ec270f2d1a1dbdbf09625776d3ebd68c5' locallysha256:bdfadbe3e4ec699ca45b67453662321ec270f2d1a1dbdbf09625776d3ebd68c5: Pulling from linuxkit/go-compile627beaf3eaaf: Pulling fs layer1b3a1005911c: Pulling fs layer[...]d58e6f1740ab: Pull complete49418cbb2668: Pull completeDigest: sha256:bdfadbe3e4ec699ca45b67453662321ec270f2d1a1dbdbf09625776d3ebd68c5Status: Downloaded newer image for linuxkit/go-compile@sha256:bdfadbe3e4ec699ca45b67453662321ec270f2d1a1dbdbf09625776d3ebd68c5gofmt...govet...golint...ineffassign...go build...tar xf tmp_moby_bin.tar > bin/mobyrm tmp_moby_bin.tartouch bin/moby[herve@salon linuxkit]$
On voit donc que la compilation se fait dans un container, qui sort un fichier bin/moby.
C'est un binaire go, compilé en statique.
C'est un binaire go, compilé en statique.
Et il fait quoi ce binaire ?
[herve@salon linuxkit]$ ./bin/moby --help
USAGE: moby [options] COMMAND
Commands:
build Build a Moby image from a YAML file
run Run a Moby image on a local hypervisor or remote cloud
version Print version information
help Print this message
Run 'moby COMMAND --help' for more information on the command
Options:
-q Quiet execution
-v Verbose execution
[herve@salon linuxkit]$ ./bin/moby build --helpUSAGE: ./bin/moby build [options] <file>[.yml]Options:-name stringName to use for output files-pullAlways pull images[herve@salon linuxkit]$
Il a en gros deux fonctions:
- création d'une "image moby"
- exécution d'une "image moby"
On crée notre première image avec le fichier yaml d'exemple.
[herve@salon linuxkit]$ ./bin/moby build linuxkit.ymlExtract kernel image: mobylinux/kernel:4.9.xAdd init containers:Process init image: linuxkit/init:42fe8cb1508b3afed39eb89821906e3cc7a70551Process init image: mobylinux/runc:b0fb122e10dbb7e4e45115177a61a3f8d68c19a9Process init image: linuxkit/containerd:60e2486a74c665ba4df57e561729aec20758daedProcess init image: mobylinux/ca-certificates:eabc5a6e59f05aa91529d80e9a595b85b046f935Add onboot containers:Create OCI config for mobylinux/sysctl:2cf2f9d5b4d314ba1bfc22b2fe931924af666d8cCreate OCI config for linuxkit/binfmt:8881283ac627be1542811bd25c85e7782aebc692Create OCI config for linuxkit/dhcpcd:48e249ebef6a521eed886b3bce032db69fbb4afaAdd service containers:Create OCI config for mobylinux/rngd:3dad6dd43270fa632ac031e99d1947f20b22eec9Create OCI config for nginx:alpineAdd files:etc/docker/daemon.jsonCreate outputs:linuxkit-bzImage linuxkit-initrd.img linuxkit-cmdlinelinuxkit.isolinuxkit-efi.iso[herve@salon linuxkit]$
Il a donc travaillé à partir d'images disponibles sur le hub docker, et a créé quelques fichiers posés dans le répertoire courant.
Une vue rapide sur ce qu'il a récupéré et créé:
Une vue rapide sur ce qu'il a récupéré et créé:
[herve@salon linuxkit]$ docker imagesREPOSITORY TAG IMAGE ID CREATED SIZElinuxkit/containerd 60e2486a74c665ba4df57e561729aec20758daed afaa98d7b77e 4 days ago 83.1MBlinuxkit/init 42fe8cb1508b3afed39eb89821906e3cc7a70551 52ad30265955 4 days ago 4.55MBlinuxkit/dhcpcd 48e249ebef6a521eed886b3bce032db69fbb4afa 4a8d5b4ecdda 5 days ago 6.86MBlinuxkit/binfmt 8881283ac627be1542811bd25c85e7782aebc692 dd624a622fea 6 days ago 10.6MBlinuxkit/go-compile <none> 3bea6c95b424 6 days ago 411MBlinuxkit/mkimage-iso-bios <none> 9fc22c04f66c 6 days ago 18.9MBlinuxkit/mkimage-iso-efi <none> 123a3bc2f714 7 days ago 21.6MBmobylinux/kernel 4.9.x 26ec714a55ef 9 days ago 7.8MBmobylinux/ca-certificates eabc5a6e59f05aa91529d80e9a595b85b046f935 ce2c43db3a0f 12 days ago 275kBmobylinux/runc b0fb122e10dbb7e4e45115177a61a3f8d68c19a9 cb5eaf524002 12 days ago 6.87MBnginx alpine bedece1f06cc 13 days ago 54.3MBmobylinux/sysctl 2cf2f9d5b4d314ba1bfc22b2fe931924af666d8c c62b83d03caa 5 weeks ago 1.8MBmobylinux/rngd 3dad6dd43270fa632ac031e99d1947f20b22eec9 818d6105077e 3 months ago 129kB[herve@salon linuxkit]$ ls -ltr[...]-rw-r--r--. 1 herve herve 52013237 19 avril 20:03 linuxkit-initrd.img-rw-r--r--. 1 herve herve 7021136 19 avril 20:03 linuxkit-bzImage-rw-r--r--. 1 herve herve 40 19 avril 20:03 linuxkit-cmdline-rw-r--r--. 1 herve herve 59768832 19 avril 20:04 linuxkit.iso-rw-r--r--. 1 herve herve 59949056 19 avril 20:04 linuxkit-efi.iso[herve@salon linuxkit]$
Exécution!
[herve@salon linuxkit]$ ./bin/moby run linuxkit[ 0.000000] Linux version 4.9.21-moby (root@84baa8e89c00) (gcc version 6.2.1 20160822 (Alpine 6.2.1) ) #1 SMP Sun Apr 9 22:21:32 UTC 2017[ 0.000000] Command line: console=ttyS0 console=tty0 page_poison=1[ 0.000000] x86/fpu: Legacy x87 FPU detected.[ 0.000000] x86/fpu: Using 'eager' FPU context switches.[ 0.000000] e820: BIOS-provided physical RAM map:[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009fbff] usable[ 0.000000] BIOS-e820: [mem 0x000000000009fc00-0x000000000009ffff] reserved[...][ 3.082403] Freeing unused kernel memory: 1184K (ffff91e15ecd8000 - ffff91e15ee00000)[ 3.570774] tsc: Refined TSC clocksource calibration: 3600.004 MHz[ 3.571355] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x33e456ed7d0, max_idle_ns: 440795322762 nsWelcome to LinuxKit## .## ## ## ==## ## ## ## ## ===/"""""""""""""""""\___/ ===~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ / ===- ~~~\______ o __/\ \ __/\____\_______// #
Woohoo, il m'a lancé… un container? Avec un microkernel? Ou une VM?
[herve@salon ~]$ pstree -la $(pgrep moby)moby run linuxkit├─qemu-system-x86 -device virtio-rng-pci -smp 1 -m 1024 -enable-kvm -machine q35,accel=kvm:tcg -kernel linuxkit-bzImage -initrd linuxkit-initrd.img -append console=ttyS0 console=tty0 page_poison=1 -nographic│ └─2*[{qemu-system-x86}]└─4*[{moby}][herve@salon ~]$
Une VM qemu visiblement!
À noter: un objectif est de démarrer ça sur des serveurs virtuels sur un IaaS, ou même sur des machines physiques via PXE.
À noter: un objectif est de démarrer ça sur des serveurs virtuels sur un IaaS, ou même sur des machines physiques via PXE.
Retournons sur notre VM.
À part les process kernel, qu'est-ce qui tourne?
/ # cat /etc/alpine-release
3.5.2
/ # ps edf | grep -v "\[.*\]"PID USER TIME COMMAND1 root 0:02 /sbin/init276 root 0:00 /usr/bin/containerd280 root 0:00 {containers} /bin/sh /etc/init.d/containers288 root 0:00 /bin/sh --289 root 0:00 /bin/sh --417 root 0:00 ctr run --runtime-config /containers/services/nginx/config.json --rootfs /containers/services/nginx/rootfs --id nginx433 root 0:00 containerd-shim447 root 0:00 nginx: master process nginx -g daemon off;532 100 0:00 nginx: worker process600 root 0:00 ps edf/ #
On a vraiment très peu de process. Init, sh, et un container nginx.
Mais pas de Docker!
Mais pas de Docker!
Regardons ctr de plus près:
/ # ctr --helpNAME:ctr -_______/ /______/ ___/ __/ ___// /__/ /_/ /\___/\__/_/containerd clientUSAGE:ctr [global options] command [command options] [arguments...]VERSION:1.0-dev+unknownCOMMANDS:run run a containerevents display containerd eventsdelete delete an existing containerlist list containersinfo get info about a containerkill signal a containerpprof provides golang pprof outputs for containerdexec execute additional processes in an existing containershim interact with a shim directlyhelp, h Shows a list of commands or help for one commandGLOBAL OPTIONS:--debug enable debug output in logs--address value, -a value address for containerd's GRPC server (default: "/run/containerd/containerd.sock")--root value path to content store root (default: "/var/lib/containerd")--help, -h show help--version, -v print the version/ # ctr listID PID STATUSnginx 447 RUNNING/ # ctr info --id nginx
{
"id": "nginx",
"pid": 447,
"status": 2
}
/ #
C'est un outil permettant de gérer ses containers, mais beaucoup plus limité que docker.
Par exemple, je n'ai pas réussi à puller une nouvelle image avec.
Par exemple, je n'ai pas réussi à puller une nouvelle image avec.
Conclusion:
Il y a quelque chose de pas clair sur le nommage linuxkit / moby.
Moby automatise la création d'images OS, linuxkit fournit toutes les briques pour cette création. Et les briques de base sont du Alpine.
Moby automatise la création d'images OS, linuxkit fournit toutes les briques pour cette création. Et les briques de base sont du Alpine.
Mais dans ce cas, pourquoi avoir renommé le dépôt docker/docker sur github? Ça semble deux produits bien différents!
Pour ce qui est de l'utilité de ces images OS, j'ai ma petite idée. En suivant le principe du pet vs cattle, du standard et jetable, il est logique d'aller jusqu'à des serveurs jetables.
On appelle ça des serveurs Phoenix, ou on peut aller encore plus loin avec des serveurs immuables.
On change le cycle de intégration/release/déploiement, pour livrer des images d'OS (50Mo l'image nginx créée pour l'article), et pour déployer on reboote les serveurs, ou on recycle les VMs.