DevOps : mission [im]possible ?

2 494 vues

Publié le

Dans un contexte d’entreprise souvent perçu comme rigide, envisager des changements techniques et organisationnels peut sembler impossible. DevOps est un bon contre-exemple car il existe des façons progressives d’introduire une telle méthodologie à plusieurs niveaux de l’entreprise. Cette session revient sur les principes de bases de DevOps (infrastructure-as-code, continuous delivery, culture de collaboration) et leur application pas-à-pas dans différents contextes.

Publié dans : Technologie
0 commentaire
5 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 494
Sur SlideShare
0
Issues des intégrations
0
Intégrations
33
Actions
Partages
0
Téléchargements
155
Commentaires
0
J’aime
5
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • FBI
    On se présente.
    Mini-sondage :
    Qui connait DevOps ?
    Qui pense faire du DevOps ?
  • FBI
    Ca peut avoir l’air compliqué à mettre en place, peut-être aussi pas adapté à votre environnement.
    C’est pourtant accessible à toutes les organisations, environnements. On peut faire du DevOps adapté à son context.
  • RFE
    Avant de se poser la question de COMMENT !
  • RFE
  • RFE
  • RFE:
    Voilà d'où viennent les 51%
  • RFE
    Ces piliers découlent de besoins sur le terrain
    Au niveau dev : consommation feedback loop, comment va mon bébé en production ? Des contraintes d’archi ?
    Au niveau ops : production feedback loop, quelles contraintes dans les conditions réelles et comment réagir
  • RFE
    Infra as code = ops mettent à dispo outils pour les devs
    Etc.
  • FBI
  • FBI
    Objectifs :
    Provisionnements de machines et déploiements d’infrastructures et d’applications automatisés
    Gestion de configuration automatisée
    S’assurer que la configuration des machines est identique d’un environnement à l’autre
    Comment ? :
    Avec un ensemble d’outils, du provisionnement de VMs au déploiement applicatif qui facilitent l’automatisation et la répétabilité des processus
    Pourquoi ?
    Garantir une infrastructure homogène
    Assurer le respect des standards en place
    Configurer un environnement plus rapidement
    Faciliter la diffusion des mises à jours / paramétrages
    Mettre au service des Ops les outils des Dev
    Finalité :
    On écrit du code qui par contrat va configurer les machines, mettre en place les flux, déployer les applications et orchestrer l’ensemble
    Rapprocher les méthodes de travail des Dev et des Ops
  • FBI
    Un ensemble d’outils, du provisionnement de VMs au déploiement applicatif

    Facilitent l’automatisation, la répétabilité des processus
    Garantir une infrastructure homogène
    Assurer le respect des standards en place
    Ouvrir l’exécution de certaines tâches
    aux développeurs
    Configurer un environnement plus rapidement
  • FBI
  • FBI
  • FBI
  • FBI
  • RFE
    UDD -> principe de base
    Avec DevOps il va plus loin
  • RFE
    Déployer en continu c’est :
    Construire un meilleur produit grâce à plus de feedbacks
    Gagner du temps en huilant son processus de déploiement
    Améliorer la qualité en limitant les risques d’une livraison
  • RFE
    La marche haute fait mal quand on tombe
  • RFE
    Réduire la taille des déploiement c’est :
    Minimiser les risques
    Réduire le « Time To Repair » (TTR)
    Réduire le temps d’indisponibilité
  • RFE
    Améliorer
    Le temps d’approvisionnement des environnements
    La fréquence et durée des déploiements
    Le MTTR (« Mean Time To Repair »)
  • RFE
    DevOps -> réorganisation du département support
    Une partie est prise en charge par les dev, ils connaissent le soft et apprennent la plateforme
  • RFE
    Améliorer le TTM = accélérer toutes les phases d’un projet (dev / test, packaging, déploiement)
    Au final -> accélérer la concrétisation des idées (servir le business / les utilisateurs)
  • RFE
    Toutes les étapes sont automatiques
    Objectifs :
    Fiabiliser les déploiements
    Déployer plus vite
    Augmenter la qualité
  • RFE
    Industrialiser le processus de développement et garantir la qualité logiciel
    Intégration continue
    Test Driven Development
    Revue de code obligatoire
    Usine d’audit en continue
    Automatisation des Tests fonctionnels & « Behaviour Driven Development »
  • RFE
    Paramétrisez, variabilisez !
    Les applications doivent disposer de caractéristiques logicielles les rendant facilement et rapidement
    Déployables
    Substituables
    Observables et analysables

    + séparer déploiement fonctionnel et technique -> contraintes d’archi
  • RFE
    Un principe majeur est la dissociation du déploiement fonctionnel du déploiement technique
    Feature flipping
    Dark launch
  • RFE
  • RFE
    Ex: Gmail
  • RFE
  • RFE
  • FBI
  • FBI
    Réduire le Time To Market (TTM) sous contrainte d’opérabilité
    La frontière entre études et production est généralement un point de friction dans les organisations pour atteindre ces objectifs
    A première vue, objectifs contraires
    En fait, objectifs en phase (feedback loop et amélioration des deux)
  • FBI
    L’un des objectifs de DevOps est de mettre ses 2 équipes autour de la même table et de les faire discuter dans un même objectif …
  • FBI
  • FBI
  • FBI
    Des équipes projet dissoutes au moment de la MEP
    Des équipes production organisées par centre de compétences multi projets
  • FBI
  • FBI
  • FBI
  • FBI
    Des compétences d’exploitation qui remontent dans les équipes produits
  • RFE
    Strator: Ex d’un script de déploiement v1 mis à disposition par les devs
    Que les ops ont repris, amélioré, et ont partagés en utilisant les mêmes outils (placé dans gestionnaire de sources)
    Collaboration étroite / échanges d’outils et de pratiques
  • RFE
  • RFE
  • RFE

    Rendre les applications, les infrastructures et les processus observables et mesurables
    Métrologie
    Supervision technique
    Supervision applicative

    Strator: Encore un système mis en place progressivement, en amélioration continue,
    Avec une collaboration étroite dev et ops, qui permet d’avoir une vision tech et business sur la PROD
    Résultat : un DG qui passe dans les bureaux de la PROD pour consulter le dashboard
  • FBI
  • Si vous deviez retenir une chose, c’est celle-la.
    L'IT c'est un moyen et pas une finalité.
    Objectif de satisfaire le business / nos utilisateurs
  • Implique l’humain

    Transition
    2 environnement en simultané
    À côté de la prod
    coûteuse
    18 mois / 2 ans
    Petite prod : 200 000 €
    30 000 serveurs : 3 à 5 M€
    Le but final n’est pas la réduction des coûts
    Amélioration du TTM

    Bénéfice
    Immédiat
    Temps de mise en production
    Long terme
    Appropriation du produit de bout en bout par les équipes
  • FBI
  • DevOps : mission [im]possible ?

    1. 1. 11 Romain Felden & Farhdine Boutzakhti @herrFelden & @farhdine DevOps : Mission [im]possible ?
    2. 2. 22 Notre mission : Démystifier l’approche et la rendre accessible !
    3. 3. 33 Pourquoi DevOps ?
    4. 4. 44 Presque 50% temps total des activités des équipes d’exploitation est consacré au déploiement :   Gestion du déploiement   Gestion des incidents (liés en grande partie au déploiement) ACTIVITÉS DES ÉQUIPES OPS Source : Etude de Deepak Patil (Microsoft Global Foundation Services) de 2006, via une présentation de James Hamilton (Amazon Web Services) http://mvdirona.com/jrh/TalksAndPapers/JamesHamilton_POA20090226.pdf
    5. 5. 55 A LA MAIN ?
    6. 6. 66 Jusqu’à quel point l’infrastructure est automatisée ? AUTOMATISATION DE L’INFRASTRUCTURE Chiffres issus d’un sondage de 690 « Ops » par RebelLabs / ZeroTurnAround (société éditrice de jRebel et LiveRebel) fait en 2013 All rights reserved. 2013 © ZeroTurnaround OÜ infrastructure as code, and those are the early adopters that manage their for this survey. This isn’t anyth code is not som infrastructure. HOw mucH Of yOur InfrasTrucTure DO yOu cOnfIgure wITH cODe? Less THan 10% 61% 10%-25% 5% 51%-75% 8% 76%-90% 6% mOre THan 90% 10% 26%-50% 10% puppeT cHef cfengIne ansIbLe fabrIc basH
    7. 7. 77 ETENDRE L’AGILITÉ À LA PRODUCTION DEVOPS Code Build Test Deploy Operate Monitor Dev Ops Développement Agile Déploiement / production Agile
    8. 8. 88 3. Culture de la Collaboration Dev Ops 2. Continuous Delivery 1. Infrastructure-as-code AGENDA
    9. 9. 99 Infrastructure- as-code Continuous Delivery Infrastructure- as-code Culture de la Collaboration
    10. 10. 1010 Infrastructure = Code
    11. 11. 1111 Source : http://code.google.com/p/devops-toolchain/wiki/ToolChainsAndUseCases PROVISIONING ET DÉPLOIEMENTS AUTOMATISÉS   Déploiement applicatif   Déploie, configure et connecte les ressources   Configuration système   Configure les ressources de façon homogène   Infrastructure agile   Virtualisation   Environnements complets en self-service
    12. 12. 1212 L’art de builder et de versionner son SI ! Que contient un SI industrialisé ? Des outils de gestion des vms Des images d'OS Des packages OS Des configurations système Des middlewares Des scripts d’installation/mise à jour de middlewares Des configurations middleware Des applications Des scripts de déploiement des applications P’TIT REX
    13. 13. 1313 La stack technique : P’TIT REX OS Middleware Machine Physique Configuration applicative technique Chef Manuel PartieapplicativePartietechnique Configuration Middleware Configuration Système Machine Virtuelle Application PXE ou Clone de VM Capistrano OpenStack
    14. 14. 1414 P’TIT REX Une version du SI :
    15. 15. 1515 Jenkins EXEMPLE D’AUTOMATISATION DU PROVISIONNING EXEMPLE AVEC CAPISTRANO ET CHEF Git Nexus Capistrano Node Chef Hyperviseur API hyperviseur Node Chef Node Chef Dép. app. 2 1 1 3 •  Capistrano demande VM à l’hyperviseur •  Installation OS par PXE ou clone 2 •  Création & mise à disposition VMs •  SSH ouvert, IP temporaire 3 •  Scripts de démarrage (maison, cloud-init…) •  Personnalisation VM, IP, Reseau etc •  Installation Chef 4 4 4 •  Capistrano lance Chef sur Node •  Chef récupère les cookbooks via Git •  Installation packages et configurations 5 5 5 •  Capistrano lance déploiement •  Exécute sur machine téléchargement livrable •  Déploie livrable •  Administrateur lance job0
    16. 16. 1616 Continuous Delivery Continuous Delivery Infrastructure- as-code Culture de la Collaboration
    17. 17. 1717 APPRENDRE VITE DU TERRAIN
    18. 18. 1818 Change Temps Beaucoup de code = Risques importants
    19. 19. 1919 “IF IT HURTS, DO IT MORE OFTEN !” Change Temps Petit changement = Risques maîtrisés
    20. 20. 2020 CONSTRUCTION ET LIVRAISON CONTINUE John  Allspaw,  Etsy   h0p://www.slideshare.net/jallspaw/ops-­‐metametrics-­‐the-­‐currency-­‐you-­‐pay-­‐for-­‐change  
    21. 21. 2121 Réduire le TTR
    22. 22. 2222 Réduire le TTM
    23. 23. 2323 CONTINUOUS… Déployé sur un environnement d’intégration Livré à l’équipe suivante (QA, MEP …) Déployé en production CONTINUOUS INTEGRATION CONTINUOUS DELIVERY CONTINUOUS DEPLOYMENT
    24. 24. 2424 INTÉGRATION CONTINUE
    25. 25. 2525 SÉPAREZ LE BLANC DES JAUNES !
    26. 26. 2626 Facebook : > 2 déploiements par jour Flickr : > 10 déploiements par jour Etsy : > 25 déploiements par jour Amazon : 1 déploiement toutes les 10 secondes sur 10000 machines CHEZ LES GÉANTS DU WEB
    27. 27. 2727 ZERO DOWNTIME DEPLOYMENT Le  Zero-­‐downAme  Deployment   (ZDD)  permet  de  déployer  une   nouvelle  version  d’un  système   sans  interrompre  le  bon   foncAonnement  du  service.  
    28. 28. 2828 Blue/Green Deployment   Pattern standard de ZDD   Une chaîne complète de l’infrastructure est dédiée à la version N+1 Pattern associé : Canary Release   Permet de confronter la version N+1 à une population restreinte d’utilisateurs   Les mécanismes sont identiques au Blue/Green Deployment PATTERNS DE DÉPLOIEMENT Version  N  du  système   Version  N+1  du  système   Load  Balancer   Serveurs   Web   Serveurs   Applica>on   Serveurs   Données   Load  Balancer   N+1 N
    29. 29. 2929 FEATURE FLIPPING http://code.flickr.net/2009/12/02/flipping-out/ if ($cfg.enable_unicorn_polo) { // do something new and amazing here. } else { // do the current boring stuff. }
    30. 30. 3030 Contexte Quotidien national Développement interne agile (Scrum) Objectif   Minimiser l’impact des mises en production sur l’exploitation Améliorer le TTM des nouvelles fonctionnalités Stratégie Livrer souvent Mesurer Solutions Chaîne de livraison continue   Monitoring / feedback loop Le nombre de mises en production passe à environ 10 par jour P’TIT REX
    31. 31. 3131 Culture de la Collaboration Continuous Delivery Infrastructure- as-code Culture de la Collaboration
    32. 32. 3232 Culture  du  Produit  (logiciel)   Culture  du  Service     (archivage,  supervision,  etc.)   Cherche  à  délivrer   Cherche  à  fiabiliser   LE MUR DE LA CONFUSION Dev Ops GaranAr  le  Run  des  applicaAons   (stabilité)   Livrer  de  nouvelles   fonc>onnalités  (de  qualité)   Objec>fs  locaux   Objec>fs  locaux  
    33. 33. 3333
    34. 34. 3434 ALLEZ PRENDRE UN CAFÉ !
    35. 35. 3535 AIDE TON PROCHAIN !
    36. 36. 3636 MODÈLE 1 : UNE ORGANISATION ORIENTÉE PROJET…
    37. 37. 3737 MODÈLE 1 : LA PATATE CHAUDE
    38. 38. 3838 MODÈLE 2 : UNE ORGANISATION HYBRIDE… Agile Agile Agile Exploitation + Infrastructure DEV + TMA
    39. 39. 3939 YOU BUILD IT, YOU RUN IT! WERNER VOGELS CTO @AMAZON
    40. 40. 4040 MODÈLE 3 : UNE ORGANISATION ORIENTÉE PRODUIT !
    41. 41. 4141 PRÊTE TES JOUETS !
    42. 42. 4242 #1. Culture de la collaboration INTÉRESSER LES « DEV » AUX PROBLÈMES DES « OPS »… CA VEUT DIRE ÇA!
    43. 43. 4343 CULTURE DE LA MESURE
    44. 44. 4444 SUPERVISION Transactions Métier € Mbps Charge machine Clients déclarés Clients connectés
    45. 45. 4545 Faire participer les Ops aux rituels Partager avec les Ops dans un objectif d’amélioration continue Des Devs qui participent aux mises en production Post Mortem Des Devs qui s’approprient les mesures / métriques P’TIT REX
    46. 46. 4646
    47. 47. 4747 Take Away Continuous Delivery Infrastructure- as-code Infrastructure- as-code
    48. 48. 4848 POURQUOI DEVOPS ? Fiabiliser les déploiements & Réduire le TTM/TTR
    49. 49. 4949 UNE DÉMARCHE PROGRESSIVE
    50. 50. 5050 Romain Felden Farhdine Boutzakhti @farhdine@herrFelden meetup.com/devopsch
    51. 51. 5151 Merci

    ×