Viadeo Tech Days 2012 : Ops@viadeo

In 2012, Viadeo hosted its first "Tech Days" event (http://techdays.viadeo.com/).

3 days with 3 / 4 presentations each with people from Viadeo and outside, sharing their experiences developing and operating websites with complexe needs.

Transcript

1. This is time for the «Puppet» show ! Ops@viadeo : Puppet & Co. 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 App1 App2 App3 Cluster1 App3 ... Cluster1 Cluster1 ~ 40 MySQL ~15 Memcached ~ 60 Fronts ~ 20 Solr Neo4j Hadoop 2 Fw 2 Lb
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 500 000 Posts 200 000 Mise en relations quotidienne 80 développeurs 4 Sites de développement « World Wide » 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. Et seulement 3 Ops ! 2 - Retour vers le Futur
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. 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 5 - Puppet « in Da pipe »
31. 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 5 - Puppet « in Da pipe »
32. Future proche : Ganeti : « Cloud » privé, capacité de provision 5 - Puppet « in Da pipe »
33. Future (moins) proche : Vagrant Interface avec les API de « cloud » publics Contribution aux outils (Foreman, modules Puppet, ...) 5 - Puppet « in Da pipe »
34. 6 - Retour d’expérience
35. 6 - Retour d’expérience Avant Ubuntu 10.04 Applications compilées Configuration manuelle Scripts « d’automatisation » Difficile à maintenir Après Debian Squeeze « Stable » Applications « standard » en Packages Installation entièrement automatique Serveur opérationnel en 30min (modulo l’import de données) 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 Portée des variables Serveur de fichiers Ordonnancement « Macro Class » Merci STDLib Inter dépendance des modules class mysql ( $type = 'oracle' ) { ... ## Ordering anchor {'mysql::begin': } -> Class['params'] -> Class['repo'] -> Class['install'] -> 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