Tutoriel : haute disponibilité des passerelles API dans les environnements multicloud et hybrides

NGINX | 20 décembre 2022

Les déploiements multicloud sont désormais incontournables. Selon le rapport State of Application Strategy in 2022 de F5, 77 % des entreprises exploitent des applications dans plusieurs clouds. L’adoption d’architectures multicloud et hybrides offre des avantages importants, tels qu’une efficacité accrue, une réduction du risque de pannes et l’absence de dépendance vis-à-vis d’un fournisseur. Toutefois, ces architectures complexes présentent également des défis spécifiques.

Les responsables des logiciels et de l’informatique interrogés par F5 ont cité les principaux défis suivants liés au multicloud :

  • Visibilité (45 % des personnes interrogées)
  • Sécurité (44 %)
  • Migration des applications (41 %)
  • Optimisation des performances (40 %)

La gestion des API pour les microservices dans des environnements multicloud est particulièrement complexe. En l’absence d’une stratégie globale en matière d’API, celles-ci prolifèrent dans les environnements de cloud public, sur site et en périphérie plus rapidement que les équipes chargées des opérations de plateforme ne peuvent les sécuriser et les gérer. Nous appelons ce problème la prolifération des API et, dans un précédent article nous avons expliqué pourquoi il constitue une menace si importante.

Vous avez besoin d’une stratégie d’API multicloud afin de mettre en œuvre une approche réfléchie pour unifier vos microservices, désormais répartis sur plusieurs clouds, et garantir une connectivité de bout en bout. Voici deux scénarios courants de déploiement multicloud et hybride :

  • Différents services dans des environnements multicloud/hybrides – Vous devez exploiter différentes applications et API à différents endroits, éventuellement pour optimiser les coûts ou parce que certains services sont destinés à différents groupes d’utilisateurs.
  • Mêmes services dans des environnements multicloud/hybrides – Vous devez garantir une haute disponibilité pour les mêmes applications déployées sur différents sites.

Dans le tutoriel suivant, nous vous expliquons étape par étape comment utiliser API Connectivity Manager, qui fait partie de F5 NGINX Management Suite, dans le deuxième scénario : déployer les mêmes services dans plusieurs environnements afin d’assurer une haute disponibilité. Cela permet d’éliminer tout point de défaillance unique dans votre environnement de production multicloud ou hybride : si une instance de passerelle tombe en panne, une autre prend le relais et vos clients ne subissent aucune interruption de service, même en cas de panne de l’un des clouds.

API Connectivity Manager est une solution cloud native indépendante de l’environnement d’exécution, qui permet de déployer, de gérer et de sécuriser les API. Depuis une interface unique, vous pouvez gérer toutes les opérations liées aux API pour les passerelles d’API NGINX Plus et les portails de développeurs déployés dans des environnements de cloud public, sur site et en périphérie. Vos équipes chargées des opérations de plateforme bénéficient ainsi d’une visibilité complète sur le trafic des API et peuvent facilement appliquer des politiques cohérentes de gouvernance et de sécurité dans chaque environnement.

Activation de la haute disponibilité pour les passerelles d’API dans un déploiement multicloud

Comme indiqué dans l’introduction, ce tutoriel explique comment configurer API Connectivity Manager afin d’assurer la haute disponibilité de services exécutés dans plusieurs environnements de déploiement. Plus précisément, nous déployons NGINX Plus en tant que passerelle d’API pour acheminer le trafic vers deux services, Service A et Service B, qui s’exécutent dans deux clouds publics, Google Cloud Platform (GCP) et Amazon Web Services (AWS). (Cette configuration s’applique également à toute combinaison d’environnements de déploiement, notamment Microsoft Azure et les centres de données sur site.)

La figure 1 illustre la topologie utilisée dans ce tutoriel.

Topologie dans laquelle un client accède à des passerelles d’API à haute disponibilité déployées sur deux clouds
Figure 1 : API Connectivity Manager permet le déploiement hautement disponible multicloud de passerelles API et de services

