Solution Ansible

1. Terminologie Ansible

En vue de contrôler des noeuds distants, des utilisateurs lancent des “playbooks” à partir d’un noeud de contrôle grâce à Ansible Engine.

Ansible Engine est composé de :

  • Modules
  • Plugins
  • API
  • Inventaire (inventory)

Ansible Engine connecte et se pratique de manière différente sur les hôtes terminaux (Linux/Unix et Windows) et les périphériques du réseau. Il s’agit de périphériques dont les missions et la gestion sont bien différentes.

2. Machine de contrôle

Les machines de contrôle doivent être un hôte Linux / Unix (par exemple, Red Hat Enterprise Linux, Debian, CentOS, OS X, BSD, Ubuntu), et Python 2.6 ou 2.7 est requis (le support Python 3 est disponible en tant que “tech preview” depuis ansible 2.2). Avec une version Windows 10 Pro, il est possible d’utiliser de commander Ansible avec WSL, voir Can Ansible run on Windows?

{% hint style=‘working’ %} Installation Ansible {% endhint %}

3. Noeuds gérés

Les noeuds gérés, s’ils sont en Linux/Unix, doivent disposer de Python 2.4 ou version ultérieure. Pour les noeuds gérés avec Python 2.5 ou antérieur, le paquet python-simplejson est également requis.

Depuis sa version 1.7, Ansible peut également gérer les noeuds Windows. Dans ce cas, on utilise PowerShell à distance de manière native au lieu de SSH.

Le matériel d’infrastructure réseau (constructeurs), pare-feux, serveurs de stockage, fournisseurs IaaS, solutions de virtualisation sont supportés via SSH, NETCONF/YANG ou encore via API HTTP REST.

{% hint style=‘working’ %} Plugins de connexion {% endhint %}

Fonctionnement Ansible

How Network Automation is Different

Clés SSH

Les mots de passe sont pris en charge, mais la gestion des clés SSH avec ssh-agent est l’un des meilleurs moyens d’utiliser Ansible. Il est également possible parmi beaucoup de possibilités des authentifications Kerberos ou autres. Les connexions “root” ne sont pas obligatoires, on peut se connecter en tant qu’utilisateur, et puis utiliser “su” ou “sudo”. Le module “authorized_key” d’Ansible est un excellent moyen d’utiliser Ansible pour contrôler quelles machines peuvent accéder à quels hôtes.

ssh-agent bash
ssh-add ~/.ssh/id_rsa

{% hint style=‘working’ %} protocole SSH {% endhint %}

4. L’inventaire

Inventory

Par défaut, Ansible représente les machines qu’il gère à l’aide d’un fichier INI très simple qui place toutes les machines gérées dans des groupes de votre choix. On peut le représenter dans d’autres formats comme YAML.

Pour ajouter de nouvelles machines, aucun serveur de signature supplémentaire n’est nécessaire, alors que NTP ou DNS sont critiques au moment des authentifications.

S’il existe une autre source de confiance dans votre infrastructure, Ansible peut également y ajouter des éléments tels que des informations d’inventaire, de groupe et variables à partir de sources telles que EC2, Rackspace, OpenStack, etc.

CMDB

Voici à quoi ressemble un fichier d’inventaire en format INI :

[webservers]
www1.example.com
www2.example.com

[dbservers]
db0.example.com
db1.example.com

Une fois que les hôtes d’inventaire sont répertoriés, des variables peuvent leur être attribuées dans des fichiers texte simples (dans un sous-répertoire appelé ‘group_vars/’ ou ‘host_vars/’) ou directement dans le fichier d’inventaire.

Aussi, on peut utiliser un inventaire dynamique pour extraire un inventaire de sources de données telles que EC2, Rackspace ou OpenStack.

{% hint style=‘working’ %} Fichiers d’inventaire {% endhint %}

5. Modules

Modules et Tasks

Les modules sont “les outils dans la boîte-à-outils”.

