1. Building a Test/Dev Cloud with
Apache CloudStack
David Nalley
ke4qqq@apache.org
@ke4qqq
2. #whoami
● Sysadmin of a decade
● Apache Software Foundation Member
● Apache CloudStack Committer & PMC Member
● Fedora Project Contributor
● Employed by Citrix in the Open Source Business Office
3. Why use cloud?
From a dev POV the process normally looks like:
● Start new project
● File ticket for resources....wait....wait....wait
● Get resources, that aren't configured....wait...
● Get network access.....get permission....wait
● Get things done.
4. Why use cloud?
● What IT Operations provides is not what a developer wants.
5. Get rid of the waiting
● Remove the constraints - developers empowered to get things
done.
● Agility
● Enforce automated process instead of manual ones
6. What does a dev/test cloud look like?
● Self-service - developers can provision their own environments
● Usage measurement - we worry about VM sprawl
● Isolated networks - must not let dev/test interfere with the real
world.
● Commodity - as cheap as practical
● May also house production workloads
7. Self service
● Provisioning manually doesn't add value
● Can be completely automated
● Do they need full control or just pushing pre-configured
environments?
14. Usage
● Jevons Paradox
● Plenty of waste possible as well - will developers always
destroy a machine when they are done with it?
● Important to show what projects and groups are consuming
resources as well as how they are using those resources
15. Commodity - Storage
● Commodity storage - this is dev/test environment - high
performance, resilient storage isn't needed.
● Local storage tends to be the best mix of cheap and performant
● No failover, but it's dev/test - do you need it?
16. Commodity - Networking
● Layer 3 isolation - (aka Security Groups)
● VLANs - (not as commodity, but still relatively cheap on a small
scale, but not at scale)
● Virtual routers (provide DHCP, DNS, LB, Firewall, PF, NAT, etc)
17. Commodity Hypervisor
● KVM is my personal choice in this space.
● Easiest to consume - completely open source
18. Limiting resources
● Limit the number of VMs, snapshots, IP addresses, etc.
● Use 'projects' to share resources
● This means most folks will never have problems, but heaviest
users will not be able to interrupt service for others.
Dev wants to work - IT has process, and tickets, etc.
Talk a lot about the general architecture of CloudStack
What does self service really mean?
IS this really your idea of enabling developers? It might be nice to have, but it shouldn't be the real interface - even with defaults this takes 6 clicks.....which is better than filing a ticket, but doesn't scale.
Elasticity is only imagined - look at default limits placed on AWS users.