Suivez les étapes décrites dans ces sections pour terminer le tutoriel :

Installer et configurer API Connectivity Manager

  1. Souscrivez à une version d’essai ou à un abonnement payant de NGINX Management Suite, qui comprend Instance Manager et API Connectivity Manager, ainsi que NGINX Plus comme passerelle d’API et NGINX App Protect pour sécuriser vos API. Commencez par un essai gratuit de 30 jours de NGINX Management Suite.
  2. Installez NGINX Management Suite. Dans la section « Installer les modules de Management Suite », suivez les instructions relatives à API Connectivity Manager (et, éventuellement, à d’autres modules).
  3. Ajoutez la licence pour chaque module installé.
  4. (Facultatif.) Configurez la terminaison TLS et le mTLS afin de sécuriser respectivement les connexions clientes à NGINX Management Suite et le trafic entre API Connectivity Manager et les instances NGINX Plus sur le plan de données.

Déployer des instances NGINX Plus en tant que passerelles d’API

Sélectionnez les environnements qui composent votre infrastructure multicloud ou hybride. Pour ce tutoriel, nous avons choisi AWS et GCP et installons une instance NGINX Plus dans chaque cloud. Dans chaque environnement, effectuez les étapes suivantes sur chaque hôte du plan de données qui fera office de passerelle API :

  1. Installez NGINX Plus sur un système d’exploitation pris en charge.
  2. Installez le module JavaScript NGINX (njs).
  3. Ajoutez les directives suivantes dans le contexte principal (de niveau supérieur) dans « /etc/nginx/nginx.conf » :
load_module modules/ngx_http_js_module.so;load_module modules/ngx_stream_js_module.so;
  1. Redémarrez NGINX Plus, par exemple en exécutant cette commande :
$ nginx -s reload

Configurer un espace de travail d’infrastructure

Vous pouvez créer plusieurs espaces de travail d’infrastructure (jusqu’à 10 au moment de la rédaction de ce document) dans API Connectivity Manager. En séparant les espaces de travail, vous pouvez appliquer des stratégies et des exigences d’authentification/d’autorisation propres à différents secteurs d’activité, équipes de développement, partenaires externes, clouds, etc.

Dans l’interface graphique d’API Connectivity Manager, créez un nouvel espace de travail :

  1. Cliquez sur « Infrastructure » dans la colonne de navigation de gauche.
  2. Cliquez sur le bouton «  + Créer » pour créer un nouvel espace de travail, comme illustré à la figure 2.
    Figure 2 : Création d’un nouvel espace de travail Infrastructure
  3. Dans le panneau Créer un espace de travail qui s’ouvre, renseignez le champ Nom (demo dans la figure 3). Vous pouvez également renseigner le champ Description ainsi que les champs de la section Coordonnées de l’espace de travail. L’administrateur de l’infrastructure (votre équipe chargée des opérations de la plateforme, par exemple) peut utiliser ces coordonnées pour informer les utilisateurs de l’espace de travail de son état ou d’éventuels problèmes.
    Figure 3 : Attribution d’un nom à un nouvel espace de travail d’infrastructure et ajout de coordonnées
  4. Cliquez sur le bouton « Créer ».

Créer un environnement et des clusters de passerelle API

Dans API Connectivity Manager, un environnement est un regroupement logique de ressources dédiées (telles que des passerelles d’API ou des portails pour développeurs d’API). Vous pouvez créer plusieurs environnements par espace de travail (jusqu’à 25 au moment de la rédaction) ; ils correspondent généralement aux différentes étapes du développement et du déploiement d’applications, telles que le codage, les tests et la production, mais vous pouvez les utiliser à toutes les fins souhaitées.

