Retrouvez les slides du webinar Smile co-organisé le 5 février avec RedHat et Ansible. Ansible est une plate-forme logicielle libre pour la configuration et la gestion des ordinateurs. Elle combine le déploiement de logiciels multi-nœuds, l'exécution des tâches ad-hoc, et la gestion de configuration. Lors du webinar, vous avez pu découvrir comment la solution Ansible déployée par Smile pour la troisième enseigne spécialisée dans la commercialisation de biens et loisirs culturels et créatifs en France, permet d'industrialiser leur SI.

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 find 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 different 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 config 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 (file, apt, mysql db, mysql user, etc.)
Role A role is a set of tasks grouped together to be more
easily reused between playbooks on different projects
(like a library)

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

24. My first 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