Let Diego Manage Your Docker Application
Did your application fail to start because Docker Hub was unavailable? Someone changed an image you depend on and messed up your application? Every new instance of your Docker application takes ages to download? Cloud Foundry’s new orchestration manager makes it possible to run any application on Linux and Windows, guarantees that the system is eventually consistent with what the users desired and provides enhanced support for running Docker applications. In this presentation we will show you how to take advantage of Docker’s packaging and deployment models, to reliably scale and run your applications without depending on Docker Hub. The project goals include enabling the use of private docker images, highly available backends and effective image management. We’ll also share our experience collaborating in a cross-continent team and the variety of tools we use for adding new features.
Recommandé
Recommandé
Contenu connexe
Dernier
Dernier (20)
En vedette
En vedette (20)
Let Diego Manage Your Docker Application
- 1. Let Diego Manage Your Docker App Georgi Sabev
- 2. Who am I? • SAP Developer • CF Dojo Participant • Cloud Foundry Committer
- 3. Who is Diego? • CF Next Gen Runtime • Self Healing • Eventually Consistent
- 4. Who is Diego? Cloud Controller Task LRP Stager Nsync Bridge Diego Stage App Run App Start Task Run LRP
- 5. CF + Docker? Why? • CF And Containers • Garden • Docker
- 6. CF + Docker? How? • cf-docker • Decker • Diego Native Support cf push --buildpack cf-docker app-dir/ cf docker-push app busybox cf push --stack decker app-dir/
- 7. Problem? What Problem? • Unpredictable scaling • Performance • Private Images
- 9. Demo
- 10. Image Caching Opt-in Support Secure Registry Private Images S3 Storage Disk Quota Riak CS Storage High Availability Golang Registry Docker v2 Timeline
- 11. Team
- 12. Thank You
Notes de l'éditeur
- Coming from Sofia, Bulgaria Backend Focus: SAP’s Enterprise Server, SAP’s PaaS offering, Docker, Cloud Foundry Cloud Foundry Dojo in Diego Team – together with Hristo Deep dive Diego Team Contribution around Docker Integration
- Diego is intended to replace the DEA Self Healing System – if app goes down it brings it back up Embraces the inherently unstable nature of distributed systems Makes clear separation between user desire and actual state
- Cloud controller knows about apps Diego know about Tasks and LRPs Bridge translates the domain of apps in terms of Tasks and LRPs Decoupling of domains makes Diego generic and reusable Explain what happens during staging and start
- CF runs apps in containers Resource optimization Isolation CF uses Warden for container management Why nee Docker? Docker provides a convenient model Images consisting of layers Hub for publishing and reuse of images CF is good at running Docker is good at packaging and distribution
- CF is build to be polyglot platform Buildpacks cf-docker buildpack CF stacks – OS templates for the runner VMs Decker stack Diego Native Docker Support Docker emulation using Warden
- Diego pulls images from internet Diego uses latest version – that can change Problematic scaling Performance hit to download large binaries from internet No support for private images Problem for proprietary software Have to deal with credentials
- Private registry in between Diego and the Hub Accessible only internally Diego uses the registry for caching Explain the staging and start with caching employed Performance improvement – reaching out only once Privacy Still need to deal with credentials Only when staging Makes private image support easier to introduce