class: center, middle # Tester sa gestion de configuration ## [Arthur Vuillard](mailto:arthur@hashbang.fr) Snowcamp 21/01/2016 --- class: center, middle # À propos de moi .center[ ] .center[ ] ??? --- count: false class: center, middle # À propos de moi Développeur Pythoniste .center[ ] ??? Je suis un développeur Python --- count: false class: center, middle # À propos de moi Développeur Pythoniste AdminSys Linuxien ??? et un administrateur système linux Est ce que je suis un devops ? --- class: center, middle # À propos de moi     ??? je suis aussi --- count: false class: center, middle # À propos de moi  Hashbang ??? le créateur d'hashbang développement et maintenance d'applications webs pour les entrepreneures/entrepreneuses et PMEs remporte beaucoup de succès et qui a déjà au moins un salarié ! --- count: false class: center, middle # À propos de moi  |  :-------------------------------------:|:------------------------------------------------: Hashbang | localg.host ??? je suis aussi en train de créer Localghost infogérance de serveurs avec de grands outils regroupement d'éditeurs et d'intégrateurs autour de meilleures pratiques --- class: center, middle # À propos de moi ??? et je suis aussi --- count: false class: center, middle # À propos de moi  ??? Bénévole à l'AFPy association francophone python trésorier organisateur de conférence et de meetup enthousiaste du langage --- # À propos de cette présentation ??? à propos de cette présentation c'est le moment où je vous inquiète vous vous rendez compte que je ne vais pas parler de ce dont vous pensiez restez quand même, ça va être sympa ! --- count: false # À propos de cette présentation - sujet devops ??? sujet devops dans le sens ou on code des outils pour le déploiement et l'infrastructure par exemple, je ne vais pas vous parler de comment gérer vos fichiers de configuration entre la prod, la préprod et le dév --- count: false # À propos de cette présentation - sujet devops - testé et approuvé ??? j'ai testé et j'utilise les techniques dont je vais vous parler --- count: false # À propos de cette présentation - sujet devops - testé et approuvé .center[(dans un écosystème Python)] ??? par contre, en tant que bon pythoniste j'utilise des outils python --- count: false # À propos de cette présentation - sujet devops - testé et approuvé .center[(dans un écosystême Python)]   |   ----:|:----  |  ??? en l'occurence salt et shinken salt est un outil qui permet de déployer des applications, leur environnement et leur configuration sur des serveurs il permet aussi de créer et supprimer des machines dans le cloud shinken est un logiciel de supervision c'est un réécriture modulaire et en python de nagios mais les concepts que je présente sont probablement applicables avec d'autres outils notamment avec Chef, Puppet, Sensu, ou même Ansible --- # Gestion de configuration ? ??? qu'est ce qu'une gestion de configuration et de déploiement désolé pour cet abus de langage --- count: false # Gestion de configuration ? description technique d'un système informatique et de ses évolutions ??? d'abort, c'est la description technique d'un système informatique et de ses évolutions --- count: false # Gestion de configuration ? description technique d'un système informatique et de ses évolutions déploiement sur un parc de serveurs ??? c'est également un outil pour déployer des application sur un parc de serveurs --- # Gestion de configuration ? ??? mais pour moi, c'est surtout --- count: false # Gestion de configuration ? la doc du système complet ??? un moyen incomparable de documenter un système composé de plusieurs serveurs --- count: false # Gestion de configuration ? la doc du système complet outil indispensable pour la maintenance ??? c'est aussi un outil super pratique pour effectuer des opérations de maintenance on n'est plus obligé de se connecter un à un à chacun des serveurs pour effectuer une action, c'est lui qui s'occupe de ces taches parallèles --- # Problème ??? Maintenant, je vais vous faire part du problème rencontré dans la vraie vie et qui m'a inspiré tout ça --- count: false # Problème nouvelle équipe, nouvelle application ??? pour un client, je suis chargé de constituer une nouvelle équipe de dév autour d'une nouvelle application web certains d'entre eux ont des connaissances d'amin sys pas beaucoup de moyen ni suffisament de charge de travail pour embaucher quelqu'un à cette tâche --- count: false # Problème nouvelle équipe, nouvelle application bonnes pratiques dès le début ??? ensemble on décide de mettre en place pleins de bonnes pratiques : syntax checker, tests, intégration continue, git flow, préprod, production --- count: false # Problème nouvelle équipe, nouvelle application bonnes pratiques dès le début dont une gestion de configuration ??? dont un servuer de gestion de configuration et de déploiement avec ça, on est blindé, pas besoin d'admin sys --- count: false # Problème nouvelle équipe, nouvelle application bonnes pratiques dès le début dont une gestion de configuration . ??? le temps passe --- count: false # Problème nouvelle équipe, nouvelle application bonnes pratiques dès le début dont une gestion de configuration .. ??? on fait des itérations, des mises à jour régulières --- count: false # Problème nouvelle équipe, nouvelle application bonnes pratiques dès le début dont une gestion de configuration ... ??? le code évolue, la conf aussi, pas de problème --- count: false # Problème nouvelle équipe, nouvelle application bonnes pratiques dès le début dont une gestion de configuration ... nouvelle instance ? ??? jusqu'au jour où il faut démarrer une nouvelle instance --- class: black, middle # Problème .center[] ??? et là, stupeur bon désolé pour ceux qui sont surpris, mais je suis un grand fan d'elen ripley, le personnage principal de la série de films alien notre gestion de configuration et de déploiement sur qui on comptait pour faire cette action ne fonctionne pas et nous crache des erreurs --- # Post mortem ??? il y a plusieurs causes qui nous ont amenés à cette situtation --- count: false # Post mortem installation incrémentale ??? on avait fait la conf incrémentalement des serveurs déjà installé sur lesquels on appliquait la conf dans un ordre précis quand on l'applique à partir de zero, l'ordre n'est pas forcèment le même --- count: false # Post mortem installation incrémentale actions manuelles ??? manque de rigueur : réglages à la main pas reporté dans la conf --- count: false # Post mortem installation incrémentale actions manuelles première exécution à partir de rien ??? jamais d'exécution à partir de rien du tout --- # chez les dévs ??? prenons un peu de recul et regardons comment ça se passe chez les developpeurs et les développeuses --- count: false # chez les dévs tests [unitaires|d'intégrations|fonctionnels] ??? On n'attend pas que ce soit sur un serveur pour valider test unitaires, tests d'intégrations, tests fonctionnels --- count: false # chez les dévs tests [unitaires|d'intégrations|fonctionnels] serveur d'intégration continue ??? serveurs d'intégration continue qui exécute les tests et font plein de vérifications trop automatiques pour un humain --- count: false # chez les dévs tests [unitaires|d'intégrations|fonctionnels] serveur d'intégration continue TDD ??? test driven development écrire et exécuter un test avant d'écrire la fonctionnalité on est sûr que le test échoue puis on écrit la fonctionnalité puis il passe il n'y a rien de pire qu'un test qui n'échoue pas et ça permet aussi de prendre du recul par rapport à ce qu'on est sur le point de coder --- # côté adminsys ??? revenons sur le côté administration system --- count: false # côté adminsys supervision, toujours ??? toujours de la supervision suivi et le pilotage du bon fonctionnement de tous les composants de l'architecture --- count: false # côté adminsys supervision, toujours gestion de configuration, parfois ??? c'est déjà beau quand il y a de la gestion de configuration --- count: false # côté adminsys supervision, toujours gestion de configuration, parfois tests ? ??? et la vérification de tout ça ? à l'exécution mais on peut faire mieux --- class: black, middle  ??? eh oui ripley c'est le seul moyen d'être sûr ! --- # Vérification de la syntaxe ??? le premier niveau de vérification est au niveau de la syntax on peut trouver une solution pour chaque logiciel --- count: false # Vérification de la syntaxe - puppet-lint ??? puppet a un linter --- count: false # Vérification de la syntaxe - puppet-lint - foodcritic pour chef ??? chef aussi --- count: false # Vérification de la syntaxe - puppet-lint - foodcritic pour chef - `ansible-playbook foo.yml --check` ??? ansible permet de lire un playbook et de le vérfier --- count: false # Vérification de la syntaxe - puppet-lint - foodcritic pour chef - `ansible-playbook foo.yml --check` - `salt '*' state.show_highstate --out yaml` ??? et salt permet de lire les states et de les vérifier en vrai, là, il les affiche juste en yaml, mais il y a une erreur si il y a un problème --- # Déploiement sur un serveur jetable ??? le second niveau de vérification est de déployer ça sur un serveur jetable c'est à dire un machine virtuelle qui sera détruite après le test --- count: false # Déploiement sur un serveur jetable 1. préparer une VM ??? lancer une vm avec une installation de base + gestionnaire de configuration --- count: false # Déploiement sur un serveur jetable 1. préparer une VM 2. préparer une conf pour le déploiement ??? récupérer les fichiers de description de confs --- count: false # Déploiement sur un serveur jetable 1. préparer une VM 2. préparer une conf pour le déploiement 3. exécuter tout ça ??? lancer un déploiement --- count: false # Déploiement sur un serveur jetable 1. préparer une VM 2. préparer une conf pour le déploiement 3. exécuter tout ça 4. vérifier ??? et vérifier que l'exécution s'est bien passée et donc, voilà à quoi ça ressemble --- # Déploiement sur un serveur jetable ```yml # minion : salt agent configuration file_client: local file_roots: base: - /vagrant/my_states ``` ??? ici c'est notre fichier de configuration salt on lui indique qu'on va tout faire en local et qu'il n'a pas besoin de se connecter à un serveur et que les états, la description du déploiement et de la configuration, se trouvent dans /vagrant/my_states --- # Déploiement sur un serveur jetable ```ruby # Vagrantfile : virtual machine configuration Vagrant.configure(2) do |config| config.vm.box = "debian/jessie64" config.vm.network "private_network", ip: "192.168.50.5" config.vm.synced_folder ".", "/vagrant", type: "rsync" config.vm.provision "shell", inline: <<-SHELL sudo cp /vagrant/minion /etc/salt/minion sudo apt-get install -y salt-minion SHELL end ``` ??? ici, j'ai choisi Vagrant, voici donc un Vagrantfile on part d'une debian jessie 64bits on configure le réseau on synchronise son dossier /vagrant avec le dossier local on configure salt et on l'installe --- # Déploiement sur un serveur jetable ```bash git clone git@gitlab.com:team/my_states.git vagrant up CMD="sudo salt-call --local state.sls my_state vagrant ssh -c "$CMD" ``` ??? et on exécute tout ça on récupére les states depuis notre dépôt git préféré on démarre et provisionne la machine virtuelle et on exécute la commande salt qui va installer un state sur la machine virtuelle on met tout ça dans notre serveur d'intégration continue ---  ??? et on détecte des erreurs --- class: black, middle  ??? ripley est contente, elle s'est rassuré en faisant de la ronronthérapie avec son chat est ce que pour autant, tout fonctionne comme espéré ? je veux dire, est ce qu'on est assuré que les services sont démarré et en exécution est ce que nginx répond bien pour un nom de serveur avec le bon résultat ? est ce qu'on peut se connecter en ssh ? est ce que le certificat ssl est valide ? --- # supervision ??? je mets tout ça de cote pour l'instant afin de parler des habitudes des admin sys et notamment de la supervision --- count: false # supervision exécute des vérifications périodiquement ??? le supervision est la pratique qui permet de réaliser des vérifications périodiques --- count: false # supervision exécute des vérifications périodiquement alerte en cas de problèmes ??? et d'alerter un humain en cas de problème --- # Test driven infrastructure ??? TDD de l'admin sys --- count: false # Test driven infrastructure mise en place des checks ??? mise en place des checks avant le déploiement --- count: false # Test driven infrastructure mise en place des checks checks sont négatifs ??? les checks sont négatifs --- count: false # Test driven infrastructure mise en place des checks checks sont négatifs déploiement ??? déploiement --- count: false # Test driven infrastructure mise en place des checks checks sont négatifs déploiement checks sont positifs ??? les checks deviennent positifs --- # TDI : double intérêt ??? double intérêt --- count: false # TDI : double intérêt un élément déployé a des checks ??? on est sûr qu'un élément déployé a ses checks de supervision --- count: false # TDI : double intérêt un élément déployé a des checks les checks échouent quand il le faut ??? et on est sûrs que ces checks échouent quand il le faut --- class: middle ??? --- count: false class: middle `checks` ??? d'un côté on a les checks --- count: false class: middle `checks` `+` ??? et de l'autrre --- count: false class: middle `checks` `+` `configuration et déploiement` ??? la gestion de configuration et de déploiement --- count: false class: middle `checks` `+` `configuration et déploiement` `=` ??? et si on couplait les checks avec la configuration de déploiement ? comme les tests avec le code ? pour pouvoir valider le déploiement de test et la prod de la même manière et concevoir les checks en même temps que la prod exemple revue/pull request --- count: false class: middle `checks` `+` `configuration et déploiement` `=` `<3` ??? ça serait de l'amour en barre pour ceux qui ne connaissent pas, ce n'est pas une syntaxe bash bizarre --- # Implémentation ??? si on regarde du côte de l'implémenation de ce concept avec salt et shinken, voilà à quoi ça ressemblerait alors je n'ai pas mis de coode car c'est très lié à des spécificités de shinken et salt et aussi un peu long pour rentrer dans les détails donc désolé --- count: false # Implémentation créer un state `supervision` ??? pour chaque state de niveau le plus haut en gros, pour chaque role qui sera appliqué à une machine on crée un state supervision le state supervision contiendra les templates des fichiers de configuration de la supervision pour ce rôle en particulier --- count: false # Implémentation créer un state `supervision` template host + services ??? pour shinken ces fichiers sont un host template (ou abstrait) et les services (checks) à lui associer il faut également créer un configuration d'un hôte en particulier, qui héritera des hosts abstraits --- count: false # Implémentation créer un state `supervision` template host + services déployer sur un serveur de monitoring ??? déployer sur le serveur de monitoring ces confs ou sur notre vm jetable de tout à l'heure --- count: false # Implémentation créer un state `supervision` template host + services déployer sur un serveur de monitoring lancer les checks ??? les appliquer à chacun des hosts à qui est appliqué le state dans le cas de la vm jetable et pour être rigoureux dans la méthode tdi on lance les checks avant le déploiement, on vérifie que tout est bien rouge puis aussi après, et on vérifie que tout est bien vert --- # Pour aller plus loin ??? Je vous ai préparé quelques pistes pour aller un peu plus loin dans cet univers Il y a pas mal de liens que vous pourrez retrouver dans 5 minutes quand j'aurai publié ces slides sur internet --- count: false # Pour aller plus loin [tests unitaires des states](http://blog.yourlabs.org/post/122381003283/test-driven-development-with-saltstack-sls-code) ??? avec salt, on peut coder ses states directement en python, et donc tester unitairement chacun des states cet article explique comment --- count: false # Pour aller plus loin [tests unitaires des states](http://blog.yourlabs.org/post/122381003283/test-driven-development-with-saltstack-sls-code) [kitchen ci](http://kitchen.ci/) ??? kitchen ci est un service de vérification de votre gestion de configuration et de déploiement il permet de faire des vérifications avec des frameworks de tests variés plutôt orienté chef à l'origine mais a des extensions pour d'autres logiciels --- count: false # Pour aller plus loin [tests unitaires des states](http://blog.yourlabs.org/post/122381003283/test-driven-development-with-saltstack-sls-code) [kitchen ci](http://kitchen.ci/) [docker](http://fr.slideshare.net/arthurlutz/pyconfr-2015-utiliser-salt-pour-tester-son-infrastructure-sur-open-stack-ou-docker-avant-la-mise-en-production), lxc, [openstack](http://fr.slideshare.net/arthurlutz/pyconfr-2015-utiliser-salt-pour-tester-son-infrastructure-sur-open-stack-ou-docker-avant-la-mise-en-production), [{{your_favorite_vm_or_container_system_here}}](https://docs.saltstack.com/en/develop/topics/cloud/index.html) ??? j'ai utilisé Vagrant mais vous pouvez également utilisé n'importe quoi d'autres il y a un lien qui pointe vers une présentation ayant eu lieu à la derniere pyconfr et qui par le de docker et d'openstack (avec salt aussi) le second lien pointe vers la doc de salt-cloud qui permet de manipuler très facilement la création de nouvelles machines virtuelles --- count: false # Pour aller plus loin [tests unitaires des states](http://blog.yourlabs.org/post/122381003283/test-driven-development-with-saltstack-sls-code) [kitchen ci](http://kitchen.ci/) [docker](http://fr.slideshare.net/arthurlutz/pyconfr-2015-utiliser-salt-pour-tester-son-infrastructure-sur-open-stack-ou-docker-avant-la-mise-en-production), lxc, [openstack](http://fr.slideshare.net/arthurlutz/pyconfr-2015-utiliser-salt-pour-tester-son-infrastructure-sur-open-stack-ou-docker-avant-la-mise-en-production), [{{your_favorite_vm_or_container_system_here}}](https://docs.saltstack.com/en/develop/topics/cloud/index.html) [travis ci](https://lambdaops.com/automation/travis/travis%20ci/configuration%20management/continuous%20integration/salt/chef/saltstack/salt%20stack/2014/01/29/travis-for-salt-states/), [gitlab ci](www.rlyon.me/blog/2015/01/19/installing-a-puppet-test-environment/) ??? travis ci et gitlab ci sont deux services d'intégration continue qui ont le bon gout de pouvoir se lancer dans des containers on n'a alors plus besoin d'initialiser une vm, on initialise plus que le container en cours le premier lien concerne travis avec salt le second concerne gitlab avec puppet --- count: false # Pour aller plus loin [tests unitaires des states](http://blog.yourlabs.org/post/122381003283/test-driven-development-with-saltstack-sls-code) [kitchen ci](http://kitchen.ci/) [docker](http://fr.slideshare.net/arthurlutz/pyconfr-2015-utiliser-salt-pour-tester-son-infrastructure-sur-open-stack-ou-docker-avant-la-mise-en-production), lxc, [openstack](http://fr.slideshare.net/arthurlutz/pyconfr-2015-utiliser-salt-pour-tester-son-infrastructure-sur-open-stack-ou-docker-avant-la-mise-en-production), [{{your_favorite_vm_or_container_system_here}}](https://docs.saltstack.com/en/develop/topics/cloud/index.html) [travis ci](https://lambdaops.com/automation/travis/travis%20ci/configuration%20management/continuous%20integration/salt/chef/saltstack/salt%20stack/2014/01/29/travis-for-salt-states/), [gitlab ci](www.rlyon.me/blog/2015/01/19/installing-a-puppet-test-environment/) [continuous delivery](http://snowcamp2016.sched.org/event/5nBV) ??? le continuous delivery est une extension de l'intégration continue dans laquelle après avoir fait les vérifications, on déploie sur une machine si vous faites du continuous delivery, vous lancez probablement souvent votre gestion de conf et de déploiement régulièrement en tout cas, si ça échoue, ça fera échouer votre processus de continuous delivery le lien pointe vers la présentation de demain sur le sujet --- count: false # Pour aller plus loin [tests unitaires des states](http://blog.yourlabs.org/post/122381003283/test-driven-development-with-saltstack-sls-code) [kitchen ci](http://kitchen.ci/) [docker](http://fr.slideshare.net/arthurlutz/pyconfr-2015-utiliser-salt-pour-tester-son-infrastructure-sur-open-stack-ou-docker-avant-la-mise-en-production), lxc, [openstack](http://fr.slideshare.net/arthurlutz/pyconfr-2015-utiliser-salt-pour-tester-son-infrastructure-sur-open-stack-ou-docker-avant-la-mise-en-production), [{{your_favorite_vm_or_container_system_here}}](https://docs.saltstack.com/en/develop/topics/cloud/index.html) [travis ci](https://lambdaops.com/automation/travis/travis%20ci/configuration%20management/continuous%20integration/salt/chef/saltstack/salt%20stack/2014/01/29/travis-for-salt-states/), [gitlab ci](www.rlyon.me/blog/2015/01/19/installing-a-puppet-test-environment/) [continuous delivery](http://snowcamp2016.sched.org/event/5nBV) [repository mirroring](https://www.debian.org/mirror/ftpmirror), [pypi proxy](http://doc.devpi.net/latest/quickstart-pypimirror.html) ??? tout ça est très consommateur en bande passante je vous recommande de mettre en place un mirror ou un proxy pour les paquets et les dépendances --- class: center, middle, black # Conclusion  ??? en conclusion, ripley a tous les outils sous la main pour vérifier sa gestion de configuration et de déploiement en tout cas, she can handle herself --- class: middle # Des questions ? ## .center[[arthur@hashbang.fr](mailto:arthur@hashbang.fr)]