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

Slide 1

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

Slide 2

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

Slide 3

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

Slide 4

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

Slide 5

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

Slide 6

N’avez vous jamais rêvé de …

Slide 7

~#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

Slide 8

Et oui, je ne dors pas beaucoup…😅

Slide 9

Je vais vous conter une histoire d’ops…

Slide 10

Voici Michael 😏

Slide 11

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

Slide 12

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)

Slide 13

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

Slide 14

Gérer ses enregistrements avec Ansible ?

Slide 15

Slide 16

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).

Slide 17

Gérer ses enregistrements avec Terraform ?

Slide 18

Slide 19

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 …

Slide 20

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

Slide 21

Gérer ses enregistrements avec l’interface Web ?

Slide 22

Slide 23

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 :

Slide 24

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

Slide 25

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

Slide 26

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

Slide 27

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

Slide 28

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.

Slide 29

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).

Slide 30

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

Slide 31

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

Slide 32

L’autonomie

Slide 33

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é. 😯

Slide 34

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

Slide 35

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).

Slide 36

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.

Slide 37

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” ?

Slide 38

Workflow 🤖

Slide 39

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

Slide 40

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