DevOps Introduction Ce qui a changé : Le Digital - PowerPoint Presentation

Slide1

DevOps

Introduction

Slide2

Ce qui a changé : Le Digital

On parle de

coût informatique

mais où est la valeur métierLe TTM est toujours là mais pour faire quoi ?L’informatique pour tout le monde, dans tous les objetsPour aller chercher de la productivité complémentaire, je n’ai pas besoin d’un chef mais d’autonomie

2

Slide3

Les impacts : Autonomie, TTM

& Innovation, Multiplication des

devices

Plus de MEP pour tester plus souventTous les 3 à 6 mois (2 à 4) => A tous les mois (12) Plus de MEP car les « grosses applications » on étés découpées en produits agiles1 application sert entre 2 à 4 métiers Plus de MEP pour plus de devices, de cibles1 fonctionnalité va s’exécuter en Web, Mobile, … Explosion du nombre de mises en productions

Les activités manuelles du cycle de production

x12 à x48

x3 à x6

x2 à x4

x2

3

Slide4

PERCEPTION DE DEVOPS COMME levier de transformation

4

Source: Gartner (

October 2016)

Slide5

Quand tu attends toujours que l’

autre

ait commencé

5

Slide6

Quand les Ops ne parlent pas avec les Dev

6

Slide7

Quand ta team

scrum

livre sa

feature en prod … 12 mois plus tard7

Slide8

Quand n’importe quel problème conduit à montrer du doigt le coupable

8

Slide9

Une opposition naturelle

Mission

: Livrer rapidement des nouvelles fonctionnalités répondant aux besoins du client

Attentes :Toujours plus de fonctionnalités

Délai de mise sur le marché

Innovation

Agilité

Mission

: Garantir le bon fonctionnement et la stabilité des applications et infrastructures

Attentes : Rapidité de correction des dysfonctionnementsRationalisationEfficacité opérationnelle

SécuritéExpression du besoinTests fonctionnelsTests d’exploitation

Mise en productionExploitationDéveloppements

Plus de changement

Plus de stabilité

Dev

Ops

Intégration

Cycle de fabrication logicielle

9

Slide10

Les différents métiers - Dev

Les

Dev

, développeurs ont la responsabilité de:Développer les applications de l’entreprise en fonction du cahier de chargesCorriger les bugs remontés par les clients ou les équipes de testFournir un livrable à chaque nouvelle version, ainsi qu’un “mode d’emploi” pour le déploiement10

Slide11

Les différents métiers - Ops

Les

Ops

, l’équipe Opérations a la responsabilité de :Fournir les serveurs (Physiques ou virtuels) pour déployer l’applicationGérer le provisioning, les mises à jour de sécuritéDéployer le livrable fourni par les “Dev” en suivant le mode d’emploiVeillez au bon fonctionnement de l’application (Monitoring)11

Slide12

ET MAINTENANT, c’est quoi

devops

?

12

Slide13

DevOps – Definition

13

“DevOps 

represents a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between

operations

and

development

teams. DevOps

implementations utilize technology — especially automation

tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective.”Gartner, http://www.gartner.com/it-glossary/devops/ DevOps

Slide14

DevOps est avant tout un changement de culture

14

Slide15

DevOps

Le mouvement

DevOps

est né de ce constat d’échec. On le symbolise par l’acronyme CALMS

« CALMS »

représente les

5 piliers fondamentaux

pour une mise en œuvre réussie

de la philosophie

DevOps

DevOps n’est pas :Une méthodologieUn outilUne norme15

Slide16

Culture

DevOps mise avant tout sur la communication entre équipes

Privilégier les interactions humaines aux processus fastidieux.

Aller voir un collègue dans une autre équipe pour lui demander conseil plutôt que de créer un ticketFavoriser la mixité et la proximité des équipesUn rapprochement géographique des Dev et des Ops peut être la solutionAvoir des objectifs communs16

Slide17

Automation

L’aspect le plus visible de DevOps.

L’Automatisation permet de :

Gagner du temps lors de tâches récurrentesCréer des processus répétables, testables, et détecter des erreurs en amontUtiliser d’Infrastructure as Code.17

