Comment Zoom utilise-t-il APISIX Ingress dans son pipeline de livraison continue ?
October 27, 2022
Contexte
Ces dernières années, de nombreux logiciels de conférence en ligne bien connus ont vu le jour avec le développement des réunions en ligne et du travail à distance. L'un des plus typiques, Zoom, est devenu un outil de réunion populaire pour le bureau à domicile, l'enseignement en ligne et les scénarios sociaux. Il compte 350 millions de participants quotidiens aux réunions et près de 470 000 clients professionnels payants utilisant la plateforme. De plus, des données récentes montrent que le nombre de minutes utilisées pour faciliter les réunions a atteint plus de 3,3 billions par an.
Cependant, comme d'autres entreprises SaaS et internet, Zoom a rencontré des défis techniques alors que son activité se développe rapidement.
-
Un nombre important de microservices : En raison de la croissance rapide des activités et des équipes de Zoom, plus de 100 services backend doivent être livrés. Cependant, il est difficile de gérer efficacement un grand nombre de microservices.
-
Divers environnements de déploiement : Les entreprises SaaS rencontrent souvent des scénarios où les clients doivent déployer sur des clouds dédiés, des clouds privés et des multi-clouds. Les services commerciaux de Zoom étant répartis dans le monde entier, il existe des défis techniques liés à un grand nombre d'environnements hybrides.
-
Infrastructure complexe : Les entreprises internet de taille moyenne et grande ont généralement des équipes d'infrastructure dédiées responsables des passerelles API, des centres de configuration, de la gestion des clés, des journaux, des alertes de surveillance, des bases de données, etc. Comme les équipes de R&D de Zoom sont réparties dans le monde entier, il est très difficile d'intégrer ces middleware et infrastructures complexes dans le pipeline de livraison continue.
Les défis ci-dessus ne sont pas une simple relation additive mais une relation multiplicative. En d'autres termes, la situation réelle est bien plus complexe. Cependant, les outils open-source que Zoom utilisait auparavant ne peuvent plus répondre aux exigences actuelles de Zoom. C'est pourquoi un pipeline de livraison continue fiable est si important.
Voici les raisons détaillées pour lesquelles Zoom n'a pas continué à utiliser ces outils open-source précédents.
Helm/Kustomize | Terraform/Pulumi | KubeVela + Crossplane |
---|---|---|
Impossible de connecter des systèmes autres que Kubernetes | Difficile d'utiliser Terraform dans les couches Kubernetes et middleware sans développer des Providers supplémentaires | Technologie trop récente avec des mises à jour rapides, pas assez sûre et stable pour être adoptée en environnement de production |
Difficile de contrôler centralement la plateforme en mode sous-répertoire Git | Augmente le coût d'apprentissage d'un autre langage de gestion de configuration : hcl | La définition de Trait + Cuelang de Kubevela et ses capacités d'expression de programmation ne suffisent pas à couvrir les diverses plateformes middleware non cloud-native en dehors du système Kubernetes |
Difficile à maintenir et à déboguer en raison de la logique complexe des modèles Helm Chart | Le mode de contrôle centralisé Mono Repo ne convient pas aux équipes volumineuses | / |
Système de paramètres peu puissant pour gérer les paramètres dynamiques dans un grand nombre d'environnements | / | / |
En raison des limitations des outils open-source ci-dessus, Zoom a finalement étudié certaines solutions principales pour construire le pipeline de livraison continue sous-jacent.
Après quelques tours de comparaison et de vérification, Zoom a finalement choisi APISIX Ingress Controller pour soutenir son nouveau pipeline de livraison continue.
Apache APISIX Ingress Controller
Qu'est-ce que Apache APISIX Ingress Controller ?
Apache APISIX Ingress Controller est un contrôleur d'entrée cloud-native qui utilise Apache APISIX comme plan de données pour transporter le trafic et étend les fonctionnalités de Kubernetes en utilisant CRD (CustomResourceDefinition). Il est responsable de l'interaction avec le serveur API Kubernetes, de la demande de contrôle d'accès basé sur les rôles (RBAC), de la surveillance des changements, de la mise en œuvre de la conversion d'objets dans le contrôleur Ingress, de la comparaison des changements, puis de la synchronisation avec Apache APISIX. De plus, il peut prendre en charge des ressources personnalisées, y compris APISIX Route, APISIX Upstream et d'autres entrées natives de Kubernetes, pour contrôler le trafic externe accédant aux services déployés dans Kubernetes.
Voici le Diagramme de séquence d'APISIX Ingress Controller.
Pourquoi Zoom choisit APISIX Ingress Controller ?
Selon le contexte ci-dessus, la question se pose : quel type de pipeline de livraison continue Zoom souhaite-t-il construire, et comment adopte-t-il APISIX Ingress pour établir son pipeline de livraison continue sous-jacent ?
Zoom utilisait auparavant NGINX comme passerelle API. Cependant, avec le développement rapide des activités et l'augmentation des microservices, les limites de la solution NGINX actuelle deviennent de plus en plus apparentes.
Différentes équipes doivent maintenir NGINX séparément, et des milliers de lignes de fichiers de configuration NGINX rendent la maintenance difficile. De plus, NGINX ne peut pas rapidement s'adapter lors du déploiement de nombreuses lignes sur le serveur cloud. Concernant le mode de rechargement de NGINX, vous pouvez consulter ce blog. Les activités de Zoom ont commencé à évoluer vers Ingress Controller.
L'équipe de la passerelle API a recherché certaines solutions open-source. Après une simulation de migration et une analyse de la configuration réelle des activités dans NGINX et un grand nombre de tests de référence de performance et de comparaison de l'écosystème des plugins, Zoom a finalement choisi le projet APISIX Ingress Controller de la Apache Software Foundation, explorant une passerelle Cloud-Native plus avancée.
En tenant compte de ses scénarios commerciaux, Zoom a accordé plus d'importance aux deux parties suivantes, qui peuvent être satisfaites par APISIX Ingress.
-
Sécurité des données : Zoom prend au sérieux la confidentialité des clients et la sécurité des services ; ainsi, l'authentification et la vérification mTLS sont largement utilisées dans les salles de réunion en ligne et les appels téléphoniques. Néanmoins, de nombreuses passerelles API similaires ne peuvent fournir un tel service que dans leur version entreprise, tandis que APISIX Ingress offre une grande faisabilité et commodité pour atteindre cet objectif.
-
Stabilité du service : Les services backend de Zoom nécessitent des déploiements Multi-AZ (Multi-Availability Zones) pour une haute disponibilité dans différentes régions. Généralement, il place les activités dans d'autres DC. Si une erreur se produit dans le DC d'origine, le trafic client doit être transféré vers un autre, ce que APISIX Ingress peut réussir à satisfaire.
Fonctionnalités d'Apache APISIX Ingress Controller
En prenant Apache APISIX comme plan de données pour transporter le trafic commercial, Apache APISIX Ingress Controller hérite des avantages suivants d'Apache APISIX.
-
Haute performance et stabilité : En tant que passerelle API open-source dynamique à haute performance, Apache APISIX est résilient et stable dans ses performances, étant utilisé dans de nombreux scénarios de trafic à grande échelle d'entreprises.
-
Communauté active : En tant que projet de passerelle API open-source de premier plan et le plus actif, Apache APISIX possède une communauté active et a maintenu un excellent taux de croissance depuis le premier jour.
-
Écosystème riche : Apache APISIX prend en charge les protocoles L7, y compris HTTP(S), HTTP2, Dubbo, le protocole IoT MQTT, etc. En outre, APISIX prend en charge les protocoles L4 tels que TCP/UDP. De plus, la prise en charge complète d'ARM64 est prise en charge dans Apache APISIX 3.0.
-
Multiples plugins : Il y a presque 100 plugins publiés par APISIX officiellement que les utilisateurs peuvent utiliser par simple glisser-déposer. Le rechargement à chaud et l'orchestration dynamique des plugins offrent une grande commodité aux utilisateurs.
En outre, l'APISIX Ingress Controller présente également les avantages uniques suivants :
-
Bonne compatibilité : APISIX Ingress Controller prend en charge plusieurs versions de ressources ingress et peut être compatible avec différentes versions de Kubernetes.
-
Mise à jour dynamique : Il n'est pas nécessaire de recharger le service lors de la modification des routes, des certificats et d'autres configurations, assurant le bon fonctionnement des activités.
-
Mise à l'échelle flexible : Comme l'APISIX Ingress Controller adopte une structure qui sépare le plan de contrôle et le plan de données, le cluster de plan de données d'Apache APISIX peut être étendu indépendamment sans mettre à l'échelle l'APISIX Ingress Controller.
- Convivial pour les opérations et la maintenance : Sous l'architecture actuelle, les utilisateurs peuvent choisir de déployer le cluster de plan de données APISIX dans le cluster Kubernetes ou dans l'environnement de machines physiques bare-metal selon la situation réelle. De plus, en raison de la séparation architecturale de l'ingress APISIX, l'APISIX sur le plan de données transporte le trafic tandis que l'APISIX ingress controller est le composant du plan de contrôle. Par conséquent, la défaillance de l'APISIX Ingress Controller n'aura aucun impact sur le trafic commercial.
Après la sélection de la passerelle, l'équipe de la passerelle API a été confrontée à un nouveau défi : comment migrer la configuration originale de la passerelle API de centaines de services vers APISIX Ingress ? L'équipe d'infrastructure de Zoom développait le pipeline de livraison continue, ce qui peut considérablement réduire le coût de migration de la conversion de nginx.conf et d'autres configurations Ingress vers APISIX Ingress.
Le processus et les fonctions de construction du pipeline de livraison continue
Le pipeline de livraison continue de Zoom
Le pipeline de livraison continue est un système de livraison d'applications de bout en bout qui met en œuvre un modèle unique pour déclarer toutes les exigences de livraison d'applications et organiser et exécuter toutes les étapes de livraison continue en une seule ligne.
Il y a six parties dans le pipeline de livraison continue :
-
Préparer : préparer les ressources prédéfinies, y compris l'infrastructure, les middleware, les ressources de services cloud, etc. ;
-
Configurer : préparer les fichiers de configuration et les clés nécessaires à l'application ;
-
Déployer : utiliser K8s pour le déploiement dans des scénarios cloud-native (y compris les informations sur les conteneurs, les images de conteneurs, les paramètres, les versions et les instances) ;
-
Accéder : créer un service Kubernetes et configurer automatiquement les règles de routage de l'Apache APISIX Ingress si le déploiement nécessite un accès externe ;
-
Observer : Effectuer des configurations liées à l'observabilité, telles que la surveillance, l'alerte, la journalisation et l'analyse de traçage ;
-
Mettre à l'échelle : Déclarer les règles de mise à l'échelle dynamique de KEDA (Kubernetes Event-driven Autoscaling) via des métriques de surveillance.
Comment adopter APISIX Ingress dans le pipeline
Gestion de projet
Les chefs de projet accordent plus d'attention aux itérations de R&D et à la manière de mieux gérer la progression des versions itératives et l'efficacité du personnel sur la chronologie correspondant aux itérations. Zoom utilise un workflow GitOps en interne pour intégrer la configuration de la passerelle API dans le modèle de livraison d'applications. Sous ce modèle, la définition des règles de routage APISIX est intégrée avec "Déployer" et d'autres liens, confiant le contrôle des changements à GitHub. Avec la création et la fusion des branches GitHub, le pipeline réalise une synchronisation des chronologies entre la publication et le retour en arrière des configurations d'application et de passerelle.
# Extrait de code du pipeline CD de Zoom dans le référentiel Git
deploy:
type: Deployment
replicas: ~{ replicas, 2 }
version: "latest"
containers:
- name: my-app
image: "busybox"
command: "echo 'Demo' && sleep 99d"
access:
- protocol: https
host: my-domain.my-org.com
cert: my-tls-cert
apisix:
routes:
http:
- name: my-api
authentication:
# ......
match:
paths:
- /my-api/*
De cette manière, la gestion des versions est simplifiée en gestion de workflow dans GitHub et résout le problème du décalage temporel entre les systèmes en amont et en aval correspondant aux changements lorsque plusieurs itérations sont traitées simultanément.
Développement d'applications
Les développeurs se concentrent principalement sur les capacités de routage et d'authentification des API, qui sont fortement liées aux services commerciaux et doivent être remplies par les développeurs pour obtenir un effet automatique. De plus, ils se concentrent sur le développement et la mise en œuvre des fonctions commerciales et des activités commerciales de niveau supérieur, espérant construire une infrastructure prête à l'emploi.
À partir des codes mentionnés ci-dessus, nous pouvons voir que les développeurs n'ont qu'à définir Authentication
et Match
dans ce pipeline de livraison continue. Ils n'ont pas besoin de connaître la logique sous-jacente :
- D'abord, traduire cela en Kubernetes Deployment et Service.
- Ensuite, appeler l'API de la plateforme pour vérifier la justesse du chemin.
- Enfin, traduire cela en objets ApisixRoute.
L'intégration de la configuration d'APISIX et du workflow du pipeline de livraison continue offre aux développeurs une manière plus efficace.
Gestion de l'environnement
Des exigences complexes de gestion et de contrôle de l'environnement se produisent souvent dans les scénarios toB, et les problèmes de livraison dans certains scénarios de cloud privé, cloud dédié et cloud hybride doivent être pris en compte.
Certaines configurations d'APISIX ingress ont été mises en œuvre pour répondre à l'exigence de masquer les différences environnementales. De cette manière, les gestionnaires de système peuvent contrôler de manière exhaustive les différences dans certains environnements hétérogènes. Tous les services déployés dans l'environnement sont efficaces, évitant la charge cognitive et les opérations de déploiement spéciales causées par les différences environnementales aux développeurs d'applications et d'opérations. Par exemple, Zoom peut utiliser une configuration personnalisée pour désactiver le traçage pour certains environnements, convertir les objets ApisixRoute en objets Ingress natifs et en annotation NGINX Ingress, et utiliser différentes images pour extraire les secrets.
De plus, l'isolation multi-locataire est nécessaire lorsque plusieurs lignes d'activité utilisent l'environnement APISIX. APISIX Ingress fournit un sélecteur d'annotation qui permet à différents objets ApisixRoute d'être récupérés par différentes instances de l'APISIX Ingress Controller.
Gestion de l'infrastructure
L'équipe de la passerelle API doit contrôler toutes les instances APISIX, configurer les politiques de sécurité de manière exhaustive, mettre en œuvre des zones de disponibilité multiples, etc.
Chaque plugin du pipeline fournit des éléments de configuration pour les ingénieurs d'infrastructure. Dans le plugin ingress-apisix
, il y a une propriété defaultPlugins
.
Après que l'équipe de la passerelle API configure cette propriété, le paramètre prendra effet pour tous les services, ce qui convient à une stratégie unifiée de sécurité et de contrôle des risques.
Conclusion
APISIX Ingress Controller joue un rôle important dans le pipeline de livraison continue de Zoom, libérant la pression sur la gestion de projet, le développement d'applications, la gestion de l'environnement et la gestion des middleware et de l'infrastructure. Le cas de Zoom mérite d'être étudié par d'autres entreprises, et nous espérons qu'APISIX Ingress Controller contribuera à l'innovation de plus d'entreprises.
De plus, Apache APISIX Ingress a officiellement publié V1.5 en août 2022, qui unifie la proposition de toutes les ressources API Versions et met à niveau toutes les versions d'API CRD à V2. En même temps, il prend en charge la plupart des ressources de l'API Gateway. Apache APISIX Ingress a permis aux ressources Ingress d'utiliser des plugins APISIX arbitraires en ajoutant une nouvelle annotation "k8s.apisix.apache.org/plugin-config-name" aux ressources Ingress. De cette manière, cela augmentera considérablement la facilité d'utilisation de l'APISIX Ingress Controller et réduira le coût pour les utilisateurs de migrer d'autres contrôleurs Ingress vers APISIX Ingress Controller.
Pour plus d'informations, veuillez consulter Apache APISIX Ingress V1.5.