Ansible et OpenStack

Précédemment, on a pu voir les possibilités de créer automatiquement un mini réseau virtuel sous OpenStack en faisant notamment appel à son module d’orchestration Heat. Pour ceux qui ont leurs habitudes avec Ansible, il est possible d’automatiser de façon similaire un déploiement grâce à son module Cloud.

Nous allons reprendre l’infrastructure cible des précédents articles. Il s’agit d’une petite infrastructure virtuelle avec deux réseaux séparés par un routeur. Chaque réseau possède un serveur pouvant communiquer en ICMP avec le serveur du réseau voisin.

À l’image de Heat avec ses templates, Ansible demande de fournir des playbooks au formal yaml décrivant les actions à mener.

OpenStack est déployé sur un serveur à l’aide de DevStack et dans notre exemple, on lancera Ansible de ce même serveur. On cible donc dans notre fichier playbook nommé « deploy.yaml » uniquement localhost.

---
- hosts: localhost

Dans nos tâches, on commence par créer nos deux réseaux.

  tasks:
  - name: Création reseau1
    os_network:
      name: reseau1
  - name: Création reseau2
    os_network:
      name: reseau2

Puis on continue par les sous-réseaux en spécifiant explicitement les adresses des passerelles pour bien respecter notre schéma réseau.

  - name: Création subnet1
  os_subnet:
    name: subnet1
    network_name: reseau1
    cidr: 192.168.1.0/24
     gateway_ip: 192.168.1.254
 - name: Création subnet2
   os_subnet:
     name: subnet2
     network_name: reseau2
     cidr: 192.168.2.0/24
     gateway_ip: 192.168.2.254

Poursuivons avec la création du routeur en spécifiant les deux interfaces pour les lier aux deux sous-réseaux précédents.

  - name: Création du routeur
    os_router:
      name: routeur1
      interfaces:
      - subnet1
      - subnet2

Nous pouvons maintenant instancier les deux serveurs. Le paramètre « auto_ip » est défini à no car l’attribution du IP flottante ne nous intéresse pas dans notre exemple.

  - name: Création du serveur1
  os_server:
    name: server1
    auto_ip: no
    flavor: m1.nano
    image: cirros-0.3.4-x86_64-uec
    network: reseau1
  - name: Création du serveur2
  os_server:
    name: server2
    auto_ip: no
    flavor: m1.nano
    image: cirros-0.3.4-x86_64-uec
    network: reseau2

Pour que les deux serveurs puissent se « pinger » et traverser le routeur on ajoute deux règles dans le groupe de sécurité par défaut.

  - name: Autoriser le ping en sortie
  os_security_group_rule:
    security_group: default
    protocol: icmp
    remote_ip_prefix: 0.0.0.0/0
  - name: Autoriser le ping en entrée
  os_security_group_rule:
    security_group: default
    protocol: icmp
    direction: egress
    remote_ip_prefix: 0.0.0.0/0

Il ne reste plus qu’à lancer Ansible en n’oubliant pas auparavant d’avoir un environnement adéquat pour pouvoir s’authentifier via Keystone :

$ source demo-openrc.sh
$ ansible-playbook deploy.yaml

[WARNING]: provided hosts list is empty, only localhost is available
PLAY ***************************************************************************

TASK [Création reseau1] ********************************************************
changed: [localhost]

TASK [Création reseau2] ********************************************************
changed: [localhost]

TASK [Création subnet1] ********************************************************
changed: [localhost]

TASK [Création subnet2] ********************************************************
changed: [localhost]

TASK [Création du routeur] *****************************************************
changed: [localhost]

TASK [Création du serveur1] ****************************************************
changed: [localhost]

TASK [Création du serveur2] ****************************************************
changed: [localhost]

TASK [Autoriser le ping en sortie] *********************************************
changed: [localhost]

TASK [Autoriser le ping en entrée] *********************************************
changed: [localhost]

PLAY RECAP *********************************************************************
localhost : ok=9 changed=9 unreachable=0 failed=0

Chaque tâche est exécutée avec succès et renvoie le statut « changed » signifiant que la totalité de nos objets sont déployés. On peut relancer le déploiement et le status « changed » devrait être à 0 indiquant qu’aucune action n’a été réalisé. L’avantage est qu’on peut modifier les tâches d’un playbook et relancer Ansible qui se chargera de modifier les objets concernés en conséquence. Une tâche qui a été modifié renverra le statut « changed ».

Ansible possède un inconvénient par rapport à Heat sur la suppression des objets créés. Il faudra refaire un playbook en décrivant chaque tâche de suppression. Avec l’orchestrateur Heat, la suppression est bien plus simple puisqu’il suffit juste de supprimer la stack créé ce qui impliquera également la suppression de tous les objets liés.
L’exemple ci-dessus est relativement simple et il est possible d’aller bien plus loin avec Ansible. Par exemple lancer des instances et dans ces mêmes instances créées, lancer et configurer des services.