Webinar Smile : Comment industrialiser votre SI avec Ansible ?

1. COMMENT INDUSTRIALISER VOTRE SI AVEC ANSIBLE ? Brice TRINEL: Ingénieur avant vente bu système Smile Kévin HOUDEBERT: Ingénieur DevOps bu système Smile Hervé LEMAITRE : Business Strategist Red Hat France Alexia OLLAGNON : Partner Manager Red Hat France

2. SOMMAIRE 1. Présentation générale Red Hat/Ansible/Smile 2. Démonstration Ansible (installation d’une pile LAMP) 3. Retour d’expérience client

3. 1.PRÉSENTATION GÉNÉRALE RED HAT ANSIBLE SMILE

4. NOVEMBER 2016 RED HAT TO ACQUIRE IT AUTOMATION AND DEVOPS LEADER ANSIBLE “Red Hat's acquisition of Ansible, one of the premier DevOps vendors in the industry, solidifies Red Hat's position and stature as a DevOps provider.” JAY LYMAN, 451 RESEARCH

5. COMMUNAUTÉ •13,000+ stars & 4,000+ forks on GitHub •2000+ GitHub Contributors •Over 450 modules shipped with Ansible •New contributors added every day •1200+ users on IRC channel •Top 10 open source projects in 2014 •World-wide meetups taking place every week •Ansible Galaxy: over 18,000 subscribers •250,000+ downloads a month •AnsibleFests in NYC, SF, London THE MOST POPULAR OPEN-SOURCE AUTOMATION COMMUNITY ON GITHUB

6. LA COMPLEXITÉ TUE LA PRODUCTIVITÉ La complexité est l'ennemi de l'innovation, raison pour laquelle les entreprises recherchent aujourd'hui des outils et des pratiques d'automatisation via le modèle DevOps DevOps can help organizations that are pushing to implement a bimodal strategy to support their digitalization efforts. Gartner 2015

7. QUAND VOUS AUTOMATISEZ, VOUS ACCÉLÉREZ Ansible est là pour exécuter les tâches répétitives dont les admins ont horreur. Il aide à encore mieux opérer ; avec moins d'erreurs et plus de responsibilités L'automatisation réduit la complexité et redonne accès à une ressource rare : le temps

8. VERS UN S.I. SANS FRICTION SIMPLE À RAPIDE INTÉGRÉ UTILISER

9. ANSIBLE DANS LE PORTFOLIO RED HAT

10. CE QU'EST ANSIBLE? C'est un langage simple d'automatisation qui peut décrire parfaitement une infrastructure de S.I. (application ou autre) sous forme de Playbooks. C'est un moteur d'automatisation qui exécute les Playbooks Ansible. Ansible Tower est un framework entreprise pour contrôler, sécuriser et gérer l'automatisation Ansible, via une Interface Utilisateur et des APIs restful

11. ANSIBLE TOWER CONTRÔLE SIMPLE PUISSANT SANS AGENT CONNAISSANCE DÉLÉGATION TOWER ÉTEND L'AUTOMATISATION À L'ENTREPRISE. AU COEUR D'ANSIBLE, ON TROUVE LE MOTEUR OPEN-SOURCE D'AUTOMATISATION Gestion de tâches ordonnancées Visibilité et conformité Accès à base de rôles et self-service Tout le monde parle le même langage Conçu pour des déploiements multi-tiers Predictif, stable, et sécurisé

12. Des centaines Une infra OpenStack Des milliers de tickets De jours de conseil Depuis 2012 Supports SYSTÈME & INFRASTRUCTURE SMILE RUN Support, MCO, Migration et Maintenance DESIGN Audit/Evolution, Définition d’Architecture, Etude de besoin BUILD Mise en place d’architecture, Intégration de produits/compléments techniques, Optimisation de performance Cloud Virtualisation Industrialisation Logicielle/DevOps Communication unifiée Helpdesk/Supervision Bases de Données OpenStack Ceph Docker … KVM Xen … Chef Puppet Ansible Foreman GLPI Zabbix RHEV OCS 50 EXPERTS 6 M€ CA Smile vous accompagne Design BuildRun Nagios/Centreon PostgreSQL CassandraMySQL MongoDB BlueMind Zimbra Openxchange Asterisk Data Hadoop Hive Pig SaltStack 50/50 Régie/Forfaits

13. 2.DEMONSTRATION ANSIBLE

14. Regular deployment A long, manual process

15. Regular deployment the result : Not exactly homogenous. But hopefully you can ﬁnd a pair of shoes in there ?

16. Regular deployment Same goes with servers You can usually tell who installed the server No two deployments are the same On diﬀerent projects On the same project, 6 months later (new frontend) Sometimes, on two frontends installed at the same time !

17. Automated deployment Repeatable, automated, no surprises !

18. Automated deployment It’s a prerequisite to continuous deployment We’re not there yet But we’re working on it

19. What do we deploy ? Short answer : everything Long answer Everything needed for the application to work Starting from a ”fresh” OS install ”Common” server admin tools are out of scope monitoring backup systems bare metal management (inventory tools, openmanage, etc.) production security (SSH keys, passwords, etc.) is usually out of scope too

20. Network architecture Unlike most conﬁg management systems, Ansible : is agent-less reuses ssh is not persistent (run on demand only) Ansible is an execution framework built on top of SSH

