Ops@viadeo : Puppet & Co... 6 mois après par Xavier Krantz http://fr.viadeo.com/fr/profile/xavier.krantz

1. Ops@viadeo : Puppet & Co.
This is time for the «Puppet» show !
Xavier Krantz
Viadeo Tech Days 2012

2. Plats à la carte
1. L’infra de Viadeo : aperçu
2. Retour vers le futur
3. The Puppet Master, «evil comes in all sizes»
4. The Foreman, le compagnon incontournable
5. Puppet «in da Pipe»
6. Retours d’expérience
7. Et maintenant ?
8. Questions

3. 1 - L’infra : Aperçu
Is that so bad ?

4. 1 - L’infrastructure Aujourd’hui
2 Lb 2 Fw
App1 App2 App3
... App3
~ 60 Fronts
~15 Memcached
Cluster1 Cluster1 Cluster1
~ 40 MySQL ~ 20 Solr Neo4j Hadoop

5. 1 - L’infrastructure Aujourd’hui
~ 60 Fronts Applicatifs (Tomcat5, Tomcat6, Tomcat7, NodeJS, Rubby)
~ 40 MySQL
~ 15 Memcached
~ 20 Solr
~ 5 Neo4J
~ 30 Hadoop
~ 5 Internal Workers
~ 15 Infrastructures tools
Total ~ 150 Serveurs de Production Physiques !

6. 2 - Retour vers le Futur
Nice car by the way !

7. 2 - Retour vers le futur
Une infrastructure croissante petit à petit
1,2 puis 3 serveurs
L’Artisanat du serveur
Installation manuelle
Tests de versions en prod
Scp, mon ami ! (Ou NFS ...)
The «bleeding Edge»
Archive *.tar.gz dans /usr/local
Compilation manuelle des programmes
Accès à la production
Root every where (Je suis l’admin et pis c’est tout !)
Privilèges d’ancien
Les DNS ? Pourquoi faire ?

8. 2 - Retour vers le Futur
Viadeo.com
45 Millions de membres
3 Millions de profils vue par jours
Y Posts
200 000 Mise en relations quotidienne
80 développeurs
4 Sites de développement
1 écosystème varié
Tomcat5, Tomcat6, Tomcat7
Java, Spring, NodeJS, Ruby
Des technologies à maitriser
Hadoop
Solr
Neo4J
+ de 200 Serveurs toutes plateformes confondues
Une BI (Des datas, des datas, encore des datas)
Des process métiers complexes

9. 2 - Retour vers le Futur
Et seulement 3 Ops !

10. 2 - Retour vers le Futur
Besoins :
QA
Consistance
Standardisation
Flexibilité
Automatisation
Une idée ?

11. 2 - Retour vers le Futur
Besoins :
QA
Consistance
Standardisation
Flexibilité
Automatisation
Une idée ?

12. 3 - The Puppet Master
It is going to change !

13. 3 - Mise en place de Puppet
Amorce :
1 Plateforme de production
Ubuntu 10.04 LTS - instable (Kernel Panic)
PXE + ~ KickStart + Scripts d’installation maisons
Des scripts (ou morceaux) à droite et à gauche
Et c’est tout !
1 Puppet Master
1 Nouvel OS : Debian
1 Apache + Mod_passenger
Quelques modules «maisons»
1 Objectif de standardisation (Packages Debian)
1 Repository SVN pour l’exploit
Détaché du produit viadeo (quand même)

14. 3 - Mise en place de Puppet
Nouveau Dogme : « Infrastructure As Code »
(so deal with it)
SVN Monolithique -> Git
Modèle de branche intuitif : « Git Flow »
Hook Pre-commit : Check de Syntax
Hook Post-commit : Création d’environnements Puppet
Git Hub Pull Request + Mode collaboratif
– « It So easy ! »
Evolution : Ops -> «Dev» Ops (un jour)

15. 3 - Mise en place de Puppet
Des outils

16. 3 - Mise en place de Puppet
Notre dépôt
Des modules «maisons»
Encore trop spécifique
– Pas de Submodules Git
– Pas de suivit de la puppet-forge
Trop de données «viadeo» dans les modules
Evolutions en cours
– Généralisation (Classes paramétrées)
– Augeas > Templates > Files
– Module «viadeo» core

17. 3 - Mise en place de Puppet
Notre dépôt
[ xkrantz@jumper ] ~/Sources/exploit-puppet (development) $ tree -L 2 -F
.
!"" README.rdoc
!"" autosign.conf
!"" fileserver.conf
|
!"" manifests/
# !"" nodes/
# !"" site.pp
# $"" templates.pp
|
!"" modules/
# !"" apache/
# !"" apt/
# !"" archive/
# !"" common/
# !"" concat/
# !"" dell/
| ...
| !"" viadeo/