Ansible fonctionne en se connectant aux noeuds à gérer et en leur envoyant des petits programmes, appelés «modules Ansible». Ces programmes sont écrits pour être des modèles de ressources de l’état souhaité du système. Ansible exécute ensuite ces modules (via SSH par défaut) grâce au protocole JSON sur la sortie standard et les supprime lorsque l’action est terminée.

La bibliothèque de modules peut résider sur n’importe quelle machine et sans aucun serveur central, démon ou base de données. En général, l’administrateur travaille avec son programme de terminal favori, un éditeur de texte et probablement un système de contrôle de version pour suivre les modifications apportées à son contenu.

Rien n’interdit d’écrire son propre module. Ces modules peuvent contrôler les ressources comme des services, des paquets ou des fichiers (n’importe quoi en réalité), ou encore exécuter des commandes système. 1

{% hint style=‘working’ %} Découverte des modules {% endhint %}

6. Plugins

Plugins

{% hint style=‘working’ %} Types de plugins {% endhint %}

7. Exécution des tâches

Concept de tâche. –> module local. Tout le code utile à l’exécution est local –> importance des màj.

  • Ad-Hoc
  • Livre de jeux
  • Roles
  • Ansible Tower

8. Le mode Ad Hoc

Le mode Ad-Hoc permet l’exécution de tâches parallèles.

Dès qu’une instance est disponible, on peut lui parler immédiatement, sans aucune configuration supplémentaire, ici sur une instance Red Hat:

ansible all -m ping
ansible foo.example.com -m yum -a "name=httpd state=installed"
ansible foo.example.com -a "/usr/sbin/reboot"

Un accès à des modules de ressources basés sur des états, ainsi qu’à des commandes “raw” est disponible. Ces modules sont extrêmement faciles à écrire. Par ailleurs, Ansible est livré avec énormément de modules déjà développés (plus de 750) de telle sorte qu’un bonne partie du travail est déjà réalisée.

{% hint style=‘working’ %} Mode Ad-Hoc {% endhint %}

9. Playbooks (Livres de jeu)

Playbooks

Les livres de jeu (playbooks) sont écrits selon un langage d’automatisation simple et puissant. Les Playbooks peuvent orchestrer avec précision plusieurs parties d’une topologie d’infrastructure, avec un contrôle très détaillé du nombre de machines à traiter à la fois.

L’approche d’Ansible en matière d’orchestration est une approche simple et précise : le code d’automatisation devrait être pérenne et il devrait y avoir très peu de choses à retenir sur la syntaxe ou des fonctionnalités spéciales.

Les livres de jeu (playbooks) sont écrits en langage YAML, Ain’t Markup Language. YAML expose un minimum de syntaxe et propose un modèle de configuration ou de processus plutôt qu’un langage de script ou de programmation.

Chaque livres de jeu est composé de un ou plusieurs “séances de jeu (plays)” dans une liste.

Un jeu est une analogie sportive qui définit un état ou un modèle et qui se “rejoue” de différentes manières à d’autres moments.

Le but d’un “jeu” est de faire correspondre un “groupe” contenant des “hôtes (hosts)” dans des “roles” bien définis représentés par des objets Ansible appelés des “tâches (tasks)”. Sur le plan fondamental, une “tâche” Ansible n’est rien de plus qu’un appel à un module Ansible accompagné de paramètres. Un module est script Ansible en vue de réaliser certaines actions sur les “hôtes”.

Un module est généré sur le contrôleur, il est copié, exécuté et effacé sur les noeud dans le cadre de l’automation des serveurs. Par contre , quand il s’agit de gérer des périphériques réseau, un module est généré et exécuté localement sur le contrôleur.

En composant un “livre de jeu” avec plusieurs “jeux” sous forme de liste, il est possible d’orchestrer un déploiement multi-machines, en exécutant certaines tâches dans un groupe de routeurs, certaines tâches dans un groupe de commutateurs, et encore d’autres commandes dans un autre groupe de périphériques …

