Les expressions locales. Ce sont ces mots et expressions dont le sens, propre à une région, peut dérouter ceux qui n’en sont pas originaires. Par exemple, quand je suis dehors et que j’ai soif, je cherche un « bubbler ». Vous, vous cherchez probablement une fontaine à eau (j’imagine que vous n’êtes pas du Wisconsin). Dans le Wisconsin, nous mesurons les distances en temps, pas en kilomètres. Les feux de circulation sont des feux « stop n’ go ». Parce que c’est exactement ce qu’on y fait.
L’expression préférée de mon mari (qui n’est pas originaire d’ici), et qui le fait bien rire, est « C’mere once ». Je ne chercherai pas à l’expliquer davantage : elle me paraît tout simplement logique, tout comme aux enfants avec qui je l’emploie. Et nous comprenons instinctivement que « Up North » n’est pas une direction, mais un lieu dont l’emplacement précis peut varier selon la personne qui parle, tout en évoquant pour tous les natifs du Wisconsin « cet endroit où l’on va pour échapper à tout ».
Comme vous avez grandi ailleurs, vous avez probablement votre propre liste. Mais c’est mon blog, alors j’ai le droit d’utiliser la mienne.
Cependant, le propos d’aujourd’hui n’est pas de donner une leçon de sémantique à proprement parler, mais plutôt d’examiner comment celle-ci s’applique à un phénomène plus localisé, qui se produit juste sous vos yeux. Du moins, si l’on considère que votre organisation est votre environnement immédiat.
L’essor des conteneurs et des systèmes de contrôle automatisé des clusters qui leur sont indispensables (souvent appelés systèmes d’orchestration) a eu pour conséquence inattendue de faire passer le jargon d’un côté à l’autre de la frontière. Autrement dit, du développement d’applications vers l’informatique à proprement parler.
L’étrange cas du jargon des conteneurs
Bon nombre des fonctions nécessaires pour atteindre le niveau requis de flexibilité, de fiabilité et de capacité de mise à l’échelle ont entraîné la migration de certains services auparavant réservés à la production vers l’« environnement » des conteneurs. Ces fonctions sont désormais, en apparence, « intégrées » à cet environnement et s’appuient sur des mécanismes d’intégration légers (API et files d’attente de messages) pour offrir ce qui, jusqu’alors, ne pouvait être obtenu qu’avec un environnement de cloud computing entièrement déployé : mise à l’échelle automatique et applications à haute disponibilité.
Ainsi, les fonctions d’équilibrage de charge sont intégrées nativement aux pods/nœuds par l’intermédiaire de petits services de type démon. Bien qu’elles ne soient pas très avancées (leurs capacités dépassent à peine celles de l’équilibrage de charge réseau), elles remplissent la mission pour laquelle elles ont été conçues. Ces services peuvent être (et sont effectivement) modulaires, si l’on peut dire, ce qui permet à d’autres projets (open source ou proposés par des fournisseurs) d’offrir des fonctionnalités plus avancées (et, espérons-le, de meilleurs algorithmes).
Mais à elles seules, ces fonctions d’équilibrage de charge ne permettent pas d’atteindre l’évolutivité et la haute disponibilité que nous recherchons en définitive (et dont nous avons besoin dans les environnements de production). Elles ne sont pas non plus capables d’acheminer les API, ce qui nécessite une gestion intelligente du protocole HTTP (couche 7). C’est indispensable pour faire évoluer efficacement des applications modernes reposant sur des microservices et exposées par l’intermédiaire de façades d’API. Il nous faut une solution plus robuste.
C’est là que les contrôleurs d’entrée entrent en jeu. Ce sont les « répartiteurs de charge » qui analysent et dirigent le trafic entrant en fonction des URI et des en-têtes HTTP afin de permettre le routage au niveau de la couche applicative et la mise à l’échelle.
En fait, les développeurs qui ont créé (et qui utilisent désormais) les contrôleurs d’ingress ont essentiellement recréé ce que nous, dans les opérations réseau, appelons la gestion du trafic, la fourniture d’applications ou encore la commutation/le routage de contenu. Au fil des ans, nous avons employé de nombreux termes différents dans les opérations réseau, tout comme nos homologues du développement et des DevOps. Le routage d’applications et le routage de pages sont également des termes utilisés par les développeurs pour désigner le routage de couche 7. Le concept est familier aux deux groupes, mais pas les termes, ni les expressions propres à chacun.
Un contrôleur d’entrée est chargé d’acheminer les requêtes vers le service (virtuel) approprié au sein du cluster de conteneurs. Ce service peut être un autre proxy d’équilibrage de charge ou une structure propre au système de conteneurs. Dans les deux cas, le rôle du contrôleur d’entrée est d’acheminer le trafic en fonction des valeurs de couche 7 (HTTP) figurant dans les en-têtes HTTP d’une requête HTTP. Il s’agit généralement de l’URI, mais il peut aussi s’agir du nom d’hôte ou d’une autre valeur personnalisée (comme un numéro de version ou une clé d’API).
Une fois que le contrôleur d’entrée a extrait la valeur de l’en-tête, il s’appuie sur les stratégies décrites dans les fichiers de ressources pour déterminer comment répartir le trafic. Il peut le répartir équitablement, ou en envoyer 75 % vers une version du service et 25 % vers une autre. Il offre donc une grande souplesse à cet égard. Le contrôleur d’entrée est également chargé de la surveillance (intégrité et état) et doit veiller scrupuleusement à ne pas acheminer une requête vers un service « hors service ».
Cela vous semble familier, les équipes réseau ? C’est normal, car ce sont essentiellement les fonctions d’un proxy intelligent (compatible L7), comme BIG-IP.
Maintenant que vous savez en quoi ils sont similaires, sachez qu’il existe tout de même quelques différences. Notamment, un contrôleur d’entrée est configuré de manière déclarative. Autrement dit, sa configuration est déterminée par une description figurant dans un fichier de ressources externe au contrôleur lui-même. Ce fonctionnement diffère de celui des proxys intelligents traditionnels qui contrôlent et dirigent le trafic entrant. Ces derniers constituent les sources faisant autorité pour l’environnement. Ce n’est pas le cas d’un contrôleur d’entrée. Celui-ci recherche ces informations ailleurs, dans des fichiers qui font office de « couche d’abstraction » et offrent une certaine souplesse dans les implémentations. Cela signifie que le contrôleur (ou un composant complémentaire) doit lire ces fichiers, les interpréter et créer la configuration correspondant à cette description. Il doit également la maintenir à jour. Bien que la variabilité au niveau du contrôle des entrées d’un environnement conteneurisé soit moindre que dans les couches plus profondes du système, des changements surviennent tout de même et doivent être surveillés.
En définitive, l’Ingress Controller est chargé d’acheminer les requêtes au niveau de la couche applicative depuis l’extérieur vers la ressource appropriée à l’intérieur de l’environnement conteneurisé. Ce qui correspond à peu près à la définition d’un répartiteur de charge intelligent.
Le nom a peut-être changé, mais les fonctions restent sensiblement les mêmes.
À propos de l’auteur
Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.
Autres articles de Lori Mac VittieArticles de blog associés
F5 NGINXaaS pour Google Cloud : des applications résilientes et évolutives
Découvrez comment NGINXaaS s’intègre à Google Cloud pour renforcer les performances et la sécurité, et préparer vos applications critiques à un avenir propulsé par l’IA.
L’intégration de F5 Web Application Firewall (WAF) à AWS est disponible dès aujourd’hui
En faisant appel à un partenaire de déploiement AWS WAF tel que F5, vous pouvez renforcer la sécurité de vos applications web grâce à des règles personnalisées qui bloquent les schémas d’attaque courants, comme les injections SQL ou les attaques par scripts intersites (XSS).
Appliquer le principe de Peter Parker à l’inspection TLS
« Un grand pouvoir implique de grandes responsabilités. » Si l’on en trouve des échos chez Voltaire et Churchill, cette citation est surtout connue grâce aux bandes dessinées Spider-Man, où elle est attribuée à l’oncle Ben. Bien entendu, si cette phrase est si répandue dans la culture populaire, c’est notamment parce qu’elle peut s’appliquer à une multitude de situations et de sujets, y compris à l’inspection TLS.
Le NetOps a besoin de défenseurs, pas d’adversaires
Il est important de reconnaître que les équipes NetOps ne sont pas toujours celles qui font obstacle au déploiement de la dernière nouveauté, application ou service. Les freins à la rapidité sont souvent dus au fait que les organisations n’adoptent pas tous les principes du DevOps lorsqu’elles cherchent à transformer leurs opérations informatiques.
Mise à jour des services applicatifs : sécurité, rapidité et visiteurs suspects
Il est de nouveau temps de nous pencher sur les services applicatifs que les entreprises utilisent réellement pour rendre leurs applications plus rapides et plus sûres. On constate notamment une hausse du recours aux services de protection contre les bots, ainsi que la progression lente mais régulière de HTTP/2. Bien qu’il ne s’agisse pas d’une application…
Les templates prennent le contrôle du cloud
Les modèles s’imposent dans le cloud. Lisez le blog de F5 pour découvrir comment l’infrastructure en tant que code et les API déclaratives automatisent la mise à disposition des applications.