Utilisation du DNS pour la découverte de services avec NGINX et NGINX Plus

[Éditeur – Ce message a été mis à jour pour faire référence à l’ API NGINX Plus , qui remplace et déprécie le module de configuration dynamique distinct mentionné dans la version originale du message.]

L’un des grands avantages d’une architecture de microservices est la rapidité et la facilité avec lesquelles vous pouvez faire évoluer les instances de service. Avec plusieurs instances de service, vous avez besoin d'un équilibreur de charge et d'un moyen de l'informer rapidement des modifications apportées à l'ensemble des instances de service disponibles. C'est ce qu'on appelle la découverte de services . NGINX Plus propose deux options d'intégration avec les systèmes de découverte de services : l' API NGINX Plus et la résolution du système de noms de domaine (DNS) . Cet article de blog se concentre sur ce dernier point.

Lorsque vous faites évoluer des instances de service (nous les appellerons backends dans cet article de blog) en ajoutant ou en supprimant des machines virtuelles (VM) ou des conteneurs, la configuration de l'équilibreur de charge doit être modifiée pour refléter chaque modification apportée à l'ensemble des backends. La mise à l’échelle peut se produire plusieurs fois par jour, par heure ou même par minute, selon l’application. Étant donné la fréquence élevée des modifications de configuration, elles doivent être automatisées, et l’un des moyens d’y parvenir est la découverte de services via DNS.

De nombreuses plateformes sur lesquelles vous exécutez vos applications aujourd’hui, telles que Kubernetes , prennent en charge la découverte de services à l’aide de DNS. Nous fournissons des liens à la fin de cet article de blog vers des articles expliquant comment intégrer NGINX Plus avec des plates-formes populaires et des outils de découverte de services qui utilisent DNS.

Un aperçu rapide des principales fonctionnalités DNS

Avant d’expliquer comment configurer la découverte de services via DNS, examinons rapidement certaines fonctionnalités du protocole DNS qui sont particulièrement pertinentes ou pratiques.

Durée de vie

Pour empêcher les clients DNS d’utiliser des informations obsolètes, les enregistrements DNS incluent le champ durée de vie (TTL) pour définir la durée pendant laquelle les clients peuvent considérer l’enregistrement comme valide. Pour se conformer aux normes DNS , les clients doivent interroger le serveur DNS pour obtenir une mise à jour lorsqu'un enregistrement dépasse sa durée de vie. NGINX Plus respecte le TTL par défaut, mais offre également un contrôle plus précis sur la « durée de vie » d'un enregistrement. Vous pouvez configurer NGINX Plus pour ignorer les TTL et mettre à jour les enregistrements à une fréquence spécifiée. (Nous discuterons de la manière dont NGINX Open Source gère le TTL plus tard dans l'article.)

DNS sur TCP

Par défaut, les clients et serveurs DNS communiquent via UDP, mais si un nom de domaine correspond à un grand nombre d'adresses IP principales, la réponse complète risque de ne pas tenir dans un seul datagramme UDP, qui est limité à 512 octets. L'utilisation de TCP au lieu d'UDP résout ce problème : lorsqu'un ensemble complet d'enregistrements ne tient pas dans un datagramme, le serveur définit un indicateur de troncature dans sa réponse, qui indique au client de passer à TCP pour obtenir tous les enregistrements. DNS sur TCP est pris en charge dans NGINX version 1.9.11 et versions ultérieures, ainsi que dans NGINX Plus R9 et versions ultérieures. Pour plus de détails, consultez Équilibrage de charge du trafic DNS avec NGINX et NGINX Plus sur notre blog.

Enregistrements SRV

Le DNS résout les noms d’hôtes en adresses IP, mais qu’en est-il des numéros de port ? Il existe certains cas, par exemple lors de l'équilibrage de charge des conteneurs Docker, où vous ne pouvez pas vous fier à des numéros de port connus, car ces derniers sont attribués de manière dynamique. Le DNS dispose d'un type d'enregistrement spécial, l' enregistrement de service ( SRV ) , qui inclut les numéros de port et quelques autres paramètres. Dans R9 et versions ultérieures, NGINX Plus prend en charge les enregistrements SRV (et peut donc en extraire des informations de port).

Éditeur – Pour un aperçu de toutes les nouvelles fonctionnalités de NGINX Plus R9, consultez Annonce de NGINX Plus R9 sur notre blog.

Méthodes de découverte de services avec DNS pour NGINX et NGINX Plus

Nous allons maintenant vous montrer cinq façons d’utiliser DNS pour la découverte de services dans NGINX et NGINX Plus, par ordre de sophistication croissante. Les trois premiers sont disponibles dans NGINX et NGINX Plus, et les deux derniers dans NGINX Plus uniquement.

Dans cette étude des méthodes de découverte de services, nous supposerons que nous disposons d'un serveur de noms faisant autorité pour la zone example.com , avec l'adresse IP 10.0.0.2. Il existe trois serveurs backend qui correspondent au nom de domaine backends.example.com , comme indiqué dans la sortie suivante de l'utilitaire nslookup . Avec les quatre premières méthodes que nous allons aborder, NGINX et NGINX Plus demandent des enregistrements A standard au DNS ; avec la dernière méthode, NGINX Plus demande des enregistrements SRV à la place.

$ nslookup backends.example.com 10.0.0.2 Serveur :		10.0.0.2 Adresse :	10.0.0.2#53 Nom : backends.example.com Adresse : 10.0.0.11 Nom : backends.example.com Adresse : 10.0.0.10 Nom : backends.example.com Adresse : 10.0.0.12

Utilisation du DNS pour la découverte de services avec NGINX

Nous commencerons par vous montrer les trois façons d'utiliser DNS avec NGINX Open Source (comme nous l'avons mentionné ci-dessus, vous pouvez également les utiliser avec NGINX Plus).