Slide18

Lean

La philosophie du Lean trouve ses sources dans les méthodes de production de Toyota, où la recherche de la performance se fait grâce à l’élimination des gaspillages appelés « muda » en Japonais

DevOps permet de remettre en cause l’organisation et des modes d’interaction en place

DevOps vise à fluidifier et optimiser, en éradiquant les gaspillages de la chaîne de livraison des applications18

Slide19

Measurement

Savoir identifier les problèmes d’équipes

Mettre en place des sondages anonymes pour identifier les sources de conflits

Mesurer le “Time to Business”Délai entre la demande d’une feature, et sa mise en productionDélai entre le reporting d’un bug, et le déploiement de son fix en productionLes métriques doivent être consultables par tous19

Slide20

Sharing

Partager des objectifs communs

Partager le code source (de Dev, et de Prod)

Autoriser les développeurs à contribuer au répo de production (et vice-versa)Mise en place de Revue de code entre équipesTout le monde peut contribuer au code et participer aux ReviewsPartager les outils et les connaissances et apprendre des autresOrganiser des BBL (Brown Bag Lunch)Participer à des meetups et conférencesPartager aussi à l’extérieur (Contributions Open Source)

20

Slide21

La transformation organisationnelle

Design/Build

Test

Run

Traditionnel

DevOps

Equipe projet intégrée

Equipes « en Silo »

Une démarche DevOps se conçoit d’abord comme une transformation de l’organisation

La mise en place des outils relevant du DevOps viennent dans un second temps au service de cette transformation

21

Slide22

DevOps n’est pas simplement la somme des GENS

22

Slide23

Autonomie, TTM & valeur métier

Infras

Infras

serveur & logiciels

MOE : Tests

Applications

MOE :

Build

Métier

Métier

Métier

Infras

Tests

Produit

Build

Métier

Coût

Valeur

Infras

Infras

Tests

Produit

Build

Métier

Infras

Infras

Tests

Produit

Build

Métier

Impacts organisations/rôles, contrats

Casser les silos pour être tous orientés valeur

Les SI ont travaillé à fournir des applications et une organisation qui privilégie la mutualisation pour optimiser les coûts.

10

23

Slide24

Comment démarrer ?

Identifier

toutes

les parties prenantes, leurs rôlesIdentifier les objectifs et les moyens de chacunMétier : réponse et couverture du besoins  Démo, tests de recetteOps : installation, Exploitation  Outils, Normes & ProcéduresDevs : qualité des développements, retours utilisateurs  Intégration continue, mise à disposition, démoIdentifier le plan de développementItératif et incrémentalPiloté par les exigencesFonctionnelles (user story, …)

Techniques (exploit,

install

, …)

24

Slide25

Comment démarrer ?

Exemple d’exigences

En tant qu’

Utilisateur, je me connecte sur le portail….La Procédure d’installation doit êtreAutomatiséeMulti-environnementRépétableTestableIdentifier le rythme projet, par exemple : Installation et tests en environnement de développement = tous les joursInstallation et tests en environnement de qualification = 2x / semaineMise à disposition et Installation sur environnement de recette à chaque itération = toutes les 2 ou 3 semainesInstallation sur environnement de pré-Prod = toutes les 6 semaines

Fonctionnelle

Technique

25

Slide26

Exemple: Chaine DevOps

26

Slide27

DevOps

DevOps

et l’Agilité

Slide28

Approche classique: Cycle en V

28

Slide29

Approche classique: Cycle en V

Course de relais

Séquentielle et

prédictiveNon rapide et non flexibleGrosse pression sur les délaisNégation dangereuse que le périmètre peut évoluerParadoxe et difficulté du sous-traitant à s’engagerLe sous-traitant minimise l’estimation quitte à se rattraper lors des change durant le projet29

Slide30

Approche AGILE

La notion de méthode agile a été officialisée en 2001 par un document

Manifeste Agile

