La vie sur le bord : comprendre la couche marginale d'Upsun

Tout d'abord, qu'est-ce que la couche périphérique et pourquoi en avons-nous besoin ? La couche d'extrémité est ce qui permet à une requête envoyée depuis votre navigateur vers un site hébergé sur Upsun d'atteindre le bon site et de renvoyer la réponse. Elle vous place également sur le bon serveur lorsque vous tapez upsun ssh dans votre terminal, en veillant à ce que les requêtes soient envoyées exactement là où elles doivent l'être.

Mais à quoi ressemble exactement la vie en périphérie avec Upsun ? Comment fonctionnent les requêtes ? Et quelles sont les principales choses que vous devez savoir sur le fonctionnement de la couche périphérique ?

Concepts fondamentaux d'Upsun

Avant d'entrer dans le vif du sujet, il est utile de comprendre quelques pièces essentielles du puzzle que nous appelons Upsun. En particulier, nous devons être clairs sur la hiérarchie des composants gérés par Upsun.

Le composant le plus large est la région. Une région fait référence à une région de nuage de l'un de nos fournisseurs de nuage sous-jacents, en particulier un nuage privé virtuel (VPC) qui représente une seule région Upsun. Une région gère des hôtes, qui sont des machines virtuelles (VM) fournies par le fournisseur de cloud de la région. Nous avons différents types d'hôtes tels que les passerelles, les hôtes de grille et les coordinateurs, et un seul hôte peut contenir de nombreux clusters, un cluster pouvant couvrir plusieurs hôtes. Une grappe est un regroupement logique de quelques services apparentés.

A service est une abstraction qui représente un service que nous gérons. Il peut s'agir de la base de données (DB), du cache ou de l'application du client elle-même. En interne, un service s'exécute dans des conteneurs. Un conteneur est comme une mini-VM légère, et nous gérons une tonne de conteneurs - un seul hôte peut avoir beaucoup de conteneurs ! Chaque service est associé à un ou plusieurs conteneurs s'il fonctionne en mode haute disponibilité.

L'énoncé du problème

Maintenant nous connaissons le strict minimum pour formuler notre problème en termes moins vagues : comment accepter une requête vers un site hébergé sur Upsun, la transmettre au conteneur exact qui contient le serveur pour ce site, et transmettre la réponse du serveur à l'utilisateur ?

La première étape consiste à faire en sorte que la demande atteigne la bonne région d'Upsun. Pour ce faire, le client ajoute un enregistrement DNS (de type CNAME/ALIAS, si cela vous intéresse) qui dit : "Mon domaine personnalisé se résout à l'adresse IP publique de cette région Upsun". Le navigateur de l'utilisateur qui consulte le site envoie ainsi la demande à la région Upsun qui héberge le site.

À partir de ce moment, notre couche de bordure prend le relais (musique dramatique).

Éplucher les couches de bordure

La plupart de nos hôtes (c'est-à-dire les machines virtuelles qui constituent une région de la couche périphérique d'Upsun) n'ont même pas d'adresse IP publique. Cela inclut les hôtes qui hébergent les serveurs des sites hébergés sur Upsun. Les hôtes qui ont une IP publique sont les hôtes en périphérie. Naturellement, toute requête dirigée vers l'IP publique d'une région atteindra la périphérie.

Rappelons qu'un hôte périphérique n'est qu'une VM fournie par un fournisseur de services en nuage. Rappelons également qu'un hôte peut contenir des clusters. Il se peut également que vous perdiez patience alors que nous épluchons couche après couche pour ne rien trouver d'intéressant. Mais restez avec nous, nous vous promettons que la prochaine couche sera intéressante !

Proxy de périphérie

La description officielle est un peu longue : Edge est un proxy dynamique, transparent et multi-protocole.

En voici la décomposition :

Dynamique : Nuntius peut récupérer les changements et mettre à jour sa configuration sans aucune intervention manuelle.

Transparent : le monde n'a pas besoin de savoir ce qu'est nuntius ou comment il fonctionne. Il vous suffit d'envoyer une requête à nuntius et vous obtenez la réponse appropriée comme si le serveur d'application lui-même vous répondait directement.

Multi-protocole : Nuntius est capable de gérer HTTP (v1.1 et 2), HTTPS et même SSH!

Proxy : C'est le point le plus important : nuntius lui-même ne peut pas traiter les requêtes qui lui sont envoyées. Au lieu de cela, il les transmet au bon endroit, attend que le bon endroit réponde et vous renvoie cette réponse.

