Date post: | 06-Dec-2014 |
Category: |
Documents |
Upload: | olivier-dasini |
View: | 1,730 times |
Download: | 0 times |
This is time for the «Puppet» show !
Ops@viadeo : Puppet & Co.
Xavier Krantz
Viadeo Tech Days 2012
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
1 - L’infra : Aperçu
Is that so bad ?
1 - L’infrastructure Aujourd’hui
App1 App2 App3
Cluster1
App3...
Cluster1Cluster1
~ 40 MySQL
~15 Memcached
~ 60 Fronts
~ 20 Solr Neo4j Hadoop
2 Fw2 Lb
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 !
2 - Retour vers le Futur
Nice car by the way !
2 - Retour vers le futurUne infrastructure croissante petit à petit
1,2 puis 3 serveurs
L’Artisanat du serveurInstallation manuelleTests de versions en prodScp, mon ami ! (Ou NFS ...)
The «bleeding Edge»Archive *.tar.gz dans /usr/localCompilation manuelle des programmes
Accès à la productionRoot every where (Je suis l’admin et pis c’est tout !)Privilèges d’ancien
Les DNS ? Pourquoi faire ?
2 - Retour vers le Futur
Viadeo.com45 Millions de membres3 Millions de profils vue par joursY Posts200 000 Mise en relations quotidienne
80 développeurs4 Sites de développement1 écosystème varié
Tomcat5, Tomcat6, Tomcat7Java, Spring, NodeJS, Ruby
Des technologies à maitriserHadoopSolrNeo4J
+ de 200 Serveurs toutes plateformes confondues
Une BI (Des datas, des datas, encore des datas)Des process métiers complexes
Et seulement 3 Ops !
2 - Retour vers le Futur
2 - Retour vers le Futur
Besoins :
QAConsistanceStandardisationFlexibilitéAutomatisation
Une idée ?
2 - Retour vers le Futur
Besoins :
QAConsistanceStandardisationFlexibilitéAutomatisation
Une idée ?
3 - The Puppet MasterIt is going to change !
3 - Mise en place de PuppetAmorce :
1 Plateforme de productionUbuntu 10.04 LTS - instable (Kernel Panic)PXE + ~ KickStart + Scripts d’installation maisonsDes scripts (ou morceaux) à droite et à gaucheEt c’est tout !
1 Puppet Master1 Nouvel OS : Debian1 Apache + Mod_passengerQuelques modules «maisons»1 Objectif de standardisation (Packages Debian)
1 Repository SVN pour l’exploitDétaché du produit viadeo (quand même)
3 - Mise en place de PuppetNouveau Dogme : « Infrastructure As Code »
(so deal with it)
SVN Monolithique -> Git
Modèle de branche intuitif : « Git Flow »
Hook Pre-commit : Check de SyntaxHook Post-commit : Création d’environnements Puppet
Git Hub Pull Request + Mode collaboratif– « It So easy ! »
Evolution : Ops -> «Dev» Ops (un jour)
3 - Mise en place de PuppetDes outils
3 - Mise en place de PuppetNotre 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
3 - Mise en place de PuppetNotre 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/
3 - Mise en place de PuppetNotre 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, }
..}
3 - Mise en place de PuppetNotre dépôt
class viadeo::webapp inherits viadeo {
## Main Modules include viadeo::webapp::apache include viadeo::webapp::tomcat include viadeo::webapp::config
...}
4 - The Foreman Now build it baby !
4 - The Foreman
4 - The Foreman
4 - The Foreman
4 - The Foreman
Provision de serveurs
4 - The Foreman
4 - The Foreman
Suivi de synchronisation
4 - The Foreman
4 - The Foreman
Unique point d’entrée des serveursOutils central de provisioning
Dashboard « Puppet »Etat des agentsInventaire des machinesAperçu de l’infrastructure (Environnements)
Inventaire automatiqueFacts : Etat de configuration matériel / logiciel « temps réel » des serveurs
LA « CMDB » : Adieux spreadsheet !
5 -Puppet « In Da Pippe »You can find me in the pipe
Objectif :Assurer une infra «ISO» tout au long de la chaine de développement
Projet transverse : build automatique des projets1 feature = 1 branche « viadeo »1 branche = 1 environnement complet et dédié
Déploiement automatique d’une infra
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,StagingDevelopment– « Pull » automatique toute les 10 min depuis
GitHub
5 - Puppet « in Da pipe »
Future proche :Ganeti : « Cloud » privé, capacité de provision
5 - Puppet « in Da pipe »
Future (moins) proche :
VagrantInterface avec les API de « cloud » publicsContribution aux outils (Foreman, modules Puppet, ...)
5 - Puppet « in Da pipe »
6 - Retour d’expérience
6 - Retour d’expérience
Avant
Ubuntu 10.04Applications compiléesConfiguration manuelleScripts « d’automatisation »
Difficile à maintenir
Après
Debian Squeeze « Stable »Applications « standard » en PackagesInstallation entièrement automatique
Serveur opérationnel en 30min (modulo l’import de données)
Consistance, automatisation95% des serveurs de production sont « Puppetizés »
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 + TravisRDoc + Graph des dépendances
6 - Retour d’expérience
Puppet 2.6.2
Portée des variablesServeur 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': }}
6 - Retour d’expérience
Foreman
Projet jeune0.1 : Septembre 20090.3 : Juin 20110.4.2 : Decembre 20111.0 : Juillet 2012
CMBD, point unique et centrale de référence / Evolution rapide du projetNiveau de confiance ?
Suivre le projet et tester !
Attention Rapport Agents / Status de synchronisation
7 - La suite ?
7 - La suite
Enc Ganeti Ipmi Hiera
Mcollective Foreman API
puppet puppetCtl
puppetdb Sensu vagrant
7 - La suiteFuture (+ ou -) proche :
PuppetCtl : Désactiver Puppet de manière contrôlée,Foreman API
Puppet 3.0 : Optimisation des performancesHiera : Data hierarchie et séparation,PuppetDB : Collecter, automatiser et capacité d’échelle,
MCollective : Marionnette « Orchestration »Sensu : Monitoring and data collectionGraphite : GDash
IPMI : Hardware and Firmware AutomationPowerDNS : On Rails + Foreman SP (Every thing as a Service)
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