blog.bressure.net

Le cloud est à la mode et son adoptions par les géants du web semble prouver qu’il est bien plus qu’une passade. Au sens strict une plateforme ou un service dans le cloud se definissent comme des ressources dont la localisation est secondaire. La conteneurisation prend ici tout son intérêt et pas seulement pour le GAFA. Le particulier qui héberge lui-même ses services trouve aussi un avantage à passer aux conteneurs.

Historique

Internet n’était pas à l’origine un concept centralisé. Loin s’en faut. Tout noeud du réseau, toute machine peut-être un serveur, tout devrait être au même niveau, tout devrait être en pair-à-pair. Grâce au logiciel libre, cela est possible depuis toujours.

Limite de l’infrastructure personnelle

Un particulier qui héberge son propre serveur arrivera néanmoins assez immédiatement à la limite de ressource physique: l’espace qui va limiter le nombre de machines physiques. Le coût d’acquisition ainsi que la mise en place de l’infrastructure réseau sont également des facteurs limitants.

Mutualisation

Le particulier va donc mutualiser des fonctions sur une même machine qui fera office de serveur web, de serveur de messagerie ou encore de serveur ftp à la fois par exemple. Mais:

La mutalisation engendre des conflits de version de librairies

Les logiciels s’appuyant sur des bibliothèques du système, partagent ces ressources de l’OS et des incompatibilités peuvent empêcher les services d’évoluer indépendamment les uns des autres.

La virtualisation

Heureusement que la virtualisation permet de s’affranchir des contraintes physiques et la prise en charge de la virtualisation par le processeur et l’OS (kvm, intel VT-x) permet d’avoir des performances proches d’une exécution non virtualisée.

La virtualisation au niveau hardware permet d’avoir des environnements d’exécution cloisonnés

Ainsi chaque application peut êtres dans la version de son choix avec la version d’OS de son choix et même avec le type de ressources de son choix. La virtualisation telle que kvm par exemple le permet, est une abstraction de la machine physique.

Le prix à payer est celui d’un nombre d’installations d’OS qui croit avec le nombre d’application. Dans ce modèle une application c’est une VM au moins. Une VM c’est un OS qu’il faut installer et administrer.

Limites de la virtualisation

Outres la charge d’administration système qui ne change pas par rapport une plateforme physique, la virtualisation est coûteuse en ressources physique de la machine hôte.

En effet une VM c’est une allocation d’office d’un espace disque et mémoire sur l’hôte. Ainsi une VM qui est taillée avec 1 Go de mémoire consomme 1 Go de mémoire sur l’hôte même si dans la VM son OS ne prend que 600 Mo. La technique de balloon que j’ai testé ne permet que de réduire la mémoire de l’invité à chaud. L’augmentation de la mémoire ne se fait pas à chaud et n’est pas automatisée. Une intervention humaine est nécessaire.

Il en est de même pour l’espace disque. La virtualisation définit des disques virtuels. Grâce à LVM on peut augmenter la tailles des partitions dans l’invité à chaud mais c’est une intervention volontaire comme on ne ferait sur une machine physique. De plus quand on alloue un disque de 10 Go à une VM, on crée un fichier de 10 Go sur l’hôte même si dans l’invité on utilise que 2 Go.

La virtualisation c’est un découpage d’une machine physique. Sur chaque partie, on installe un OS et les applications.

En terme d’isolation la virtualisation est championne

Simplifier la virtualisation

L’administration de multiples VM est fastidieuse. Il faut mettre à jours autant d’OS que de VM.

La création d’une VM fonctionnelle l’est tout autant. Il faut d’abord installer l’OS puis l’application et son parametrage. Heureusement grâce aux virtual appliance comme celles fournies par turnkeylinux, l’ajout d’une nouvelle application virtualisée, qui se materialise par une VM, est rapide.

Vers la conteneurisation

On a évoqué le manque de souplesse dans l’allocation des ressources. Ce problème ne se rencontrerait pas si les applications étaient toutes installées sur l’hôte en partageant les bibliothèques du système et les ressources de l’OS que sont la mémoire et le disque.

Cette idée qu’un service comme un moteur de blog par exemple devrait être ce qu’il a toujours été depuis l’origine: une application et non pas une VM, est fondamentale à mon sens pout appréhender la conteneurisation avec la bonne grille de lecture. Comme une application ne doit pas être associé à un OS dédié depuis l’avènement du multitâche…les applications doivent se partager less ressources de la machine qui les heberge via un l’OS.

Pour autant on ne veut pas retomber dans les écueils de la mutualisation et garder un cloisonnement des applications afin que chacune puisse évoluer avec des versions de librairies différentes.

C’est là que les concepts d’isolations via des techniques qui ont évoluées du chroot (1982), en passant pas lxc (2008) puis docker (2013) au sein même de l’OS rentrent en jeu. Ainsi les applications sont isolées tout en étant à un niveau de performances quasi identiques que si elles non conteneurisées. En effet tous les appels systèmes se font directement sur l’OS hôtes sans passer par un OS invité qui va ensuite appeler via la couche de virtualisation l’OS hôte. C’est plus long même si et le noyaux linux avec kvm et les cpu (ex: Intek VT-x) offrent un support de la virtualisation.

Un conteneur n’est pas une VM

Je souligne encore cette difference car il me semble assez commun de faire l’erreur. Voici les differences à bien avoir en tête.

Un conteneur execute une application qui utilise l’OS de l’hôte ou plus exactement les appels systèmes (noyaux linux) de l’hôte. De la on comprend qu’il ne sera pas possible d’executer une applications compilée pour un CPU différent ou un OS différent. On pourra exécuter une distribution différente (simple arborescence de fichiers spécifique à la distribution) mais il n’est pas possible d’executer une application Windows sur un hôte linux.

Un conteneur c’est une application. On ne définit plus des ressources physiques dans ce paradigme. L’application va utiliser à la demande la mémoire et le disque disponible sur l’hôte.

Quand passer à Docker ?

Hier.

Dans le cas où toutes VM sont des linux que l’on souhaite garder à jour c’est-à-dire dans la plus récente version disponible alors la conteneurisation est la solution pour mieux utiliser les ressources en quantité et en performance.

La paradigme des VM mono-application n’est pas optimum et represente une solution surdimensionnée au besoin d’isolations réel: a-t-on vraiment besoin d’un OS par application ?

A suivre sur ce blog, mes prochaines aventures dans le monde de docker avec la conteneurisations de mes VM.