Gestion de configuration plus sûre avec NGINX Controller

En discutant avec nos clients au cours de l'année écoulée, nous avons remarqué quelques thèmes récurrents qui les motivent à évaluer des produits d'orchestration tels que NGINX Controller :

• Complexité – Gérer, maintenir, valider et appliquer de grands ensembles d’objets de configuration individuels provenant de différentes sources n’est pas facile.
• Fragilité – La mise à l’échelle peut se produire rapidement, souvent en réponse à un événement. Parfois, c'est stratégique, mais comme c'est souvent le cas dans tous les services opérationnels, c'est imprévu et organique.
• Sécurité – Éviter les erreurs et détecter les problèmes avant le déploiement en production sont les pierres angulaires de la méthodologie agile. Ils contribuent également à atténuer la complexité et la fragilité.

Ce ne sont pas les préoccupations auxquelles les clients sont généralement confrontés lors du premier déploiement d’une application. Au contraire, ils apparaissent à mesure que le temps passe et que l’application devient un succès et doit être étendue. Nous constatons que la mise à l’échelle – ou plus précisément, la mise à l’échelle non planifiée – est la cause profonde commune des problèmes énumérés ci-dessus.

Heureusement, le modèle d’objet de configuration du contrôleur NGINX répond à ces trois préoccupations :

• Il réduit la complexité du déploiement en rassemblant dans un seul emplacement tous les composants de configuration susceptibles d'avoir un impact sur un ensemble spécifique d'instances NGINX Plus .
• Il réduit la fragilité en permettant aux équipes de valider et de tester les configurations avant de les mettre en production, ce qui facilite les échecs rapides et garantit que le trafic des utilisateurs de production continue de circuler.
• Il favorise la sécurité car il est très flexible. Au lieu de vous forcer à ajuster vos processus pour qu'ils correspondent au modèle, le modèle d'objet de configuration est conçu pour s'aligner sur vos flux de travail d'entreprise et la répartition des responsabilités. Vous pouvez accorder à diverses unités commerciales la propriété appropriée sur les éléments de configuration, selon le cas.

Objets de configuration du contrôleur

Plongeons un peu plus en profondeur dans certains objets de configuration clés pour vous donner une meilleure idée du fonctionnement du modèle de contrôleur.

Environnements

Dans la plupart des organisations, les logiciels passent par plusieurs étapes avant d’être publiés : développement, acceptation par l’utilisateur, préproduction, production et autres étapes de contrôle qualité. Ces étapes correspondent à l’objet NGINX Controller appelé Environnement.

Un environnement est une zone d'isolement pour les éléments de configuration dans le contrôleur. Il s’agit généralement du niveau auquel le contrôle d’accès basé sur les rôles (RBAC) est défini. Les environnements peuvent transporter des artefacts de configuration identiques à travers les différentes étapes tout en remplaçant des modifications minimales par des éléments tels que les serveurs cibles, les centres de données et d'autres objets d'infrastructure qui diffèrent généralement entre les environnements.

Passerelles

Une passerelle est un objet de configuration au sein d'un environnement, souvent utilisé comme niveau supérieur pour définir la manière dont les applications sont fournies aux clients – paramètres tels que le nom d'hôte, le protocole et le comportement TLS/SSL – bien que ces paramètres puissent également être définis à un niveau inférieur. Dans la pratique, les équipes d’opérations réseau (NetOps), les personnes qui gèrent les appareils réseau périphériques ou la DMZ, possèdent le plus souvent des objets Gateway. Les passerelles utilisent également le concept de « Placement », qui permet de lier le contrôleur et les instances NGINX Plus qui reçoivent les configurations et effectuent le travail réel.

Applications

Le niveau inférieur est l’objet de configuration d’application, où vous commencez à modéliser des applications et à regrouper les comportements de mise en forme du trafic. Vous pouvez utiliser autant d'applications que nécessaire pour répondre aux besoins de votre organisation. La seule exigence est qu’une application doit être unique dans un environnement.

Composants

Au sein d'une application, les composants décrivent le comportement de gestion du trafic souhaité pour l'application. Dans le cas le plus simple, tout le trafic pour un chemin d'accès donné est envoyé au même groupe de serveurs. Mais les composants contrôlent également des formes plus avancées comme la manipulation d'en-têtes, la réécriture d'URL, les comportements d'équilibrage de charge du back-end, la gestion des cookies et d'autres paramètres. Le nom d'hôte et le comportement TLS/SSL peuvent également être définis à ce niveau.

Relier les choses ensemble

Voici une représentation visuelle de la relation entre les objets de configuration :

