LogoLogo Light
  • Product
  • Services
  • about us
  • career
  • Blog
  • Product
  • Services
  • about us
  • career
  • Blog
Related post
How to separate the sheep from the goat using the Gini coefficient?

How to separate the sheep from the goat using the Gini coefficient?

Perception and reality, the secrets of a fluid WEB application

Perception and reality, the secrets of a fluid WEB application

blog launch

blog launch

Related post
Pourquoi est-on passé de Selenium à Cypress ?

Pourquoi est-on passé de Selenium à Cypress ?

Les avantages d’une BDD pour la gestion du DNS

Les avantages d’une BDD pour la gestion du DNS

Langage et pensée formelle : des réseaux neuronaux dissociables

Langage et pensée formelle : des réseaux neuronaux dissociables

Les composants logiciels d’une fonctionnalité de cartographie vectorielle

Les composants logiciels d’une fonctionnalité de cartographie vectorielle

Blog Image
Tout

Les avantages d’une BDD pour la gestion du DNS

  • Posted by LivingObjects

Les avantages d’une BDD pour la gestion du DN

Mettre 172.16.1.1 dans la barre du navigateur au lieu de « http://mon-intranet.local » donne un certain prestige à l’administrateur système lorsqu’un œil non expert regarde par-dessus son épaule. Mais, avec tout le respect que je dois à ma profession, notre mémoire n’est pas infaillible. Retenir des dizaines, voire beaucoup plus, d’adresses IP est impossible.

Les limites d’un serveur DNS implémenté avec BIND

Le serveur DNS (Domain Name System) est le dictionnaire qui permet de transformer les adresses IP en noms. L’implémentation classique d’un DNS sous GNU/Linux, utilise BIND (Berkeley Internet Name Domain) conçu au début d’Internet. L’administrateur réseau référence l’intégralité de son parc machines dans un fichier plat, en respectant une nomenclature précise imposé par BIND.

BIND est depuis longtemps le serveur DNS incontournable du monde Unix. Il est peu gourmand en ressource, performant, sécurisé…

Mais le format de fichier qu’il utilise n’est pas facilement manipulable par programmation (JSON, XML, YAML…). Il est donc complexe à exploiter en dehors des usages classiques d’un serveur DNS, et c’est de cela que nous parlons !

Prenons un exemple : Requêter un serveur DNS sous BIND, c’est comme appeler le 118 218 pour connaitre un numéro de téléphone : Il nous faut connaitre le nom, prénom, ville, ….de la personne recherchée. Or dans l’exploitation d’un nombre important d’équipements, il est impossible de connaitre toutes les caractéristiques de toutes les machines. Lorsqu’on réalise une requête, il nous faut en retour, une liste des serveurs « approchant » les caractéristiques qu’on a indiqué, pour reconnaitre celui qui nous convient. Comme si on feuilletait les pages jaunes à la rubrique « plombier ».

Implémentation du DNS sous PowerDNS

Notre approche se base sur PowerDNS avec un backend MySQL, une interface d’administration et une API maison développée en Python/Flask.
L’interface d’administration permet à toute personne ayant les droits, de consulter la liste complète des machines (écran de gauche ci-dessous) et aux administrateurs de réaliser les opérations de CRUD sur les machines (écran de droite ci-dessous).
Cette gestion de droits avec les logs associés permet de vérifier rapidement les modifications apportées et éventuellement de faire des retours arrière en cas d’erreur (l’Admin Sys. étant un être humain…. jusqu’à preuve du contraire.). Le versionning sous Git des fichiers BIND aurait été possible mais le suivi des historiques par ce procédé est plus laborieux.

Écrans de visualisation :

Architecture :

Une gestion simplifiée du parc machines

Voici quelques exemples basés sur notre API :

    • Génération des fichiers “hosts” Ansible.
      Quoi de plus fastidieux que de maintenir, malgré le versionning, un fichier hosts Ansible avec plusieurs centaines de lignes, alors qu’un simple script permet de le générer automatiquement à tout moment depuis les enregistrements actualisés du DNS.
    • Ajout automatique des sauvegardes pour les nouveaux hôtes.
      Nous utilisons BackupPC pour les serveurs GNU/Linux. Dès qu’un hôte est déployé et ajouté au DNS, BackupPC en a connaissance via une interrogation régulière de l’API. Aucune intervention de notre part n’est nécessaire, en dehors d’un contrôle de routine régulier.
    • Autocomplétion Bash/ZSH (client SSH, ping…).
      Lorsqu’on cherche un élément, on utilise les capacité d’autocompletion de la base de données. Trois lettres à taper, un chiffre + TAB et le nom complet de l’hôte auquel je veux me connecter apparait. Très pratique pour les nouveaux arrivants, comme pour les plus anciens.
    • Mise à jour automatique de l’inventaire du parc.
      Tout comme pour le fichier hosts Ansible, la connexion du système à Rudder permet une découverte automatique des éléments du parc, et la mise à jour associée. Il n’est plus nécessaire de mettre à jour manuellement des informations « réseaux » lors d’un changement de topologie.

Sauf si mémoriser le parc machine constitue pour vous le meilleur entrainement à l’exercice de votre mémoire, la solution que nous avons adoptée nous parait plus fiable pour exploiter sereinement un parc machines important.

Références :

#PowerDNS #MySQL #Ansible #Rudder #BackupPC

Previous Post

Langage et pensée formelle : des réseaux neuronaux dissociables

Next Post

Pourquoi est-on passé de Selenium à Cypress ?
0 comments on Les avantages d’une BDD pour la gestion du DNS
Scroll

LivingObjects

Legal | Privacy police