En conclusion, un “livre de jeu” consiste à :

  • exécuter des “tâches (tasks)” pour un “inventiare (inventory)” d’”hôtes (hosts)” rassemblés en “groupes”,
  • utilisant certains modules,
  • utilisant ou peuplant certaines variables,
  • à travers certains modèles (templates) de fichiers.

Un “livre de jeu” organise des tâches. Mais il de bonne pratique de l’organiser en “roles”. Un “role” ajoute un niveau d’abstraction dans l’exécution d’un livre de jeu.

---
- name: DEPLOY VLANS
  hosts: access
  connection: network_cli
  gather_facts: no
  tasks:
    - name: ENSURE VLANS EXIST
      nxos_vlan:
        vlan_id: 100
        admin_state: up
        name: WEB
- name: Configure webserver with nginx
  hosts: webservers
  become: True
  become_method: sudo
  tasks:
    - name: install nginx
      apt:
        name: nginx
        update_cache: yes
    - name: copy nginx config file
      copy:
        src: files/nginx.conf
        dest: /etc/nginx/sites-available/default
    - name: enable configuration
      file:
        dest: /etc/nginx/sites-enabled/default
        src: /etc/nginx/sites-available/default
        state: link
    - name: copy index.html
      template:
        src: templates/index.html.j2
        dest: /usr/share/nginx/html/index.html
        mode: 0644
    - name: restart nginx
      service:
        name: nginx
        state: restarted
- name: DEPLOY DRUPAL
  hosts: webserver
  vars_files:
    - vars/main.yml
  roles:
    - apache
    - mysql
    - php
    - php-mysql
    - composer
    - drush
    - drupal

3. États des tâches

4. Idempotence

« Being idempotent allows the defined task to run one time or a thousand times without having an adverse effect on the target system, only ever making the change once. In other words, if a change is required to get the system into its desired state, the change is made; and if the device is already in its desired state, no change is made. This is unlike most traditional custom scripts and the copy and pasting of CLI commands into a terminal window. When the same command or script is executed repeatedly on the same system, errors are (sometimes) raised. »

Extrait de: Jason Edelman. « Network Automation with Ansible. », O’Reilly Media, 2016.

En français : “Être idempotent permet à une tâche définie d’être exécutée une seule fois ou des centaines de fois sans créer un effet contraire sur le système cible, ne provoquant un changement à une seule reprise. En d’autres mots, si un changement est nécessaire pour obtenir le système dans un état désiré, alors le changement est réalisé ; par contre si le périphérique est déjà dans l’état désiré, aucun changement n’intervient. Ce comportement est différent des pratiques de scripts personnalisés et de copier/coller de lignes de commandes. Quand on exécute les mêmes commandes ou scripts sur un même système de manière répétée, le taux d’erreur est souvent élevé.”

5. Les rôles

Roles

Les rôles (roles) permettent de charger automatiquement des _varsfiles, des tasks, des handlers sur base d’une structure de fichier définie. Les rôles sont intéressants pour leur aspect “ré-utilisable”. Par contre, peu d’éléments permettent d’évaluer la qualité de ces propositions de code “ré-utilisable”.

6. Ansible Tower

Ansible Tower est un API, un service Web et une console Web conçue pour rendre Ansible utilisable pour les équipes informatiques avec différents profils. Ansible Tower dispose de toute une gestion des contrôle d’acccès basé sur des rôles. C’est une console centrale de gestion des tâches d’automatisation. Tower est un produit commercial pris en charge par Red Hat, Inc. Red Hat a annoncé à l’AnsibleFest 2016 que Tower passait en Open Source. En 2017, Tower est publié en opensoucé sous le nom de AWX. Semaphore est une alternative open source à Ansible Tower, écrit en Go.2

agentless

Roles 1

Ansible Tower

Roles 1

Voir AWX.