Comment utiliser la configuration faisant autorité partagée OctoDNS et DNS

Présentation

Construire un système robuste nécessite de le concevoir en prévision de l'échec. En tant qu'ingénieurs en fiabilité de site (SRE) chez GitHub, nous cherchons toujours à atténuer les problèmes grâce à la redondance, et aujourd'hui, nous discuterons des travaux récents que nous avons effectués pour vous aider à trouver nos serveurs via DNS.

Les grands fournisseurs DNS intègrent plusieurs niveaux de redondance dans leurs services, et lorsqu'un problème survient entraînant une panne, des mesures peuvent être prises pour atténuer son impact. L'une des meilleures options consiste à répartir les services faisant autorité de votre région entre plusieurs fournisseurs de services. L'activation du partage d'autorité est aussi simple que de configurer deux ou plusieurs ensembles de serveurs de noms pour votre zone auprès de votre registraire de domaine, et les requêtes DNS seront réparties sur la liste. Cependant, vous devez conserver les enregistrements dans ces domaines synchronisés entre plusieurs fournisseurs, et selon la situation, cela peut être soit complexe à mettre en place, soit un processus entièrement manuel.

$ dig NS github.com. @a.gtld-servers.net.
...
;; QUESTION SECTION:
;github.com. IN NS
;; AUTHORITY SECTION:
github.com. 172800 IN NS ns4.p16.dynect.net.
github.com. 172800 IN NS ns-520.awsdns-01.net.
github.com. 172800 IN NS ns1.p16.dynect.net.
github.com. 172800 IN NS ns3.p16.dynect.net.
github.com. 172800 IN NS ns-421.awsdns-52.com.
github.com. 172800 IN NS ns-1283.awsdns-32.org.
github.com. 172800 IN NS ns2.p16.dynect.net.
github.com. 172800 IN NS ns-1707.awsdns-21.co.uk.
...

La requête ci-dessus demande au serveur de noms TLD les enregistrements NS de github.com. Il renvoie la valeur que nous avons configurée dans le registraire de domaine. Dans ce cas, il existe deux fournisseurs de services DNS avec quatre enregistrements chacun. Si l’un des fournisseurs subit une panne, on peut espérer que les autres pourront toujours répondre à la demande. Nous synchronisons les enregistrements partout et pouvons les modifier en toute sécurité sans nous soucier des données obsolètes ou d'un état incorrect.

La dernière partie de la configuration complète de l'autorité partagée consiste à ajouter tous les serveurs de noms des deux fournisseurs de services DNS en tant qu'enregistrements NS de niveau supérieur à la racine de la zone.

$ dig NS github.com. @ns1.p16.dynect.net.
...
;; QUESTION SECTION:
;github.com. IN NS
;; ANSWER SECTION:
github.com. 551 IN NS ns1.p16.dynect.net.
github.com. 551 IN NS ns2.p16.dynect.net.
github.com. 551 IN NS ns-520.awsdns-01.net.
github.com. 551 IN NS ns3.p16.dynect.net.
github.com. 551 IN NS ns-421.awsdns-52.com.
github.com. 551 IN NS ns4.p16.dynect.net.
github.com. 551 IN NS ns-1283.awsdns-32.org.
github.com. 551 IN NS ns-1707.awsdns-21.co.uk.

Chez GitHub, nous avons des dizaines de zones et des milliers d'enregistrements, et la plupart de ces zones ne sont pas suffisamment critiques pour nécessiter une redondance, nous ne devons donc en gérer que quelques-unes. Nous aimerions disposer d'une solution capable de synchroniser ces enregistrements entre plusieurs fournisseurs de services DNS et, plus généralement, de gérer tous les enregistrements DNS en interne et en externe. Nous annonçons donc aujourd’hui OctoDNS.

Configuration

OctoDNS nous permet de réinventer notre workflow DNS. Nos régions et enregistrements sont stockés dans des fichiers de configuration dans le référentiel Git. Utilisez les flux GitHub pour les modifier et déployez-les avec des branches, tout comme un site. Nous pouvons même effectuer un déploiement "vide" pour prévisualiser quels enregistrements seront modifiés lors du changement. Les fichiers de configuration sont des dictionnaires yaml, un par région, dont les clés de niveau supérieur sont des noms d'enregistrement et les valeurs de clé sont des données ttl, type et spécifiques au type. Par exemple, lorsqu'elle est incluse dans le fichier de zone github.com.yaml, la configuration suivante créera un enregistrement A pour octodns.github.com.

octodns:
type: A
values:
- 1.2.3.4
- 1.2.3.5

La deuxième partie de la configuration mappe la source des données d'enregistrement au fournisseur de services DNS. L'extrait de code suivant indique à OctoDNS de charger la zone github.com à partir du fournisseur de configuration et de synchroniser ses résultats avec dyn et route53.

zones:
github.com.:
sources:
- config
targets:
- dyn
- route53

Sync

Une fois notre configuration terminée, OctoDNS peut évaluer l'état actuel et créer un plan décrivant l'ensemble des changements qui seront nécessaires pour faire correspondre l'état cible à la source. Dans l'exemple ci-dessous, octodns.github.com est un nouvel enregistrement, l'action requise consiste donc à créer des enregistrements dans les deux.

$ octodns-sync --config-file=./config/production.yaml
...
********************************************************************************
* github.com.
********************************************************************************
* route53 (Route53Provider)
* Create
* Summary: Creates=1, Updates=0, Deletes=0, Existing Records=0
* dyn (DynProvider)
* Create
* Summary: Creates=1, Updates=0, Deletes=0, Existing Records=0
********************************************************************************
...

Par défaut, octodns-sync est en mode d'exécution de simulation, donc aucune action ne sera entreprise. Une fois que nous avons examiné les modifications et en sommes satisfaits, nous pouvons ajouter l'indicateur `--doit' et réexécuter la commande. OctoDNS poursuivra son flux de traitement, en apportant cette fois les modifications nécessaires dans Route53 et Dynect pour créer le nouvel enregistrement.

$ octodns-sync --config-file=./config/production.yaml --doit
...

À ce stade, nous avons les mêmes enregistrements de données chez les deux fournisseurs de services DNS et pouvons facilement répartir nos requêtes DNS entre eux, sachant qu'elles fourniront des résultats précis. Lorsque nous exécutons directement la commande OctoDNS ci-dessus, notre flux de travail interne repose sur des scripts de déploiement et des chatops. Vous pouvez trouver plus d’informations dans la section workflow du README.

Résumé

Nous pensons que la plupart des sites Web pourraient bénéficier d'une séparation des autorités, et nous espérons qu'avec OctoDNS, le plus gros obstacle a été supprimé. Même si le partage de l'autorité ne vous intéresse pas, OctoDNS vaut toujours le détour car il apporte les avantages de l'infrastructure sous forme de code au DNS.

Vous souhaitez aider l'équipe GitHub SRE à résoudre un problème intéressant ? Nous serions ravis de nous rejoindre. Appliquer ici.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!