OpenStack : Installation de Designate (DNSaaS)

OpenStack : Installation de Designate (DNSaaS)

Comme nous l’avons vu dans notre dernier article sur Openstack , plusieurs modules ont été développés afin d’enrichir cette plate-forme IaaS. L’utilisation d’Openstack a suscité un grand intérêt de la part de ses utilisateurs afin d’intégrer un service de DNS, notamment pour les développeurs. Cela leur permet d’avoir à disposition un moyen plus simple et sécurisé d’utiliser un nom de domaine lors de leur développement afin de référencer leurs serveurs d’application plutôt que d’utiliser une adresse IP.

C’est ainsi que le projet de mettre en place un service de DNS fut introduit pour Openstack.

Le projet s’appelait au départ Moniker mais fut rapidement rebaptisé Designate.

Designate : DNS as a Service

Le module Designate permet d’interagir avec un serveur DNS préalablement installé afin de créer, mettre à jour ou effacer une entrée DNS en utilisant son API.

L’architecture de Designate a été basée sur les même concepts que les autres modules Openstack. Pour résumé, les briques principales offrent les fonctionnalités suivantes :

  • Un REST API pour les utilisateur afin d’interagir avec le back-end DNS
  • Le DNS Central qui gère les requêtes RPC via un bus de messagerie (RabbitMQ)
  • Intercepter les requêtes DNS (NOTIFY et AXFR) et les envoie aux back-end enregistré.
  • Délégue l’authentification à Keystone

Openstack Designate architecture

Installation

Je détaillerai dans cet article les étapes à réaliser pour la mise en place du module Designate sur une VM. Quelques détails sur la configuration :

OS : Ubuntu 14.04 RAM : 2GB Disk : 10 GB Openstack : Liberty Réseau Management : 10.0.0.0/24

Préparation de l’environnement :

On active le repository d’Openstack Liberty sur le système :

$ sudo apt-get update 
$ sudo apt-get install software-properties-common 
$ sudo add-apt-repository cloud-archive:liberty  

Mise à jour du système :

$ sudo apt-get update  
$ sudo apt-get dist-upgrade

Installation du la base de données MariaDB.

$ sudo apt-get install mariadb-server python-pymysql 

Installation et configuration du bus de messagerie RabbitMQ. On ajoute un utilisateur avec son mot de passe et attribue ainsi les permissions nécessaires :

$ sudo apt-get install rabbitmq-server 
$ sudo rabbitmqctl add_user openstack-designate DESIG-RABBIT-PASSWORD 
$ sudo rabbitmqctl set_permissions openstack-designate ".*" ".*" ".*" 

Installation du serveur DNS

Designate supporte actuellement plusieurs backends, tels que PowerDNS, Bind, NSD, DynECT. Pour ce tutorial, nous utiliserons Bind9.

$ sudo apt-get install bind9

Commençons par configurer Bind afin de permettre la création de plusieurs zones, ce qui permettra pour chaque tenant d’avoir une zone dédiée au nom de domaine de ses VM. On édite alors le fichier /etc/bind/named.conf.options, en ajoutant à la fin, les 3 lignes suivantes :

$ sudo vi /etc/bind/named.conf.options >
 [...] 
 allow-new-zones yes;
 request-ixfr no;
 recursion no; 
};

On redémarre ensuite le service :

$ sudo service bind9 restart

Installation de Designate

On lance maintenant l’installation de Designate. Des demandes de configuration sont proposées pendant le lancement :

 $ sudo apt-get install designate >
  Set up a database for Designate ? - Yes
  IP adresse of your RabbitMQ host : - localhost 
  Username for connection to the RabbitMQ server: - openstack-designate 
  Password for connection to the RabbitMQ server: - DESIG-RABBIT-PASSWORD 
  Authentication server hostname (keystone) : - 127.0.0.1 
  Authentication server password : - DESIG-KEYSTONE-PASSWORD 
  Register Designate in the Keystone endpoint catalog ? - No 
  Configure database for designate-common with dbconfig-common - Yes 
  Database type to b used by designate-common: - mysql 
  Password of the database’s administrative user : - DESIG-DATABASE-PASSWORD 
  MySQL application password for designate-common: - DESIG-COMMON-DATABASE-PASSWORD

On enregistre les informations nécessaires à la plate-forme Openstack afin qu’elles soient reconnues par les autres services, notamment Keystone et le client Openstack. Cela permettra alors d’authentifier les requêtes à l’aide des tokens utilisés vers l’API de Designate.

