Ops@viadeo : Puppet & Co... 6 mois après par Xavier Krantz

Post on 06-Dec-2014

1,730 views 0 download

Tags:

description

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

transcript

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 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