Infra : Donnez de l’autonomie à vos développeurs avec OctoDNS

Infra : Donnez de l’autonomie à vos développeurs avec

N’avez vous jamais rêvé d’un monde où … 🤔

La création d’enregistrements DNS est accessible à toutes et tous? 🤨

Le DNS n’est plus réservé aux Ops? 😇

Vous pouvez migrer de l’on-prem’ vers du Cloud en moins de 5mn*? 🤯 *sous réserve de l’effet démo …

N’avez vous jamais rêvé de …

~#whoami Julien Briault 😎 (ex) SecOps consultant chez IT/Infrastructure Manager (bénévole) aux Network Engineer / SRE chez Auteur principal sur blog.jbriault.fr #Networking #FOSS #Dev #Music @ju_hnny5

Et oui, je ne dors pas beaucoup…😅

Je vais vous conter une histoire d’ops…

Voici Michael 😏

Des 90s à 2005 : L’âge d’or de Bind 🤠 Les balbutiements de l’automatisation (gestion de configuration, pet vs cattle) Une administration via Telnet/SSH : ○ Modification dans un fichier de zone ○ Les utilisateurs doivent posséder un minimum de connaissances pour ne pas casser le fichier de zone … 😬 N’expose pas d’API

L’arrivée de PowerDNS* : la modernité 😍 Une API REST Gestion simplifiée des zones Une CLI performante Un gros défaut : une API mono tenant. *pdns_server (authoritative server)

Une solution écrasante AWS Route53 😱 Gain de temps de gestion des instances on-prem : ● Pas besoin de gérer la répartition de charge avec dnsdist Possibilité de gestion “as-code” avec des outils comme Terraform* ou Ansible* par exemple. *https://www.terraform.io/ *https://www.ansible.com/ Source : https://bit.ly/42U3GrZ

Gérer ses enregistrements avec Ansible ?

Gérer ses enregistrements avec Ansible ? ● Le module Ansible Route53 n’est pas idempotent (enfin, pas totalement)… ● Il est lent quand on possède un très grand nombre de zones/enregistrements. ● Il atteint rapidement les limites d’appels d’API Route 53 (environ 5 requêtes /sec). ● Pas de possibilité de migrer des enregistrements on-prem vers Route53 simplement (ou sans passer par scripting/adaptation).

Gérer ses enregistrements avec Terraform ?

x2

Gérer ses enregistrements avec Terraform ? ● Tout comme Ansible, lent quand on possède un très grand nombre de zones/enregistrements. ● Format très (trop) verbeux …

Gérer ses enregistrements avec Terraform ? Idéal pour des petites zones (dans des projets restreints). Un enfer quand on souhaite migrer d’un provider à un autre. ● Le format n’étant pas identique. ● Obligé de “scripter” pour transférer. AWS Route53 GCP Cloud DNS

Gérer ses enregistrements avec l’interface Web ?

OctoDNS, késako ? ● ● ● ● Créé par GitHub pour gérer leur infrastructure DNS Première release (Licence MIT) en 2017 Écrit en Python (3) 🤨 Outil dit “stateful” et en CLI. ● Permet de migrer rapidement d’un provider DNS à un autre (pratique en cas de panne). 🔥 ● Liste non exhaustive des providers supportés :

https://www.bortzmeyer.org/meteofrance-dns.html

Pourquoi OctoDNS ? Parce qu’il fait les choses simplement et de manière agnostique. 😅

Configuration explicite et accessible ● Au format YAML ● Définition des zones gérées ● Définition des sources et destination

Création d’enregistrement accessible ● Utilisation du format YAML pour déclarer ses enregistrements. ● Exemple pour déclarer foo.example.org : Terraform OctoDNS

Migrer/ récupérer facilement une zone 😳 ● Permet de migrer d’un provider à l’autre sans effort particulier via la commande octodns-sync.* ○ Peu importe la ou les source(s) ou la ou les destination(s). ● Permet de récupérer le contenu d’une zone et de le convertir au format OctoDNS via la commande octodns-dump.

Ce qu’il ne fait pas : ● Ne permet pas de gérer la configuration des serveurs DNS. ○ Il n’est pas là pour remplacer des outils comme Ansible. ● Ne permet pas de changer la configuration des registrar (ex : Gandi).

Peux-tu ouvrir l’accès aux devs ?

Quoi ?! Laisser les devs faire de l’ops ? 🤬

L’autonomie

L’autonomie 🫶 ● Définition d’un cadre (ex : dépôt Git avec workflow + CICD) ● L’autonomie n’empêche pas le contrôle ! 🫶 ○ L’équipe propriétaire du dépôt possède un droit de véto sur les modifications (ex : équipe réseau). ● Des CODEOWNERS pour plus d’eﬃcacité. 😯

L’autonomie ● La communication 🤓 ○ Des channels dédiés ■ Chan dédié aux questions portant sur le fonctionnement d’OctoDNS ou sur un besoin d’accompagnement. ● Ex : #discuss-octodns

L’autonomie ● La communication 🤓 ○ Des channels dédiés ■ Chan dédié aux modifications sur le ou les dépôts OctoDNS (via un bot Github par exemple (et son template définit dans .github/PULL_REQUEST_TEMPLATE.md).

L’autonomie ● Gain : ○ Augmentation de la vélocité du développeur. ○ Retire du toil aux équipes d’infrastructure/réseau (sauf la partie de review. ○ Permet d’éviter les erreurs en passant par une application orchestrée par CI/CD des modifications.

L’autonomie ● Gain : ○ Retour arrière facile (via git revert) en cas d’erreur (sur la zone même). ○ Obtenir plus de contexte (avec les commits) sur les modifications apportées : ■ Permet également de suivre qui a fait une modification. ■ Permet de répondre à : “pourquoi cette modif” ?

Workflow 🤖

Workflow* sur une Pull Request (PR) 1. Nouvelle PR avec des enregistrements créée 2. Validation de la syntaxe (via octodns-validate & yamllint) 3. Application sur l’environnement de staging 4. Report de l’état des enregistrements de l’env de staging 5. Pr validée ✅ *Workflow simple, utilisé chez Deezer

Workflow* au merge sur master 1. Merge de la branche sur master 2. Application sur l’env de prod 3. Report de l’état des enregistrements de l’env de prod 4. Enregistrements dispos ! *Workflow simple, utilisé chez Deezer

Démos !

Démo 1 : Créer ses premiers enregistrements. 😺

Démo 2 : Récupérer les enregistrements d’une zone (dump). 😻

Démo 3 : Migrer d’on-premise vers le cloud. 🙀

Instant pub … 🫶 https://boutique.ed-diamond.com/en-kiosque/1652-linux-pratique-136.html

Merci

One link : https://t.ly/wxK0Q

🫶 Merci pour votre attention ! 🫶