En d'autres termes, Edge Proxy est le premier composant qui fait quelque chose avec la requête. Cela signifie qu'il a plusieurs responsabilités importantes :

Agir en tant que proxy pour les projets des clients

Agir en tant que pare-feu d'application Web

Agir en tant que proxy pour l'API Upsun

Edge Proxy : trouver le chemin

Dans cet article, nous nous concentrerons sur le premier rôle : un proxy qui achemine une requête vers la bonne application.

Chaque conteneur sur la région a une IP qui est unique dans le réseau (superposé) sur lequel tous les conteneurs se trouvent. L'objectif est que le proxy transmette la requête au bon conteneur qui héberge le serveur d'application du projet. Pour que cela fonctionne, le proxy maintient une correspondance entre les URL et les IP des conteneurs. Il s'agit d'une information dont le proxy n'a pas connaissance, il doit donc s'adresser à quelque chose qui est : l'orchestration du conteneur ou le magasin de données distribué. L'orchestrateur de conteneurs expose des informations sur les routes vers les projets, les ACL, etc. via une RPC. Le proxy s'appuie sur ces informations pour savoir a) si l'utilisateur qui fait cette demande est autorisé à le faire et b) le conteneur qui peut répondre à cette demande.

L'IP du conteneur que le proxy a trouvé est sur une VM différente. Et pour compliquer encore les choses, nous pouvons avoir un nombre quelconque d'hôtes de conteneurs dans une région.

En d'autres termes, lorsque le proxy transmet une requête à l'IP du conteneur, quelque chose doit déterminer sur quelle VM se trouve ledit conteneur. Cette chose est le démon ARP. Ce terme est légèrement trompeur, car le protocole ARP est utilisé pour convertir une adresse IP en adresse physique (c'est-à-dire en adresse MAC). Dans notre cas, le démon ARP détermine l'hôte de la grille sur lequel se trouve un conteneur en se basant sur l'IP du conteneur, c'est-à-dire qu'il convertit l'IP du conteneur en IP de l'hôte.

En fait, les IP des conteneurs n'appartiennent même pas au même réseau que les hôtes. Elles appartiennent en fait à un réseau superposé. Pour l'instant, il est important de savoir que le démon ARP se chargera de veiller à ce qu'une requête adressée à une certaine IP de conteneur arrive à destination.

Les portes de l'environnement : le routeur

Vous vous souvenez quand je vous ai dit que le proxy détermine l'IP du conteneur de l'application afin de pouvoir lui transmettre des requêtes ? J'ai menti. Les requêtes sont en fait acheminées vers un service spécial appelé routeur. Le service de routeur contient un seul conteneur de routeur, qui est le gardien de l'environnement - oui, nous avons un routeur par environnement.

Le conteneur de routeur exécute un proxy inverse de mise en cache. Un proxy inverse est quelque chose qui se place devant votre serveur et transmet les requêtes et les réponses tout en agissant comme un cache ou un équilibreur de charge.

C'est le service que vous pouvez configurer via le fichier routes.yaml dans votre projet Upsun. C'est ainsi que vous avez un routeur par environnement - si votre fichier routers.yaml diffère entre deux environnements, ces environnements auront des routeurs configurés différemment.

Le routeur envoie finalement la requête au conteneur d'application, c'est-à-dire au serveur qui dessert réellement le site.

À ce stade, la requête a enfin atteint le serveur !

Toutes les connexions entre les différents nœuds sur le chemin d'une requête sont des connexions TCP. L'avantage de TCP est que la connexion utilisée par une requête peut rester ouverte. Cela signifie que la réponse du serveur peut emprunter le même chemin vers l'hôte à la périphérie et vers le monde entier. C'est ainsi que la réponse à la requête parvient à l'utilisateur.

Mise en réseau de conteneur à monde et autres choses

Il y a une partie importante de la couche périphérique que cet article ne couvre pas : comment faire interagir le conteneur de l'application avec l'internet externe ?

C'est beaucoup plus difficile que vous ne le pensez. Nous avons des routes séparées pour le trafic sortant via les hôtes de périphérie (parfois dédiées uniquement au trafic sortant) qui nous permettent de contrôler finement le trafic sortant de nos régions.

Nous vous attendons là-bas !

Remerciements

Un grand merci à nos collègues experts qui ont contribué à ce billet : Ricardo Kirkner, Pilar Gomez, Colin Strickland, Krishna Kashyap et Eder Leão Moosmann.