20151120 d day marseille docker rex

336 vues

Publié le

http://sched.co/4YeN Retour d'expérience Docker chez Orange lors des devops DDay à Marseille orgnaisé par Treeptik

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

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
336
Sur SlideShare
0
Issues des intégrations
0
Intégrations
22
Actions
Partages
0
Téléchargements
10
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • Renaud
  • Renaud
    Bref, cool, faut qu'on y aille … et Renaud a convaincu son manager et le manager de son manage de nous laisser (3 personnes) explorer sur la techno.
    Enfin, on n'a pas du tout fait de l'exploration : on vise la PRODUCTION!!! Ce qui veut dire que l’on doit savoir déployer, exploiter, opérer, surveiller la QoS , sécurité, …
    On n'est pas là que pour se faire plaisir avec de la techno, non, on est là pour la faire fonctionner

  • Renaud
    La seule vraie preuve dans le SI ou l'IT c’est la PROD: C.A.D servir des clients, savoir gérer sur la durée et de prouver que ça fonctionne …
     
    Pour ça il faut un projet applicatif qui veut se lancer (parce sinon ils ne veulent pas nous donner les moyens de créer des PF de dev ou de sandbox … une vague histoire de CAPEX …)
     
    Et on a trouvé des équipes de développement qui ont voulu jouer avec nous. Et ça c'est priceless ! Et nous tenions à les remercier, parce qu’ils sont aussi fous que nous.

    Ensuite il a fallu convaincre ceux qui s’occupe de la prod au jour le jour: les … OPS – finalement eux aussi ils aiment le challengent !
  • Renaud:
    Avec toutes les questions qui vont avec :
    Comment on fait pour le réseau, et comment on fait pour router
    les back ends on les mets dans des conteneurs ?
    et on pourrait pas avoir un cluster Ah oui et la sécu, c'est important la sécu ! Et le stokage on va faire comment, on n'a que du NFS pour l'instant
    du service discovery, ce serait bien du service discovery.
    et on met quoi dans le conteneurs
    Et ces quelques petits sujets en … 4 mois, en partant de pas grand-chose.
     
    OK … On y va !!!
    Juste qu'il faut voir ce sur quoi on s'engage vraiment.
  • Renaud
  • Philippe
  • Philippe :
    Avant de commencer un peu de vocabulaire Docker pour que l’on se comprenne bien: Dockerfile, Image, Container et Registry
  • Philippe
    Commençons par parler du contenu du conteneur:
    1 conteneur  1 service afin de mieux délimiter les rôles et les responsabilités applicatives des composants
    1 passage à l’échelle plus simple et plus fin (ne passer à l’échelle que ce qui est nécessaire)
    Ne construire / reconstruire que ce qui est nécessaire
    Plus c’est léger, plus c’est facile à déployer
  • Philippe
    Donc on va parler du cycle de vie de Docker et de ce que nous avons mis en place
    Cycle de vie de l’application dans un Docker:
    développement: les dev fournissent le code & le Dockerfile réaliser en collaboration avec les exploitants (devops)
    construction automatique de l’image par l’usine à image
    déploiement (peu importe la cible: dev, qualif, preprod & prod)
    exploitation, avec la possibilité d’avoir des Docker de l’application avec différente version sur la machine pour les rollback:
    - possibilité de garder la version n-1 pendant que la version n fonctionne
  • Philippe
    Construire le conteneur
    L’usine à image: objectif construction automatique de l’image et première passe de conformité / sécurité
    Point de passage obligé pour arriver dans les registries de production

    L’usine à image est un job Jenkis, qui fait un checkout du code, contruit l’image Docker et vérifier les paquets installés.
  • Philippe
    Fonctionnement simplifié de l’usine à image.
  • Philippe
  • Philippe
  • Philippe
    Une fois en production il faut savoir comment fonctionnement l’application => logs & metrics
  • Philippe
  • Philippe
  • Philippe
  • Philippe
  • Philippe
  • Rnaud
  • Renaud

    On a rien repris de l’existant monitoring, sup, … parce que la maille de notre SI c’est la Machine & PFS != granularité docker qui a une granularité service / micro service
    Tous les outils existants de notre SI sont adhérant à ce modèle
  • RENAUD
  • Don’t manage resources, I manage people !
    I don’t sell mandays, I sell value and I give some sense to it
    I want commitment and results !

    Ttechno : faites des paliers

    On ne sait rien tant qu’on n’est pas à la fin … enfin on se rassure quand meme

  • Organization too mayb
  • Renaud
  • 20151120 d day marseille docker rex

    1. 1. 1 Orange Restricted “DEVOPS-DDAY” Docker@DFY : REX Marseille, November 20, 2015
    2. 2. 2 Orange Restricted DISCLAIMER  If you want to learn Docker or important information about it  If you want to watch sexy girls/boys  If you expect a technology scoop  If you think you’ll learn magical recipes to do whatever you wish
    3. 3. 3 Orange Restricted Docker@DFY : Synopsis  Who (and where) are we ? – just a bunch of IT guys  Why Docker ? – context – reasonable choice ?  The bet we took : we need a significant project to go to production – our production – what’s at stake – challenge accepted !  Implementation choices : get closer of standards we’re aiming to reach – principles – advantages to be carefully conserved – examples  What we’ve learned – a lot of work – ROI is here as long as you dedicated means to reach it  What’s next : bets we’re taking – Docker cluster – Mesos cluster
    4. 4. 4 Orange Restricted Who are we  Orange/OF/DTSI/DSI/DFY/HBX/GOT/NOH – Not long ago in a galaxy far, far away …  4 guys, geeks and unconventional – Including the manager – Technologies are tools we love to use !  Motivated – Strong opinions, beliefs, maybe faith …  Thinking IT is more than machines and software – Humans ?
    5. 5. 5 Orange Restricted Docker@DFY : Why Docker  Old school Technology mastery – Permanent craftmanship – Losing value : bad TTM, expensive maintenance – Pet vs Cattle : very poor efficiency of our hardware capex  Exceptional geographic and organizational position – We have think/build AND run under the same hierarchical roof – Why don’t we rethink the way we address our hosting services  So why don’t we think about fancies technologies : [I|P]aaS – Still a cloudware in the house : changing from Cloudstack to Openstack … – We’re the production ! Difficult to push to PaaS without a global commitment – And Ubuntu LTS 2014 has been released … With Docker in it !  Docker was obviously (already) offering new values – A good complement with our virtual and bare metal offers – Easy to set up, learn and use – Fancy technology : good argument for geeks  Easy marketing : a lot of buzzwords to sell to our teams (and management) – Same components from dev to prod – Scalability, elasticity … Cloud ? – 12 factors app, infra as a code … microservices – Agile, Devops – Hardware Capex efficiency improvements, separation of concerns … – And so on …
    6. 6. 6 Orange Restricted  We manage  We operate  We garantee QoS  We are here to make technology operable  Not (only) to play with it But we’re the production team ! So …
    7. 7. 7 Orange Restricted interne Orange7 OBJECTIVES  PRODUCTION 1. Find a partner • A development team crazy enough • And a significant project to to production with it 2. Convince (real) OPS • To accept this challenge (and risks) 3. Convince management we’ll do the job … To do list
    8. 8. 8 Orange Restricted What’s at stake ?  Project : Advise as a service – A breakthrough (for us) – High visibility : just what we needeed  Delay : 4 month – So what ?  Code refactoring : make it fit into containers  Collect “OPS” constraints – And make them as light as possible – Still give them confidence …  Hosting and system operations : what has to be done (@minimum) – On what infra ? – Logs – Monitoring and supervision : Inside and outside containers – Deployment, orchestration … of containers and software pieces in it – Build chain ? What’s technically at stake ?
    9. 9. 9 Orange Restricted The contract  Alerting in legacy supervision system  Reuse what already exists – When possible … – If it respects the technology philosophy  Operating components: – logs management – Monitoring – Supervision – minimal orchestration
    10. 10. 10 Orange Restricted  Lightweight container  Containers Life cycle  Automating Docker image build  Security  Application configuration  Easy deployment  Metrics  Alerting in legacy supervision system (yes it’s important)  Reuse what exists  Logs: only files  Containerize everything ! Implementation choices
    11. 11. 11 Orange Restricted interne Orange11 Reminder : Basic Docker Vocabulary Dockerfile: text file, composed of various commands (instructions) to build an image Image: an image, is a set of layers as described in a Dockerfile Container: an instance of an image is called container Registry: server that stores and lets you distribute Docker images
    12. 12. 12 Orange Restricted Ligthweight container  1 container  1 service  Easy to scale (up and down)  Only scale what needs to be scale  Only build / rebuild what is needed  Fast and safe deployment  Buzz word: Micro services
    13. 13. 13 Orange Restricted Life cycle
    14. 14. 14 Orange Restricted Automating Docker image build  Build docker image from Dockerfile  Extract the list of installed packages  Verify installed packages  Checkpoint for images before being pushed in registries  Use Jenkins
    15. 15. 15 Orange Restricted interne Orange15 Automating Docker image build / SecuritySCM (Gforge, Orange Forge, Gitorious, etc) Security Preriquisite satisfied 1931 - 2015 Files to build (Dockerfile & co) Image Build Data Extractions Security Check If security preriquisite Are not satisfied… Repository
    16. 16. 16 Orange Restricted Configuration  Staging configuration: – outside the container – or use environment variables  With configuration outside the container – you deploy the same container – in different environments  You can generate / deploy configuration with chef, ansible, puppet .. whatever
    17. 17. 17 Orange Restricted interne Orange17 Deployment  Maestro-ng – immediate availability – effectiveness – simplicity of implementation – manual launch  Description of deployment in a yaml file: – ships : target machines – registries : registries used to retrieve images – services: services to deploy ( set of instances ) – …  Healthcheck  Deployment order : dependencies managed  Deploy all your containers in an command line (in a static way)
    18. 18. 18 Orange Restricted interne Orange18 Application metrics Fluentd: –data collector written in Ruby, easy to patch Heka: –high performance data gathering, analysis, and routing, with a lua sandbox, written in Go InfluxDB –time series and metrics database, written in Go Riemann: –streams events processor, written in … Clojure Grafana –Gorgeous metric viz, and dashboards Metrics collected with Fluentd sent to Heka and processed by Riemann, stored in InfluxDB and displayed in Grafana
    19. 19. 19 Orange Restricted Application metrics
    20. 20. 20 Orange Restricted Docker metrics – same player shoots again  Read docker metrics on disk (file) : – Cpu – Ram – I/O … Metrics collected with Fluentd sent to Heka, processed by Riemann and stored in InfluxDB …
    21. 21. 21 Orange Restricted Docker metrics
    22. 22. 22 Orange Restricted Metrics
    23. 23. 23 Orange Restricted interne Orange23 Containerize EVERYTHING For 1 application in a container, you have: –1 docker to collect Docker metrics –1 docker to collect Application logs –1 docker Heka to route logs/events –1 docker Riemann to process events –1 docker Riemann dash for infra alerting –1 docker influxdb to store metrics –1 docker grafana to display metrics
    24. 24. 24 Orange Restricted Tools … again … we need tools … and we don’t have them all  Inventory tools : – Where are my containers (discovey) – On what machine (at what time) – How many (and what kind of) containers by host – What kind of containers  Inspection tools : – What network interface attached to which container  Graphical tools – Registry – Provisionning …  Reporting, dashboarding, convincing, fu…ng … tools
    25. 25. 25 Orange Restricted interne Orange25 We started from nothing – We wanted to ! We do pets not cattle – Our production system granularity : the machine  And clearly organization is not helping us out  In 4 month all has been rebuilt : – Logs : collection and routing, graphing – Monitoring and supervision (threshold) – Orchestration what we’re doing has Because
    26. 26. 26 Orange Restricted interne Orange26 Technology break … or breakthrough ? Finally… we didn’t go to production in 4 month –It wasn’t that easy for both IT guys (all of them not just us) and developpers –We were ready though … but other problems prevented development team to deliver –We’re close now from production : but final tests are not a piece of cake ! But we did it in 4 month –Cleary still wet (and not drying) –Still changing (a lot) and already too old –But it works We proved Docker can let us go far, very far –Lego building blocks –Pop infrastructure as a code –CI to CD’s Revolution is on his way* … at least it begins to move a bit at Orange *But it’s slow and it takes time
    27. 27. 27 Orange Restricted interne Orange27 The famous …. REX
    28. 28. 28 Orange Restricted interne Orange28 Lessons learned … if any  What is important  Techno is a mean not an end  it ain’t over till it’s over :  Using well buzzwords I don’t appreciate so much 1. The team : all is about giving sense 2. The team : all is about pride 3. The team : all is about fun and interest – a game you play … to win … money or time (which is the same) – techno goes fast … don’t try to go as fast (linearly) … take steps (and breathe slowly) – never stop communicate … get your chakras opened always – be agile and devops … mouarf – it could be a long story … – all has to be integrated : loose coupling is a dream not easy to catch – and discussions never stop …
    29. 29. 29 Orange Restricted  DEVOPS – BUILD & RUN – DESIGN & PRODUCTION – isn’t it only building walls ??? underlining this bloody dichotomy we want to avoid  DEVOPS : what [I|we] learned – are small pizza teams product and value oriented : best definition of devops ever : when developers got the pager in their pocket – run what you build : be responsible, be aware of others constraints, be empathic ! – none is trained to be a devops tech … you become one … it’s a mindset before competencies – still you need skill … a lot of skill : especially with cloud and disruptive technologies : multidisciplinary – I’m bored of hearing devops … so bored … like agile or cloud … I love precise words describing clear concepts …  Doing Devops … is nearly completely impossible (at least for the moment) – Silos ? You know silos ? Organization too ? – And management ? I’m sure you do know management ! And have an idea about it …  Same for ‘Agile’ – We did what we did with officially no machines – Three different projects to (not) achieve it (yet) Devops Dday … DEVOPS ! DEVOPS ? DEVOPS … what about that, Rex
    30. 30. 30 Orange Restricted interne Orange30 AGILE SHARING My two cents vision about it AGILE / LEAN DEVOPS CLOUD CULTURE ORGA AUTOMATION MEASURES
    31. 31. 31 Orange Restricted We’re not there Trust and confidence are lacking But we’ve got all to achieve it … And I believe … (For sure I can’t fly …) Once upon a time in a far far away …
    32. 32. 32 Orange Restricted interne Orange32
    33. 33. 33 Orange Restricted interne Orange33 Keep cool buddy  We need it a lot – Pressure on TTM, – Budgets … – with reliability …  We’re still looking for have chosen solutions – CloudFoundry and Mesos – With what organization and governance ?  Docker seems to be « central » – Automated, orchestrated – A nice build chain – With a managed configuration And good urbanised repositories – Release management is a key feature
    34. 34. 34 Orange Restricted interne Orange34 We need a « tour de PaaS PaaS » IaaS PaaS CaaS CFY Cloudstack Swarm Compose Mesos DUCP Bare Metal aaS
    35. 35. 35 Orange Restricted interne Orange35 Quiete a lot of work to do • MVP approach • Nothing like a full automated PaaS as CFY • Still a lot of difficulties • Technical … Network … multi tenant … security … • Most important : every one has to be transformed … at once … • Does not seem right to me • But, still alive and kicking : having faith and hope (a lot will be needed)
    36. 36. 36 Orange Restricted interne Orange36
    37. 37. 37 Orange Restricted Thank you

    ×