Utiliser le DNS pour la découverte de services avec NGINX et NGINX Plus

Michael Pleshakov

[Note de la rédaction – Cet article a été mis à jour pour faire référence à l’API NGINX Plus, qui remplace et rend obsolète le module distinct de configuration dynamique mentionné dans la version originale de l’article.]

L’un des grands avantages d’une architecture de microservices réside dans la rapidité et la facilité avec lesquelles vous pouvez faire évoluer le nombre d’instances de service. Lorsque vous disposez de 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 que l’on appelle la découverte de services. NGINX Plus offre deux possibilités d’intégration aux systèmes de découverte de services : l’API NGINX Plus et la résolution DNS (Domain Name System) périodique. Cet article de blog se concentre sur cette dernière.

Lorsque vous adaptez le nombre d’instances de service (que nous 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 changement apporté à l’ensemble des backends. Selon l’application, cette mise à l’échelle peut avoir lieu plusieurs fois par jour, par heure, voire par minute. Compte tenu de la fréquence élevée des changements de configuration, ceux-ci doivent être automatisés. La découverte de services via DNS est l’un des moyens d’y parvenir.

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

Bref rappel des principales fonctionnalités du DNS

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

Durée de vie

Pour empêcher les clients DNS d’utiliser des informations obsolètes, les enregistrements DNS comportent un champ de durée de vie (TTL) qui définit la période pendant laquelle les clients peuvent considérer l’enregistrement comme valide. Pour respecter les normes DNS, les clients doivent interroger le serveur DNS afin d’obtenir une mise à jour lorsque la TTL d’un enregistrement a expiré. Par défaut, NGINX Plus respecte la TTL, mais permet également de contrôler plus précisément la « durée de vie » d’un enregistrement : vous pouvez configurer NGINX Plus pour qu’il ignore les TTL et mette plutôt à jour les enregistrements à une fréquence définie. (Nous verrons plus loin dans cet article comment NGINX Open Source gère la TTL.)

DNS sur TCP

Par défaut, les clients et serveurs DNS communiquent via UDP. Toutefois, si un nom de domaine correspond à un grand nombre d’adresses IP de serveurs backend, la réponse complète risque de ne pas tenir dans un seul datagramme UDP, dont la taille est limitée à 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 seul datagramme, le serveur active un indicateur de troncation dans sa réponse, signalant ainsi au client qu’il doit passer à TCP pour obtenir tous les enregistrements. DNS sur TCP est pris en charge à partir de NGINX 1.9.11 et de NGINX Plus R9. Pour plus d’informations, consultez l’article « Équilibrage de charge du trafic DNS avec NGINX et NGINX Plus » sur notre blog.

SRV Enregistrements

Le DNS résout les noms d’hôte en adresses IP, mais qu’en est-il des numéros de port ? Dans certains cas – par exemple, lors de la répartition de charge entre des conteneurs Docker –, il n’est pas possible de s’appuyer sur des numéros de port bien connus, car ceux-ci sont attribués dynamiquement. Le DNS dispose d’un type d’enregistrement spécial – l’enregistrement de service (SRV) – qui inclut les numéros de port ainsi que quelques autres paramètres. À partir de la version R9, NGINX Plus prend en charge les enregistrements SRV (et peut donc en extraire les informations de port).

Note de la rédaction – Pour un aperçu de toutes les nouvelles fonctionnalités de NGINX Plus R9, consultez l’article « 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 présenter cinq façons d’utiliser le DNS pour la découverte de services dans NGINX et NGINX Plus, par ordre de sophistication croissante. Les trois premières sont disponibles dans NGINX et NGINX Plus, tandis que les deux dernières sont réservées à NGINX Plus.

Dans cette présentation 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, à l’adresse IP 10.0.0.2. Trois serveurs backend correspondent au nom de domaine backends.example.com, comme l’illustre la sortie suivante de l’utilitaire nslookup. Avec les quatre premières méthodes présentées, NGINX et NGINX Plus demandent au DNS des enregistrements A standard ; avec la dernière méthode, NGINX Plus demande à la place des enregistrements SRV.

$ nslookup backends.example.com 10.0.0.2Server:		10.0.0.2
Address:	10.0.0.2#53

Name:	backends.example.com
Address: 10.0.0.11
Name:	backends.example.com
Address: 10.0.0.10
Name:	backends.example.com
Address: 10.0.0.12

Utiliser le DNS pour la découverte de services avec NGINX

Nous commencerons par vous présenter les trois façons d’utiliser le DNS avec NGINX Open Source (comme indiqué précédemment, vous pouvez également les utiliser avec NGINX Plus).

Utilisation du nom de domaine dans la directive « proxy_pass »

Le moyen le plus simple de définir le groupe de serveurs en amont (backends) consiste à spécifier un nom de domaine comme paramètre de la directive proxy_pass :

server {    location / {
        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 serveurs backend mentionnés ci-dessus, et NGINX utilise l’algorithme Round Robin par défaut pour répartir la charge des requêtes entre eux. NGINX sélectionne 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 également les inconvénients suivants :

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

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

Pour tirer parti des options de répartition de charge proposées par NGINX, vous pouvez définir le groupe de serveurs en amont dans le bloc de configuration upstream. Toutefois, au lieu d’identifier chaque serveur par son adresse IP, utilisez le nom de domaine comme paramètre de la directive server.

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é, celui des connexions les moins nombreuses, et utiliser le paramètre max_fails pour activer les contrôles d’intégrité passifs, en précisant que NGINX marque un serveur comme indisponible lorsque trois requêtes consécutives échouent.

upstream backends {    least_conn;

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

server {
    location / {
        proxy_pass http://backends;
    }
}

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

Définition du nom de domaine dans une variable

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

resolver 10.0.0.2 valid=10s;
server {
    location / {
        set $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 consulte pas /etc/resolv.conf comme dans les deux premières méthodes). En ajoutant le paramètre valid à la directive resolver, vous pouvez demander à NGINX d’ignorer le TTL et de résoudre à nouveau les noms à une fréquence définie. Ici, nous demandons à NGINX de résoudre à nouveau les noms toutes les 10 secondes.

Remarque : Pour l’équilibrage de charge TCP/UDP, cette méthode consistant à utiliser une variable dans la directive proxy_pass est prise en charge à partir de NGINX 1.11.3 et de NGINX Plus R10.

Cette méthode élimine deux inconvénients de la première méthode : 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 ce nom. Toutefois, comme elle n’utilise pas de groupe en amont, vous ne pouvez pas spécifier l’algorithme d’équilibrage de charge ni d’autres paramètres dans la directive server (comme nous l’avons fait dans la deuxième méthode).

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

Examinons maintenant les deux méthodes de découverte de services via DNS qui sont propres à NGINX Plus.

Utilisation des enregistrements A avec NGINX Plus

Avec NGINX Plus, nous pouvons résoudre à nouveau les noms DNS aussi souvent que nous le souhaitons, 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 « upstream » afin d’allouer une zone de mémoire partagée.
• Ajoutez le paramètre « resolve » à la directive « server » lorsque nous utilisons le nom de domaine.

Prenons l’exemple suivant :

resolver 10.0.0.2 valid=10s;
upstream backends {
    zone backends 64k;
    server backends.example.com:8080 resolve;
}

server {
    location / {
        proxy_pass http://backends;
    }
}

Par défaut, NGINX Plus respecte la durée de vie (TTL) et résout à nouveau les noms lorsque les enregistrements expirent. Pour que NGINX Plus résolve plutôt les noms à nouveau selon une fréquence définie, ajoutez le paramètre valid à la directive resolver.

Dans cet extrait, NGINX Plus interroge toutes les 10 secondes le serveur de noms à l’adresse 10.0.0.2 afin de résoudre backends.example.com. Si le nom ne peut pas être résolu, NGINX Plus ne génère aucune erreur, que ce soit au démarrage, lors du rechargement de la configuration ou pendant l’exécution. À la place, le client voit la page d’erreur standard 502.

Utilisation des enregistrements « SRV » avec NGINX Plus

NGINX Plus R9 et les versions ultérieures prennent en charge les enregistrements DNS SRV. NGINX Plus peut ainsi obtenir auprès d’un serveur de noms non seulement les adresses IP, mais aussi les numéros de port, les pondérations et les priorités. Cette fonctionnalité est essentielle dans les environnements de microservices, où les numéros de port des services sont souvent attribués dynamiquement.

Note de la rédaction – Pour un aperçu de toutes les nouvelles fonctionnalités de NGINX Plus R9, consultez l’article « Announcing NGINX Plus R9 » sur notre blog.

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 ces trois éléments. Notre serveur de noms 10.0.0.2 possède trois enregistrements SRV avec le triplet suivant : nom du service http, protocole tcp et nom de domaine backends.example.com, comme le montre cette sortie de l’utilitaire nslookup :

$ nslookup -query=SRV _http._tcp.backends.example.com 10.0.0.2Server:		10.0.0.2
Address:	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 de chaque enregistrement SRV, nous obtenons son adresse IP :

$ nslookup backend-0.example.com 10.0.0.2...
Name:	backend-0.example.com
Address: 10.0.0.10

$ nslookup backend-1.example.com 10.0.0.2
...
Name:	backend-1.example.com
Address: 10.0.0.11

$ nslookup backend-2.example.com 10.0.0.2
...
Name:	backend-2.example.com
Address: 10.0.0.12

Examinons de plus près les informations contenues dans le premier enregistrement « SRV » renvoyé par la première commande « nslookup » :

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

• _http._tcp. – Le nom et le protocole de l’enregistrement SRV. Nous l’indiquerons comme valeur du paramètre service de la directive server dans le fichier de configuration de NGINX Plus (voir ci-dessous).
• 0 – La priorité. Plus la valeur est faible, plus la priorité est élevée. NGINX Plus désigne les serveurs ayant la priorité la plus élevée comme serveurs principaux, et les autres comme serveurs de secours. Cet enregistrement possède la valeur la plus faible (la priorité la plus élevée) parmi tous les enregistrements. NGINX Plus désigne donc le serveur backend correspondant comme serveur principal.
• 2 – Le poids. NGINX Plus attribue cette valeur au poids du serveur backend lorsqu’il l’ajoute au groupe upstream (équivalent au paramètre weight de la directive server).
• 8090 – Le numéro de port. NGINX Plus définit le port du serveur backend sur cette valeur lorsqu’il ajoute ce serveur au groupe de serveurs 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 de serveurs en amont. Si le nom correspond à plusieurs enregistrements, NGINX Plus ajoute plusieurs serveurs.

Voyons maintenant comment configurer NGINX Plus pour utiliser les enregistrements « SRV ». Voici un exemple de fichier de configuration :

resolver 10.0.0.2 valid=10s;

upstream backends {
    zone backends 64k;
    server backends.example.com service=_http._tcp resolve;
}

server {
    location / {
        proxy_pass http://backends;
    }
}

À l’aide du paramètre « service » de la directive « server », nous indiquons le nom et le protocole des enregistrements SRV que nous souhaitons résoudre. Dans notre cas, il s’agit respectivement de « _http » et « _tcp ». Hormis le paramètre « service » et le fait que nous ne spécifions pas de port, cette configuration est identique à l’exemple de configuration de la section précédente.

D’après les valeurs renvoyées par la première commande « nslookup » de cette section, NGINX Plus est configuré avec trois serveurs backend :

• 10.0.0.10 – Serveur principal utilisant le port 8090 et ayant un poids de 2.
• 10.0.0.11 – Serveur principal avec le port 8091 et un poids de 1.
• 10.0.0.12 – Serveur de secours utilisant le port 8092 et ayant un poids de 1.

Si nous configurons la surveillance de l’activité en temps réel pour NGINX Plus, nous pouvons voir ces serveurs back-end dans le tableau de bord intégré :

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

Mises en garde

Lorsque vous utilisez DNS pour la découverte de services avec NGINX Plus, gardez quelques points à l’esprit :

• Le serveur DNS doit être hautement disponible ou disposer d’un serveur de secours. Si le serveur DNS devient indisponible, NGINX Plus cesse de recevoir les mises à jour. Il conserve les serveurs backend existants dans la configuration (sauf si vous le redémarrez ou rechargez la configuration), sans tenir compte des valeurs TTL des enregistrements correspondants.
• Vous pouvez spécifier plusieurs serveurs de noms à l’aide de la directive resolver afin que, si l’un d’eux est indisponible, NGINX Plus essaie les autres.
• Comme indiqué dans l’introduction, l’NGINX Plus API constitue une alternative au DNS pour la découverte de services avec NGINX Plus. Elle permet d’effectuer de simples requêtes HTTP afin d’ajouter ou de supprimer des serveurs dans un groupe en amont.

Exemples

Si vous souhaitez consulter des exemples complets, découvrez ces articles de blog sur l’intégration de NGINX et NGINX Plus avec des plateformes de découverte de services utilisant le DNS :

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

Nous mettrons cette liste à jour à mesure que nous publierons de nouveaux articles sur les futures options d’intégration.

Conclusion

La découverte de services via DNS, entièrement disponible dans NGINX Plus, permet de mettre à jour facilement la configuration de l’équilibreur de charge dans un environnement de microservices. La prise en charge des enregistrements SRV à partir de la version 9 rend NGINX Plus encore plus puissant, car elle lui permet d’obtenir non seulement les adresses IP, mais aussi les numéros de port des serveurs back-end.

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

À propos de l’auteur

Michael Pleshakov

Autres articles de Michael Pleshakov