Nous avons tous ressenti cette satisfaction grisante : après quelques échanges avec notre IA favorite, le code de notre application est là, fonctionnel, sur notre machine locale. Mais pour qu'elle soit accessible au monde entier, elle doit quitter notre salon pour rejoindre « le nuage ». Pour beaucoup, le Cloud ressemble à une boîte noire magique.
Pourtant, comprendre ce qui se cache sous le capot n'est pas qu'une question de curiosité technique ; c'est ce qui nous permet de passer du prototype fragile à une solution de production robuste et sécurisée. Cet article a pour but de partager les clés de la virtualisation et du stockage, pour ensuite déployer nos projets en toute sérénité.
La Machine Virtuelle : un ordinateur dans les nuages ?
Lors d'un précédent article, nous nous étions lancés dans un voyage au centre du nuage, au cours duquel nous avions pu survoler la plupart des concepts clés des différentes strates du Cloud.
Nous y avions survolé quelques concepts de base, comme celui de Machine virtuelle (ou VM). Contrairement à un serveur physique (que nous retrouvons en tant que « Bare Metal » dans le Cloud), une VM est une machine créée et exécutée comme un logiciel, grâce à une application spéciale : l'hyperviseur. Ce dernier simule le matériel physique, tandis que la VM se comporte comme un ordinateur, mais virtuel (avec un système d'exploitation, et ses propres logiciels à l'intérieur).
Pour nous, développeurs, cela signifie que nous disposons d'un environnement isolé où nous pouvons choisir notre système d'exploitation et nos ressources (CPU, RAM). C'est la brique élémentaire du IaaS (Infrastructure as a Service), nous offrant un contrôle total sur l'environnement d'exécution.
Et comme nous l'avions vu lors du voyage au centre du nuage, le IaaS est une strate essentielle sur laquelle reposent les suivantes.
L’Image Machine : le « blueprint » de notre serveur
Si la VM est la maison, l’Image Machine est le plan de construction. Une image contient le système d'exploitation, la configuration et la plupart du temps, nos outils pré-installés (comme NginX, NodeJS, ou Python).
L'Image Machine est un outil très puissant. Une fois que nous avons configuré une VM parfaite pour notre service, nous créons une image à partir de celle-ci. À partir de ce modèle, nous pouvons ensuite répliquer notre service, « créer de nouvelles instances », pour absorber la charge lorsque le nombre de visiteurs augmente. Et cette « scalabilité horizontale » peut nous permettre d'absorber des pics de charge soudains (comme pendant les soldes sur Amazon) en automatisant l'approvisionnement en Machines Virtuelles au moment où nous décelons l'arrivée du pic (soit parce que les dates sont prévisibles, soit parce que la charge augmente suffisamment lentement pour laisser le temps de créer de nouvelles instances).
Le Stockage pour conserver nos données
Dans le Cloud, la VM fournit l'abstraction de la puissance de calcul de l'ordinateur, les CPU, les GPU (cartes graphiques), la RAM... Le stockage est géré à part, via des volumes qui peuvent être « montés » sur la VM, de la même façon que nous pouvons monter une clé USB sur notre ordinateur physique.
Ces volumes peuvent être branchés, débranchés, dupliqués, déplacés vers une autre VM, etc. Ils sont cruciaux pour la résilience de nos applications : si la VM rencontre une panne, ou que notre service se plante (quand nous avons un gros bug, ou que l'IA a un peu trop halluciné sur le code...), nos données restent intactes sur le volume, qui peut être rattaché à une nouvelle instance.
Les volumes pourraient faire l'objet d'un chapitre à part entier, car de nombreuses technologies en découlent, suivant les types de données à stocker, à quel point ils sont critiques,... Par exemple, pour les données qui ne supportent pas la corruption (dans le sens où une modification aurait été partiellement appliquée, cassant des liens entre les données), nous utilisons des Snapshots (ou « captures »), qui sont des photographies instantanées de l'état de nos données, dédiées à la conservation d'un ancien état du volume. Lorsqu'un événement cause une corruption des données (bug ou attaque d'un pirate), nous pouvons restaurer le volume à l'état antérieur à partir du contenu du snapshot.
Les Security Groups : notre premier rempart pour sécuriser nos services
La sécurité ne doit jamais être une option ajoutée après coup. Le Security Group est notre première ligne de défense : c'est un pare-feu virtuel qui contrôle quel trafic a le droit d'entrer ou de sortir de notre instance.
Par défaut, tout est fermé. Nous devons explicitement ouvrir des « robinets » (les ports). Typiquement, nous ouvrirons le port 80 pour les flux HTTP et 443 pour les flux HTTPS, ou le port 22 pour le SSH (ce qui nous permet de nous connecter à la machine pour l'administrer).
Nous pouvons également spécifier des adresses, ou plages d'adresses avec lesquelles nous pouvons nous connecter aux services. Par exemple, nous pouvons ouvrir le port 22 sur une machine spéciale, le bastion, qui sert de porte d'entrée au service, puis le port 22 sur notre serveur d'application, en spécifiant uniquement l'adresse IP de notre bastion. Et entre le bastion et le serveur, nous devons fournir un autre moyen d'authentification que celui nécessaire à l'accès au bastion... De cette façon, même si un pirate a pu se procurer l'accès au bastion (par exemple en nous volant notre ordinateur), il sera confronté à un nouveau blocage avant d'accéder aux données sensibles du service...
VPS : la solution simplifiée
Lorsque nous commençons à concevoir des machines virtuelles sur mesure pour notre service, nous commençons également à rechercher et identifier les portions critiques de notre service, celles qui deviennent un goulot d'étranglement lorsque le pic de charge approche. Nous allons alors répartir ces services sur plusieurs Images Machines différentes, et lorsque la charge augmente, nous créons de nouvelles instances des services les plus impactés en priorité.
Maintenant, gérer chaque brique de l'infrastructure peut être lourd. C'est là qu'intervient le VPS (Virtual Private Server). C'est une solution « tout-en-un » où le fournisseur gère une partie de la complexité pour nous, avec un prix souvent plus prévisible que chez les grands Hyperscalers (AWS, Azure, GCP). Les offres des hyperscalers sont idéales pour la scalabilité automatique et les architectures complexes, mais elles peuvent vite devenir coûteuses si nous ne maîtrisons pas la consommation.
Des fournisseurs « VPS-first » comme Hetzner, OVH ou DigitalOcean, se concentrent spécifiquement sur la création et la gestion de ces Images Machines sur mesure, pour nous. En effet, les goulots d'étranglements étant prévisibles et récurrents, ces fournisseurs prennent à leur compte leur gestion, incluant la mise à l'échelle automatique (pour la gestion des pics de charge). Ils s'arrangent également pour mutualiser les ressources, de sorte à dégager des économies qui se répercutent sur notre facture.
Ainsi, les offres de VPS n'exposent aux utilisateurs que les portions de services essentiels à la gestion de leur site web, avec un budget maîtrisé. En contrepartie, nous abandonnons une partie du contrôle fin sur les couches basses de l'infrastructure.
L’œuf ou la poule : l'image et la VM
Pour la petite histoire, on nous demande souvent : qu'est-ce qui vient en premier ? Dans les faits, nous partons toujours d'une image de base fournie par le Cloud Provider pour créer notre première VM. Une fois cette VM personnalisée avec notre code, elle devient à son tour le parent d'une nouvelle image personnalisée. C'est un cycle vertueux qui nous permet d'automatiser nos déploiements.
Pour le Cloud Provider (ou futur hyperscaler) se pose un problème similaire, à l'autre bout du spectre : la création d'une machine virtuelle part d'une image machine, mais la création de l'image part d'une VM,... Mais comment résoudre ce problème d'œuf et de poule ?
Pour y parvenir, l'hyperscaler doit repartir du niveau d'abstraction antérieur au Cloud : le Bare Metal, que nous avons déjà abordé dans notre ancien article . Nous partons alors d'une image souche créée à partir d'une distribution Linux vierge, souvent Red Hat ou Suse, qui sont deux distributions Linux (des variantes du système d'exploitation Linux) très utilisées dans le monde professionnel.
À partir de cette première image, nous allons utiliser un émulateur local pour démarrer une première machine virtuelle, dans laquelle les développeurs pourront installer et configurer les outils de base de la future offre de Cloud.
Et des années plus tard, nous devenons leader mondial du Cloud et 90% du réseau internet passe par nos infrastructures, mais ça, c'est une autre histoire !
Conclusion
Maîtriser ces fondamentaux nous permet de ne plus subir le Cloud, mais de l'utiliser comme un levier de croissance. En comprenant comment s'articulent nos instances, nos images et notre sécurité, nous posons les fondations d'une infrastructure capable de supporter le succès de notre produit.
Pour débuter, nous pouvons abstraire la majeure partie de cette complexité grâce aux offres de VPS, et ensuite progressivement reprendre le contrôle sur les couches basses qui supportent ces offres.
Cela nécessite cependant d'aller encore un peu plus loin. Dans notre prochain article, nous irons donc explorer les réseaux virtuels (VPC ou VNet), grâce auxquels nos services pourront discuter entre eux de manière sécurisée.
Ressources (et quelques lectures intéressantes)
- Software Architecture with Python, de Anand Balachandran Pillai
- Modern Operating Systems, de Andrew S. Tanenbaum
- Mastering KVM Virtualization, Humble Devassy Chirammal, Prasad Pant & Vignesh Kumar
- OpenStack in Action, Cody Bumgardner