La Fibre
Télécom => Logiciels et systèmes d'exploitation => 
Linux (usage serveur) => Discussion démarrée par: kgersen le 01 septembre 2016 à 17:07:12
-
Hors sujet extrait de Avis de corrector sur Unix (https://lafibre.info/systeme-exploitation/avis-de-corrector-sur-unix/)
De toute façon Linux (et tout les autres OS) c'est *bientôt* du passé.
L'évolution en marche c'est la fin des OS au profit d'hyperviseurs et unikernels.
Une OS était fait pour partager et organiser l'acces au ressources physiques entre plusieurs applications.
Puis les VM sont apparu puis les containers.
Les applications modernes c'est une application par container donc on n'a plus vraiment besoin de l'OS et de tout ce qu'il implique en terme de sécurité, lourdeur, maintenance, maj, etc.
Il est vrai qu'avoir un Ubuntu complet pour faire tourner juste un serveur web et que ca c'est un peu "overkill". 90% des fichiers présents et des fonctions du kernel ne servent a rien mais sont la et sont donc sources potentielles de failles et consomment des ressources.
Pour palier a cela, on commence a voir des prototypes d'applications qui tournent directement sur un hyperviseur, sans OS/kernel en dessous.
Google travaille la dessus a fond: s'ils pouvaient se passer de l'OS sur leur millions de serveurs le gain serait juste énorme.
Voici un état d'avancement de leur travaux:
https://www.youtube.com/watch?v=F2Ls6xZdSrE
Docker prend la meme voie aussi. Ils ont racheté Unikernels en janvier 2016: https://blog.docker.com/2016/01/unikernel/
Dans les 2 cas, le but est le même: partir du code source de l'application pour générer un "executable" qui fonctionne sans OS en dessous, directement sur du hardware (virtualisé).
Ca reste pour le moment du prototype mais tout le monde veut aller vers ca... sauf les sysadmins qui voit un menace a leur boulot ...
bref sus a l'OS c'est du passé!
-
Si c'est la fin imminente des OS pourquoi Google bosse pour en faire un à partir de zéro alors (https://fuchsia.googlesource.com/) ?
-
Si c'est la fin imminente des OS pourquoi Google bosse pour en faire un à partir de zéro alors (https://fuchsia.googlesource.com/) ?
La c'est pour du mobile/IoT, pas du serveur.
Google ca n'est pas Microsoft, ils ne cherchent pas à faire tourner le meme OS sur leurs serveurs et les mobiles/IoT... :P
Les gens qui s'occupent de l'infra et des serveurs ne sont pas contraits par les travaux des gens sur mobiles/Android.
Mais a terme, les containers/unikernels viendront aussi sur le desktop et le mobile, y'a pas de raison... ;D
D'ailleurs ChromeOS supporte les apps Android de cette facon.
-
Dans ce projet il y a 2 kernels distinct : LK (Little Kernel) pour de l’embarqué, mais l'autre kernel "Magenta" est prévu pour le PC moderne et les smartphones :
https://github.com/fuchsia-mirror/magenta/blob/master/docs/mg_and_lk.md (https://github.com/fuchsia-mirror/magenta/blob/master/docs/mg_and_lk.md)
-
De toute facon Linux (et tout les autres OS) c'est *bientot* du passé.
L'évolution en marche c'est la fin des OS au profit d'hyperviseurs et unikernels.
Une OS était fait pour partager et organiser l'acces au ressources physiques entre plusieurs applications.
Puis les VM sont apparu puis les containers.
Les applications modernes c'est une application par container donc on n'a plus vraiment besoin de l'OS et de tout ce qu'il implique en terme de sécurité, lourdeur, maintenance, maj, etc.
Il est vrai qu'avoir un Ubuntu complet pour faire tourner juste un serveur web et que ca c'est un peu "overkill". 90% des fichiers présents et des fonctions du kernel ne servent a rien mais sont la et sont donc sources potentielles de failles et consomment des ressources.
Pour palier a cela, on commence a voir des prototypes d'applications qui tournent directement sur un hyperviseur, sans OS/kernel en dessous.
Google travaille la dessus a fond: s'ils pouvaient se passer de l'OS sur leur millions de serveurs le gain serait juste énorme.
Voici un état d'avancement de leur travaux:
https://www.youtube.com/watch?v=F2Ls6xZdSrE
Docker prend la meme voie aussi. Ils ont racheté Unikernels en janvier 2016: https://blog.docker.com/2016/01/unikernel/
Dans les 2 cas, le but est le même: partir du code source de l'application pour générer un "executable" qui fonctionne sans OS en dessous, directement sur du hardware (virtualisé).
Ca reste pour le moment du prototype mais tout le monde veut aller vers ca... sauf les sysadmins qui voit un menace a leur boulot ...
bref sus a l'OS c'est du passé!
Mouais, t'es un peu trop corporate sur le sujet, non ?
Le "on vire l'OS", ça existe déjà, pour le réseau par exemple
Au final, c'est beaucoup de contraintes, virer l'OS, c'est mettre un processus par serveur, dédié un serveur par tâche.
C'est pire que ne pas faire de virtualisation : c'est un vrai retour aux OS mono-tâche, bref, une catastrophe;
-
Oui j'ai un gros doute sur l'efficacité, aussi.
-
Mouais, t'es un peu trop corporate sur le sujet, non ?
Le "on vire l'OS", ça existe déjà, pour le réseau par exemple
Au final, c'est beaucoup de contraintes, virer l'OS, c'est mettre un processus par serveur, dédié un serveur par tâche.
C'est pire que ne pas faire de virtualisation : c'est un vrai retour aux OS mono-tâche, bref, une catastrophe;
qui parle d'un processus par serveur ? on a un hyperviseur sur lequel on fait tourner autant d' "apps" qu'on veut.
Sur la meme machine, je peux mettre mon app serveur web et mon app serveur sql par exemple. c'est juste qu'il n'y a pas plus d'OS commun aux deux. chaque vm est une app, si on veut simplifier.
De toute facon on en est deja la depuis la virtualisation: avec VMware et les autres on a deja séparer les apps entres elles. On trouve que tres rarement plusieurs apps dans la meme vm (j'en connais qui font encore cela mais c'est rare). Chaque app a son os et sa vm. C'est cette évolution qui rend 'superflue' l'OS en fait. Il ne sert plus a partager le hardware entre plusieurs apps.
voila l'évolution:
(http://blogs-images.forbes.com/janakirammsv/files/2016/01/Unikernels.png)
De toute facon ca prendra du temps , ca va pas basculer du jour au lendemain.
-
T'as le hardware
Sur ton hardware, tu fais tourner un unique processus, c'est lui qui manipule tout le hardware
Ce processus, traditionnellement, est appelé "kernel". Il permet de partager du temps hard entre plusieurs autres processus
Si tu vires le kernel, personne ne gère le partage de temps, tu ne peux donc avoir qu'un seul processus sur la machine
Sauf si ton processus, qui n'est pas un kernel, s'occupe de faire cette tâche. C'est donc un kernel.
Ceci dit, je note qu'il y a peut-être confusion (moins dans ta tête que dans la façon dont je lis ta prose) entre OS et kernel (et linux, donc)
Si par "OS", tu veux bien dire kernel + tout le tas qui forme le userspace, alors je parsage ton point de vu
M'enfin, note que ça existe depuis toujours, un OS qui contient juste un kernel et des VM (coucou xen)
Aucun intérêt;
-
T'as le hardware
Sur ton hardware, tu fais tourner un unique processus, c'est lui qui manipule tout le hardware
Ce processus, traditionnellement, est appelé "kernel". Il permet de partager du temps hard entre plusieurs autres processus
Si tu vires le kernel, personne ne gère le partage de temps, tu ne peux donc avoir qu'un seul processus sur la machine
Sauf si ton processus, qui n'est pas un kernel, s'occupe de faire cette tâche. C'est donc un kernel.
Ceci dit, je note qu'il y a peut-être confusion (moins dans ta tête que dans la façon dont je lis ta prose) entre OS et kernel (et linux, donc)
Si par "OS", tu veux bien dire kernel + tout le tas qui forme le userspace, alors je parsage ton point de vu
M'enfin, note que ça existe depuis toujours, un OS qui contient juste un kernel et des VM (coucou xen)
mouais tu joues avec les mots la ou tes notions ne sont pas les memes que moi... ;D
Aucun intérêt;
l’intérêt est tres grand car ca 'déplace' les domaines d'intervention et de responsabilité.
Avec les unikernels : le développeur (ou l'éditeur) 'build' et délivre son app (qui inclut le kernel) pour tel ou tel hyperviseur (xen par exemple). le sysadmin ne s'occupe que du hardware et de l'hyperviseur. Y'a plus de fichiers d'OS (/ et donc /bin) et d'userspace autre que l'app elle-meme (donc on ne peut lancer un shell par exemple).
Avec les containers : le développeur (ou l'éditeur) 'build' et délivre son app (qui n'inclut pas le kernel mais qui peut inclure des fichiers userspace / donc notamment un /bin). Il dépend du syadmin pour gerer le kernel en dessus (avec ou sans VM).
Avec les VMs ou sur bare metal: le développeur (ou l'éditeur) 'build' et délivre son app sous forme de binaire exécutable (elf par exemple) et un ensemble de fichiers. C'est le cas de tout ce qu'on trouve en repo (apt, yum, dnf). Il dépend du syadmin pour mettre a jour les dépendances et gérer l'OS.
Il y a aussi une énorme économie de ressource (place disque, mémoire) quand t'as des milliers de serveurs et d'apps.
-
Ouais c'est bien ça:
Avec les unikernels : le développeur (ou l'éditeur) 'build' et délivre son app (qui inclut le kernel) pour tel ou tel hyperviseur (xen par exemple). le sysadmin ne s'occupe que du hardware et de l'hyperviseur. Y'a plus de fichiers d'OS (/ et donc /bin) et d'userspace autre que l'app elle-meme (donc on peut lancer un shell par exemple).
Ça existe depuis toujours, sous windows par exemple, on appele ça des gros-binaires-static-de-merde
Système pas à jour, système troué etc etc, vla les conséquences
(ouais, le coup du "mais si, le dev va maintenir son code à jour", laisse moi rire, chez google peut-être, mais sinon ... faut pas compter sur un dev pour nettoyer)
-
Ouais c'est bien ça:
Ça existe depuis toujours, sous windows par exemple, on appele ça des gros-binaires-static-de-merde
Système pas à jour, système troué etc etc, vla les conséquences
(ouais, le coup du "mais si, le dev va maintenir son code à jour", laisse moi rire, chez google peut-être, mais sinon ... faut pas compter sur un dev pour nettoyer)
c'est pas la meme chose: un gros binaires statique Windows met en danger tout le Windows qui est en dessous.
un gros statique unikernel: y'a rien en dessous.
Le niveau d'isolation n'est pas du tout le même.
-
Ça existe depuis toujours, sous windows par exemple, on appele ça des gros-binaires-static-de-merde
Ubuntu prends la même direction que Windows, avec ses nouveaux paquets "Snap"
ça a l'air d'être un modèle "merdique" à suivre. (http://forum-images.hardware.fr/images/perso/2/s@ms.gif)
-
Le niveau d'isolation n'est pas du tout le même.
Dans les deux cas, ton code métiers (db ? serveur mail ? fichiers ? whatever) est troué :)
-
ça a l'air d'être un modèle "merdique" à suivre. (http://forum-images.hardware.fr/images/perso/2/s@ms.gif)
Dans la vraie vie les bibliothèques dynamiques peuvent être un vrai enfer à gérer...
Par contre :
Ça existe depuis toujours, sous windows par exemple, on appele ça des gros-binaires-static-de-merde
Les binaires ne sont pas si souvent statiques ça que ça soit Windows. En fait c'est ça va même à l'encontre des bonnes pratiques conseillées par Microsoft.
-
Objet dynamique.
Une bibliothèque dynamique, c'est comme l'eau sèche.
-
Je ne suis pas convaincu, si pour faire un ls il est nécessaire de lancer un
container unikernels
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 ?
Aujourd'hui avec un container, tu as un Ubuntu server complet, donc cela fonctionne...
C'est vrai que SNAP, j'ai essayé et 120 Mo la calculatrice toute basique, j'ai été impressionné...uniquement par la taille à télécharger !
Un OS complet devrait dépasser les 100 Go si chaque binaire fait plus de 100 Mo.
J'ai testé snap
Voici la liste complète des applications disponibles, contre plusieurs dizaines de milliers au format .deb :
$ sudo snap find
Name Version Summary
audovia 3.2.2 Database application for making music using JFugue MusicStrings
beagleblack 3.1 OEM Beagle Bone Black
canonical-dragon 0.7.1 The gadget snap for the dragonboard
canonical-i386 3.1.i386 The gadget snap for generic i386 systems
canonical-pc 3.2 AMD64 generic package
canonical-pc-linux 4.4.0-18+20160419.13-26 The ubuntu-core kernel snap
canonical-pi2 3.2 Raspberry Pi 2 support package
go-example-webserver 16.04-4 Minimal Golang webserver for snappy
hello-world 6.0 Hello world example
http 4.6692016 HTTPie in a snap
john-the-ripper 1.8.0-11765-g9a09113 John the Ripper Jumbo password cracker for Linux
links 2.12-1 Web browser running in text mode
moon-buggy 1.0.51.9 Drive a car across the moon
morse-converter-py 1-2 Simple command-line Morse converter
nmap 7.12SVN-0.4 Nmap ("Network Mapper") is a free and open source utility for network discovery and security auditing
notes 0.0.8~snap3.gita80fd1c Note-taking application, write down your thoughts
shout 0.53.0 A self hosted web IRC client
squid3 3.5.16-2 Squid3 web proxy
sshtron 1.0 multiplayer Tron via ssh
sudo 1 not sudo
tmux 2.3bump1 tmux
tor-middle-relay 0.2.7.6-6 Essential infrastructure node for Tor network
ubuntu-calculator-app 2.1+snap3 Ubuntu Calculator application for the Unity 7 desktop
ubuntu-clock-app 3.6+snap3 Ubuntu Clock application for the Unity 7 desktop
ubuntu-core 16.04+20160419.20-55 The ubuntu-core OS snap
xkcd-webserver 16.04-5 Show random XKCD compic via a build-in webserver
yacas 1.4.2 Yet Another Computer Algebra System
Installation d'une calculatrice au format SNAP :
$ sudo snap install ubuntu-calculator-app
120.01 MB / 120.01 MB [==============================] 100.00 % 2.26 MB/s
Voila ce que cela donne : aucune option n'est disponible à part le "favorite" qui apparaît en bas :
(https://lafibre.info/testdebit/ubuntu/201604_snap_calculator.png)
Calculatrice au format .snap : 120 Mo compressé, avec aucune option et pas de localisation en françaus
Calculatrice au format .deb : 317 Ko compressé (cf dépôt Ubuntu (http://fr.archive.ubuntu.com/ubuntu/pool/main/g/gnome-calculator/)) Elle propose bien plus d'option et a une interface localisé en Français.
Au niveau réseau, c'est complètement différent des .deb (qui sont signés et sont téléchargés en http)
.snap fait une première connexion en https sur search.apps.ubuntu.com qui pointe sur les serveurs de Canonical à Londres, quel que soit l'emplacement du client dans le monde.
.snap fait ensuite une seconde connexion, toujours en https sur public.apps.ubuntu.com qui pointe sur les serveurs de Canonical à Londres, quel que soit l'emplacement du client dans le monde.
Ces deux connexions, font quelques Ko après l'échange de clé https.
Enfin le téléchargement de 120 Mo est effectué depuis le CDN Internap, toujours en https.
Pour ma part c'est 068ed04f23.site.internapcdn.net qui a été utilisé (cela pointe vers 77.242.195.173, hébergé lui aussi à Londres)
Bref, l’infrastructure de distribution des .deb d'Ubuntu n'est pas utilisée (ce sont 405 serveurs a travers le monde proposant une bande passante cumulée de 859 Gb/s)
-
Effet waoou.
Seulement 120 Mo, je pensais que ce serait 10 fois plus!
-
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 (https://hub.docker.com/_/httpd/) 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
-
kgersen, tu peux me redire quel est l'intérêt ?
Avec, si possible, des cas typiques, avec et sans, histoire de bien mettre en lumière le gain apporté (et plus globalement, les différences)
Par exemple, quel intérêt de ne pas avoir ls ?
-
Je vois que je ne suis pas le seul à ne rien comprendre à ce concept!
-
Spawner des centaines voir des milliers d'instances d'une application ?
-
C'est déjà tout à fait faisable (et fait), que je sache
Et surtout, je ne vois pas en quoi retirer ls va "aider"
-
Pourquoi tu mettrais ls et tout /bin ou plein de truc s'ils ne servent jamais ? ls (et /bin plus généralement) impliquent que t'as un shell ou un moyen de les lancer (ou via l'application en appelant execve(2)).
T'as jamais vu de faille de secu ou d'exploit en vrai pour demander en quoi retirer ls va "aider" ? faille dans application ou lib d'OS -> un intrus qui entre peut utiliser les binaires existants (dont ls, rm, etc) pour 'faire' des choses. si y'a pas de binaires autre que l'application -> l'intrus est plus limité dans ces actions (il doit télécharger ou refaire lui même ces commandes via des syscall, mais s'il n'y a plus de kernel y'a donc plus de syscall...ou si y'en a ils sont dans l'app et que ceux qu'elle utilise donc moins de surface d'action. Par exemple pour implèmenter un 'rm' il faut le syscall 'unlink' ou 'unlinkat' et passer le bon descripteur, avoir le driver du fs, etc).
Donc quel intérêt de laisser plein de binaires ("ls -1 /bin /sbin | wc -l" sur Ubuntu de base y'a plus de 300 binaires) ?
Apres le but 1er n'est pas de retirer 'ls' ou autre , ca c'est juste une conséquence bénéfique.
Autre facon de voir les choses: on parle de faire tourner des applications et rien qu'elles dans un contexte minimal ou la présence d'un OS et kernel complet n'apporte rien de plus a ces applications. Dans ce cas quel intérêt de garder l'OS et le kernel complet ?
Ou autre facon: quel intérêt d'avoir 'ls' si y'a pas de système de fichier présent ?
Il ne faut pas raisonner par rapport a une perception 'sysadmin' des choses : dans ce contexte d'unikernels, y'a plus besoin d'un sysadmin donc plus besoin de ses outils (ls et /bin plus généralement, etc) du moins au niveau qu'on les connait actuellement (userland sur kernel).
Si sysadmin il y a encore, il s'occupera de l'hyperviseur et utilisera les outils propres a l'hyperviseur s'il a besoin de faire un ls (pour voir les "exe" qu'il peut lancer par exemple). Le sysadmin n'a pas acces et ne doit pas avoir accès a l’intérieur de ces "exe" (exe au sens unikernel donc application + unikernel). Tout comme un sysadmin ne va pas mettre son nez dans un binaire elf.
-
J'ai rien compris...
-
kgersen, tes idées rejoignent beaucoup ce que fait Lennart Poettering avec CoreOS.
-
Quel est le risque d'avoir ls s'il n'y a pas de fs présent?
-
Je ne suis pas bien certain de bien comprendre non plus.
Le propos c'est d'avoir des instances de containers dans docker qui tourne dans une VM,d'avoir un "mini busybox" avec une seule application dessus ?
-
Quels attributs?
Mais ceux que tu voulais préserver en utilisant l'option -a de la commande cp, pardi !
Comment les préserver?
Si tu veux conserver tous ses attributs, tar, cpio ou rsync sont appropriés, mais cp ne l'est pas.
. (avec les options qui vont bien, ça va de soi)
Comment proposes-tu d'utiliser cet attribut, concrètement?
Chez un précédent client, il est utilisé pour déplacer les données peu accédées sur des unités de stockage "lentes", voire de les archiver sur bandes, afin de réduire le coût de conservation de ces données sur le long terme.
Chez mon client actuel, il est utilisé par les gestionnaires d'une arborescence tampon afin d'y faire du ménage.
Tu n'as pas idée du nombre d'entreprises qui utilisent des données en mode WORM et pour lesquelles l'information utile n'est pas de savoir quand le fichier a été modifié pour la dernière fois (puisqu'il est créé sans plus jamais être modifié par la suite), mais quand il a été effectivement utilisé pour la dernière fois.
C'est pas le C spécifiquement que tu ignores, c'est la sémantique Unix, la programmation et l'informatique en général.
Vue ton ignorance sur l'utilité de l'attribut atime, je te retourne le compliment.
-
C'est déjà tout à fait faisable (et fait), que je sache
En VM ? Non car il faut gérer la configuration de l'OS individuellement.
En container, t'as pas ce problème. Tu déploye une appli, point. En X fois, sans t'occuper de savoir où est-ce que ça tourne.
Tout Google fonctionne sur ce principe.
-
Autre facon de voir les choses: on parle de faire tourner des applications et rien qu'elles dans un contexte minimal ou la présence d'un OS et kernel complet n'apporte rien de plus a ces applications. Dans ce cas quel intérêt de garder l'OS et le kernel complet ?
Énorme intérêt : ne pas se taper une stack réseau dans mon serveur web.
-
Énorme intérêt : ne pas se taper une stack réseau dans mon serveur web.
sauf qu'en pratique on voudrait avec la stack réseau dans le code du serveur web pour pouvoir l'optimiser ou la faire évoluer plus rapidement ce que la stack de l'OS ne permet pas.
exemple typique c'est QUIC (https://www.chromium.org/quic): TCP est figé et lent a évolué, si on veut des changements ou faire différent il faut changer TCP coté client et coté serveur dans tout les OS -> c'est quasi impossible. Les seuls changements qui arrivent vraiment partout sont les patchs de sécurité et encore pas toujours. solution de Google avec QUIC: ils ont "refait" eux-memes un sorte de TCP dans les applications (le serveur web d'un coté et Chrome de l'autre) au dessus d'UDP (qui lui reste celui de la stack de l'OS).
C'est ca aussi un gros des avantages des unikernels: on peut faire des changements et des évolution de technos sans dépendre qu'elles soient disponibles au niveau des OS ou des kernels, qui par nature ont une grosse inertie a changer.
On réduit donc la friction au changement due aux kernels et OS.
-
sauf qu'en pratique on voudrait avec la stack réseau dans le code du serveur web pour pouvoir l'optimiser ou la faire évoluer plus rapidement ce que la stack de l'OS ne permet pas.
Oula oula, arrête ton char, c'est tout à fait possible (et encore une fois, c'est fait)
exemple typique c'est QUIC (https://www.chromium.org/quic): TCP est figé et lent a évolué, si on veut des changements ou faire différent il faut changer TCP coté client et coté serveur dans tout les OS -> c'est quasi impossible. Les seuls changements qui arrivent vraiment partout sont les patchs de sécurité et encore pas toujours. solution de Google avec QUIC: ils ont "refait" eux-memes un sorte de TCP dans les applications (le serveur web d'un coté et Chrome de l'autre) au dessus d'UDP (qui lui reste celui de la stack de l'OS).
Tu me parles:
- du windows xp de bobonne; C'est de la merde, ce sera toujours de la merde, et c'est hors sujet
- du "dans tout les OS"; Genre ta boite utilise "tout les OS" ? Et pas seulement une minorité (voir seulement un seul), avec dans tout les cas un seul kernel ?
C'est ca aussi un gros des avantages des unikernels: on peut faire des changements et des évolution de technos sans dépendre qu'elles soient disponibles au niveau des OS ou des kernels, qui par nature ont une grosse inertie a changer.
Ouais, désolé mais la solution du "le monde est naze, j'vais faire mieux", sur la durée, c'est rarement fonctionnel
-
Ca sera bien avec l'IPv6 (Une IP par application), mais avec IPv4, il faut faire du NAT pour que plusieurs applications partagent la même IP.
-
Oula oula, arrête ton char, c'est tout à fait possible (et encore une fois, c'est fait)
Tu me parles:
- du windows xp de bobonne; C'est de la merde, ce sera toujours de la merde, et c'est hors sujet
- du "dans tout les OS"; Genre ta boite utilise "tout les OS" ? Et pas seulement une minorité (voir seulement un seul), avec dans tout les cas un seul kernel ?
Ouais, désolé mais la solution du "le monde est naze, j'vais faire mieux", sur la durée, c'est rarement fonctionnel
personne a dit le monde est naze on va faire mieux. Je ne comprend pas ton 'braquage' et ton négativisme. Tu juges des projets et technos qui sont a l’état de R&D / prototypes sans essayer de voir plus loin. Ca me rappelle les types qui crachaient sur VMware et autres solutions de virtualisation quand elle étaient encore confidentielles. C'est de la défensive sans ouverture d'esprit. On a vu le résultat.
Y'a pas d'universalité de toute façon. Prétendre que les OS et kernels actuels sont la seule façon valable de faire les choses c'est aussi débile que prétendre que les unikernels seront LA seule solution d'avenir ce que personne n'a prétendu ici. Pour beaucoup de gens qui sont confrontés pour de vrai (et pas en théorie) a des problématiques d' hyperscaling les OS et kernels actuels ne conviennent pas. Tout comme mettre Ubuntu dans un smartphone ou un core router ne convient pas non plus.
Moi je crois a cette voie et cette évolution car elle semble 'logique' et découle naturellement l'évolution introduite par la virtualisation:
barebone -A-> virtualisation -B-> containers -C-> unikernels
Aujourd'hui on est a peine a B avec une grosse partie (>90%) des gens qui ne font pas encore de containers. Ca ne doit pas pour autant empêcher de réfléchir et expérimenter C.
Il ne faut pas oublier que tout cela se place dans le contexte global de l'évolution de l'informatique. De la (re)centralisation due aux datacenters, de la limite récemment atteinte en terme de puissance CPU (par core du moins), etc. Il faut prendre en compte tout ces facteurs et l'impact qu'ils ont sur l’architecture des logiciels qui a leur tour ont un impact sur l'évolution de l'architecture des OS et kernels et du matériel en dessous.
-
Ces technos/archis sont en train d'envahir des domaines insoupçonnés ;)
-
Ca sera bien avec l'IPv6 (Une IP par application), mais avec IPv4, il faut faire du NAT pour que plusieurs applications partagent la même IP.
Tu peux NATer en bordure du réseau. Rien n'oblige de faire du NAT sur le serveur lui meme.
-
Oula oula, pédale douce !
J'en suis resté à ça :
De toute facon Linux (et tout les autres OS) c'est *bientot* du passé.
Et au fait que "unikernels" et "container", ça m'apparait comme, techniquement, identique (ou "très proche", si tu veux)
Hors, les containers, ce n'est pas un rêve éloigné de chercheurs fantaisistes, c'est une réalité, chez moi par exemple
Et, en me basant sur cette expérience, non merci
Je veux bien croire que ça marche dans certaines sociétés comme google, chez qui la notion de qualité arrive peut-être à descendre sur tout les niveaux
Chez moi, et comme, il faut l'avouer, chez la plupart des gens, le dev chit, et n'essuie pas.
Je constate;
-
Et, en me basant sur cette expérience, non merci
C'est quoi ton souci d'expérience avec les containers ? souvent les changements/évolutions techniques coincent parce qu'ils sont imposés et subis et pas accompagnés de changements au niveau humain (orga, RH, etc).
-
C'est quoi ton souci d'expérience avec les containers ? souvent les changements/évolutions techniques coincent parce qu'ils sont imposés et subis et pas accompagnés de changements au niveau humain (orga, RH, etc).
Container = évolution géré par le dev = pas d'évolution autre que le code métier = software troué :)
-
Container = évolution géré par le dev = pas d'évolution autre que le code métier = software troué :)
T'as eu le cas pratique ? car "software troué" c'est peu facile de sortir ca.
Le truc c'est de bien placé la limite de responsabilité/zone d'intervention.
Y'a des images de containers maintenus et d'autres non, c'est la meme chose avec les packages (apt, yum,etc) . la problématique est la meme et pas spécifique au containers.
Y'a aussi plusieurs facon de gerer les images des containers. Soit tu laisses le dev tout faire , soit tu exiges un Dockerfile et build toi meme.
A mon avis c'est plus un probleme de process/répartition des responsabilités qu'un probleme intrinsèque a la techno. Bref c'est un probleme humain et organisationnel.
-
T'as eu le cas pratique ? car "software troué" c'est peu facile de sortir ca.
Je te parle toujours d'expérience hein !
-
Pour ceux qui n'y connaissent pas grand chose (dont moi), peut-on résumer le sujet ainsi?
On peut se passer de l'OS uniquement dans certains cas très particuliers d'applications tournant sur des serveurs.
Mais on ne pourra pas se passer d'OS pour les "clients" (PC, smartphones, tablettes), ni sur tous les serveurs.
Leon.
-
Pour ceux qui n'y connaissent pas grand chose (dont moi), peut-on résumer le sujet ainsi?
On peut se passer de l'OS uniquement dans certains cas très particuliers d'applications tournant sur des serveurs.
Mais on ne pourra pas se passer d'OS pour les "clients" (PC, smartphones, tablettes), ni sur tous les serveurs.
C'est ce qu'avance kgersen, si j'ai bien compris
C'est, pour moi, faux, considérant que :
- OS = kernel + userspace
- hardware sans kernel = un seul processus executable
- kernel sans userspace = il est possible d'executer plusieurs processus en même temps, mais il n'y a aucun processus à executer
En conséquence, et bien qu'il soit possible, en théorie, de ne pas avoir "d'OS" sur une machine, en pratique, c'est absurde, contreproductif, délétère, et donc jamais réalisé
-
C'est ce qu'avance kgersen, si j'ai bien compris
C'est, pour moi, faux, considérant que :
- OS = kernel + userspace
- hardware sans kernel = un seul processus executable
- kernel sans userspace = il est possible d'executer plusieurs processus en même temps, mais il n'y a aucun processus à executer
En conséquence, et bien qu'il soit possible, en théorie, de ne pas avoir "d'OS" sur une machine, en pratique, c'est absurde, contreproductif, délétère, et donc jamais réalisé
OK, ce que je comprends surtout, c'est vous êtes tous les 2 bornés, et que vous n'avez simplement pas la même définition de ce qu'est un "OS".
Donc vous avez tous les 2 raison.
Leon.
-
OK, ce que je comprends surtout, c'est vous êtes tous les 2 bornés, et que vous n'avez simplement pas la même définition de ce qu'est un "OS".
Donc vous avez tous les 2 raison.
Leon.
?!?
Ma définition est celle de wikipedia, j'ignorai qu'il y en avait une autre:
An operating system (OS) is system software that manages computer hardware and software resources and provides common services for computer programs. All computer programs, excluding firmware, require an operating system to function.
-
C'est ce qu'avance kgersen, si j'ai bien compris
C'est, pour moi, faux, considérant que :
- OS = kernel + userspace
- hardware sans kernel = un seul processus executable
- kernel sans userspace = il est possible d'executer plusieurs processus en même temps, mais il n'y a aucun processus à executer
En conséquence, et bien qu'il soit possible, en théorie, de ne pas avoir "d'OS" sur une machine, en pratique, c'est absurde, contreproductif, délétère, et donc jamais réalisé
tu confond machine physique et machine virtuelle la. On parle de machines virtuelles tournant au dessus d'un hyperviseur.
L'important c'est comment une app ou des apps utilisent les ressources du hardware (mémoire, réseau, disque, etc). Soit t'as un kernel+os directement au dessus du hardware et celui permet le partage des ressources. soit tu rajoute en dessous une couche avec un hyperviseur.
Quand t'as un hyperviseur qui permet le partage des ces ressources entre plusieurs kernels (et OS au dessus de chaque kernel) on peut 'réduire au strict minimum' le kernel (et l'OS) voir les supprimer: l'application s'interface directement sur l'hyperviseur.
Exemple:
kernel = linux
os = ubuntu
app = ping
si je fais une VM qui ne fait que ca (que ping), on est bien d'accord que j'ai un "kernel+os+ping" complet juste pour faire un ping.
Maintenant si je pars du source de ping, je regarde ce que ca utilise au niveau os (fonctions de niveau (3)) et au niveau kernel (niveau (2) syscalls + drivers des ressources utilisées) et je simplifie tout ca en l'intégrant directement dans une seul "binaire executable" appelé "uni-ping". Ce binaire est l'équivalent d'une VM ,c'est comme une image de VM mais ca ne fait que 'ping' et rien d'autre. y'a donc plus vraiment de kernel et d'OS dedans et ca tourne directement sur mon hyperviseur. C'est de ca dont on parle depuis le début.
Bref vu autrement une VM qui fait touner un kernel+un OS peut faire tourner n'importe quoi d'autre. Il faut pas se restreindre qu'aux kernel+OS classiques.
ps: ca serait bien de séparer la discussion sur atime du sujet principal d'ici.
-
tu confond machine physique et machine virtuelle la. On parle de machines virtuelles tournant au dessus d'un hyperviseur.
L'important c'est comment une app ou des apps utilisent les ressources du hardware (mémoire, réseau, disque, etc). Soit t'as un kernel+os directement au dessus du hardware et celui permet le partage des ressources. soit tu rajoute en dessous une couche avec un hyperviseur.
Quand t'as un hyperviseur qui permet le partage des ces ressources entre plusieurs kernels (et OS au dessus de chaque kernel) on peut 'réduire au strict minimum' le kernel (et l'OS) voir les supprimer: l'application s'interface directement sur l'hyperviseur.
Exemple:
kernel = linux
os = ubuntu
app = ping
si je fais une VM qui ne fait que ca (que ping), on est bien d'accord que j'ai un "kernel+os+ping" complet juste pour faire un ping.
Maintenant si je pars du source de ping, je regarde ce que ca utilise au niveau os (fonctions de niveau (3)) et au niveau kernel (niveau (2) syscalls + drivers des ressources utilisées) et je simplifie tout ca en l'intégrant directement dans une seul "binaire executable" appelé "uni-ping". Ce binaire est l'équivalent d'une VM ,c'est comme une image de VM mais ca ne fait que 'ping' et rien d'autre. y'a donc plus vraiment de kernel et d'OS dedans et ca tourne directement sur mon hyperviseur. C'est de ca dont on parle depuis le début.
Bref vu autrement une VM qui fait touner un kernel+un OS peut faire tourner n'importe quoi d'autre. Il faut pas se restreindre qu'aux kernel+OS classiques.
ps: ca serait bien de séparer la discussion sur atime du sujet principal d'ici.
C'est très clair, merci pour les précisions et les exemples, en particulier quant à la "frontière" du concept
-
T'as jamais vu de faille de secu ou d'exploit en vrai pour demander en quoi retirer ls va "aider" ? faille dans application ou lib d'OS -> un intrus qui entre peut utiliser les binaires existants (dont ls, rm, etc) pour 'faire' des choses. si y'a pas de binaires autre que l'application -> l'intrus est plus limité dans ces actions (il doit télécharger ou refaire lui même ces commandes via des syscall, mais s'il n'y a plus de kernel y'a donc plus de syscall...ou si y'en a ils sont dans l'app et que ceux qu'elle utilise donc moins de surface d'action.
S'il n'y a plus de syscall, comment marchent les applications?
Ce que tu racontes est très mystérieux.
-
Mais ceux que tu voulais préserver en utilisant l'option -a de la commande cp, pardi !
Je veux préserver les caractéristiques intrinsèques qui affectent l'interprétation du fichier. Par exemple, la permission EXECUTE rend un fichier exécutable (si il a le bon format), donc ça affecte son comportement. Les autres permissions, les propriétaires, etc. détermine qui peut faire quelle opération, donc c'est important de les préserver.
L'attribut atime n'est utile que si quelqu'un a la curieuse idée de l'utiliser, ce qui est très rarement le cas. C'est une méta-information sans aucun intérêt dans 97 % des cas (mais qui peut, parfois, être utile).
De toute façon, tu ne peux pas créer une copie identique d'une arborescence ou même d'un seul fichier, tel que TOUS les attributs Unix soient identiques!
-
Désolé pour le déterrage.
Je ne comprend pas bien le concept exposé.
J'ai l'impression de voir la même chose que quand j'installe une appliance packagée par un éditeur dans VMWare, avec comme nouveauté le but de légèreté et donc juste ne plus se contenter d'avoir une SUSE complète mais verrouillée comme je rencontre actuellement.
Du coup ca semble surtout un changement de packaging.
Enfin je vois les mêmes avantages / inconvénients que les "appliances", le fait de juste m'occuper de l'hyperviseur sans avoir à construire moi-même la VM hébergeant l'appli (et donc avoir un bloc certifié par l'éditeur), donc en théorie moins de souci appli car moins de diversité à gérer côté éditeur.
En contrepartie, je suis limité / bloqué sur ce que je peux diagnostiquer de l'appli puisque l'accès est verrouillé.
De manière générale, je ne peux utiliser que les services / fonctionnalités prévues par le fournisseur (du coup, pas d'utilitaire pour voir ce que l'appli fait en terme de disque, RAM,...) et je suis dépendant de ses choix (par exemple de son absence de support d'un hyperviseur plus vieux que X mois, d'autoriser des comptes lignes de commandes limités, pas de séparation des interfaces réseaux admin/service/NAS...).
-
Désolé pour le déterrage.
Tu appelles ça un déterrage, après même pas 6 mois?
Non mais tu plaisantes!
Je ne comprend pas bien le concept exposé.
Donc je ne suis pas seul!
-
Désolé pour le déterrage.
Je ne comprend pas bien le concept exposé.
J'ai l'impression de voir la même chose que quand j'installe une appliance packagée par un éditeur dans VMWare, avec comme nouveauté le but de légèreté et donc juste ne plus se contenter d'avoir une SUSE complète mais verrouillée comme je rencontre actuellement.
Du coup ca semble surtout un changement de packaging.
Enfin je vois les mêmes avantages / inconvénients que les "appliances", le fait de juste m'occuper de l'hyperviseur sans avoir à construire moi-même la VM hébergeant l'appli (et donc avoir un bloc certifié par l'éditeur), donc en théorie moins de souci appli car moins de diversité à gérer côté éditeur.
En contrepartie, je suis limité / bloqué sur ce que je peux diagnostiquer de l'appli puisque l'accès est verrouillé.
De manière générale, je ne peux utiliser que les services / fonctionnalités prévues par le fournisseur (du coup, pas d'utilitaire pour voir ce que l'appli fait en terme de disque, RAM,...) et je suis dépendant de ses choix (par exemple de son absence de support d'un hyperviseur plus vieux que X mois, d'autoriser des comptes lignes de commandes limités, pas de séparation des interfaces réseaux admin/service/NAS...).
tu m'a plutôt l'air d'avoir compris le concept ... tu vois juste les inconvénients sans voir les avantages.
Vu de l’extérieur (de l'hyperviseur) oui c'est juste un changement de packaging.
Vu de l’intérieur c'est très différent, l'OS n'est plus la c'est juste une bibliothèque (library OS).
Pour ceux qui connaissent le C/C++ voici une bonne intro: https://www.youtube.com/watch?v=t4etEwG2_LY
Ca parle de http://www.includeos.org/. En gros on commence son programme par "#include <os>" et le binaire produit tourne directement sans OS (il inclut un bootloader donc pour pouvoir démarrer sur une machine physique (plutot IoT) ou virtuelle).
Il ne faut pas non plus raisonner avec les architectures applicatives passées , grosses et souvent monolitiques.
On parle de micro-services la, avec des nuées d'instances.
Quand t'as 1000 ou plus instances d'une meme app si tu peux dégager 1000 fois l'OS et tout ce qui ne sert pas, le gain est énorme. Pouvoir faire un acces ssh sur chacun des 1000 instances ne sert a rien non plus...(et la sécurité, upgrade, etc)
Apres c'est l'éternel débat d'ou on met la 'frontière' d'intervention. Certains sysadmins ne supportent pas de devoir faire tourner des 'boites noires' sans pouvoir aller jeter un oeil dedans. Certains devs ne supportent pas que les sysadmins bidouillent dans leur apps. Il est vrai que quelque part certains métiers vont se simplifier...voir disparaitre.
Pour le support d'hypersiveur, tout va dépendre de la rétrocompatibilité qu'offrira celui-ci. On a le même souci avec une VM entre l'app et l'OS ou des libs.
J'ai pas bien compris "pas de séparation des interfaces réseaux admin/service/NAS".
Encore une fois c'est un domaine récent et en plein évolution. Tout n'est pas figé et il y a plusieurs façon de faire les choses. Comme au début des VM par exemple. Ce qui marche et est efficace va l'emporter et sans doute 'descendre' au niveau hardware comme ce fut le cas avec les VM (cf tout ce qu'Intel et d'autres ont fait pour améliorer le fonctionnement de la virtualisation en terme de cpu, io, mem, etc).
Il faudra aussi que les mentalités s'adaptent comme ce fut le cas avec les VMs.
-
tu m'a plutôt l'air d'avoir compris le concept ... tu vois juste les inconvénients sans voir les avantages.
(...)
On parle de micro-services la, avec des nuées d'instances.
(...)
Apres c'est l'éternel débat d’où on met la 'frontière' d'intervention. Certains sysadmins ne supportent pas de devoir faire tourner des 'boites noires' sans pouvoir aller jeter un oeil dedans. Certains devs ne supportent pas que les sysadmins bidouillent dans leur apps. Il est vrai que quelque part certains métiers vont se simplifier...voir disparaitre.
(...)
J'ai pas bien compris "pas de séparation des interfaces réseaux admin/service/NAS".
(...)
Je suis probablement plus dans les inconvénients du fait de ce que je vois au boulot.
Je m'ocuppe d'OS et de stockage sur des environnements virtualisés pour des appli de compta à base d'ERP.
Il m'arrive d'avoir à aller sur les machines pour voir comment se comporte l'appli dessus ou l'OS en terme de performance principalement notamment pour ce qu'ils demandent aux couche dessou (sur des VM à OS AIX et Linux).
Par ailleurs, nous avons un ordonnanceur externe pour les traitements applicatifs et une partie des traitements techniques (par exemple j'arrête les tomcat d'une appli puis je lance le recalcul des stats de la DB associée puis démarrage des tomcat dans le bon ordre le tout réparti sur une 20aines de serveurs, ok, l'exemple est un peu bateau).
Je me suis donc principalement intéressé à l'impact sur mon quotidien sachant que quasi tout les avantages / inconvénients pour un DEV ne me concernent pas (et pas de souci là dessus, chacun son métier).
Vu que je vais recevoir un "tout en un", il va falloir que les spec de DEV incluent d'autres fonctions que juste le mini-service afin d’intégrer celui-ci dans un environnement ou le monitoring de l'appli/"OS".
De plus, un partie des problématiques de perf repérée ce jour par les sysadmin devra être vue par l'éditeur et pour l'instant, je ne leur fait pas confiance pour dépenser plus de budget pour faire un bon produit en terme d'utilisation technique.
Avec le modèle proposé, je n'aurait plus aucun argument pour contrer un support.
C'est un point de vue sur la généralisation de ce mode de déploiement, l'idée technique est bien sur elle est correctement réalisée, mais j'ai des doutes sur la mise en œuvre.
Pour la séparation des interfaces réseaux admin/service/NAS.
Chez nous, les VM on 3 interfaces virtuelles :
- une qui va vers le NAS sans traverser de firewall et qui sert aussi pour les backup IP en direct sur l'équipement de backup.
- une qui sert à venir dessus en tant qu'administrateur (par exemeple en SSH)
- une pour le service applicatif
Ca permet de bien s'y retrouver, gérer plus facilement les firewall (notamment d'avoir des FW périphériques différents) et les routes réseau et le diagnostique
Sur les appliance que je vois, il n'y a en général qu'une interface virtuelle avec une seule IP qui ne supporte qu'une donc passerelle et pas toujours la possibilité de rajouter des routes ce qui complique un peu le management.
Encore une fois, ca n'est pas une limite inhérente à la techno choisie mais des choix de mise en oeuvre au plus simple / moins couteux constatés.
-
Cela a l'air pas mal :)
------------------------------------------------------------
Starting VM: 'Demo_Service.img'
------------------------------------------------------------
qemu-system-i386 -drive file=Demo_Service.img,format=raw,if=ide -device virtio-net,netdev=net0,mac=c0:01:0a:00:00:2a -netdev tap,id=net0,script=/root/IncludeOS_install/etc/qemu-ifup -nographic -smp 4 -m 128 -k en-us
================================================================================
#include<os> // Literally
================================================================================
[ Kernel ] Stack: 0x9fb6c
[ Kernel ] Boot args: 0xa58 (multiboot magic), 0x746 (bootinfo addr)
[ Kernel ] Max mem (from linker): 128 MiB
* Low memory: 640 Kib
* High memory (from linker): 131072 Kib
[ Kernel ] Assigning fixed memory ranges (Memory map)
* Unavailable memory: 0x8100000 - 0x880ffffe
* Last chunk of memory: 0x880fffff - 0xffffffff
[ Kernel ] Printing memory map
* Statman 8000 - 9fff (Statistics, 8192 / 8192 bytes used)
* Kernel / service main stack a000 - 9fbff (N/A, 613376 / 613376 bytes used)
* EBDA 9fc00 - 9ffff (Extended BIOS data area, 1024 / 1024 bytes used)
* VGA/ROM a0000 - fffff (Memory mapped video memory, 393216 / 393216 bytes used)
* ELF 100000 - 20e508 (Your service binary including OS, 1107209 / 1107209 bytes used)
* Pre-heap 20e509 - 26cfff (Heap randomization area (not for use)), 387831 / 387831 bytes used)
* Heap 26d000 - 80fffff (Dynamic memory, 282624 / 132722688 bytes used)
* N/A 8100000 - 880ffffe (Reserved / outside physical range, 2147483647 / 2147483647 bytes used)
* N/A 880fffff - ffffffff (Reserved / outside physical range, 2012217345 / 2012217345 bytes used)
[ INTR ] Creating interrupt handlers
+ Default interrupt gates set for irq >= 32
[ ACPI ] Reading headers
OEM: BOCHS Rev. 0
[ ACPI ] Reading APIC information
LAPIC base: 0xfee00000 (flags: 0x1)
-> CPU 0 ID 0 (flags=0x1)
-> CPU 1 ID 1 (flags=0x1)
-> CPU 2 ID 2 (flags=0x1)
-> CPU 3 ID 3 (flags=0x1)
I/O APIC 0 ADDR 0xfec00000 INTR 0x0
IRQ redirect for bus 0 from IRQ 0 to VEC 2
IRQ redirect for bus 0 from IRQ 5 to VEC 5
IRQ redirect for bus 0 from IRQ 9 to VEC 9
IRQ redirect for bus 0 from IRQ 10 to VEC 10
IRQ redirect for bus 0 from IRQ 11 to VEC 11
LAPIC id: 0 ver: 50014
[ APIC ] Enabling BSP LAPIC
APIC_BASE MSR is now 0xfee00900
[ IOAPIC ] Initializing
Base addr: 0xfec00000 Redirection entries: 24
[ IOAPIC ] Done
[ APIC ] SMP Init
[ APIC ] Initializing APs
[ APIC ] Starting APs
AP 1 started at 0x2b4000
AP 2 started at 0x2b6000
AP 3 started at 0x2b8000
[ APIC ] All APs are online now
[ BSP ] Enabling interrupts
Enabled redirected IRQ 0 -> 2 on lapic 0
[ PCI Manager ] Probing PCI bus
|
+--+ Host Bridge (0x0)
|
+--+ ISA Bridge (0x1)
|
+--+ Mass Storage Controller
| +--+ Driver: Not found
|
+--+ Other Bridge (0x80)
|
+--+ Display Controller
|
+--+ Ethernet Network Controller (0x0)
| +--+ Driver: Found
[ Virtio ] Attaching to PCI addr 0x18
[x] Vendor ID is VIRTIO
[x] Device ID 0x1000 is in a valid range (Virtio LEGACY)
[x] Device Revision ID (0x0) supported
[ Resource @ BAR 0 ]
Address: 0xc000 Size: 0x20
Type: IO Resource
[ Resource @ BAR 1 ]
Address: 0xfebd1000 Size: 0x1000
Type: Memory Resource
[x] Unit has valid I/O base (0xc000)
[*] Reset device
[x] Device has 3 MSI-X vectors
MSI-X vector 0 pointing to cpu 0 intr 96
MSI-X vector 1 pointing to cpu 0 intr 97
MSI-X vector 2 pointing to cpu 0 intr 98
[ Virtio ] Initialization complete
[ VirtioNet ] Driver initializing
[x] Negotiated needed features
[x] Negotiated wanted features
[x] Device handles packets w. partial checksum
[x] Guest handles packets w. partial checksum
[x] There's a control queue
[x] Queue can handle any header/data layout
[x] We can use indirect descriptors
[x] There's a Ring Event Index to use
[ ] There are multiple queue pairs
[x] Merge RX buffers
[x] RX queue assigned (0x5c5000) to device
[x] TX queue assigned (0x5c9000) to device
[x] CTRL queue assigned (0x5cd000) to device
[ VirtioNet ] Adding 128 receive buffers of size 1546
[x] Valid Mac address: c0:01:0a:00:00:2a
[x] Signalled driver OK
[ VirtioNet ] Driver initialization complete
[x] Link up
|
o
[ Devices ] Listing registered devices
|
+--+ NIC
| + #0: VirtioNet Driver
|
o
[ Kernel ] Estimating CPU-frequency
|
+--(10 samples, 0.000100 sec. interval)
|
+--> 2289.853328 MHz
[ APIC ] Measuring APIC timer...
Enabled redirected IRQ 0 -> 2 on lapic 0
[ CMOS ] Setting 24 hour format UTC
[ Kernel ] Calling custom initialization functions
[ Kernel ] Starting IncludeOS Demo Service
================================================================================
[ Inet4 ] Bringing up a IPv4 stack
[ Inet4 ] Negotiating DHCP...
[ DHCPv4 ] Negotiating IP-address (xid=2316641875)
[ Inet4 ] Network configured
IP: 10.0.0.42
Netmask: 255.255.255.0
Gateway: 10.0.0.1
DNS Server: 10.0.0.1
*** TEST SERVICE STARTED ***
================================================================================
IncludeOS v0.9.3-10-g65ffb9c
+--> Running [ IncludeOS Demo Service ]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
Pour la séparation des interfaces réseaux admin/service/NAS.
Chez nous, les VM on 3 interfaces virtuelles :
- une qui va vers le NAS sans traverser de firewall et qui sert aussi pour les backup IP en direct sur l'équipement de backup.
- une qui sert à venir dessus en tant qu'administrateur (par exemeple en SSH)
- une pour le service applicatif
Ca permet de bien s'y retrouver, gérer plus facilement les firewall (notamment d'avoir des FW périphériques différents) et les routes réseau et le diagnostique
Ayant pratiqué cette segmentation je plussoie sur les avantages de configuration des règles de firewall quand on a plusieurs interfaces réseaux distinctes en terme d'utilisation. N'avoir qu'une seule adresse IP/Vlan est vraiment pénible surtout quand un auditeur sécurité demande à avoir un aperçu sur les flux autorisés.
-
Vous avez pensé à la maintenance ?
Si chaque "vm" embarque ses piles logicielles de base qu'on sort donc d'un OS commun, imaginez le chemin de croix pour patcher une faille de sécurité commune, avec les centaines d'éditeurs qui vont devoir produire leur patch !
C'est déjà pénible avec X OS différents, mais alors si on passe à Y applis avec Y=100*X...
-
Vous avez pensé à la maintenance ?
Si chaque "vm" embarque ses piles logicielles de base qu'on sort donc d'un OS commun, imaginez le chemin de croix pour patcher une faille de sécurité commune, avec les centaines d'éditeurs qui vont devoir produire leur patch !
C'est déjà pénible avec X OS différents, mais alors si on passe à Y applis avec Y=100*X...
on est en 2016... il ne s'agit pas d'aller 'a la main' accéder a chaque 'vm ou 'image' pour patcher, mettre a jour ou administrer.
En production, tout ce passe au sein d'un système qui s'auto-heal, s'auto-corrige et ou tout ses aspects de maintenance sont pris en compte des le départ via l'utilisation d'un orchestrateur.
Au cours des derniers années il y a eu de gros travaux et avancées sur ces outils d'automation, orchestration et de gestion de clusters ou d'essaims (swarm).
cf Docker Swarm, Apache Mesos, Kubernetes, etc
-
kgersen a une vue "google" de la situation;
-
on est en 2016... il ne s'agit pas d'aller 'a la main' accéder a chaque 'vm ou 'image' pour patcher, mettre a jour ou administrer.
Tu n'as pas bien compris le sens de ma remarque : tu confonds nombre de VM et nombre d'éditeurs.
Si chaque éditeur d'applis embarque sa propre libC, son propre bash, etc, bref ses propres fonctions de bases autrefois communes aux OS classiques, tu vas multiplier les sources de fournisseurs logiciels, et tu vas pleurer pour maintenir ça, avec ou sans orchestration.
Et ce, que tu ais 200 ou 10000 VM...
-
Tu n'as pas bien compris le sens de ma remarque : tu confonds nombre de VM et nombre d'éditeurs.
Si chaque éditeur d'applis embarque sa propre libC, son propre bash, etc, bref ses propres fonctions de bases autrefois communes aux OS classiques, tu vas multiplier les sources de fournisseurs logiciels, et tu vas pleurer pour maintenir ça, avec ou sans orchestration.
Et ce, que tu ais 200 ou 10000 VM...
en quoi c'est différent de maintenant ? Soit l'éditeur fourni un binaire soit il fournit un source. Dans le 1er cas c'est a lui de fournir une nouvelle version, dans l'autre tu recompile/rebuild avec la libC ou le "libOS" a jour.
Je ne comprend pas bien pas la 'complexité' que tu vois en terme de maintenance.
-
L'avis de Bryan Cantrill pourrait bien refroidir l'enthousiasme de quelques-uns:
http://www.theregister.co.uk/2016/01/27/unikernels_dos_era/ (http://www.theregister.co.uk/2016/01/27/unikernels_dos_era/)
https://www.joyent.com/blog/unikernels-are-unfit-for-production (https://www.joyent.com/blog/unikernels-are-unfit-for-production)
Unikernels are entirely undebuggable.
From a debugging perspective, to say this is primitive understates it: this isn’t paleolithic — it is precambrian.
-
C'est son avis. Chacun le sien. Apres il défend son domaine...