Import manuel de records DNS route53 avec Terraform

Mon, 20 Sep 2021 06:10:00 +0000

Terraform et l’Infrastructure as Code

Ce n’est pas la première fois que je parle de terraform, l’outil d’Infrastructure as Code particulièrement efficace dans les environnements cloud (mais pas que) de Hashicorp.

J’avais fait un petit « tour d’horizon » de l’outil quand il était encore en v0.10 (Hashicorp a passé terraform en v1.0 en juin), si vous avez besoin d’un petit rafraîchissement de mémoire ou que vous découvrez l’outil.

Pour la faire courte, l’intérêt de terraform (et de l’infrastructure as code) par rapport à l’automatisation plus classique est de passer dans un mode « déclaratif » où vous déclarez dans des manifests l’état souhaité de votre infrastructure plutôt que de dérouler un script qui fait les opérations unes à unes.

Vos manifests deviennent la « source de vérité », auditable, versionnable, absolue (pas de diff possible entre ce que vous pensez avoir déployé et le bidule modifié à la main hier que vous avez oublié).

Réconcilier l’existant avec l’infrastructure as code

Tout ça c’est super si jamais vous venez de commencer à travailler dans le cloud et que vous partez de 0.

Si vous avez déjà de l’existant, c’est plus compliqué puisque vous vous retrouvez avec une partie décrite dans votre dépôt Git et une autre partie « historique ».

Et même si on peut se dire que cette partie « historique » va finir par disparaitre au profit des nouveaux projets gérés par IaC, il existe une zone floue où on ne sait plus très bien si c’est géré à la main ou en IaC.

Du coup, autant en profiter quand on a le temps pour réintégrer le legacy dans l’IaC.

Route53, le DNS by AWS

Je suis donc arrivé dans un contexte technique où le DNS externe est géré par AWS depuis bien longtemps, et qu’on intègre progressivement les nouveaux records dans terraform. Cependant, j’avais besoin de modifier un record déjà existant (de type TXT) et je n’avais pas envie de le faire à la main.

Sachez donc qu’il existe pour une grande partie (tous ?) des providers terraform une commande terraform import qui permet comme son nom l’indique d’importer l’existant dans terraform.

Le souci est que cette import n’est réalisée que dans le « state » de terraform, pas la configuration elle même.

The current implementation of Terraform import can only import resources into the state. It does not generate configuration. A future version of Terraform will also generate configuration.

Vous allez donc devoir écrire le pavé HCL à la main.

D’un certain côté, c’est presque plus rassurant quand on y réfléchit, car ça permet de bien se poser la question de comment on souhaite découper nos projets, comment on veut construire l’IaC (avec des variables, avec des boucles, etc).

Récupérer les IDs uniques

L’idée ici va être de récupérer le record en donnant à terraform toutes les infos nécessaire pour qu’il retrouve celui qui nous intéresse. A la suite de terraform import, on doit lui donner les informations suivantes :

terraform import {resource_type}.{resource_name} {zone_id}_{record_name}_{record_type}

Dans mon cas, le resource_type était aws_route53_record, le resource_name mytxtrecord (le nom que je veux lui donner dans ma conf et mon state terraform). La zone ID dépend de votre compte AWS/route53, le record_name, c’est le nom du record (comme sur la console) et le record_type dans mon cas, un TXT mais ça aurait très bien pu être un A, un AAAA, un CNAME, etc.

terraform import aws_route53_record.mytxtrecord ABCDE1234567890_awesomeexample.org_TXT
aws_route53_record.mytxtrecord: Importing from ID "ABCDE1234567890_awesomeexample.org_TXT"...
aws_route53_record.mytxtrecord: Import prepared!
Prepared aws_route53_record for import

A l’issue de la commande, si tout s’est bien passé, vous devriez avoir un message qui indique le succès de l’opération et l’ajout du record dans le state de votre terraform. Il ne reste plus qu’à rédiger le pavé HCL pour votre IaC qui a cette tête là dans mon exemple :

resource "aws_route53_record" "mytxtrecord" {
zone_id = data.aws_route53_zone.awesomedomain.zone_id
name = "awesomeexample.org"
type = "TXT"
ttl = "60"
records = ["existingsuperimportantdata"]
}

