le - dernière modification le par
Jimena Saez
Ci-dessous vous retrouverez les questions qui ont été répondues par nos experts durant le webcast.
Automatisez le déploiement de Data Centers en utilisant APIs et Terraform.
Nos experts : Francesco Molino (présentateur) et Xavier Crèvecœur (question manager).
Pour plus d'informations, visitez la section Data Center.
Cliquez sur les boutons pour accéder aux contenus proposés
Sujets abordés lors de la présentation : NXOS, EVPN, VxLAN, ACI, APIs, Terraform, Python.
Automatisation Data Center (ACI et NXOS EVPN)
Q : Peut-on considérer Terraform comme « idempotent » au même titre que Ansible ?
R : F.M. - Terraform est effectivement idempotent et donc seulement les changements souhaités seront appliqués.
Q : Est ce qu'il y a un check automatique que ce qui a été poussé à l'APIC n'a pas généré de Fault ?
R : F.M. - Lorsqu’on envoie du code, celui peut avoir 2 statuts : Échec ou Succès. Ce statut est lié simplement au code lui-même, à savoir si la ressource Terraform a été configurée correctement ou pas. Il n’y aura pas de validation pour dire si la donnée est conforme ou pas avec les objets ACI. En revanche, dans ACI, dans chacun des objets, il y a un onglet « Faults » qui lui va vous indiquer si la donnée poussée est conforme ou non avec ce qu’ACI s’attend et/ou si les liaisons sont correctes. Si des ressources sont liées avec d’autres ressources, on peut valider avec Terraform que l’ensemble des données soient poussées et lever une alerte le cas échéant (en combinant les « resources » et « data resources »).
Q : Bonjour, Ansible vs Terraform quelles sont le différences majeures ?
R : F.M. - Tout d’abord, Terraform est un outil d’orchestration versus Ansible qui est dit « Configuration Management ».
Les deux peuvent être utilisés communément, et certains overlaps existent entre ces 2 outils.
L’une des plus grosses différences est que dans un outil d’orchestration, nous allons rechercher la stabilité de notre infrastructure et c’est que va faire Terraform en focalisant sur le « State » de notre infrastructure ; ceci pourra être corrigé rapidement en réexécutant un terraform apply. Avec Ansible, au même titre d’exemple, si quelque chose échoue, il va se focaliser à corriger le bout qui est en échec mais pas remettre l’infrastructure au complet dans son état d’origine ; ce qui peut compliquer la gestion au quotidien. Terraform est l’outil qui décrit le mieux le terme IAC « Infrastructure As Code ». Également la notion de code « procedural » vs « declarative » est important, Ansible aura du code dit « procedural » alors que Terraform est plus en mode « declarative ».
Q : Est ce qu'on peut faire le même script pour les contrats ?
R : F.M. - On peut effectivement utiliser Terraform pour appliquer les contrats et toutes les liaisons y afférentes comme « subjects », « rules »….
Si votre fabrique est déjà provisionnée, contrairement à ce que j’ai fait aujourd’hui, où j’ai fait que du provisioning, il va falloir utiliser les « data ressources » pour aller lire au préalable les informations existantes et ensuite configurer/provisionner vos contrats. Il y a déjà des fonctions de contrats qui sont disponibles avec le provider ACI.
Q : Pourquoi on utilise Terraform au lieu des APIs avec Python et le data en json ou yang. Si je suis déja à l'aise avec ces APIs pour firepower et dcnm, y a t-il un avantage à Terraform pour ACI spécifiquement dû au provider déjà fourni ?
R : F.M. - On va utiliser Terraform pour provisionner une fabrique ACI et prendre en compte son opération en mode DevOps. Oui, si vous êtes à l’aise avec les APIs directement, vous pouvez très bien provisionner votre fabrique. En revanche, ce sera plus compliqué en mode opération pour gérer le statut de ACI et faire un « rollback » en cas de souci. L’idée est de provisionner une infrastructure (ACI, AWS, Azure) et surtout pouvoir gérer les changements et maintenir son statut fonctionnel à tout moment ; ce qui peut être compliqué à gérer manuellement avec votre propre code Python, toujours en prenant en compte la notion de DevOps (automatiser durant des opérations quotidiennes et les possible « rollbacks » pouvant être nécessaire).
Q : Est-ce possible d'avoir un démo sur VxLAN, ACI ou une séance de présentation, svp ?
R : F.M. - La démo VXLAN a eu lieu sur un webcast Community Live (privé) en date du 28 avril 2020 : Community Live - Introduction à VxLAN (BGP-EVPN). Je vous invite fortement à aller regarder le replay de la session.
Pour la partie ACI, nous pourrions organiser un webcast pour avoir un overview/initiation de comment monter une fabrique..
Q : Pourquoi dans NXAPI, on voit que des méthodes de type POST ?
R : F.M. - NXAPI CLI n’est pas structuré en mode REST API avec des fonctions exposées. Il s’agit simplement d’encapsulation de commandes NX-OS au travers du protocole http/https. Au niveau REST API, nous allons avoir la notion de get pour lire de l’information, post pour créer de la donnée, put et delete pour aller modifier et supprimer.
Dans NXAPI CLI, vu que nous encapsulons des commandes NX-OS, qu’on veuille lire ou écrire quelque chose, nous « poussons » des commandes NX-OS d’où le fait que chacune de ces transactions soit en mode POST.
Q : Comment configurer des fonctionnalités dans ACI quand indisponibles avec Terraform ?
R : F.M. - Il existe 3 possibilités :
- Utiliser la fonction aci_rest du provider terraform « aci ». Celle-ci permet de configurer des appels API simples.
- Utiliser une librairie existante si la fonction souhaitée y est disponible
- Développer votre propre code Python pour effectuer l’appel API en créant donc le « header », « payload » et gérer la réponse de cet appel API.
.