Utilisation du nom de domaine dans la directive proxy_pass

La manière la plus simple de définir le groupe de serveurs en amont (backends) est de spécifier un nom de domaine comme paramètre de la directive proxy_pass :

serveur { emplacement / {
proxy_pass http://backends.example.com:8080;
}
}

Lorsque NGINX démarre ou recharge sa configuration, il interroge un serveur DNS pour résoudre backends.example.com . Le serveur DNS renvoie la liste des trois backends décrits ci-dessus, et NGINX utilise l'algorithme Round Robin par défaut pour équilibrer la charge des requêtes entre eux. NGINX choisit le serveur DNS à partir du fichier de configuration du système d'exploitation /etc/resolv.conf .

Cette méthode est la moins flexible pour effectuer la découverte de services et présente les inconvénients supplémentaires suivants :

• Si le nom de domaine ne peut pas être résolu, NGINX ne parvient pas à démarrer ou à recharger sa configuration.
• NGINX met en cache les enregistrements DNS jusqu’au prochain redémarrage ou rechargement de la configuration, en ignorant les valeurs TTL des enregistrements.
• Nous ne pouvons pas spécifier un autre algorithme d’équilibrage de charge, ni configurer des contrôles de santé passifs ou d’autres fonctionnalités définies par des paramètres de la directive serveur , que nous décrirons dans la section suivante.

Utilisation d'un nom de domaine dans un groupe de serveurs en amont

Pour profiter des options d’équilibrage de charge fournies par NGINX, vous pouvez définir le groupe de serveurs en amont dans le bloc de configuration en amont . Mais au lieu d'identifier les serveurs individuels par adresse IP, utilisez le nom de domaine comme paramètre de la directive serveur .

Comme avec la première méthode , backends.example.com est résolu en trois serveurs backend lorsque NGINX démarre ou recharge sa configuration. Mais nous pouvons désormais définir un algorithme d’équilibrage de charge plus sophistiqué, Least Connections , et utiliser le paramètre max_fails pour activer les contrôles de santé passifs, en spécifiant que NGINX marque un serveur comme étant en panne lorsque trois requêtes consécutives échouent.

backends en amont { least_conn;

serveur backends.example.com:8080 max_fails=3;
}

serveur {
emplacement / {
proxy_pass http://backends;
}
}

Bien que cette méthode nous permette de choisir l’algorithme d’équilibrage de charge et de configurer les contrôles de santé, elle présente toujours les mêmes inconvénients en matière de démarrage, de rechargement et de TTL que la méthode précédente.

Définition du nom de domaine dans une variable

Cette méthode est une variante de la première , mais nous permet de contrôler la fréquence à laquelle NGINX résout à nouveau le nom de domaine :

résolveur 10.0.0.2 valide=10s ;
serveur {
emplacement / {
définir $backend_servers backends.example.com ;
proxy_pass http://$backend_servers:8080 ;
}
}

Lorsque vous utilisez une variable pour spécifier le nom de domaine dans la directive proxy_pass , NGINX résout à nouveau le nom de domaine lorsque son TTL expire. Vous devez inclure la directive resolver pour spécifier explicitement le serveur de noms (NGINX ne fait pas référence à /etc/resolv.conf comme dans les deux premières méthodes). En incluant le paramètre valide dans la directive resolver , vous pouvez indiquer à NGINX d’ignorer le TTL et de résoudre à nouveau les noms à une fréquence spécifiée. Ici, nous demandons à NGINX de résoudre à nouveau les noms toutes les 10 secondes.