Notez qu'il n'y a que deux groupes qui interagissent avec le contrôleur - dans ce cas, deux équipes de développement, Référencement et Transferts . En réalité, nous savons que le nombre de personnes impliquées dans la livraison et la sécurité des applications est probablement beaucoup plus important, couvrant la mise en réseau et la sécurité (Platform Ops), DevOps, le développement d'applications, etc. Les équipes disposant du plus de connaissances peuvent définir des politiques et créer des flux de travail en libre-service qui s'alignent sur les meilleures pratiques et fournissent des garde-fous aux équipes travaillant avec des applications, des composants et des passerelles dans l'environnement « Dev » qui couvre les sites des centres de données Est et Ouest de l'organisation.

Regardons cela d’une manière légèrement différente, davantage du point de vue d’un secteur d’activité (LOB) . Les propriétaires de LOB prennent de plus en plus de décisions d'application pour les applications modernes.

Le diagramme suivant illustre un scénario plus réaliste qui inclut un pool d’utilisateurs beaucoup plus large comprenant diverses équipes LOB et Shawn, la personne qui gère tous les renouvellements de certificats.

Nous avons désormais davantage d’acteurs et de pipelines individuels qui impactent le flux de données résultant.

À mesure que chaque pipeline individuel traverse les différentes modifications d'objet du contrôle de source (comme GitHub) vers le contrôleur, les objets de configuration sont validés côté contrôleur, puis combinés avec tous les objets associés avant que les modifications ne soient transmises aux instances NGINX Plus.

C'est ainsi que Controller peut contribuer à rendre la gestion de la configuration plus sûre – en garantissant que les dernières modifications sont compatibles avec les paramètres précédents et les paramètres d'autres propriétaires d'applications et de secteurs d'activité.

Nous sommes conscients qu’en pratique, toutes les configurations appliquées à une seule instance NGINX Plus doivent être possibles, mais les paramètres ne doivent pas être en conflit, se chevaucher ou se heurter les uns aux autres. Il est également important de détecter les conflits en amont et d’informer les personnes qui fournissent la configuration de chaque composant individuel.

Dans l'exemple ci-dessus, lorsque le composant de référence tente d'utiliser le même modèle d'expression régulière que le composant de transfert déjà implémenté, un conflit de chemin est immédiatement détecté et l'équipe de référence peut être avertie bien avant de tenter de déployer cette configuration en production, évitant ainsi les nombreux maux de tête associés à une mauvaise configuration.

En ce qui concerne les certificats, Shawn est autorisé – via la fonctionnalité RBAC du contrôleur – à mettre en œuvre immédiatement les modifications de certificat. Les responsables de la passerelle et des composants n'ont besoin que de référencer les certificats corrects et Shawn peut les gérer en toute confiance sur leur propre cycle de vie. Si Shawn met à jour un certificat dans Controller, il est envoyé vers les instances appropriées, sans la panique associée à l'expiration d'un certificat.

Maintenant que NGINX Controller dispose de tous vos objets de configuration et d'une association de placement avec une ou plusieurs instances NGINX Plus, il peut effectuer les dernières étapes : appliquer la configuration.

La sécurité dans la pratique

En fin de compte, l’objectif de la gestion de la configuration avec Controller est d’appliquer la configuration correcte sur les instances NGINX Plus correctes au bon emplacement – en garantissant que les applications, les composants, les passerelles et tous les certificats et instances associés sont correctement configurés, ce qui se traduit par des déploiements plus sûrs et plus évolutifs.

Cette vérification finale est la dernière partie du processus de gestion de la configuration que Controller rend plus simple et plus sûr. L'ensemble de la configuration est vérifié lors de son application à une instance NGINX Plus qui a subi une modification d'objet associée, comme la persistance de session dans un groupe de charge de travail Web pour NGINX Plus déployé en tant que proxy, garantissant ainsi que l'instance est compatible avec la configuration souhaitée. Si cette condition est remplie, la configuration est appliquée. Et pour plus de sécurité, si quelque chose échoue lors de l'application de la configuration, le contrôleur revient à une configuration précédente.

En plus de garantir que les configurations sont conformes, Controller peut également tirer parti des fonctionnalités NGINX avancées, telles que le drainage de session, lorsqu'une nouvelle configuration est appliquée – garantissant ainsi que les sites maintiennent la disponibilité et les performances malgré les modifications.

Pour les équipes d’exploitation, les concepts et les conceptions de flux de travail décrits ci-dessus contribuent à la sécurité offerte par NGINX Controller en matière de gestion de la configuration. Ces mesures de protection aident à aligner les flux de travail et les différentes équipes qui travaillent avec des applications modernes, tout en répondant aux besoins de l’entreprise.

Pour essayer NGINX Controller, démarrez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .