Publier un service web dans le cloud : ce qui change

Publier dans le cloud ne change pas ce que fait un reverse proxy, mais change qui l'exploite, ce qu'on peut y régler et ce qu'il coûte. Cette dernière leçon s'adresse à qui vient de publier un service derrière Nginx, Traefik ou HAProxy et se demande ce qui reste vrai chez un fournisseur de cloud. Elle sépare trois choses : les concepts qui survivent, les réglages qui changent de main (fichier, puis API), et les sujets que la formation n'avait aucune raison d'enseigner : facturation, quotas, zones de disponibilité, bordure managée. Aucun geste de fournisseur n'est enseigné ici.

Ce que vous allez apprendre

La leçon part de ce que vous savez déjà faire à la main, et dit pour chaque pièce laquelle des trois choses lui arrive : elle survit telle quelle, elle change d'opérateur, ou elle cède la place à un sujet que l'auto-hébergement ne posait pas.

• Dire quels concepts de la formation restent valables avec un répartiteur managé
• Traduire un réglage de fichier en réglage d'API ou de console
• Nommer ce que le cloud ajoute : facture, quotas, zones
• Expliquer pourquoi les machines restent privées et seule la bordure publique

Prérequis

Cette leçon ferme la formation : elle suppose que vous avez publié au moins un service derrière un reverse proxy. Trois notions suffisent pour la lire : le reverse proxy, la sonde de santé et le pare-feu.

• Ce qu'est un reverse proxy et la différence entre un nom, un port et un backend : voir Reverse proxy : définition, rôle et quel outil choisir.
• Ce qu'est une sonde de santé : voir Choisir la répartition et mesurer les sondes.
• Ce que fait un pare-feu devant un service : voir Relier interfaces, ports, pare-feu et exposition.

Aucun compte chez un fournisseur n'est nécessaire : la leçon n'a donc pas de lab, seulement un quiz.

Qu'est-ce qui reste vrai quand on publie chez un fournisseur de cloud ?

Les concepts de la formation restent exacts : seul l'opérateur change. Un répartiteur managé reçoit les connexions sur une adresse publique, choisit un backend, termine le TLS si on le lui demande, sonde ses backends et cesse d'envoyer du trafic vers celui qui échoue. C'est exactement le contrat que la formation vous a fait vérifier à la main : un nom, un certificat, un chemin de la requête jusqu'au backend, une bascule.

Trois savoirs servent donc autant qu'avant. Lire une sonde : une sonde qui vérifie seulement qu'un port répond laisse passer une application bloquée, comme avec HAProxy. Comprendre une bascule : le délai de détection est le produit de l'intervalle par le seuil d'échec, que le réglage soit une ligne fall ou un champ d'API. Savoir où l'adresse du visiteur passe : derrière un répartiteur qui relaie les requêtes (L7), le backend voit en général l'adresse du répartiteur, et l'adresse réelle voyage dans un en-tête, à ne croire que s'il vient de la couche précédente. Certains répartiteurs de niveau 4 conservent l'adresse source : la documentation du produit tranche.

La distinction entre un répartiteur L4 et L7, une passerelle d'API et un ingress n'est pas refaite ici : elle est posée dans Répartiteur de charge, passerelle d'API, ingress : les distinguer. Cette leçon prend le relais sur ce que cette page laisse de côté, le passage d'un composant que vous installez à un service que vous consommez.

Qu'est-ce qui change de main avec un service managé ?

Ce que vous écriviez dans un fichier devient un réglage d'API, et ce que vous surveilliez dans les journaux devient une métrique du fournisseur. Vous ne déployez plus de binaire, vous ne le mettez plus à jour et vous ne portez plus sa disponibilité : c'est le gain. En contrepartie, vous n'avez plus accès au programme, donc aux options que le fournisseur n'a pas exposées : c'est la perte.

Le tableau traduit les objets de la formation en leur équivalent managé, sans nom de produit puisque ceux-ci varient d'un fournisseur à l'autre.

