Stratégies de prise en charge de la passerelle auto-hébergée

  • Article

S’APPLIQUE À : Développeur | Premium

Le service Gestion des API Azure, aux niveaux Développeur et Premium, permet le déploiement de la passerelle Gestion des API en tant que conteneur s’exécutant dans une infrastructure locale, d’autres clouds et des options d’infrastructure Azure qui prennent en charge les conteneurs. Cet article fournit des détails sur les stratégies de support technique et les limitations pour la passerelle auto-hébergée Gestion des API.

Important

La prise en charge des images conteneur de la passerelle auto-hébergée version 0 et version 1 d’Azure Gestion des API se termine le 1er octobre 2023, ainsi que son API de configuration correspondante v1. Utilisez notre guide de migration pour utiliser la passerelle auto-hébergée v2.0.0 ou une version ultérieure avec l’API de configuration v2. En savoir plus dans notre documentation de dépréciation

Différences entre la passerelle managée et la passerelle auto-hébergée

Lors du déploiement d’une instance du service Gestion des API, vous obtenez toujours une passerelle API managée dans le cadre du service. Cette passerelle s’exécute dans une infrastructure managée par Azure, et le logiciel est également managé et mis à jour par Azure.

Dans les niveaux de service pris en charge, la passerelle auto-hébergée est une option de déploiement facultative.

Bien que les passerelles managées et auto-hébergées partagent de nombreuses fonctionnalités communes, il existe également plusieurs différences.

Responsabilités

Le tableau suivant présente les responsabilités de Microsoft, les responsabilités partagées et les responsabilités des clients en matière de gestion et de prise en charge de la passerelle auto-hébergée.

Microsoft Azure Responsabilités partagées Clients
▪️ Point de terminaison de configuration (plan de gestion) : la passerelle auto-hébergée dépend d’un point de terminaison de configuration qui fournit la configuration, les API, les noms d’hôte et les informations de stratégie. Ce point de terminaison de configuration fait partie du plan de gestion de chaque service Gestion des API.

▪️ Maintenance et mises à jour des images conteneur de passerelle : correctifs de bogues, patches, améliorations des performances et nouvelles fonctionnalités dans l’image conteneur de la passerelle auto-hébergée.		 ▪ Sécurisation de la communication de la passerelle auto-hébergée avec le point de terminaison de configuration : la communication entre la passerelle auto-hébergée et le point de terminaison de configuration peut être sécurisée par deux mécanismes : un jeton d’accès qui expire automatiquement tous les 30 jours et doit être mis à jour pour les conteneurs en cours d’exécution ou l’authentification avec Microsoft Entra ID, qui ne nécessite pas d’actualisation des jetons.

▪ Maintenir la passerelle à jour : le client supervise la mise à jour régulière de la passerelle vers la dernière version et les dernières fonctionnalités. Microsoft fournira des images mises à jour avec de nouvelles fonctionnalités, des correctifs de bogues et des patches.		 ▪ Hébergement de passerelle : déploiement et exploitation de l’infrastructure de passerelle : machines virtuelles avec runtime de conteneur et/ou cluster Kubernetes.

▪ Configuration réseau : nécessaire pour maintenir la connectivité du plan de gestion et l’accès à l’API.

▪ SLA de passerelle : gestion de la capacité, mise à l’échelle et durée de bon fonctionnement.

▪ Fourniture de données diagnostics à prendre en charge : collecte et partage des données diagnostics avec les ingénieurs du support technique.

▪ Composants logiciels OSS tiers (logiciel open source) : la combinaison de la passerelle auto-hébergée avec d’autres logiciels tels que Prometheus, Grafana, les mailles de service, les runtimes de conteneur, les distributions Kubernetes et les proxys est de la responsabilité du client.

Couverture de prise en charge de l’image conteneur de passerelle auto-hébergée

Nous avons la stratégie d’étiquetage suivante pour l’image conteneur de la passerelle auto-hébergée, en suivant la convention de patch majeure et mineure : {major}.{minor}.{patch}. Vous pouvez consulter une liste complète des étiquettes disponibles. Comme meilleure pratique, nous recommandons aux clients d’exécuter la dernière version stable de notre image conteneur. Compte tenu des publications continues de notre image conteneur, nous fournirons une prise en charge officielle pour les versions suivantes :

Versions prises en charge

  • La dernière version majeure et les trois dernières versions mineures

    Par exemple, si la dernière version est 2.2.0, nous allons prendre en charge toutes les versions mineures 2.2.x, 2.1.x et 2.0.x. Pour toutes les versions précédentes, nous vous demanderons de mettre à jour vers une version prise en charge.

  • Correctifs

    Si nous découvrons un problème de bogue, de CVE ou de performance dans une version prise en charge (par exemple, un bogue est détecté dans l’image conteneur 2.0.0), le correctif sera corrigé en tant que patch dans la dernière version mineure, par exemple 2.2.x.

Versions non prises en charge

  • Images conteneur avec l’étiquette beta.

  • N’importe quelle version avec le suffixe preview.

Scénarios de prise en charge de la passerelle auto-hébergée

Microsoft fournit un support technique pour les exemples suivants

  • Durée de bon fonctionnement et configuration du point de terminaison de configuration et du plan de gestion pour les niveaux pris en charge.

  • Bogues d’image conteneur de la passerelle auto-hébergée, problèmes de performance et améliorations.

  • Les correctifs de sécurité des images conteneur de la passerelle auto-hébergée seront corrigés dès que possible.

  • Projets open source tiers pris en charge, par exemple : Open Telemetry et DAPR (Distributed Application Runtime).

Microsoft n’assure pas de support technique pour les exemples suivants

  • Questions sur l’utilisation de la passerelle auto-hébergée à l’intérieur de Kubernetes. Par exemple, le Support Microsoft ne fournit pas de conseils sur la façon dont les contrôleurs d’entrée doivent être créés, les mailles du service, l’utilisation des charges de travail d’application ou l’application d’outils ou de packages logiciels open source ou tiers.

  • Projets open source tiers combinés à notre passerelle auto-hébergée, à l’exception de projets pris en charge spécifiques, par exemple : Open Telemetry et DAPR (Distributed Application Runtime).

  • Logiciels close source tiers, y compris des outils d’analyse de sécurité et des logiciels ou appareils réseau.

  • Résolution des problèmes de personnalisations réseau, CNI, mailles de service, stratégies réseau, pare-feux et circuits réseau complexes. Microsoft ne vérifie que le fonctionnement de la communication entre la passerelle auto-hébergée et le point de terminaison de configuration.

Bogues et problèmes

Si vous avez des questions, posez-les aux experts de la communauté dans Microsoft Q&A.

Si vous disposez d’un plan de support et que vous avez besoin d’une aide technique, créez une demande de support :

  1. Pour Type de problème, sélectionnez Technique.

  2. Pour Abonnement, sélectionnez votre abonnement.

  3. Sous Service, sélectionnez Mes services, puis Service Gestion des API.

  4. Sous Ressource, sélectionnez la ressource Azure pour laquelle vous créez une demande de support.

  5. Pour Type de problème, sélectionnez Passerelle auto-hébergée.

Vous pouvez également obtenir de l’aide de nos communautés. Vous pouvez déposer un problème sur GitHub ou poser des questions sur Stack Overflow et utiliser l’étiquette « azure-api-management ».

Étapes suivantes