Automatisation, de Python à Ansible

Informations

• Publié par: gmoisio
• Date de parution: 27 janvier 2018
• Nombre de lectures: 133
• Langue: Français

Extrait

AUTOMATISATION, DE PYTHON À
ANSIBLE
MINI GUIDE
GILBERT MOÏSIO
ALEX FAIVREAutomatisation, de Python à Ansible de Gilbert MOÏSIO est mis à disposition selon les termes
de la licence Creative Commons Attribution - Pas d’Utilisation Commerciale - Partage dans les
Mêmes Conditions 4.0 Ceci peut être votre site web principal ou la page d’informations vous
concernant sur une plate forme d’hébergement, comme Flickr Commons., except where
otherwise noted.
L i c e n c e
Vous êtes autorisé à :
– Partager — copier, distribuer et communiquer le matériel par tous moyens et sous tous
formats
– Adapter — remixer, transformer et créer à partir du matériel
L’Offrant ne peut retirer les autorisations concédées par la licence tant que vous appliquez les
termes de cette licence.
Selon les conditions suivantes :
– (BY) Attribution — Vous devez créditer l’Œuvre, intégrer un lien vers la licence et indiquer si
des modifications ont été effectuées à l’Œuvre. Vous devez indiquer ces informations par tous
les moyens raisonnables, sans toutefois suggérer que l’Offrant vous soutient ou soutient la
façon dont vous avez utilisé son Œuvre.
– (NC) Pas d’Utilisation Commerciale — Vous n’êtes pas autorisé à faire un usage commercial
de cette Œuvre, tout ou partie du matériel la composant.
– (SA) Partage dans les Mêmes Conditions — Dans le cas où vous effectuez un remix, que
vous transformez, ou créez à partir du matériel composant l’Œuvre originale, vous devez
diffuser l’Œuvre modifiée dans les même conditions, c’est à dire avec la même licence avec
laquelle l’Œuvre originale a été diffusée.
Pas de restrictions complémentaires — Vous n’êtes pas autorisé à appliquer des conditions
légales ou des mesures techniques qui restreindraient légalement autrui à utiliser l’Œuvre
dans les conditions décrites par la licence.
Notes :
Vous n’êtes pas dans l’obligation de respecter la licence pour les éléments ou matériel
appartenant au domaine public ou dans le cas où l’utilisation que vous souhaitez faire est
couverte par une exception. Aucune garantie n’est donnée. Il se peut que la licence ne vous
donne pas toutes les permissions nécessaires pour votre utilisation. Par exemple, certains
droits comme les droits moraux, le droit des données personnelles et le droit à l’image sont
susceptibles de limiter votre utilisation.
ISBN Ebook – 979-10-96574-06-3
ISBN Papier – 979-10-96574-07-0Contents
Crédits images
Préface
Part I. Python
1. Positionnement
2. Fondamentaux
3. Connexion SSH
4. Netmiko
5. Napalm
6. pyntc
7. Utilisation de modèles
Part II. Ansible
8. Introduction
9. Démarrage
10. Playbooks
11. Templates
12. Exemple système
13. Exemple réseau
14. Astuces
Pour aller plus loin
Auteurs
BibliographieCrédits images
Image de couverture : basée sur une création de kmlmtz66/123RF
Avatars : Guillaume LAMARQUEP r é f a c e
La méthode traditionnelle utilisée pour manipuler les réseaux consiste à se connecter
manuellement avec un compte et un mot de passe sur les équipements et entrer des
commandes ou copier/coller des commandes préparées dans un éditeur de texte.
Certains constructeurs possèdent des processus plus ou mois évolués pour revenir en
arrière en cas de problème, mais la moindre petite erreur peut engendrer un
dysfonctionnement sur l’ensemble du réseau.
Améliorer les méthodologies a pour objectifs d’améliorer la disponibilité et la sécurité
des réseaux, mais aussi de mieux répondre aux méthodes inspirées de l’approche
Agile maintenant utilisées dans le monde des réseaux. Depuis le provisionnement ZTP
(Zero Touch Provisioning) ou ZTD (Zero Touch Deployment) jusqu’à l’intégration
continue, en passant par la collecte de données, la migration, la gestion de
configuration, le test de conformité, le tableaux de bord et le diagnostic,
l’automatisation apporte des solutions à chacune des étapes.
Il n’est pas question de créer une confusion entre les différentes composantes d’un
équipement réseau. Le “Data Plane” a pour mission de gérer la “Forwarding Table” au
plus prêt du matériel et de faire passer les trames d’un port d’entrée vers un port de
sortie. Le “Control Plane” utilise sa mémoire et sa CPU pour faire tourner un système
d’exploitation dont la mission est de découvrir le réseau, de gérer des protocoles
d’états de niveau 2 ou de niveau 3 tels que STP (Spanning Tree Protocol), SPB
(Shortest Path Bridging), OSPF (Open Shortest Path First), BGP (Border Gateway
Protocol), …, de prendre en charge les trames dont le destinataire n’est pas connu et
plus généralement de mettre à jour la “Forwarding Table” du “Data Plane”. Le
“Management Plane” s’occupe de la partie orchestration en offrant des protocoles de
communication, tels que Telnet (Terminal Network), SNMP (Simple Network
Management Protocol), SSH (Secure SHell), HTTPS (HyperText Transfer Protocol
Secure)…, aux administrateurs afin d’interagir avec l’équipement.
Open SDN (Software-Defined Networking) et plus particulièrement le protocole
OpenFlow, dont on a tant entendu parler, consiste à séparer physiquement le “Control
Plane” du “Data Plane”, avec pour objectif d’offrir un “Control Plane” commun ayant une
vue centralisée du réseau et d’apporter une synchronisation adaptée. Ce n’est pas de
ce débat dont il est question ici.
Le “Management Plane” tend à évoluer pour passer des accès SNMP et
SSH/Telnet/CLI, au protocole NETCONF (Network Configuration Protocol), puis aux API
REST (Application Programming Interfaces REpresentational State Transfer). Le format
de transfert des données entre l’équipement et l’administrateur se structure également
pour passer du mode texte pur au XML (YANG utilisé par NETCONF) ou au JSON
(JavaScript Object Notation). Cependant, lors du salon INTEROP 2016 à Las Vegas, il
a été mis en évidence que seuls 15% à 20% des équipements supportaient des APIs
ou le protocole NETCONF. De ce fait, le protocole SSH est encore indispensable.Il va sans dire que rien ne vaut Unix, voire Linux, pour héberger tous les outils
nécessaires à l’automatisation. Une bonne connaissance système est indispensable
pour effectuer les configurations nécessaires à la mise en place des moyens intégrés
dans l’infrastructure réseau. L’appel au “NetWork Namespace”, au conteneur de type
Docker, à la virtualisation de type KVM (Kernel Virtual Machine) et au switch virtuel
OVS (Open vSwitch) peut s’avérer un plus pour la mise en place des moyens
opérationnels.
Ne posez pas la question “quelle technologie va l’emporter ?”. Toutes les personnes
d’expérience savent parfaitement, que, chaque fois qu’une technologie voit le jour, elle
est présentée comme “l’arme fatale” avant de trouver sa vraie place souvent constituée
d’une niche.
Pour terminer cette préface, je souhaiterai attirer l’attention sur le fait que, si les scripts
sont extrêmement rapides pour configurer entièrement un réseau en exploitation, ils
peuvent devenir aussi très dangereux. Si aucun réseau d’administration “Out of Band”
n’a été prévu dans la conception de l’architecture, et que la gestion s’effectue par une
méthode “In Band”, toute exécution partielle et interrompue des scripts pourrait laisser
les équipements dans un état injoignable et rendrait laborieux la remise en état de
fonctionnement optimal.
PART I
Python