Au sein d’un environnement, un cluster de passerelles API est un regroupement logique d’instances NGINX Plus faisant office de passerelles API. Un même environnement peut comporter plusieurs clusters de passerelles API partageant le même nom d’hôte (par exemple, api.nginx.com, comme dans ce tutoriel). Les instances NGINX Plus d’un cluster de passerelles API peuvent être hébergées sur plusieurs types d’infrastructures, par exemple dans plusieurs clouds.

Il existe deux façons de configurer un environnement dans API Connectivity Manager afin d’assurer la haute disponibilité active-active des passerelles d’API :

La principale raison de déployer plusieurs clusters API Gateway est de pouvoir appliquer un ensemble distinct de politiques de sécurité à chaque cluster.

Dans Déployer des instances NGINX Plus en tant que passerelles d’API, nous avons déployé deux instances NGINX Plus : l’une dans AWS et l’autre dans GCP. Le tutoriel utilise les mêmes instances pour illustrer les deux types d’environnement (avec un seul cluster de passerelles d’API ou avec plusieurs clusters de passerelles d’API). Si vous souhaitez déployer les deux types d’environnement dans un même espace de travail, vous devrez créer des instances NGINX Plus supplémentaires pour le second environnement.

Déployer un environnement avec un seul cluster de passerelles API

Pour un environnement doté d’un seul cluster de passerelles API, les mêmes politiques de sécurité s’appliquent à toutes les instances de passerelle API NGINX Plus, comme illustré à la figure 4.

Schéma montrant comment les mêmes politiques de sécurité s’appliquent aux passerelles d’API déployées dans un même cluster de passerelles d’API dans API Connectivity Manager
Figure 4 : les mêmes politiques de sécurité s’appliquent aux passerelles d’API déployées dans un même cluster de passerelles d’API

Créer un environnement et un cluster de passerelles API
  1. Accédez à votre espace de travail et cliquez sur le bouton Créer un environnement, comme illustré à la figure 5.
    Figure 5 : Création d’un environnement dans un espace de travail d’infrastructure
  2. Dans le panneau « Créer un environnement » qui s’ouvre, renseignez le champ « Nom » (« prod » dans la figure 6) et, si vous le souhaitez, le champ « Description », puis sélectionnez le type d’environnement (ici, nous choisissons « Production »).
    Figure 6 : Attribution d’un nom à un nouvel environnement et association de celui-ci à un cluster de passerelles API
  3. Dans la section « Clusters de passerelles API », renseignez les champs « Nom » et « Nom d’hôte » (api-cluster et api.nginx.com dans la figure 6).
  4. Cliquez sur le bouton « Créer ». Le panneau « Environnement créé » s’ouvre et affiche la commande à exécuter sur chaque instance NGINX Plus pour l’affecter au cluster de passerelles API. Pour plus de commodité, ces commandes sont indiquées à l’étape 7 ci-dessous.
Affecter des instances de passerelle API à un cluster de passerelles API

Répétez l’opération sur chaque instance NGINX Plus :

  1. Utilisez ssh pour vous connecter à l’instance.
  2. Si NGINX Agent est déjà en cours d’exécution, arrêtez-le :
$ systemctl stop nginx-agent
  1. Exécutez la commande de votre choix (soit « curl », soit « wget ») pour télécharger et installer le paquet NGINX Agent :
