Architecture microservices avec docker
- 1. ArchitectureMicroservicesavecDocker Présentation de est mise à disposition selon les termes de la@CattGr licence Creative Commons Attribution 4.0 International
- 2. EN45MINUTES... 1. Le constat. 2. Petit rappel sur Docker. 3. Les Microservices, c'est quoi ? 4. Pourquoi migrer vers les Microservices ? 5. Quels outils pour orchestrer ceci ?
- 3. LECONSTAT Les géants du web ont changé leurs méthodes de développement et de déploiement depuis plusieurs années pour être plus efficace. Les petites entreprises innovantes utilisent maintenant les mêmes méthodes. Docker, Devops, Orchestration, Microservices, ... Et nous ?
- 4. CHANGEMENTDEVITESSE Datacenter Virtualisation Docker Déploiement dans le mois ⇨ Déploiement dans la minute ⇨ Déploiement dans la seconde Pendant des années Pendant des mois Pendant quelques heures/minutes Développement en cascade Agile DevOps
- 6. DevOpsestunepartied'unchangement pluslarge QUI ? QUOI ? COMMENT ? DevOps Cloud Apps + Microservices Containers
- 9. LesoutilsDockerlibres DOCKERMOTEUR/CLIENT Le moteur et le client pour utiliser docker en cli. DOCKERMACHINE Permet de créer automatiquement un environnement virtuel pour lancer Docker. DOCKERCOMPOSE Permet de lancer des applications multi-containers. DOCKERSWARM Permet de gérer les containers Docker dans un cluster.
- 10. LesoutilsDockerlibres DOCKERREGISTRY Application de gestion des images locales. NOTARY Outils permettant la signature des images par le fournisseur et la vérification de l'intégrité par le client. LIBNETWORK Outil d'abstraction réseau permettant la communication et l'isolation entre les containers et ceci même sur des nœuds différents.
- 12. Pourquoiutilise-t-onDocker? Distribution des applications facilitée. Comportement identique des applications en Dev/Qualif/Prod. Déploiement, lancement et arrêt rapide. Linux et Windows (en preview dans Windows Server 2016) Permet de reconstruire un container à partir d'un simple fichier Dockerfiles. Gestion des containers avec peu d'outils, identique sur toutes les plateformes. Des API disponibles pour piloter l'ensemble depuis d'autres applications.
- 13. TheTwelveFactors La popularité de Docker vient en partie de sa compatibilité avec les règles 12 Factors. 1. CODEBASE 2. DEPENDENCIES 3. CONFIG 4. BACKINGSERVICES 5. BUILD,RELEASE,RUN 6. PROCESSES 7. PORTBINDING 8. CONCURRENCY 9. DISPOSABILITY 10. DEV/PRODPARITY 11. LOGS 12. ADMINPROCESS http://12factor.net
- 14. Codebase Tout code doit être géré par un logiciel de suivi de version (git, mercurial, ...). Une application = code source
- 15. Dependencies Toutes les dépendances doivent être clairement précisées. Le système cible n'est pas censé contenir de programme pré-installé. Pas de dépendances implicites.
- 16. Config Est considéré comme configuration, tous ce qui diffère d'un environnement à l'autre (dev, qualif, prod, autre site). Tout élément de configuration doit être passé par des variables d'environnement. Il ne doit y avoir absolument aucune référence à la configuration dans le code.
- 17. BackingServices Un backing service est une ressource externe au conteneur (base mysql, smtp, activemq, memcache, ...). L'accès à ces ressources doit être passé en paramètre. Pas de distinction entre les services locaux et distants.
- 18. Build,release,run On recrée l'application et l'environnement avant tout déploiement d'une nouvelle version. Aucune modification n'est apportée sur l'application déployée. Chaque version déployée a un numéro de version unique (timestamp, numero de commit, ...).
- 19. Processes L'application est exécutée dans l'environnement d'exécution en tant qu'un ou plusieurs processus. Toutes les données doivent être stockées dans une ressource externe (base de données). Les variables de sessions utilisateurs ne doivent jamais être stockées localement.
- 20. Portbinding L'application fournit un service qui écoute sur un port.
- 21. Concurrency Chaque application peut être mise à l'echelle. Les conteneurs peuvent être lancés x fois pour répartir la charge. Le programme dans le conteneur ne doit pas être lancé en tâche de fond. L'arrêt du programme entraîne l'arrêt du conteneur.
- 22. Disposability Le conteneur doit être jetable. Il doit donc pouvoir être lancé très rapidement. Un arrêt intempestif ne doit pas compromettre les données.
- 23. Dev/prodparity Le développeur doit pouvoir déployer rapidement le code qu'il vient de finir d'écrire. Le développeur doit être plus proche du déploiement (DevOps). Maintenir le développement et la production aussi semblables que possible en utilisant les mêmes outils. Éviter de prendre des backends différents en prod et en dev (ex: base de données, ...) pour limiter les surprises en production.
- 24. Logs Les applications doivent externaliser leurs journaux pour la visualisation et l'archivage à long terme (ELK, Spunk, rsyslog ...). Les journaux peuvent s'afficher dans la sortie standard de l'application, mais pas dans un fichier du conteneur.
- 25. Adminprocess Les commandes d'administration doivent s'exécuter dans un environnement identique aux autres processus d'exploitation. Même conteneur, mêmes variables d'environnement, mais en mode interactif.
- 27. MICROSERVICES
- 28. JusteunBuzz? Micro-Web-Services en 2005 Définition Microservices en 2011 Microservices c'est comme SOA mais seulement les bonnes parties.
- 30. Lesapplicationsmonolithiques Composant 1 Composant 2 Composant 3 Vue Web API
- 31. Lesapplicationsmonolithiques Applications N-tiers. IHM, core, accès aux BDD. Chaque modification nécessite de redéployer la totalité de l'application. Chaque modification nécessite de retester l'ensemble de l'application. Difficile de garder au fil du temps une bonne structure modulaire. Mise à l'echelle couteuse. Manque de diversité technologique. Pas facile de changer un composant.
- 32. LesApplisMicroservices API Gateway App Web UI App Rest API Messaging www DB DB DB Composant 1 App Composant 2 App Composant 3 App
- 33. LesMicroservices ÉLASTIQUE Un Microservice doit pouvoir être déployé un nombre de fois qui varie en fonction de la demande, et ce, indépendamment des autres services dans la même application. RÉSILENT Un Microservice doit échouer sans affecter d'autres services dans la même application.
- 34. LesMicroservices API Les Microservices doivent avoir une API stable, cohérente et bien documentée. https://openapis.org/ MINIMALMAISCOMPLET Un Microservice doit être le plus petit possible mais pas plus petit. Il doit offire une fonction complète avec des dépendances minimales avec les autres services.
- 35. Avantages Facilite le travail en équipe. Augmente la qualité globale des applications. Permet d'utiliser le meilleur langage de programmation en fonction de la problématique. Permet d'automatiser les tests, la qualification et le déploiement en production. Chaque Microservice peut être mise à l'échelle indépendament et peut être optimisé sans affecter le reste de l'application. Augmentation de la robustesse de l'architecture, de la tolérance aux pannes.
- 36. Inconvénients Nécessite un bon niveau d'expertise DevOps. Gestion décentralisée des données. Application polyglotte. Augmentation du trafic réseau. Coût initial plus élevé. Sécurité des communications entre les Applis. Tous ces points peuvent être résolut par l'utilisation d'outils adéquats et d'un peu d'huile de coude.
- 37. Lamotivationquipousseàutiliserles Microservices Frustration de na pas obtenir le résultat souhaité avec une architecture monolithique. Arrivé sur le marché d'outils permettant le déploiement des applications Microservices avec plus de facilité. Large adoption des solution d'infrastructure en tant que service (IaaS). Le passage des grosses sociétés du Web vers des architectures complètement Microservices. Dans un avenir plus ou moins proche les applications monolithiques ne serviront qu'au prototypage.
- 39. DockerMachine/Compose/Swarm http://www.docker.com AVANTAGES Outils certifiés compatible Docker ;-) INCONVÉNIENTS Pas d'interface graphique libre (Docker Universal Control Plane n'est pas libre.) Difficiles à utiliser pour un déployement à grand échelle sans développer ses propres outils d'administration.
- 40. Kubernetes http://k8s.io AVANTAGES Utilisable en production (v1.1) Support plusieurs type de Containers (Docker, Rkt, Hyper) Permet de gérer des milliers de nœuds. Produits plus ancien que Docker INCONVÉNIENTS Utilise ses propres outils réseau. API différente de Docker
- 41. ApacheMesos http://mesos.apache.org/ AVANTAGES Permet de gérer plus de 10 000 nœuds. Produits plus ancien que Docker. Vient du monde cluster INCONVÉNIENTS Complexité de mise en œuvre (nombreuses briques) Marathon couche d'abstraction pour faire tourner Docker Adapté au monstre du Web
- 42. OpenshiftOriginv3 http://www.openshift.org AVANTAGES Très bon produit PaaS Basé sur Kubernetes Intégration à Eclipse INCONVÉNIENTS Outil Redhat adapter à Docker Fonctionnalités disponibles par rapport à la version RedHat ?
- 43. Rancher http://rancher.com AVANTAGES Simplicté d'utilisation et de mise en œuvre. Utilisation des API Docker, des scripts Docker- compose. Permet de déployer des containers en cloud privé/publique + BareMetal. Gestion centralisé multi-environnement. Connexion ldap, local, github. INCONVÉNIENTS Solution un peu jeune. Pas de retour sur un déploiement à grande echelle.
- 44. Kontena http://www.kontena.io/ AVANTAGES Proche de Rancher mais sans interface Graphique. Utilisation des API Docker, des scripts Docker- compose. Gestion registre Privé. Support clouds publics (AWS, Azure, DigitalOcean) + BareMetal. Gestion des containers stateful pour les BDD. INCONVÉNIENTS Outils + Dev que Ops. Solution un peu jeune, pas prêt pour la production.
- 45. QUESTIONS? Merci