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.
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