$ curl [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <cluster_name> && sudo systemctl start nginx-agent
  1. ou
$ wget [--no-check-certificate] https://<NMS_FQDN>/install/nginx-agent --no-check-certificate -O install.sh && sudo sh install.sh -g <cluster_name> && sudo systemctl start nginx-agent
  1. Les instances NGINX Plus apparaissent désormais dans la section « Instances » de la fenêtre « Cluster » pour « api-cluster », comme illustré à la figure 7.
    Figure 7 : un seul cluster de passerelles API regroupe les instances NGINX Plus déployées dans plusieurs clouds
    • Si vous n’avez pas activé mTLS dans Installer et configurer API Connectivity Manager, ajoutez :
      • L’option ‑k de la commande curl command
      • L’option « --no-check-certificate » de la commande wget command
    • Pour <NMS_FQDN>, indiquez l’adresse IP ou le nom de domaine complet de votre serveur NGINX Management Suite.
    • Pour <cluster_name>, indiquez le nom du cluster de passerelle API (api-cluster dans ce tutoriel).
  2. Passez à l’étape « Appliquer des stratégies globales ».

Déployer un environnement avec plusieurs clusters de passerelles API

Pour un environnement comportant plusieurs clusters de passerelles API, différentes politiques de sécurité peuvent s’appliquer à différentes instances de passerelle API NGINX Plus, comme illustré à la figure 8.

Schéma montrant comment différentes politiques de sécurité peuvent s’appliquer aux passerelles d’API déployées dans des clusters de passerelles d’API distincts dans API Connectivity Manager
Figure 8 : différentes politiques de sécurité peuvent s’appliquer aux passerelles d’API déployées dans
des clusters de passerelles d’API distincts

Créer un environnement et un cluster de passerelles API
  1. Accédez à votre espace de travail et cliquez sur le bouton Créer un environnement, comme illustré à la figure 9.
    Figure 9 : Création d’un environnement dans un espace de travail d’infrastructure
  2. Dans le panneau Créer un environnement qui s’ouvre, renseignez le champ Nom (prod dans la figure 10) et, si vous le souhaitez, le champ Description, puis sélectionnez le type d’environnement (ici, nous choisissons Production).
    Figure 10 : Attribution d’un nom à un nouvel environnement et affectation du premier cluster de passerelles API à celui-ci
  3. Dans la section « Clusters de passerelles API », renseignez les champs « Nom » et « Nom d’hôte » (dans la figure 10, il s’agit de « aws-cluster » et « api.nginx.com »).
  4. Cliquez sur le bouton « Créer ». Le panneau « Environnement créé » s’ouvre et affiche la commande à exécuter sur chaque instance NGINX Plus pour l’affecter au cluster de passerelles API. Pour plus de commodité, ces commandes sont indiquées à l’étape 10 ci-dessous.
  5. Revenez à l’onglet « Environnement » et cliquez sur le bouton «  + Ajouter » dans le coin supérieur droit de la section « Clusters de passerelles API », comme illustré à la figure 11.
    Figure 11 : ajout d’un autre cluster de passerelles API à un environnement
  6. Dans le panneau Créer un cluster de passerelles API, saisissez dans le champ Nom le nom du deuxième cluster (gcp-cluster dans la figure 12) et dans le champ Nom d’hôte le même nom d’hôte que pour le premier cluster (api.nginx.com).
    Figure 12 : Ajout du deuxième cluster de passerelles API à un environnement

Les deux clusters de passerelles API apparaissent désormais dans la section « Clusters de passerelles API » de l’environnement « Prod », comme illustré à la figure 13.

Figure 13 : Liste des instances NGINX Plus déployées dans plusieurs clouds et dans des clusters de passerelles API distincts

Affecter des instances de passerelle API à un cluster de passerelles API

Répétez l’opération sur chaque instance NGINX Plus :

  1. Utilisez ssh pour vous connecter à l’instance.
  2. Si NGINX Agent est déjà en cours d’exécution, arrêtez-le :
$ systemctl stop nginx-agent
  1. Exécutez la commande de votre choix (soit « curl », soit « wget ») pour télécharger et installer le paquet NGINX Agent :
$ curl [-k] https://<NMS_FQDN>/install/nginx-agent > install.sh && sudo sh -install.sh -g <cluster_name> && sudo systemctl start nginx-agent
  1. ou
$ wget [--no-check-certificate] https://<NMS_FQDN>/install/nginx-agent --no-check-certificate -O install.sh && sudo sh install.sh -g <cluster_name> && sudo systemctl start nginx-agent
  1. L’instance NGINX Plus appropriée apparaît désormais dans la section Instances des fenêtres Cluster pour aws‑cluster (figure 14) et gcp‑cluster (figure 15).
    Figure 14 : Le premier des deux clusters de passerelles API d’un environnement multicloud
    Figure 15 : Le second des deux clusters de passerelles API d’un environnement multicloud Appliquer des politiques globales Vous pouvez désormais ajouter des politiques globales qui s’appliquent à toutes les instances NGINX Plus d’un cluster de passerelles API. Par exemple, pour sécuriser l’accès des clients à vos API, vous pouvez appliquer la politique Partie utilisatrice OpenID Connect ou TLS entrant. Pour sécuriser la connexion entre une passerelle API et le service backend qui expose l’API, appliquez la politique TLS backend. Pour plus d’informations sur les politiques TLS, consultez la documentation d’API Connectivity Manager. Conclusion La gestion des architectures multicloud et hybrides n’est pas une tâche facile. Il s’agit d’environnements complexes, composés d’applications qui évoluent rapidement et qui sont souvent difficiles à observer et à sécuriser. Toutefois, avec les bons outils, vous pouvez éviter la dépendance vis-à-vis d’un fournisseur tout en conservant l’agilité et la flexibilité nécessaires pour commercialiser plus rapidement de nouvelles fonctionnalités. En tant qu’outil cloud natif, API Connectivity Manager de NGINX vous offre l’évolutivité, la visibilité, la gouvernance et la sécurité dont vous avez besoin pour gérer les API dans des environnements multicloud et hybrides. Commencez un essai gratuit de 30 jours de NGINX Management Suite, qui inclut l’accès à API Connectivity Manager, à NGINX Plus en tant que passerelle API et à NGINX App Protect pour sécuriser vos API.
    • Si vous n’avez pas activé mTLS dans « Installer et configurer API Connectivity Manager », ajoutez :
      • L’option « ‑k » de la commande curl command
      • L’option « --no-check-certificate » de la commande « wget »
    • Pour <NMS_FQDN>, indiquez l’adresse IP ou le nom de domaine complet de votre serveur NGINX Management Suite.
    • Pour <cluster_name>, indiquez le nom du cluster de passerelle API approprié (dans ce tutoriel, aws‑cluster pour l’instance déployée dans AWS et gcp‑cluster pour l’instance déployée dans GCP).
  1. Accédez à l’onglet « Cluster » de l’API Gateway à laquelle vous souhaitez appliquer une politique (api-cluster dans la figure 16). Cliquez sur le bouton « Manage » situé au-dessus du coin supérieur droit du tableau « Policies ».
    Figure 16 : gestion des politiques d’un cluster API Gateway
  2. Cliquez sur « Politiques globales » dans la colonne de navigation de gauche, puis sur l’icône « … » dans la colonne la plus à droite de la ligne correspondant à la politique (« Backend TLS » dans la figure 17). Sélectionnez « + Ajouter une politique » dans le menu déroulant.
    Figure 17 : Ajout d’une politique globale à un cluster API Gateway


Partager

À propos de l’auteur

Akash Ananthanarayanan
Akash AnanthanarayananResponsable marketing technique | F5 NGINX

Autres articles de Akash Ananthanarayanan

Articles de blog associés

Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
NGINX | 13/10/2025

Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA

Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.

Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
NGINX | 03/11/2023

Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?

Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.

Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
NGINX | 11/03/2020

Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX

Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.

Un testeur d’expressions régulières pour NGINX et NGINX Plus
NGINX | 11/06/2019

Un testeur d’expressions régulières pour NGINX et NGINX Plus

Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.

Caches partagés avec les clusters de cache NGINX Plus, partie 1
NGINX | 24/01/2017

Caches partagés avec les clusters de cache NGINX Plus, partie 1

Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.

Introduction aux microservices
NGINX | 19/05/2015

Introduction aux microservices

Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.