Cloud hybridation leveraging on Docker 1.12
•Download as PPTX, PDF•
0 likes•439 views
Since many apps are not about just a single container, this talk discusses the ability and benefits of creating an hybrid Docker cluster capacity leveraging on Linux+Windows OS and x86+ARM architectures. Moreover, the Docker nodes composing this cloud will be hosted across several providers (local DC, cloud vendors such as Azure or AWS), in order to face various scenarios (cloud migration, elasticity…).
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to Cloud hybridation leveraging on Docker 1.12
Similar to Cloud hybridation leveraging on Docker 1.12 (20)
More from Ludovic Piot
More from Ludovic Piot (10)
Recently uploaded
Recently uploaded (20)
Cloud hybridation leveraging on Docker 1.12
- 1. Adrien Blind DevOps Coach @adrienblind Ludovic Piot, Oxalide Conseil, architecture, DevOps @lpiot Usecase: cloud hybridation leveraging on Docker 1.12
- 2. @adrienblind @lpiotPlease twit us on #experiences ! On-demand & pay-per-use DevOps compliant : easy automation, Infra-as-code, versionnable, reproductible Leads to new usecases: elastic applications, ephemeral environments… The cloud is sexy
- 3. @adrienblind @lpiotPlease twit us on #experiences ! Versatile resources Fail-over through distributed architecture Rebuild vs. restore Frequency of reinstall Pay per-use but… low perf/cost ratio load-balancing network-based architecture : asynchronous architecture A cloudy picture
- 4. @adrienblind @lpiotPlease twit us on #experiences ! Security No network peripheral security New organisation-based security model Managed services very appealing but… vendor lock-in consequences on project/prod collaboration Keep a decent ROI on recent on-premise assets A cloudy picture
- 5. @adrienblind @lpiotPlease twit us on #experiences ! Docker benefits ‘’A universal, self-sufficient and standard artifact embedding an app module, and its subsequent infrastructure configuration’’ Docker provides both the artifact and the ecosystem to handle it! Immutable Portable Lightweight Incremental Versionned/tagged Disposable
- 6. @adrienblind @lpiotPlease twit us on #experiences ! Topology & orchestration App 3 App 2 App 1 X64/WIN X64/LINUX ARM/LINUX An app is made of several atomic containers Compose, Bundle & Service enable to manage topologies of containers accross a single cluster of nodes Docker should support ARM & Windows enabling to describe various types of assets in the topology Third-part assets may be handled artificially through abassador containers
- 7. @adrienblind @lpiotPlease twit us on #experiences ! Span a cluster over providers Extend your network up to cloud vendors platform (VPN, dedicated connections…) Set up an hybrid docker swarm cluster on top of this various commodites NETWORK Host
- 8. @adrienblind @lpiotPlease twit us on #experiences ! Scale the application through docker services Scale the swarm cluster capacity Scale up, scale down BEWARE OF APP ARCHI !
- 9. Adrien Blind DevOps Coach @adrienblind Ludovic Piot, Oxalide Conseil, architecture, DevOps @lpiot Demo
- 10. @adrienblind @lpiotPlease twit us on #experiences ! Architecture Raspberry (ARM) Win 2016 SWARM CLUSTER Load injector (Apache AB) IIS Website MySQL Backend Overlay network Linux X86_64 Linux X86_64 Linux X86_64 Linux X86_64 Linux X86_64 INTERNET (arg!) REDIS
- 11. @adrienblind @lpiotPlease twit us on #experiences ! Have a look on the running cluster Scale the cluster with docker- machine Scale the app with docker service Focuses
- 12. @adrienblind @lpiotPlease twit us on #experiences ! A real, hybrid cluster ARM/Linux x86_64/Linux x86_64/Win x86_64/Linux
- 13. @adrienblind @lpiotPlease twit us on #experiences ! Spawning docker services
- 14. @adrienblind @lpiotPlease twit us on #experiences ! Scale up & down
- 15. Adrien Blind DevOps Coach @adrienblind Ludovic Piot, Oxalide Conseil, architecture, DevOps @lpiot Conclusion
- 16. @adrienblind @lpiotPlease twit us on #experiences ! Docker offers a nice opportunity to create an abstraction layer to facilitate transition to the cloud Hybridation facilitates composite orchestration… when it’ll be fully operational Conclusion
- 17. @adrienblind @lpiotPlease twit us on #experiences ! Step 1 Shift to docker packaging pardigmes Start deploying your apps through docker (trough CD pipelines for instance) Step 2 Shift to dynamic orchestration: swarm cluster handles container deployments over the cluster, ensures desired instances are up, etc. Step 3 Extend your local own cluster to third-part vendors Step 4 Shift to self-healing clusters (autoscaling nodes for instance) Plan your migration
- 18. Adrien Blind DevOps Coach @adrienblind Ludovic Piot, Oxalide Conseil, architecture, DevOps @lpiot Thank you!
Editor's Notes
- ABL/LPI
- LPI Objectif du slide: rappeler brièvement les vertues traditionnelles du cloud, le rendant si sexy Le cloud est porteur des vertues développées ici, ce qui a beaucoup expliqué son succès Présenter un peu cela comme le monde de oui-oui béa, tant la picture est sexy
- LPI Objectif du slide: entâcher la belle image d’épinale précédente en mettant le doigt sur l’enjeu le plus complexe: pour bénéficier du cloud il faut s’en approprier les contraintes. Tout l’enjeu et la complexité porte donc sur la transition vers le cloud, et non la cible Avant tout, cela retourne le paradigme de l’infra vis à vis de l’app Avt, l’infra était designé ad-hoc pour une appli Maintenant, l’archi est contrainte vis à vis d’un set de capacités restreint Instances volatiles : résilience par cluster réinstallation fréquente Reconstruction plutôt que sauvegarde/restauration Faible ration performances/coût : Performance par scalabilité horizontale Répartition de charge Architecture asynchrone Sécurité : Pas de sécurité périphérique Fournisseur : Éviter le vendor lock-in : les fonctionnalités différentiantes que l’on tente de vous vendre sont mécaniquement celles qui vous lockent. => bâtir son PaaS/CaaS sur du seul IaaS public ? Impact sur l'organisation projet/prod Valorisation des assets : et je fais quoi de la capex investie il y a 6 mois dans du matos tout neuf ? Les applications sont intriquées/ pas isolées. Et comme on ne peut généralement pas tout basculer d’un coup…. Conséquence : tout n’est peut être pas éligible au cloud => il faut hybrider les ressources Bonne nouvelle, les patterns d’archi se sont adaptés à cette démarche (microservices & co) Un mécanisme qui crée un artefact unique Tout à la fois package à releaser, à stocker, à distribuer Déployable sans pré-requis complexe, rapidement, idempotent, immuable, sans dépendance, sans processus de réconciliation, ou de reconstruction d'un état cible à instantiation instantanée Dont l'empreinte sur la plate-forme est volatile Et contexte d'exécution indépendant du contexte technique sous-jacent autoportant (faible impact de la plate-forme sous-jacente) cloisonné (pas de risque d'incompatibilité avec les autres artefacts présents sur la plate-forme) Étanche (inaccessible hors des flux autorisés)
- LPI Objectif du slide: entâcher la belle image d’épinale précédente en mettant le doigt sur l’enjeu le plus complexe: pour bénéficier du cloud il faut s’en approprier les contraintes. Tout l’enjeu et la complexité porte donc sur la transition vers le cloud, et non la cible Avant tout, cela retourne le paradigme de l’infra vis à vis de l’app Avt, l’infra était designé ad-hoc pour une appli Maintenant, l’archi est contrainte vis à vis d’un set de capacités restreint Instances volatiles : résilience par cluster réinstallation fréquente Reconstruction plutôt que sauvegarde/restauration Faible ration performances/coût : Performance par scalabilité horizontale Répartition de charge Architecture asynchrone Sécurité : Pas de sécurité périphérique Fournisseur : Éviter le vendor lock-in : les fonctionnalités différentiantes que l’on tente de vous vendre sont mécaniquement celles qui vous lockent. => bâtir son PaaS/CaaS sur du seul IaaS public ? Impact sur l'organisation projet/prod Valorisation des assets : et je fais quoi de la capex investie il y a 6 mois dans du matos tout neuf ? Les applications sont intriquées/ pas isolées. Et comme on ne peut généralement pas tout basculer d’un coup…. Conséquence : tout n’est peut être pas éligible au cloud => il faut hybrider les ressources Bonne nouvelle, les patterns d’archi se sont adaptés à cette démarche (microservices & co) Un mécanisme qui crée un artefact unique Tout à la fois package à releaser, à stocker, à distribuer Déployable sans pré-requis complexe, rapidement, idempotent, immuable, sans dépendance, sans processus de réconciliation, ou de reconstruction d'un état cible à instantiation instantanée Dont l'empreinte sur la plate-forme est volatile Et contexte d'exécution indépendant du contexte technique sous-jacent autoportant (faible impact de la plate-forme sous-jacente) cloisonné (pas de risque d'incompatibilité avec les autres artefacts présents sur la plate-forme) Étanche (inaccessible hors des flux autorisés)
- LPI Objectif du slide: mettre en avant les qualités particulières de l’artefact dans ce contexte: portabilité, immuabilité… Image Docker package Docker build à releaser, tag à stocker, Docker registry à distribuer Docker pull Déployable… Docker run, le déploiement, c'est l'instantiation d'un container depuis une image. Et contexte d'exécution indépendant du contexte technique sous-jacent autoportant (faible impact de la plate-forme sous-jacente) cloisonné (pas de risque d'incompatibilité avec les autres artefacts présents sur la plate-forme) Étanche (inaccessible hors des flux autorisés) On a donc un artefact portable, permettant l’abstraction des couches basses. On peut donc transvaser nos ressources facilement
- ABL Objectif du slide: on fait un zoom-out, mettant en relief le fait que le conteneur n’est qu’un atome ; il reste donc néanmoins nécessaire de modéliser la topologie complète de l’appli. On commence à parler d’hybridation des archis en introduisant ARM.
- ABL Objectif du slide: on aborde maintenant la capacité à hybrider en termes de providers de capacités pour notre cloud. On présente une vision statique, en mettant le doigt sur les aspects réseaux servant de backbones en particulier : on peut créer des VPNS, on peut utiliser des providers de connexions dédiées (intercloud, etc.)
- ABL Objectif du slide: exposer le fait que la scalabilité se joue au sein des applications au premier titre (et rappeler rapidement comment on le fait en docker 1.12, car ce n’est pas l’enjeu de la présentation). On déplace donc le débat sur la capacité à scaler notre capacité d’hébergement, qui est un débat distinct. On rappelle tout de même qu’il faut que l’application soit « pensée » pour cela (par ex. en cas de scale down, le conteneur portant une instance d’appli est trashée, on peut perdre de la data, etc.) Dans les deux cas, l’archi de l’appli est essentielle pour ce genre de scenarios: il faut qu’elle soit capable de scaler horizontalement, de pas perdre de data lorsque un conteneur est tué, etc.
- ABL/LPI Objectif du slide: un schéma qui synthétise la plateforme et ses différents axes d’hybridation All hosts directly on internet
- LPI Montrer la plateforme: avec des docker node et inspect, montrer celui-ci Montrer l’app : montrer la topologie compose, la docker stack / docker services Modifier le scaling de l’app avec la commande docker service : si on a mis en place la petite boucle d’asservissement cela devrait au passage engendrer le provisioning de nouveaux nœuds sur le cluster
- ABL L’enjeu ne porte pas tant sur le cloud, mais sur la façon de l’atteindre, considérant tout les impacts de celui-ci La portabilité des conteneurs, les overlay network et l’orchestration de swarm combinés permettent de créer une couche d’abstration élégante facilitant cette transition L’hybridation des backends (ARM/Linux/Windows) permet de décrire la topologie d’applications hétérogènes, et de tirer profit au mieux de chaque technologie.
- LPI