21. Vocabulary Task A task is a single action Ansible may take (edit a file, install a package, run a command) Inventory An inventory is a list of servers and groups of servers Play A play is a list of task to be executed on a server or on a group of server (exemple : a play can install and configure MySQL on a database server) Playbook A playbook is a list of plays, where each play can affect different servers or groups (exemple : a playbook may run a MySQL play on DB servers, then an Apache play on web servers)

22. Vocabulary Module A module is a component that provides types of tasks (ﬁle, apt, mysql db, mysql user, etc.) Role A role is a set of tasks grouped together to be more easily reused between playbooks on diﬀerent projects (like a library)

23. Summary task = function call module = function role = library play = what you need to conﬁgure one type of server playbook = what you need to do a full deployment

24. My ﬁrst inventory The default inventory is /etc/ansible/hosts but you will never use it Ansible will not work without an inventory :( A simple inventory : $ cat inventory localhost

25. My first ansible run $ ansible -i inventory -c local -m ping all localhost | success >> { "changed": false, "ping": "pong" } -i specifies the inventory to use -c specifies the connection type (local = no connection) -m specifies the module you want to run all is the host or host group you want to run the module on All hosts are added to a host group called all Try running the command with localhost instead

26. My second ansible run $ ansible -i inventory -c local -m copy -a ’dest=/tmp/ansible content=hello’ all localhost | success >> { "changed": true, "dest": "/tmp/ansible", "gid": 1000, "group": "smile", "md5sum": "5d41402abc4b2a76b9719d911017c592", "mode": "0644", "owner": "smile", "size": 5, "state": "file", "uid": 1000 } The ”copy” module allows you to copy file between hosts -a allows you to set options The copy module has an option to specify the file content instead of a source file Run it again, what do you notice ? Ansible can detect when an action does not need to be executed

27. RTFM ansible-doc -l : list modules ansible-doc module : show full module documentation ansible-doc -s module : give a short example of module usage

28. Preparation You will need at least 2 vms Make sure you can SSH login as root to them (sudo is possible, ssh key recommended, RTFM) $ cat inventory slave1.lxc ansible_ssh_user=root slave2.lxc ansible_ssh_user=root Make sure python is installed inside the vms Create an inventory with the two hosts (one per line) Check : $ ansible -u root -i inventory -m ping all slave2.lxc | success >> { "changed": false, "ping": "pong" } slave1.lxc | success >> { "changed": false, "ping": "pong" }

29. First tasks Let’s create a playbook ! --- - hosts: all tasks: - name: Ping both hosts ping: YAML code ! Jinja template language

30. A little YAML A YAML document starts with three dashes : --- YAML is a superset of JSON : every JSON document is a valid YAML document You could write your playbooks in JSON (don’t do it) The top structure of a playbook is a list (of plays) A play is a YAML object Each play must have a hosts and a tasks attribute Each of those attributes contains a list hosts is a list of strings (hostnames)

31. A little YAML tasks themselves are objects tasks optionnaly have a name (do it!) tasks have an attribute to identify the module they use the value of this attribute is a non-YAML list of module parameters example : apt: name=apache2 state=present install recommends=false

32. 3.RETOUR D’EXPÉRIENCE

33. RETOUR D’EXPERIENCE Industrialisation d'un site e-commerce §Uniformisation des configurations §Environnements ISO §Facilitation des déploiements avec une méthodologie d'intégration continue (Jenkins) §Configuration centralisée

34. RETOUR D’EXPERIENCE Industrialisation d'un site e-commerce Uniformisation des configurations Toutes les configuration de type: §VHOST apache « templétisé » §Configuration du MySQL en mode Master/Slave §Configuration des serveurs de cache Varnish §Configuration des service MongoDB et Redis §…. En conclusion tous les fichiers de configuration sont « templétisés » pour tous les environnements

35. RETOUR D’EXPERIENCE Industrialisation d'un site e-commerce Environnements ISO §A cause de l'historique, avant la mise en place d'Ansible, les environnements étaient hétérogènes. §Suite au déploiement de la solution, nous avons pu homogénéiser tous les environnements de façon efficiente. §Il n'y a pas eu de duplication des configurations.. §Limitation de l'erreur humaine

36. RETOUR D’EXPERIENCE Industrialisation d'un site e-commerce Facilitation des déploiements avec une methodologie d'intégration continue (Jenkins) §Orchestration des mise en production (MEP) à l'aide de jenkins. ØPackaging des sources ØLancement des tests unitaires ØTests d'intégration ØLancement des tests de qualimétrie ØLancement d'un test de charge (Jmeter) ØDéploiement automatisé en recette, pré-prod, production avec validation manuelle.

37. RETOUR D’EXPERIENCE Industrialisation d'un site e-commerce Configuration centralisée §Un seul template unique par fichier de configuration §Le template est alimenté par des variables définies par environnement. (Par exemple pour un vhost, nous avons une variable ServerName pour chaque environnement) §Nous avons un système de versioning grâce à GIT/SVN qui nous permet d'avoir: un historique des modifications, un rollback, travail collaboratif)

38. QUESTIONS ? NOUS CONTACTER AU COMMERCIAL.SYSTEME@SMILE.FR Confidential