Code As Infrastructure & Ansible - Meetup Python Bdx 2016

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

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 ?