Dans la formation	Avec un répartiteur managé
Fichier nginx.conf, haproxy.cfg ou configuration dynamique Traefik	Ressources décrites par l'API, la console ou un outil d'infrastructure en code
Bloc server ou routeur par nom de domaine	Règle d'écoute et de routage du répartiteur (L7 seulement)
Certificat obtenu par ACME et rechargé	Certificat géré ou importé par le fournisseur, renouvelé par lui
Sonde écrite dans la configuration	Sonde déclarée comme ressource, avec chemin, intervalle et seuil
stub_status, journaux JSON, exportateur	Métriques de plateforme et journaux d'accès à activer
Mise à jour du binaire (patch de sécurité)	Faite par le fournisseur, sans votre calendrier

Glissez pour voir

Le piège de cette traduction est de croire que tout réglage a un équivalent. Une directive très précise, une réécriture d'en-tête fine ou un module dynamique peuvent n'avoir aucun réglage correspondant. Avant de migrer, listez les directives dont dépend votre service : c'est cette liste, et non la préférence pour un outil, qui décide si un service managé suffit. Les cas de répartiteur de niveau 4 ou 7, de terminaison TLS et de sondes sont détaillés dans Load Balancing : répartition de charge L4, L7 et terminaison TLS.

Pourquoi la facture et les quotas deviennent-ils un sujet de conception ?

Un service managé se facture, et la facture dépend souvent de votre trafic : c'est une contrainte d'architecture, pas seulement de comptabilité. Avec un reverse proxy sur votre machine, le coût du composant est celui de la machine, fixe. Avec un service managé, la facture se compose en général d'une part fixe, due tant que le service existe, et d'une part variable selon le trafic ou le nombre de connexions, mais les modèles diffèrent : certains fournisseurs facturent le trafic, d'autres affichent un prix fixe sans facturer le trafic traité. Un trafic entre zones peut s'y ajouter. Lisez la grille tarifaire du produit avant de supposer la structure. Un répartiteur oublié devant un environnement de recette continue de payer sa part fixe, même sans visiteur ; seule la part variable suit le trafic.

Les quotas, ou limites de service, sont l'autre surprise. Un fournisseur plafonne le nombre de ressources d'un type, par compte ou par région selon le fournisseur. Certaines limites se relèvent sur demande, d'autres sont fixes : la documentation du produit indique lesquelles. Le moment où l'on découvre la limite est le pire : au moment d'ajouter une ressource pour absorber un pic. La question à poser, avant la mise en production, n'est donc pas seulement « combien de répartiteurs ? » mais « quelles limites s'appliquent, sont-elles relevables, et comment en demander plus ? ».

Trois réflexes suffisent à garder la maîtrise. Estimer le coût à partir du trafic attendu, avant la mise en service. Alerter sur le dépassement du budget plutôt que le découvrir en fin de mois. Supprimer les ressources d'un environnement éphémère avec lui, car un répartiteur orphelin continue de se facturer. Une attaque applicative peut aussi faire grossir une infrastructure élastique sans rien casser, comme le détaille le guide Exposer une application.

Que change le découpage en zones de disponibilité ?

Une zone de disponibilité est un datacenter, ou un groupe de datacenters, isolé des autres au sein d'une région : la disponibilité se décide en choisissant dans combien de zones on place chaque composant. Avec votre propre reverse proxy sur une seule machine, la question ne se posait pas : la machine était le point de défaillance, et la formation vous l'a fait mesurer. Dans le cloud, elle se pose pour chaque brique, y compris celle que vous ne gérez plus.

C'est ici que la lecture attentive s'impose : selon le fournisseur, un répartiteur peut être zonal (il tombe avec sa zone) ou régional (le fournisseur répartit lui-même ses nœuds sur plusieurs zones), et seule la page du produit dit lequel des deux modèles s'applique. La conséquence vaut d'être posée : deux backends dans deux zones derrière un répartiteur zonal ne tolèrent pas la perte de la zone du répartiteur, et le soin pris à répartir les backends ne sert alors à rien. Le principe est détaillé dans Load Balancing : répartition de charge L4, L7 et terminaison TLS, section « Un répartiteur survit-il à la perte de sa zone ? ».

Le nom du service reste l'autre maillon. Basculer vers un second répartiteur passe par le DNS, avec les délais de cache que vous avez étudiés en préparant une bascule DNS. Un DNS managé fournit les mêmes enregistrements et la même durée de vie, ainsi qu'un basculement automatique dont la limite est décrite dans DNS managé : zones, records, TTL et basculement.

