Save 37% off PRO during our Black Friday Sale! »

Code As Infrastructure & Ansible - Meetup Python Bdx 2016

Code As Infrastructure & Ansible - Meetup Python Bdx 2016

12 factors apps & code as infrastructure associé à une introduction à Ansible

Beb422437c1dfb5366f197919e41ac50?s=128

Arnaud LEMAIRE
PRO

June 29, 2016
Tweet

Transcript

  1. LA MISE EN PRODUCTION EST UN LIEU OÙ LA CHANCE

    N’A PAS SA PLACE !
  2. INFRASTRUCTURE AS CODE ARNAUD LEMAIRE | @LILOBASE

  3. • Avoir son infrastructure dans un état connu et documenté

    • Bénéficier d’une procédure de configuration indépotente & répétable
  4. MAIS AVANT, PARLONS DU COTÉ APPLICATIF… THE TWELVE FACTOR APP

  5. INTRODUCTION PRINCIPES • Créé par Adam Wiggins (Heroku) • Limite

    grandement l’adhérence de l’application à son infrastructure • Permet d’automatiser le déploiement de l’application • Simplifie le déploiement continu
  6. SÉPARER APPLICATION ET PERSISTENCE PRINCIPES • L’application doit être en

    share-nothing et stateless • Données • Bases de Données (utilisez des migrations) • Fichiers persistant (les caches ne comptent pas) • Logs
  7. UNE INJECTION DE DÉPENDANCE AU NIVEAU APPLICATIF PRINCIPES • Injecter

    les dépendances logicielles (package) • Injecter les dépendances aux backing services (datastores, serveur mail, queue, …) • Configuration
  8. OBJECTIF PRINCIPES • Une code base, plusieurs déploiements • Séparer

    ce qui est constant entre les installations de ce qui est spécifique • Les déploiement pouvant être fait sur des environnements ou clients différents
  9. SÉPARER APPLICATION ET PERSISTENCE MISE EN OEUVRE • Placer l’application

    et ses « backing services » sur des serveurs différents • Placer les fichiers devant être persistés dans un espace partagé (NAS, Bucket, …) • Envoyer les logs sur la sortie standard
  10. UNE INJECTION DE DÉPENDANCE AU NIVEAU APPLICATIF MISE EN OEUVRE

    • Décrire et installer les dépendances à l’aide d’un outil dédié (composer, npm, bundler, gradle, …) • Injecter la configuration de l’application via des variables d’environnements • Injecter les accès aux datastores via des variables d’environnements
  11. CONCLUSION • Les sauvegardes sont simplifiés : seul les datastores

    et les espaces de fichiers sont concernés • Le scaling horizontal devient très simple, il suffit d’injecter les bonnes variables d’environnement pour démarrer une nouvelle instance L’APPLICATION EST BIEN PLUS RÉSILIENTE
  12. PARLONS MAINTENANT DE L’INFRASTRUCTURE CE POUR QUOI VOUS ÉTIEZ VENU…

  13. INFRASTRUCTURE AS CODE • L’on décrit son infrastructure sous forme

    de « code » qui une fois exécuté permettra d’obtenir l’infrastructure en question • L’infrastructure devient prévisible et contrôlée, elle peut être testée et versionnée • L’outil qui va exécuter la description de l’infrastructure est un système de provisioning
  14. A QUOI SERT UN OUTIL DE PROVISIONING • C’est de

    l’administration système automatisé, vous gagnez du temps sur des taches répétitives et peu intéressantes • Installe et configure automatiquement votre infrastructure • Garantie et documente l’état de l’infrastructure • Vous pouvez déployer et administrer facilement un cluster de machines
  15. A QUOI NE SERT PAS UN OUTIL DE PROVISIONING •

    Ça n’est pas un système de déploiement / build • Ça ne remplace pas un administrateur système (docker non plus d’ailleurs…) • Ça ne gère pas les machines (physiques ou virtuelles) mais uniquement le logiciel qui va dessus • Utilisez du provisioning en association avec des outils qui gèrent déploiements et machines
  16. ANSIBLE CE POUR QUOI VOUS ÉTIEZ VRAIMENT VENU…

  17. TOUT COMMENCE AVEC UN INVENTAIRE • L’inventaire est un fichier

    au format ini qui contiens les machines qu’Ansible doit provisionner • Les machines peuvent être regroupées par groupe
  18. AUXQUELS L’ON ASSOCIE DES RÔLES • Les rôles représente une

    configuration de provisioning, au format yaml, pour un service donné (utilisateur, db, …) • Ils sont composés de : • tasks : commandes à effectuer pour provisioner le service • handlers : pour gérer les services systèmes associés (démarrage, arrêts, …) • templates : fichier qui pourra recevoir des variables avant d’être transférés sur la machine distante
  19. TASKS

  20. HANDLER

  21. TEMPLATES

  22. CES RÔLES SONT ORCHESTRÉS AU SEIN D’UN PLAYBOOK • Le

    playbook décrit les rôles à exécuter pour un groupe de machine donné • En fait les rôles sont des playbook spécialisés
  23. DANS LEQUEL ON INJECTE DES VARIABLES

  24. RÉCAPITULONS • L’infrastructure est décrite sous forme d’un playbook qui

    va orchestrer des rôles en fonction de groupes décrit dans un inventaire • Les rôles sont composés de tasks, handlers et templates • L’ensemble reçoit des variables de configuration Il ne reste plus qu’à déclencher le provisioning : ANSIBLE-PLAYBOOK -I HOSTS PLAYBOOK.YML
  25. MERCI ARNAUD LEMAIRE | @LILOBASE QUESTIONS ?