L'infrastructure on INF1410 - Initiation au génie logiciel

La conteneurisation (Docker)

Mon, 01 Jan 0001 00:00:00 +0000

La conteneurisation (Docker)#

Parallèlement à l’essor du cloud, une autre approche de l’isolation a émergé, plus légère que la virtualisation classique. L’idée de base est ancienne : la commande chroot d’Unix, disponible depuis 1979, permettait déjà de restreindre la vision du système de fichiers d’un processus. Au fil des années, le noyau Linux a développé des mécanismes d’isolation de plus en plus sophistiqués : les cgroups (control groups, 2006), qui permettent de limiter les ressources (CPU, mémoire) allouées à un groupe de processus, et les namespaces (2002-2013), qui isolent différents aspects du système (réseau, identifiants de processus, système de fichiers). Ces primitives existaient, mais restaient difficiles à utiliser directement. En 2013, Solomon Hykes et son entreprise dotCloud (qui deviendra Docker Inc) ont lancé Docker, un outil qui rend ces mécanismes accessibles à travers une interface simple et élégante. Au lieu de virtualiser une machine complète avec son propre noyau (comme le fait une VM), un container partage le noyau du système hôte tout en maintenant une isolation quasi complète de l’environnement applicatif. Le résultat est beaucoup plus léger qu’une VM : un container démarre en secondes plutôt qu’en minutes, et consomme une fraction des ressources. Docker a également popularisé le concept d’image comme artefact reproductible et distribuable, résolvant de manière élégante le fameux problème “ça marche sur ma machine”.

L'orchestration (Kubernetes)

Mon, 01 Jan 0001 00:00:00 +0000

L’orchestration (Kubernetes)#

Docker compose, que nous venons de voir, permet de gérer un groupe de containers sur une seule machine. Mais que se passe-t-il quand une application doit tourner sur des dizaines ou des centaines de machines, avec des exigences de haute disponibilité ? Si un container tombe, qui le redémarre ? Si la charge augmente, qui décide de créer de nouvelles instances ? Comment répartir le trafic entre les containers disponibles ? Ces questions définissent le problème de l’orchestration.

L'infrastructure comme code (Terraform)

Mon, 01 Jan 0001 00:00:00 +0000

L’infrastructure comme code (Terraform)#

Jusqu’ici, nous avons traité l’infrastructure comme une donnée acquise. Le cluster Kubernetes existe, les serveurs tournent, le réseau fonctionne. Mais d’où vient cette infrastructure ? Concrètement, l’infrastructure d’un système logiciel comprend tout ce qui doit exister avant que le code puisse s’exécuter. On y trouve les serveurs (physiques ou virtuels), les réseaux (sous-réseaux, règles de pare-feu, load balancers), le stockage (disques, espaces de stockage cloud), les bases de données, les certificats SSL et les entrées DNS. Pendant longtemps, cette infrastructure était créée et configurée manuellement. Un administrateur se connectait à une console cloud pour créer un serveur, puis en SSH pour installer des paquets et modifier des fichiers de configuration. Le résultat était ce qu’on appelle un snowflake server : une machine unique, configurée à la main au fil du temps, dont personne ne sait exactement reproduire l’état. Si elle tombe en panne, la reconstruire à l’identique relève de l’archéologie.