(Agile Manifesto) signé par 17 personnalités impliquées dans l'évolution du génie logiciel« Une méthode agile est une approche itérative et incrémentale, qui est menée dans un esprit collaboratif avec juste ce qu’il faut de formalisme. Elle génère un produit de haute qualité tout en prenant en compte l’évolution des besoins des clients »Une méthode agile est doncItérativeIncrémentaleAdaptativeCollaborative30

Slide31

MéthodeS : V, agile, scrum, itératifs ?

3 modes de fonctionnement possibles

et un éventail de possibilités

VAGILEitératifs1 coût, 1 délai, 1 livraison et 1 périmètre

1 coût, 1 délai

, n livraisons et un périmètre ajusté continuellement.

1 coût, 1 délai

,n livraisons et 1 périmètre

31

Slide32

AVANTAGE DE L' agile et intégration continue

Une méthode agile☺

Principe : plus l’intégration est fréquente, moins elle est longue

32

Slide33

DevOps et l’Agilité

Les pratiques

DevOps

et Agiles sont souvent confonduesDevOps cible le problème spécifique de la séparation des équipes Dev et Ops sur les aspects techniques, organisation, et communicationLes méthodes Agiles sont des méthodologies créées pour améliorer le processus de développement.DevOps et Agilité font souvent la paire en entreprise car elles mettent en avant les mêmes principes:Releaser plus souvent pour suivre les demandes clients

Améliorer la qualité des livrables

33

Slide34

DevOps en étendant l’agilité à l’exploitation

34

Slide35

DevOps: Où on va?

End-to-End IT Value Chain

Speed

Continuous Delivery

Continuous Integration

Agile Development

Dev Ops

Time to Market

35

Slide36

Eléments constitutifs : Multiplicité des outils (>250)

Chaîne de

Continuous

Delivery

Gestion des Déploiements et de la configuration

Supervision, Orchestration et Collaboration

Build

et

Intégration Continue

Gestion et Monitoring de la Production

Automatisation des Tests fonctionnels et d’exploitationGestion de versionsdu code source

Vérification de la qualité du code

Intégration continue

Tests fonctionnels

et métier

Gestion des releases

Orchestration de la chaîne de fabrication

Tests d’exploitation : charge et de performance

Tests d’exploitation : sécurité applicative

Gestion des infrastructures : Virtualisation et conteneurs

Gestion des infrastructures : Bases de données

Exploitation & Monitoring

Centralisation des logs

Planification, Collaboration & Partage

Configuration et déploiement automatisés des environnements

Gestion des Infrastructures

Gestion des infrastructures : Application

platforms

and

PaaS

36

Slide37

Automate – Build

,

Deploy

, Manage37

Slide38

DevOps

DevOps

& Cloud

Slide39

DevOps & Cloud

Laissons l’infra aux professionnels

Ils font mieux et moins chers

Couverture globaleFacturation à l’utilisation (0€ pour démarrer)Possibilité de scalabilité quasi infinieChaque jour AWS ajoute la capacité équivalente à la capacité nécessaire à Amazon quand l’entreprise faisait $5 Md de CAFlexibilité, vitesse et agilitéDisponibilité de l’infra en minutesEx: 20 secondes pour doubler la capacité d’un parc de milliers de machine39

Slide40

DevOps & Cloud

Ops

: « Le Cloud est un outil au service du produit »

Dev : « Le Cloud est un outil pour construire le produit »Les enjeux sontConcevoir le produit pour tirer parti du CloudInfrastructure As Code Architecture micro servicesDéployer le produit pour tirer parti du CloudContinuous Deployment, MonitoringSécuriser le produitApplicative Security Tests, Tests d’intrusion …40

Slide41

DevOps & Cloud: La cible

« The end of server management »

Penser l’hébergement « Plug ‘n

play »La production doit être sans défaut, mais l’erreur est humaine : pas de connexion ssh sur la productionLe travail du développeur doit s’arrêter au « commit », chaque « push » est une Release CandidateLes applications doivent se déployer sans arrêt de serviceLa scalabilité et la gestion des ressources doivent être gérées par la plateforme elle-même (les arrêts/relances, les backups, etc…) 41

Slide42

DevOps

CI/CD

