Autosleep: Inactive apps get automatically put to sleep and restarted on incoming traffic
•Télécharger en tant que PPTX, PDF•
2 j'aime•1,953 vues
Did you ever run out of Cloud Foundry cells capacity, while your Iaas budget is already maxed out ? Tired of asking org/space admins to clean up these hello-world apps that waste RAM on the platform ? The autosleep service might help: it automatically stops inactive apps and restarts them upon incoming traffic. Try it by yourself by installing it from https://github.com/Orange-OpenSource/autosleep/ or come to this session to learn its motivations, get the current status of this work-in-progress, watch a demo, and understand how to autosleep service leverages cloudfoundry features (service broker api, route services, CC api) sometimes in unusual ways. This session wraps up with learnings and suggestions for potential evolution of the service broker API that could open up new innovative usages of the platform. These are slides of the Cf summit Santa Clara 2016 talk http://cfsummit2016.sched.org/event/96809c0229663f0bd1f226d4c9e3be33
Recommandé
Recommandé
Contenu connexe
Dernier
Dernier (20)
En vedette
En vedette (20)
Autosleep: Inactive apps get automatically put to sleep and restarted on incoming traffic
- 1. Autosleep service Inactive apps get automatically put to sleep and restarted on incoming traffic
- 2. Introduction • About orange • Autosleep team @gberche gberche-orange guillaume.berche (*) Guillaume Berche Benjamin Einaudi antechrestos benjamin.einaudi (*) Arnaud Ruffin arnaudruffin arnaud.ruffin (*) (*) @orange.com
- 3. Why
- 4. Why ? Image credit: https://www.flickr.com/photos/amagill/3366720659 CC 2.0
- 5. Why ? • For app teams: save cash on public / onprem CF instances • For platform providers – save RAM and increase app density – enables free/cheap/trial tiers
- 6. What suiteable workload ? • non-production – Hello world / tutorials / demos – hackathons/ spikes – API stubs/fakes – serving docs, dev tools – qa, preprod, staging app instances used in ci. • production? – Service brokers 44% non production CF app nstances at Rakuten in 2015 https://speakerdeck.com/tcnksm/how-to-dev-and-ops- internal-paas
- 7. How
- 8. Autosleep features • exposed as a service broker • enrolled apps get automatically stopped on inactivity • auto-wake-up sleeping apps on incoming traffic (work in progress)
- 9. Autosleep features • exposed as a service broker – enrolled app == app bound to an autosleep service instance – 3 modes: • 1- opt-in: user binds app to service instance • 2- standard auto-enrollment: a service instance automatically enrolls apps in associated space. opt-out by unbinding service instance, or exclusion regexp. • 3- forced auto-enrollment: forced enrollment rejects opt-outs (auto-rebinds) – dashboard to check enrollment status and current idle duration • enrolled app automatically stopped on inactivity: – activity measured by cf events + cf logs – configureable idle duration • auto-wake-up sleeping apps on incoming traffic – buffers traffic while app is unavailable
- 10. Demo • installation • standard enrollment • autosleep • autowakeup • forced enrollment Recorded demo at https://drive.google.com/open?id=0B_RQz82R zSUndnd4TFJOODFkTU0
- 11. What
- 12. Autosleep architecture Autosleep-core Autowakeup-proxy Mysql DB Servicebroker DashboardUI Space Enroller Application Stopper CloudFoundry CCAPI Controller Scan apps, [un]Bind apps fetch logs, fetch events, stop apps Sends orphan traffic on mapped wildcard domains Starts apps app team: create service unbind-service delete-service app user: query sleeping app Gorouter Forwards app traffic
- 13. Alternative autowakeup designs Design Pros Cons Route services • autosleep mutualisation between CF instances • enables optimizations (pass appguid in route service url) • Not yet feasible: (no traffic sent to route service unless bound to an active app). Cf-routing priorization in progress. Wildcard route • feasible • automatic « unregistration » when app is started • Single autosleep instance per domain (Single wildcard route by domain.) • Does not coexist well with other wildcard routes • Only works for wildcard domains • autowake up receives unrelated orphan traffic, requiring more capacity to not be vulnerable to DoS
- 14. Potential future improvements • Harden auto-wake-up & queue traffic during restart • HA and load balancing • Dashboard authentication + check permissions • Bosh release / PCF tile packaging • space/org auto-enrollment • Fine grain autosleep tuning (business hours vs off- business hours) • User notification when applications are put to sleep.
- 16. Learnings and PF suggestions Learnings: • service broker CRUD: powerful but restrictive UX • cf-java-client reimplementation: solid but distracting • route services routing traffic to routes with no avail app instances (details) Suggestions: • service broker API enhancements to – propagate requester identity – requester delegate permissions to broker to act on this behalf • Custom CLI UI for service brokers – Service broker actions • cf perform-service-action set-mode –i myautosleep standard –s « mysecret » – Custom plugin auto-installation: • cf autosleep set-mode –i myautosleep standard –s « mysecret »
- 17. Wrap up
- 18. Thanks • This is work in progress available at: https://github.com/Orange-OpenSource/autosleep/ • Test it and tell us what you think • Report bugs • Suggest new ideas • Contribute enhancements Questions / comments / inspirations ?
- 19. Backup slides
- 20. Std vs forced auto-enrollment
Notes de l'éditeur
- I’m working at Orange, one of the leading telco operator in Europe and Africa: 29 markets, 240M subscribers, This talk is about autosleep, a new service broker that automatically stops inactive apps and wake them up on incoming traffic This is a work in progress, as part of an Orange applied research projet, with developments from Benjamin and Arnaud. I’ve been doing product management on this project. Orange started on this project both to get autosleep feature for our CF deployments, as well as better understand/control CF extensions points such as CC API, service broker and route services. It’s also educational for us.
- Why would autosleep be of interest ? Why should you care ?
- Save money and power, do good for the planet.
- autosleep can be deployed within the CF instance, or externally on prem or on my local computer. autosleep will turn off all of my inactive apps on public CF instances. for platform providers, on prem providers will have less dormant apps, and thus be able to turn off some diego cells, lowering infrastructure costs and power consumption. public cloud providers could potentially offer free/cheap/trial tiers by systematically configuring autosleep to only start apps on demand.
- Use-cases for an autosleep service Rakuten in 2015: https://speakerdeck.com/tcnksm/how-to-dev-and-ops-internal-paas 2500 instances: 1400 prod (56%), 700 staging (28%), 400 dev (16%) => non-prod sums up to 44% There might be use cases for production workloads which are rarely used and can cope with a slow start up (up to 60 s) depending on buildpacks used.
- How do you use autosleep to save money or do good for the planet ?
- Why a broker ? Ease discovery, and leverage standard service life cycle, avoids installation prereqs, enables automation (manifest, Cf CLI scripting…) Why not built-in 1st class feature: harder for us, plus we’re keen on learning about SB and route services
- PS1="[\t \W ] $ " autosleep deployment, and wildcard route mapping standard enrollment $ HISTFILE=~/.history-1 $ for a in active-app hello-world production-no-sleep; do cf start $a ;done $ cf cs autosleep default autosleep -c '{"idle-duration": "PT20S", "exclude-from-auto-enrollment": "production.*"}' $ history –a $ watch -c "cf s; echo""; cf a; echo $ cf service-open autosleep $ watch -c -n1 'curl -s -S -k http://active-app.cfapps.elpaaso.net?`date +%s`‘ $ watch -c cf set-env active-app date `date +%s` autowake up forced enrollment $ cf cs autosleep default autosleep -c '{"idle-duration": "PT20S", "exclude-from-auto-enrollment": "production.*", "auto-enrollment": "forced", "secret": "Th1s1zg00dP@$$w0rd"}‘ $ cf unbind-service hello-world autosleep $ cf update-service autosleep -c '{"auto-enrollment": "standard“, "secret": "Th1s1zg00dP@$$w0rd"}' $ for a in active-app hello-world production-no-sleep; do cf unbind-service $a autosleep ; done; cf ds -f autosleep
- What is delivered exactly
- Reactive cf java-client I learned the hard way that …
- We hope this work could inspire service providers into automating some tasks using CC API while providing visibility to app teams, and leaving them some control.