18. 3 - Mise en place de Puppet
Notre dépôt
class baseclass {
## Includes Environments Variables
class {'viadeo::params':
stage => 'first',
}
## Modules
class {'locale': }
class {'timezone': }
class {'system': }
class {'ntp':
ntp_servers => $viadeo::params::ntp_servers,
}
class {'postfix':
relayhost => $viadeo::params::relayhost,
alias_root => $viadeo::params::alias_root,
external_domain => $viadeo::params::external_domain,
}
..
}

19. 3 - Mise en place de Puppet
Notre dépôt
class viadeo::webapp inherits viadeo {
## Main Modules
include viadeo::webapp::apache
include viadeo::webapp::tomcat
include viadeo::webapp::config
...
}

20. 4 - The Foreman
Now build it baby !

21. 4 - The Foreman

22. 4 - The Foreman

23. 4 - The Foreman

24. 4 - The Foreman
Provision de serveurs

25. 4 - The Foreman

26. 4 - The Foreman
Suivi de synchronisation

27. 4 - The Foreman

28. 4 - The Foreman
Unique point d’entrée des serveurs
Outils central de provisioning
Dashboard « Puppet »
Etat des agents
Inventaire des machines
Aperçu de l’infrastructure (Environnements)
Inventaire automatique
Facts : Etat de configuration matériel / logiciel « temps réel » des serveurs
LA « CMDB » : Adieux spreadsheet !

29. 5 -Puppet « In Da Pippe »
You can find me in the pipe

30. 5 - Puppet « in Da pipe »
Objectif :
Assurer une infra «ISO» tout au long de la
chaine de développement
Projet transverse :
build automatique des projets
1 feature = 1 branche « viadeo »
1 branche = 1 environnement complet et dédié
Déploiement automatique d’une infra

31. 5 - Puppet « in Da pipe »
Actuellement :
1 Puppet Master / site
+ infra (DNS, DHCP, PXE, Foreman, Repo Debian ...)
1 Subnet = 1 environment
1 Puppet Master = 1 Depot Git + Hooks
3 Branches principales :
Production,
Staging
Development
– « Pull » automatique toute les 10 min depuis
GitHub

32. 5 - Puppet « in Da pipe »
Future proche :
Ganeti : « Cloud » privé, capacité de provision

33. 5 - Puppet « in Da pipe »
Future (moins) proche :
Vagrant
Interface avec les API de « cloud » publics
Contribution aux outils (Foreman, modules Puppet, ...)

34. 6 - Retour d’expérience

35. 6 - Retour d’expérience
Avant Après
Ubuntu 10.04 Debian Squeeze « Stable »
Applications compilées Applications « standard » en Packages
Configuration manuelle Installation entièrement automatique
Scripts « d’automatisation » Serveur opérationnel en 30min
(modulo l’import de données)
Difficile à maintenir Consistance, automatisation
95% des serveurs de production sont
« Puppetizés »

36. 6 - Retour d’expérience
A l’usage
Nouvelles manières de travailler
Flexibilité / Rigueur : PuppetCtl
Puppet VS Packages VS Déploiement d’application
Attention au redémarrage automatique des services
Tester, tester et encore tester !
Puppet : Autoroute du bonheur ou Apocalypse
Rspec Puppet + Travis
RDoc + Graph des dépendances

37. 6 - Retour d’expérience
Puppet 2.6.2
class mysql (
$type = 'oracle'
) {
Portée des variables
Serveur de fichiers ...
## Ordering
Ordonnancement « Macro Class » anchor {'mysql::begin': }
Merci STDLib -> Class['params']
-> Class['repo']
-> Class['install']
Inter dépendance des modules -> Class['config']
-> Class['service']
## Set users account
-> Class['pwgen']
-> Class['root']
-> Class['security']
-> anchor {'mysql::end': }
}

38. 6 - Retour d’expérience
Foreman
Projet jeune
0.1 : Septembre 2009
0.3 : Juin 2011
0.4.2 : Decembre 2011
1.0 : Juillet 2012
CMBD, point unique et centrale de référence / Evolution rapide du projet
Niveau de confiance ?
Suivre le projet et tester !
Attention Rapport Agents / Status de synchronisation

39. 7 - La suite ?

40. 7 - La suite
Enc Ganeti Ipmi Hiera
Mcollective Foreman API
puppet puppetCtl
puppetdb Sensu vagrant

41. 7 - La suite
Future (+ ou -) proche :
PuppetCtl : Désactiver Puppet de manière contrôlée,
Foreman API
Puppet 3.0 : Optimisation des performances
Hiera : Data hierarchie et séparation,
PuppetDB : Collecter, automatiser et capacité d’échelle,
MCollective : Marionnette « Orchestration »
Sensu : Monitoring and data collection
Graphite : GDash
IPMI : Hardware and Firmware Automation
PowerDNS : On Rails + Foreman SP (Every thing as a Service)

42. 8 - Questions ?
Puppet Family
Des modules «maisons»
Encore trop spécifique
– Pas de Submodules Git
– Pas de suivit de la puppet-forge
Trop de données «viadeo»
Evolutions en cours
– Généralisation (Classe paramettrées)
– Augeas > Templates > Files