Note: Pour l'équilibrage de charge TCP/UDP, cette méthode d'utilisation d'une variable dans la directive proxy_pass est prise en charge dans NGINX 1.11.3 et versions ultérieures, ainsi que dans NGINX Plus R10 et versions ultérieures.

Cette méthode élimine deux inconvénients de la première méthode, dans la mesure où l'opération de démarrage ou de rechargement de NGINX n'échoue pas lorsque le nom de domaine ne peut pas être résolu, et nous pouvons contrôler la fréquence à laquelle NGINX résout à nouveau le nom. Cependant, comme il n’utilise pas de groupe en amont, vous ne pouvez pas spécifier l’algorithme d’équilibrage de charge ou d’autres paramètres dans la directive serveur (comme nous l’avons fait dans la deuxième méthode ).

Utilisation du DNS pour la découverte de services avec NGINX Plus

Nous allons maintenant examiner les deux méthodes de découverte de services avec DNS qui sont exclusives à NGINX Plus.

Utilisation des enregistrements A avec NGINX Plus

Avec NGINX Plus, nous pouvons résoudre les noms DNS aussi souvent que nous le souhaitons, et sans les inconvénients évoqués ci-dessus pour les trois premières méthodes. Pour utiliser cette fonctionnalité, nous devons :

• Incluez la directive resolver pour spécifier le serveur de noms, comme dans la méthode précédente.
• Incluez la directive zone dans le bloc de configuration en amont pour allouer une zone de mémoire partagée.
• Ajoutez le paramètre resolve à la directive serveur où nous utilisons le nom de domaine.

Considérez l’exemple suivant :