Slide43

Continuous

Integration

[Fowler 2008]Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily leading to multiple integrations

per

day

.

Each

integration is

verified by an automated build (including test) to detect integration errors as quickly as possible43

Slide44

Continuous

Integration

L’intégration continue consiste à vérifier à chaque modification du code source que le résultat des modifications ne produit pas de régressionObjectif :Garantir la qualité du logiciel (Exécution de tests, Code Style) S’assurer que chaque version du code peut produire un livrable correctLes principaux avantages d'une telle technique sont :Le test quasi-immédiat des modifications La notification rapide en cas de code incompatible ou manquant Les problèmes d’intégration sont détectés et réparés de façon continue, évitant les problèmes de dernière minute Une version est toujours disponible pour un test, une démonstration ou une distribution

44

Slide45

Continuous

Delivery

Le

Continuous Delivery consiste à être tout le temps prêt à déployer une nouvelle version de l’application en production.À chaque modification de code, le livrable est testé et validé pour être déployé en production.La mise en production nécessite ensuite une validation manuelle.45

Slide46

Continuous

Deployment

Le Continuous Deployment va plus loin que le Continuous Delivery.Chaque modification de code, si elle passe les tests et validations, va aboutir à une mise en production, de manière automatiqueLe déploiement continu, est une pratique qui vise à réduire le plus possible le temps de cycle, le temps écoulé entre l’écriture d’une nouvelle ligne de code et l’utilisation réelle de ce même code par les utilisateurs finaux.Le déploiement continu permet depuis une livraison d’installer l’application en production. De même que pour la livraison continue, il doit être possible via un simple bouton de pouvoir revenir en arrière et donc d’avoir une application fonctionnelle sur l’environnement de production.

46

Slide47

Continuous

Deployement

47

Slide48

DevOps

Automatisation du

provisioning

Slide49

Automatisation du provisioning des environnements

Définir un processus commun et répétable

Présentation des alternatives (

Dockerfile, Puppet, Chef, Ansible, Salt)Mise en œuvre via Docker49

Slide50

Provisioning

Le

provisioning

correspond à l’allocation de ressources nécessaires à un projet pour être déployé. On différencie :Provisioning InfrastructureProvisioning Applicatif50

Slide51

Provisioning Infrastructure

Allocation de Machines Virtuelles

Création des éléments réseaux

Réseaux PrivésLoad BalancerIP PubliquesMise en place de la sécuritéSecurity GroupFirewall51

Slide52

Provisioning Applicatif

Installation des packages systèmes

Installation du runtime du langage de l’application

Installation des outils annexesMonitoring & SupervisionLogsBackups52

Slide53

Provisioning : Avant

Installation manuelle

Non répétable

Non testableNon idempotentInstallation à l’aide de scripts bashRépétableTestableNon idempotent53

Slide54

Idempotence

Une opération a le

même effet

qu’on l’applique une ou plusieurs fois C’est un concept important dans le domaine de l’automatisationIl n’est pas nécessaire de connaître l’état actuelAppliquer une opération amène l’infrastructure dans un État désiré54

Slide55

Configuration Management

Un outil de

gestion de Configuration

permet de gérer :Le provisionning de l’infrastructure et de l’applicatifLe déploiement de la configuration de l’applicationLes mises à jour et montées de version55

Slide56

Configuration Management

Les outils de gestion de config se basent sur plusieurs fichiers

Fichiers versionnés dans un gestionnaire de source

Chaque modification de l’infrastructure passe par une modification de codeEnsuite, on applique l’outil de CM pour applique les modifications (d’où l’intérêt de l’idempotence)56

Slide57

Puppet

, Chef

Gèrent le provisioning applicatif.

Architecture Master / AgentUn agent est installé sur chaque serveur.Au démarrage il contacte le serveur master pour récupérer sa configurationIl applique ensuite sa configuration en localInstallation des packages, outils, configuration, etc.Pour modifier le serveur, il faut pousser une nouvelle configuration sur le master57

Slide58

Puppet

, Chef

58

Slide59

Quelques chiffres

Puppet