Pourquoi garder ses machines privées dans le cloud ?

La bonne position par défaut dans le cloud est de ne donner d'adresse publique à aucune machine et de ne publier que par un service de bordure. Le principe, nommé « private by default », réduit la surface d'attaque à une porte surveillée. Dans la formation, vous avez fermé des ports sur une machine ; ici, la machine n'a simplement pas d'adresse joignable depuis Internet, et le seul chemin entrant passe par le répartiteur, éventuellement précédé d'un CDN et d'un pare-feu applicatif.

Ces services de bordure, CDN, WAF et anti-DDoS, n'existent presque jamais chez soi : personne n'héberge un réseau de diffusion de contenu dans son garage. Ils sont déjà décrits dans CDN, WAF, anti-DDoS : lire les services de bordure, qui rappelle aussi le contournement à éviter : si l'origine reste joignable directement, la bordure ne protège rien. Le guide Exposer une application : bordure, CDN, WAF et anti-DDoS donne la méthode pour les activer sans bloquer ses propres utilisateurs, et Edge computing cloud : du CDN aux fonctions à la périphérie explique jusqu'où la bordure peut exécuter du code.

Deux cas particuliers prolongent cette position. Quand le trafic ne doit pas passer par Internet du tout, par exemple entre votre application et un service managé, un point de terminaison privé garde le flux dans le réseau du fournisseur. Et si votre exposition est faite d'appels d'API avec authentification et quotas par consommateur, la question « faut-il une passerelle ? » a sa propre réponse dans Faut-il une passerelle d'API devant son application cloud ?.

Faut-il garder son reverse proxy ou prendre le service managé ?

Prenez le service managé tant que vos besoins tiennent dans ses réglages, et gardez votre reverse proxy quand une fonction que vous ne pouvez pas exprimer chez le fournisseur est au cœur du service. La décision se prend sur trois critères, dans cet ordre : la liste des fonctions réellement utilisées (voir plus haut), le coût d'exploitation que vous acceptez de porter (mises à jour, sauvegarde de configuration, astreinte), et la portabilité. Une configuration d'API est écrite pour le vocabulaire d'un fournisseur et se réécrit presque entièrement pour en changer. Un fichier Nginx se déplace plus facilement, sans être universel : il dépend de la version, des modules compilés et de l'arborescence du paquet, comme cette formation l'a montré avec les paquets de nginx.org, qui ne posent pas les mêmes répertoires que ceux de Debian.

Les deux se combinent souvent. Un répartiteur managé en façade, qui porte la disponibilité de la porte d'entrée et le certificat, peut envoyer vers un reverse proxy que vous exploitez pour un routage fin à l'intérieur du réseau privé. Dans ce montage, tout ce que la formation vous a appris continue de servir tel quel sur le second étage, et la lecture d'une sonde ou d'une bascule s'applique aux deux étages. Dans Kubernetes, l'ingress joue ce rôle de reverse proxy interne : c'est le sujet de la formation Kubernetes, pas de celle-ci.

Ce que vous ne devez pas faire, c'est choisir par habitude : ni le managé par crainte de l'exploitation, ni l'auto-hébergé par attachement à un outil. Chacun a un coût que vous pouvez écrire avant de décider.

À retenir

• Les concepts de la formation restent vrais : un répartiteur managé termine le TLS, sonde et bascule comme le faisait votre reverse proxy.
• Le réglage change de main : un fichier devient un réglage d'API, et vous perdez l'accès au binaire, donc à certaines options.
• Vous ne portez plus la disponibilité du composant, mais vous portez sa facture et ses quotas.
• La disponibilité se décide par les zones : un répartiteur zonal tombe avec sa zone, quel que soit l'emplacement des backends.
• Dans le cloud, les machines restent privées et la publication passe par la bordure.
• Le choix entre managé et auto-hébergé se fait sur les fonctions utilisées, le coût d'exploitation et la portabilité.

Contrôle de connaissances

Vérifiez que l'essentiel de ce guide est acquis. Les questions portent uniquement sur ce qui vient d'être expliqué ici.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

8 questions

8 min.

70% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

×

📖 Voir la documentation →