On peut commiter ça, puis faire nos modifications comme d’habitude et en toute sécurité :-)

terraform plan
[...]
Terraform will perform the following actions:
# aws_route53_record.mytxtrecord will be updated in-place
~ resource "aws_route53_record" "mytxtrecord" {
fqdn = "awesomeexample.org"
id = "ABCDE1234567890_awesomeexample.org_TXT"
name = "awesomeexample.org"
~ records = [
+ "newtxtstring=veryimportantdata",
"existingsuperimportantdata",
]
~ ttl = 300 -> 60
type = "TXT"
zone_id = "ABCDE1234567890"
}
Plan: 0 to add, 1 to change, 0 to destroy.

Informations/sources additionnelles

Création d’un DynHost avec le nouveau manager OVH

Wed, 24 Jun 2015 15:51:50 +0000

Cet article fait suite à un précédent article qui explique pas à pas comment mettre en place le client permettant de mettre à jour votre DNS OVH si votre IP n’est pas fixe. Je vous conseille d’y jeter un œil après celui ci, si vous êtes intéressés par DynHost.

Pour rappel, DynHost est un service qui au même titre que No-IP ou DynDNS, permet de mettre à jour de manière dynamique une adresse IP dans un DNS si elle est dynamique. C’est particulièrement pratique dans le cas de l’auto hébergement sur un ISP comme Orange, qui ne propose pas (ou pas vraiment) d’IP fixe pour les lignes ADSL pour particuliers.

L’avantage est que le service est gratuit et intégré à votre « manager » si vous disposez d’un domaine chez OVH, ce qui est mon cas.

Jusqu’à il y a peu, lorsqu’OVH a migré vers le nouveau manager (beaucoup plus joli), il n’était plus possible de créer, de modifier ni même de voir les champs de type « DynHost » dans la partie DNS de votre compte. Cela ne pouvait plus se faire que depuis l’ancien manager, heureusement encore disponible.

C’est maintenant de nouveau disponible, et voici un petit tuto pour vous guider car la documentation d’OVH n’est pas à jour.

Création du compte

La première chose à faire est de se connecter dans votre Manager OVH, puis de vous connecter dans la partie « Domaines ».

Une fois le domaine sélectionné, si vous allez dans le sous menu « DynHost », il ne devrait pour l’instant rien y avoir.

Il faut commencer par cliquer sur « Gérer les accès », puis « Créer un identifiant ». Un formulaire de création de compte s’ouvrira. Le plus simple est de juste mettre votrdomaine.fr-dynh0st comme login, et dynh0st.votredomaine.fr comme sous-domaine.

Conservez bien ce login/mdp, il sera à renseigner dans le client de mise à jour du DynHost.

Entrée DynHost dans la zone DNS

A partir de là, le compte est créé. Mais pour l’instant votre DNS n’a toujours pas connaissance de ce sous domaine. Pour cela, il faut revenir dans l’onglet DynHost, et créer une entrée en cliquant sur « Ajouter un DynH0st ».

Renseignez les champs avec d’une part le sous domaine que vous avez renseigné lors de la création du compte, d’autre part l’adresse IP actuelle vers laquelle vous voulez que votre DynH0st redirige.

Si vous hébergez plusieurs applications chez vous (et surtout si vous disposez d’un reverse proxy), le plus « propre » est de créer des alias pour chacune d’entre elle qui pointeront sur le sous domaine. Ainsi, lorsque celui ci sera mis à jour, tous vos sous domaines associés le seront également.

Par exemple, imaginons que vous hébergez un wiki mediawiki et un blog wordpress :

dynmediawiki.votredomaine.fr sera un alias de dynhost.votredomaine.fr
dynblog.votredomaine.fr sera un alias de dynhost.votredomaine.fr
dynhost.votredomaine.fr sera mis à jour automatiquement à chaque bascule de votre adresse IP dynamique

Sous le manager OVH, ça se traduirait par la configuration suivante :

Pour aller plus loin, et notamment la configuration du client pour mettre à jour le DynHost depuis chez vous :

DNS on Zwindler's Reflection