Labs fondé en 2005~ 350 employésPremier produit commercial (Puppet Enterprise) sorti en 2011Levées de fonds :En 2013, VMWare investit 30M$ (+ partenariat stratégique)En 2014, 40M$ par plusieurs investisseursCommunauté :~ 2 000 Contributeurs Git~ 3 500 Modules publiquesPlus de 2 000 modules mis à disposition59

Slide60

QueL

est sont intérêt?

Éviter les tâches répétitives : on ne fait le travail de configuration qu’une seule fois

Configuration des hôtesCréation des utilisateursGestion des applications, démons et services…Permettre une configuration homogène de parc (recette, pré-production, production)S’assurer que les machines conservent leur configuration / maîtrise rapide du parc informatiqueDéploiement rapide de machinesGain de temps lors de l’exécution d’une MEP et lors de la création de nouveaux environnements / machines60

Slide61

Ansible

Ansible est un logiciel libre et open source

Créé par Michael

DeHaanPremière sortie en 2012Support et interface graphique fournis par Ansible Inc.Ansible Inc. racheté par RedHat en 2015Ansible est:Écrit en pythonSans agent À base de pushUtilisé à grande échelle: Apple, RedHat, NASA, Airbus, etc.61

Slide62

Ansible

Gère le provisioning infrastructure et applicatif.

Architecture

AgentlessAnsible se connecte en SSH sur la machineToutes les opérations sont effectuées à distanceAnsible est aussi capable de se connecter à des APIs pour créer des ressources (Instances Cloud, Record DNS, etc.)62

Slide63

Ansible - caractéristiques

Fichiers de configuration simples à écrire et à lire : pas de programmation complexe!

Notion de

Playbook : ensemble de commandes à appliquer pour une certaine tâche Ex: playbook configuration base serveur centos ou playbook apache Notion de Role : niveau d’abstraction au dessus d’un playbook Ex: permet d’appliquer au serveur centos-apache les rôles centos et apache. Ex: si serveur Ubuntu, alors on appliquera les rôles ubuntu et apache63

Slide64

Ansible Galaxy

https://galaxy.ansible.com/home

64

Slide65

Ansible Tower

Ansible est open-source et supporté par Red-

hat

Red-hat vend un produit qui utilise Ansible : Ansible Tower. Ajoute une interface graphique, simplifie encore l’automatisation et le suivi. Vise le marché des entreprises65

Slide66

Ansible

66

Slide67

ARCHITECTURE ANSIBLE

67

Slide68

 

Language

License

Agent-lessHave GUI

First Release

Ansible

Python

GPL

Yes

Yes2012ChefRubyApache

NoYes2009PuppetRubyApacheNoYes2005

SaltPythonApacheBothYes2011COMPARAISON DES OUTILS DE PROVISIONNING

68

Slide69

Contexte de l’automatisation des déploiement

Une fois l’infrastructure provisionnée, il est nécessaire d’automatiser les déploiements applicatifs.

Sans interruption de service lorsque possible

Avec interruption de service69

Slide70

Sémantique des versions

Il est nécessaire de définir une politique de versioning claire pour toutes les équipes. Classiquement, une version est définie par :

MAJOR.MINOR.PATCH-QUALIFIER

Major : Version incluant des changements non rétro-compatiblesMinor : Version avec ajout de fonctionnalités qui ne casse pas la rétrocompatibilitéPatch : Version incluant uniquement des correctifs, sans nouvelles fonctionnalitésQualifier : Descriptif qualifiant la version (Optionnel)Exemple : 2.0.4-rc170

Slide71

Schéma de base de données

Les évolutions de schéma de base de données doivent être versionnées au même titre que le code de l’application.

Certains outils automatisent les montées de schéma au démarrage d’une nouvelle version. Certains automatisent aussi les rollbacks.

En Java, Liquibase, flywayDB. En Python, Alembic71

Slide72

Rolling Upgrade

Montée de version sans interruption de service.

Un

