Je ne suis pas convaincu, si pour faire un ls il est nécessaire de lancer un container unikernels
'faire un ls' n'est pas une "application serveur". C'est de l'administration. T'as pas forcement besoin de faire ca dans le meme contexte (=kernel+os) qu'une application déployée en prod.
Tu peux prevoir un container unikernel qui contient un shell complet (donc avec ls) par exemple. Mais c'est de l'admin.
Si ton app a un système de ficher (c'est pas forcement obligé avec un unikernel) et que tu souhaite 'ls' ce système de fichier il peut être accedé par partage via l'hyperviseur par exemple (comme 2 VMs peuvent partager un meme fs de leur hote).
Apres "faire de l'admin" (ou un ls) dans ce contexte d'unikernels n'a plus trop de sens aussi.
On raisonne trop en fonction des OS actuels et de l'admin qu'ils permettent ou nécessitent. Les unikernels permettront des trucs complètement différents ou une app a sa propre pile réseau (ou plusieurs), pas ou plein de filesystems et pas forcement des filesystems actuels ou connus, etc. Il faut donc aussi changer sa facon de raisonner sur l'architecture et le type des ressources (réseau, fichier, etc) et comment on y accède.
Par contre pour les grosses appli je vois bien le principe mais comment faire si je souhaite netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c dans l'unikernels qui fait tourner apache ?
Il ne faut pas forcement chercher a transposer ses habitudes avec l'unikernel.
L’exécutable du serveur web embarque sa propre couche tcp/ip , etc donc faire un netstat n'a pas trop de sens. Si on veut cette fonctionnalité il faut l'intégrer dans l'application directement ou partager la couche ip dans l'hyperviseur. etc
Aujourd'hui avec un container, tu as un Ubuntu server complet, donc cela fonctionne...
Tu n'es pas obligé. Les gens mettent souvent un Ubuntu (ou autre) complet par flemme mais si on veut être propre, securisé et léger il faudrait ne mettre que le strict nécessaire pour faire tourner l'app.
D'ailleurs pas mal de containers utilisent plutot Alpine (5Mo) ou Busybox (2Mo) plutot qu'un Ubuntu (180Mo).
Par exemple, le
container officiel d'Apache utilise un full "debian:jessie" mais il y a aussi une version 'light' basée sur Alpine.
root@vdock:~# docker images
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE
httpd latest 929f5c8eee3f 4 weeks ago 195.4 MB
httpd alpine 59225972dbea 7 weeks ago 63.81 MB
=>presque 200MB pour un container Apache sur debian et 64MB pour le meme sur Alpine.
On arrive même à faire des containers 'from scratch' donc sans aucune distrib (y'a donc pas de /bin/ls ou de shell dans le container. le dossier / est vide de base et on ajoute juste le binaire de l'app et éventuellement des fichiers statiques propre a l'app ou ses libs).
Ce qui est bien c'est qu'on a le choix. On peut faire un container 'plein' de trucs (donc avec un shell et ls dedans par exemple) ou juste avec l'application. Une version 'debug' ou y'a netstat et une version 'securé et opti' sans rien d'autre que l'app. etc