Nouvelles

Les « containers » … ça contient quoi au juste?

2 juin 2017

 

 

 

 

 

 

 

Il y a quelques semaines j’ai eu la chance de participer au OpenStack Summit à Boston. Lors de cet événement planétaire et bisannuel, où des milliers de développeurs et autres acteurs du monde des DevOps se rencontrent, le concept est de se mettre à jour sur l’avancement des différents projets, planifier les prochaines étapes du développement et échanger sur les projets des autres. Pour des gens spécialisés dans l’infrastructure comme c’est notre cas, on réalise rapidement qu’OpenStack est immensément plus près du développement que des opérations bien que le terme DevOps sous-entende les deux.

Une des choses qui frappe dans cette réalité, c’est le concept du « container » ou conteneur. Non seulement ce n’est pas « nouveau », car, après tout, dans le monde Unix/Linux (FreeBSD Jails, UNIX chroot, Solaris containers, AIX avec ses WAPRs, etc.) ça existe depuis des lustres, mais en plus c’est même à la base du « lingo » et des pratiques dans les environnements de développement. Tellement que certains reviennent sur l’idée des machines virtuelles et se demandent ce qu’ils peuvent faire et offrir par rapport aux machines virtuelles. Ce court article se veut une modeste tentative pour aider à démystifier le concept du point de vue de l’infrastructure pure.

Qu’est-ce que les conteneurs peuvent offrir que les VMs ne font pas déjà depuis que VMware ESX a débuté au début des années 2000?

L’efficacité. En effet, puisque les conteneurs roulent directement sur l’OS et donc sur le matériel des serveurs (CPU, mémoire, disque, réseau), l’accès est beaucoup plus efficace puisqu’il n’existe aucune entrave ou réserve pour une couche logicielle additionnelle (tel un hyperviseur). Autrement dit, tout comme dans le temps des serveurs physiques, toutes les ressources disponibles du matériel sont accessibles pour les applications et tout ce qui roule dans les conteneurs maximise dans les faits l’investissement. Sans compter que, lorsqu’on roule une application ou un environnement dans une machine virtuelle, chaque VM roule sa propre copie du système d’exploitation en plus de chaque composante virtualisée du matériel du serveur, ce qui signifie qu’en réalité beaucoup de ressources sont utilisées pour la virtualisation et non pour les applications.

La performance. Tel qu’expliqué ci-dessus et pour les mêmes raisons, puisque les conteneurs roulent directement sur le matériel des serveurs, la performance est par le fait même améliorée, car l’accès est plus direct. Les hyperviseurs ont bien des avantages, qu’il ne faut pas dénigrer, mais côté performance pure, les conteneurs ont le haut du pavé.

La sécurité est elle aussi (et de plus en plus, surtout dans les derniers mois) un enjeu critique avec les conteneurs, car le concept même rend leur défense différente à bien des égards de ce à quoi nous sommes habitués avec les machines virtuelles. Le fait de rouler à partir d’un même noyau (kernel) augmente les possibilités et les vulnérabilités, mais, en même temps, si l’ensemble des conteneurs est bien sécurisé, plusieurs sont d’avis que le niveau de sécurité peut être aussi, sinon plus élevé que c’est le cas avec les machines virtuelles. L’expertise des équipes qui mettent en place ces environnements est donc d’une importante capitale.

Puisqu’on voit tous les grands manufacturiers (IBM, Microsoft, etc.) développer et investir dans cette technologie, on sait qu’elle constituera une portion de notre avenir, même en infrastructure plus traditionnelle. La popularité de la virtualisation x86 a causé une vague dans l’industrie et son but était l’efficacité et la portabilité, donc les conteneurs peuvent définitivement aider. C’est simple, on peut rouler plus d’applications sur le même matériel avec des conteneurs qu’avec des VMs. Donc, si on a l’expertise et que les charges de travail sont appropriées, pourquoi ne pas profiter de cet avantage concurrentiel?

 

– Par Nicolas Brodeur, Ambassadeur des solutions d’infrastructures et infonuagiques

Pour toute question technique, écrivez-nous à service@micrologic.ca