résolveur 10.0.0.2 valide=10s ; backends en amont { zone backends 64k ; serveur backends.exemple.com:8080 résoudre ; } serveur { emplacement / { proxy_pass http://backends; } }

Par défaut, NGINX Plus respecte le TTL, en résolvant à nouveau les noms lorsque les enregistrements expirent. Pour que NGINX Plus résolve à nouveau les noms à une fréquence spécifiée, incluez le paramètre valide dans la directive resolver .

Dans l'extrait, toutes les 10 secondes, NGINX Plus interroge le serveur de noms à 10.0.0.2 pour résoudre backends.example.com . Si le nom ne peut pas être résolu, NGINX Plus n'échoue pas, ni au démarrage, ni lors du rechargement de la configuration, ni pendant l'exécution. Au lieu de cela, le client voit la norme502 page d'erreur.

Utilisation des enregistrements SRV avec NGINX Plus

NGINX Plus R9 et versions ultérieures prennent en charge les enregistrements DNS SRV . Cela permet à NGINX Plus d'obtenir non seulement des adresses IP à partir d'un serveur de noms, mais également des numéros de port, des poids et des priorités. Ceci est essentiel dans les environnements de microservices où les numéros de port des services sont souvent attribués de manière dynamique.

Éditeur – Pour un aperçu de toutes les nouvelles fonctionnalités de NGINX Plus R9, consultez Annonce de NGINX Plus R9 sur notre blog.

Les enregistrements SRV sont définis par un triplet composé du nom du service, du protocole de communication avec le service et du nom de domaine. Lors de l'interrogation du serveur de noms, nous devons fournir les trois. Notre serveur de noms 10.0.0.2 possède trois enregistrements SRV avec le triplet de nom de service http , protocole tcp et nom de domaine backends.example.com , comme indiqué dans cette sortie de l'utilitaire nslookup :

$ nslookup -query=SRV _http._tcp.backends.example.com Serveur 10.0.0.2 :		10.0.0.2 Adresse :	10.0.0.2#53 _http._tcp.backends.example.com service = 0 2 8090 backend-0.example.com. _http._tcp.backends.example.com service = 0 1 8091 backend-1.example.com. _http._tcp.backends.example.com service = 10 1 8092 backend-2.example.com.

Lorsque nous interrogeons le nom d'hôte dans chaque enregistrement SRV , nous obtenons son adresse IP :

$ nslookup backend-0.exemple.com 10.0.0.2 ...
Nom : backend-0.exemple.com Adresse : 10.0.0.10 $ nslookup backend-1.exemple.com 10.0.0.2 ...
Nom : backend-1.exemple.com Adresse : 10.0.0.11 $ nslookup backend-2.exemple.com 10.0.0.2 ...
Nom : backend-2.exemple.com Adresse : 10.0.0.12

Examinons de plus près les informations du premier enregistrement SRV renvoyé par la première commande nslookup :

_http._tcp.backends.exemple.com service = 0 2 8090 backend-0.exemple.com.

• _http._tcp. – Le nom et le protocole de l’enregistrement SRV . Nous spécifierons ceci comme valeur du paramètre de service de la directive serveur dans le fichier de configuration NGINX Plus (voir ci-dessous).
• 0 – La priorité. Plus la valeur est basse, plus la priorité est élevée. NGINX Plus désigne les serveurs ayant la priorité la plus élevée comme serveurs principaux et le reste des serveurs comme serveurs de sauvegarde. Cet enregistrement a la valeur la plus basse (la priorité la plus élevée) parmi tous les enregistrements, donc NGINX Plus désigne le backend correspondant comme serveur principal.
• 2 – Le poids. NGINX Plus définit le poids du backend sur cette valeur lorsqu'il ajoute le backend au groupe en amont (équivalent au paramètre de poids sur la directive serveur ).
• 8090 – Le numéro de port. NGINX Plus définit le port du backend sur cette valeur lorsqu'il ajoute le backend au groupe en amont.
• backend‑0.example.com – Le nom d’hôte du serveur backend. NGINX Plus résout ce nom et ajoute le backend correspondant au groupe en amont. Si le nom correspond à plusieurs enregistrements, NGINX Plus ajoute plusieurs serveurs.

Voyons maintenant comment nous configurons NGINX Plus pour utiliser les enregistrements SRV . Voici l'exemple de fichier de configuration :

resolver 10.0.0.2 valid=10s;

backends en amont {
zone backends 64k;
serveur backends.exemple.com service=_http._tcp resolve;
}

serveur {
emplacement / {
proxy_pass http://backends;
}
}

En utilisant le paramètre service de la directive serveur , nous spécifions le nom et le protocole des enregistrements SRV que nous souhaitons résoudre. Dans notre cas, il s'agit respectivement de _http et _tcp . Mis à part le paramètre de service et le fait que nous ne spécifions pas de port, cela ressemble à l'exemple de configuration de la section précédente .

Sur la base des valeurs renvoyées par la première commande nslookup de cette section, NGINX Plus est configuré avec trois serveurs principaux :

• 10.0.0.10 – Serveur principal avec port 8090 et poids 2.
• 10.0.0.11 – Serveur principal avec port 8091 et poids 1.
• 10.0.0.12 – Serveur de sauvegarde avec port 8092 et poids 1.

Si nous configurons la surveillance des activités en direct pour NGINX Plus, nous pouvons voir ces backends sur le tableau de bord intégré :

Notez comment les demandes sont réparties en fonction des poids spécifiés. Le serveur 10.0.0.11:8091 (avec pondération 1) reçoit un tiers des requêtes, tandis que le serveur 10.0.0.10:8090 (avec pondération 2) reçoit les deux tiers. En tant que serveur de sauvegarde, le serveur 10.0.0.12:8092 ne reçoit aucune demande, sauf si les deux autres serveurs sont en panne.

Mises en garde

Lorsque vous utilisez DNS pour la découverte de services avec NGINX Plus, il y a quelques points à garder à l'esprit :

• Le serveur DNS doit être hautement disponible ou disposer d'un serveur de sauvegarde. Si le serveur DNS devient indisponible, NGINX Plus cesse de recevoir des mises à jour. Il conserve les backends existants dans la configuration (sauf si vous le redémarrez ou rechargez la configuration), en ignorant les valeurs TTL des enregistrements correspondants.
• Vous pouvez spécifier plusieurs serveurs de noms avec la directive resolver , de sorte que si l'un d'entre eux est en panne, NGINX Plus essaie les autres.
• Comme mentionné dans l'introduction, une alternative au DNS pour la découverte de services avec NGINX Plus est l' API NGINX Plus , qui vous permet de faire des requêtes HTTP simples pour ajouter ou supprimer des serveurs dans un groupe en amont.

Exemples

Si vous souhaitez découvrir des exemples complets, consultez ces articles de blog sur l’intégration de NGINX et NGINX Plus avec des plateformes de découverte de services qui utilisent DNS :

• Découverte de services pour NGINX Plus à l'aide des enregistrements DNS SRV de Consul
• Équilibrage de charge des services Kubernetes avec NGINX Plus

Nous mettrons à jour cette liste au fur et à mesure que nous écrirons davantage sur les nouvelles options d’intégration à l’avenir.

Conclusion

La découverte de services via DNS, entièrement disponible dans NGINX Plus, fournit un moyen simple de mettre à jour la configuration de l'équilibreur de charge dans un environnement de microservices. La prise en charge des enregistrements SRV dans la version 9 et les versions ultérieures rend NGINX Plus encore plus puissant, car elle permet à NGINX Plus d'obtenir non seulement les adresses IP, mais également les numéros de port des backends.

Prêt à essayer la découverte de services avec DNS pour NGINX Plus, ainsi que ses autres fonctionnalités améliorées ? Commencez votre essai gratuit de 30 jours dès aujourd'hui ou contactez-nous pour discuter de vos cas d'utilisation .