Création de l’utilisateur Designate dans Keystone :

$ openstack user create --password-prompt designate 
User Password: DESIGNATE-KEYSTONE-PASSWORD  

Associer le rôle admin sur le tenant Service à l’utilisateur Designate :

$ openstack role add --project service --user designate admin 

Création service dns et des endpoints :

$ openstack service create --name designate --description "Openstack DNS service" dns 
$ openstack endpoint create --region RegionOne dns \
  --publicurl http://10.0.0.10:9001 \
  --internalurl http://10.0.0.10:9001 \
  --adminurl http://10.0.0.10:9001 

Configuration de designate

Editez le fichier de configuration de Designate /etc/designate/designate.conf afin de changer les paramètres suivants :

  • Dans la section [service:api] pour la stratégie d’authentification et accès api :
[service:api] 
api_host = 10.0.0.10  
api_port = 9001  
auth_strategy = keystone  
enable_api_v1 = False  
enable_api_v2 = True  
enabled_extensions_v2 = quotas, reports  
api_base_uri = 'http://10.0.0.10:9001/'  

Comme il est conseillé de ne plus utiliser la v1, on spécifie ici l’utilisation de l’api V2 uniquement.

  • Section [keystone_authtoken] pour l’authentification avec keystone :
[keystone_authtoken] 
auth_host = 10.0.0.10  
auth_port = 35357  
auth_protocol = http  
admin_tenant_name = service  
admin_user = designate  
admin_password = DESIG-KEYSTONE-PASSWORD  
  • Section [storage:sqlalchemy] et [poolmanagercache:sqlalchemy] pour la connexion à la BDD MySQL :
[storage:sqlalchemy] 
connection = mysql+pymysql://designate-common:DESIG-DATABASE-PASSWORD@localhost/designatedb

[pool_manager_cache:sqlalchemy] 
connection = mysql+pymysql://designate-common:DESIG-DATABASE-PASSWORD@localhost/designate_pool_manager  

A ce stade, il faut redémarrer les services api et central afin qu’ils se connectent bien au bus de messagerie sans erreurs. Continuons ensuite avec la création de la base de données dédiée au pool_manager.

$ sudo service restart designate-api 
$ sudo service restart designate-central 
$ mysql -u root -p > CREATE DATABASE `designate_pool_manager` CHARACTER SET utf8 COLLATE utf8_general_ci; > GRANT ALL PRIVILEGES ON designate_pool_manager.* TO 'designate-common'@'localhost' IDENTIFIED BY 'DESIG-DATABASE-PASSWORD';

Il faut ensuite installer les derniers paquets de la suite Designate et initialiser de leur base de données :

$ sudo apt-get install designate-pool-manager designate-mdns 
$ sudo su -s /bin/sh -c "designate-manage pool-manager-cache sync" designate

Même si les bases ont été créées, aucun nameserver n’est enregistré. Ce nameserver, qui correspond au serveur DNS, est reconnu par un identifiant se trouvant à la fois sur la base de données et dans le fichier de configuration.

La création du nameserver peut se faire directement via l’api de Designate.

Au moment de mes tests, aucun client, que ce soit Designate-client ou Openstack-client, ne possédait de méthodes pour envoyer les requêtes pour la configuration du pool.

J’ai donc eu recours à un script qui définit le payload nécessaire pour la création du nameserver via l’api du pool manager. (scripts disponible sur github )

# create-ns.py 
# Python script to create NameServer for designate api v2 
# Author : Pascal 
# Date : July 2016 
import os  
import json  
import urllib2  
import requests 

keystone_url = "http://10.0.4.15:5000/v2.0"  
designate_url = "http://10.20.0.3:9001/v2"  
payload_auth = '{ "auth": { \ "tenantName": "admin", \ "passwordCredentials": { \ "username": "admin", \ "password": "nova" \ }}}' payload_ns = '{ "name": "DevStack-OS Example Pool", \ "ns_records": [{ \ "hostname": "ns1.wescaleblog.fr.", \ "priority": 1 }]}'  
headers = { 'content-type' : 'application/json', 'accept' : 'application/json' }

def getToken():  
 token = requests.post(keystone_url + "/tokens",  data=payload_auth, headers=headers)
 print token.status_code 
 #print token.text
 return json.loads(token.text) 

