Ansible Déploiement, provisionning et configuration 24 Septembre 2015

Contexte GM L’état actuel : Des déploiement hétérogènes Déploiement à la main, un peu répétitif comme tache, non ? Déploiement par scripts (robustesse ??), chacun sa façon de déployer

Contexte GM Les besoins : Pouvoir déployer de manière uniforme la configuration quelque soit l’environnement Limiter les interactions humaines, sources d’erreurs Maitriser le déploiement pour plus de reproductibilité Gérer la scalabilité Les contraintes : Mettre en œuvre une solution rapidement Maitriser les coûts de la solution Automatiser !!

Démystifions un peu Stop aux préjugés ! Je n’aurai plus de travail si tout est automatisé ! FAUX : je serai libéré des taches répétitives, et puis il faudra bien le maintenir cet automate, le faire évoluer En automatisant, l’équipe finira par perdre son expertise ! FAUX : pour automatiser des actions, il faut une excellente connaissance du processus et des outils, on acquière du coup de nouvelles compétences en automatisation Une fois la tache automatisée, on ne peux plus la suivre ! FAUX : Il est plus simple de suivre les logs d’un automate que d’interroger les équipes et compiler leurs retours d’activité

Les outils du marché Pourquoi faire ? Automatiser et rationnaliser Le provisionnement de serveurs La configuration Le déploiement des applications Le déploiement continu Oui mais, pourquoi automatiser ? je sais le faire manuellement avec mon document d’installation Ne pas refaire 2 fois la même chose Ne pas se tromper quand on fait 2 fois la même chose Investir du temps dans ce qui est utile et qui pourra resservir Eviter les tâches répétitives

Les outils du marché Les principaux concurrents :

Ansible, le choix de la raison Pourquoi Ansible : Pas d’agent à déployer sur les machines cibles, connexion directe en ssh (*nix) ou winrm (windows) Courbe d’apprentissage, le langage est simple à comprendre (DSL), il est alors très rapide de mettre en œuvre un premier déploiement Pas de serveur central, n’importe quel machine sous linux peut lancer les opérations Fini les scripts (et de copier/coller), idempotence des actions Ses « limitations » : Vitesse d’exécution : pas d’agent = connexion pour chaque « tache » Gestion des inventaires (par fichier de manière nominale), il est possible d’externaliser ces inventaires, mais pas d’outil « officiel »

Ansible, le choix de la raison Qu’est-ce que je dois connaître ? Un nouveau DSL : connaître les fonctions essentielles Ce qu’est un playbook, ses composants et comment ils s’articulent entre eux Yaml, un langage descriptif Jinja2: un langage de templating Comment communiquer efficacement avec Développeurs et Opérationnels

Ansible, les composants Qu’est-ce qui compose mon playbook de déploiement ? Mon playbook proprement dit, un fichiers Yaml qui décrit la configuration à déployer Mon inventaire : la liste des machines qui vont être ciblées par mon playbook Les groups: sert à ranger/classifier les machines (par domaine fonctionnel, ou technique), la mise en hierarchie/héritage est possible Les group_vars : un fichier de configuration par group contient la configuration propre à celui-ci Les host_vars : un fichier par machine (ou alias de machine), contient la configuration propre à la machine Les tâches : une action à exécuter sur une machine (copier un fichier, créer un utilisateur,…) Les roles : un ensembles de taches regroupées en un package fonctionnel précis et réutilisable

Ansible, les bons réflexes Quelques bons réflexes à avoir quand on développe les scripts : Si l’installation d’un produit n’est pas automatisable, c’est que le produit est mal fait ou trop compliqué Penser simplement, commencer par des taches simples avant de factoriser Penser au scope d’utilisation des variables Penser à la généralisation de vos tâches Regarder ce qui existe déjà, ne réinventez pas la roue !

Ansible et orchestration Ansible, c’est bien… mais quand c’est orchestré, c’est mieux ! Pouvoir suivre les déploiements Déclencher à la demande ou déclenchement automatique Consultation des logs Historisation Comment Ansible est et sera utilisé aux GM ? Un orchestrateur : Jenkins Un gestionnaire de sources pour les playbooks : BitBucket Un gestionnaire d’artifacts (livrables) : Artifactory Un serveur relais pour la Pré-Prod et Prod

Ansible et orchestration Développeurs Equipes PROD Code source BitBucket (git) Artifactory (livrables) playbooks Intégrateurs Playboooks + artefacts Playboooks + artefacts Artifactory (proxy) Inventaires Jenkins (orchestrateur) Jenkins (esclave) Ansible Ansible VM VM VM VM VM VM Hors-PROD PROD

Ansible, normes et outillage Ce qu’il nous reste à faire : Travailler sur les normes GM (document en cours) Outiller la gestion de l’inventaire (Tower, Semaphore, custom ?) Outiller le reporting de déploiement …

Ansible, quelques liens intéressants Un peu de doc, de présentation ou d’aide : http://fr.slideshare.net/johnthethird/ansible-presentation-24942953 http://linuxfr.org/news/presentation-d-ansible-et-version-2-a-venir …