load-balancer en entrée permet de contrôler sur quels serveurs sont envoyées les requêtes.On enlève un à un (ou par groupe) les serveursOn procède à la montée de version de ces serveursEt on les ajoute de nouveau dans le load-balancerPrérequis : Les deux versions n et n+1 doivent être compatibles avec le même schéma de base de données72

Slide73

Rolling Upgrade

État initial :

Les deux instances sont dans la même version

73

Slide74

Rolling Upgrade

Première étape :

On enlève la première instance du

load-balancer74

Slide75

Rolling Upgrade

On procède à la montée de version de la première instance

75

Slide76

Rolling Upgrade

On rajoute la première instance dans le

load

-balancer.Les deux versions de l’ application fonctionnent en simultané76

Slide77

Rolling Upgrade

On procède ensuite de la même manière pour la deuxième instance

77

Slide78

Rolling Upgrade

On procède ensuite de la même manière pour la deuxième instance

78

Slide79

Rolling Upgrade

L’application a été montée de version sans interruption de service

79

Slide80

Ansible -

rolling

upgrade

Ansible fournit une option pour gérer automatiquement les rolling upgradeLes tâches ne seront effectués que sur 2 serveurs à la fois. Il est possible de définir un pourcentage au lieu d’une valeur fixe80

Slide81

Exemple de configuration: Ansible

Poste Ubuntu

Exploitation

Front x2

Préprod

SVN

Tomcat x2

Batch x2

SolR x8

Front x4

Production

Tomcat x12

Batch x6

SolR x76

Front x1

Tomcat x1

Batch x1

SolR x4

DEV / QUALIF

PIC

Jenkins

versions

81

Slide82

Automatisation du provisioning des environnements

C

ulture

L’outil est au centre du process : On ne modifie plus les serveurs à la mainFaire d’une MEP un non-évènement, avoir confiance en son déploiementAutomationLa création de l’infrastructure et le provisioning sont automatisésPossibilité de créer des environnements éphémères et de les supprimerMeasurementCompter le nombre de déploiement par jour/semaine/moisMesurer le temps de provisioning, essayer de l’améliorerSharingLes fichiers de provisionning et les scripts de déploiement sont partagés entre les équipes, dans un gestionnaire de code source82

Slide83

DevOps

Des exemples de transitions

DevOps

Slide84

Collaboration entre les équipes

Les types d'organisations possibles

Prise en compte des user stories de production

Organisation de cérémonies communesCoopération sur les choix techniquesOutils de communication issues de la démarche ChatOps (Hubot…)84

Slide85

Les types d’organisation

Mettre en place une organisation DevOps ne consiste pas à imposer une organisation.

Les différents équipes doivent avant tout comprendre le besoin, les intérêts de DevOps, et se mettre d’accord sur des objectifs communs.

85

Slide86

Les types d’organisation

la plus classique : Collaboration entre les Devs et les Ops

86

Slide87

Les types d’organisation

Une équipe DevOps dédiée aux tâches d’automatisation

87

Slide88

Les types d’organisation

NoOps

: Une seule équipe qui gère tout, du développement à la production

88

Slide89

ChatOps

Lors de l’utilisation d’un outil de messagerie instantané (Slack,

Hipchat

), installation d’un bot pour interagir avec les équipesVisibilité : Avertir des alertes, des déploiements en coursAutomatisation :Commander des déploiements en parlant au botCelui-ci va ensuite communiquer par API avec les outils utilisés89

Slide90

Stratégies DevOps mal menées : technique first

Attention le DEVOPS

n’est pas une discipline technologique,

mais une technique mixant plusieurs démarches,Dont une démarche technologique

90

Slide91

Collaborer: Établir ensemble les exigences non fonctionnelles

91

≈ 95

Slide92

La maturité requise par DevOps

passe par plusieurs stades

92

La systématisation des tests à toutes les étapes, combinée à l’automatisation de la fabrication et de l’intégration permettront de détecter les anomalies au plus tôt et de livrer un produit de meilleure qualité.

Objectif à 1 an

Effort méthodologique et organisationnel requis

Objectif à 3 ans

État initial

Slide93

Les enjeux

DevOps

Agilité

Succès !93

Slide94

S’organiser en feature TEAM

94