data = getToken()  
print "New token :"  
print data["access"]["token"]["id"]  
headers = { 'content-type' : 'application/json', 'accept' : 'application/json', 'x-Auth-Token' : data["access"]["token"]["id"] }  
response = requests.post(designate_url + "/pools", data=payload_ns, headers=headers)  
print "New pool ID : " + json.loads(response.text)["id"]  

Au lancement, le script récupère l’identifiant du nameserver qui fut créé en base afin de le renseigner dans les configurations de Designate.

$ python create-ns.py >
 [...] 
 New pool ID : 271482b4-5d0c-4d88-9e89-c02861980596

 $ vi /etc/designate/designate.conf > 
[service:central] 
Default_pool_id = ‘271482b4-5d0c-4d88-9e89-c02861980596’

[service:pool_manager] 
pool_id = ‘271482b4-5d0c-4d88-9e89-c02861980596’

[pool:271482b4-5d0c-4d88-9e89-c02861980596] 
nameservers = 0f66b842-96c2-4189-93fc-1dc95a08b012  
targets = f26e0b32-736f-4f0a-831b-039a415c481e 

[pool_nameserver:0f66b842-96c2-4189-93fc-1dc95a08b012]
port = 53  
host = 10.0.0.10 

[pool_target:f26e0b32-736f-4f0a-831b-039a415c481e]
options = port: 53, host: 10.0.0.10  
masters = 10.0.0.10:5354  
type = bind9  

On redémarre ensuite tous les services Designate pour enfin commencer la création des zones et des noms de domaine sur notre tenant. En cadeau, un petit script plutôt pratique pour l’opération :

#!/bin/bash 
# designate.sh
echo "$1 Designate services "  
for DESIG_SERVICE in `ls /etc/init.d/designate-* | awk -F '/' ' { print $4;}'`; do  
 if [ $DESIG_SERVICE != "designate-agent" ]; then
  service $DESIG_SERVICE $1 
 fi 
done  
$ sudo chmod +x designate.sh 
$ sudo ./designate.sh restart >
 restart Designate services designate-api stop/waiting designate-api start/running, process 22082 designate-central stop/waiting designate-central start/running, process 22112 designate-mdns stop/waiting designate-mdns start/running, process 22135 designate-pool-manager stop/waiting designate-pool-manager start/running, process 22154

On peut maintenant créer nos zones et associer l’adresse IP flottante d’une de nos VMs à un nom de domaine :

$ openstack zone create --email pascal.edouard@wescale.fr --description “New zone” newtenant.wescaleblog.fr.

La zone se crée en état PENDING, le temps que Designate communique avec le serveur afin de créer l’entrée DNS nécessaire.

$ openstack zone list | grep 'newtenant.wescaleblog.fr'|awk '{print $2}' > 9222d823-1f55-447c-92a4-be1fd1cf0450 
$ openstack recordset create 9222d823-1f55-447c-92a4-be1fd1cf0450 --records 172.24.4.3 --ttl 3600 --type A --description "My Web app" mywebapp.newtenant.wescaleblog.fr.

On réalise alors un test afin de vérifier que la machine qui se trouve à l’adresse 172.24.4.3 est bien accessible par son nouveau nom de domaine :

$ ping mywebapp.newtenant.wescaleblog.fr > 
PING mywebapp.newtenant.wescaleblog.fr (172.24.4.3) 56(84) bytes of data.  
64 bytes from 172.24.4.3: icmp_seq=1 ttl=63 time=1.77 ms  
64 bytes from 172.24.4.3: icmp_seq=2 ttl=63 time=0.480 ms  
64 bytes from 172.24.4.3: icmp_seq=3 ttl=63 time=0.485 ms  

Conclusion

Le DNS a toujours été un service essentiel dans la gestion d’une architecture réseau et d’autant plus lorsqu’il s’agit du cloud. L’arrivée du DNS as a Service sur l’infrastructure Openstack est donc un point important et bien reçu par la communauté. Cependant, il reste encore des améliorations à apporter et simplifications d’installation à certains niveaux. Designate fonctionne bien une fois installé, et répond correctement au besoin des administrateurs et des développeurs, surtout au niveau de l’automatisation d’enregistrement des noms de domaine pour leurs applications.

* J’espère que cet article vous a aidé dans l’installation de Designate, n’hésitez pas à laisser un commentaire si vous avez des remarques ou des questions supplémentaires. *